[tahoe-lafs-trac-stream] [tahoe-lafs] #393: mutable: implement MDMF

[tahoe-lafs]

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

Comment (by warner):

 I noticed another curiosity, in the !ServermapUpdater(update_range=) code
 (which fetches the segments that live on the two ends of the span being
 modified, which are only partially changed and thus need to copy the old
 contents). There are lots of situations which cause {{{start_segment}}}
 and {{{end_segment}}} to be the same, such as modifying a small range in
 the middle of a segment. In those cases, it looks like
 {{{Servermapupdater._got_results}}} will request the same data twice, and
 the cache in {{{MDMFSlotReadProxy}}} doesn't help unless the second
 request arrives after the first has been resolved. So I think we're
 fetching twice as much data as we need to.

 Also, if the span we're replacing exactly aligns with the start or end of
 a segment (which is very common if we're modifying the start or end of the
 file), then we don't need to fetch the old segment at all. I think (but
 haven't confirmed) that the current code always fetches two segments, even
 in the aligned case.

 If so, then after we land this stuff, let's do a cleanup pass. I think the
 {{{update_range=}}} code could changed from thinking about start/end
 segments to just getting a set of segnums, of length 0 (if the span aligns
 on both ends), length 1 (if only one end is aligned, or if the span falls
 within a single segment) or length 2 (if the two ends of the span fall in
 different segments). Then the {{{fetch_update_data}}} code can make
 exactly as many {{{get_block_and_salt}}} calls as necessary, instead of
 always making 2.

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