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:
parent
ea76d04e15
commit
afb3e3e472
4 changed files with 50 additions and 8 deletions
|
@ -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"
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue