Daniel, thanks for your comments.
Daniel Shahaf wrote:
> Julian Foad wrote on Mon, Jan 30, 2017 at 21:40:00 +0000:
>> it is a little "tricky": in particular, it opens a second FS instance and
>> fakes the "youngest revision seen" field and then relies on this FS instance
>> never reading the "current" file
>
> Right: if some code refreshes youngest_rev_cache (by open()ing
> 'current', reading a value from it, and setting youngest_rev_cache to
> that value), that will cause root->rev to be "newer than youngest".
>
> I think the 'verify' code already has to deal with this possibility,
> since 'recover' can backdate 'current' in the following situation:
> .
> 1. svn_fs.h consumer opens an svn_fs_root_t for r42
> 2. invisible monkeys delete db/revs/0/42 and db/current
> 3. admin runs 'svnadmin recover', which regenerates 'current' as 41
> 4. svn_fs.h consumer calls verify() on the root it had opened earlier
I don't buy this. verify_root() is not required to successfully verify
r42 in this scenario.
> Moreover, the 'verify' code is inherently the place where violated
> invariants are least likely to cause trouble, and it's read-only.
> Therefore, while a bug might cause a false positive verification error
> that rejects a commit, I don't see any worse outcome. (If there's
> a failure mode here that I overlooked, it's most likely to be in the f7
> code, since I haven't worked much with those parts of fsfs.)
>
> All that said, I agree that checking after the _verify_root() call that
> root->rev and youngest_rev_cache haven't changed would be an improvement.
[...]
>
>> nor using anything that would have been done post-commit.
>
> That's a good point: the svn_fs_fs__verify_root() must not add any
> permanent references to the revision it thinks is youngest — e.g., it
> must not add reps it traverses to rep-cache.db. That's true today but
> not necessarily true forever.
Interesting observation. It would be good the verify could use a
read-only FS instance, but I don't think we have such a mechanism.
I meant the opposite direction: a successful commit does some things
post-commit (e.g. remove the txn directory, update the fulltext cache,
update the rep cache) and this verify must not assume any of those
things have been done already.
> I also wonder if having verify_as_revision_before_current_plus_plus()
> run in a child process would gain anything.
>
>> verify_as_revision_before_current_plus_plus() is currently compiled in to
>> debug builds but not to release builds. We can say therefore it gets
>> reasonable coverage in test suite runs but has had little or no real-world
>> testing.
>
> Indeed. How about enabling that function in the alpha1 release so we
> can get some more feedback about it?
I like that idea: it seems like entirely appropriate behaviour for an
alpha or beta release, and we'd probably get no direct feedback and this
would be a good sign that it's working ok.
- Julian
Received on 2017-01-31 11:22:12 CET