Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#18 TRIM support on LVM and dm-crypt

open
nobody
None
5
2010-05-06
2010-05-06
R.
No

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.

Discussion

1 2 3 4 > >> (Page 1 of 4)
  • R.
    R.
    2010-05-06

    Patch to wiper.sh 2.5 to support (linear) LVM and dm-crypt

     
    Attachments
  • JG^
    JG^
    2010-05-14

    thanks very much for this! i just tested your new script with a ocz vertex2 (sandforce sf-1200) and it works for my root partition (no dmcrypt) and another partition which is dmcrypt/luks (no lvm). at the moment i'm diffing the partition with my backup but i'm confident :)

    i only had to change line 747 ( i>=512) to i>=64, everything greater than 64 doesn't work => results in FAILED: Input/output error.

     
  • R.
    R.
    2010-05-15

    wiper.sh version2.5 with device-mapper and max-ranges patches applied

     
    Attachments
  • the dmcrypt patch doesn't seem to work for the intel x25-m. my root partition is encrypted, here's the wiper.sh output:

    ./wiper.sh --verbose /

    wiper.sh: Linux SATA SSD TRIM utility, version 2.5, by Mark Lord.
    rootdev=/dev/mapper/root rdev=/dev/mapper/root
    fsmode1: fsmode=read-write
    /: fstype=ext4
    freesize = 5658380 KB, reserved = 56583 KB
    Preparing for online TRIM of free space on /dev/mapper/root (ext4
    mounted read-write at /). This will be a DRY-RUN only. Use --commit to
    do it for real. Creating temporary file (5601797 KB)..
    Syncing disks..
    Simulating TRIM operations..
    get_trimlist=/sbin/hdparm --fibmap WIPER_TMPFILE.14619
    (dry-run) trimming 0 sectors from 0 ranges
    Removing temporary file..
    Syncing disks..
    Done.

    => see "trimming 0 sectors from 0 ranges"

    performing a --commit doesn't seem to do anything (no hard disk load at all):
    This operation could silently destroy your data. Are you sure (y/N)? y
    Creating temporary file (5594336 KB)..
    Syncing disks..
    Beginning TRIM operations..
    get_trimlist=/sbin/hdparm --fibmap WIPER_TMPFILE.14100
    Removing temporary file..
    Syncing disks..
    Done.

    the script _does_ work on my /dev/sda1 ext4 partition which is not encrypted.

     
  • R.
    R.
    2010-05-19

    It's looking like 'hdparm --fibmap' may not be working properly (returning an error). First of all, what kernel version and version of hdparm are you using? Second, can you add the following around line 751 (just before the $get_trimlist call):

    $get_trimlist
    echo $?

    and show me the output.

     
  • sorry, i completely forgot to mention that. it's 2.6.33.2 and hdparm v9.28., 32bit.
    /dev/mapper/root = /dev/sda6

    it seems that the device can't be found:
    ./wiper_dmcrypt.sh --verbose /dev/mapper/root

    wiper_dmcrypt.sh: Linux SATA SSD TRIM utility, version 2.5, by Mark Lord.
    rootdev=/dev/mapper/root rdev=/dev/mapper/root
    fsmode2: fsmode=read-write
    /: fstype=ext4
    freesize = 8186220 KB, reserved = 81862 KB
    max-ranges = 512
    Preparing for online TRIM of free space on /dev/mapper/root (ext4 mounted read-write at /).
    This will be a DRY-RUN only. Use --commit to do it for real.
    Creating temporary file (8104358 KB)..
    Syncing disks..
    Simulating TRIM operations..
    get_trimlist=/sbin/hdparm --fibmap WIPER_TMPFILE.10511
    254,0: device not found in /dev
    2
    (dry-run) trimming 0 sectors from 0 ranges
    Removing temporary file..
    Syncing disks..
    Done.

     
  • R.
    R.
    2010-05-23

    It looks like for some reason you have no /dev/dm-<num> devices. On my system I get both /dev/mapper/root and /dev/dm-0 devices (with same major/minor), and 'hdparm --fibmap' only looks in /dev/ (not subdirectories thereof). The proper fix would probably be for hdparm to be fixed to look for devices anywhere in the /dev/ tree, but in the mean time you could work around it by explicitly creating a /dev/dm-<num> device: 'mknod /dev/dm-0 b 254 0' (this won't survive a reboot, though). It might also be possible to add an ugly hack to wiper.sh to temporarily create such a device entry and delete it again on exit - I'll think about that.

     
  • R.
    R.
    2010-05-24

    wiper.sh version2.5 with device-mapper and max-ranges patches applied; this variant contains a hack to deal with a limitation of 'hdparm --fibmap'

     
    Attachments
1 2 3 4 > >> (Page 1 of 4)