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

[tahoe-lafs]

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

Comment (by kevan):

 Replying to [comment:151 davidsarah]:
 > If I understand correctly, {{{self.datalength}}} is the length that
 we're going to update. Because of the issue in comment:38, we don't do
 partial updates yet, which might explain why this code sets
 {{{self.datalength}}} to at least {{{self._node.get_size()}}} (the
 previous size of the file). However, I don't see how this works when
 {{{offset > 0}}}. If ({{{offset}}}, {{{self.datalength}}}) is supposed to
 be the offset and length of the share contents we're going to write, then
 I would expect:
 > {{{
 >         self.datalength = max(self._node.get_size(), offset +
 data.get_size())
 >         offset = 0
 > }}}

 {{{self.datalength}}} is perhaps confusingly named -- it is the size of
 the
 MDMF file if the update operation completes successfully, and is used to
 calculate
 segment boundaries and to initialize the tail segment encoder (if the
 tail segment differs in length from the other segments).

 {{{self.datalength}}} should be calculated as in your first example.
 Actually, due
 to a bug in {{{TransformingUploadable}}}, it is calculated that way -- for
 whatever reason, I wrote {{{TransformingUploadable.get_size}}} to return
 {{{offset + get_size}}}. That's inconsistent with
 {{{MutableFileHandle.get_size}}}, and not what I would expect a method
 named {{{get_size}}} to do; I'll fix that. AFAICT, the update method works
 despite relying on buggy behavior because it is always passed a
 {{{TransformingUploadable}}} -- full-file updates use
 {{{MutableFileHandles}}} or
 {{{MutableData}}} instances.

 As an aside, we still do partial updates -- we just do them in such a
 way as to ensure that all of the changes are written at once, in that we
 retain all of the updated segments in memory as write vectors, then send
 those all at once to the storage server. So, IIUC, it isn't necessarily
 correct to just set offset to zero.

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