From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47191) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bntcz-0005Ac-Su for qemu-devel@nongnu.org; Sat, 24 Sep 2016 16:32:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bntcy-0005Bh-Uy for qemu-devel@nongnu.org; Sat, 24 Sep 2016 16:32:53 -0400 References: <57E5752C.3080407@virtuozzo.com> <20160923212126.vo3hvb4hxojjh7s4@grep.be> <57E66C60.8040102@virtuozzo.com> <57E6ACDD.7080205@virtuozzo.com> <57E6B423.6010007@virtuozzo.com> <57E6B8CF.6040406@virtuozzo.com> <57E6DEA0.7050002@gmx.net> From: Vladimir Sementsov-Ogievskiy Message-ID: <57E6E2E2.9000509@virtuozzo.com> Date: Sat, 24 Sep 2016 23:32:34 +0300 MIME-Version: 1.0 In-Reply-To: <57E6DEA0.7050002@gmx.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Nbd] write_zeroes/trim on the whole disk List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Carl-Daniel Hailfinger , Alex Bligh Cc: "nbd-general@lists.sourceforge.net" , Kevin Wolf , qemu block , "qemu-devel@nongnu.org" , Paolo Bonzini , "Stefan stefanha@redhat. com" , "Denis V. Lunev" , Wouter Verhelst On 24.09.2016 23:14, Carl-Daniel Hailfinger wrote: > On 24.09.2016 19:33, Vladimir Sementsov-Ogievskiy wrote: >> On 24.09.2016 20:13, Vladimir Sementsov-Ogievskiy wrote: >>> I agree that requests larger than disk size are ugly.. But splitting >>> request brings me again to idea of having separate command or flag >>> for clearing the whole disk without that dance. Server may report >>> availability of this/flag command only if target driver supports fast >>> write_zeroes (qcow2 in our case). >> Also, such flag may be used to satisfy all needs: >> >> flag BIG_REQUEST is set and length = 0 -> request on the whole >> disk, offset must be 0 >> flag BIG_REQUEST is set and length > 0 -> request on >> (offset*block_size, length*block_size), length*block_size must be <= >> disk_size > What happens if length*block_size<=disk_size, but > offset*block_size+length*block_size>disk_size? Wraparound? Personally, for me main scenario for is length=0, to clear the whole disk. In general allowing requests larger than disk size may not be very good idea.. Also: On 24.09.2016 19:49, Alex Bligh wrote: >> >May be, additional option, specifying the shift would be better. With convention that if offset+length exceeds disk size, length should be recalculated as disk_size-offset. > I don't think we should do that. We already have clear semantics that prevent operations beyond the end of the disk. Again, just break the command up into multipl commands. No great hardship. So, most possible answer on your question: it should be an error. > > Regards, > Carl-Daniel -- Best regards, Vladimir