Please describe the problem.
The assistant regulary ends up trying to perform repair (I don't know why, it happens fairly often, once a week or so). When it does so, it ends up creating a huge (2.4G) .git/objects directory, and a git prune-packed process uses so much I/O the machine really slows down.
What steps will reproduce the problem?
I don't have any reliable way to reproduce it. The repository ends up being attempted to be repaired around once a week. This week the repair (and the slowdown) also happened on a second computer.
What version of git-annex are you using? On what operating system?
git-annex version: 5.20140221-gbdfc8e1 (using the standalone 64bit builds)
This is on an up-to-date Arch Linux. It also happened on Fedora 20.
Please provide any additional information below.
The daemon.log is fairly long, but not particulary interesting: https://ssl.zerodogg.org/~zerodogg/private/tmp/daemon.log-2014-02-25.1
The «resource vanished (Broken pipe)» at the end is the result of me killing the prune-packed in order to be able to use the machine again.
Auto repair is not intended to be a common occurrance. It means something went badly, horribly wrong on your machine, and it lost data that git wrote to disk. It's more important in such a scenraio to get back to a working system eventually than to do something fast or inexpensively.
If you're seeing the need for auto repair on a weekly basis, your computer is failing in a horrible way horribly frequently, and the thing to do is to find out why, and fix that. Perhaps you need to start cleanly shutting down the system. Perhaps something is causing your computer to crash, and you need to fix that.
That's the thing. The drive is fine, I've fscked it, and the machine is always shut down cleanly (and it is very stable, can't remember the last time it crashed). So there's no reason why this should be happening, and since git-annex doesn't say anything about why it started the auto-repair, I'm unable to track it down further.
It's also always this repository. I have several assistant managed repos on the same machine, and this is the only one that git-annex regulary starts repairing (and the only one that it has auto-repaired on another box as well). No files in the repository itself has ever been noticed as corrupt, nor has there been any indications anywhere else about problems, hardware or filesystem (nothing wrong in the 40 or so git repos on the machine, no problems with software installed on the drive, never seen anything in dmesg).
It's happening often enough for me to have to consider dropping use of the assistant. It could still be a problem with the machine (though it seems unlikely, given that it's consistently the same repo, and that it has done it with the same repo on other machines), but git-annex doesn't provide any information about it.
Could you add some more information about what it thinks is wrong to the logging?
Funnily enough, git-annex started repairing it again as I was writing this.
It seems to me that if you don't want to repair your repository, you can just go into the webapp and disable all scheduled consistency check jobs.
If someone with this problem would like to run "git annex repair" at the console, and paste the output, perhaps I could then see why it thinks it needs to repair the repository. So far, I have nothing to go on, and no proof that this is a bug at all, and not just people with actually corrupted repositories that really do need to be repaired.
git annex repairat the console so I can see what's going on.