1 of 1 people found this helpful
It is possible that TRIM is not enabled due to the SATA/RAID controller (PATA bridge) you are using.
In case this is true, you may secure erase or low level format the drive whenever you observe performance degradation, with the major consequence of deleting all files from the drive, unless you have a SATA controller that identifies the drive properly and provides the TRIM command to it.
Do NOT write zeros or anything to a SSD in an attempt to clean it as TRIM does.That will not benefit anything and only cause more performance degradation.
Any time anything is written to NAND storage cells, it is then in the used/written to state. Before it can be written to again, the NAND cells must be cleared/reset to their "ready to be written to" state. That is what slows down performance, the time it takes to prepare enough NAND cells that are not reset before they can be used. TRIM commands tell the SSD which data is no longer needed, and the SSD can then reset those NAND cells when it is not busy.
When you mentioned "... optimises storage of zero blocks.", that sounds like a data compression like feature, created for HDDs? The SandForce controller in a 335 does data compression of its own, but I would not expect a SSD to perform anything designed for HDDs.
Since the logical block number has to be mapped internally to get the physical block number, it seems an obvious optimisation to keep a special physical block number for an all-zero block. Since an SSD isn't really read-write (a write goes to a different physical block) then this is like de-duplication of all-zero blocks. Well -- if I was writing the firmware it seems like it would be a good cheap optimisation, so I wondered if it was done that way. Or maybe I don't know enough about the low-level workings of a SSD drive and if I did I would know that this is not feasible. Unfortunately we seem to have no firmware engineers on this forum to answer the question!
BTW, if the Sandforce controller does compression then my all-zero block would compress really well, and maybe only take up a few bytes on the drive. Which means that writing zeros would be almost as good as TRIM.
I think this question is unanswerable unless a firmware engineer comes along to tell us who's right. I'll hold off writing zeros for now, though! Thanks.
As far as I know TRIM is supported by ext4 file system since kernel version 2.6.33. It is important to note that if the kernel available in the Linux distribution is compiled without the TRIM support, it will be necessary to recompile the kernel and enable the support for TRIM.
If by any chance (as stated above) your SATA/RAID controller (PATA bridge) is not capable of providing the TRIM command we suggest a secure erase or low level format to optimize the drive again.
Thanks, I am aware of all that. On 2.6.34, attempts to use TRIM cause fatal errors and shut down the driver. I assume this is because of limitations of the PATA bridge. That is why I was looking for an alternative. I am not going to risk secure erase over this PATA bridge, so that would probably mean removing the drive from the machine, in which case I might as well plug it into a machine that does support direct SATA connections and TRIM and use fstrim to rejuvenate the drive.
My original question was about using zeroing as an alternative.
To resolve this thread, I think that the answer to my question about zeroing is:
Nobody here knows the answer (despite their best intentions)