[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