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
