Bug 873734
Summary: | [RFE] Provide a way to mark a dm device as "auto delete" | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Milan Broz <mbroz> |
Component: | kernel | Assignee: | Mikuláš Patočka <mpatocka> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | low | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | agk, berrange, gansalmon, gmazyland, itamar, jbrassow, jonathan, kernel-maint, madhu.chinakonda, mpatocka, msnitzer, okozina, pvrabec |
Target Milestone: | --- | Keywords: | FutureFeature |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Enhancement | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2019-08-30 08:04:35 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 873686 |
Description
Milan Broz
2012-11-06 15:34:22 UTC
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> |