qemu-block
[Top][All Lists]
Advanced

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

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


From: Bob Chen
Subject: Re: [Qemu-block] [Nbd] [Qemu-devel] How to online resize qemu disk with nbd protocol?
Date: Sun, 22 Jan 2017 18:25:09 +0800

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.

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


reply via email to

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