summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGravatar eigengrau <eigengrau@web>2015-05-28 13:09:23 +0000
committerGravatar admin <admin@branchable.com>2015-05-28 13:09:23 +0000
commitfabd07e5ff083b8fc99de47d8162ab0e1ca2d9a6 (patch)
treef728658abbc16994f3970b85e8c984e5574ea48f
parenta4a208079916ebc1d42b5b77f677dc170e0af3a5 (diff)
Added a comment
-rw-r--r--doc/bugs/git_annex_fsck_on_btrfs_devices/comment_3_dfcef745c92ec629f82ec6acc14d1519._comment9
1 files changed, 9 insertions, 0 deletions
diff --git a/doc/bugs/git_annex_fsck_on_btrfs_devices/comment_3_dfcef745c92ec629f82ec6acc14d1519._comment b/doc/bugs/git_annex_fsck_on_btrfs_devices/comment_3_dfcef745c92ec629f82ec6acc14d1519._comment
new file mode 100644
index 000000000..ec277f9c2
--- /dev/null
+++ b/doc/bugs/git_annex_fsck_on_btrfs_devices/comment_3_dfcef745c92ec629f82ec6acc14d1519._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="eigengrau"
+ subject="comment 3"
+ date="2015-05-28T13:09:23Z"
+ content="""
+Thanks! If it’s just for one file, it’s probably okay to move it to bad. If the error was intermittent, one can try reinjecting the content.
+
+As for the risk of overkill, I don’t know enough about how the SATA/SCSI subsystem handles things. The cornercase would be one where (say due to EM interference) the SATA connection is reset and the device driver reports read errors for lots and lots of files, but the drive comes back in time so that these files are erroneously moved to bad. However, I guess you do the “move to bad” action file by file, and the whole fsck fails if moving to bad fails. In this case, we probably wouldn’t bite the cornercase, because when the drive comes back online, at most one file is moved to “bad“ erroneously.
+"""]]