[tahoe-lafs-trac-stream] [tahoe-lafs] #1657: Sneakernet grid scenario

tahoe-lafs trac at tahoe-lafs.org
Fri Jan 20 21:01:55 UTC 2012


#1657: Sneakernet grid scenario
-----------------------------+-----------------------
     Reporter:  amontero     |      Owner:  nobody
         Type:  enhancement  |     Status:  new
     Priority:  major        |  Milestone:  undecided
    Component:  unknown      |    Version:  1.8.3
   Resolution:               |   Keywords:
Launchpad Bug:               |
-----------------------------+-----------------------

Comment (by amontero):

 Replying to [comment:3 davidsarah]:
 > > I want each member to hold x+1 shares, where x is enough for the file
 to be readable from that single node.
 >
 > How does this improve on replication (i.e. k = 1)? Replication is
 simpler.

 Hi David.

 As most of time the nodes will be isolated, the default N/happy/k of
 3/7/10 doesn't works, so by now I'm using 3/1/10. Using 3/7 just because
 it is the recommended setting in the docs and I think (maybe I'm wrong)
 they're a fine enough settings for my goals.

 Do you mean setting 1/1/10? That would be a worst case of space waste as I
 understand. I made the test, just to be sure, and it is a tenfold increase
 in space requirements when uploading. The grid members have to do their
 backups isolated and replicate to other nodes when they rendez-vous.

 Or do you mean some other values for N/k? You made me think about it, and
 since my goal seems a replication (with LAFS privacy) setup it may work.
 But I can see no difference apart from the expansion factor in let's say
 1/1/2. I'm aware that, as shares would be named either 0 or 1, that would
 make it somewhat simpler to script management, but the annoyances when
 repairing would stand.

 A downside I can think of with less shares is losing the ability to hold
 an "extra share more than needed" at a reasonable space cost. I would like
 to keep it, just to be covered against "bit flippings" since I'll be using
 USB external drives as nodes also. However, that is secondary and I can
 give up that ability if thus makes things easier.

 I've set up a testbed with 1/1/2 and as long as !#1 and !#2 it makes
 little difference when managing the grid nodes, so I would like to ask you
 help me understand better what N/k parameters do you mean.


 Thanks.

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1657#comment:5>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage


More information about the tahoe-lafs-trac-stream mailing list