On Thu, Jun 09, 2011 at 09:48:18AM -0400, Matthew Beals wrote:
> I just suffered a fairly major repo corruption problem. Fortunately I had nightly dumps to restore from as well as an updated working copy of the affected repos, so the only thing I lost was some file history. Now I'm trying to figure out what caused the issue and if I can prevent it in the future.
>
> I have two areas of concern:
>
> 1. The repos are stored on our RAID and accessed over NFS mounted with the nolock option. I've read that this isn't a concern with the fsfs backend, but I'm still worried this had something to do with it.
>
> 2. We access the repos over both dav_svn and ssh spawning svnserve (using the wrapper script to set umask to 002). I auth apache through pam, so uid/gid is identical for both methods for all users. These repos were stable for a solid year with no problems using only dav_svn. I only introduced svnserve recently to make accessing the repos from outside the firewall easier with tortiseSVN and one month later....broken repos.
>
> Is any of this considered bad practice that could lead to repo corruption?
FSFS requires file locking to ensure consistency when multiple processes
concurrently access the repository. If the repository is accessed over
NFS without locking corruption could certainly occur.
I'm not sure where you could have gotten the opposite information from.
Did you read this in Subversion's documentation or somewhere else?
If your Apache server is handling requests via threads (rather than forking
processes) this might explain why you never saw this problem with just dav.
The threads can synchronise via mutexes which live in the same process
address space. But separate processes require file locking for proper
synchronisation.
Received on 2011-06-09 16:21:15 CEST