[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paolo Bonzini
Subject: Re: [Qemu-devel] [Nbd] [PATCH v2] doc: Add NBD_CMD_BLOCK_STATUS extension
Date: Tue, 5 Apr 2016 15:50:16 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

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.



Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]