[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eric Blake
Subject: Re: [Qemu-devel] [Qemu-block] [Nbd] How to online resize qemu disk with nbd protocol?
Date: Thu, 12 Jan 2017 12:45:56 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0

On 01/12/2017 11:57 AM, Bob Chen wrote:
> There might be a time window between the NBD server's resize and the
> client's `re-read size` request. Is it safe?

For resize larger, it seems that it would be safe for the server to just
remember the last size it has advertised to the client.  As long as the
client doesn't request read/write to any offset beyond the
last-advertised size (either the size the server gave at handshake, or
the size that the server reported when the client last used the new
're-read size' command), there's no difference in behavior (and
well-behaved clients fall in this group); if the client DOES try to
access out-of-bounds with respect to the last known size, the server
SHOULD reject the access, but MAY serve it instead.  A client that is
unaware of the 're-read size' command will never learn that the server
is now offering a larger image.

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.

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

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

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

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]