All of lore.kernel.org
 help / color / mirror / Atom feed
From: Max Reitz <mreitz@redhat.com>
To: qemu-block@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>, Fam Zheng <fam@euphon.net>,
	qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>,
	Maxim Levitsky <mlevitsk@redhat.com>
Subject: Re: [PATCH 0/8] block: Add @exact parameter to bdrv_co_truncate()
Date: Mon, 28 Oct 2019 12:10:54 +0100	[thread overview]
Message-ID: <0dbdc19b-c740-92e1-4ee7-294d3d7581e1@redhat.com> (raw)
In-Reply-To: <20190918095144.955-1-mreitz@redhat.com>


[-- Attachment #1.1: Type: text/plain, Size: 1846 bytes --]

On 18.09.19 11:51, Max Reitz wrote:
> Hi,
> 
> This series is supposed to pull out some of the problems from my
> “Generic file creation fallback” series.
> 
> The blk_truncate_for_formatting() function added there was buggy, as
> Maxim noted, in that it did not check whether blk_truncate() actually
> resized the block node to the target offset.  One way to fix this is to
> add a parameter to it that forces the block driver to do so, and that is
> done by this series.
> 
> I think this is generally useful (you can see the diff stat saldo is
> only +23 lines), because it allows us to drop a special check in
> qemu-img resize, and it fixes a bug in qed (which has relied on this
> behavior for over 8 years, but unfortunately bdrv_truncate()’s behavior
> changed quite exactly 8 years ago).
> 
> However, in the process I noticed we actually don’t need
> blk_truncate_for_formatting(): The underlying problem is that some
> format drivers truncate their underlying file node to 0 before
> formatting it to drop all data.  So they should pass exact=true, but
> they cannot, because this would break creation on block devices.  Hence
> blk_truncate_for_formatting().
> 
> It turns out, though, that three of the four drivers in question don’t
> need to truncate their file node at all.  The remaining one is qed which
> simply really should pass exact=true (it’s a bug fix).
> 
> (I do drop those blk_truncate() invocations in this series, because
> otherwise I feel like it is impossible to decide whether they should get
> exact=false or exact=true.  Either way is wrong.)

Thanks for the review, I’ve applied the series to my block branch and
changed the comment in qed.c as requested and suggested by Maxim on patch 7:

https://git.xanclic.moe/XanClic/qemu/commits/branch/block

Max


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

      parent reply	other threads:[~2019-10-28 11:23 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-18  9:51 [Qemu-devel] [PATCH 0/8] block: Add @exact parameter to bdrv_co_truncate() Max Reitz
2019-09-18  9:51 ` [Qemu-devel] [PATCH 1/8] block: Handle filter truncation like native impl Max Reitz
2019-09-18 20:49   ` Maxim Levitsky
2019-09-18  9:51 ` [Qemu-devel] [PATCH 2/8] block/cor: Drop cor_co_truncate() Max Reitz
2019-09-18 20:49   ` Maxim Levitsky
2019-09-18  9:51 ` [Qemu-devel] [PATCH 3/8] block: Do not truncate file node when formatting Max Reitz
2019-09-18 20:50   ` Maxim Levitsky
2019-09-18  9:51 ` [Qemu-devel] [PATCH 4/8] block: Add @exact parameter to bdrv_co_truncate() Max Reitz
2019-09-18 20:50   ` Maxim Levitsky
2019-10-28 11:05     ` Max Reitz
2019-09-18  9:51 ` [Qemu-devel] [PATCH 5/8] block: Evaluate @exact in protocol drivers Max Reitz
2019-09-18 20:51   ` Maxim Levitsky
2019-09-18  9:51 ` [Qemu-devel] [PATCH 6/8] block: Let format drivers pass @exact Max Reitz
2019-09-18 20:51   ` Maxim Levitsky
2019-09-18  9:51 ` [Qemu-devel] [PATCH 7/8] block: Pass truncate exact=true where reasonable Max Reitz
2019-09-18 20:52   ` Maxim Levitsky
2019-10-28 11:08     ` Max Reitz
2019-09-18  9:51 ` [Qemu-devel] [PATCH 8/8] Revert "qemu-img: Check post-truncation size" Max Reitz
2019-09-18 20:52   ` Maxim Levitsky
2019-10-28 11:10 ` Max Reitz [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0dbdc19b-c740-92e1-4ee7-294d3d7581e1@redhat.com \
    --to=mreitz@redhat.com \
    --cc=fam@euphon.net \
    --cc=kwolf@redhat.com \
    --cc=mlevitsk@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.