#18 TRIM support on LVM and dm-crypt


I've added support for TRIM'ing even if the fs is on an LVM or dm-crypt device. This currently only supports linear logical volumes on top of a single device (i.e. no striped, mirrored, or concatenated volumes), but it does support arbitrary LVM and dm-crypt stackings (i.e. LVM on top of dm-crypt or visa-versa).

BACK UP YOUR DATA before using this. I've tested actual TRIM's on a dm-crypt device, as well as set up a dummy stacked LVM and dm-crypt and verified the reported ranges from --verbose make sense, so I'm reasonably confident it works properly, but...

To use this, LVM must be activated and/or the encrypted devices opened. For online TRIM specify the fs mount point as usual; for offline TRIM specify the device the fs is usually mounted on (e.g. /dev/mapper/home) (in a stacked setup make sure you specify the top-level device, not some intermediate device; e.g. if you have LVM on top of dm-crypt then specify the logical-volume's device, such as /dev/mapper/VolGroup0-LogVol1).

I'm attaching both the full script as well as the diff; both are against version 2.5 because there is no 'rdev' command on my distro, but the patch should apply straightforwardly to 2.6 too. The attached full script also has the x25-m patch, btw. The patch consists of 3 parts: the first part detects device-mapper devices and walks them to figure out the underlying scsi/sata device and to calculate the additional lba offset to use; the second part replaces the use of 'fsdev' with 'fspar' as the fs-device may not be the same as the underlying scsi/sata device; the third part adjusts 'fsoffset' to account for the additional LVM/dm-crypt headers and to account for the fact that the fibmap will return lba's that are relative to the LVM/dm-crypt container.

This should fix both http://sourceforge.net/tracker/?func=detail&aid=2927763&group_id=136732&atid=736685 and http://sourceforge.net/tracker/?func=detail&aid=2990354&group_id=136732&atid=736682 - the reason I created a separate issue here is so I can attach files.


<< < 1 2 (Page 2 of 2)
  • Jost

    Jost - 2011-01-08

    in an unrelated issue I noticed a regression going from Ubuntu 10.04 LTS to the current 10.10 on my system.

    TRIM on encrypted volumes used to work on 10.04, now with 10.10 it complains about not being able to determine the underlying device.
    Is this maybe a regression caused by the recent syntax-change in dm-crypt? Or can your script not handle dm-crypt containers that were created inside a partition?

    confirmed working:
    OCZ Vertex Turbo == (entire unpartitioned disk) == dm-crypt luks == lvm2 == logical volume == ext4 (mounted as root partition)
    Ubuntu 10.04 LTS amd64
    kernel (compiled from kernel.org with ubuntu configs)
    hdparm 9.28
    wiper.sh 2.5 with dm-crypt patch

    NOT working:
    OCZ Vertex Turbo == Primary Partition == dm-crypt luks == lvm2 == logical volume == ext4 (mounted as root partition)
    Ubuntu 10.10
    hdparm 9.28 (also tried 9.36, same result)
    wiper 2.5 with dm-crypt patch

    root@theta:/# ./wiper.sh --commit /

    wiper.sh: Linux SATA SSD TRIM utility, version 2.5, by Mark Lord.
    /dev/mapper/system-root: unable to reliably determine the underlying physical device name, aborting

    Any help is appreciated

  • Jost

    Jost - 2011-01-15

    Ha! Found it!

    With the new version of dm-crypt introduced in Ubuntu 10.10 the device nodes for cryptographic containers are no longer created by their names in /dev/mapper/<volumename>. Instead, these are only symlinks, pointing to the numeric devices in /dev/dm-X (where X is an integer).

    This triggers the sanity check on line 412 of wiper.sh (the patched one attached here), because fspar contains the link name, not the link target and hence the get_major function polls the wrong device and then of course the major number is off. This happens because at least Ubuntu still uses the actual given names in /dev/mapper (which are symlinks) when mounting encrypted volumes.

    The variable rawdev on the other hand does contain the correct device, so I'm assuming the sanity check is just overreacting here. I didn't dare to just comment it out, though.

    I desperately need this functionality, so I will attempt to modify the script and come back here. My bash is a little rusty however, I guess I need to find out how to reliably resolve symlinks first...

    I'll take all the help I can get, so if you have an idea I'll be glad to test it.

  • R.

    R. - 2011-01-15

    wiper.sh 2.5 with device-mapper and max-ranges patches and fibmap hack; updated to deal with symlinks in /dev/mapper/

  • R.

    R. - 2011-01-15

    Sorry for late reply. Thanks for you analysis. Yes, I ran into that issue a few months back too, but forgot to upload the new script here. This is done now - please give it a shot (but please back up your data first, at least the first time).

  • Jost

    Jost - 2011-01-15

    thanks for the reply!
    I just testet your new version after spending the entire morning trying to reverse-engineer what wiper.sh actually does (and where it fails).

    I am sorry to report that your new version still does not work for me. It still complains about not being able to reliably determine the underlying device.

    I did however manage to get the original version to work on my system with a little hacking. In the end all I had to change was one line in the definition of the fspar variable around line 360 (I added lots of comments to the code, may be off a few lines)

    ### MODIFICATION ###
    # fspar="$fsdev"
    fspar="`get_realpath $fsdev`"
    ### /MODIFICATION ###

    Not a lot to show for a morning's work, but if it took me that long I obviously needed the exercise!
    Works like a charm now...

    Is there any chance someone who actually knows what he's doing can merge the LVM/dm-crypt patch with the raid patch I mentioned in another comment?

    If not I will attempt it myself, but judging from this morning's experience it would take me forever to get it working, and I have a feeling it's probably a one-liner too if you know where to look...


  • Nobody/Anonymous

    Hey roadrunner :)

    I installed Ubuntu 11.04 and now the whole thing isn't working anymore - it worked before, but now: "/dev/mapper/laptop--ubuntu-root: unable to reliably determine the underlying physical device name, aborting"

    Are you still developing the script?

    Thank you very much

  • Jost

    Jost - 2011-07-28

    Hey nobody!

    Don't know about roadrunner, but I ran into the same problem (again) a few days back when trying to install 11.10 alpha2.

    The error you describe occurs because the naming scheme for dm-crypt device nodes has changed a while back. You can easily adapt the original scripts yourself. See my comment below.

  • Nobody/Anonymous

    If a HARDWARE RAID controller is used, does anyone know whether this can manually TRIM the underlying devices? (and please state whether you know first-hand or second-hand)

    (I see "no striped, mirrored... volumes," but was that meant to apply only to LVM's stripe/mirror/etc "volumes"?)

<< < 1 2 (Page 2 of 2)

Log in to post a comment.