[Top][All Lists]

[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: Paolo Bonzini
Subject: Re: [Qemu-devel] [Nbd] Is NBD_CMD_FLAG_FUA valid during NBD_CMD_FLUSH?
Date: Wed, 6 Apr 2016 15:28:58 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

On 06/04/2016 15:14, Kevin Wolf wrote:
>>> > > 
>>> > > I think it does make sense. It means that on completion there is no
>>> > > pending discard operation (i.e. either there wasn't a discard or if
>>> > > there was, it has completed) and other readers will see the final state
>>> > > of the blocks.
>> > 
>> > This is what already happens though, isn't it?
> You mean because in practice discard requests aren't even cached, so we
> always behave as if FUA were specified? That's probably right, but is
> there a fundamental reason why some storage backend couldn't have a
> writeback cache for discards?

No, there isn't.  Does qcow2's discard get cached?  I wouldn't be
surprised (and SCSI actually says nowhere that WRITE SAME is durable
without a subsequent SYNCHRONIZE CACHE!).

> It probably wouldn't make sense to introduce FUA for this if it didn't
> already exist elsewhere, but now that we do have it, I'd allow it for
> TRIM, too, for the sake of consistency and symmetry.

Yes, that's fine.


reply via email to

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