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 <w...@uter.be>:
> 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
>
