3

I have sshfs setup to connect to another system (Rackspace Cloud Sites) that I don't have ssh access to (but for some reason I can use sshfs? Go figure). I'm attempting to rsync files from the sshfs mount to my local disk. It's several thousand small files (1k-200k). Sometimes, the rsync will just pause and hang for a while on files that are very small. It will pause on, say a 10k text file for like 5 minutes, then it will continue.

Is there anyplace I can look on my machine to determine why rsync would be hanging like this? Or is there a good chance it's simply a problem on the other end that I can't do anything about?

My rsync options are simply -avrP.

3
  • Do you get the same behaviour when copying large files?
    – Khaled
    Jan 10, 2012 at 16:08
  • Not that I have noticed. Jan 10, 2012 at 16:11
  • What options are you using with rsync? Jan 10, 2012 at 16:15

1 Answer 1

4

Alright, I'm going to take a stab at this, because I think my idea makes sense.

You are dealing with multiple caches in this case, and that's what is tripping you up, I think.

The first thing that rsync does is to determine which files it needs to transfer. It usually does this by spawning an instance of rsync at the remote side, reading the metadata for each of the files in the directory on the source, while at the same time reading metadata for the local files, and then the two metadata sets are compared. Anything newer (or different, depending on the rsync options) gets transferred.

You don't have a "remote side", according to rsync. You're working "locally", so it will iterate over both directories, the source and the destination.

This is very disk intensive, particularly with a ton of small files - the more files, the more discrete disk operations. This causes a lot of disk thrashing, plus it fills the cache with the metadata from those files.

Notice that this happens all the way down the stack. Your local machine caches metadata from the FUSE filesystem you've got mounted over ssh AND the local directory. The remote machine caches metadata from the local disk mount. And the VM host that your remote machine is running on is almost certainly overcommitted and giving you ballooned memory.

I suspect that it's very likely that you're crossing thresholds when it freezes, and everything has to catch up and either decache or swap.

I would be very interested to see if this happens when you do rsync over ssh without the disk mount.

6
  • That sounds like that might be right. Because the remote environment is a dynamic website with an ever-changing web cache, I noticed that rsync couldn't find some files, most likely because some cache files were there when it started but were gone by the time rsync tried to find them. And unfortunately I can't do rsync over ssh with the remote host. It's Rackspace and SSH/SFTP isn't allowed :-( Super lame. I know. But my hands are tied. SSHFS is the best solution I've been able to put together. Jan 10, 2012 at 16:44
  • What is the overall goal of what you're trying to do? There may be a better way Jan 10, 2012 at 16:50
  • Just sync files from the remote server to the local disk. I'm just using rsync so that I can run it again later to download the latest files without having to re-copy stuff that doesn't need to be copied again. I don't know if there are any FTP-protocol-specific tools like Rsync. Jan 10, 2012 at 16:55
  • Might there be a way to transfer a smaller number of files at a time? Can you logically break it up according to directories or file names, rather than reading everything? Jan 10, 2012 at 17:23
  • Yeah I thought about that. Just getting a directory listing or something and then rsyncing each directory one at a time. Or else getting a list of all the files and then rsyncing 100 at a time or something along those lines. This wouldn't be very difficult using the --include-from= rsync option. Jan 10, 2012 at 20:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .