#1092: shares.happy is the wrong name of the measure
--------------------------------+-------------------------------------------
Reporter: zooko | Owner: warner
Type: defect | Status: new
Priority: minor | Milestone: eventually
Component: code-nodeadmin | Version: 1.7.0
Resolution: | Keywords: usability upload
Launchpad Bug: |
--------------------------------+-------------------------------------------
Comment (by gdt):
-1 on the servers.happy.
If we're going to change, I think it would be good to also pick a
different word than happy. There's an important concept lurking under a
seemingly flippant word.
bWhat's really going on is that this single variable is a rough first cut
at ensuring that there is adequate redundancy based on some policy and
some knowledge of physical and administrative correlation among servers.
I see the 3/7/10 values as very closely linked, and changing shares to
servers makes that less clear.
I do agree that shares.happy gives the wrong impression. So I'll suggest
"shares.independent", with the meaning being "the minimum number of shares
that must be on independent servers". I think that's what is meant, and
this keeps the parallelism of shares.* and clarifies this variable. One
could have shares.independent and shares.independent-target, but I'm not
sure independent-target needs to be different from total.
The current ordering gives the impression that shares.needed are
shares.total are more independent than they are. So perhaps
"shares.coding = (3, 10)" would be better than two variables. (I am
under the impression that I can't just set shares.total to 12 and
reconstruct those missing sh10, sh11 without having to recode the entire
file; if I'm confused on that point this paragraph is invalid.)
3/7/10 seems reasonable, and I've been using 2/5/7. I don't think it
makes sense to talk about the right value of
shares.independent/shares.happy without considering the whole 3-tuple.
--
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1092#comment:2>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage
_______________________________________________
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
