Linux – How to check if the ssd supports fstrim

I'm running btrfs on top of dm-crypt for a while now. Since btrfs is a multi-device capable and dynamic (grow, shrink etc) filesystem, I don't really need the LVM layer for my purposes.

Other than that, use a recent enough dm-crypt that has --allow-discards capability, 3.1+ kernel and a filesystem that also allows discards (btrfs, ext*, ...).

Some stuff to read through doing all this:

• https://code.google.com/p/cryptsetup/wiki/Cryptsetup140 (--allow-discards)
• http://thread.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/4075/
• http://asalor.blogspot.com/2011/08/trim-dm-crypt-problems.html (Milan Broz, dm-crypt developer)

I'll update with more links over time as I find them from my bookmark abyss :>

I have not benchmarked my setup particularly much. For me it's behaving more than adequate in performance i.e. still worlds ahead of HDD. I don't know for now exactly what state my SSD is in and whether the multi-layer discard system is really working 100%. What's important rather is I have enough performance with enough of a security model to fend off the higher-probability issues, such as , forgetting the device, device being stolen by random people, etc.

So finding out exactly how much my SSD lifespan has possibly shortened, or performance slowed because of the discard system not working 100% correctly for TRIM, or how much dm-crypt discards weaken its inherent security - I have not been able to gather information to warrant giving these questions a high priority. One of the reasons I'm writing this answer is perhaps I'm wrong too much and putting this out here is currently the optimal way for me to try to find out.

I think the major misconception here is that issuing TRIM will cause the blocks to be erased then and there. Really all that the TRIM command is doing is informing the SSD that the OS no longer needs the data at this location, exactly what happens after that is up to the firmware Ideally the firmware should use this information to:

1. Avoid copying and re-writing this data when another part of the block is rewritten. Remember that the erase block size for an SSD is (always?) larger than the write block size, so when it has to re-write a particular block, it will often have to copy a larger area, erase and re-write the larger area with the updated data included. If a TRIM has been issued for part of that area, this part it does not have to be copied or rewritten. This is faster and prevents unneeded writes which will shorten the life of the device.

2. Perform other wear levelling optimisations.

Neither of these require that the data be erased straight away. In fact, it may be better for the SSD's lifespan if this doesn't happen when the trimmed area is less than the size of an erase block. That said, it also follows that it may be good practice for the SSD to erase the areas that cover full erase blocks soon after the TRIM is issued.

If you have had success with the above method before, it may have been that the SSDs used had a smaller erase block size. Unfortunately the manufacturers rarely publish this data, but digging around, 512k doesn't seem to be unheard of. You may have success if you try reading and writing a larger area which would cover several erase blocks and reading from the middle of the area rather than the start or end, since the first part may not get its own erase block.

However note that I had the same result as the question even with an 16 MiB continuous block.