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