Re: [Nbd] NBD_CMD_RESIZE
- To: nbd-general@lists.sourceforge.net
- Subject: Re: [Nbd] NBD_CMD_RESIZE
- From: Wouter Verhelst <w@...112...>
- Date: Sat, 18 May 2013 10:51:22 +0200
- Message-id: <5197410A.5020304@...112...>
- In-reply-to: <CAECXXi6LtvDwiYvge16Xio7-jJn+D-OEV-YRwZV5S0-NK+P=Gg@...18...>
- References: <1368813979.6056.15.camel@...1343...> <CAECXXi6LtvDwiYvge16Xio7-jJn+D-OEV-YRwZV5S0-NK+P=Gg@...18...>
On 17-05-13 20:51, Paul Clements wrote:
> On Fri, May 17, 2013 at 2:06 PM, Nick Thomas <nick@...1342...
> <mailto:nick@...1342...>> wrote:
>
>
> I notice that Alex Bligh proposed the addition of NBD_CMD_RESIZE (along
> with some others) to the NBD protocol back in 2011:
>
> http://comments.gmane.org/gmane.linux.drivers.nbd.general/993
>
> I'm assuming this didn't go anywhere, at the time; would there be any
> interest in reviving the idea? I find myself wanting to implement
> block_resize in QEMU for NBD devices.
>
> One option is to stop the NBD server, resize the file, start NBD again,
> then run a peculiar version of block_resize that reconnects, reads the
> new size and advertises that to the guest;
>
> but NBD_CMD_RESIZE would be considerably simpler.
>
>
> Agreed.
>
> I'd be open to patches, if you have some. Doesn't appear it would take
> much in the kernel to get this functioning.
I guess it's going to take slightly more to get this functioning in
userspace, but I'd similarly be open to patches.
--
This end should point toward the ground if you want to go to space.
If it starts pointing toward space you are having a bad problem and you
will not go to space today.
-- http://xkcd.com/1133/
Reply to: