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:
signature.asc
Description: OpenPGP digital signature