qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [Nbd] Is NBD_CMD_FLAG_FUA valid during NBD_CMD_FLUSH?


From: Alex Bligh
Subject: Re: [Qemu-devel] [Nbd] Is NBD_CMD_FLAG_FUA valid during NBD_CMD_FLUSH?
Date: Fri, 1 Apr 2016 10:25:18 +0100

On 1 Apr 2016, at 08:49, Paolo Bonzini <address@hidden> 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







reply via email to

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