From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58581) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWK2V-0000nY-2E for qemu-devel@nongnu.org; Thu, 18 Feb 2016 03:34:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aWK2R-0005nq-TB for qemu-devel@nongnu.org; Thu, 18 Feb 2016 03:34:19 -0500 Received: from mx2.parallels.com ([199.115.105.18]:40366) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aWK2R-0005nm-Mv for qemu-devel@nongnu.org; Thu, 18 Feb 2016 03:34:15 -0500 References: <1455732653-3106-1-git-send-email-den@openvz.org> <00466EEA-174D-40E5-B74F-974D11DBB97C@alex.org.uk> From: "Denis V. Lunev" Message-ID: <56C581FC.6020603@openvz.org> Date: Thu, 18 Feb 2016 11:34:04 +0300 MIME-Version: 1.0 In-Reply-To: <00466EEA-174D-40E5-B74F-974D11DBB97C@alex.org.uk> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC 1/1] nbd (specification): add NBD_CMD_WRITE_ZEROES command List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Bligh Cc: "nbd-general@lists.sourceforge.net" , "qemu-devel@nongnu.org" 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; - 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. The difference comes from the situation when sparse files results in a serious performance impact if written by small pieces. In this case the data of one block of the virtual disk can be placed to very different blocks of the physical disk seriously impacting subsequent sequential reading. Thus I propose to make the situation distinct for these commands. Though you proposal to add NBD_FLAG_SEND_TRIM_ZEROED to export flags is also great. Though this IMHO is a different story. Den