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

Suggestion: preventing inode crowding with FSFS

From: Kean Johnston <jkj_at_sco.com>
Date: 2005-10-07 09:12:48 CEST


I am about to convert a fairly large CVS repository over to
svn (yay - thats hwta SVN aims at eh?). I'm going to be using
FSFS. I have been doing some tests, and I think I recall the
doc even talking about this, but as I understand it, each new
revision lands in a new file in revs/. Ofbviously, with
hundreds, thousands or even hundreds of thousands of revs,
this doesn't scale well on many platforms where you start
paying a severe penalty when a single directory has too many
inodes in it.

Did the designers consider a scheme similar to what Squid
does (it has the same problem, wants to put thousands of
cached files into a database)? An effective way to do this
is thus. Convert the revision number to a 8-digit hex number.
Take the very last digit as a top level directory. Take the
next two digits as a second tier directory. The create the
file inside that directory. This spreads the load out fairly
evenly, and I would image it would be pretty trivial to

If anyone likes the idea and can point me in the approximate
direction of the right place in teh code, I will work on a
patch to do so. However, fi this idea has been previously
suggested and subsequently rejected for some reason, I'd
be curious why it was rejected.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 7 09:13:35 2005

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.