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}