[tahoe-dev] [tahoe-lafs] #467: change peer-selection to allow introducerless explicit serverlist, alternative backends

Justin Stottlemyer justin.h.stottlemyer at gmail.com
Sat Feb 20 04:43:21 UTC 2010

I could see in my case a (similar style) need. I have a concern that while
running a private grid with dense storage systems containing 36-45 nodes.
that I could end up with enough shares on a single system that if that
system were down I could have a failure to retrieve data until that box was
back up and running.  A slightly different use case, but it may be able to
use a similar structure.

-- Justin

On Fri, Feb 19, 2010 at 8:26 PM, tahoe-lafs <trac at allmydata.org> wrote:

> #467: change peer-selection to allow introducerless explicit serverlist,
> alternative backends
> ---------------------------------------+------------------------------------
>  Reporter:  warner                     |           Owner:
>     Type:  enhancement                |          Status:  new
>  Priority:  major                      |       Milestone:  undecided
> Component:  code-peerselection         |         Version:  1.1.0
>  Keywords:  availability preservation  |   Launchpad_bug:
> ---------------------------------------+------------------------------------
> Comment(by zooko):
>  USSJoin is considering using Tahoe-LAFS as the bulk storage for his
>  gargoyle (as in Snow Crash) rig. He wants to be able to use it in caching
>  mode for when he is offline, so that his files which are in Tahoe-LAFS are
>  retrievable when off-line (because at least {{{K}}} shares of each file
>  are stored in the local Tahoe-LAFS server which is on his person).
>  I think he is wrong to want this! I think that caching should be done
>  outside of Tahoe-LAFS instead of inside of it, such as by not running a
>  Tahoe-LAFS server on his on-person rig at all but instead having a local
>  filesystem on there with explicitly-managed local copies of some of his
>  files.
>  However, the great thing about this ticket is that it enables people to do
>  things with Tahoe-LAFS that I don't necessarily think are a good idea. :-)
>  In particular, USSJoin could specify that each file which is uploaded has
>  to have at least K shares going to the one storage server which runs on
>  his local rig.
> --
> Ticket URL: <http://allmydata.org/trac/tahoe/ticket/467#comment:5>
> tahoe-lafs <http://allmydata.org>
> secure decentralized file storage grid
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at allmydata.org
> http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20100219/d12a7edb/attachment.html>

More information about the tahoe-dev mailing list