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

Re: filesystem config

From: Nico Kadel-Garcia <nkadel_at_comcast.net>
Date: 2006-07-08 14:55:06 CEST

gmu 2k6 wrote:
> I'm experimenting with different filesystems (linux fs, not svn
> backend) to see which might be the best option for one or more SVN 1.3
> repos I'm going to host.
>
> the data to be committed to SVN consists of the following top-level
> directories which are spread aroung 2 or 3 repos in CVS right now:
> src 1GiB
> res 3.3 GiB
> projX 780MiB
> projXsetup 230MiB
> all sizes are the space used on a local disk after checking it out
> from CVS of course and not the size on the CVS server.
> we will commit all existing data from a fresch CVS-checkout to SVN and
> use a read-only CVS server for history. this is done so that we start
> anew and get rid of the accumulated history no one actually needs and
> if one needs it she can use the read-only CVS server.
>
> ---- server-info
> storage: HP SmartArray 6400 RAID 1+0 with four primary partitions for
> trying out four different linux file system configurations in parallel
> cpu: one or two Xeon 3GHz
> ram: 4GiB
> distro: Debian Testing
> linux: >= 2.6.15
>
> the partitions I have created so far are:
> p1: ext3 dir_index, sparse_super
> p2: ext3 dir_index, sparse_super, largefile
> p3: ext3 dir_index, sparse_super, largefile4
> p4: <empty>
>
> AFAIK the FSFS backend will create one file per changeset so ext3's
> dir_index might be of help but I'm not sure how to tackle the problem
> that changesets are normally really small but can be quite big with
> binary files. choosing the best block size with ext3 for this pattern
> is hard. maybe Reiser3 or XFS might be a better fit, any opinions with
> good reasoning might be useful.

Don't hurt yourself trying to over-tune the system. Seriously, the default
ext3 settings with dir_fs for directories or database files that may number
in the many thousands in a single directory as they accumulate is plenty,
and I've found ext3 to be more reliable when hardware begins to fail than
Reiserfs.

> the second big question I have is whether there is a performance
> problem with stuffing all of the dirs as outlined above into one repo
> or using separate repos. when using svnserve without ssh and many
> repos this would of course mean that I have to maintain multiple
> access-control configs and sync the password files. therefore for
> creating multiple repos to be used by the same groups of devs it may
> be best to use svn+ssh and rely on xattr or go with WebDAV although I
> really want to avoid Apache for security and performance reasons.

Hah. I've dealt with this. Welcome to the world of Apache password files,
which can be entirely shared for a master directory, and the additional
layer of user access avaiable through svnperms.py and svnperms.conf, which
can be symlinked into every repositoriies configuration.

> the third question mark in my head is: what setup do people like
> apache.org, kde.org and other big projects with many binary files and
> text files use?

Sourceforge: lots of projects, many of which are huge but most of which are
functionally distinct from each other and have their own codebases.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jul 8 14:56:11 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.