summaryrefslogtreecommitdiff
path: root/doc/bugs/fsck_should_double-check_when_a_content-check_fails/comment_2_41214a7d18c66b694645248d6ebeadbf._comment
blob: ea9518cb6b5ab4672622745b803f4144f690025d (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawkHDm_DOFRcHYebCnnYKKyIwiPD4iOiiIU"
 nickname="Jörn"
 subject="comment 2"
 date="2013-01-14T17:37:45Z"
 content="""
Maybe I was too quick in blaming the hard drive. It might be my problem is somewhere else. Let me do what I should have done in the first place and give you a detailed problem description:

I have got three hard drives, two internal, one external connected via USB. I have got a couple of repositories with small files (mp3, JPEGs and so on). Those are fine, fsck never complains about them. 
But in one repository with video files (i.e. much bigger files than in the other repos), git-annex fsck will always find some broken files. I run git-annex get to retrieve the broken files from other sources. Then I run
fsck again - and it complains about some other files. This happens on all drives.

This could mean:

- all my drives are broken. However, SMART data are unsuspicious, and one of the drives is just a couple of days old.
- git-annex fsck is broken
- read errors like I mentioned in my first post
- some process actually _altering_ the files (should not happen when the files are locked, right?)
- something completely different? Some possibly dangerous source of radiation? :)

Any ideas on this? Maybe I should hash the data in .git/annex/bad and check which value I get - can I tell git-annex to do so?

Thanks,
Jörn
"""]]