[tahoe-dev] server selection

Troy Benjegerdes hozer at hozed.org
Wed Apr 22 19:35:40 UTC 2009


On Wed, Apr 22, 2009 at 01:11:31PM -0600, Shawn Willden wrote:
> On Wednesday 22 April 2009 12:55:24 pm Troy Benjegerdes wrote:
> > On Wed, Apr 22, 2009 at 10:34:09AM -0600, Shawn Willden wrote:
> > > On Tuesday 21 April 2009 02:50:41 pm Brian Warner wrote:
> > > > We picked the pseudo-random permuted serverlist to get these
> > > > properties. I'd love to be able to get stronger diversity among hosts,
> > > > racks, or data centers, but I don't yet know how to get that '''and'''
> > > > get the properties listed above, while keeping the filecaps small.
> > >
> > > Well, there's always the old CS aphorism:  "There is no problem in
> > > computing that cannot be solved (or created) by another layer of
> > > indirection".
> > >
> > > What about using the permuted list to find a set of servers that know the
> > > set of servers that hold the shares?  The share location list deployed to
> > > the first n servers in the permuted server list would be small, so it
> > > wouldn't impose a large burden either on servers storing the list or on
> > > clients uploading the list, and it would allow complete freedom to place
> > > shares wherever the client wants them.
> >
> > Would there be a reasonable way to use DNS SRV records to do this? For
> > example, 'username.livejournal.com' is quite a conventient way to map a
> > DNS name to a particular set of servers.
> 
> That would work if you wanted to use the same set of servers for all of your 
> files.  That has negative impacts on performance, reliability and storage 
> balancing.

My vote is create a layer of indirection like the AFS volume location
database servers. So from nothing, a client looks up DNS SRV records to
find a couple of 'serverlist providers' (otherwise known as metadata
servers), then proceeds to connect and go on with life getting it's files.

It's quite possible I'm missing something really important here.

I'm still trying to wrap my brain around how having erasure codes makes
a lot of the hard problems other distributed filesystems have to solve a
lot easier.



More information about the tahoe-dev mailing list