[tahoe-dev] [tahoe-lafs] #393: mutable: implement MDMF

[tahoe-lafs]

#393: mutable: implement MDMF
------------------------------+---------------------------------------------
     Reporter:  warner        |       Owner:  kevan                                                      
         Type:  enhancement   |      Status:  assigned                                                   
     Priority:  major         |   Milestone:  1.8β                                                       
    Component:  code-mutable  |     Version:  1.0.0                                                      
   Resolution:                |    Keywords:  newcaps performance random-access privacy gsoc mdmf mutable
Launchpad Bug:                |  
------------------------------+---------------------------------------------

Comment (by kevan):

 attachment:393status26.dpatch fixes more bugs in the update behavior; all
 of the tests I wrote on Monday now pass, though I'm going to write more
 tests tomorrow to see if some edge cases that have been bothering me are
 going to be problematic. After that, it'll be time to figure out a way to
 integrate update into the rest of Tahoe-LAFS; into the WebAPI, at least.

 It also occurs to me that we could get rid of the re-encoding update case
 (where we need to re-encode and upload the file because the block hash
 tree grows, shifting everything else forward into where the block and salt
 data was before the update) by juggling the layout of MDMF files. If we
 put the block and salt data after the offsets and signature but before the
 integrity data, then we no longer have to re-upload the file when the
 block hash tree grows larger than it was originally, since there wouldn't
 be any share data to be upset beyond the block hash tree. The disadvantage
 of this approach is that reading the first 1000 or so bytes of an MDMF
 file will have a smaller chance of fetching the encrypted private key and
 verification key, which would make the servermap update step use more
 roundtrips, but this could be addressed by putting those (and whatever
 else the servermap update step is likely to want) before the blocks and
 salts. We'd probably be just fine if we stuck only the block and share
 hash trees after the block and salt data, since that gets re-written on an
 update anyway. Then we'd have O(change_size) updates in general without
 any real regression with what is there now.

 If testing goes well tomorrow, I'll start working on that.

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