On Fri, Nov 7, 2014 at 4:17 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
> On 7 November 2014 02:44, Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
> wrote:
> > [This goes mostly to Ivan but the last part goes to Brane. Don't want to
> > sub-thread here.]
> >
> > On Thu, Nov 6, 2014 at 8:24 PM, Branko Čibej <brane_at_wandisco.com> wrote:
> >>
> >> On 06.11.2014 20:03, ivan_at_apache.org wrote:
> >> > Author: ivan
> >> > Date: Thu Nov 6 19:03:31 2014
> >> > New Revision: 1637184
> >> >
> >> > URL: http://svn.apache.org/r1637184
> >> > Log:
> >> > Make FSFSv7 repositories always use consistent addressing mode,
> instead
> >> > of
> >> > saving revision number from which logical addressing was enabled.
> >>
> >>
> >> Congrats on finally doing something concrete about FSFSv7.
> >
> >
> > +1 on the meta point.
> >
> > It looks a bit like a rushed commit, though (partly corrected by the
> > r1637186 commit). Documentation update is missing:
> >
> > structure:Filesystem format options
> > * update addressing mode description
> >
> > fs_fs.c:read_format()
> > * update docstring
> >
> > transaction.c:store_l2p_index_entry()
> > * update docstring
> >
> Thanks for review! I've fixed these typos in r1637330.
>
Thank you! I added a minor follow-up in r1637393.
Getting docs consistent is tedious.
> > I'm -.5 on removing the "mixed addressing" feature for exactly the
> > points made by Brane.
>
> I'm going to reply on your comments a bit later.
>
> > Brane, you might confuse this with 'svnadmin pack'. The thing
> > about upgrade is that we have a nasty FS API limitation that
> > is a missing concept of read sessions / locks.
>
> But I want to comment this one particular and important thing right
> now. Please do not treat all things that are unclear for you as
> a "nasty limitations".
>
I think it is important to call limitations limitations.
That does not imply that they are a bad as such
nor that they are unjustified. But they will prevent
us from doing something that we would like to do.
The "nasty" bit is that svn_fs_t is a bit of a misnomer.
It's actually more of a session pointer, maintaining
an independent view onto the FS. It lead to an
implementation where no object has the clear
responsibility of managing the FS singleton which
could mediate between the FS and session. IOW,
nothing explicitly manages "the repository".
> Missing of read sessions/locks is a core (and pretty successful)
> design decision of the FSFS. Quoting original Greg Hudson email
> in 2004 [1]:
> [[[
> * Despite the above, scalability may be better, because there are no
> read-locks and no potential interference between readers and other
> readers, or between readers and writers.
> ]]]
>
That is all good an well, yet pure conjecture. A simple
fopen, no different from what we do today many times
per session, may well be enough.
> This solution is perfectly works for ten (!) years.
It imposes scalability restrictions in other dimensions.
I count that under things we learned over time just like
we learned that merging is the hard part once we solved
the branching problem.
One limitation is that we can't take a repository off-line
for maintenance. It always requires a server restart
that may or may not result in a disruption of service
for everybody on *other* repositories.
A related problem is that you can't safely update the
configuration, e.g. authz, without restarting the server.
Both make administration hard on servers with many
active repositories on them.
> If you want to change
> (or beat) this approach, please do this in the experimental FSX
> format.
That is the plan. The change will probably involve FSX,
an FS2 API and a separated repository server.
> All other 'revolutionary' FSFS-related performance improvements
> should be also implemented there.
>
Well, that is why there is FSX in the first place. All the
actually "revolutionary" changes will happen there leaving
little overlap with FSFS. So, without the split, it would be
two widely separate bodies of code pretending to be one.
-- Stefan^2.
Received on 2014-11-13 17:05:59 CET