An idiots understanding of SSD limitations/trim/GC – guru's please opine

[idata]

In the absence of trim/garbage collection an SSD has the following problem (not present in spinners which can automatically overwrite old data): –In a heavily used drive, the SSD has to find "invalid" pages (as marked by the OS) to write new information. Here we have two sets of problems. Firstly the SSD cannot overwrite the "invalid" page without deleting this page. Secondly, and more seriously, SSD's cannot simply select one or more pages to delete/write but are limited to working with an entire block (each block consisting of 128 pages utilizing 512 K). As a result (barring trim/GC) the SSD has to read the entire block into its cache/flash and perform the delete/write process on the respective pages. It then has to copy the entire "corrected" block from on board cache to the drive even though it might be only working with one or two or more of the total 128 pages within the block. This process is what causes the delays in the heavily used untrimmed SSD. Trim when executed correctly, instantly marks the aforementioned, OS identified invalid pages for deletion. This allows the SSD's controller to execute the time-consuming aforementioned process prior to any writes to these pages (whether this process occurs instantaneously or during idle periods is questionable but irrelevant as long as it occurs relatively quickly). Garbage collection also is designed for the SSD controller to execute a similar erase function based on the design of the SSD controller. Obviously, in very heavily used SSD's and/or inefficient controllers and/or improper OS set up, SSD's will lose their performance and often cause stuttering. In such situations the secure erase followed by an image restore might be the only solution. Wear leveling does not directly affect these processes unless trim/GC cannot keep up with very heavy usage and the drive is saturated. Guru's please opine but be gentle. I am trying my best to understand these processes.

[idata]

"I troll and I learn."

Don't we all.

I see what you are saying, yes that is correct.

I was reading about Write Amplification (WA) and I was under the impression, possibly false, that a WA factor of 1 was either the minimum or the optimal value, perhaps theoretically, and of course I don't have the WA factor equation handy at the moment.

Intel has claimed a WA factor of 1.1, which is excellent. Recently, I read that OCZ (I think is was) claimed they have achieved a WA factor of 0.5. That seemed odd to me, given what I wrote above. I highly doubt that is a false claim, and may have been achieved by a different philosophy in their GC algorithm.

I am wondering what others think about this?

[idata]

I think that SandForce makes that claim because the use a compression algorithm as part of their process. This allows them to reduce the amount of rewrites and potentially increases the life of the drives. Unfortunately this also seems to create the Achilles' heel of the vertex2 sand force drives when trying to handle incompressible data. This is a area where the C 300 has a clear advantage over the sand force OCZ drives. Would welcome any further thoughts.

[idata]

Yes, I am aware of the data compression-thing with the Sandforce controllers/firmware. I wonder about that, and while I don't understand it, there are ramifications of that which could cause issues in other areas.

For instance, that controller obviously must un-compress all data when it is read for use by the OS, user, etc. The compress/decompress process, and vice versa, takes time but apparently does not hurt performance to much. I thought that doing backups of those drives, disk images, etc, would be odd if the data was sent from the SSD in the compressed state, but then they just could not allow that to happen, since the data would be useless on any other 'drive. Storing data in a proprietary format like that is somewhat scary, but I suppose no more so than data stored in some RAID arrays.

Regardless, it seems that the Sandforce SSDs are not quite on the same playing field as other SSDs, due to the compression of data. I wonder if there are any issues that might be caused by the data compression that I am not seeing.

[idata]

The problem I would think where SSD's doing compression and not handling incompressible data well is just down to how fast it can do it like a slow CPU?

I think built in compression on an SSD is not needed...and if anyone wanted compression on an SSD to improve Write Amplification or Endurance NTFS has a compression option and with CPU's being as fast as they are it shouldn't affect performance.

Of course you don't want to use NTFS compression with an SSD that has built in compression nor for programs like Microsoft MSMQ that modifies data through mapped sections in a compressed file that can produce "dirty" pages faster than the mapped writer can write them. The other thing is with NTFS compression you can select what gets compressed but an SSD with built in compression does it all.

This could likely be why Intel SSD's don't do compression?

[idata]

PeterUK wrote:

The problem I would think where SSD's doing compression and not handling incompressible data well is just down to how fast it can do it like a slow CPU?

I think built in compression on an SSD is not needed...and if anyone wanted compression on an SSD to improve Write Amplification or Endurance NTFS has a compression option and with CPU's being as fast as they are it shouldn't affect performance.

Of course you don't want to use NTFS compression with an SSD that has built in compression nor for programs like Microsoft MSMQ that modifies data through mapped sections in a compressed file that can produce "dirty" pages faster than the mapped writer can write them. The other thing is with NTFS compression you can select what gets compressed but an SSD with built in compression does it all.

This could likely be why Intel SSD's don't do compression?

The compression processing is done by the SandForce controller. It does not rely on the host system CPU at all.

The compression is not just for improving write amplification. It helps wih performance as there is less data to read/write. You can see this performance difference on compressable vs uncompressable benchmarks. I won't comment on how the compression algorithm actually works as I doubt anyone outside of SandForce knows and it is hard to run tests.

I believe the concept of on-the-compression is a relatively novel idea.