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

Re: some questions/comments on using fsfs for file system

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2004-08-12 22:11:17 CEST

> The time to load dump file using svnadmin:

> BDB: 5 hrs 5% processor
> FSFS: 1 hr 30% processor usage

I heard tell this morning of a change to cvs2svn to make it use
bdb-txn-nosync, allegedly speeding up conversion by a factor of four
or so. So you might be able to get comparable conversion performance
between the two back ends now.

> Would the NTFS file compression work ok with FSFS? I wouldn't expect
> it to work safely with BDB and never tried it.

I assume it would work okay, but it might not buy you very much, since
file contents in an FSFS repository are already compressed. Directory
contents and metadata are not compressed, so you might see some
savings, but your performance would probably degrade noticeably.

> I no longer need hotbackup or recover?

Recover is a no-op at the moment (and will remain so unless we
discover common failure cases we can automatically recover from). You
still "need" hotbackup, in that a naively copied FSFS repository might
suffer from (easily repairable) inconsistencies between the "current"
file and the set of revision files present under db/revs.

> Is it good for 20,000, 30,000, and upwards revisions? Has anyone
> tried more?

I think it is. If you experience bad performance, let me know. There
are two theoretical reasons to believe performance might suffer:

  * The FSFS delta storage algorithm means that as the number of file
    revs goes up, the number of deltas required to check out the head
    also goes up. However, the increase is logarithmic, so I don't
    think performance will become unacceptable even with a very large
    number of file revs.

  * FSFS has a big directory full of rev files (and another one full
    of revprop files), one for each revision. Although in my
    experience, most filesystems perform very well with large
    directories even if they don't use advanced techniques like
    B-trees, at least one person complained that his NFS FSFS
    repository performed poorly for non-svn operations like backup.

The second factor may be addressed in 1.2 with an option to split up
the revs and revprops directories into smaller subdirs.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Aug 12 22:11:43 2004

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.