[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [RFC] FSFS filesystem options (long, sorry)

From: Malcolm Rowe <malcolm-svn-dev_at_farside.org.uk>
Date: 2007-03-05 19:12:38 CET

On Mon, Mar 05, 2007 at 07:30:55AM -0800, Karl Fogel wrote:
> > - I don't have the information to choose the most efficient size of
> > directory. I could choose a reasonable value (4096? 10000?) and
> > that'd be okay...
> Can we get that information?

No, but I can make a reasonable guess.

> > - ... but if I need per-filesystem options for the local-txn-storage
> > idea anyway...
> > - ... then I could punt on making a decision and make the user specify
> > the number of files is they want sharded storage...
> I understand, but when we punt on making that decision, we're forcing
> the user to make it.

Good point. (Mattias Engdegård also makes the point elsethread that
there is unlikely to be a difference in practice between the two fs
layouts for any tree-based OS filesystem, and on reflection I mostly

So would this need to be a user-configurable knob at all, then?

> > - ... and if they don't know they want it, they don't get it, so our
> > repositories are compatible with 1.4 by default.
> Why do we need compatibility with 1.4 clients for file:// by default?
> (We're only talking about file:// here, as I understand it.)
> Oh, because clients might be running on other servers and accessing
> the repository via NFS. Hmmm. But we've had incompatible upgrades
> before: in the working copy format, at least, and perhaps also in the
> repository format (I can't recall exactly, just think we've done it).

Sure, we did it in 1.4, hence the --pre-1.4-compatible flag.

Maybe we should just do the same in 1.5?

> > I guess the things holding me back from making it the default are:
> > - it's inelegant if you have a decent filesystem.
> > - we still need to support both methods, it's just a metter of where
> > the switch is located.
> > - I can't really set a policy for the right number of files myself.
> > - I quite like the idea of making it opt-in rather than opt-out, and
> > of reusing the options mechanism to do so.
> But the result would be that the repositories we create by default are
> not as scalable as they could be. Absent the compatibility concerns,
> is there any reason why we wouldn't make the new way the default?

"It's not as pretty". I think that's really what it comes down to, and
it's a pretty poor reason.


  • application/pgp-signature attachment: stored
Received on Mon Mar 5 19:12:54 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.