[tahoe-dev] [tahoe-lafs] #643: Tahoe Repair process

[Brian Warner]

On Thu, 5 Mar 2009 17:59:51 +1100
Andrej Falout <andrej at falout.org> wrote:

> >   Brian Warner has been writing code like that, to trigger repair processes
> >  at certain times.  I think it isn't quite documented yet but already runs.
> 
> Would it be possible to see that script code to use as an example?

The easiest way to drive a repair process is to use the CLI "deep-check"
command with the extra --repair argument:

 tahoe deep-check --repair ALIAS:

That will examine every file and directory reachable from the root ALIAS:,
and will perform repair on anything that appears unhealthy. I've seen this
command check anywhere from 1 to 10 files per second, depending upon the
grid. The main downside is that, in the current codebase, repair is performed
at the slightest sign of missing shares: a file that was encoded at 3-of-10
will be repaired if the checker finds 9 shares. What we really want is to
allow the user to provide a "repair threshold", probably with an argument
like "--repair=7", to mean that a file should be repaired if it has fewer
than 7 shares, rather than fewer than 10 shares. The idea is defer repairing
almost-healthy files until later, to conserve network bandwidth.

The other scripts I've been writing are fairly allmydata-specific, as they
work from manifests generated from our database of account rootcaps. They're
also designed to run in parallel (using dozens of worker nodes) on multiple
accounts at once. Also, they're pretty gross :). One of them takes a manifest
file (the output of "tahoe deep-check --raw") and writes individual entries
to a set of files that are organized according to how healthy the files are.
Another script looks at those individual files and runs single-file repairs
("tahoe check --repair") on each object.

If the "tahoe deep-check" approach doesn't work for you, let me know and I'll
see if I can clean up those scripts and publish a copy.

cheers,
 -Brian