subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Foad <>
Subject Re: verify_as_revision_before_current_plus_plus() on a production repo?
Date Tue, 31 Jan 2017 10:22:06 GMT
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

View raw message