Hi, and sorry for the delay (I was overseas for a month in May to
visit family
etc)
On Tue, May 03, 2022 at 09:07:17AM +0100, Richard W.M. Jones wrote:
> On Mon, May 02, 2022 at 03:36:33PM +0100, Nikolaus Rath wrote:
> > So I tried to reproduce this, and noticed something odd. It seems I can
> > disconnect the nbd device (nbd-client -d) while there are still requests
> > in flight:
> >
> > May 02 15:20:50
vostro.rath.org kernel: nbd1: detected capacity change from 0
to 52428800
> > May 02 15:20:50
vostro.rath.org kernel: block nbd1: NBD_DISCONNECT
> > May 02 15:20:50
vostro.rath.org kernel: block nbd1: Disconnected due to user
request.
> > May 02 15:20:50
vostro.rath.org kernel: block nbd1: shutting down sockets
> > May 02 15:20:50
vostro.rath.org kernel: I/O error, dev nbd1, sector 776 op
0x0:(READ) flags 0x80700 phys_seg 29 prio class 0
> > May 02 15:20:50
vostro.rath.org kernel: I/O error, dev nbd1, sector 776 op
0x0:(READ) flags 0x0 phys_seg 1 prio class 0
> > May 02 15:20:50
vostro.rath.org kernel: Buffer I/O error on dev nbd1, logical
block 97, async page read
> > May 02 15:20:50
vostro.rath.org kernel: block nbd1: Attempted send on invalid
socket
> > May 02 15:20:50
vostro.rath.org kernel: I/O error, dev nbd1, sector 0 op
0x1:(WRITE) flags 0x800 phys_seg 0 prio class 0
> > May 02 15:20:50
vostro.rath.org kernel: block nbd1: Attempted send on invalid
socket
> > May 02 15:20:50
vostro.rath.org kernel: I/O error, dev nbd1, sector 0 op
0x1:(WRITE) flags 0x800 phys_seg 0 prio class 0
> >
> > This was generated by running:
> >
> > $ nbd-client localhost /dev/nbd1 && mkfs.ext4 /dev/nbd1 &&
nbd-client -d
> > /dev/nbd1
> >
> > Is that expected behavior?
>
> It's a bit unexpected to me. Adding Wouter to the thread - he might
> have an idea here, especially if there's a way to have "nbd-client
-d"
> wait for pending requests to finish before disconnecting.
>
> I don't use the kernel client very much myself. We mostly use either
> libnbd or the qemu client.
The kernel is supposed to deal with this. If there are still processes
using the device and/or, nbd-client -d should receive an error (I believe it
was EPERM). If there are outstanding writes, the disconnect should flush
those, wait for them to return, and *then* handle the disconnect.
At least those are the assumptions made in nbd-client ;-)
(I notice you did send this to the kernel maintainer too, but just
wanted to follow up on what nbd-client assumes)
--
w(a)uter.{be,co.za}
wouter(a){grep.be,fosdem.org,debian.org}