All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Richard W.M. Jones" <rjones@redhat.com>
To: Nikolaus Rath <nikolaus@rath.org>
Cc: libguestfs@redhat.com, linux-block@vger.kernel.org,
	Josef Bacik <josef@toxicpanda.com>
Subject: Re: [Libguestfs] Communication issues between NBD driver and NBDKit server
Date: Sun, 15 May 2022 19:05:25 +0100	[thread overview]
Message-ID: <20220515180525.GF8021@redhat.com> (raw)
In-Reply-To: <04a0a06b-e6dc-48b7-bc29-105dab888a56@www.fastmail.com>

On Sun, May 15, 2022 at 04:45:11PM +0100, Nikolaus Rath wrote:
> Hi,
> 
> I am observing some strange errors when using the Kernel's NBD driver with
> NBDkit.
> 
> On the kernel side, I see:
> 
> May 15 16:16:11 vostro.rath.org kernel: nbd0: detected capacity change from 0
> to 104857600
> May 15 16:16:11 vostro.rath.org kernel: nbd1: detected capacity change from 0
> to 104857600
> May 15 16:18:23 vostro.rath.org kernel: block nbd0: Possible stuck request
> 00000000ae5feee7: control (write@4836316160,32768B). Runtime 30 seconds
> May 15 16:18:25 vostro.rath.org kernel: block nbd0: Possible stuck request
> 000000007094eddc: control (write@5372947456,10240B). Runtime 30 seconds
> May 15 16:18:27 vostro.rath.org kernel: block nbd0: Suspicious reply 89 (status
> 0 flags 0)
> May 15 16:18:31 vostro.rath.org kernel: block nbd0: Possible stuck request
> 0000000075f8b9bc: control (write@8057764864,32768B). Runtime 30 seconds
> May 15 16:18:41 vostro.rath.org kernel: block nbd0: Possible stuck request
> 000000002d1b3e8b: control (write@14499979264,32768B). Runtime 30 seconds
> [...]

Does it really take over 30 seconds for nbdkit to respond?  You might
want to insert some debugging into the S3 plugin to see what stage of
the request cycle is taking so long, although I'm going to guess it's
the remote Amazon server itself.

It seems like you can adjust this timeout using the nbd-client -t flag
(it calls ioctl(NBD_SET_TIMEOUT) in the kernel).  If I understand the
logic correctly, the nbd timeout is currently set to 0, which causes
the default socket timeout to be used.  Using the -t flag overrides this.
So I guess try setting it larger and see if the problem goes away.

Rich.

> And userspace ('zfs snapshot" in this instance) is stuck afterwards.
> 
> On the NBDkit side, there seemingly are write errors when replying back to the
> kernel:
> 
> $ nbdkit --unix /tmp/tmpi5o59_y_/nbd_socket_sb --foreground --filter=exitlast
> --filter=stats --threads 16 S3 size=50G bucket=nikratio-backup key=sb statsfile
> =/tmp/tmpi5o59_y_/stats_sb.txt object-size=32K &
> $ nbd-client -unix /tmp/tmpi5o59_y_/nbd_socket_sb /dev/nbd2
> Warning: the oldstyle protocol is no longer supported.
> This method now uses the newstyle protocol with a default export
> Negotiation: ..size = 51200MB
> Connected /dev/nbd0
> [....]
> nbdkit: python.10: error: write reply: NBD_CMD_WRITE: Broken pipe
> 
> 
> What's the best way to narrow down who's the culprit here (kernel vs NBD
> server)?
> 
> Best,
> -Nikolaus
> 
> --
> GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
> 
>              »Time flies like an arrow, fruit flies like a Banana.«
> 
> 

> _______________________________________________
> Libguestfs mailing list
> Libguestfs@redhat.com
> https://listman.redhat.com/mailman/listinfo/libguestfs


-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org


  parent reply	other threads:[~2022-05-15 18:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <04a0a06b-e6dc-48b7-bc29-105dab888a56@www.fastmail.com>
2022-05-15 15:51 ` Communication issues between NBD driver and NBDKit server Josef Bacik
2022-05-15 16:39   ` Nikolaus Rath
2022-05-15 18:05 ` Richard W.M. Jones [this message]
2022-05-15 19:12   ` [Libguestfs] " Nikolaus Rath
2022-05-15 19:25     ` Richard W.M. Jones
2022-05-16  1:08       ` yukuai (C)
2022-05-17 21:16         ` Nikolaus Rath

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220515180525.GF8021@redhat.com \
    --to=rjones@redhat.com \
    --cc=josef@toxicpanda.com \
    --cc=libguestfs@redhat.com \
    --cc=linux-block@vger.kernel.org \
    --cc=nikolaus@rath.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.