Daniel Shahaf wrote:
> Julian Foad wrote on Fri, Mar 23, 2018 at 17:30:14 +0000:
>> Nathan Hartman wrote:
>>> It just occurred to me that because correct operation of the rep-
>>> cache is so crucial to the reliability of the system, perhaps it
>>> would be a good idea to make sure the rep-cache does not contain too-
>>> new revs as a sanity check during normal commits?
>>
>> Discussed before: thread "FSFS rep-cache validation", 2014-01-22,
>>
>> https://svn.haxx.se/dev/archive-2014-01/0086.shtml
>> https://lists.apache.org/thread.html/832c0367adfee2208e609dc54048447651ab66cb12876ddbaa0c8fbd@1390425594@%3Cdev.subversion.apache.org%3E
>>
>> No conclusion that time. Seems like a good idea. Want to make it happen? :-)
>
> We already check rep-cache references before using them:
[...]
> subversion/libsvn_fs_fs/rep-cache.c:314: (apr_err=SVN_ERR_FS_CORRUPT)
> svnmucc: E160004: Checksum '005ed0b0c9e3ea5d84be64386aadc786164013d8' in rep-cache is beyond HEAD
Detecting when a cache hit is beyond HEAD is not the same, and not
sufficient.
> While we're at it, do we check, before using a rep-cache reference, that the
> revision:offset coordinates we obtained do in fact refer to a representation?
> I.e., do we seek() to that position and ensure that we see, at the very least,
> either "DELTA" or "PLAIN"?
That's not sufficient either, as you admit ("at the very least"), so why
choose that particular level of probability-increasing rather than
definite methods such as those mentioned in the discussion linked above?
- Julian
> Perhaps the call to svn_fs_fs__check_rep_reference()
> (in transaction.c:2328) does that, but I don't fully understand that function.
> (For starters, why does it take a different codepath for logical addressing
> than for physical addressing?)
Received on 2018-03-26 09:07:55 CEST