Yes, for this caches are a nuisance. They also make it hard to verify backups that are smaller than main memory. The way to go for device testing is to make sure your test-files are larger than the available memory. You can also limit memory via boot option. Another thing I found wise to check in case of corruption is main memory. 24 hours of memtest86+ usually do the trick. Side note on USB: I used to have an USB cable (!) that caused corruption with some devices. It seems sensible checksum usage never made it into USB or at least not into mandatory adoption. Apart from that, I don't feel that my time has been wasted. To know about a possible source of corruption is always interesting. And dm-crypt just got a bit more trustworthy, because it was scrutinized carefully. Arno On Sat, Nov 10, 2007 at 01:05:18PM +0100, Clemens Fruhwirth wrote: > Short Message: There is no corruption caused by dm-crypt (at least in > my case). Faulty hardware. I'm sorry for the disturbance my false warning > caused. > > Long Message: It turned out to be a hardware fault. Of course I did > some tests to rule this cause out, but unfortunately the tests were > incorrect. The device cache masked the corruptions in the case of > direct disk access but when going via dm-crypt the device caching > appearently behaved different revealing corruptions. The conclusion > that its dm-crypt's fault is wrong of course. > > What made me believe in the first place that my hardware was ok was > that my initial test showed no errors: > > dd if=large-random-file of=/dev/blockdev > sync > dd if=/dev/blockdev of=large-random-file2 > cmp large-random-file large-random-file2 > > Luckily after repeating the test on 2.6.16.25 -- still without errors > -- I paid more attention to the statistics dd printed. The transfer > rate for reading the content back exceeded the rate the disk was > physically capable of. Putting a power cycle between the writing and > reading back (invalidating any device cache) quickly revealed that this > ultra cheap chinese USB product isn't any good. > > I'm deeply sorry for wasting your time. Thanks though for providing > assistance to all respondents. I knew that I would not have time to > track this issue down during the last week, but keeping this suspicion > of corruption to myself seemed unjustifiable -- especially as LUKS' > designer I know how sensitive LUKS is to corruption even when it's > just a single bit. > -- > Fruhwirth Clemens - http://clemens.endorphin.org > > --------------------------------------------------------------------- > dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ > To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx > For additional commands, e-mail: dm-crypt-help@xxxxxxxx > -- Arno Wagner, Dipl. Inform., CISSP --- CSG, ETH Zurich, arno@xxxxxxxxxxx GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier --------------------------------------------------------------------- dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx For additional commands, e-mail: dm-crypt-help@xxxxxxxx
