archive mirror
 help / color / mirror / Atom feed
From: Charles Hedrick <>
To: Charles Hedrick <>
Cc: Chuck Lever III <>,
	Benjamin Coddington <>,
	Patrick Goetz <>,
	Linux NFS Mailing List <>
Subject: more problems with NFS. sort of repeatable problem with vmplayer
Date: Tue, 5 Oct 2021 15:46:21 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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.

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.

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. 

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-05 19:46 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                 ` Charles Hedrick [this message]
2021-10-11 14:45                   ` more problems with NFS. sort of repeatable problem with vmplayer J. Bruce Fields
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).