On 1 Apr 2016, at 08:49, Paolo Bonzini <pbonz...@redhat.com> wrote: > > On 31/03/2016 22:34, Eric Blake wrote: >> give me possibly stale data because I accessed >> the underlying storage rather than paying attention to in-flight writes >> that would change what I read". > > Overlapping I/O is always unspecified, so you should expect stale data > if a read overlaps an in-flight write.
Sure, that's a consideration for overlapping I/O in general rather than FUA. You need to wait until a write operation has completed to be able to guarantee that a read operation will read back the written data (whether or not it has been persisted to disk rather than e.g. sitting in a cache somewhere). A read following a FUA write that has not completed could be processed prior to the write. Similarly a read following a non-FUA write that has completed must read the written data even if it's not persisted. I'm interested with either Qemu or the kernel have a sense of FUA on reads. Do you have a view on that? This (which was the inspiration for nbd FUA and now appears slightly clearer than I remember at the time): https://www.kernel.org/doc/Documentation/block/writeback_cache_control.txt says > The REQ_FUA flag can be OR ed into the r/w flags of a bio submitted from the > filesystem and will make sure that I/O completion for this request is only > signaled after the data has been committed to non-volatile storage. and > For devices that also support the FUA bit the block layer needs > to be told to pass through the REQ_FUA bit using: > > blk_queue_flush(sdkp->disk->queue, REQ_FLUSH | REQ_FUA); > > and the driver must handle write requests that have the REQ_FUA bit set > in prep_fn/request_fn. If the FUA bit is not natively supported the block > layer turns it into an empty REQ_FLUSH request after the actual write. That's pretty ambiguous as to whether you need to handle it for reads as well. If it does read+FUA means that the read needs an fdatasync() type operation to happen. -- Alex Bligh
