Linux – How to enable SSD TRIM support on Fedora 17

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.

Just use --assume-clean and don't even sync in the first place.

Once you create your RAID, the first thing you do is mkfs... and mkfs TRIMs by default without even asking (unless you use -E nodiscard or similar) and your RAID sync is already gone at this point anyway.

Basically it's impossible to keep a mixed SSD+HDD RAID in sync as long as TRIM affects only one side. Even with SSD+SSD RAID, a TRIM will likely cause differences if it's different SSD models or different partition offsets.

It's not a problem as long as it only affects "free space". The actual data itself will still be in sync and thus redundancy is provided.

If the SSD ever fails or you decide to replace the HDD with another SSD later on, that's where you get the full sync on SSD since that's the only way md knows how to do things. md does not record TRIM commands and thus remember "free" regions to speed up syncing; it is also not smart enough to TRIM (and thereby zero) the target SSD and only write non-zero data. Maybe when SSD become more common such features will be added to speed up resyncs.

Even so it's not something you should worry too much about; TRIM is a long-term measure, your filesystem will see TRIM during regular use, so over time even a fully written SSD will see enough trimmed areas.