Re: [Libguestfs] New extents structure proposal
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
Attachments:
- signature.asc (application/pgp-signature — 488 bytes)