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

Re: Subdirectories for db/revs/* on fsfs backend

From: Mark Benedetto King <mbk_at_lowlatency.com>
Date: 2004-07-21 00:44:23 CEST

On Tue, Jul 20, 2004 at 06:31:09PM -0400, Garrett Rooney wrote:
> Mark Benedetto King wrote:
>
> >On Wed, Jul 21, 2004 at 12:05:47AM +0200, Sven Mueller wrote:
> >
> >>Anyway, what I really meant was: That person (you?) overlooked the
> >>pretty well known problems with huge directories. Making mistakes is
> >>human. However it is pretty difficult to change FSFS layout now without
> >>breaking existing installations.
> >
> >
> >Actually, here's a strawman plan:
> >
> >At open time: determine whether we have a new format or old format
> >repository (based on, perhaps, the content of "format", or the existence
> >of new-format-only directories). If old format, convert to new format.
> >The conversion be essentially a few mkdirs and bunch of rename operations.
> >This could even be written as a shell script.
>
> Why bother? Just have fallback code that tries to open the file as it
> would have existed in the previous naming scheme. If someone wants to
> convert they can dump/load.

Fallback code is tricky business (which is why the configurable
WC admin directories never got off the ground, IMO).

If we don't want to *require* a conversion, we could have an internal
vtable that provides path_rev() and path_revprops(), or we could
have those functions behave differently based on the repo format.

> >Instead of putting revision N in revs/N, put it in revs(N/1000)/N.
> >This gives us 1000 files per revs dir, and doesn't use more than 1000
> >revs dirs until after 1000000 revs. The same thing goes for revprops.
>
> I'd suggest revs/(N/1000)/N, so we don't clutter up the db directory.
>

The dirnames would clash with existing revs, but yes, I agree, we
shouldn't clutter the db directory.

--ben

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 21 00:45:05 2004

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.