From: "Richard W.M. Jones" <rjones@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Cc: kwolf@redhat.com, eblake@redhat.com, qemu-devel@nongnu.org,
qemu-block@nongnu.org
Subject: Re: [PATCH v2] nbd/server: Suppress Broken pipe errors on abrupt disconnection
Date: Tue, 14 Sep 2021 15:52:00 +0100 [thread overview]
Message-ID: <20210914145200.GJ26415@redhat.com> (raw)
In-Reply-To: <6c59b070-b9b4-6ecb-8557-3ea54af3d45a@virtuozzo.com>
On Tue, Sep 14, 2021 at 05:40:59PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> 13.09.2021 18:19, Richard W.M. Jones wrote:
> >$ rm -f /tmp/sock /tmp/pid
> >$ qemu-img create -f qcow2 /tmp/disk.qcow2 1M
> >$ qemu-nbd -t --format=qcow2 --socket=/tmp/sock --pid-file=/tmp/pid /tmp/disk.qcow2 &
> >$ nbdsh -u 'nbd+unix:///?socket=/tmp/sock' -c 'h.get_size()'
> >qemu-nbd: Disconnect client, due to: Failed to send reply: Unable to write to socket: Broken pipe
> >$ killall qemu-nbd
> >
> >nbdsh is abruptly dropping the NBD connection here which is a valid
> >way to close the connection. It seems unnecessary to print an error
> >in this case so this commit suppresses it.
> >
> >Note that if you call the nbdsh h.shutdown() method then the message
> >was not printed:
> >
> >$ nbdsh -u 'nbd+unix:///?socket=/tmp/sock' -c 'h.get_size()' -c 'h.shutdown()'
>
> My personal opinion, is that this warning doesn't hurt in general. I
> think in production tools should gracefully shutdown any connection,
> and abrupt shutdown is a sign of something wrong - i.e., worth
> warning.
>
> Shouldn't nbdsh do graceful shutdown by default?
On the client side the only difference is that nbd_shutdown sends
NBD_CMD_DISC to the server (versus simply closing the socket). On the
server side when the server receives NBD_CMD_DISC it must complete any
in-flight requests, but there's no requirement for the server to
commit anything to disk. IOW you can still lose data even though you
took the time to disconnect.
So I don't think there's any reason for libnbd to always gracefully
shut down (especially in this case where there are no in-flight
requests), and anyway it would break ABI to make that change and slow
down the client in cases when there's nothing to clean up.
> >Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
> >---
> > nbd/server.c | 7 ++++++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> >diff --git a/nbd/server.c b/nbd/server.c
> >index 3927f7789d..e0a43802b2 100644
> >--- a/nbd/server.c
> >+++ b/nbd/server.c
> >@@ -2669,7 +2669,12 @@ static coroutine_fn void nbd_trip(void *opaque)
> > ret = nbd_handle_request(client, &request, req->data, &local_err);
> > }
> > if (ret < 0) {
> >- error_prepend(&local_err, "Failed to send reply: ");
> >+ if (errno != EPIPE) {
>
> Both nbd_handle_request() and nbd_send_generic_reply() declares that
> they return -errno on failure in communication with client. I think,
> you should use ret here: if (ret != -EPIPE). It's safer: who knows,
> does errno really set on all error paths of called functions? If
> not, we may see here errno of some another previous operation.
Should we set errno = 0 earlier in nbd_trip()? I don't really know
how coroutines in qemu interact with thread-local variables though.
Rich.
> >+ error_prepend(&local_err, "Failed to send reply: ");
> >+ } else {
> >+ error_free(local_err);
> >+ local_err = NULL;
> >+ }
> > goto disconnect;
> > }
> >
>
>
> --
> Best regards,
> Vladimir
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
next prev parent reply other threads:[~2021-09-14 15:36 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-13 15:19 [PATCH v2] nbd/server: Suppress Broken pipe errors on abrupt disconnection Richard W.M. Jones
2021-09-14 14:40 ` Vladimir Sementsov-Ogievskiy
2021-09-14 14:52 ` Richard W.M. Jones [this message]
2021-09-14 15:21 ` Vladimir Sementsov-Ogievskiy
2021-09-14 16:32 ` Richard W.M. Jones
2021-09-15 7:15 ` Vladimir Sementsov-Ogievskiy
2021-09-15 9:00 ` Richard W.M. Jones
2021-09-15 9:11 ` Vladimir Sementsov-Ogievskiy
2021-09-17 16:10 ` Eric Blake
2021-09-17 16:05 ` Eric Blake
2021-09-14 19:06 ` Eric Blake
2021-09-14 19:01 ` Eric Blake
2021-11-17 15:47 ` Eric Blake
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=20210914145200.GJ26415@redhat.com \
--to=rjones@redhat.com \
--cc=eblake@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=vsementsov@virtuozzo.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).