[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: backing chain & block status & filters
From: |
Kevin Wolf |
Subject: |
Re: backing chain & block status & filters |
Date: |
Tue, 28 Apr 2020 13:28:53 +0200 |
Am 28.04.2020 um 13:08 hat Max Reitz geschrieben:
> On 28.04.20 10:55, Vladimir Sementsov-Ogievskiy wrote:
> > Hi!
> >
> > I wanted to resend my "[PATCH 0/4] fix & merge block_status_above and
> > is_allocated_above", and returned to all the inconsistencies about
> > block-status. I keep in mind Max's series about child-access functions,
> > and Andrey's work about using COR filter in block-stream, which depends
> > on Max's series (because, without them COR fitler with file child breaks
> > backing chains).. And, it seems that it's better to discuss some
> > questions before resending.
> >
> > First, problems about block-status:
> >
> > 1. We consider ALLOCATED = ZERO | DATA, and documented as follows:
> >
> > * BDRV_BLOCK_DATA: allocation for data at offset is tied to this layer
> > * BDRV_BLOCK_ZERO: offset reads as zero
> > * BDRV_BLOCK_OFFSET_VALID: an associated offset exists for accessing
> > raw data
> > * BDRV_BLOCK_ALLOCATED: the content of the block is determined by this
> > * layer rather than any backing, set by block
> > layer
> >
> > This actually means, that we should always have BDRV_BLOCK_ALLOCATED for
> > formats which doesn't support backing. So, all such format drivers must
> > return ZERO or DATA (or both?), yes?. Seems file-posix does so, but, for
> > example, iscsi - doesn't.
>
> Hm. I could imagine that there are formats that have non-zero holes
> (e.g. 0xff or just garbage). It would be a bit wrong for them to return
> ZERO or DATA then.
>
> But OTOH we don’t care about such cases, do we? We need to know whether
> ranges are zero, data, or unallocated. If they aren’t zero, we only
> care about whether reading from it will return data from this layer or not.
>
> So I suppose that anything that doesn’t support backing files (or
> filtered children) should always return ZERO and/or DATA.
I'm not sure I agree with the notion that everything should be
BDRV_BLOCK_ALLOCATED at the lowest layer. It's not what it means today
at least. If we want to change this, we will have to check all callers
of bdrv_is_allocated() and friends who might use this to find holes in
the file.
Basically, the way bdrv_is_allocated() works today is that we assume an
implicit zeroed backing layer even for block drivers that don't support
backing files.
Kevin
signature.asc
Description: PGP signature
- backing chain & block status & filters, Vladimir Sementsov-Ogievskiy, 2020/04/28
- Re: backing chain & block status & filters, Max Reitz, 2020/04/28
- Re: backing chain & block status & filters,
Kevin Wolf <=
- Re: backing chain & block status & filters, Vladimir Sementsov-Ogievskiy, 2020/04/28
- Re: backing chain & block status & filters, Eric Blake, 2020/04/28
- Re: backing chain & block status & filters, Vladimir Sementsov-Ogievskiy, 2020/04/28
- Re: backing chain & block status & filters, Kevin Wolf, 2020/04/28
- Re: backing chain & block status & filters, Vladimir Sementsov-Ogievskiy, 2020/04/28
- Re: backing chain & block status & filters, Vladimir Sementsov-Ogievskiy, 2020/04/29
- Re: backing chain & block status & filters, Vladimir Sementsov-Ogievskiy, 2020/04/29
Re: backing chain & block status & filters, Vladimir Sementsov-Ogievskiy, 2020/04/28