From fabd07e5ff083b8fc99de47d8162ab0e1ca2d9a6 Mon Sep 17 00:00:00 2001 From: eigengrau Date: Thu, 28 May 2015 13:09:23 +0000 Subject: Added a comment --- .../comment_3_dfcef745c92ec629f82ec6acc14d1519._comment | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 doc/bugs/git_annex_fsck_on_btrfs_devices/comment_3_dfcef745c92ec629f82ec6acc14d1519._comment (limited to 'doc/bugs') 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. +"""]] -- cgit v1.2.3