diff options
Diffstat (limited to 'doc')
-rw-r--r-- | doc/bugs/git_annex_fsck_on_btrfs_devices/comment_3_dfcef745c92ec629f82ec6acc14d1519._comment | 9 |
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. +"""]] |