Bug 873734 - [RFE] Provide a way to mark a dm device as "auto delete"
Summary: [RFE] Provide a way to mark a dm device as "auto delete"
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: ---
Assignee: Mikuláš Patočka
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 873686
TreeView+ depends on / blocked
 
Reported: 2012-11-06 15:34 UTC by Milan Broz
Modified: 2019-08-30 08:04 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-08-30 08:04:35 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Milan Broz 2012-11-06 15:34:22 UTC
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.

Comment 1 Josh Boyer 2012-11-06 19:13:20 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.

Comment 2 Alasdair Kergon 2012-11-07 17:38:24 UTC
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?

Comment 3 Alasdair Kergon 2012-11-07 17:41:08 UTC
  - 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?

Comment 4 Alasdair Kergon 2012-11-08 01:58:01 UTC
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?

Comment 5 Daniel Berrangé 2012-11-08 12:20:55 UTC
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.

Comment 6 Milan Broz 2012-11-08 12:33:14 UTC
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)

Comment 7 Alasdair Kergon 2012-11-09 01:44:14 UTC
OK.  I'm working on filling out the details of a design along those lines, which I'll post here.

Comment 9 Milan Broz 2013-08-29 05:38:44 UTC
What's the current status here?

Auto removal of underlying LUKS device is sometimes really needed.

Comment 10 Alasdair Kergon 2013-08-30 22:34:06 UTC
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.

Comment 11 Milan Broz 2013-08-31 06:41:13 UTC
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:)

Comment 12 Alasdair Kergon 2013-09-02 16:20:53 UTC
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.

Comment 13 Mikuláš Patočka 2013-09-16 20:55:22 UTC
Patches for this feature are at:
http://people.redhat.com/mpatocka/patches/kernel/deferred-remove/

Comment 14 Ondrej Kozina 2019-08-30 08:04:35 UTC
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>


Note You need to log in before you can comment on or make changes to this bug.