One can find many guides on the net on how to test TRIM using dd
and 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 hdparm --read-sector.
You must add any offsets resulting from either other partitions or
payload offsets from LVM, LUKS and the-like to the address you got from
hdparm --fibmap!
Here's an example 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 that 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.
[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 TRIM brings for crypto!