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'm not a guru, but I would not describe that as an idiots understanding

[idata]

Yup... that's it is summary.

[idata]

Yes, quite accurate, hardly an "idiots understanding" of SSDs. One statement did catch my eye, that being:

"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."

My interpretation of this may not be what you meant, and my detail nit-picking notwithstanding, but TRIM and GC have nothing to do with the need to read a block into cache for an erase operation, that is just innate in Flash memory, their layout, or the controllers for some reason. I imagine you had something else in mind.

This seeming requirement to only work with blocks during delete operations is a huge stumbling block for SSDs. Remove that constraint, and the NAND flood gates will be open much wider. Even page level erases would make a big difference. Wouldn't it be great if the new G3's had that as a feature! NOT trying to start a rumor here, but OMGosh, I'm sure you know what I mean!

We certainly need more idiots like you Snakeyeskm!

[idata]

Appreciate the feedback guys.

parsec, appreciate your point, what I meant was that it was because of that cumbersome read/erase/write process trim/GC were required to trigger the preemptive read/erase part of the process so that the block was ready for just the write process.I hope that is consistent with your understanding.

I hope you are right about the G3's. The whole game is now about Write Amplification in SSD's an area in which Intel has always had the lead. But that's a whole another topic.Thanks for the feedback and your many helpful posts scattered through this forum. I troll and I learn.