[mythtv-users] NFS and remote backend

David Brodbeck gull at gull.us
Sat Jan 12 01:20:50 UTC 2008

Just thought I'd add some notes on NFS tuning, since I had to do some  
recently.  I think the effects of some of the options on NFSv3 are  
widely misunderstood.

On Jan 11, 2008, at 11:46 AM, Chris Pinkham wrote:
> Share is async on the server.  It's for video only so I don't slow the
> clients down by requiring sync when recording.

Note that "async" greatly speeds up NFSv2, but with NFSv3 it just  
makes things riskier without much speed improvement.

NFSv3 added data caching to the protocol.  An NFSv3 server in sync  
mode *won't* wait for the data to be written to disk during normal  
requests, but when the client issues an fsync() call or closes a file  
the server will wait until the data is written to disk before allowing  
the call to complete.  This is nearly as fast as async operation most  
of the time, and offers better data integrity.  Look at http://nfs.sourceforge.net/ 
  and search for "safe asynchronous writes" for a good explanation.

The client mount option to avoid in NFSv3, unless you really can't  
avoid it, is "noac".  That *really* slows down performance by  
disabling attribute caching.  If you can afford to have clients have  
slightly out-of-sync views of the filesystem you can lower overhead a  
bit by increasing actimeo.  For example "actimeo=3" will tell clients  
they can rely on cached data for up to 3 seconds.

Sorry to pontificate, but I just went through setting this up in a  
computer lab I maintain, about six months ago.  For a video share it  
doesn't really matter if you get a corrupted file when the server  
crashes, but when this happens to someone's home directory they get  
testy. ;)

More information about the mythtv-users mailing list