script for determining space consumed by increments

[Ben Escoto]

--==_Exmh_1055166590P
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

--==_Exmh_1055166590P
Content-Type: application/pgp-signature

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

iD8DBQE83dYG+owuOvknOnURAoLKAJ9YwiWPmwtcrSw/bN5t87uCf+VBAACfSMWA
4w8sVSoCrgb4YGoVrU7p5eA=
=1x83
-----END PGP SIGNATURE-----

--==_Exmh_1055166590P--