[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: Kevin Wolf
Subject: Re: [Qemu-devel] [Nbd] Is NBD_CMD_FLAG_FUA valid during NBD_CMD_FLUSH?
Date: Tue, 5 Apr 2016 07:09:26 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Am 01.04.2016 um 09:43 hat Paolo Bonzini geschrieben:
> On 31/03/2016 22:17, Alex Bligh wrote:
> >> > In qemu, read+FUA just triggers blk_co_flush() prior to reading; but
> >> > that's the same function it calls for write+FUA.
> > That's harmless, but unnecessary in the sense that current documented
> > behaviour doesn't require it. Perhaps it should?
> > 
> > I suppose TRIM etc. should support FUA too?
> TRIM is an advisory operation, so it doesn't make sense to force access
> to the medium.

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.

> The closest you could get would be to add FUA to WRITE_ZEROES.  But
> since WRITE_ZEROES is not a particularly common operation there isn't
> much to gain compared to FLUSHing after the write has completed; in
> fact SCSI doesn't have a FUA bit on its WRITE SAME command.

Right, I guess this would mostly be for consistency when FUA is
supported more or less everywhere else.


reply via email to

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