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
agree).
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.
Regards,
Malcolm
- application/pgp-signature attachment: stored
Received on Mon Mar 5 19:12:54 2007