[prev in list] [next in list] [prev in thread] [next in thread] 

List:       subversion-issues
Subject:    [Issue 4577] New - Read error with nodes whose DELTA chain starts with a PLAIN rep
From:       sf () tigris ! org
Date:       2015-04-30 4:47:04
Message-ID: iz4577 () subversion ! tigris ! org
[Download RAW message or body]

http://subversion.tigris.org/issues/show_bug.cgi?id=4577
                 Issue #|4577
                 Summary|Read error with nodes whose DELTA chain starts with a 
                        |PLAIN rep
               Component|subversion
                 Version|1.8.x
                Platform|All
                     URL|
              OS/Version|All
                  Status|NEW
       Status whiteboard|
                Keywords|
              Resolution|
              Issue type|DEFECT
                Priority|P3
            Subcomponent|libsvn_fs_fs
             Assigned to|sf
             Reported by|sf






------- Additional comments from sf@tigris.org Wed Apr 29 21:47:03 -0700 2015 -------
Read error with nodes whose DELTA chain starts with a PLAIN rep

This issue is for documentation only. It has originally been reported here:
http://mail-archives.apache.org/mod_mbox/subversion-dev/201504.mbox/%3CCAC9r9zaWxkUDZDVc%2B3et%3DicjzcVAFqSvf5wrC8UwmxtwYyzpvg%40mail.gmail.com%3E


Revision 1676667 fixes it.  Affected are the SVN releases 1.8.0 through
1.8.13 as well as the 1.9.0rc1.  1.7.x and earlier work correctly.

The problem itself is not limited to directories but can occur with any
representation.  However, directories are the most likely ones to meet
the following trigger criteria:

1. The delta chain must start with a PLAIN rep.

   This is always true for the root folder within the first 1000 revs
   even if directory deltification has been enabled from the beginning.
   Other directories as well as properties fulfill this if deltification
   was enabled after the original rep for that node got committed.

   File contents is very unlikely to ever be a PLAIN rep - unless the
   fulltext matches an existing serialized hash *and* rep sharing has
   been enabled. The most plausible candidate would be 'END\n'.

   Note that the 'max-deltification-walk' option puts a cap on the length
   of any delta chain.  After 1024 changes to a subtree after enabling
   deltification, for instance, the base directory will no longer use
   the PLAIN rep as a base for its delta chain.

2. At least two DELTA reps must follow in that chain and the last one
   must not reuse any substrings from its predecessor, i.e. be all new
   contents.  It is always the last one because the bug prevents future
   commits to that node rep.

   "All new contents" can happen the obvious way but it can also be
   the byproduct of the skip-delta scheme.  If the history spanned by
   a single delta is long enough, txdelta may not find any matching
   sub-strings any more.  This is more likely to happen to directories
   (all entries touched) and all-binary files (e.g. compressed data).

   Note that this criterion is being evaluated once per delta window,
   i.e. once every 100 kByte chunk in case of a longer rep.

3. The fulltext of the previous rep in the chain must be long enough
   to result in a read beyond the rev / pack file.

   While 1. and 2. are enough to trigger the bug, this 3rd condition
   must be met to actually cause an I/O error instead of a mere
   inefficiency.  The actual condition is as follows:

   The second-last rep in the delta (i.e. immediately before the "all
   new" one) has a fulltext SIZE.  The on-disk size will often be much
   less due to deltification an compression.  The PLAIN rep at the
   start of the delta chain has an OFFSET in its respective rev / pack
   file.  If OFFSET + SIZE exceed the length of that rev / pack file,
   the I/O error gets triggered.

   So, again directories are more susceptible in format 6 and earlier
   than file contents and properties because they are being stored
   closer to the end of the rev file.  Packing reduces the problem
   and may actually "fix" existing occurrences.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=463&dsMessageId=3115123

To unsubscribe from this discussion, e-mail: \
[issues-unsubscribe@subversion.tigris.org].


[prev in list] [next in list] [prev in thread] [next in thread]