-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
Thanks, Carlos
You have grasped the setup exactly ...
Good :-)
let me see:
- 2 machines - encripted storage ¿type?
luKs
Ah. No, I was thinking of the filesystem type. Any of them xfs? I'm having problems with them, which according to the SGI people seems to be a bug on the DM code. No answer from Novell.
- rip on any, copied to the other using rsync - some tracks bad on machine "home". - bad file on "home" is bad on "away" if copied via scp
Correct?
Correct
Ok, leaving the text above for reference.
I would try comparing a "bad" file with the same file on the other machine. My guess is that they willbe different, and thus, it would prove that "rsync" botched the job, and worse, it does not detect it.
Two objections to that solution:
1) Files that were ripped on "home" get corrupted, presumably _after_ a good copy has been rsynced to "away", though I can't prove that. Generally, the synchronisation will take place within a few days of ripping. The mirroring has been going on for 3 or 4 years.
Curious. Or rather, weird.
2) Why would rsync only botch things in one direction. You'd expect to find damaged files at both ends, surely. Although, come to think of it, there is some asymmetry, in that rsync both pushes and pulls from "away", while "home" runs an 'always on' rsync daemon.
Mmm. Network problems in one direction? I would do something: once you create a file, add a checksum of it to a text file or database. When you transmit it to the other computer, check it. After a period or when you suspect a problem, check it. Thus, you will be able to detect a corruption, and know if transmission is to be blamed, or storage. Plus, if you save on the log where the file was created, better. We should not trust our own memory ;-) It is no solution, but it would track or prove the issue. Your files either develop problems while stored, or they are damaged on transmission. It is unfortunate that copy tools nowdays do not include an option to verify that files were correctly copied and saved. I wonder if rsync could be used somehow to run a compare? Perhaps best thing would be using checksums.
and:
smartctl --all /dev/sdj
Find out if you have remapped (reallocated) sectors. It is in the list of attributes. If so, a sector could have been remapped while containing data and would explain the problem.
I'll take a look at that.
I see you did on your next post. No problems there, it seems. Although the "100" is not really the reallocation count, I think it is the raw index which is, and is zero in your case. Let me see, I had a disk go bad recently, I'll see what it reported [...] ah, look: 5 Reallocated_Sector_Ct 0x0033 001 001 036 Pre-fail Always FAILING_NOW 30748 So yours is perfect, count is "0". - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAktKfjwACgkQtTMYHG2NR9U5XQCeJvkjr9iMepGh1q6xbKH3qn6c TdsAnRC+4ymiEh+1LFZPXe5Es88AuIDX =fa6x -----END PGP SIGNATURE-----