Libguestfs - Jun 2022 - nbdkit error: "write reply: NBD_CMD_WRITE: Broken pipe"

Same story.

On Fri, Jun 17, 2022 at 01:09:25PM +0200, Wouter Verhelst
wrote:
> 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 at uter.{be,co.za}
> wouter@{grep.be,fosdem.org,debian.org}
-- 
     w at uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}