NFS on Snow Leopard

I don't know what it is about Apple and NFS, but they keep moving things around. The new UI to NFS mounting is much nicer than it was before, but it's now in a totally different place: the Disk Utility. But if you use a lot of NFS file systems, it's a pain to have to mount them one by one: ignoring the UI and using the /net automount filesystem is far more convenient. Just use the file name /net/hostname/path and you don't have to mess with any mounting, it just happens by automagic. I wrote a blog entry about this a long time ago.

However, there is a huge problem with this: OS X does a phenominal amount of file locking (some would say, needlessly so) and has always been really sensitive to the configuration of locking on the NFS servers. So much so that if you randomly pick an NFS server in a large enterprise, true success is pretty unlikely. It'll succeed, but you'll keep getting messages indicating that the lock server is down, followed quickly by another message that the lock server is back up again. Even if you do get the NFS server tuned precisely the way that OS X wants it, performance sucks because of all the lock/unlock protocol requests that fly across the network. They clearly did something in Snow Leopard to aggravate this problem: it's now nasty enough to make NFS almost useless for me.

Fortunately, there is a fix: just turn off network locking. You can do it by adding the "nolocks,locallocks" options in the advanced options field of the Disk Utility NFS mounting UI, but this is painful if you do a lot of them, and doesn't help at all with /net. You can edit /etc/auto_master to add these options to the /net entry, but it doesn't affect other mounts - however I do recommend deleting the hidefromfinder option in auto_master. If you want to fix every automount, edit /etc/autofs.conf and search for the line that starts with AUTOMOUNTD_MNTOPTS=. These options get applied on every mount. Add nolocks,locallocks and your world will be faster and happier after you reboot.



Why keep using OS X when you see how Apple has become, full of themselves, disdain of Java technologies, etc.

Posted by guest on August 30, 2009 at 02:01 AM PDT #

For my family, Apple's stuff works very well. For them Linux/Solaris just aren't there yet. For myself, I use both OS X and Solaris fairly evenly. OS X because applications like Lightwave, Photoshop and Illustrator are necessary to me. Solaris because everything else is so much better (eg. NetBeans performance is \*amazing\*).

Posted by James Gosling on August 30, 2009 at 02:20 AM PDT #

Out of curiosity, do you run solaris on a laptop or workstation?

Posted by Les Stroud on August 30, 2009 at 03:49 AM PDT #

To extend my question a little further, it would be interesting to know your hardware setup in general.

I use netbeans quite a lot, and while it's performance has significantly improved over time, I would never describe it as blazing. I run it on my mac (4 core) and a 2 core linux box. Both have significant RAM. Does netbeans perform that much better on solaris than either OSX or linux? If so, I'll switch in a heart beat. :-P

Posted by Les Stroud on August 30, 2009 at 04:44 AM PDT #

On equivalent hardware, Solaris and Linux are essentially identical for computational benchmarks. I run NetBeans on a fairly hefty [in all senses :-( ] alienware laptop. For computational stuff, OS X is pretty much the same as Solaris. They're all using the same VM. The problem with OS X is that the optimized java2d graphics hardware pipelines haven't been hooked up by Apple, so all too often, it's pure CPU software rendering. NetBeans doesn't do terribly exotic rendering, but it is noticeable. Applications that render through APIs like jogl do much better.

Posted by James Gosling on August 30, 2009 at 05:26 AM PDT #


You'd think that making NFS work badly, especially on a BSD derivative, would be hard after all these years! (I remember AIX's pains trying to use/admin it ~15 years ago for a large client of mine, but even cheap Windows PC clients could do better...)

And though I like my OS X '\*nix' laptop, given Apple's disdain for my primary development platform, Java (JDK6), it may well be my last Mac, and I'm amazed that you continue to give their stuff the time of day.

I do hope that someone makes a really captivating developer- and human- friendly Linux laptop before my MacBook dies. I have a Eee, but even the netbook market seems to have been subverted by ... ahem ... someone in WA.



Posted by Damon Hart-Davis on August 30, 2009 at 05:52 AM PDT #

Yeah, it is amazing how apple continues to frustrate us java folk. I hope apple sees the wisdom of carving out the piece of the jvm that they use to integrate into their system and building it on top of open jdk. For that matter, it would be nice if they would open source their integrated pieces as well. Maybe we would have a chance to optimize such things in a decent time frame. It's apple, I know, I know....but I can dream. :)

Thanx for the feedback.

Posted by Les Stroud on August 30, 2009 at 06:25 AM PDT #

Same sentiment as other posters. Just wish you (& other Sun executives) could have spent more time on "Open"Solaris. Emphasis added.

'nuff said.

Posted by W. Wayne Liauh on August 30, 2009 at 07:27 PM PDT #

James, side note Can u reassure us with respect of swing, javafx & swing integration. Why for ex, in 2009, we still do not have a proper jtreetable? Thx

Posted by guest on August 30, 2009 at 10:04 PM PDT #

Amazing how people complain over Apple, yet still defend and stick to this more proprietary platform than they originally fled to from Microsoft.

Posted by Martin S. on August 31, 2009 at 05:19 AM PDT #


Without putting too fine a point on it Martin, Apple has engineering standards that I can live with. This MacBook of mine is several years old, has not crashed seriously at all (has probably rebooted once unbidden), is based on a secure OS that I have faith in (ie a \*nix), probably has a little of my code lurking in it (as in Solaris and Linux too), and restart in <<30s from opening the lid whereas my XP boxes take minutes, etc, etc.

However, even robust engineering does not outweigh my irritation from the lack of support for my preferred language, Java.



Posted by Damon Hart-Davis on September 01, 2009 at 05:31 AM PDT #

The file locking Mac OS X generates comes probably from the large amount of RAM caching it does, and in 64 bit machines this has increased.

In any case, the preference for locks should be more easily settable from the UI...

Posted by juandesant on September 02, 2009 at 10:39 PM PDT #

Gents, this linux hack (me) barely managed to get his NFS shares up-and-running on linux in the first place (years ago), and now is flummoxed by the Snow Leopard changes. S L O W. Glad someone else has seen the same.

I'm wondering if there is a way to have cake / eat it, too w.r.t. a solution:

have cake: I connect to my NFS using the simple "Connect to Server" feature of Finder. Super easy = good for me. Have no idea what parameters are established; "it just works"

Eat it, too: is it possible to avoid the client-side locking behavior by changing a parameter on the NFS? I'm capable of changing /etc/exports to include a parameter. today, my parameters are: rw,root_squash,async,insecure

Most grateful for any assistance you can offer to this NFS n00b (problem isn't that I haven't tried to RTFM; problem is that it doesn't stick too well...)

Posted by Todd on September 03, 2009 at 04:31 AM PDT #

Doing some speed tests of NFS, using the nolocks,locallocks option. Writing using dd if=/dev/zero ...; reading using dd ... of = /dev/null
- write to NFS from OS X: 150% faster
- read from NFS on OS X: 20% slower

That is significant, as I'm seeing that reads from NFS are much, much slower than writes: 180Kbps for reads; 4161Kbps for writes.
I repeated the above with a cp rather than dd and found it to be even worse: about 40x faster to copy to an NFS than to copy from it.

Anyone have insights on how to speed up reads from NFS in OS X?

Posted by todd on September 04, 2009 at 07:40 AM PDT #

Post a Comment:
Comments are closed for this entry.



« July 2016