On 15/09/2016 17:23, Alex Bligh wrote: > Paolo, > >> On 15 Sep 2016, at 15:07, Paolo Bonzini <pbonzini@...696...> wrote: >> >> I don't think QEMU forbids multiple clients to the single server, and >> guarantees consistency as long as there is no overlap between writes and >> reads. These are the same guarantees you have for multiple commands on >> a single connection. >> >> In other words, from the POV of QEMU there's no difference whether >> multiple commands come from one or more connections. > > This isn't really about ordering, it's about cache coherency > and persisting things to disk. > > What you say is correct as far as it goes in terms of ordering. However > consider the scenario with read and writes on two channels as follows > of the same block: > > Channel1 Channel2 > > R Block read, and cached in user space in > channel 1's cache > Reply sent > > W New value written, channel 2's cache updated > channel 1's cache not > > R Value returned from channel 1's cache. > > > In the above scenario, there is a problem if the server(s) handling the > two channels each use a read cache which is not coherent between the > two channels. An example would be a read-through cache on a server that > did fork() and shared no state between connections. qemu-nbd does not fork(), so there is no coherency issue if W has replied. However, if W hasn't replied, channel1 can get garbage. Typically the VM will be the one during writes, everyone else must be ready to handle whatever mess the VM throws at them. Paolo > Similarly, if there is a write on channel 1 that has completed, and > the flush goes to channel 2, it may not (if state is not shared) guarantee > that the write on channel 1 (which has completed) is persisted to non-volatile > media. Obviously if the 'state' is OS block cache/buffers/whatever, it > will, but if it's (e.g.) a user-space per process write-through cache, > it won't. > > I don't know whether qemu-nbd is likely to suffer from either of these. It can't happen. On the other hand, channel1 must be ready to handle garbage, it's illegal.
Attachment:
signature.asc
Description: OpenPGP digital signature