[reviving an old thread] On 01/23/2017 08:54 AM, Eric Blake wrote:
> I'm still thinking that allowing the client to query the current size is > useful. Over the weekend, I was thinking of SEEK_SET/SEEK_END semantics > (SEEK_CUR doesn't really make sense, since we don't maintain a current > offset), and wondering if we could improve the command as follows: > > If invoked without flags, it operates with SEEK_SET semantics (the > offset is the new requested size); if invoked with > NBD_CMD_FLAG_RELATIVE, it operates with SEEK_END semantics (the offset > is added to the existing size, and can be treated as a signed 64-bit > negative number to shrink). Either way, on success, the command replies > with a structured reply containing the new 64-bit total size of the > disk. This would require the reply to be a structured reply, and the > semantics of NBD_CMD_FLAG_RELATIVE with an offset of 0 becomes a way to > probe the existing disk size (thus enabling the server to resize without > client request, and perhaps used with some out-of-band means for the > client to know that it should query the server for an updated size). > Also note that the server's reply of the current size may be slightly > different than what was requested by the client (that is, we should > allow the server to round the client's request up to an appropriate > granularity) - we should probably require that the server can only round > up (not down). > > Thoughts? Another thought - with structured replies, we finally have a way to let the client ask for the server to send resize information whenever the server wants, rather than having to be polled by a new client request all the time. This is possible by having the server reply with a chunk without the NBD_REPLY_FLAG_DONE bit, for as many times as it wants, (that is, the server never officially ends the response to the single client request for on-going status, until the client sends an NBD_CMD_DISC). I don't think the server should go into this mode without a flag bit from the client requesting it (as it potentially ties up a thread that could otherwise be used for parallel processing of other requests), and that the server could reject a repeat command with the flag if it is already serving a previous open-ended request. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature