I tried to setup TRIM with LVM and dm-crypt on ubuntu 13.04 following this tutorial: http://blog.neutrino.es/2013/howto-properly-activate-trim-for-your-ssd-on-linux-fstrim-lvm-and-dmcrypt/See the notes about my configuration and my testing procedure below.QuestionsIs there a reliable test if TRIM works properly?Is my test routine wrong or is my TRIM not working?If it's not working: what is wrong with my setup?How can I debug TRIM for my setup and make TRIM work?ConfigurationHere ist my configuration:cat /etc/crypttabsda3_crypt UUID=[...] none luks,discardand cat /etc/lvm/lvm.conf# [...]devices  {      # [ ... ]      issue_discards = 1      # [ ... ]   }# [...]The SSD is a Samsung 840 Pro.Here is my test-procedureTo test the setup I just did sudo fstrim -v / which resulted in /: [...] bytes were trimmed Doing this again resulted in /: 0 bytes were trimmed which seems to make sense and indicated that TRIM seems to work. However then I did this test: dd if=/dev/urandom of=tempfile count=100 bs=512k oflag=directsudo hdparm --fibmap tempfile                                 tempfile: filesystem blocksize 4096, begins at LBA 0; assuming 512 byte sectors. byte_offset  begin_LBA    end_LBA    sectors           0    5520384    5521407       1024      524288    5528576    5529599       1024     1048576    5523456    5525503       2048     2097152    5607424    5619711      12288     8388608    5570560    5603327      32768    25165824    5963776    5980159      16384    33554432    6012928    6029311      16384    41943040    6275072    6291455      16384    50331648    6635520    6639615       4096syncsudo hdparm --read-sector 5520384 /dev/sda                    /dev/sda:reading sector 5520384: succeeded7746 4e11 bf42 0c93 25d3 2825 19fd 8edabd93 8ec6 9942 bb98 ed55 87eb 53e1 01d5c61a 3f52 19a1 0ae5 0798 c6e2 39d9 771ab89f 3fc5 e786 9b1d 3452 d5d7 9479 a80d114a 7528 a79f f475 57dc aeaf 25f4 998c3dd5 b44d 23bf 77f3 0ad9 8688 6518 28ee81db 1473 08b5 befe 8f2e 5b86 c84e c7d21bdd 1065 6a23 fd0f 2951 d879 e823 021bfa84 b9c1 eadd 9154 c9f4 2ebe cd70 64ec75a8 4d93 c8fa 3174 7277 1ffb e858 5eca7586 8b2e 9dbc ab12 40ab eb17 8187 e67d5e0d 0005 5867 b924 5cfd 6723 9e4a 6f5f99a4 a3b0 eeac 454a 83b6 c528 1106 6682ca77 4edf 2180 bf0c b175 fabb 3d4b 37e2b834 9e3e 82f2 2fdd 2c6a c6ca 873f e71ef979 160f 5778 356f 2aea 6176 46b6 72b9f76e ee51 979c 326b 1436 7cfe f677 bfcd4c3c 9e11 4747 45c1 4bb2 4137 03a1 e4c8e9dd 43b4 a3b4 ce1b d218 4161 bf64 727b75d8 dcc2 e14c ebec 2126 25da 0300 12bd6b1a 28b3 824f 3911 c960 527d 97cd de1b9f08 9a8e dcdc e65f 1875 58ca be65 82bfe844 50b8 cc1b 7466 58b8 e708 bd3d c01f64fb 9317 a77a e43b 671f e1fb e328 93a9c9c7 291c 56e0 c6c1 f011 b94d 9dc7 71e6c8b1 5720 b8c9 b1a6 14f1 7299 9122 912b312a 0f2f a31a 8bf9 9f8c 54e6 96f3 60b804a7 7dc9 3caa db0a a837 e5d7 2752 b477c22d 7598 44e1 84e9 25d4 5db5 9f19 f73b85a0 c656 373a ec34 55fb e1fc 124e 46741ba8 1a84 6aa4 7cb5 455e f416 adc6 a125c4d4 8323 4eee 2493 2920 4e38 524c 1981sudo rm tempfilesyncsudo fstrim /syncsudo hdparm --read-sector 5520384 /dev/sda/dev/sda:reading sector 5520384: succeeded7746 4e11 bf42 0c93 25d3 2825 19fd 8edabd93 8ec6 9942 bb98 ed55 87eb 53e1 01d5c61a 3f52 19a1 0ae5 0798 c6e2 39d9 771ab89f 3fc5 e786 9b1d 3452 d5d7 9479 a80d114a 7528 a79f f475 57dc aeaf 25f4 998c3dd5 b44d 23bf 77f3 0ad9 8688 6518 28ee81db 1473 08b5 befe 8f2e 5b86 c84e c7d21bdd 1065 6a23 fd0f 2951 d879 e823 021bfa84 b9c1 eadd 9154 c9f4 2ebe cd70 64ec75a8 4d93 c8fa 3174 7277 1ffb e858 5eca7586 8b2e 9dbc ab12 40ab eb17 8187 e67d5e0d 0005 5867 b924 5cfd 6723 9e4a 6f5f99a4 a3b0 eeac 454a 83b6 c528 1106 6682ca77 4edf 2180 bf0c b175 fabb 3d4b 37e2b834 9e3e 82f2 2fdd 2c6a c6ca 873f e71ef979 160f 5778 356f 2aea 6176 46b6 72b9f76e ee51 979c 326b 1436 7cfe f677 bfcd4c3c 9e11 4747 45c1 4bb2 4137 03a1 e4c8e9dd 43b4 a3b4 ce1b d218 4161 bf64 727b75d8 dcc2 e14c ebec 2126 25da 0300 12bd6b1a 28b3 824f 3911 c960 527d 97cd de1b9f08 9a8e dcdc e65f 1875 58ca be65 82bfe844 50b8 cc1b 7466 58b8 e708 bd3d c01f64fb 9317 a77a e43b 671f e1fb e328 93a9c9c7 291c 56e0 c6c1 f011 b94d 9dc7 71e6c8b1 5720 b8c9 b1a6 14f1 7299 9122 912b312a 0f2f a31a 8bf9 9f8c 54e6 96f3 60b804a7 7dc9 3caa db0a a837 e5d7 2752 b477c22d 7598 44e1 84e9 25d4 5db5 9f19 f73b85a0 c656 373a ec34 55fb e1fc 124e 46741ba8 1a84 6aa4 7cb5 455e f416 adc6 a125c4d4 8323 4eee 2493 2920 4e38 524c 1981This seems to indicate that TRIM doesn't work. Since sudo hdparm -I /dev/sda | grep -i TRIM                               *    Data Set Management TRIM supported (limit 8 blocks)       *    Deterministic read ZEROs after TRIMEditHere is the output of sudo dmsetup tablelubuntu--vg-root: 0 465903616 linear 252:0 2048lubuntu--vg-swap_1: 0 33308672 linear 252:0 465905664sda3_crypt: 0 499222528 crypt aes-xts-plain64 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0 8:3 4096 1 allow_discardsHere is my /etc/fstab:# <file system> <mount point>   <type>  <options>       <dump>  <pass>/dev/mapper/lubuntu--vg-root /               ext4    errors=remount-ro 0       1# /boot was on /dev/sda2 during installationUUID=f700d855-96d0-495e-a480-81f52b965bda /boot           ext2    defaults        0       2# /boot/efi was on /dev/sda1 during installationUUID=2296-2E49  /boot/efi       vfat    defaults        0       1/dev/mapper/lubuntu--vg-swap_1 none            swap    sw              0       0# tmptmpfs /tmp tmpfs nodev,nosuid,noexec,mode=1777          0       0 Edit:I finally reported it as a bug in https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1213631 Hope somebody will find a solution there or at least test the setup and verify the bug.UpdateNow it works, see accepted answer.
Trim with LVM and dm-crypt
lvm;ssd;troubleshooting;dm crypt;trim
I suggest using a different testing method. hdparm is a bit weird as it gives device addresses rather than filesystem addresses, and it doesn't say which device those addresses relate to (e.g. it resolves partitions, but not devicemapper targets, etc.). Much easier to use something that sticks with filesystem addresses, that way it's consistent (maybe except for non-traditional filesystems like zfs/btrfs).Create a test file: (not random on purpose)# yes | dd iflag=fullblock bs=1M count=1 of=trim.test Get the address, length and blocksize: (exact command depends on filefrag version)# filefrag -s -v trim.testFile size of trim.test is 1048576 (256 blocks, blocksize 4096) ext logical physical expected length flags   0       0    34048             256 eoftrim.test: 1 extent foundGet the device and mountpoint:# df trim.test/dev/mapper/something  32896880 11722824  20838512   37% /mount/pointWith this set up, you have a file trim.test filled with yes-pattern on /dev/mapper/something at address 34048 with length of 256 blocks of 4096 bytes.Reading that from the device directly should produce the yes-pattern:# dd bs=4096 skip=34048 count=256 if=/dev/mapper/something | hexdump -C00000000  79 0a 79 0a 79 0a 79 0a  79 0a 79 0a 79 0a 79 0a  |y.y.y.y.y.y.y.y.|*00100000If TRIM is enabled, this pattern should change when you delete the file. Note that caches need to be dropped also, otherwise dd will not re-read the data from disk.# rm trim.test# sync# fstrim -v /mount/point/ # when not using 'discard' mount option# echo 1 > /proc/sys/vm/drop_caches# dd bs=4096 skip=34048 count=256 if=/dev/mapper/something | hexdump -COn most SSD that would result in a zero pattern:00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|*00100000If encryption is involved, you will see a random pattern instead:00000000  1f c9 55 7d 07 15 00 d1  4a 1c 41 1a 43 84 15 c0  |..U}....J.A.C...|00000010  24 35 37 fe 05 f7 43 93  1e f4 3c cc d8 83 44 ad  |$57...C...<...D.|00000020  46 80 c2 26 13 06 dc 20  7e 22 e4 94 21 7c 8b 2c  |F..&... ~..!|.,|That's because physically trimmed, the crypto layer reads zeroes and decrypts those zeroes to random data.If the yes-pattern persists, most likely no trimming has been done.