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

[Wouter Verhelst]

On Sun, Jan 22, 2017 at 06:25:09PM +0800, Bob Chen wrote:
> Hi folks,
> 
> My time schedule doesn't allow me to wait for the community's solution, so I
> started to work on quick fix, which is to add a 'bdrv_truncate' function to 
> the
> current NBD's BlockDriver. Basically it's an 'active resize' implementation.

Fair enough.

If you're going to do that though, please add some negotiation before
trying to use the option, too. That way, other implementations can add
support for that option too, if they want

Having given this some more thought, I'm not entirely sure anymore that
an active resize from the NBD layer is necessarily a layering violation.
There might be other cases where this is useful, and e.g., the Linux
kernel also supports active resizes of block devices in some cases
(e.g., LVM). We'll also need to define what happens in case the resize
operation isn't possible for some reason (e.g., the size increase asks
for more space than the server's storage has available).

I suggest the following semantics:

- Add a transmission flag to indicate resize is possible for
  transmission phase (NBD_FLAG_SEND_RESIZE, flag 10). I don't see any
  need for an NBD_OPT_RESIZE or some such; just the flag should suffice.
- NBD_CMD_RESIZE (command 7): resize the export. The "offset" field
  contains the new size, "length" is reserved (why not the other way
  around? offset is 64 bits, length is 32)
- resize command can fail with:
  EPERM: server configuration does not allow this resize, or
  (optionally) other clients are using the same export and the request
  was for a smaller size.
  EIO: I/O error while trying to resize the device
  ENOSPC: new export size requires more space than is available
  ESHUTDOWN: server is shutting down

I've added an "extension-resize" branch with the above. If that works
for you, then run with it. If not, just implement what you want and send
updates as you go along.

> I also realized that the 'bdrv_truncate' caller stack is not in a coroutine,
> seemed to be the main thread? Then I tried some synchronous code as below:
> 
> int nbd_truncate(BlockDriverState *bs, int64_t offset)
> {
>     //...
>     nbd_client_detach_aio_context(bs);
>     qio_channel_set_blocking(client->ioc, true, NULL);
> 
>     ret = nbd_send_request(client->ioc, &request);            // step 1, send
> custom NBD_CMD_RESIZE request
>     ret = nbd_receive_reply(client->ioc, &reply);
> 
>     read_sync(client->ioc, &new_size, sizeof(new_size));     // step 2,
> expected to receive the confirmed new_size as data
>     new_size = be64_to_cpu(new_size);
> 
>     qio_channel_set_blocking(client->ioc, false, NULL);
>     nbd_client_attach_aio_context(bs, aio_context);
>     //...
> }
> 
> However at step 2, the 'new_size' I read is not always correct. Sometimes the
> bytes are repeating, for instance 1073741824 (1GB) became 1073741824073741824
> ...
> 
> Could you help me figure out what went wrong?
> 
> 
> Regards, 
> Bob
> 
> 2017-01-18 16:01 GMT+08:00 Wouter Verhelst <address@hidden>:
> 
>     On Mon, Jan 16, 2017 at 01:36:21PM -0600, Eric Blake wrote:
>     > 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.
> 
>     It's not necessarily a bad idea, which could also be used for:
>     - keepalive probes from server to client
>     - unsolicited ESHUTDOWN messages
> 
>     both of which are currently not possible and might be useful for the
>     protocol to have.
> 
>     --
>     < 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
> 
> 

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