[tahoe-dev] several questions about tahoe backup

[Brian Warner]

On 3/1/12 1:06 AM, Dmitriy Kazimirov wrote:

Good questions!

> - backup's filecheck - is it only checks file or also perform lease
>   renewal for it's shares?

It looks like it only checks the files, and does *not* do lease-renewal.
It's really just there to make sure it's safe to re-use an existing file
instead of re-uploading it, and it's only trying to provide for the
current ("Latest") snapshot.

Since "tahoe backup" doesn't look at older snapshots anyways (except for
shared files), to make sure all your (old and new) backups are intact
and renewed, you should do a "tahoe deep-check --add-lease --repair"
after the "tahoe backup". The --repair will be redundant for the most
recent snapshot, since "tahoe backup" re-uploads any files that don't
pass the filecheck.

> - when filecheck --repair proceeds with file, if file was uploaded
>   with different k and N and new values of k/N ones(on this gateway)
>   are not enough(but file is otherwise ok) -will file be fixed to new
>   settings?

> - same as previous question but file is unhealthy. Will new k/N values
>   be used for repair or original ones?

Nope. Changing a file to use different k/N values is called
"re-encoding", and nothing in tahoe does that right now. The filecheck
operation is satisfied if there are N distinct shares (maybe requiring N
distinct hosts, I forget), and does not complain if the file's k/N are
different from the local gateway's configured default values. Those
tahoe.cfg values are only used for newly-uploaded files.

Repair strictly uses the k/N values from the uploaded file, *not* the
defaults configured into the local gateway. It needs to do this because
k and N are properties of the encoding, and are included in the filecap
(uploading the same plaintext with different k/N values will result in
different shares and different filecaps).

That said, I don't know how our "shares of happiness" (H) value is
handled. I don't believe that H is stored in the share (whereas k and N
are definitely stored in the share). I wouldn't be surprised if there's
a bug in which repair fails because it's trying to achieve a
locally-configured H value on a file that was encoded with very
different k/N values (say k=1 N=2 but H=5). Kevan, David-Sarah, any
thoughts?

cheers,
 -Brian