[mythtv-users] pixelation when using nfs for playback

Vincent McIntyre vincent.mcintyre at gmail.com
Sun May 15 10:19:13 UTC 2011


On 5/15/11, f-myth-users at media.mit.edu <f-myth-users at media.mit.edu> wrote:

> ### With either noac or actimeo=1, we're pretty much up-to-the-second,
> ### but you should NOT use noac.  Use actimeo=1 instead.  The reason
> ### is a -50x- performance hit only in the PUSH direction if noac is
> ### used.  E.g,. -pulling- things from the remote host to the local
> ### host will work fine, but -pushing- things will run at about 20
> ### meg/min.  It doesn't matter which way the bits are flowing, as
> ### long as both ends have noac, nor whether rsync or cp is being
> ### used, nor whether rsync is bwlimited---what matters is purely
> ### whether the command that's moving the bits is pushing them away to
> ### a remote NFS mount or pulling from a remote mount to the local
> ### disk.  In the push case, performance goes to hell with noac, but
> ### in the pull case, it seems unaffected.  Using actimeo=1 instead
> ### seems to work just fine and doesn't screw up our ability to notice
> ### updates quickly.  (My guess is that the push case causes a
> ### complete refresh of the entire destination directory's attributes
> ### every single time the file gets extended, which happens pretty
> ### much on every packet or bufferful thereof.  So the vast majority
> ### of the network traffic turns out to be NFS attribute updates
> ### instead of actual work.)  Note that fixing this at the NFS
> ### -client- side fixes this, e.g., if A has noac set for its mount
> ### of B, then pushing -to- B sucks.  But as soon as A's noac is
> ### remounted as actimeo=1 (even mid-transfer, via "mount remount -o
> ### actimeo=1 B:/foo /foo"), the push from A to B immediately takes
> ### off and continues at its more-normal ~1G/min instead of 20M/min.

I looked this up and found some notes in nfs(5) that may help to explain this:
...
                      In  addition  to preventing the client from caching file
                      attributes, the noac option forces application writes to
                      become  synchronous  so  that  local  changes  to a file
                      become visible on the  server  immediately.   That  way,
                      other clients can quickly detect recent writes when they
                      check the file’s attributes.

                      Using the noac option provides greater  cache  coherence
                      among  NFS  clients  accessing  the  same  files, but it
                      extracts a significant performance  penalty.   As  such,
                      judicious  use  of  file  locking is encouraged instead.
                      The DATA  AND  METADATA  COHERENCE  section  contains  a
                      detailed discussion of these trade-offs.
...


More information about the mythtv-users mailing list