> -----Original Message-----
> From: Evan Driscoll [mailto:driscoll_at_cs.wisc.edu]
> Sent: 26 January 2012 21:05
> Subject: "database disk image is malformed"
>
> [There's a lot of background information; I have some
> questions near the end.]
>
>
> When I try to commit, I see the following:
>
> Sending <file>
> ...
> Sending <file>
> Transmitting file data ............svn: Commit failed
> (details follow):
> svn: database disk image is malformed
> svn: database disk image is malformed
>
>
> Vital statistics:
>
> Repository format: FSFS stored on AFS
> Access via: svn+ssh
> Subversion version: 1.6.0
[Knee jerk:] 1.6.0 is quite old now (march 2009). Any chance of upgrading?
> The subversion FAQ [1] states:
>
> If you are using the FSFS repository back end, then storing the
> repository on a modern NFS server (i.e., one that supports locking)
> should be fine.
>
> Here's what one site [2] says about file locking on AFS.
>
> The file locking mechanism in AFS does not really follow POSIX6
> semantics. There are a few issues to mention:
>
> - Files may only be locked as a whole; regions of a file may not be
> locked.
> - File locking only works properly and reliably from a
> single system.
> If a file is locked from one client and an attempt is made to
> access the file from another client, the error EWOULDBLOCK is
> returned.
> - There is no deadlock prevention in AFS, so deadlock
> situations can occur with file locking.
> - Any program that attempts to use byte-range file locking in AFS
> will get a message from the cache manager warning that other
> users may be accessing the same file. Usually these messages
> can be safely ignored.
>
> Generally we don't recommend including applications that depend on
> file locking in the AFS file space.
>
> From the second point there it sounds to me like AFS provides the
> environment that Subversion needs, but I'm no expert.
>
>
> I found an old thread [3] that seems to suggest dumping and reloading
> the repository should fix the problem, but also suggests removing the
> db/rep-cache.db file and perhaps disabling rep-sharing. I did the
> latter, and it cleared up the problem.
>
>
> My questions:
>
> 1. Did removing rep-cache.db fix it, or is there still a potential for
> some latent repository corruption? Is there any way to check a
> repository for something like that?
Check out svnadmin verify:-
http://svnbook.red-bean.com/en/1.6/svn.ref.svnadmin.c.verify.html
> 2. Regarding dumping and reloading vs deleting rep-cache.db, what are
> the tradeoffs? How do I decide which one to do? The ~15%
> savings is a little nice but not even remotely essential.
> Does that mean that deleting rep-sharing.db is more attractive
> since it's less work?
>
> 3. What caused this problem in the first place? Was it putting the
> repository on AFS? Is there any *safe* way to do that
> with using the svn+ssh protocol, which is attractive because
> it requires no setup on my part, no worries about security
> of access, etc.?
>
> 4. A later reply [4] to the aforementioned thread states that
> Subversion 1.7+ uses BDB with revprops.db. What is in
> this file? Is it something which is really important
> (e.g. commit logs and users) or just something inessential
> like rep-sharing.db?
I believe that this uses SQLite, not BDB ?
> If it's essential, does that mean that whatever caused
> corruption to our rep-sharing.dp could, if we upgrade,
> cause actual problems and made us restore from backup?
>
> Evan Driscoll
>
>
>
> [1] http://subversion.apache.org/faq.html#nfs
> [2] http://computing.fnal.gov/unixatfermilab/html/afs.html#57212
> [3]
> http://mail-archives.apache.org/mod_mbox/subversion-users/201012.mbox/%3C201012161703.01954.rdorsch@web.de%3E
> [4]
> http://mail-archives.apache.org/mod_mbox/subversion-users/201012.mbox/%3C20101218184143.GA8544@daniel3.local%3E
>
Received on 2012-01-27 08:43:48 CET