We use rsync to update an nfs server. After an update, we noticed that
a large number of clients didn't see the updated data.
It took me a while to be able to reliably reproduce this problem, but it
happens on old and new versions of rysnc. It also happens across all
the platforms we use here (sun/linux/netapp).
This shows the problem: [Note my home directory is NFS mounted]
***************************************************
rm -f /tmp/testpath/* $HOME/testpath/*
#Prime it
echo some data > /tmp/testpath/testfile
sleep 1
rsync -a /tmp/testpath/ $HOME/testpath/
ssh $otherbox ls -li $HOME/testpath
#Break it
echo additional data >> /tmp/testpath/testfile
sleep 1
rsync -a -b /tmp/testpath/ $HOME/testpath/
ssh $otherbox ls -li $HOME/testpath
#Fix it
touch $HOME/testpath
ssh $otherbox ls -li $HOME/testpath
***************************************************
Here's the output:
total 0
483079 -rw-r--r-- 1 brian source 10 May 6 18:05 testfile
total 0
483079 -rw-r--r-- 1 brian source 10 May 6 18:05 testfile
total 0
483080 -rw-r--r-- 1 brian source 26 May 6 18:05 testfile
483079 -rw-r--r-- 1 brian source 10 May 6 18:05 testfile~
The output from the "break it" section matches "prime it", but it should
match the "fix it" output.
What I think is happening:
--------------------------
* testfile is updated in place, so the mtime of testpath
isn't udpated.
* The nfs client is caching the mtime of "testpath"
* The seconds rsync modifies the contents of testpath, but
when finished, it resets the mtime on "testpath"
* The client believes it's cache is valid, so I doesn't refresh, and
therefore it misses the update
NFS Clients tested: sun (solaris 8 & 9), linux (2.4.18 & 2.4.24)
NFS Servers tested: sun, linux, and netapp.
They all behaved the same.
Proposed fix:
-------------
Change rsync so it doesn't reset mtimes on directories if --backup is
in effect.
Thanks,
Brian
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
