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

Re: Problems with FSFS

From: Joshua Varner <jlvarner_at_gmail.com>
Date: 2005-10-27 00:04:35 CEST

On 10/26/05, Kahn, Peter <Peter.Kahn@ironmountain.com> wrote:
> Thanks for the information. Actually, I have had an environment where BDB
> is reasonably reliable, but in the past I had up to 4 hangs/corruption
> events per month. Needless to say, we all considered going to FSFS at that
> point, but without information regatrding the cause we weren't sure throwing
> another variable in the mix was worth it. I have achieved BDB reliability
> by restricting access to the repository to svnserve only for writing and
> keeping my server's up to date. I cannot be certain that any of these had
> anything to do with my corruption events, they are products of software
> superstition to a large extent.

One of the things that has been known to corrupt a BDB repository
is if two access methods try to access the repository at the same time,
The only serialization is provided by the filesystem locking (I believe).

> I do have a question regarding corruption in FSFS. I realize that it is
> less frequent. What's the standard resolution path (recovery?) and how
> often has it failed totally?
The way repositories are stored in FSFS if one file is corrupted you will
lose only the single revision it represented. If there is no backup, the
best bet is to manually fix the file, which can be done in a number of
ways, but requires knowledge of the format. I've seen people run svnadmin
verify, find the broken revision, send it to a dev (who volunteered to look)
and they fixed the file.

Failure rate statistics are not something I have, might be a good idea to
do a survey at some point.


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Oct 27 00:07:20 2005

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.