Branko Čibej wrote on Mon, Oct 15, 2012 at 23:51:43 -0400:
> On 15.10.2012 17:14, Stefan Fuhrmann wrote:
> > However, if you have a long-running process like a server, that race
> > condition extends now extends over its whole lifetime. I.e. once a
> > revprop got read, any change to its value by a pre-1.8 tool may never
> > get detected.
>
> Ouch. This seems wrong. I'd understand a design like this if the
> long-running server were the only process accessing the repository, but
> that has never been the case in Subversion. In this case, a cache that
> can't detect out-of-band changes to the canonical dataset isn't very useful.
Another questionable part of the revprop cache: the
ATOMIC_REVPROP_TIMEOUT mechanism in fs_fs.c. (Basically, the code
assumes that if another process is rewriting a revprops file, it will
always finish within 10 seconds.)
1. It's not documented. (And by that I mean a few paragraphs explaining
the algorithm; not docstrings to individual functions, nor documentation
of the on-disk format.)
2. It's another instance of breaking FSFS discipline --- if you do
something that we think is very rare, your filesystem's behaviour may
lose that 'correctness' property. FSFS does not have "correctness
except in rare situations" anywhere else --- and 1.6 and 1.7 features
had taken some trouble to make sure that had remained the case.
The problem raised earlier in this thread is that a 1.8 server might not
notice changes made by a 1.7 svnadmin. The problem I have in mind here
is that if a writer _does_ happen to take more than 10 seconds, the
first process will miss the second process's changes.
In short, I believe the FSFS code in 1.8.x sacrifices Subversion's
unconditional correctness promises on the altar of performance.
Received on 2012-10-18 01:57:40 CEST