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

[Markus Pargmann]

On Tuesday 05 April 2016 15:50:16 Paolo Bonzini wrote:
> 
> 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.

At least from the protocol side they were atomic. You had one read/write that
does not rely on any other commands before or after.

I think this was mostly a misunderstanding of the "SHOULD" sentence. I was
assuming that should would more be like a "must" which would have introduced
strange requirements for the client, for example that it has to receive the
block status before making any reads. And this as well would have lead to
possibly complicated interaction between two clients receiving block status
before reading.

But there was a mail recently which referenced rfc2119 so everything is fine
with that.

Best Regards,

Markus

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

signature.asc
Description: This is a digitally signed message part.