From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37529) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1annW8-0004p5-Fc for qemu-devel@nongnu.org; Wed, 06 Apr 2016 09:29:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1annW4-0000m5-Eq for qemu-devel@nongnu.org; Wed, 06 Apr 2016 09:29:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42911) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1annW4-0000m1-9I for qemu-devel@nongnu.org; Wed, 06 Apr 2016 09:29:04 -0400 References: <56FD7B7E.4060004@redhat.com> <64B326DA-CDF4-4537-B38A-46E7B57C319C@alex.org.uk> <56FD8069.7020101@redhat.com> <56FE26B2.6090903@redhat.com> <20160405050926.GC4183@noname.redhat.com> <5703BD8F.1080409@redhat.com> <20160406131448.GH5098@noname.redhat.com> From: Paolo Bonzini Message-ID: <57050F1A.9070604@redhat.com> Date: Wed, 6 Apr 2016 15:28:58 +0200 MIME-Version: 1.0 In-Reply-To: <20160406131448.GH5098@noname.redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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: Kevin Wolf Cc: "nbd-general@lists.sourceforge.net" , "qemu-devel@nongnu.org" , Alex Bligh On 06/04/2016 15:14, Kevin Wolf wrote: >>> > >=20 >>> > > 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. >> >=20 >> > 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. Paolo