Re: [Qemu-devel] [Nbd] [RFC 1/1] nbd (specification): add NBD_CMD_WRITE_ZEROES command

From: "Denis V. Lunev" <den@openvz.org>
To: Wouter Verhelst <w@uter.be>, Paolo Bonzini <pbonzini@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
	"nbd-general@lists.sourceforge.net"
	<nbd-general@lists.sourceforge.net>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [Nbd] [RFC 1/1] nbd (specification): add NBD_CMD_WRITE_ZEROES command
Date: Sun, 6 Mar 2016 21:54:29 +0300	[thread overview]
Message-ID: <56DC7CE5.6080503@openvz.org> (raw)
In-Reply-To: <20160306102830.GB13207@grep.be>

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