Re: [Libguestfs] New extents structure proposal
On 3/20/19 11:57 AM, Richard W.M. Jones wrote:
>> Also an observation: qemu's nbd client only ever issues block status
>> requests with the req-one flag set, so perhaps we should optimize for
>> that case.
>
> I hope to get to the point where future qemu doesn't send the req-one
> flag. There's several threads on the qemu list about how qemu-img is
> slower than it needs to be because it is throwing away useful
> information, and where it is aggravated by the kernel's abyssmal lseek()
> performance on tmpfs. But until qemu learns useful caching, you're
> right that most existing NBD clients that request block status do so one
> extent at a time (because I don't know of any other existing NBD clients
> that use BLOCK_STATUS yet).
Is it ever possible to cache block status results? What happens in
the (admittedly unusual) case where two writers are hitting the same
NBD server? For example if the server is implementing a cluster
filesystem.
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).
--
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)