Tips September 26, 2005 at 2:57 pm

Spotlight indexing and RsyncX

After upgrading my home system to Tiger, I noticed that my RsyncX backups to an external FireWire drive were no longer working. Much consternation and hair-pulling later, I realized that the Spotlight indexing was causing problems with RsyncX. I used mdutil to disable indexing on that drive, and the problem was solved.

Ed. Note: keep in mind that Spotlight indexing can make any type of file transfer take longer due to the overhead of indexing every file. This is especially true when you’re moving large amounts of small files.

No Comments

  • Could you please elaborate on the side effects of Spotlight and RsyncX? I’m
    currently in development of a backup solution that will likely be able to use
    RsyncX so this topic is of interest to me.

    Thanks in advance

    • Here’s what I found today when doing a test to see what kind of improvement
      I could get when disabling Spotlight…

      I transferred 12 SQL backup files from a Windows Server 2003 box running
      Cygwin to our backup box, which actually stores the data on an Xserve RAID.
      The two boxes are connected to the our backbone gigabit switch, so don’t be
      alarmed at the bandwidth results…

      All stats reported using the –stats option with the rsync binary included in
      Tiger.

      After the first test, I removed the transferred files so I could force them to be
      copied again.

      Total bytes transferred: 47132868 bytes
      Transfer rate (with spotlight enabled): 5266910.77 bytes/sec
      Transfer rate (with spotlight disabled): 6592846.35 bytes/sec

      Total improvement: 1325935.58 bytes/sec (~25% faster)

      Just what I saw…

  • Just curious to know why you are still using RsyncX when the rsync that now
    ships with 10.4 Tiger maintains the resources from the files.

    The attribute to make this happen is rsync -E
    The "-E" stands for Extended Attributes

    Just an FYI in case you didn’t know.

    • That would be great except for the fact that rsync -E is hideously broken, along with most other CLI apps when forks and meta are concerned.


      Breaking my server to save yours.

      Josh Wisenbaker
      http://www.afp548.com

    • just curious to know why you are still using RsyncX when the rsync that now
      ships with 10.4 Tiger maintains the resources from the files.

      The attribute to make this happen is rsync -E

      The “-E” stands for Extended Attributes

      Just an FYI in case you didn’t know.

      rsync -E – Not ready for prime time yet.. FYI in case you didn’t know

      J.D. Bakker jdb at lartmaker.nl reports –
      Serious problems include:

      • 1) The rsync sender will frequently crash with a Bus Error /
        Segmentation Fault after generating the file list, but before
        transferring any files. This turns out to be caused by a buffer
        overrun.
      • 2) When used with the –delete option, the rsync receiver will try to unlink the (fake) synthetic files, flooding the syslog with failure reports, possibly filling the entire boot disk.
      • 3) When files with extended attributes are transferred, the
        modification time will be set to the time of the transfer, even when the user has specified that modification times be preserved. As a result, using mtime to determine whether a file has changed is broken.
      • 4) Extended attributes have no modification time of themselves. Since
        a file’s mtime is not updated when its attributes are changed, only
        checksumming can be used to determine whether attribute data needs to
        be transferred. With default settings, this means that ALL extended
        attributes are ALWAYS copied.

      Check out Fixing rsync on Tiger Except, this fix isn’t ready for prime time either because it doesn’t recognize that it has already transferred the resource forks and attempts to move them each time it sync’s. But, an answer looms on the horizon..

Leave a reply

You must be logged in to post a comment.