[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v5 12/21] block: define get_block_status return

From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH v5 12/21] block: define get_block_status return value
Date: Tue, 6 May 2014 15:08:29 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Am 06.05.2014 um 14:31 hat Paolo Bonzini geschrieben:
> Il 06/05/2014 13:34, Kevin Wolf ha scritto:
> >But the result still wouldn't be right. We have an implication that you
> >can't simply reverse:
> >
> >    If this block is unallocated and unallocated blocks read as zero,
> >    then this block reads as zero.
> >
> >You're trying to use something like "If the block reads as zero and
> >unallocated blocks read as zero, it must be unallocated", which quite
> >obviously doesn't work.
> This is not what the condition says in is_allocated.  The right one
> is (excluding the backing_hd case, which is handled with a function
> like the one I sketched in the previous message):
>     If the block reads as zero and not all unallocated blocks read as
>     zero, the sector will be read from BS rather than the backing file,
>     even if it is not allocated.
> This is true, because bdrv_get_block_status does not ask the backing
> file whether it is zero in the backing file.  Thus, reading from the
> backing file does not guarantee to read zeroes.

Aha, this paragraph is the key. :-)

I assumed that bdrv_get_block_status() does ask the backing file, but
apparently it doesn't. The current meaning of BDRV_BLOCK_ZERO is
therefore not simply "sectors read as zero", but "sectors read as zero
and this is determined by bs itself (mostly, except for the backing file

Is it a good idea to rely on this or would it be reasonable for
bdrv_get_block_status() to look at the backing file for returning ZERO
sometime in the future? I think that could be useful information in some


reply via email to

[Prev in Thread] Current Thread [Next in Thread]