To implement feature below, kernel device mapper must provide equivalent to AUTOCLEAR flag. +++ This bug was initially created as a clone of Bug #873686 +++ Description of problem: The loop back device has a LO_FLAGS_AUTOCLEAR flag. libvirt LXC uses loop devices with LO_FLAGS_AUTOCLEAR so that when the container exits, releasing its mount namespaces, the loop device gets automatically destroyed by the kernel. With dm-crypt some administrative process in userspace has to go around cleaning up devices after the container as stopped. I'd really like to have some way to mark dm-crypt devices to be autodestroyed when their last usage is released (whether an open FD to the device or a mount of the device) Off the top of my head, something along the lines of # cryptsetup luksOpen /dev/sdd1 mydev # mount /dev/mapper/mydev /mnt/containerfoo # cryptsetup luksAutoClose mydev .....time passes... # umount /mnt/containerfoo .... kernel automatically does equivalent of 'cryptsetup luksClose mydev' If there are other ways to achieve the same end result, I'm open to proposals. Also, if the LUKS device is ontop of a loop device, the auto-close of the LUKS device should in turn trigger release of the loop device, though this quite possibly happens already. Version-Release number of selected component (if applicable): cryptsetup-1.5.0-1.fc17.x86_64 --- Additional comment from mbroz on 2012-11-06 10:31:31 EST --- (In reply to comment #0) > Also, if the LUKS device is ontop of a loop device, the auto-close of the > LUKS > device should in turn trigger release of the loop device, though this quite > possibly happens already. That's how it works from the beginning (for all loops allocated by cryptsetup). So this is similar to losetup use, losetup -d on used loop will set autoclear flag (with recent kernels). But this must be implemented in-kernel device-mapper first, I'll clone the bug for it.
Normally RFEs go upstream first. Fedora will inherit it whenever it gets rolled into Linus' tree. I'll move this bug to rawhide for now, as we're not going to get it in f18 GA anyway.
Considerations: New ioctl or addition to existing ioctl (e.g. new flag or message handled by core)? Undoable before the final close? Are further opens (e.g. by udev) permitted? Will udev cope OK when it disappears? - When does the udev node disappear? - When does the dev node disappear in the non-udev case?
- In the non-udev case, does the dev node disappear immediately (while still in use => no further opens possible), or does libdevmapper (dmsetup) block until the device is closed?
To what extent should device remain addressable via dm ioctls until it actually disappears? What's precise list of restrictions when it's in this new state? If further opens are not permitted, how will blkid record this intermediate state correctly?
My inclination would be to align with the behaviour of the loopdevice AUTOCLEAR flag. With that setting the flag does not place any restriction on ongoing usage, nor any visible change in userspace. Everything continues as normal until the last usage is released, either by userspace closing the last open FD to the device, or by the kernel releasing the last mount of the device.
For udev case, node removal is automatic ("remove" event generated by block layer once kobject is dereferenced). For non-udev case - I do not care, really :-) It can block, it can say it is unsupported... whatever is simpler. Just correction - loop autoclear flag is visible in userspace (in sysfs, e.g. /sys/block/loop0/loop/autoclear). The same is possible for dm sysfs. (add /sys/block/dm-X/dm/autoclear)
OK. I'm working on filling out the details of a design along those lines, which I'll post here.
What's the current status here? Auto removal of underlying LUKS device is sometimes really needed.
Current proposal: Add a --deferred option to dmsetup remove. This will supply a new flag to the remove ioctl to tell it to defer the remove if it cannot do it immediately because the device is in use. As soon as the device's "open count" drops to 0, it is then removed automatically. If you change your mind, you can send a new 'dmsetup message' to the device to clear this deferred remove state. 'dmsetup info' will show the flag, if set.
Actually I am interested only in the kernel part (crypt/veritysetup will implement similar flag to -a). New flag is fine, just please provide some minor iface version increase to DM ioctl to check if it can be used. thx:)
Regarding udev, we shall probably first try leaving the uevents and rules unchanged, so the 'remove' is actioned immediately in userspace even if it is deferred on the kernel side.
Patches for this feature are at: http://people.redhat.com/mpatocka/patches/kernel/deferred-remove/
commit 2c140a246dc0bc085b98eddde978060fcec1080c Author: Mikulas Patocka <mpatocka> Date: Fri Nov 1 18:27:41 2013 -0400 dm: allow remove to be deferred This patch allows the removal of an open device to be deferred until it is closed. (Previously such a removal attempt would fail.) The deferred remove functionality is enabled by setting the flag DM_DEFERRED_REMOVE in the ioctl structure on DM_DEV_REMOVE or DM_REMOVE_ALL ioctl. On return from DM_DEV_REMOVE, the flag DM_DEFERRED_REMOVE indicates if the device was removed immediately or flagged to be removed on close - if the flag is clear, the device was removed. On return from DM_DEV_STATUS and other ioctls, the flag DM_DEFERRED_REMOVE is set if the device is scheduled to be removed on closure. A device that is scheduled to be deleted can be revived using the message "@cancel_deferred_remove". This message clears the DMF_DEFERRED_REMOVE flag so that the device won't be deleted on close. Signed-off-by: Mikulas Patocka <mpatocka> Signed-off-by: Alasdair G Kergon <agk> Signed-off-by: Mike Snitzer <snitzer>