[rdiff-backup-users] Q. on max-file-size behavior

[Whit Blauvelt]

Hi,

Situation:

I've backed up a large directory tree once - went fine. Then I've decided
that going forward I don't really care about overly large files that
sometimes show up in the original. So I change the subsequent invocation to:

rdiff-backup -v 5 --max-file-size 1000 somebox::/some/dir /some/dir

And I watch rdiff-backup go along, until it gets to one particulary large
file (> 16g), at which point it sits there for many minutes with high CPU
use and a message that it is

Incrementing mirror file /some/dir/sub/16gplus.file

Now, this is rdiff-backup 1.1.15 on Ubuntu 8.04 LTS (the current version for
that distro version). But Google hasn't found me to any discussion of this
sort of bug in this function since fixed. My expectation is when that file
it says it's incrementing is way beyond max-file-size, it should simply
leave it alone and go on to the next file. Is the problem that I didn't have
max-file-size flagged the first time through, so that any file copied once
gets incremented in subsequent runs regardless?

Or is something else at the root of the problem here? In my current test
it's been hanging on that one large file for over 25 minutes, with no
traffic across the interface.

It may not be a coincidence that with this same file system, but copying it
to a different place on the backup machine, I also couldn't get rsync
(3.0.7) to obey its similar --max-size command. It also wants to choke
itself on that file anyhow, and at least rdiff-backup only runs the system
load to ~1 while doing this, where rsync is happy to run it > 10. This is
with ext3 file systems on both ends, and a crossover cable between the two
machines. It's because of rsync's failure here that I'm trying rdiff-backup.

Whit