[tahoe-dev] Primary shares

[David-Sarah Hopwood]

On 2010-10-31 05:55, Shu Lin wrote:
> Hi,
> 
> There are deployment scenarios that several server mirroring each other,
> everyone has the full content of file system instead of pieces of files in
> shares. In these case, erasure coding might be unnecessary. I learned I can
> avoid erasure coding by using primary shares from changeset 3300,
> http://tahoe-lafs.org/trac/tahoe-lafs/changeset/3300/trunk.

Be careful using changeset messages as documentation; that's not what they're
intended for. For a start, the history is immutable, so errors in changeset
messages cannot be corrected. Also they assume knowledge of the
implementation, they don't usually explain the terms they use, and they
may refer to behaviour that has changed since the message was written.

> But, I could not find any node configuration page describing how to configure
> a node in that way.

> My understanding of primary share is a server which saves the full content
> of a file instead of piece of shares. Is that correct?

No. What that changeset message means by a "primary share", is one of the
first k shares of a given file. It is *slightly* more efficient to
encode/decode a primary share, because it is just a slice of the (encrypted)
file data.

However, you should think of this as just an implementation detail of the
erasure coding algorithm. To only use primary shares, you would have to
set k = N, which is not what you want (it would provide no redundancy).

To use only replication, set k to 1. Replication is a special case of
erasure coding.

(k above is the 'shares.needed' setting in tahoe.cfg, and N is the
'shares.total' setting.)

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20101031/1d0939d2/attachment.pgp>