[tahoe-dev] [tahoe-lafs] #869: Allow Tahoe filesystem to be run over a different key-value-store / DHT implementation

[tahoe-lafs]

#869: Allow Tahoe filesystem to be run over a different key-value-store / DHT
implementation
-----------------------------+----------------------------------------------
     Reporter:  davidsarah   |       Owner:  nobody                                                           
         Type:  enhancement  |      Status:  new                                                              
     Priority:  major        |   Milestone:  undecided                                                        
    Component:  unknown      |     Version:  1.5.0                                                            
   Resolution:               |    Keywords:  scalability performance availability newcaps docs anti-censorship
Launchpad Bug:               |  
-----------------------------+----------------------------------------------

Comment (by davidsarah):

 Replying to [comment:1 warner]:
 > ... This ties in closely to the docs outline that we wrote up
 > (but which we haven't finished by writing the actual documentation it
 calls
 > for): source:docs/specifications/outline.txt .

 Now [source:docs/specifications/outline.rst].

 >  * on the other hand, the shared-secret slot-modify authority is nice
 and
 >    simple, is fast and easy for the server to verify (meaning a slow
 server
 >    can still handle lots of traffic), and doesn't require the server to
 have
 >    detailed knowledge of the share layout (which decouples server
 version
 >    from client version). Most of the schemes we've considered for
 >    signed-message slot-modify operations require the servers to verify
 the
 >    proposed new slot contents thoroughly, making it harder to deploy new
 >    share types without simultaneously upgrading all the servers.

 As far as performance is concerned, signature ''verification'' is fast
 with RSA, ECDSA or hash-based signatures (and the hashing can be done
 incrementally as the share is received, so no significant increase in
 latency). I don't think this is likely to be a performance bottleneck.

 The compatibility impact of changes in the mutable share format would be
 that an older server is not able to accept mutable shares of the newer
 version from a newer client. The newer client can still store shares of
 the older version on that server. Grids with a mixture of server and
 client versions (and old shares) will still work, subject to that
 limitation.

 On the other hand, suppose that the reason for the change is migration to
 a new signing algorithm to fix a security flaw. In that case, a given
 client can't expect any improvements in security until all servers have
 upgraded, then all shares are migrated to the new format (probably as part
 of rebalancing), then that client has been upgraded to stop accepting the
 old format. Relative to the current scheme where servers don't need to be
 upgraded because they are unaware of the signing algorithm, there is
 indeed a significant disadvantage. At least the grid can continue
 operating through the upgrade, though.

 The initial switch from write-enablers to share verification also requires
 upgrading all servers on a grid -- but if you're doing this to support a
 different DHT, then that would have to be effectively a new grid, which
 would just start with servers of the required version. The same caps could
 potentially be kept when migrating files from one grid to another, as long
 as the cap format has not changed incompatibly.

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/869#comment:6>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage