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

[Eric Blake]

On 01/14/2017 08:45 AM, Wouter Verhelst wrote:
> 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...)

Not my fault, but a well-known issue with mailman. It rewrites portions
of message bodies that look like headers, yet GPG signatures
intentionally include a portion of the body that includes a repeat of
the original headers in order to authenticate the original sender. Thus,
the rewritten message no longer has a valid signature :(

In the past I've compared a broken and pristine copy of my messages, and
it's fairly annoying that the difference is sometimes as subtle as a
space vs. a tab, due to the way the header line was rewritten.


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

In other words, a resize-smaller request (outside of the NBD protocol)
can either force the server to tell the clients to disconnect, or else
is merely a hint that is at the mercy of the client actually being smart
enough to request the information.  I don't know how we'd specify that,
but the idea seems reasonable enough.

The sad part is that the NBD protocol (currently) lacks any way for the
server to send an unsolicited hint to the client.  I've seen other
protocols (such as libvirt) that include a hint mechanism; intentionally
designed where a client that ignores the hints is no worse for the wear,
but where the hints can allow the server to pass information to the
client faster than what is possible if the client never asks the right
question.

Maybe the structured reply proposal can be extended into this (reserve a
"reply" header that can be issued as many times as desired by the server
without the client ever having issued the request first, and where the
reply never uses the end-of-reply marker), but I'm not sure I want to go
that direction just yet.

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

Fair enough; for now it will just be a passive re-query command.

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

I'll see what I can come up with in the next day or so, at least into an
RFC-quality spec change.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature