NFS share on Ubuntu grinds iMac down to a halt when mounted

Question

We're at a university in a lab trying to create an NFS share that can be shared between OS X and Ubuntu machines. This problem has been driving my supervisor and I crazy for the past few days - posting here because we're at wits' end.

I'll try and outline the situation as best I can:

• NFS daemon (1:1.2.5-3ubuntu3.1) is running on an Ubuntu server 12.04

• The server setup (/etc/exports) looks like so:

  /export -rw,fsid=0,no_subtree_check client.computer.name
  /export/data -rw,async,subtree_check,all_squash,anonuid=2000,anongid=2000 client.computer.name
  /export/moredata -rw,async,subtree_check client.computer.name
  

• share /data and /moredata have successfully been mounted on Ubuntu machines without problems using the following command:

  sudo mount server:/data /srv/data
  

• On certain Mac OS X machines, ones running Lion or Snow Leopard, the mounts all work as normal but require modifications to the mount command due to some issues that I think are irrelevant to the problem at hand

  sudo mount -t nfs -o resvport,vers=4,proto=tcp,port=2049 server:/data /Volumes/data
  

• On two separate machines running OS X 10.8 (latest version of Mountain Lion) however, there are major problems.

• About half the time, the NFS share mounts fine on my iMac running OS X 10.8 but my computer grinds to a halt and even running an 'ls -la' on the server directory takes minutes to start. Once the server has mounted, even running ls on local directories has the same effect!

The other half of the time, the computer grinds to a halt during the mounting process.

• edit Spotlight indexing is not an issue as the mount point is added to the spotlight exclusion list.

Also, running activity monitor, or 'top' yields no insight, nothing is taking more than 10% processing power, and there is plenty of available RAM.

How can I debug this? What logs are useful to interrogate?

** Updates **

• rpcinfo log before and after mounting

http://pastebin.com/FZUxbK1s

• Here are some interesting log results during the mounting of the share:

http://pastebin.com/yd6JEH10

This is the message that seems more alarming

2013-01-11 12:27:49.572191 PST - 348.1506 - Client: mount_nfs, UID: 0, EUID: 0, GID: 0, EGID: 0
2013-01-11 12:27:49.572191 PST - 348.1506, Module: SystemCache - Invalid name (null) for KAUTH_EXTLOOKUP_VALID_PW/GRNAM

Answer 1

Try adding nolocks and locallocks to those specific machine mounts.

credits: http://hardforum.com/showthread.php?p=1039476929

Answer 2

It is possible that spotlight (OS X index/search service) is trying to index the new mount points, which means trying to go through the whole directory structure and every single files in it. You can disable indexing on those mount point doing following

1. Open System Preferences
2. Click Spotlight
3. Click Privacy
4. Click + to add NFS mount point into exclusion list.

Answer 3

It's an IO bottleneck, not a CPU bottleneck. This is why you are not seeing high percentage usage with a task manager.

This points me to think that there might be issues with your network connection to the NFS server. Perhaps routers, hubs, or switches, the in-between devices may be dropping your packets (had this issue with both FTP and SVN on different occasions with different hardware). If you can, I would try setting a static IP for both server and iMac, and use one good, tested ethernet cable to connect them directly together. See how it performs then.

If the problem still persists, perhaps there is 3rd party NFS mounting software you can use on the Mac, that would pin-point if it is Apples NFS implementation causing issues.

Perhaps try installing Linux in a virtual machine on the Mac and see if you can connect to the NFS on that. That would rule out any sort of hardware issues on the iMac side.

Tools:

• Look into the terminal application "iotop" command on both Mac and Linux side.
• Wireshark, I don't use this much, but perhaps it will help.

Answer 4

You could also try mounting it using autofs (see here or here for a technical white paper from Apple).

That way, the share is only mounted when accessed and automatically unmounted when not in use. If you make sure to add the soft option so the system does not hang waiting for the share to respond, you might have solved your problem.