Karl, thanks for the comments. Come to think of it, if there is
a lot of SVN activity, then the pathname-to-inode lookup will be
fairly quick, regardless of the directory size, because the
relevant entries will most likely be cached anyway. (This would
be in fs/namei.c of the Linux kernel source.)
I'm considering using ReiserFS instead of EXT3 filesystem on the
SVN box after we're done testing, because Reiser performs much
better with huge directories, and also directories with many
small files.
--- kfogel@collab.net wrote:
> Subversion Newbie <subversionnewbie@yahoo.com> writes:
> > Just wondering if there are plans to have the "db/revs"
> > directory under the repository use a multi-level ("hashed")
> > scheme, similar to what postfix does with its
> "hash_queue_depth"
> > option.
> > Those of us using Linux with EXT2 or EXT3 filesystems (and
> > probably Solaris people, too) will probably see a
> performance
> > hit when we start reaching a few thousand revisions (i.e.,
> files
> > in db/revs) given that the lookup for a directory entry is
> > pretty much sequential. Just curious.
>
> This is one of those FAQs that seems to come up a lot with the
> FSFS
> repository storage scheme.
>
> Greg Hudson (I believe) tested at least EXT3 up to hundreds of
> thousands of revisions, and saw no performance decrease.
>
> Now, possibly that test was skewed, because the inodes would
> have
> ended up right near each other, because the test was being run
> all at
> once -- whereas in real life there would be many other disk
> events in
> between Subversion revisions. Nevertheless, Greg's results
> are all we
> have to go on right now. We have heard speculation that there
> might
> be a performance problem someday, but we've never had a report
> of an
> actual problem.
>
> -Karl
__________________________________
Do you Yahoo!?
All your favorites on one personal page – Try My Yahoo!
http://my.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Nov 29 20:48:56 2004