blob: 8d2e95161548d933cbde2805da34246047035e69 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
|
[[!comment format=mdwn
username="joey"
subject="""comment 2"""
date="2015-05-27T19:10:48Z"
content="""
Similar thing could happen on non-btrfs, if a disk sector
is bad, or the disk has gone walkabout, you might get back an
IO error reading it sometimes. And it could well be an intermittent error.
`git annex fsck` already says "failed" and exits nonzero (immediately!)
when this happens. It just doesn't move the file to the `bad` directory.
I've improved the "sha1sum parse error" to instead be
"sha1sum failed" in the case where the command exited nonzero.
Moving everything to `bad` on what could be an
intermittent error risks overkill. OTOH, if the whole disk is gone,
it can make any changes it likes, it won't affect the actual disk. ;)
On balance, I think fsck should assume that an IO error is something it
should fix, and so it should move such files to `bad/`. With care taken to
differentiate between a disk IO error and eg, a broken sha1sum command that
fails to run, or a permissions problem reading the file, or whatever.
"""]]
|
