You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by stephen meechan <mg...@dsl.pipex.com> on 2004/08/12 00:07:28 UTC
some questions/comments on using fsfs for file system
Having just had a problem yesterday with an error "No transaction named
'a80'. DB needs recovery", I already had a dumpfile to do the recovery
process, so I thought I would try out the fsfs alternative in the latest
version of svn. I read the notes that mentions the advantages and
disadvantages but my initial impressions are very good!
The server setup was dual processor AMD MP-2000, 512 MB ram, MS Windows
Server 2003, NTFS formatted disk.
The dump file is 2 GB from yesterdays database to do recovery , 13210
revisions. I use svnserve for repository access.
BDB = svn with Berkeley DB
FSFS = svn with file system
The time to load dump file using svnadmin:
BDB: 5 hrs 5% processor
FSFS: 1 hr 30% processor usage
This alone would make it worthwhile for me to switch to FSFS! The time to
convert other repositories from CVS would be much reduced.
Disk space used:
BDB 840 MB,
FSFS 244 MB ( 320 MB on disk reported by explorer)
Copy across network with explorer, ( not good for copying lots of files, but
everyone uses it ):
BDB 3 minutes, 50% network utilisation
FSFS 5 minutes 10 % network utilisation
Checkout trunk with svnserve and command line client, 6000 files:
BDB 6 minutes
FSFS 4 minutes
Backup using server 2003 backup program:
BDB 2 1/2 minutes
FSFS 4 1/2 minutes
Would the NTFS file compression work ok with FSFS? I wouldn't expect it to
work safely with BDB and never tried it.
I no longer need hotbackup or recover?
Is it good for 20,000, 30,000, and upwards revisions? Has anyone tried more?
Assuming it works reliably for multi user access I cant see any downside to
switching, have I over looked something?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: some questions/comments on using fsfs for file system
Posted by stephen meechan <mg...@dsl.pipex.com>.
> > 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.
>
> You can either pass --bdb-txn-nosync directly to cvs2svn, or make
> cvs2svn create a dumpfile and pass --bdb-txn-nosync when creating the
> repo yourself.
>
> When doing our conversion, 'svnadmin load' took ~10 hours by default.
> Creating the repo with --bdb-txn-nosync sped things up to ~2 hours. In
> both cases 'svnadmin load' was I/O bound.
>
> Putting the whole repository in tmpfs sped it up even more, from ~2
> hours to ~20 minutes (and then it was CPU bound, not I/O bound). Note
> that you don't even need enough RAM to fit it all in memory for this to
> be a win; in our case, most of the tmpfs mount got pushed out to swap
> (~600mb repo on a 256mb machine). Obviously you have to remember to copy
> the repo somewhere permanent afterwards if you do this :)
Interesting because you get the full benefit of having a fast machine. But
doing it this way leaves the db-txn-nosync off even for normal use. It looks
like the latest cvs2svn program modifies the DB_CONFIG file to turn is back
on, so presumably there's no svnadmin command to reenable it.
Is there a recommendation on whether it should or shouldn't be on for normal
usage?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: some questions/comments on using fsfs for file system
Posted by Oliver Jowett <ol...@opencloud.com>.
Greg Hudson wrote:
>>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.
You can either pass --bdb-txn-nosync directly to cvs2svn, or make
cvs2svn create a dumpfile and pass --bdb-txn-nosync when creating the
repo yourself.
When doing our conversion, 'svnadmin load' took ~10 hours by default.
Creating the repo with --bdb-txn-nosync sped things up to ~2 hours. In
both cases 'svnadmin load' was I/O bound.
Putting the whole repository in tmpfs sped it up even more, from ~2
hours to ~20 minutes (and then it was CPU bound, not I/O bound). Note
that you don't even need enough RAM to fit it all in memory for this to
be a win; in our case, most of the tmpfs mount got pushed out to swap
(~600mb repo on a 256mb machine). Obviously you have to remember to copy
the repo somewhere permanent afterwards if you do this :)
-O
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: some questions/comments on using fsfs for file system
Posted by stephen meechan <mg...@dsl.pipex.com>.
> 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.
I've checked out the latest cvs2svn and I'll try it as I'm still
experimenting with the repositories to see what settings give the best
overall conversion results.
> > 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.
The benefit might come in the revprops directory, the files are very small,
the smallest is 50 bytes and the largest is 528. Under NTFS it reports the
directory size as 1.69 MB for 13211 files, but the disk used as 51.6 MB.
Obviously this is just wasted space, but overall it's still smaller that the
equivalent DB file.
> > 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.
I tried the hotcopy, it was slower that the DB hotcopy, but not by much.
> > 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:
OK I'm going to try it out. I dont think I have enough real data to reach
30,000, but by combining all my repositories that would at least show me
that there's enough growing room for few years.
> * 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.
I've seen the 2nd problem happen on CD, backing up 40,000 TIFF images files
to one directory on a CD worked OK, but browsing that directory in explorer
would take around 10 minutes to come up. The solution was similar to what
you suggested, copy every 1000 files to their own sub directory.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: some questions/comments on using fsfs for file system
Posted by Greg Hudson <gh...@MIT.EDU>.
> 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