From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51470) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anSoZ-0002p9-RO for qemu-devel@nongnu.org; Tue, 05 Apr 2016 11:22:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1anSoV-0004Pr-MA for qemu-devel@nongnu.org; Tue, 05 Apr 2016 11:22:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:31210) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anSoV-0004Ph-GY for qemu-devel@nongnu.org; Tue, 05 Apr 2016 11:22:43 -0400 References: <1459858065-13348-1-git-send-email-alex@alex.org.uk> <5703CC16.1000002@redhat.com> <9A3BB330-4BFC-48AA-A129-89CB521A35FC@alex.org.uk> From: Paolo Bonzini Message-ID: <5703D83F.60708@redhat.com> Date: Tue, 5 Apr 2016 17:22:39 +0200 MIME-Version: 1.0 In-Reply-To: <9A3BB330-4BFC-48AA-A129-89CB521A35FC@alex.org.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCHv3] Improve the documentation of NBD_CMD_FLUSH and NBD_CMD_FLAG_FUA. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Bligh Cc: "nbd-general@lists.sourceforge.net" , Wouter Verhelst , "qemu-devel@nongnu.org" On 05/04/2016 17:16, Alex Bligh wrote: > > > * Document that sending FUA for commands that do nothing is permissible, but > > > 'SHOULD NOT' be done; an existing client does this. > > > > Can you send a pointer to the discussion? FUA on reads definitely does > > *something* in SCSI (it ensures that the data is moved out of the > > volatile cache prior to the read, similar to what QEMU implements). > > Sure. I got a solitary one reply that referenced the kernel, which > was copied to this list - see below. Ok, thanks. > I don't have strong feelings either way, but the safer option would > be to not REQUIRE the server to rely on any FUA read behaviour (I'm > already saying they should ignore the bit on reads). Qemu can't > currently RELY on FUA on reads, as it's not documented anywhere > and with the reference NBD server did nothing until recently; recently > it started errorring the read! See below. Right. However, bugs get fixed... Paolo > On that basis I chose to go with 'FUA on read does nothing'. > > If the kernel actually does something on read perhaps we should > reconsider.