fully fix fsck memory use by iterative fscking
Not very well tested, but I'm sure it doesn't eg, loop forever.
This commit is contained in:
parent
475bf70af6
commit
67f09bca6d
4 changed files with 108 additions and 57 deletions
|
@ -18,3 +18,13 @@ So I tried to follow your advice here and increase the stack:
|
|||
git-annex: Most RTS options are disabled. Link with -rtsopts to enable them.
|
||||
|
||||
I wasn't sure what to do next, so any help would be appreciated.
|
||||
|
||||
> Now only 20k problem shas max (more likely 10k) are collected from fsck,
|
||||
> so it won't use much memory (60 mb or so). If it had to truncate
|
||||
> shas from fsck, it will re-run fsck after the repair process,
|
||||
> which should either find no problems left (common when eg when all missing shas
|
||||
> were able to be fetched from remotes), or find a new set of problem
|
||||
> shas, which it can feed back through the repair process.
|
||||
>
|
||||
> If the repository is very large, this means more work, but it shouldn't
|
||||
> run out of memory now. [[fixed|done]] --[[Joey]]
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue