[rdiff-backup-users] --check-destination-dir taking a very long time

[Walt Mankowski]

I've been running rdiff-backup to an external USB drive for years
without any problems. Over the weekend my backup failed with

  Exception '[Errno 28] No space left on device

This is odd, since there is 1.2 TB free on the drive. I didn't see any
errors in syslog, and I was able to create a new file on the drive
without any problem.

Thinking it might have been a USB glitch I rebooted the machine and
now I'm running

  rdiff-backup --check-destination-dir

to recover the backup directory. It was taking a very long time, and I
restarted it with the -v8 hoping I might get some clue as to what it
was doing. Unfortunately after spitting out some routine-looking
output in the first few seconds it's now been running in silence for
nearly 12 hours.

It's getting CPU time and I don't see any errors in syslog, so I'm
assuming that it's doing something. But I don't have any idea what
it's doing, if it's working correctly, or how much longer it's likely
to take.

Is it normal that a regression takes this long? /backup is currently
at 527 GB.

Thanks.

Walt