Hi Carlos, On Monday 11 Jan 2010 01:26:10 Carlos E. R. wrote:
Content-ID:
On Sunday, 2010-01-10 at 19:00 -0000, Bob Williams wrote:
- 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.
Both ext3
- 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.
This suggestion is the slow but sure method of tracking down the cause of the problem. Whether it will lead to a solution that prevents it happening in the future, I don't know.
I wonder if rsync could be used somehow to run a compare? Perhaps best thing would be using checksums.
More in-depth reading of the man page needed :) Many thanks for your helpful suggestions. Bob -- Registered Linux User #463880 FSFE Member #1300 GPG-FP: A6C1 457C 6DBA B13E 5524 F703 D12A FB79 926B 994E openSUSE 11.2, Kernel 2.6.31.8-0.1-desktop, KDE 4.3.4 Intel Core2 Quad Q9400 2.66GHz, 4GB DDR RAM, nVidia GeForce 9200GS -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org