One can find many guides on the net on how to test TRIM using
hdparm, which all describe the same procedure:
- create a random-filled file, sync it to disk
- determine the LBAs the file resides in using
hdparm --fibmap [file]
- pick one sector, raw-read it with
hdparm --read-sector [sector] [device]
- delete the random file, sync again
- verify TRIM was issued by reading the same block again, should return only zeroes
The problem with all these guides is that they don’t say anything about the influence partitioning and other layers like LVM can have on the right LBA to use with
You must add any offsets resulting from either other partitions or payload-offsets from LVM, LUKS and thelike to the address you got from
I’ll explain the concrete steps using my setup:
[alex@thor ~]$ fdisk -l /dev/sdd Disk /dev/sdd: 128.0 GB, 128035676160 bytes 255 heads, 63 sectors/track, 15566 cylinders, total 250069680 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xddfc7af4 Device Boot Start End Blocks Id System /dev/sdd1 * 2048 1050623 524288 83 Linux /dev/sdd2 1050624 250069679 124509528 8e Linux LVM
The PV our target LV resides on starts at sector 1050624, which is our first offset.
[alex@thor ~]$ dmsetup table root-plain: 0 56619008 crypt aes-xts-plain [keyslot] 0 254:0 4096 1 allow_discards m4vg0-root: 0 55050240 linear 8:50 2048 (...)
Here we can see that LVM has a payload offset of 2084 bytes and LUKS (dm-crypt) one of 4096 bytes (fits well for an SSD).
[alex@thor usr]$ hdparm --fibmap testfile testfile: filesystem blocksize 4096, begins at LBA 0; assuming 512 byte sectors. byte_offset begin_LBA end_LBA sectors 0 272600 272607 8
So finally we calculate the “real” address of our chosen sector (the first one) by 272600 + 1050624 + 2048 + 4096 = 1329368.
Happy TRIM-testing, and keep in mind the implications for crypto-recurity!