[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: John Szakmeister <john_at_szakmeister.net>
Date: 2007-03-06 09:03:58 CET

Malcolm Rowe wrote:
> On Mon, Mar 05, 2007 at 10:41:10PM -0600, Peter Samuelson wrote:
>> Kean Johnston (CC'd) wanted this feature back in 2005 on the grounds
>> that SCO Unixware had severe scalability problems when a directory
>> exceeds 4096 entries:
>> http://svn.haxx.se/dev/archive-2005-10/0269.shtml
> Oh yeah, I remember that thread. "exponential degradation for each
> multiple of 4096 inodes".
>> I guess I'd vote for 2000 entries per bucket. Honestly, 1000 entries
>> is probably sufficient - you have to go north of 2000000 revisions
>> before it scales worse than 2000 entries.
> A power of ten is probably useful for that purpose, but I'd like to go
> with buckets of at least 4000 entries. That's not too high that any
> reasonable filesystem should have problems, but it leaves enough space
> for large repositories to grow into.
> And yes, I'm aware that I'm effectively considering repositories with
> 16M revisions as 'large' there :-)

FYI, FAT32 doesn't allow more than 65536 entries per directory. That
number is actually affected by the presence of long filenames, and
unicode. I can't remember how this plays out in real life, but if you
have two entries per file (and more for a unicode name with several
numbers in it), it cuts the available entries in half.

NTFS doesn't have that limit, but other things start happening when you
get into large directory sizes. I did a quick test, and 16,384 revision
was taking roughly 6 seconds to show up in explorer. 25,600 was taking
nearly 10 seconds. I was taking these measurements under XP in a VM, so
it's not quite as efficient... but then, there are probably a number of
people running SVN in a virtualized environment.

FWIW, I remember hearing of another file system (coda or a related one)
that had a limit slightly less than 2048 by default.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 6 09:04:56 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.