> On 13 Dec 2016, at 12:18, Wouter Verhelst <[email protected]> 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 <[email protected]> > 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 <[email protected]> > Cc: Alex Bligh <[email protected]>, Eric Blake <[email protected]>, > "[email protected]" <[email protected]>, > [email protected], [email protected], qemu block <[email protected]>, > "[email protected]" <[email protected]>, Paolo Bonzini > <[email protected]> > > >> On 6 Dec 2016, at 09:25, Kevin Wolf <[email protected]> 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 > > > >
