Philip Martin <philip.martin_at_wandisco.com> wrote on 06/30/2011 12:43:54
PM:
> >> - since 1.6, if FSFS rep-sharing is not disabled there is the
problem
> >> of copying the rep-sharing SQLite database.
> >
> > rep-cache.db? I thought that could be easily regenerated. Is there
> > another .db file I missed?
>
> Yes, rep-cache.db. I'm not sure there is a tool to regenerate it, but
> if you know it is corrupt you can simply delete the file and rep-caching
> will then index any new revisions. The problem is that if it is simply
> copied while an SQLite write was in progress you don't know whether or
> not it is corrupt.
>
> You also need to ensure it is copied before the rev files so that
> rep-cache.db does not refer to revisions not yet in the database (recent
> 1.6 return SVN_ERR_FS_CORRUPT, older 1.6 could lose data).
This is sorta my point. That file is not essential to correct operation,
so one could simply not backup/restore that file and then you do not
need to worry if SQLite was writing at the time of the backup.
(Or, as you said, make sure that file is backed up before the revs
directory, just like you should with the "current" file.)
> >> > On a similar note, could a server or application crash now leave
> >> > a 1.7 repository in an inconsistent and unrecoverable state?
> >>
> >> Not sure what you are thinking of here, but it's perfectly OK to
> >> interrupt SQLite in the middle of a transaction.
> >
> > Understood, but I want to make sure that a corrupted SQLite db
> > doesn't make the whole past history of the repository unusable.
> > For example, if the server dies a horrible death in the middle
> > of updating r100, I'd really hope it can't easily make r1-r99
> > unusable in the process.
>
> Why do you think that would happen? How are you corrupting the SQLite
> db?
Unexpected things happen. If your process is to only ever write
new files and never modify files in place, you can always get back
to a working state, because you can just remove/ignore the
corrupted information. *IF* you modify a file in place, *AND*
that file is essential to using other information, you have
just created a single point of failure...
What I don't know is if the revprop SQLite db in 1.7
is essential to the operation of the repo. If it can't
be deleted and recreated like the rep-cache.db file above, I would
consider it a single point of failure for the entire fsfs repository.
That new single point of failure would make me uneasy about
enabling revprop packing in 1.7...
Kevin R.
Received on 2011-06-30 20:16:11 CEST