git-annex/doc/bugs/enormous_fsck_output_OOM.mdwn
Joey Hess 67f09bca6d fully fix fsck memory use by iterative fscking
Not very well tested, but I'm sure it doesn't eg, loop forever.
2014-03-12 15:18:43 -04:00

30 lines
1.3 KiB
Markdown

Hi,
My Webapp isn't working:
$ git-annex webapp error: refs/gcrypt/gitception+ does not point to a valid object!
error: refs/remotes/Beta/git-annex does not point to a valid object!
error: refs/remotes/Beta/master does not point to a valid object!
fatal: unable to read tree 656e7db5be172f01c0b6994d01f1a08d1273af12
So I tried to repair it:
$ git-annex repair Running git fsck ...
Stack space overflow: current size 8388608 bytes. Use `+RTS -Ksize -RTS' to increase it.
So I tried to follow your advice here and increase the stack:
$ git-annex +RTS -K35000000 -RTS fsck
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]]