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

[Alex Bligh]

> On 14 Jan 2017, at 14:48, Wouter Verhelst  wrote:
> 
> On Thu, Jan 12, 2017 at 06:56:42PM +, Alex Bligh wrote:
>> My preferred way to do this would be essentially to allow NBD_OPT_INFO
>> to be sent (wrapped appropriately) during the main transmission phase.
>> That would allow *any* INFO stuff to be reread.
> 
> Can you go into a bit more detail how you'd see that? It feels a bit
> awkward to me, at best; but I could be missing something.

Well, the idea would be something like: NBD_CMD_INFO, use the offset
specified as the the information type, and put the INFO reply
within the reply block. I guess the client doesn't know the
length of the reply so we'd have to use structured replies
or similar. Although looking through the current info types,
I can't see why today you'd want to reread anything other than
the length, so maybe this is useless futureproofing.

-- 
Alex Bligh

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

[Wouter Verhelst]

On Thu, Jan 12, 2017 at 06:56:42PM +, Alex Bligh wrote:
> My preferred way to do this would be essentially to allow NBD_OPT_INFO
> to be sent (wrapped appropriately) during the main transmission phase.
> That would allow *any* INFO stuff to be reread.

Can you go into a bit more detail how you'd see that? It feels a bit
awkward to me, at best; but I could be missing something.

-- 
< 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

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

[Wouter Verhelst]

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,Bno error
resize to X
READ X,Yno error
reread sizes
READ X,YENOSPC
READ A,Bno 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