On Thu, Oct 18, 2012 at 1:57 AM, Daniel Shahaf <d.s_at_daniel.shahaf.name>wrote:
> 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.)
>
Did you read and *understand* the code?
What exactly will happen after the 10s timeout?
> 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.)
>
Still a lot of documentation to done for sure.
And it is the right time to that (1.8 stabilization
starting soon-ish).
> 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.
>
No need to go off on a hyperbole. Raise your
concerns in a factual way and hold off meta-
discussion until after those facts got confirmed.
Still appreciate the review, though. And, yes, the
coded logic may contain holes and I'm absolutely
willing to work them out, discuss ways to address
them or even to remove large chunks of work if
that turns out the be the right thing to do.
-- Stefan^2.
--
*
Join us this October at Subversion Live
2012<http://www.wandisco.com/svn-live-2012>
for two days of best practice SVN training, networking, live demos,
committer meet and greet, and more! Space is limited, so get signed up
today<http://www.wandisco.com/svn-live-2012>
!
*
Received on 2012-10-18 02:26:45 CEST