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

Re: svnadmin load using fsfs is agonizingly slow

From: Ryan Schmidt <subversion-2006d_at_ryandesign.com>
Date: 2006-10-03 17:42:43 CEST

On Oct 3, 2006, at 10:25, Keith Bottner wrote:

>>> We have several repositories and our largest repository when
>>> svnadmin
>>> dump'd is approximately 71gigs in size (Takes a very long time to
>>> dump
>>> even though all users are kicked out of the repository so no changes
>>> will take place.) Restoration of this repository using svnadmin load
>>> has currently taken over 48 hours and is still NOT complete.
>> [snip]
>>> I dumped my repositories because I am upgrading from 1.3.2 to 1.4.0
>>> and wanted to make sure the repositories were using the new 1.4
>>> format.
>> [snip]
>>> Any advice or guidance would be greatly appreciated as I have
>>> engineers who are looking to lynch me and I would like to avoid a
>>> fiery death.
>> Not sure if there's a way to speed this up, but to try to avert your
>> lynching, I think you could safely allow the engineers to continue
>> working
>> on the old 1.3.2 repository while the dump proceeds. You can then
>> load this
>> into a new 1.4 repository at your leisure. Once it's done, then
>> you can kick
>> everybody out of the old repository, do an incremental dump of any
>> revisions
>> created since your initial dump, load that into the new
>> repository, point
>> the server at the new repository, and get back to work.
> Good suggestion, I will have to implement that process in the future.
> I am still concerned that if we had to rebuild from backups and
> could not
> implement your suggestion that it would take days to restore our
> repository
> and get everyone back to work. I would really like to know if the
> problem I
> am seeing on the FSFS type is fsync related and if it is can fsync be
> disabled for FSFS when loading a repository through svnadmin.

For backup and quick restore purposes, you could consider instead (or
additionally) doing a "hot backup". Your backup is then a complete
repository which you can use immediately without having to load it
anywhere. You're back to work as quickly as your OS / hardware can
copy the backup onto the primary disk(s), or quicker if you keep a
copy of the backup on the same disk(s) as your main repository.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Oct 3 17:43:43 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.