[tahoe-dev] Mixing different shares.needed/happy/total settings

[Brian Warner]

On 5/3/11 7:00 AM, Lionel Bouton wrote:
> 
> 1/ If I understand correctly, at least "needed" and "total" are only
> used when creating new content (file-encoding.rst: « the encoding
> parameters are included in the hash stored »). But is the "happy"
> value stored too or read from conf ? IE: will a repair use the client
> node configuration (which could be bad if I move to happy > 6 after
> creating content with total = 6 for example).

Nope, "happy" is not recorded anywhere, it is only read from tahoe.cfg
at client-startup time, whereas "needed" and "total" *are* stored in the
filecap. During repair, "needed" and "total" are taken from the existing
filecap, not read from tahoe.cfg . But note that during repair (at least
for immutable files), "happy" is set to 0 (see ticket #1212 for details).

(mutable files are different: I don't think we have servers-of-happiness
implemented yet, for either repair or the original upload)

> 2/ when creating an alias, I assume the current shares.needed/total
> are used for the encoding and (if it works) using more robust settings
> later for content stored in the tree below the alias leaves the alias
> itself with the original (less robust) encoding settings.

Aliases are just directories (which are usually mutable files), so the
question is really about the relationship between the k/N (needed/total)
values used for a directory, and the values used for (immutable) files
stored underneath.

There is no such relationship :). Whatever your tahoe.cfg contained at
startup time will be used for all uploads (both mutable and immutable).
Repair will use the k/N values from the filecap.

So yes, changing the encoding settings and uploading files underneath an
alias will leave the aliased directory with it's original encoding
settings. Since k/N are embedded in the filecap, there is no way to
change the encoding parameters of an existing file: you'd need to
re-upload it with different settings, and you'll get a different
filecap.

> 3/ If I did get it right above, I guess it's better to create a new
> alias with the new settings and move content with old encodings to the
> new alias (waiting for them to be deleted then garbage collected in my
> case).

Yup:

 tahoe create-alias new
 tahoe cp -r old: new:
 # then do 'grep old ~/.tahoe/private/aliases' and delete that line

> Is it possible to create a link to the old alias in the tree below to
> have only one tree to maintain?

If I understand what you're asking, then yes. If the unix equivalent
would be:

 cd new
 ln -s ~/old ./old

then the Tahoe operation is to use 'tahoe list-aliases' to find the
dircap for the old aliase, then use 'tahoe webopen new:' to open a
web-browser to the new directory, then use that in-browser WUI to paste
the dircap into the "Add a link to a file or directory which is already
in Tahoe-LAFS" form. (there's no CLI command for this, unfortunately).
The result will be like a hardlink to the old directory. Unlink unix,
Tahoe handles directory cycles pretty well: the filesystem is a general
directed graph, not just a tree.

> I thought about creating a directory manually forcing it to use the
> same capabilities than the alias (didn't look it up in the doc yet) or
> is there another simple way to move the data without reencoding the
> files?

I think I lost you there. But two tidbits that might be relevant. The
first is that you can't force the system to give you a particular
filecap or dircap (capability string) for an upload or mkdir operation:
it's effectively random. The second is that it's easy to move files and
directories around (they're all referenced by their caps.. no actual
data motion happens, just pointer shuffling). But you can't change the
encoding of a file: instead you have to upload the same contents with a
different k/N, and you'll get a new filecap.

hope that helps,
 -Brian