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]

The SF-2xxx is going to be SATA 6Gb/s so port bandwidth won't be a problem.

I was thinking more on the connecting port then what the SSD has.

[idata]

I've just had a brain wave!

So SSD's in RAID can't TRIM and lets say can't GC when the SSD's in the array are filled with data and garbage the SSD does the read-modify-write thing to write new data.

Now here's the thing what if the RAID controller tells the OS its going to write some data...the OS looks at the array to see where its free (from it point of view) which the SSD does the read-modify-write thing but the RAID controller that was going to write data in the free space doesn't so that the read-modify-write operation just writes back data that is valid and frees the free space.

[idata]

Anand goes some preliminary SF-2582 benchmarks with compressible and uncompressible data: http://www.anandtech.com/show/4100/ocz-vertex-pro-3-demo-worlds-first-sandforce-sf2000 http://www.anandtech.com/show/4100/ocz-vertex-pro-3-demo-worlds-first-sandforce-sf2000

I'm a bit confused on your proposal. Is it that you want the RAID controller to hold the write in cache while SSD is going through the long read-modify-write process? This only works if the controller has enough cache to hold the requests while the SSD is trying to catch up on completing them all.

Also, the OS doesn't look at where the array is free though. It just tells the controller to do something with its member disks.

[idata]

I'm a bit confused on your proposal. Is it that you want the RAID controller to hold the write in cache while SSD is going through the long read-modify-write process? This only works if the controller has enough cache to hold the requests while the SSD is trying to catch up on completing them all.

You need coffee...no this has nothing to do with cache this is to do with what the read-modify-write process writes back by faking write so that valid data is written back and garbage is not.

The OS shows 80GB free on a array of a total 160GB but that free space has garbage with the only option to read-modify-write but if by some way you can fake a 70GB write the SSD's in the array will read-modify-write but what you don't do is write 70GB of data you read-modify-write the valid data back should it be a block with some valid data on and with other blocks with garbage on read-modify-write nothing back to the SSD's so as to free space up.

[idata]

I see... but would increase write amplification drastically though?