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

Re: Suggestion: preventing inode crowding with FSFS

From: Kean Johnston <jkj_at_sco.com>
Date: 2005-10-07 10:26:33 CEST

> So far I've seen a fair number of people worrying about the problem, but
> not many people experiencing it.
I suspect that most people are actually using approximately
modern filesystems, where its less likely to be an issue.
On the platform I care about (SCO, which means almost no-one
else does), the FS does indeed slow down drastically after
4096 inodes in a directory. Its a nice exponential degradation
for each multiple of 4096 inodes.

> * Provide a Python script to convert an existing repository to the new
> layout. (An sh script would be simpler, but wouldn't work on Windows.)
I could do almost all the rest except for that bit. I just
dont "get" Python (but admittedly havent tried too hard either).

> We might prefer something simpler; I'm not sure if the load-spreading
> goal of the Squid cache layout is of any great value to a Subversion
> repository. Also, although 2^64 is "plenty" of revisions, the current
> FSFS layout does not impose an upper limit on the number of revisions,
> and it would be nice to keep that property.
The FSFS layout may not impose such a limitation but the data
type for a revision does. In fact, it limits it to 2^31 on
a 32-bit platform or 2^63 on a 64 bit one (its a long int).
So at the point where you must do a sprintf of the revision to
get to the name (%d most likely) the limitation is implied.

I will look at all the other code you pointed me at. Thanks
for the pointers Greg.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 7 10:28:32 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.