> On 13 Dec 2016, at 12:18, Wouter Verhelst <w...@uter.be> wrote: > > I'm not opposed either, but I do agree with you that we shouldn't add > such a feature if it doesn't end up getting used. Especially so if it > burns a flag in the (16-bit) "transmission flags" field, where space is > at a premium.
I did suggest a few non-Qemu uses (see below). I think it might be an idea if the reference implementation supported it before merging (which per below should be trivial). -- Alex Bligh > Begin forwarded message: > > From: Alex Bligh <a...@alex.org.uk> > Subject: Re: [Nbd] [Qemu-block] [PATCH] doc: Propose NBD_FLAG_INIT_ZEROES > extension > Date: 6 December 2016 at 10:29:41 United Kingdom Time > To: Kevin Wolf <kw...@redhat.com> > Cc: Alex Bligh <a...@alex.org.uk>, Eric Blake <ebl...@redhat.com>, > "nbd-gene...@lists.sourceforge.net" <nbd-gene...@lists.sourceforge.net>, > xieying...@huawei.com, su...@huawei.com, qemu block <qemu-block@nongnu.org>, > "qemu-de...@nongnu.org" <qemu-de...@nongnu.org>, Paolo Bonzini > <pbonz...@redhat.com> > > >> On 6 Dec 2016, at 09:25, Kevin Wolf <kw...@redhat.com> wrote: >> >> Am 06.12.2016 um 00:42 hat Eric Blake geschrieben: >>> While not directly related to NBD_CMD_WRITE_ZEROES, the qemu >>> team discovered that it is useful if a server can advertise >>> whether an export is in a known-all-zeroes state at the time >>> the client connects. >> >> Does a server usually have the information to set this flag, other than >> querying the block status of all blocks at startup? > > The server may have other ways of knowing this, for instance > that it has just created the file (*), or that it stat'd the file > before opening it (not unlikely) and noticed it had 0 allocated > size. The latter I suspect would be trivial to implement in nbd-server > > (*) = e.g. I had one application where nbd use the export path > to signify it wanted to open a temporary file, the path consisting > of a UUID and an encoded length. If the file was not present already > it created it with ftruncate(). That could trivially have used this. > >> If so, the client could just query this by itself. > > Well there's no currently mainlined extension to do that, but yes > it could. On the other hand I see no issue passing complete > zero status back to the client if it's so obvious from a stat(). > > -- > Alex Bligh > > > >
