[Libguestfs] New extents structure proposal

[Eric Blake]

On 3/21/19 7:18 AM, Martin Kletzander wrote:

>> For a read-only client: caching 'data' regions is okay, caching 'zero'
>> or 'hole' regions is bad (because even though you are not modifying the
>> image, another writer might be; demoting 'hole' to 'data' is safe - it
>> merely pessimizes into a read() instead of skipping work; but caching
>> 'hole' that is later promoted to 'data' is wrong - it can cause data
>> lass if the client doesn't read the actual data).
>>
>> For a writing client: either you are an exclusive writer (and should
>> know what you wrote, so the cache is the fact that you changed the state
>> yourself) or you are on a cluster filesystem (at which point, your
>> cluster system better have its own rules for how to resolve races
>> inherent in multiple writers, where you shouldn't be relying on block
>> status but on the cluster protocol in the first place).
>>
> 
> Even for the reading client, you don't need to need to access a place on
> the
> disk twice, even one access is racy because there can be a change between
> BLOCK_STATUS and READ.  And that same thing happens in the plugins for
> files and
> everything that someone else can access.  I don't think it is designed for
> concurrent access.  Or is it?

Indeed, there is always a TOCTTOU race when you rely on block status if
there is ever a concurrent writer.  But, is it dangerous?  Without a
block status, we can have either:

reader           writer
------------------------
read sector X as A
                 write sector X as B

or:

reader           writer
------------------------
                 write sector X as B
read sector X as B

with the two steps, we have one of:

reader           writer
------------------------
learn sector X has status Y
read sector X as A
                 write sector X as B

reader           writer
------------------------
learn sector X has status Y
                 write sector X as B
read sector X as B

reader           writer
------------------------
                 write sector X as B
learn sector X has status Y
read sector X as B

where the shortcut is that if the reader sees status 'hole', it skips a
read. Had it done the read in spite of learning about a hole, it would
either see all 0s (contents A - but that's no different than read
winning the race without a status check), or the new content (contents B
just written by the writer - proving the hole status is out of date, but
no different from losing the race without a status check).

In general, trying to copy an image while it is being modified is not
going to work reliably; the main point of block status is to make
copying more efficient, but when copying, you are assuming no concurrent
modifications.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20190321/f58a751c/attachment.sig>