From: "NeilBrown" <neilb@suse.de>
To: "Charles Hedrick" <hedrick@cs.rutgers.edu>
Cc: "Charles Hedrick" <hedrick@rutgers.edu>,
"Chuck Lever III" <chuck.lever@oracle.com>,
"Benjamin Coddington" <bcodding@redhat.com>,
"Patrick Goetz" <pgoetz@math.utexas.edu>,
"Linux NFS Mailing List" <linux-nfs@vger.kernel.org>
Subject: Re: more problems with NFS. sort of repeatable problem with vmplayer
Date: Tue, 12 Oct 2021 10:44:14 +1100 [thread overview]
Message-ID: <163399585460.17149.13892990608606706424@noble.neil.brown.name> (raw)
In-Reply-To: <2C0DB856-23E5-41A2-A9F5-6E64F5A9FCB6@cs.rutgers.edu>
On Wed, 06 Oct 2021, Charles Hedrick wrote:
>
> It tried running vmplayer. Shortly after starting to create a new VM,
> vmplayer hung. I had another window with a shell. I went into the
> directory with the vm files and did “ls -ltrc”. It didn’t quite hang,
> but look about a minute to finish I also saw log entries from VMware
> complaining that disk operations took several seconds.
Useful information to provide when a process appears to hang on NFS
include:
- cat /proc/$PID/stack
- rpcdebug -m nfs -s all; rpcdebug -m rpc -s all ; sleep 2 ;
rpcdebug -m rpc -c all; rpcdebug -m nfs -c all
then collect kernel logs
- tcpdump -w filename.pcap -s 0 -c 1000 port 2049
and compress filename.pcap and put it somewhere we can find it.
- trace-cmd record -e 'nfs:*' sleep 2
trace-cmd report > filename
>
> We’re probably an unusual installation. We’re a CS department, with
> researchers and also a large time-sharing environment for students
> (spread across many machines, with a graphical interface using Xrdb,
> etc). Our people use every piece of software under the sun.
Probably not all that unusual. There certainly are lots of large and
varied NFS sites out there.
>
> Client and server are both Ubuntu 20.04. Server is on ZFS with NVMe storage.
If it is possible to reproduce without ZFS, that would provide useful
information.
I don't think it is *likely* that ZFS causes the problem, but neither
would I be surprised if it did.
NeilBrown
next prev parent reply other threads:[~2021-10-14 22:28 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-13 14:33 safe versions of NFS hedrick
2021-04-13 14:52 ` Patrick Goetz
2021-04-13 15:17 ` hedrick
2021-04-13 15:35 ` Benjamin Coddington
[not found] ` <22DE8966-253D-49A7-936D-F0A0B5246BE6@rutgers.edu>
2021-04-13 16:23 ` Benjamin Coddington
2021-04-13 17:24 ` Chuck Lever III
2021-04-13 17:48 ` hedrick
2021-04-13 18:20 ` hedrick
2021-04-13 19:40 ` hedrick
2021-04-13 19:48 ` hedrick
2021-10-05 19:46 ` more problems with NFS. sort of repeatable problem with vmplayer Charles Hedrick
2021-10-11 14:45 ` J. Bruce Fields
2021-10-11 23:44 ` NeilBrown [this message]
2021-10-14 22:55 ` Charles Hedrick
2021-04-14 14:15 ` safe versions of NFS Chuck Lever III
2021-04-14 14:24 ` hedrick
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=163399585460.17149.13892990608606706424@noble.neil.brown.name \
--to=neilb@suse.de \
--cc=bcodding@redhat.com \
--cc=chuck.lever@oracle.com \
--cc=hedrick@cs.rutgers.edu \
--cc=hedrick@rutgers.edu \
--cc=linux-nfs@vger.kernel.org \
--cc=pgoetz@math.utexas.edu \
/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).