script for determining space consumed by increments

Ben Escoto
Sat, 11 May 2002 19:40:07 -0700

Content-Type: text/plain; charset=us-ascii

>>>>> "KS" == Kevin Spicer <Spicer>
>>>>> wrote the following on Sun, 12 May 2002 01:25:40 +0100

  KS> I can understand why this would be the case for directories but
  KS> not for files, surely rdiff-backup would only need to examine
  KS> files whose mtime is different to the remote copy?  Also I noted
  KS> that the atimes have been copied accross to the mirror (or
  KS> caused to be set to the same time) even when there are no
  KS> increments for that file [is the the bug fixed below?].

I think the bug was only with --change-source-perms, and caused
rdiff-backup to unnecessarily set certain atimes (not to look into the
files affected).  Casually testing just now it seems rdiff-backup is
now (0.7.4 at least) doing the right thing as far as atimes go, but
tell me if you see any more weirdness.

  KS> Finally - an idea - if rdiff-backup is only interested in the
  KS> mtime would keeping a local cache of the mtimes of files on the
  KS> mirror to speed up operation when the destination directory is
  KS> on a remote machine.  I'm not sure whether this would be
  KS> worthwhile on small backups, but my directory contains the best
  KS> part of a million and a half files - so even a few milliseconds
  KS> on each file would save substantial time (my whole rdiff-backup
  KS> run takes about 10hours per night).

That could definitely save on bandwidth.  Do you have a feel to where
the bottleneck is (e.g. local disk, local cpu, network, remote disk,
remote cpu)?

Ben Escoto

Content-Type: application/pgp-signature

Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Exmh version 2.5 01/15/2001