Dear Clemens Fruhwirth, in preparation for a server switch (oldey dual-Xeon to be replaced by 4x2 AMD64), I have been using cryptsetup (but not LUKS) heavily during the past weeks, running the latest kernel versions, currently, Linux-2.6.23.1. The encrypted filesystem has been mounted repeatedly, and a database (dump file's size: 785 MByte) has been deleted and set up again quite often on the encrypted partition. Luckily enough, I have not seen any problems until now, which, of course, does not count as a proof that cryptsetup/dm-crypt is fine under the kernel used. Many thanks for all the work you have done on encryption under Linux - it's highly appreciated. Best regards, Ernst -- Dr. med. Ernst Molitor Institute for Medical Microbiology, Immunology and Parasitology University of Bonn, Germany On Saturday 03 November 2007 13:01:24 Clemens Fruhwirth wrote: > We might have some corruption issues for dm-crypt. > > I recently switched to an LVM setup that is backed by a single > physical volume accessed via dm-crypt. I have seen strange corruptions > with cryptsetup, incompletely written headers that were reproducible > 4/5 of the time. > > I blamed the fact that I had orphaned mappings to the corrupting > device (left overs of temporary-cryptsetup-mapping). The upcoming > version of cryptsetup will require exclusive access to the underlying > device and also trap ctrl-c's so that these mappings are > removed. After hacking these sanity checks into cryptsetup, this thing > went away. But it doesn't look like that this was the thing to blame. > > Yesterday I renamed the LVM volume (vgrename), and after that the LVM > header was corrupted. LVM is in the same position as cryptsetup > (although it does not know). cryptsetup sets up a temporary mapping > and opens this raw block dev to write headers. LVM gets a block device > and also writes header by opening the raw block device. So these > positions are identical when you hand an encrypted volume to LVM as > physical volume. > > I neither have a reproducible test case, only the observation that > things didn't happen that way in 2.6.20 (2.6.21 was affected too, > sorry it's too long ago I can't remember the setup details precisely). > > I have the strong suspicion that your LUKS disk might DIE due when it > trying to touch the header and only a corrupted header version is > written. Unfortunately, I don't have much time to look at this at the > moment. I suspect this is some kind of race (yeah fun to debug!). > > This message should only serve as warning that you might not want to > go for any kernels more recent than 2.6.20 with LUKS. Sorry for the > ultra-vague information. > > Christophe, Alasdair: has anything crossed your way that might explain > this/looks familiar? > -- > 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 --------------------------------------------------------------------- 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
