[clug] nfs issue
bob at cs.anu.edu.au
Mon May 20 23:15:33 UTC 2019
On 20/5/19 7:20 pm, Eyal Lebedinsky via linux wrote:
> On 20/5/19 6:26 pm, Brett Worth via linux wrote:
>> On 20/5/19 4:13 pm, Eyal Lebedinsky via linux wrote:
>>> Looking at the log I noticed this line:
>> Hi Eyal, Sounds weird.
>> Are both systems time sync'd?
> The source machine is both the nfs server and the local ntp server.
> But even if time is slightly off, why would a file be missing at times?
My response may have been slightly obtuse. As Paul points out, in your
use case (similar to mine), rsync is effectively doing a local "copy"
(it doesn't actually copy if it doesn't need to), with a _lot_ of
fstat()s going on. Rsync is notorious for hammering local filesystems -
it is specifically coded to go fast.
If one or both of the "local" filesystems are actually NFS mounts, then
rsync will hammer the NFS server(s), especially with all those fstat()
If the NFS server is also busy (maybe someone is watching something on
MythTV), then it can behave badly, with some requests being dropped and
having to be repeated. It is possible that rsync doesn't recover well
in this situation.
My work-around is to use ionice to slow rsync down a bit when working
with NFS mounts.
You can also use rsync over SSH (Paul's suggestion), although there is
a lot of encryption/decryption going on, which your NFS server may not
be so happy about. When you do run rsync over SSH, you also then get the
option to control bandwidth, which can also help with not overly loading
down the file server.
You can also run rsync over other network transport protocols to the
I use rsync with NFS mounts as the NFS file servers are in a high-
availability cluster (drbd, keepalived etc.), and running an rsync
daemon on the file servers would prevent the HA code from failing over
More information about the linux