Hello, we observed the following behaviour: 1. Create a plain file on a removable drive, e.g. USB pendrive or hotpluggable SATA drive (dd if=/dev/zero of=/media/somedrive/testfile bs=1 count=1 seek=100000000). Don't make it bigger than ~50% of free memory. 2. Create a loopback device with this file (losetup -f /media/somedrive/testfile) 3. Make this /dev/loopX a device mapper target. Tested with truecrypt, dm_crypt (cryptsetup luksFormat ... and luksOpen ...) and lvm (pvcreate /dev/loopX, vgcreate testvg /dev/loopX, lvcreate -N testlv testvg). 4. Create a filesystem on top of that mapping (mkfs.ext3 /dev/mapper/...) 5. Mount that filesystem 6. Copy some data to it 7. Remove the drive without unmounting anything Expected behavior: Writing to the still mounted mapping should at least give an error Actual behavior: Reading from and writing to the mapping is still possible, as long as the written data fits into the page cache. Even unmounting works cleanly. When you remount the whole thing, data is obviously lost. This does not happen with whole block devices as targets, which is AFAIK the case in most uses of the device mapper. We experienced this with truecrypt volumes, where the user accidentally removed a drive containing an encrypted TrueCrypt container. He plugged it back in, and since everything worked, he continued to work. Only after unmounting and re-opening the container the next day, he noticed that several hours of work had been lost because nothing had actually been written. We are using Ubuntu 10.04 LTS with linux 2.6.32. Since this is reproducible with other device mapper targets, I am sure this is not a truecrypt problem. It might be related to udev, which AFAIK should notify higher levels when a device is removed. IMHO, this is a rather severe problem, since loss of connection to a device may also occur by bad cables, connections etc. Do you have any explanation for that? Thanks, Andreas -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
