mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

comment

Browse source
This commit is contained in:
Joey Hess 2015-05-27 16:43:17 -04:00
parent 4e8321fd8d
commit 3879bca336
1 changed files with 24 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

24
doc/bugs/git_annex_fsck_on_btrfs_devices/comment_2_fe050712ea067df80f8d8c52d90d24d9._comment Normal file
View file

@ -0,0 +1,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.
"""]]