That message probably comes from SQLite.
SQLite uses the same locks FSFS uses internally.
FSFS depends on locks to ensure consistency with multiple writers.
FSFS does not guarantee correctness without locks. (Concretely:
without locks, if you run 'svnadmin pack' twice concurrently, you can
lose a shard of data. If you run two commits concurrently, you can
pretty easily have both of them succeed and claim to be r42 (and then
one of your developers needs to rm -rf a working copy).)
Does that spell "Don't do that"?
David White wrote on Wed, Aug 03, 2011 at 07:56:15 -0400:
> We have a Blade Center downstairs with a NAS mounted to it for additional
> storage. I'm in the process of setting up a SVN server for folks in our
> company umbrella to use. My boss wants a folder on the NAS to be used as the
> repo storage location, due to the extra space and redundancy we have on it.
> Thus...
>
> I have SVN 1.6.11 installed on a fresh install of CentOS 6 (on the Blade
> Center). I have mounted the NAS running NFS to be used as the repository
> storage location on /var/svn/. When I run "svnadmin create
> /var/svn/new-repo", it hangs for a few seconds, and then says (twice)
> "svnadmin: database is locked". However, when I go into "new-repo" and run
> ls -la, I see the subversion skeleton files.
>
> After lots of googling and brainstorming, I finally edited /etc/fstab and
> added the "nolock" option to the NFS partition when it gets mounted (and
> then these errors went away).
>
> I do understand folks' hesitation to use a network file system as the
> location for repositories. I have hidden the folder on the NAS, and have set
> permissions appropriately so only the authorized people (who know that
> messing with SVN repo files manually can royally screw everything up). All
> of this aside....
>
> Do you forsee problems with the NAS being mounted with the "nolock" option?
> In /etc/fstab, the line looks like this:
>
> {private-ip}:/volume1/svn /var/svn nfs nolock 0 0
>
> My guess is, if you get two people trying to do commits at the same time
> (which is unlikely right now, but as we grow, could become more possible),
> things could get corrupted. So, how worried should I be about this? If it's
> going to cause royal pains in the future, how would you suggest I fix the
> "database is locked" error message when the nolock isn't enabled on the
> mount?
>
> --
> - David White -
> Smooth Stone Services
> Computer Technical Support, IT Services, & Web Hosting Solutions
> http://www.smoothstoneservices.com
Received on 2011-08-03 14:21:09 CEST