[tahoe-dev] Change the parameters(K-N) when using
Brian Warner
warner at lothar.com
Mon Feb 28 13:11:43 PST 2011
On 2/28/11 11:06 AM, David-Sarah Hopwood wrote:
> On 2011-02-28 18:41, Jiawei Jiang wrote:
>>
>> Assume that I have a grid with 10 servers with 3-6, and there are
>> already files stored. With the scale growth of the grid, maybe to 100
>> nodes or even 1000, is there possibility to change the K-N parameter
>> to a larger one (for example 20-40) without damaging the existing
>> files. Another assumption would only customers have the encryption
>> key.
>>
>> In other words, is that possible to have two different settings of
>> parameters on the same grid simultaneously.
>
> There is no problem with that. The parameters for each file/directory
> are set according to the tahoe.cfg of the uploading gateway at the
> time of the upload.
Just to clarify: each Tahoe file/directory object has a separate set of
encoding parameters, stored in the filecap (as well as inside the
shares). The downloader looks at those recorded parameters to figure out
how to reconstruct the file.
Each time a file is uploaded, the settings in tahoe.cfg are used to
encode the file and then copied into the filecap+shares: each file can
use different parameters, and all downloaders can handle them. So
there's no such thing as "grid-wide encoding parameters".
We tend to lean towards putting more information in the shares and
filecaps, rather than rely upon an algorithm to deduce those values,
since that improves forward-compatibility. For example, the "segment
size" (the amount of data in each erasure-coded/hashed segment) is
stored in the share's UEB, even though the uploader always calculates it
from the overall filesize and 'k'. The downloader pays attention to the
stored value, not the equation, so that we have the flexibility to
change the uploader's behavior in the future without breaking
downloaders or requiring a "flag day" to upgrade both sides at the same
time.
cheers,
-Brian
More information about the tahoe-dev
mailing list