summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGravatar antymat <antymat@web>2012-02-14 16:34:27 +0000
committerGravatar admin <admin@branchable.com>2012-02-14 16:34:27 +0000
commit0e3f7b64b6a9d92e86801a09b98c54c976fad864 (patch)
treece0ced341af7784686fe6f7111502b0e85d7e810
parenta40ec5e03e980b7337bf01eca1661a088ee476c2 (diff)
-rw-r--r--doc/forum/fsck_gives_false_positives.mdwn6
1 files changed, 6 insertions, 0 deletions
diff --git a/doc/forum/fsck_gives_false_positives.mdwn b/doc/forum/fsck_gives_false_positives.mdwn
new file mode 100644
index 000000000..ac3bd1b46
--- /dev/null
+++ b/doc/forum/fsck_gives_false_positives.mdwn
@@ -0,0 +1,6 @@
+Hi,
+
+I use git-annex 3.20120123 on a debian-testing amd-64 machine with software RAID6 and LVM2 on it. I needed to move the whole `/home` directory to another LV (the new LV is on encrypted PV, the old LV is encrypted and not properly aligned; I'm changing from encrypted `/home` only to encrypted everything except `/boot`), so I have user the `rsync -aAXH` from a `ro` mounted `/home` to a new LV mounted on `/mnt/home_2`. After the move was complete I run the `git annex fsck` on my (4TB of) data. The fsck finds some files bad, and moves them to the `..../bad` directory. So far so good, this is how it should be, right? But then- I have a file with sha1sum of all my files. So - I checked the 'bad' file against that. It was OK. Then I computed the SHA256 of the file - this is used by `git annex fsck`. It was OK, too. So how did it happen, that the file was marked as bad? Do I miss something here? Could it be related to the hardware (HDDs) and silent data corruption? Or is it the undesirable effect of rsync? Or maybe the fsck is at fault here?
+
+Any ideas?
+