2024-08-12 15:19:58 +00:00
|
|
|
{- Sqlite database used to track the sizes of repositories.
|
|
|
|
-
|
|
|
|
- Copyright 2024 Joey Hess <id@joeyh.name>
|
|
|
|
-:
|
|
|
|
- Licensed under the GNU AGPL version 3 or higher.
|
|
|
|
-}
|
|
|
|
|
|
|
|
{-# LANGUAGE CPP #-}
|
|
|
|
{-# LANGUAGE QuasiQuotes, TypeFamilies, TemplateHaskell #-}
|
|
|
|
{-# LANGUAGE OverloadedStrings, GADTs, FlexibleContexts #-}
|
|
|
|
{-# LANGUAGE MultiParamTypeClasses, GeneralizedNewtypeDeriving #-}
|
|
|
|
{-# LANGUAGE DataKinds, FlexibleInstances #-}
|
|
|
|
{-# LANGUAGE RankNTypes #-}
|
|
|
|
{-# LANGUAGE UndecidableInstances #-}
|
|
|
|
{-# LANGUAGE TypeOperators #-}
|
|
|
|
#if MIN_VERSION_persistent_template(2,8,0)
|
|
|
|
{-# LANGUAGE DerivingStrategies #-}
|
|
|
|
{-# LANGUAGE StandaloneDeriving #-}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
module Database.RepoSize (
|
|
|
|
RepoSizeHandle,
|
2024-08-23 20:35:12 +00:00
|
|
|
getRepoSizeHandle,
|
2024-08-12 15:19:58 +00:00
|
|
|
openDb,
|
|
|
|
closeDb,
|
2024-08-30 15:58:10 +00:00
|
|
|
isOpenDb,
|
2024-08-27 17:07:06 +00:00
|
|
|
lockDbWhile,
|
2024-08-15 15:50:01 +00:00
|
|
|
getRepoSizes,
|
|
|
|
setRepoSizes,
|
2024-08-23 16:51:00 +00:00
|
|
|
startingLiveSizeChange,
|
2024-08-25 14:34:47 +00:00
|
|
|
successfullyFinishedLiveSizeChange,
|
2024-08-26 18:50:09 +00:00
|
|
|
removeStaleLiveSizeChange,
|
2024-08-28 17:52:59 +00:00
|
|
|
removeStaleLiveSizeChanges,
|
closing in on finishing live reposizes
Fixed successfullyFinishedLiveSizeChange to not update the rolling total
when a redundant change is in RecentChanges.
Made setRepoSizes clear RecentChanges that are no longer needed.
It might be possible to clear those earlier, this is only a convenient
point to do it.
The reason it's safe to clear RecentChanges here is that, in order for a
live update to call successfullyFinishedLiveSizeChange, a change must be
made to a location log. If a RecentChange gets cleared, and just after
that a new live update is started, making the same change, the location
log has already been changed (since the RecentChange exists), and
so when the live update succeeds, it won't call
successfullyFinishedLiveSizeChange. The reason it doesn't
clear RecentChanges when there is a reduntant live update is because
I didn't want to think through whether or not all races are avoided in
that case.
The rolling total in SizeChanges is never cleared. Instead,
calcJournalledRepoSizes gets the initial value of it, and then
getLiveRepoSizes subtracts that initial value from the current value.
Since the rolling total can only be updated by updateRepoSize,
which is called with the journal locked, locking the journal in
calcJournalledRepoSizes ensures that the database does not change while
reading the journal.
2024-08-27 15:04:27 +00:00
|
|
|
recordedRepoOffsets,
|
|
|
|
liveRepoOffsets,
|
2024-09-23 16:28:18 +00:00
|
|
|
setSizeChanges,
|
2024-08-12 15:19:58 +00:00
|
|
|
) where
|
|
|
|
|
2024-08-15 15:50:01 +00:00
|
|
|
import Annex.Common
|
2024-08-23 20:35:12 +00:00
|
|
|
import qualified Annex
|
|
|
|
import Database.RepoSize.Handle
|
2024-08-15 16:31:27 +00:00
|
|
|
import qualified Database.Handle as H
|
2024-08-12 15:19:58 +00:00
|
|
|
import Database.Init
|
2024-08-15 15:50:01 +00:00
|
|
|
import Database.Utility
|
|
|
|
import Database.Types
|
2024-08-23 20:35:12 +00:00
|
|
|
import Annex.LockFile
|
|
|
|
import Git.Types
|
2024-08-12 15:19:58 +00:00
|
|
|
import qualified Utility.RawFilePath as R
|
|
|
|
|
|
|
|
import Database.Persist.Sql hiding (Key)
|
|
|
|
import Database.Persist.TH
|
|
|
|
import qualified System.FilePath.ByteString as P
|
2024-08-26 18:50:09 +00:00
|
|
|
import qualified Data.Map.Strict as M
|
|
|
|
import qualified Data.Set as S
|
2024-08-27 17:07:06 +00:00
|
|
|
import Control.Exception
|
2024-08-28 17:52:59 +00:00
|
|
|
import Control.Concurrent
|
2024-08-12 15:19:58 +00:00
|
|
|
|
|
|
|
share [mkPersist sqlSettings, mkMigrate "migrateRepoSizes"] [persistLowerCase|
|
2024-08-15 15:50:01 +00:00
|
|
|
-- Corresponds to location log information from the git-annex branch.
|
2024-08-12 15:19:58 +00:00
|
|
|
RepoSizes
|
|
|
|
repo UUID
|
2024-08-25 12:22:40 +00:00
|
|
|
size FileSize
|
2024-08-12 15:19:58 +00:00
|
|
|
UniqueRepo repo
|
2024-08-15 15:50:01 +00:00
|
|
|
-- The last git-annex branch commit that was used to update RepoSizes.
|
|
|
|
AnnexBranch
|
|
|
|
commit SSha
|
|
|
|
UniqueCommit commit
|
2024-08-23 16:51:00 +00:00
|
|
|
-- Changes that are currently being made that affect repo sizes.
|
2024-08-25 14:34:47 +00:00
|
|
|
-- (Only updated when preferred content expressions are in use that need
|
|
|
|
-- live size changes.)
|
2024-08-23 16:51:00 +00:00
|
|
|
LiveSizeChanges
|
|
|
|
repo UUID
|
|
|
|
key Key
|
2024-08-28 17:52:59 +00:00
|
|
|
changeid SizeChangeUniqueId
|
|
|
|
changepid SizeChangeProcessId
|
2024-08-23 16:51:00 +00:00
|
|
|
change SizeChange
|
2024-08-28 17:52:59 +00:00
|
|
|
UniqueLiveSizeChange repo key changeid changepid
|
2024-08-25 14:34:47 +00:00
|
|
|
-- A rolling total of size changes that were removed from LiveSizeChanges
|
|
|
|
-- upon successful completion.
|
|
|
|
SizeChanges
|
|
|
|
repo UUID
|
|
|
|
rollingtotal FileSize
|
|
|
|
UniqueRepoRollingTotal repo
|
2024-08-26 18:50:09 +00:00
|
|
|
-- The most recent size changes that were removed from LiveSizeChanges
|
|
|
|
-- upon successful completion.
|
|
|
|
RecentChanges
|
|
|
|
repo UUID
|
|
|
|
key Key
|
|
|
|
change SizeChange
|
|
|
|
UniqueRecentChange repo key
|
2024-08-12 15:19:58 +00:00
|
|
|
|]
|
|
|
|
|
2024-08-23 20:35:12 +00:00
|
|
|
{- Gets a handle to the database. It's cached in Annex state. -}
|
|
|
|
getRepoSizeHandle :: Annex RepoSizeHandle
|
|
|
|
getRepoSizeHandle = Annex.getState Annex.reposizehandle >>= \case
|
|
|
|
Just h -> return h
|
|
|
|
Nothing -> do
|
|
|
|
h <- openDb
|
|
|
|
Annex.changeState $ \s -> s { Annex.reposizehandle = Just h }
|
|
|
|
return h
|
|
|
|
|
2024-08-12 15:19:58 +00:00
|
|
|
{- Opens the database, creating it if it doesn't exist yet.
|
|
|
|
-
|
2024-08-15 15:50:01 +00:00
|
|
|
- Multiple readers and writers can have the database open at the same
|
|
|
|
- time. Database.Handle deals with the concurrency issues.
|
|
|
|
- The lock is held while opening the database, so that when
|
|
|
|
- the database doesn't exist yet, one caller wins the lock and
|
|
|
|
- can create it undisturbed.
|
2024-08-12 15:19:58 +00:00
|
|
|
-}
|
|
|
|
openDb :: Annex RepoSizeHandle
|
2024-08-27 17:07:06 +00:00
|
|
|
openDb = lockDbWhile permerr $ do
|
|
|
|
dbdir <- calcRepo' gitAnnexRepoSizeDbDir
|
|
|
|
let db = dbdir P.</> "db"
|
|
|
|
unlessM (liftIO $ R.doesPathExist db) $ do
|
|
|
|
initDb db $ void $
|
|
|
|
runMigrationSilent migrateRepoSizes
|
|
|
|
h <- liftIO $ H.openDb db "repo_sizes"
|
2024-08-28 17:52:59 +00:00
|
|
|
mkhandle (Just h)
|
2024-08-15 15:50:01 +00:00
|
|
|
where
|
2024-08-28 17:52:59 +00:00
|
|
|
mkhandle mh = do
|
|
|
|
livev <- liftIO $ newMVar Nothing
|
|
|
|
return $ RepoSizeHandle mh livev
|
|
|
|
|
2024-08-15 15:50:01 +00:00
|
|
|
-- If permissions don't allow opening the database,
|
|
|
|
-- just don't use it. Since this database is just a cache
|
|
|
|
-- of information available in the git-annex branch, the same
|
|
|
|
-- information can be queried from the branch, though much less
|
|
|
|
-- efficiently.
|
2024-08-28 17:52:59 +00:00
|
|
|
permerr _e = mkhandle Nothing
|
2024-08-12 15:19:58 +00:00
|
|
|
|
2024-08-30 15:58:10 +00:00
|
|
|
-- When the repository cannot be written to, openDb returns a
|
|
|
|
-- RepoSizeHandle that is not actually open, all operations on it will do
|
|
|
|
-- nothing.
|
|
|
|
isOpenDb :: RepoSizeHandle -> Bool
|
|
|
|
isOpenDb (RepoSizeHandle (Just _) _) = True
|
|
|
|
isOpenDb (RepoSizeHandle Nothing _) = False
|
|
|
|
|
2024-08-12 15:19:58 +00:00
|
|
|
closeDb :: RepoSizeHandle -> Annex ()
|
2024-08-28 17:52:59 +00:00
|
|
|
closeDb (RepoSizeHandle (Just h) _) = liftIO $ H.closeDb h
|
|
|
|
closeDb (RepoSizeHandle Nothing _) = noop
|
2024-08-12 15:19:58 +00:00
|
|
|
|
2024-08-27 17:07:06 +00:00
|
|
|
-- This does not prevent another process that has already
|
|
|
|
-- opened the db from changing it at the same time.
|
|
|
|
lockDbWhile :: (IOException -> Annex a) -> Annex a -> Annex a
|
|
|
|
lockDbWhile permerr a = do
|
|
|
|
lck <- calcRepo' gitAnnexRepoSizeDbLock
|
|
|
|
catchPermissionDenied permerr $ withExclusiveLock lck a
|
|
|
|
|
2024-08-26 18:50:09 +00:00
|
|
|
{- Gets the sizes of repositories as of a commit to the git-annex
|
|
|
|
- branch. -}
|
2024-08-15 15:50:01 +00:00
|
|
|
getRepoSizes :: RepoSizeHandle -> IO (M.Map UUID RepoSize, Maybe Sha)
|
2024-08-28 17:52:59 +00:00
|
|
|
getRepoSizes (RepoSizeHandle (Just h) _) = H.queryDb h $ do
|
2024-08-26 18:50:09 +00:00
|
|
|
sizemap <- M.fromList <$> getRepoSizes'
|
2024-08-15 15:50:01 +00:00
|
|
|
annexbranchsha <- getAnnexBranchCommit
|
|
|
|
return (sizemap, annexbranchsha)
|
2024-08-28 17:52:59 +00:00
|
|
|
getRepoSizes (RepoSizeHandle Nothing _) = return (mempty, Nothing)
|
2024-08-26 18:50:09 +00:00
|
|
|
|
|
|
|
getRepoSizes' :: SqlPersistM [(UUID, RepoSize)]
|
|
|
|
getRepoSizes' = map conv <$> selectList [] []
|
2024-08-12 15:19:58 +00:00
|
|
|
where
|
|
|
|
conv entity =
|
|
|
|
let RepoSizes u sz = entityVal entity
|
|
|
|
in (u, RepoSize sz)
|
|
|
|
|
2024-08-15 15:50:01 +00:00
|
|
|
getAnnexBranchCommit :: SqlPersistM (Maybe Sha)
|
|
|
|
getAnnexBranchCommit = do
|
|
|
|
l <- selectList ([] :: [Filter AnnexBranch]) []
|
|
|
|
case l of
|
|
|
|
(s:[]) -> return $ Just $ fromSSha $
|
|
|
|
annexBranchCommit $ entityVal s
|
|
|
|
_ -> return Nothing
|
|
|
|
|
|
|
|
{- Updates the recorded sizes of all repositories.
|
|
|
|
-
|
|
|
|
- This can be called without locking since the update runs in a single
|
|
|
|
- transaction.
|
|
|
|
-
|
|
|
|
- Any repositories that are not in the provided map, but do have a size
|
|
|
|
- recorded in the database will have it cleared. This is unlikely to
|
|
|
|
- happen, but ensures that the database is consistent.
|
|
|
|
-}
|
|
|
|
setRepoSizes :: RepoSizeHandle -> M.Map UUID RepoSize -> Sha -> IO ()
|
2024-08-28 17:52:59 +00:00
|
|
|
setRepoSizes (RepoSizeHandle (Just h) _) sizemap branchcommitsha =
|
2024-08-15 16:31:27 +00:00
|
|
|
H.commitDb h $ do
|
2024-08-26 18:50:09 +00:00
|
|
|
l <- getRepoSizes'
|
|
|
|
forM_ (map fst l) $ \u ->
|
2024-08-15 15:50:01 +00:00
|
|
|
unless (M.member u sizemap) $
|
|
|
|
unsetRepoSize u
|
|
|
|
forM_ (M.toList sizemap) $
|
|
|
|
uncurry setRepoSize
|
closing in on finishing live reposizes
Fixed successfullyFinishedLiveSizeChange to not update the rolling total
when a redundant change is in RecentChanges.
Made setRepoSizes clear RecentChanges that are no longer needed.
It might be possible to clear those earlier, this is only a convenient
point to do it.
The reason it's safe to clear RecentChanges here is that, in order for a
live update to call successfullyFinishedLiveSizeChange, a change must be
made to a location log. If a RecentChange gets cleared, and just after
that a new live update is started, making the same change, the location
log has already been changed (since the RecentChange exists), and
so when the live update succeeds, it won't call
successfullyFinishedLiveSizeChange. The reason it doesn't
clear RecentChanges when there is a reduntant live update is because
I didn't want to think through whether or not all races are avoided in
that case.
The rolling total in SizeChanges is never cleared. Instead,
calcJournalledRepoSizes gets the initial value of it, and then
getLiveRepoSizes subtracts that initial value from the current value.
Since the rolling total can only be updated by updateRepoSize,
which is called with the journal locked, locking the journal in
calcJournalledRepoSizes ensures that the database does not change while
reading the journal.
2024-08-27 15:04:27 +00:00
|
|
|
clearRecentChanges
|
2024-08-15 15:50:01 +00:00
|
|
|
recordAnnexBranchCommit branchcommitsha
|
2024-08-28 17:52:59 +00:00
|
|
|
setRepoSizes (RepoSizeHandle Nothing _) _ _ = noop
|
2024-08-15 15:50:01 +00:00
|
|
|
|
|
|
|
setRepoSize :: UUID -> RepoSize -> SqlPersistM ()
|
|
|
|
setRepoSize u (RepoSize sz) =
|
2024-08-12 15:19:58 +00:00
|
|
|
void $ upsertBy
|
|
|
|
(UniqueRepo u)
|
|
|
|
(RepoSizes u sz)
|
|
|
|
[RepoSizesSize =. sz]
|
|
|
|
|
2024-08-15 15:50:01 +00:00
|
|
|
unsetRepoSize :: UUID -> SqlPersistM ()
|
|
|
|
unsetRepoSize u = deleteWhere [RepoSizesRepo ==. u]
|
2024-08-12 15:19:58 +00:00
|
|
|
|
2024-08-15 15:50:01 +00:00
|
|
|
recordAnnexBranchCommit :: Sha -> SqlPersistM ()
|
|
|
|
recordAnnexBranchCommit branchcommitsha = do
|
|
|
|
deleteWhere ([] :: [Filter AnnexBranch])
|
|
|
|
void $ insertUniqueFast $ AnnexBranch $ toSSha branchcommitsha
|
2024-08-23 16:51:00 +00:00
|
|
|
|
2024-08-25 14:34:47 +00:00
|
|
|
startingLiveSizeChange :: RepoSizeHandle -> UUID -> Key -> SizeChange -> SizeChangeId -> IO ()
|
2024-08-28 17:52:59 +00:00
|
|
|
startingLiveSizeChange (RepoSizeHandle (Just h) _) u k sc cid =
|
2024-08-23 20:35:12 +00:00
|
|
|
H.commitDb h $ void $ upsertBy
|
2024-08-28 17:52:59 +00:00
|
|
|
(UniqueLiveSizeChange u k
|
|
|
|
(sizeChangeUniqueId cid)
|
|
|
|
(sizeChangeProcessId cid))
|
|
|
|
(LiveSizeChanges u k
|
|
|
|
(sizeChangeUniqueId cid)
|
|
|
|
(sizeChangeProcessId cid)
|
|
|
|
sc)
|
2024-08-25 14:34:47 +00:00
|
|
|
[ LiveSizeChangesChange =. sc
|
2024-08-28 17:52:59 +00:00
|
|
|
, LiveSizeChangesChangeid =. sizeChangeUniqueId cid
|
|
|
|
, LiveSizeChangesChangepid =. sizeChangeProcessId cid
|
2024-08-25 14:34:47 +00:00
|
|
|
]
|
2024-08-28 17:52:59 +00:00
|
|
|
startingLiveSizeChange (RepoSizeHandle Nothing _) _ _ _ _ = noop
|
2024-08-25 14:34:47 +00:00
|
|
|
|
closing in on finishing live reposizes
Fixed successfullyFinishedLiveSizeChange to not update the rolling total
when a redundant change is in RecentChanges.
Made setRepoSizes clear RecentChanges that are no longer needed.
It might be possible to clear those earlier, this is only a convenient
point to do it.
The reason it's safe to clear RecentChanges here is that, in order for a
live update to call successfullyFinishedLiveSizeChange, a change must be
made to a location log. If a RecentChange gets cleared, and just after
that a new live update is started, making the same change, the location
log has already been changed (since the RecentChange exists), and
so when the live update succeeds, it won't call
successfullyFinishedLiveSizeChange. The reason it doesn't
clear RecentChanges when there is a reduntant live update is because
I didn't want to think through whether or not all races are avoided in
that case.
The rolling total in SizeChanges is never cleared. Instead,
calcJournalledRepoSizes gets the initial value of it, and then
getLiveRepoSizes subtracts that initial value from the current value.
Since the rolling total can only be updated by updateRepoSize,
which is called with the journal locked, locking the journal in
calcJournalledRepoSizes ensures that the database does not change while
reading the journal.
2024-08-27 15:04:27 +00:00
|
|
|
{- A live size change has successfully finished.
|
|
|
|
-
|
|
|
|
- Update the rolling total, add as a recent change,
|
|
|
|
- and remove the live change in the same transaction.
|
|
|
|
-
|
|
|
|
- But, it's possible that the same change has been done by two
|
|
|
|
- different processes or threads. If there is a matching recent change,
|
|
|
|
- then this one is redundant, so remove it without updating the rolling
|
|
|
|
- total.
|
|
|
|
-}
|
2024-08-25 14:34:47 +00:00
|
|
|
successfullyFinishedLiveSizeChange :: RepoSizeHandle -> UUID -> Key -> SizeChange -> SizeChangeId -> IO ()
|
2024-08-28 17:52:59 +00:00
|
|
|
successfullyFinishedLiveSizeChange (RepoSizeHandle (Just h) _) u k sc cid =
|
2024-08-25 14:34:47 +00:00
|
|
|
H.commitDb h $ do
|
closing in on finishing live reposizes
Fixed successfullyFinishedLiveSizeChange to not update the rolling total
when a redundant change is in RecentChanges.
Made setRepoSizes clear RecentChanges that are no longer needed.
It might be possible to clear those earlier, this is only a convenient
point to do it.
The reason it's safe to clear RecentChanges here is that, in order for a
live update to call successfullyFinishedLiveSizeChange, a change must be
made to a location log. If a RecentChange gets cleared, and just after
that a new live update is started, making the same change, the location
log has already been changed (since the RecentChange exists), and
so when the live update succeeds, it won't call
successfullyFinishedLiveSizeChange. The reason it doesn't
clear RecentChanges when there is a reduntant live update is because
I didn't want to think through whether or not all races are avoided in
that case.
The rolling total in SizeChanges is never cleared. Instead,
calcJournalledRepoSizes gets the initial value of it, and then
getLiveRepoSizes subtracts that initial value from the current value.
Since the rolling total can only be updated by updateRepoSize,
which is called with the journal locked, locking the journal in
calcJournalledRepoSizes ensures that the database does not change while
reading the journal.
2024-08-27 15:04:27 +00:00
|
|
|
getRecentChange u k >>= \case
|
|
|
|
Just sc' | sc == sc' -> remove
|
|
|
|
_ -> go
|
|
|
|
where
|
|
|
|
go = do
|
2024-08-25 14:34:47 +00:00
|
|
|
rollingtotal <- getSizeChangeFor u
|
2024-08-26 18:50:09 +00:00
|
|
|
setSizeChangeFor u (updateRollingTotal rollingtotal sc k)
|
|
|
|
addRecentChange u k sc
|
closing in on finishing live reposizes
Fixed successfullyFinishedLiveSizeChange to not update the rolling total
when a redundant change is in RecentChanges.
Made setRepoSizes clear RecentChanges that are no longer needed.
It might be possible to clear those earlier, this is only a convenient
point to do it.
The reason it's safe to clear RecentChanges here is that, in order for a
live update to call successfullyFinishedLiveSizeChange, a change must be
made to a location log. If a RecentChange gets cleared, and just after
that a new live update is started, making the same change, the location
log has already been changed (since the RecentChange exists), and
so when the live update succeeds, it won't call
successfullyFinishedLiveSizeChange. The reason it doesn't
clear RecentChanges when there is a reduntant live update is because
I didn't want to think through whether or not all races are avoided in
that case.
The rolling total in SizeChanges is never cleared. Instead,
calcJournalledRepoSizes gets the initial value of it, and then
getLiveRepoSizes subtracts that initial value from the current value.
Since the rolling total can only be updated by updateRepoSize,
which is called with the journal locked, locking the journal in
calcJournalledRepoSizes ensures that the database does not change while
reading the journal.
2024-08-27 15:04:27 +00:00
|
|
|
remove
|
2024-08-28 17:52:59 +00:00
|
|
|
remove = removeLiveSizeChange u k sc cid
|
|
|
|
successfullyFinishedLiveSizeChange (RepoSizeHandle Nothing _) _ _ _ _ = noop
|
2024-08-25 14:34:47 +00:00
|
|
|
|
2024-08-26 18:50:09 +00:00
|
|
|
updateRollingTotal :: FileSize -> SizeChange -> Key -> FileSize
|
|
|
|
updateRollingTotal t sc k = case sc of
|
|
|
|
AddingKey -> t + ksz
|
|
|
|
RemovingKey -> t - ksz
|
|
|
|
where
|
|
|
|
ksz = fromMaybe 0 $ fromKey keySize k
|
|
|
|
|
|
|
|
removeStaleLiveSizeChange :: RepoSizeHandle -> UUID -> Key -> SizeChange -> SizeChangeId -> IO ()
|
2024-08-28 17:52:59 +00:00
|
|
|
removeStaleLiveSizeChange (RepoSizeHandle (Just h) _) u k sc cid =
|
|
|
|
H.commitDb h $ removeLiveSizeChange u k sc cid
|
|
|
|
removeStaleLiveSizeChange (RepoSizeHandle Nothing _) _ _ _ _ = noop
|
2024-08-25 14:34:47 +00:00
|
|
|
|
|
|
|
removeLiveSizeChange :: UUID -> Key -> SizeChange -> SizeChangeId -> SqlPersistM ()
|
2024-08-28 17:52:59 +00:00
|
|
|
removeLiveSizeChange u k sc cid =
|
2024-08-25 14:34:47 +00:00
|
|
|
deleteWhere
|
2024-08-23 20:35:12 +00:00
|
|
|
[ LiveSizeChangesRepo ==. u
|
|
|
|
, LiveSizeChangesKey ==. k
|
2024-08-28 17:52:59 +00:00
|
|
|
, LiveSizeChangesChangeid ==. sizeChangeUniqueId cid
|
|
|
|
, LiveSizeChangesChangepid ==. sizeChangeProcessId cid
|
2024-08-23 20:35:12 +00:00
|
|
|
, LiveSizeChangesChange ==. sc
|
|
|
|
]
|
2024-08-23 16:51:00 +00:00
|
|
|
|
2024-08-28 17:52:59 +00:00
|
|
|
removeStaleLiveSizeChanges :: RepoSizeHandle -> [StaleSizeChanger] -> IO ()
|
|
|
|
removeStaleLiveSizeChanges (RepoSizeHandle (Just h) _) stale = do
|
|
|
|
let stalepids = map staleSizeChangerProcessId stale
|
|
|
|
H.commitDb h $ deleteWhere [ LiveSizeChangesChangepid <-. stalepids ]
|
|
|
|
removeStaleLiveSizeChanges (RepoSizeHandle Nothing _) _ = noop
|
|
|
|
|
2024-08-28 15:00:59 +00:00
|
|
|
getLiveSizeChangesMap :: SqlPersistM (M.Map UUID [(Key, (SizeChange, SizeChangeId))])
|
|
|
|
getLiveSizeChangesMap = M.fromListWith (++) . map conv <$> getLiveSizeChanges
|
2024-08-23 16:51:00 +00:00
|
|
|
where
|
2024-08-28 17:52:59 +00:00
|
|
|
conv (LiveSizeChanges u k cid pid sc) = (u, [(k, (sc, sid))])
|
|
|
|
where
|
|
|
|
sid = SizeChangeId cid pid
|
2024-08-25 14:34:47 +00:00
|
|
|
|
2024-08-28 15:00:59 +00:00
|
|
|
getLiveSizeChangesList :: SqlPersistM [(UUID, Key, SizeChange)]
|
|
|
|
getLiveSizeChangesList = map conv <$> getLiveSizeChanges
|
closing in on finishing live reposizes
Fixed successfullyFinishedLiveSizeChange to not update the rolling total
when a redundant change is in RecentChanges.
Made setRepoSizes clear RecentChanges that are no longer needed.
It might be possible to clear those earlier, this is only a convenient
point to do it.
The reason it's safe to clear RecentChanges here is that, in order for a
live update to call successfullyFinishedLiveSizeChange, a change must be
made to a location log. If a RecentChange gets cleared, and just after
that a new live update is started, making the same change, the location
log has already been changed (since the RecentChange exists), and
so when the live update succeeds, it won't call
successfullyFinishedLiveSizeChange. The reason it doesn't
clear RecentChanges when there is a reduntant live update is because
I didn't want to think through whether or not all races are avoided in
that case.
The rolling total in SizeChanges is never cleared. Instead,
calcJournalledRepoSizes gets the initial value of it, and then
getLiveRepoSizes subtracts that initial value from the current value.
Since the rolling total can only be updated by updateRepoSize,
which is called with the journal locked, locking the journal in
calcJournalledRepoSizes ensures that the database does not change while
reading the journal.
2024-08-27 15:04:27 +00:00
|
|
|
where
|
2024-08-28 17:52:59 +00:00
|
|
|
conv (LiveSizeChanges u k _cid _pid sc) = (u, k, sc)
|
2024-08-28 15:00:59 +00:00
|
|
|
|
|
|
|
getLiveSizeChanges :: SqlPersistM [LiveSizeChanges]
|
|
|
|
getLiveSizeChanges = map entityVal <$> selectList [] []
|
closing in on finishing live reposizes
Fixed successfullyFinishedLiveSizeChange to not update the rolling total
when a redundant change is in RecentChanges.
Made setRepoSizes clear RecentChanges that are no longer needed.
It might be possible to clear those earlier, this is only a convenient
point to do it.
The reason it's safe to clear RecentChanges here is that, in order for a
live update to call successfullyFinishedLiveSizeChange, a change must be
made to a location log. If a RecentChange gets cleared, and just after
that a new live update is started, making the same change, the location
log has already been changed (since the RecentChange exists), and
so when the live update succeeds, it won't call
successfullyFinishedLiveSizeChange. The reason it doesn't
clear RecentChanges when there is a reduntant live update is because
I didn't want to think through whether or not all races are avoided in
that case.
The rolling total in SizeChanges is never cleared. Instead,
calcJournalledRepoSizes gets the initial value of it, and then
getLiveRepoSizes subtracts that initial value from the current value.
Since the rolling total can only be updated by updateRepoSize,
which is called with the journal locked, locking the journal in
calcJournalledRepoSizes ensures that the database does not change while
reading the journal.
2024-08-27 15:04:27 +00:00
|
|
|
|
2024-08-26 18:50:09 +00:00
|
|
|
getSizeChanges :: SqlPersistM (M.Map UUID FileSize)
|
|
|
|
getSizeChanges = M.fromList . map conv <$> selectList [] []
|
2024-08-25 14:34:47 +00:00
|
|
|
where
|
|
|
|
conv entity =
|
|
|
|
let SizeChanges u n = entityVal entity
|
|
|
|
in (u, n)
|
|
|
|
|
|
|
|
getSizeChangeFor :: UUID -> SqlPersistM FileSize
|
|
|
|
getSizeChangeFor u = do
|
|
|
|
l <- selectList [SizeChangesRepo ==. u] []
|
|
|
|
return $ case l of
|
|
|
|
(s:_) -> sizeChangesRollingtotal $ entityVal s
|
|
|
|
[] -> 0
|
|
|
|
|
|
|
|
setSizeChangeFor :: UUID -> FileSize -> SqlPersistM ()
|
|
|
|
setSizeChangeFor u sz =
|
|
|
|
void $ upsertBy
|
|
|
|
(UniqueRepoRollingTotal u)
|
|
|
|
(SizeChanges u sz)
|
|
|
|
[SizeChangesRollingtotal =. sz]
|
closing in on finishing live reposizes
Fixed successfullyFinishedLiveSizeChange to not update the rolling total
when a redundant change is in RecentChanges.
Made setRepoSizes clear RecentChanges that are no longer needed.
It might be possible to clear those earlier, this is only a convenient
point to do it.
The reason it's safe to clear RecentChanges here is that, in order for a
live update to call successfullyFinishedLiveSizeChange, a change must be
made to a location log. If a RecentChange gets cleared, and just after
that a new live update is started, making the same change, the location
log has already been changed (since the RecentChange exists), and
so when the live update succeeds, it won't call
successfullyFinishedLiveSizeChange. The reason it doesn't
clear RecentChanges when there is a reduntant live update is because
I didn't want to think through whether or not all races are avoided in
that case.
The rolling total in SizeChanges is never cleared. Instead,
calcJournalledRepoSizes gets the initial value of it, and then
getLiveRepoSizes subtracts that initial value from the current value.
Since the rolling total can only be updated by updateRepoSize,
which is called with the journal locked, locking the journal in
calcJournalledRepoSizes ensures that the database does not change while
reading the journal.
2024-08-27 15:04:27 +00:00
|
|
|
|
2024-09-23 16:28:18 +00:00
|
|
|
setSizeChanges :: RepoSizeHandle -> M.Map UUID FileSize -> IO ()
|
|
|
|
setSizeChanges (RepoSizeHandle (Just h) _) sizemap =
|
|
|
|
H.commitDb h $ forM_ (M.toList sizemap) $ uncurry setSizeChangeFor
|
|
|
|
setSizeChanges (RepoSizeHandle Nothing _) _ = noop
|
|
|
|
|
2024-08-26 18:50:09 +00:00
|
|
|
addRecentChange :: UUID -> Key -> SizeChange -> SqlPersistM ()
|
|
|
|
addRecentChange u k sc =
|
|
|
|
void $ upsertBy
|
|
|
|
(UniqueRecentChange u k)
|
|
|
|
(RecentChanges u k sc)
|
|
|
|
[RecentChangesChange =. sc]
|
|
|
|
|
|
|
|
getRecentChange :: UUID -> Key -> SqlPersistM (Maybe SizeChange)
|
|
|
|
getRecentChange u k = do
|
|
|
|
l <- selectList
|
|
|
|
[ RecentChangesRepo ==. u
|
|
|
|
, RecentChangesKey ==. k
|
|
|
|
] []
|
|
|
|
return $ case l of
|
|
|
|
(s:_) -> Just $ recentChangesChange $ entityVal s
|
|
|
|
[] -> Nothing
|
|
|
|
|
closing in on finishing live reposizes
Fixed successfullyFinishedLiveSizeChange to not update the rolling total
when a redundant change is in RecentChanges.
Made setRepoSizes clear RecentChanges that are no longer needed.
It might be possible to clear those earlier, this is only a convenient
point to do it.
The reason it's safe to clear RecentChanges here is that, in order for a
live update to call successfullyFinishedLiveSizeChange, a change must be
made to a location log. If a RecentChange gets cleared, and just after
that a new live update is started, making the same change, the location
log has already been changed (since the RecentChange exists), and
so when the live update succeeds, it won't call
successfullyFinishedLiveSizeChange. The reason it doesn't
clear RecentChanges when there is a reduntant live update is because
I didn't want to think through whether or not all races are avoided in
that case.
The rolling total in SizeChanges is never cleared. Instead,
calcJournalledRepoSizes gets the initial value of it, and then
getLiveRepoSizes subtracts that initial value from the current value.
Since the rolling total can only be updated by updateRepoSize,
which is called with the journal locked, locking the journal in
calcJournalledRepoSizes ensures that the database does not change while
reading the journal.
2024-08-27 15:04:27 +00:00
|
|
|
getRecentChanges :: SqlPersistM [(UUID, Key, SizeChange)]
|
|
|
|
getRecentChanges = map conv <$> selectList [] []
|
|
|
|
where
|
|
|
|
conv entity =
|
|
|
|
let RecentChanges u k sc = entityVal entity
|
|
|
|
in (u, k, sc)
|
|
|
|
|
|
|
|
{- Clears recent changes, except when there is a live change that is
|
|
|
|
- redundant with a recent change. -}
|
|
|
|
clearRecentChanges :: SqlPersistM ()
|
|
|
|
clearRecentChanges = do
|
2024-08-28 15:00:59 +00:00
|
|
|
live <- getLiveSizeChangesList
|
closing in on finishing live reposizes
Fixed successfullyFinishedLiveSizeChange to not update the rolling total
when a redundant change is in RecentChanges.
Made setRepoSizes clear RecentChanges that are no longer needed.
It might be possible to clear those earlier, this is only a convenient
point to do it.
The reason it's safe to clear RecentChanges here is that, in order for a
live update to call successfullyFinishedLiveSizeChange, a change must be
made to a location log. If a RecentChange gets cleared, and just after
that a new live update is started, making the same change, the location
log has already been changed (since the RecentChange exists), and
so when the live update succeeds, it won't call
successfullyFinishedLiveSizeChange. The reason it doesn't
clear RecentChanges when there is a reduntant live update is because
I didn't want to think through whether or not all races are avoided in
that case.
The rolling total in SizeChanges is never cleared. Instead,
calcJournalledRepoSizes gets the initial value of it, and then
getLiveRepoSizes subtracts that initial value from the current value.
Since the rolling total can only be updated by updateRepoSize,
which is called with the journal locked, locking the journal in
calcJournalledRepoSizes ensures that the database does not change while
reading the journal.
2024-08-27 15:04:27 +00:00
|
|
|
if null live
|
|
|
|
then deleteWhere ([] :: [Filter RecentChanges])
|
|
|
|
else do
|
|
|
|
let liveset = S.fromList live
|
|
|
|
rcs <- getRecentChanges
|
|
|
|
forM_ rcs $ \rc@(u, k, sc) ->
|
|
|
|
when (S.notMember rc liveset) $
|
|
|
|
deleteWhere
|
|
|
|
[ RecentChangesRepo ==. u
|
|
|
|
, RecentChangesKey ==. k
|
|
|
|
, RecentChangesChange ==. sc
|
|
|
|
]
|
|
|
|
|
|
|
|
{- Gets the recorded offsets to sizes of Repos, not including live
|
|
|
|
- changes. -}
|
|
|
|
recordedRepoOffsets :: RepoSizeHandle -> IO (M.Map UUID SizeOffset)
|
2024-08-28 17:52:59 +00:00
|
|
|
recordedRepoOffsets (RepoSizeHandle (Just h) _) =
|
closing in on finishing live reposizes
Fixed successfullyFinishedLiveSizeChange to not update the rolling total
when a redundant change is in RecentChanges.
Made setRepoSizes clear RecentChanges that are no longer needed.
It might be possible to clear those earlier, this is only a convenient
point to do it.
The reason it's safe to clear RecentChanges here is that, in order for a
live update to call successfullyFinishedLiveSizeChange, a change must be
made to a location log. If a RecentChange gets cleared, and just after
that a new live update is started, making the same change, the location
log has already been changed (since the RecentChange exists), and
so when the live update succeeds, it won't call
successfullyFinishedLiveSizeChange. The reason it doesn't
clear RecentChanges when there is a reduntant live update is because
I didn't want to think through whether or not all races are avoided in
that case.
The rolling total in SizeChanges is never cleared. Instead,
calcJournalledRepoSizes gets the initial value of it, and then
getLiveRepoSizes subtracts that initial value from the current value.
Since the rolling total can only be updated by updateRepoSize,
which is called with the journal locked, locking the journal in
calcJournalledRepoSizes ensures that the database does not change while
reading the journal.
2024-08-27 15:04:27 +00:00
|
|
|
M.map SizeOffset <$> H.queryDb h getSizeChanges
|
2024-08-28 17:52:59 +00:00
|
|
|
recordedRepoOffsets (RepoSizeHandle Nothing _) = pure mempty
|
closing in on finishing live reposizes
Fixed successfullyFinishedLiveSizeChange to not update the rolling total
when a redundant change is in RecentChanges.
Made setRepoSizes clear RecentChanges that are no longer needed.
It might be possible to clear those earlier, this is only a convenient
point to do it.
The reason it's safe to clear RecentChanges here is that, in order for a
live update to call successfullyFinishedLiveSizeChange, a change must be
made to a location log. If a RecentChange gets cleared, and just after
that a new live update is started, making the same change, the location
log has already been changed (since the RecentChange exists), and
so when the live update succeeds, it won't call
successfullyFinishedLiveSizeChange. The reason it doesn't
clear RecentChanges when there is a reduntant live update is because
I didn't want to think through whether or not all races are avoided in
that case.
The rolling total in SizeChanges is never cleared. Instead,
calcJournalledRepoSizes gets the initial value of it, and then
getLiveRepoSizes subtracts that initial value from the current value.
Since the rolling total can only be updated by updateRepoSize,
which is called with the journal locked, locking the journal in
calcJournalledRepoSizes ensures that the database does not change while
reading the journal.
2024-08-27 15:04:27 +00:00
|
|
|
|
|
|
|
{- Gets the offsets to sizes of Repos, including all live changes that
|
2024-08-28 18:13:12 +00:00
|
|
|
- are happening now whose SizeChange matches the provided function.
|
2024-08-26 18:50:09 +00:00
|
|
|
-
|
closing in on finishing live reposizes
Fixed successfullyFinishedLiveSizeChange to not update the rolling total
when a redundant change is in RecentChanges.
Made setRepoSizes clear RecentChanges that are no longer needed.
It might be possible to clear those earlier, this is only a convenient
point to do it.
The reason it's safe to clear RecentChanges here is that, in order for a
live update to call successfullyFinishedLiveSizeChange, a change must be
made to a location log. If a RecentChange gets cleared, and just after
that a new live update is started, making the same change, the location
log has already been changed (since the RecentChange exists), and
so when the live update succeeds, it won't call
successfullyFinishedLiveSizeChange. The reason it doesn't
clear RecentChanges when there is a reduntant live update is because
I didn't want to think through whether or not all races are avoided in
that case.
The rolling total in SizeChanges is never cleared. Instead,
calcJournalledRepoSizes gets the initial value of it, and then
getLiveRepoSizes subtracts that initial value from the current value.
Since the rolling total can only be updated by updateRepoSize,
which is called with the journal locked, locking the journal in
calcJournalledRepoSizes ensures that the database does not change while
reading the journal.
2024-08-27 15:04:27 +00:00
|
|
|
- This does not necessarily include all changes that have been made,
|
2024-08-26 18:50:09 +00:00
|
|
|
- only ones that had startingLiveSizeChange called for them will be
|
closing in on finishing live reposizes
Fixed successfullyFinishedLiveSizeChange to not update the rolling total
when a redundant change is in RecentChanges.
Made setRepoSizes clear RecentChanges that are no longer needed.
It might be possible to clear those earlier, this is only a convenient
point to do it.
The reason it's safe to clear RecentChanges here is that, in order for a
live update to call successfullyFinishedLiveSizeChange, a change must be
made to a location log. If a RecentChange gets cleared, and just after
that a new live update is started, making the same change, the location
log has already been changed (since the RecentChange exists), and
so when the live update succeeds, it won't call
successfullyFinishedLiveSizeChange. The reason it doesn't
clear RecentChanges when there is a reduntant live update is because
I didn't want to think through whether or not all races are avoided in
that case.
The rolling total in SizeChanges is never cleared. Instead,
calcJournalledRepoSizes gets the initial value of it, and then
getLiveRepoSizes subtracts that initial value from the current value.
Since the rolling total can only be updated by updateRepoSize,
which is called with the journal locked, locking the journal in
calcJournalledRepoSizes ensures that the database does not change while
reading the journal.
2024-08-27 15:04:27 +00:00
|
|
|
- included.
|
2024-08-26 18:50:09 +00:00
|
|
|
-
|
|
|
|
- In the unlikely case where two live changes are occurring, one
|
|
|
|
- adding a key and the other removing the same key, the one
|
|
|
|
- adding the key is used, in order to err on the side of a larger
|
closing in on finishing live reposizes
Fixed successfullyFinishedLiveSizeChange to not update the rolling total
when a redundant change is in RecentChanges.
Made setRepoSizes clear RecentChanges that are no longer needed.
It might be possible to clear those earlier, this is only a convenient
point to do it.
The reason it's safe to clear RecentChanges here is that, in order for a
live update to call successfullyFinishedLiveSizeChange, a change must be
made to a location log. If a RecentChange gets cleared, and just after
that a new live update is started, making the same change, the location
log has already been changed (since the RecentChange exists), and
so when the live update succeeds, it won't call
successfullyFinishedLiveSizeChange. The reason it doesn't
clear RecentChanges when there is a reduntant live update is because
I didn't want to think through whether or not all races are avoided in
that case.
The rolling total in SizeChanges is never cleared. Instead,
calcJournalledRepoSizes gets the initial value of it, and then
getLiveRepoSizes subtracts that initial value from the current value.
Since the rolling total can only be updated by updateRepoSize,
which is called with the journal locked, locking the journal in
calcJournalledRepoSizes ensures that the database does not change while
reading the journal.
2024-08-27 15:04:27 +00:00
|
|
|
- repository size.
|
2024-08-26 18:50:09 +00:00
|
|
|
-
|
2024-08-27 13:18:25 +00:00
|
|
|
- In the case where the same live change is recorded by two different
|
|
|
|
- processes or threads, the first to complete will record it as a recent
|
|
|
|
- change. This omits live changes that are redundant due to a recent
|
|
|
|
- change already being recorded for the same change.
|
2024-08-26 18:50:09 +00:00
|
|
|
-
|
|
|
|
- This is only expensive when there are a lot of live changes happening at
|
|
|
|
- the same time.
|
|
|
|
-}
|
2024-08-28 18:13:12 +00:00
|
|
|
liveRepoOffsets :: RepoSizeHandle -> (SizeChange -> Bool) -> IO (M.Map UUID SizeOffset)
|
|
|
|
liveRepoOffsets (RepoSizeHandle (Just h) _) wantedsizechange = H.queryDb h $ do
|
closing in on finishing live reposizes
Fixed successfullyFinishedLiveSizeChange to not update the rolling total
when a redundant change is in RecentChanges.
Made setRepoSizes clear RecentChanges that are no longer needed.
It might be possible to clear those earlier, this is only a convenient
point to do it.
The reason it's safe to clear RecentChanges here is that, in order for a
live update to call successfullyFinishedLiveSizeChange, a change must be
made to a location log. If a RecentChange gets cleared, and just after
that a new live update is started, making the same change, the location
log has already been changed (since the RecentChange exists), and
so when the live update succeeds, it won't call
successfullyFinishedLiveSizeChange. The reason it doesn't
clear RecentChanges when there is a reduntant live update is because
I didn't want to think through whether or not all races are avoided in
that case.
The rolling total in SizeChanges is never cleared. Instead,
calcJournalledRepoSizes gets the initial value of it, and then
getLiveRepoSizes subtracts that initial value from the current value.
Since the rolling total can only be updated by updateRepoSize,
which is called with the journal locked, locking the journal in
calcJournalledRepoSizes ensures that the database does not change while
reading the journal.
2024-08-27 15:04:27 +00:00
|
|
|
sizechanges <- getSizeChanges
|
2024-08-28 15:00:59 +00:00
|
|
|
livechanges <- getLiveSizeChangesMap
|
2024-08-27 19:00:10 +00:00
|
|
|
let us = S.toList $ S.fromList $
|
|
|
|
M.keys sizechanges ++ M.keys livechanges
|
closing in on finishing live reposizes
Fixed successfullyFinishedLiveSizeChange to not update the rolling total
when a redundant change is in RecentChanges.
Made setRepoSizes clear RecentChanges that are no longer needed.
It might be possible to clear those earlier, this is only a convenient
point to do it.
The reason it's safe to clear RecentChanges here is that, in order for a
live update to call successfullyFinishedLiveSizeChange, a change must be
made to a location log. If a RecentChange gets cleared, and just after
that a new live update is started, making the same change, the location
log has already been changed (since the RecentChange exists), and
so when the live update succeeds, it won't call
successfullyFinishedLiveSizeChange. The reason it doesn't
clear RecentChanges when there is a reduntant live update is because
I didn't want to think through whether or not all races are avoided in
that case.
The rolling total in SizeChanges is never cleared. Instead,
calcJournalledRepoSizes gets the initial value of it, and then
getLiveRepoSizes subtracts that initial value from the current value.
Since the rolling total can only be updated by updateRepoSize,
which is called with the journal locked, locking the journal in
calcJournalledRepoSizes ensures that the database does not change while
reading the journal.
2024-08-27 15:04:27 +00:00
|
|
|
M.fromList <$> forM us (go sizechanges livechanges)
|
2024-08-26 18:50:09 +00:00
|
|
|
where
|
closing in on finishing live reposizes
Fixed successfullyFinishedLiveSizeChange to not update the rolling total
when a redundant change is in RecentChanges.
Made setRepoSizes clear RecentChanges that are no longer needed.
It might be possible to clear those earlier, this is only a convenient
point to do it.
The reason it's safe to clear RecentChanges here is that, in order for a
live update to call successfullyFinishedLiveSizeChange, a change must be
made to a location log. If a RecentChange gets cleared, and just after
that a new live update is started, making the same change, the location
log has already been changed (since the RecentChange exists), and
so when the live update succeeds, it won't call
successfullyFinishedLiveSizeChange. The reason it doesn't
clear RecentChanges when there is a reduntant live update is because
I didn't want to think through whether or not all races are avoided in
that case.
The rolling total in SizeChanges is never cleared. Instead,
calcJournalledRepoSizes gets the initial value of it, and then
getLiveRepoSizes subtracts that initial value from the current value.
Since the rolling total can only be updated by updateRepoSize,
which is called with the journal locked, locking the journal in
calcJournalledRepoSizes ensures that the database does not change while
reading the journal.
2024-08-27 15:04:27 +00:00
|
|
|
go sizechanges livechanges u = do
|
2024-08-26 18:50:09 +00:00
|
|
|
let livechangesbykey =
|
2024-08-27 13:18:25 +00:00
|
|
|
M.fromListWith (++) $
|
|
|
|
map (\(k, v) -> (k, [v])) $
|
|
|
|
fromMaybe [] $
|
|
|
|
M.lookup u livechanges
|
2024-08-26 18:50:09 +00:00
|
|
|
livechanges' <- combinelikelivechanges <$>
|
|
|
|
filterM (nonredundantlivechange livechangesbykey u)
|
|
|
|
(fromMaybe [] $ M.lookup u livechanges)
|
|
|
|
let sizechange = foldl'
|
2024-08-28 18:13:12 +00:00
|
|
|
(\t (k, sc) -> if wantedsizechange sc then updateRollingTotal t sc k else t)
|
2024-08-26 18:50:09 +00:00
|
|
|
(fromMaybe 0 (M.lookup u sizechanges))
|
|
|
|
livechanges'
|
closing in on finishing live reposizes
Fixed successfullyFinishedLiveSizeChange to not update the rolling total
when a redundant change is in RecentChanges.
Made setRepoSizes clear RecentChanges that are no longer needed.
It might be possible to clear those earlier, this is only a convenient
point to do it.
The reason it's safe to clear RecentChanges here is that, in order for a
live update to call successfullyFinishedLiveSizeChange, a change must be
made to a location log. If a RecentChange gets cleared, and just after
that a new live update is started, making the same change, the location
log has already been changed (since the RecentChange exists), and
so when the live update succeeds, it won't call
successfullyFinishedLiveSizeChange. The reason it doesn't
clear RecentChanges when there is a reduntant live update is because
I didn't want to think through whether or not all races are avoided in
that case.
The rolling total in SizeChanges is never cleared. Instead,
calcJournalledRepoSizes gets the initial value of it, and then
getLiveRepoSizes subtracts that initial value from the current value.
Since the rolling total can only be updated by updateRepoSize,
which is called with the journal locked, locking the journal in
calcJournalledRepoSizes ensures that the database does not change while
reading the journal.
2024-08-27 15:04:27 +00:00
|
|
|
return (u, SizeOffset sizechange)
|
2024-08-26 18:50:09 +00:00
|
|
|
|
|
|
|
combinelikelivechanges =
|
|
|
|
S.elems
|
|
|
|
. S.fromList
|
|
|
|
. map (\(k, (sc, _)) -> (k, sc))
|
|
|
|
|
|
|
|
nonredundantlivechange livechangesbykey u (k, (sc, cid))
|
|
|
|
| null (competinglivechanges livechangesbykey k sc cid) =
|
|
|
|
getRecentChange u k >>= pure . \case
|
|
|
|
Nothing -> True
|
|
|
|
Just sc' -> sc /= sc'
|
|
|
|
| otherwise = pure False
|
|
|
|
|
|
|
|
competinglivechanges livechangesbykey k RemovingKey cid =
|
|
|
|
filter (\(sc', cid') -> cid /= cid' && sc' == AddingKey)
|
|
|
|
(fromMaybe [] $ M.lookup k livechangesbykey)
|
|
|
|
competinglivechanges _ _ AddingKey _ = []
|
2024-08-28 18:13:12 +00:00
|
|
|
liveRepoOffsets (RepoSizeHandle Nothing _) _ = pure mempty
|