High volume problem: stat: no such file or directory

Bob Robison bob.robison at swri.org
Tue Jan 24 18:32:35 GMT 2006

On Fri, 20 Jan 2006 08:42:09 -0800
Wayne Davison <wayned at samba.org> wrote:

> On Thu, Jan 19, 2006 at 04:26:32PM -0600, Bob Robison wrote:
> > The server-side error messages occasionally report the problem
> > referenced in the subject  stat: no such file or directory.
> Older rsync versions would first move the file into place, and then
> chmod() the file to the right permissions.  Newer versions chmod() the
> temp file to the right permissions, and then move the file into place.
> Since you have a process that is yanking finished files away from the
> destination directory, I assume that upgrading rsync with fix this
> problem for you.

OK, I've upgraded to rsync 2.6.6 and the no such file or directory problem went away.  However, I'm still having difficulty.  Primarily with performance, at the moment.  I switched from running rsync under xinetd, to running just rsync --daemon, but it didn't help.

After running a while, I have seen as many as 300+ rsync processes remain active.  I have seen the client side process stay active for a long time (7-10 minutes) while trying to transfer a few-K file.  I 'shut off' the source of these transfers and eventually, the server process catches up.  The last time I tried this I saw a 10 minute gap in the timestamps showing up in the syslog file --- like something was hung for that whole time, and then finally cleared up.

Possibly I should totally disable syslog logging (at least as a test), but I couldn't figure out how to do that.  I guess I could try setting a log file to /dev/null.  Any ideas if this is worth it?

I'm open to other suggestions on optimizing, or monitoring what is going on.  Is anyone else using rsync to transfer many files continuously, on this scale?  BTW, this is running on a dual-opteron system and average CPU load shows about 10% idle most of the time.


More information about the rsync mailing list