From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55336) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bnq4A-0005gi-Pb for qemu-devel@nongnu.org; Sat, 24 Sep 2016 12:44:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bnq45-0000jw-Uh for qemu-devel@nongnu.org; Sat, 24 Sep 2016 12:44:42 -0400 References: <57E5752C.3080407@virtuozzo.com> <20160923212126.vo3hvb4hxojjh7s4@grep.be> <57E66C60.8040102@virtuozzo.com> <57E682AC.8070704@virtuozzo.com> <57E6A7D4.4040000@virtuozzo.com> From: Vladimir Sementsov-Ogievskiy Message-ID: <57E6AD6C.9020107@virtuozzo.com> Date: Sat, 24 Sep 2016 19:44:28 +0300 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] write_zeroes/trim on the whole disk List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Bligh Cc: Wouter Verhelst , Eric Blake , "qemu-devel@nongnu.org" , qemu-block@nongnu.org, "nbd-general@lists.sourceforge.net" , Kevin Wolf , "Denis V. Lunev" , Paolo Bonzini , "Stefan stefanha@redhat. com" On 24.09.2016 19:35, Alex Bligh wrote: >> On 24 Sep 2016, at 17:20, Vladimir Sementsov-Ogievskiy wrote: >> >> Also, accordingly to documentation, NBD_CMD_TRIM is not appropriate for disk clearing: >> >> * `NBD_CMD_TRIM` (4) >> >> A hint to the server that the data defined by len and offset is no >> longer needed. A server MAY discard len bytes starting at offset, but >> is not required to. >> >> After issuing this command, a client MUST NOT make any assumptions >> about the contents of the export affected by this command, until >> overwriting it again with `NBD_CMD_WRITE`. >> >> - it may do nothing.. So, what to do with this? add flag FORCE_TRIM for this command? Or add FORCE_HOLES flag to WRITE_ZEROES? > You cannot force a hole, because NBD the is not guaranteed to support holes. > > Use NBD_CMD_WRITE_ZEROES without NBD_CMD_FLAG_NO_HOLE and you can pretty much assume that a server that supports holes will write holes. A server that does not support holes will write zeroes. If you don't care whether the resultant data is zero, just use NBD_CMD_TRIM. But as you do care (see above) you must be prepared for a 'thick' write of zeroes on servers that don't support it. > No, holes are critical. Concreate case: incremental backup to delta file. If we write zeroes instead of holes, we will lose underlying data (from previous incremental). -- Best regards, Vladimir