From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54663) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ablQY-0001oq-PI for qemu-devel@nongnu.org; Fri, 04 Mar 2016 03:49:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ablQV-0007Mx-GB for qemu-devel@nongnu.org; Fri, 04 Mar 2016 03:49:38 -0500 Received: from barbershop.grep.be ([89.106.240.122]:39869) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ablQV-0007MA-4t for qemu-devel@nongnu.org; Fri, 04 Mar 2016 03:49:35 -0500 Date: Fri, 4 Mar 2016 09:49:11 +0100 From: Wouter Verhelst Message-ID: <20160304084911.GA5955@grep.be> References: <1455732653-3106-1-git-send-email-den@openvz.org> <00466EEA-174D-40E5-B74F-974D11DBB97C@alex.org.uk> <56C581FC.6020603@openvz.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56C581FC.6020603@openvz.org> 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: "Denis V. Lunev" Cc: "nbd-general@lists.sourceforge.net" , "qemu-devel@nongnu.org" , Alex Bligh Hi folks, (sorry about the lateness of this reply, was busy for the last few weeks) On Thu, Feb 18, 2016 at 11:34:04AM +0300, Denis V. Lunev wrote: > On 02/18/2016 11:09 AM, Alex Bligh wrote: > > On 17 Feb 2016, at 18:10, Denis V. Lunev wrote: > > > >> Currently available NBD_CMD_TRIM command can not be used as the > >> specification explicitely says that "a client MUST NOT make any > >> assumptions about the contents of the export affected by this > >> [NBD_CMD_TRIM] command, until overwriting it again with `NBD_CMD_WRITE`" > > Would a flag to NBD_CMD_TRIM that says "ensure the written > > data is zeroed" not be an easier solution than adding another > > very similar command? > > > > Or (cough) changing the spec? > > > from the point of the receiver the situation (from my POW) could > be different. Let us assume that we are writing to the plain > file. > > There are 2 type of queries: > - pls make the target sparse, i.e. perform FALLOC_FL_PUNCH_HOLE > and there is no problem that the operation could not be performed, > this is a hint; This is what NBD_CMD_TRIM does, currently. The reason this is a hint, is that there is no guarantee that the underlying operating system or storage even supports FALLOC_FL_PUNCH_HOLE (or similar). We could have made NBD_CMD_TRIM fail with a "not possible on this export" kind of error in that case, but it was chosen not to do that (for reasons I don't remember; maybe we just didn't consider this enough). This could be remedied if the client could somehow ask what the result of a TRIM command would be; i.e., if the server has support for FALLOC_FL_PUNCH_HOLE, it could set a flag which would let the client know that NBD_CMD_TRIM will zero out bytes. If the server doesn't set that flag and the client requires zeroes, it could then just issue a WRITE command, followed (maybe) by a TRIM for the same region (which would be less optimal, but have the same result with older servers) > - pls write the following amount of zeroes in either way (even calling > write directly), i.e. ensure that the data is zeroed and the space on > the file system is allocated for that. IOW, you *don't* want to have a sparse file in that case? Or do I misunderstand things here? I'm not entirely sure I understand the problem here... -- < ron> I mean, the main *practical* problem with C++, is there's like a dozen people in the world who think they really understand all of its rules, and pretty much all of them are just lying to themselves too. -- #debian-devel, OFTC, 2016-02-12