Uploaded image for project: 'Subversion'
  1. Subversion
  2. SVN-4577

Read error with nodes whose DELTA chain starts with a PLAIN rep



    • Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 1.8.x
    • ---
    • libsvn_fs_fs
    • None


      Read error with nodes whose DELTA chain starts with a PLAIN rep
      This issue is for documentation only. It has originally been reported here:
      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.




            stefan2 Stefan Fuhrmann
            stefan2 Stefan Fuhrmann
            0 Vote for this issue
            0 Start watching this issue