From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52812) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1acdpQ-0000vY-7u for qemu-devel@nongnu.org; Sun, 06 Mar 2016 13:54:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1acdpN-00057S-1N for qemu-devel@nongnu.org; Sun, 06 Mar 2016 13:54:56 -0500 Received: from mx2.parallels.com ([199.115.105.18]:53844) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1acdpM-00057I-Rp for qemu-devel@nongnu.org; Sun, 06 Mar 2016 13:54:52 -0500 References: <1455732653-3106-1-git-send-email-den@openvz.org> <00466EEA-174D-40E5-B74F-974D11DBB97C@alex.org.uk> <56C581FC.6020603@openvz.org> <20160304084911.GA5955@grep.be> <20160304095413.GC4366@noname.redhat.com> <56D995AE.1080805@redhat.com> <20160306102830.GB13207@grep.be> From: "Denis V. Lunev" Message-ID: <56DC7CE5.6080503@openvz.org> Date: Sun, 6 Mar 2016 21:54:29 +0300 MIME-Version: 1.0 In-Reply-To: <20160306102830.GB13207@grep.be> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Nbd] [RFC 1/1] nbd (specification): add NBD_CMD_WRITE_ZEROES command List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wouter Verhelst , Paolo Bonzini Cc: Kevin Wolf , "nbd-general@lists.sourceforge.net" , "qemu-devel@nongnu.org" On 03/06/2016 01:28 PM, Wouter Verhelst wrote: > Hi all, > > On Fri, Mar 04, 2016 at 03:03:26PM +0100, Paolo Bonzini wrote: >> NBD-wise, I think the TRIM command is good as it is, and >> NBD_CMD_WRITE_ZEROES should be added like Den is doing. >> >> It also makes sense to use trimming to implement NBD_CMD_WRITE_ZEROES, >> but it should be explicitly requested by the user. For this, my >> suggestion is that NBD_CMD_WRITE_ZEROES should have an >> NBD_FLAG_TRY_TRIM flag in bit 16. If specified, the backend can use a >> zero-writing mechanism that trims, _but_ it must ensure that the bytes >> read as zero. If it cannot ensure that, it must not trim and it >> should instead do a full write. This is similar to the SCSI command >> WRITE SAME (when the command payload is all zeroes). Like Kevin said, >> it also happens to map nicely to the QEMU block device layer. > That seems like a sensible approach, yes. > > Would one of you who feels strongly about this be willing to write up a > proposed spec for that? I could do it, but since I'm not 100% sure I > understand all the specific requirements, I'm uncomfortable doing so. > > If that doesn't raise any obvious issues that I'm aware of, I'd be happy > to add it to the "experimental" section of the proto.md file. > > (speaking of which, I notice that the STARTTLS patches got merged into > qemu, so I've moved the description of that to the main body and out of > the "experimental" part of that document) > I am going to send next RFC next Wednesday. Just waited other opinions not from QEMU side. Den