[mythtv-users] NFS and remote backend

[Chris Pinkham]

All comments below are related to _dedicated_ video filesystems.

* On Fri Jan 11, 2008 at 05:20:50PM -0800, David Brodbeck wrote:
> 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.

This is video, my regular data shares do not use async.

> 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.

Myth's ThreadedFileWriter calls fsync(), so at most I'll lose a second or
two of video.  Myth also runs fsync() in its own thread.

> 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.

If this is a dedicated video filesystem, you _don't_ want attribute caching.
You want the client to know about filesystem changes as soon as they are made,
This has been discussed on the list before.  Attribute caching has shown to
cause issues with the frontend not seeing the data soon enough after the
backend has written data to disk.  You're not accessing these files
hundreds of times a second, you're checking for files occasionally and
then spending 30 or 60 minutes or more watching a video.  Any attribute
cache has now expired by the time you finish watching the recording, so the
only thing you're speeding up is if you constantly start and stop playback
or surf through the same channels in the guide grid.  In my opinion that's
not enough of a reason to enable attribute caching which is why I use
actimeo=0.

> 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. ;)

That was my point.  These are my video shares and I'm not attached to
my TV recordings enough that losing one will hurt too much.  The WAF
might drop a little, but that's what "delete and re-record" is for.

At work I deal with an environment with over 1000 servers including
multiple Linux, Windows, and EMC Celerra fileservers.  I would never
advocate using these settings in my production work environment or for
anything that you can't afford to lose part of, but for replaceable TV
recordings, they are more optimal.  We've had lots of NFS tuning
discussions on the mailing lists in the past and I think there is even
a page on the wiki describing recommended settings and why they are
recommended.

--
Chris