On 11/09/2011 07:14 PM, Alexander Koch wrote: > Hello everyone, > > I'm trying to verify that TRIM is actually working on my dm-crypt (LUKS) > encrypted LVM volume with the following layers: > > SSD (Crucial M4 128GB) -> LVM -> LUKS -> ext4 > > I followed the guide available at [1], which includes these steps: > > 1) create a random-filled file, sync to disk > 2) fetch LBAs via 'hdparm --fibmap' > 3) pick one sector, raw-read contents with 'hdparm --read-sector' > 4) delete the file, sync to disk > 5) re-read the sector chosen above, verify it contains zeroes > > Unfortunately I already get a zeroed sector in step three: > > > $ hdparm --read-sector 271984 /dev/sdd > > > > /dev/sdd: > > reading sector 271984: succeeded > > 0000 0000 0000 0000 0000 0000 0000 0000 > > 0000 0000 0000 0000 0000 0000 0000 0000 > > 0000 0000 0000 0000 0000 0000 0000 0000 > > 0000 0000 0000 0000 0000 0000 0000 0000 > > (...) > > > Is there any LBA-calculation I must do because of the LVM layer? If LVM provides just linear mapping of LV, it is about calculating proper sector offset you need to add to calculated value here. hdparm uses just top level device offset. Also note you will NEVER get zeroes on top level device if dm-crypt is involved. TRIM is bypassed to lower level device, so zeroes are on hw, but dm-crypt interprets it as ciphertext, so you get "random" noise on top level device (decrypted zeroes). Maybe better an example - this is test config, ext4 on LUKS on LVM on sdb # lsblk /dev/sdb -f NAME FSTYPE LABEL MOUNTPOINT sdb LVM2_member `-vg_test-lv (dm-0) crypto_LUKS `-crypt_lv (dm-1) ext4 /mnt/tst Here are the mapping tables: # dmsetup table crypt_lv: 0 405504 crypt aes-cbc-essiv:sha256 <key> 0 254:0 4096 vg_test-lv: 0 409600 linear 8:16 2048 So, crypt_lv has data offset 4096 sectors (LUKS metadata) and LV under it has data offset 2048 sectors (LVM metadata). So sector 0 of crypt_lv is mapped to sector 6144 (4096 + 2048) of /dev/sdb. This is the offset you should use in calculations. Note this is always in 512 bytes sectors but drive can use 4096 sectors. So TRIM for sector 10 on /dev/mapper/crypt_lv should be forwarded as TRIM for sector 6154 (6144 + 10) on /dev/sdb. Moreover, if you have TRIM enabled, you should see "allow_discards" in mapping table for LUKS. Otherwise TRIM is blocked. You should be also able to trace discard (and other) block requests using blktrace/btrace, this should be really more user friendly :) Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
