linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Emmanuel Florac <eflorac@intellique.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: linux-nfs@vger.kernel.org
Subject: Re: Hard to debug NFS loss of connectivity
Date: Thu, 5 Sep 2013 23:34:49 +0200	[thread overview]
Message-ID: <20130905233449.5eb8bf79@galadriel.home> (raw)
In-Reply-To: <20130905204536.GB24805@fieldses.org>

Le Thu, 5 Sep 2013 16:45:36 -0400 vous écriviez:

> Well, it sounds like you have a reproducer that shouldn't be *too*
> huge (the test where it freezes after stat'ing 25 files).
> 
> What do you see on the network in that case?

I didn't look yet what's actually happening, out of the drop in network
throughput.
 
> Are you literally using just tcpdump?  Wireshark will give more
> (and easier to read) information.

I didn't install tcpdump yet, but isn't wireshark with a GUI? I can't
run anything with a GUI, this is a remote site behind several ssh
portals. So I should run tshark, then get my hands on the results to
analyze them with wireshark on my PC. Will try that.
 
> Does the server stop responding at some point, or reply with an error?

No response. I don't know if the server actually stops responding or if
something's wrong on the client side. Unfortunately I don't have
access to any other NFS client on this network, out of this VM and the
server itself. When rebooting the VM reconnects to the server  all by
itself, so the server most probably is OK at all times.

> Or does the getattr reply on the problem file look odd in any way?

Not odd at all; it just stops after a particular file, though this file
and the following files can be accessed OK before I run the failing
test.

regards,
-- 
------------------------------------------------------------------------
Emmanuel Florac     |   Direction technique
                    |   Intellique
                    |	<eflorac@intellique.com>
                    |   +33 1 78 94 84 02
------------------------------------------------------------------------

  reply	other threads:[~2013-09-05 21:35 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-05 17:18 Hard to debug NFS loss of connectivity Emmanuel Florac
2013-09-05 20:45 ` J. Bruce Fields
2013-09-05 21:34   ` Emmanuel Florac [this message]
2013-09-05 21:40     ` J. Bruce Fields
2013-09-06 15:57       ` Emmanuel Florac
2013-09-06 16:07         ` J. Bruce Fields
2013-09-06 16:55           ` Emmanuel Florac
2013-09-10 13:28             ` J. Bruce Fields
2013-09-10 13:34               ` Emmanuel Florac
2013-09-06 17:15         ` Jim Rees
2013-09-11 15:11 ` Hard to debug NFS loss of connectivity: problem solved Emmanuel Florac
2013-09-11 20:14   ` J. Bruce Fields

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=20130905233449.5eb8bf79@galadriel.home \
    --to=eflorac@intellique.com \
    --cc=bfields@fieldses.org \
    --cc=linux-nfs@vger.kernel.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 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).