archive mirror
 help / color / mirror / Atom feed
From: (J. Bruce Fields)
To: Charles Hedrick <>
Cc: Charles Hedrick <>,
	Chuck Lever III <>,
	Benjamin Coddington <>,
	Patrick Goetz <>,
	Linux NFS Mailing List <>
Subject: Re: more problems with NFS. sort of repeatable problem with vmplayer
Date: Mon, 11 Oct 2021 10:45:52 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Tue, Oct 05, 2021 at 03:46:21PM -0400, Charles Hedrick wrote:
> We just found a nearly repeatable problem. If you run vmplayer (a desktop VM system from VMware). with its vm storage on NFS, the system eventually locks up. Some of the time. It happens consistently for one user, and I just saw it.

Could you explain what you mean by "locks up"?  Is one application
hanging, or is the whole machine unresponsive until rebooted?

> When we told the user for which it is consistent to move his vm’s to local storage, the problem went away.
> 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.

Any kernel messages in the log around that time?

> We saw this problem last semester consistentl, though I didn’t realize
> a connection with vmplayer (if it existed). We fixed it by forcing
> mounts to use NFS 4.0. Since delegations are now disabled on our
> server, I’m assuming that the problem is locking. We don’t normally
> use locking a lot, but I believe that VMware uses it extensively. 

So you're normally using NFSv4.2?


> The problem occurs on Ubuntu 20.04 with both the normal (5.4) and HWE
> (5.11) kernels.
> Any thoughts? At the moment I’m tempted to force 4.0, but I’d like to
> be able to use 4.2 at some point. Since it still happens with 5.11 it
> doesn’t look good. I’m willing to try a more recent kernel if it’s
> likely to help.
> 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.
> Client and server are both Ubuntu 20.04. Server is on ZFS with NVMe
> storage.

  reply	other threads:[~2021-10-11 14:45 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]       ` <>
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 [this message]
2021-10-11 23:44                   ` NeilBrown
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:

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

  git send-email \ \ \ \ \ \ \ \ \

* 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).