[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
size)".
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
cases.
Kevin