[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