I don't know if it's the right section to ask those questions, I thought it would be the most appropriate one since it concerns SSDs. Sorry if I was wrong.
My normal setup on my PC is a dual boot Windows 7/Ubuntu installed on a hard drive.
Sometimes I need to reinstall one of my OS, when it happens I format the partition with a linux utility such as GParted before beginning the installation process.
Recently I bought an SSD.
In the past there was a problem with such a device : when you would delete a file at the OS level, the controller of the SSD was not immediately aware of it. If you wrote a lot of data that you erased afterwards, after a while the controller was full of invalid data even though the file system seemed to still have a lot of free space.
And yet the controller needs free space for some of its internal tasks such as wear leveling and garbage collection.
Luckily manufacturers build all their SSDs with some space which is neither available to the user nor to the OS nor to any utility. This space usually corresponds to 7% of the user accessible space and enables the controller to always have some space for its internal tasks no matter how the SSD is used. It's called over-provisioning.
7% is good but more is better, that's why it's sometimes advised not to format all the available space on the SSD and let some unallocated space. This space will be used by the controller as over-provisioning and added to the pre-existent 7%. It will help reduce the write amplification (the controller will write less onto the NAND) and thus the SSD will maintain good performance over time.
Now going back to the first models of SSDs, if you didn't do that, if you would format all the available space, at the beginning the controller could use the original 7% plus all the free space at the OS level. However if the user wrote a lot of data and deleted it afterwards after a while the controller could only rely on the first 7% for its internal tasks because NAND was full of invalid data and the controller had no means to distinguish between valid data and stale data.
Besides each time the user wanted to write a new file, even a small one like 4KB for example, the controller had to overwrite stale data and you had to pay a performance penalty because the controller had to read a whole block of maybe 512KB to load it into the DRAM chip, modify the portion of data that changed and rewrite the whole block onto the NAND (read-modify-write cycle).
These 2 things were the reason why the performance on the first SSDs would degrade over time.
That's why manufacturers implemented TRIM. Basically TRIM is supposed to tell the controller, each time you erase a file at the OS level, to delete the LBA addresses corresponding to this file in its allocation table, then afterwards at one point in time garbage collection will erase the data on the NAND. Thus, provided that the user let some free space in his file system (10% to 20%) the controller will always have enough over-provisioning and the user will never have to pay the read-modify-write cyle penalty because there will be always some free space on the NAND.
I'm not sure that all of this is 100% correct, it's just what I understood after reading the trilogy of articles about SSDs written by Anand Lal Shimpi. So feel free to correct me.
So TRIM is an important command for an SSD because without it performance goes down.
I think that for the TRIM command to be passed to an SSD 4 things need to support it : the file system, the OS, the SSD and the SATA controller driver.
I mainly use ext4 and ntfs as file systems which support TRIM, my Operating Systems are Windows 7 and Ubuntu which support TRIM (TRIM support was added to the linux kernel in version 2.6.33) and my SSD support TRIM.
However concerning the SATA controller driver I'm completely at a loss.
I've got an AMD motherboard, so here is my first question :
Is there any linux driver for my mobo that supports TRIM (be it proprietary or open-source) ?
(For Intel motherboards I know it's the case but AMD... even after looking on Google I'm still not sure.)
I've got a second question.
I think that if you format a partition with the formatting tool from Windows 7 then TRIM command is sent to the SSD. On the contrary if you delete a partition with the same tool TRIM command is not sent :
sourceTRIM is triggered by two things it seems. Either deleting a file and emptying the recycle bin (to truly delete it) or formatting the drive. Simply deleting a partition doesn't TRIM the entire drive as I found out the hard way.
But what happens if you use GParted live-cd ?
I've read that for Linux to pass the TRIM command to an SSD you have to add the 'discard' option in /etc/fstab
But if I use a GParted live-cd and open a terminal to see what contains /etc/fstab there's no information about the partitions I'm going to format.
Do I have to add a line ([Device] [Mount Point] [File System Type] [Options] [Dump] [Pass]) for each partition I'm about to format ?
If so will the changes be taken into account immediately, don't you need to reboot (and thus lose the changes made in /etc/fstab since it's a live-cd) ?
In other words if I format an ext4 partition with GParted live-cd will it send the TRIM command to my SSD ?
Same question if I format a ntfs partition ?
If I delete a partition ?
And finally if I delete the whole partition table in case I'm going to be starting over from scratch?
Any help and advice on these 2 problems would be greatly appreciated.
Thank you in advance.
PS : sorry if my English was bad, it's not my native language.