avoid crash when starting fsck --incremental when one is already running

Turns out sqlite does not like having its database deleted out from
underneath it. It might suffice to empty the table, but I would rather
start each fsck over with a new database, so I added a lock file, and
running incremental fscks use a shared lock.

This leaves one concurrency bug left; running two concurrent fsck --more
will lead to: "SQLite3 returned ErrorBusy while attempting to perform step."
and one or both will fail. This is a concurrent writers problem.
This commit is contained in:
Joey Hess 2015-02-17 13:04:22 -04:00
parent ea76d04e15
commit afb3e3e472
4 changed files with 50 additions and 8 deletions

View file

@ -72,7 +72,7 @@ seek ps = do
(\k -> startKey i k =<< getNumCopies)
(withFilesInGit $ whenAnnexed $ start from i)
ps
withFsckDb i (liftIO . FsckDb.closeDb)
withFsckDb i FsckDb.closeDb
getIncremental :: Annex Incremental
getIncremental = do
@ -91,8 +91,10 @@ getIncremental = do
where
startIncremental = do
recordStartTime
FsckDb.newPass
StartIncremental <$> FsckDb.openDb
ifM FsckDb.newPass
( StartIncremental <$> FsckDb.openDb
, error "Cannot start a new --incremental fsck pass; another fsck process is already running."
)
contIncremental = ContIncremental <$> FsckDb.openDb
checkschedule Nothing = error "bad --incremental-schedule value"