Re: [Qemu-devel] [Nbd] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension

[Paolo Bonzini <pbonzini@redhat.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1394 bytes --]



On 05/04/2016 11:24, Markus Pargmann wrote:
> Also it is uncertain if these status bits may change over time through
> reorganization of backend storage, for example holes may be removed in
> the backend and so on. Is it safe to cache this stuff?

If there's no concurrent access, it is.  Even if it is out of date, it
is still a valid representation.  For example, suppose a file has a
hole.  The client knows that *its own client* (whoever's using /dev/nbd0
for example) should write to it before relying on the contents of the
area.  This remains true if a hole becomes a non-hole.

If there's concurrent access, all bets are off.  Suppose a zero area
loses the zero flag.  Client A knows that the area remains zero unless
someone has written to it.  If *another* client B has concurrently
written something, there must be a communication mechanism by which B
tells A to invalidate the cache, or A must not cache the
information---and probably should not request it in the first place.

> Until now something like READ and WRITE where somehow atomic operations
> in the protocol.

No, they weren't.  If you have overlapping I/O from multiple clients
there's no way to know what data you will get.  You might even get old
data and new data interspersed in a single read.  There's definitely no
guarantee of atomicity in either POSIX or NBD.

Thanks,

Paolo


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]