rbd-nbd: update size only when NBD_SET_SIZE successful

[liupan1111]

Signed-off-by: Pan Liu liupan1111@gmail.com

[liupan1111]

@trociny Please help take a look.

[dmick]

My fault the submodule test failed, ignore

[trociny]

@liupan1111 Actually I am not sure this makes things better (or different). For this I would need to know real cases when ioctl may fail. I suppose the only difference after your change, that it will try ioctl again when the next notification (that does not change size) comes. But I suppose ioctl will fail again.

Not sure what would be the best in this case. May be nbd process shut down, or switch to RO mode, or all subsequent nbd requests returning error? @dillaman do you have any opinion?

[dillaman]

@trociny IMHO, I don't see anything wrong with the change but also probably provides little value. If the nbd resize failed and the client writes to an extent outside the new image size, the IO will fail -- and in the case where the image size was increased, the client just won't have access to the new space. @liupan1111 did you actually see this ioctl fail before? [1]

[1] https://github.com/torvalds/linux/blob/master/drivers/block/nbd.c#L779

[liupan1111]

@dillaman and @trociny I haven't see this IOCtl failed actually. But the logic of change size was not reasonable to me, so I change it. I want to confirm very logic correctly before there is really an possible error happen after it is online.

[trociny]

LGTM

[liupan1111]

@dillaman @trociny talking about NBD and librbd, I met an issue: if we are writing one nbd device, and manually killed a rbd-nbd process, there will be linux panic sometimes ... Do you have any idea to resolve this?

[trociny]

if we are writing one nbd device, and manually killed a rbd-nbd process, there will be linux panic sometimes ... Do you have any idea to resolve this?

I think this is the kernel/nbd driver problem. They should properly handle this.

[trociny]

I think this is the kernel/nbd driver problem. They should properly handle this.

I mean, in general, it is certainly the kernel problem: any misbehaviour of a user-space process should be handled.

But I think we can improve rbd-nbd for case when it is killed with SIGINT or SIGTERM (have you observed the panic when killing with the default signal?). We can register a signal handler. See rbd-mirror as an example (start from main.cc, register_async_signal_handler).

[liupan1111]

@trociny, yes, for SIGINT or SIGTERM, we could register handler, but it is a ideal case. If rbd-nbd crashed for some exceptional reason: out of memory, program bugs, ... how does user space handle this?

[trociny]

If a process crashes due to out of memory or program bug its state is not consistent. E.g. you can't be sure that a memory region that contain an object you are trying to access is valid. In this case the best thing the program can do is to die. The ceph programs have a handler that tries to log the backtrace, usually it succeeds when the inconsistency was detected internally (assert failed).

[liupan1111]

@trociny , i agree, i would like to implement it and let u review.