Mitigating the problem
Mitigating the problemHow do you stop a drive from slowing down from the controller/OS and page/block deleting issue? There are three ways around the problem. The first is with having greater-than-advertised capacity on the drive, such that the 'overflow' takes care of writing without having to erase complete blocks, but this is only a short-term measure as you will run out of space as more data is filled.
The second option is to equip the drive with what's known as the ATA TRIM command, whereby, with a compliant OS - Windows 7, for example - the SSD controller is informed when a file deletion is required by the OS. The file is then physically deleted by reading the block to and from the buffer, as described on the previous page, but the advantage is that the SSD's controller always tallies up with the OS.
The penalty of reading in and out of the buffer for erasing blocks when writing pages is still there, of course, but the drive can execute it on an on-the-fly basis - timely housekeeping, shall we say - and doesn't have to scratch around furiously deleting the mismatch that would occur without the controller knowing exactly what's deleted and when, as capacity runs out. Cutting down on the deletes is not only beneficial for keeping performance up, it increases the SSD's lifespan by extending write endurance, too.
The third method is the most draconian and unsuitable for the SSD if it's a boot drive. The drive can be formatted via a secure-erase command to a state where all the SSD's pages are empty, bringing it back to an as-new state. You will lose all data, naturally.
