[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 kevan):

 Replying to [comment:80 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.

 I think you're right on that; I don't remember designing for either of
 those scenarios (I was apparently firmly in the two-segment mindset when I
 wrote that), and a quick glance at the code doesn't reveal that they're
 given special consideration.

 > 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.

 Sounds good.

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