From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48623) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anJF9-0003r1-FO for qemu-devel@nongnu.org; Tue, 05 Apr 2016 01:09:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1anJF4-00013A-Gg for qemu-devel@nongnu.org; Tue, 05 Apr 2016 01:09:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44963) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anJF4-000134-Az for qemu-devel@nongnu.org; Tue, 05 Apr 2016 01:09:30 -0400 Date: Tue, 5 Apr 2016 07:09:26 +0200 From: Kevin Wolf Message-ID: <20160405050926.GC4183@noname.redhat.com> References: <56FD7B7E.4060004@redhat.com> <64B326DA-CDF4-4537-B38A-46E7B57C319C@alex.org.uk> <56FD8069.7020101@redhat.com> <56FE26B2.6090903@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56FE26B2.6090903@redhat.com> Subject: Re: [Qemu-devel] [Nbd] Is NBD_CMD_FLAG_FUA valid during NBD_CMD_FLUSH? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: "nbd-general@lists.sourceforge.net" , "qemu-devel@nongnu.org" , Alex Bligh 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. Kevin