Re: [Qemu-devel] [Nbd] [Qemu-block] How to online resize qemu disk with nbd protocol?

[Wouter Verhelst <w@uter.be>]

Hi Eric,

(side note: my mutt tells me that the signature on your message does not
validate. Not sure what's going on, but something you might want to look
into...)

On Thu, Jan 12, 2017 at 12:45:56PM -0600, Eric Blake wrote:
> For resize smaller, things are a lot trickier - how do you block access
> to a portion of a file that the client still thinks exist, but which the
> server has truncated away?  Maybe the easy way out is to state that the
> server MUST NOT resize smaller.

I would prefer something along the lines of "the server MUST NOT
activate the 'resize smaller' command (which it received out of band
from whereever) until the client asked for and was told the new size of
the device."

That is (with A & X being offsets, and B & Y being sizes, A+B < X):

client        			server			server mgmt
READ A,B        		no error
        						resize to X
READ X,Y        		no error
reread sizes
READ X,Y        		ENOSPC
READ A,B        		no error

In that scenario, it should be the responsibility of the server to
ensure there are no more readers; servers could implement that (if they
don't want to do the required bookkeeping and keep such requests as
pending) by simply sending ESHUTDOWN or some such.

> > What about an active `resize` request from the client? Considering some NBD
> > servers might have the capability to do instant resizing, not applying to
> > LVM or host block device, of course...
> 
> And perhaps the 're-read size' command can serve a dual purpose.  Since
> all NBD commands already include space for size and offset parameters,
> we could define that if the client passes 0/0 for size and offset, it
> wants to read the server's current size; if it passes 0/non-zero, it is
> asking the server to resize to the new non-zero size (and the server's
> success or error response tells whether the resize happened).

I agree with Alex that adding an active resize command to the NBD
protocol feels like a layering violation. We should probably not do
that.

> Should I spend time turning this idea into a more formal spec, along the
> lines of other NBD extension proposals?

Feel free.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12