Clemens Fruhwirth wrote: > 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. So you are talking about some race between writing LUKS header in combination with writing LVM metadata area ? *Not* corruption of data on volume, just header ? > 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). Are you sure that you see this corruption in latest .22 kernel (2.6.22.11) ? (Also 2.6.24-rc has rewritten workqueue code,it would be nice to test this too.) > 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!). Could you please send me steps what you did before corruption detection ? (I see that you have no reproducer script, but please send me configuration of your crypt volume and description of steps which lead to this - you can use "lvmdump" command to collect data). Milan -- mbroz@xxxxxxxxxx --------------------------------------------------------------------- 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
