A few corrections here, Fish:
- The C300 drives are using a Marvell controller, not JMicron.
Ya, you're absolutely right. I get these two mixed up. It's probably due to my bias against them. I don't think either controller is all that great.
- The SF drives *do* take a performance hit if you fill them up, look at Anand's graphs in his articles.
- The ability of the SF controller to use free space beyond the over-allocated amount has nothing to do with compression. The Intel controller also uses all available free space just like the SF controller does.
I believe you're referring to the graph on this page.
If you read the actual text that accompanies the graph, you will note that the SF drive was filled with completely random bits with a custom build of Iometer in order to defeat the compression algorithm of the SF controller. I'm sure you would agree that under normal use, data written to the drive is much more compressible than the truly random bits used for this test.
I have said this before, for which I am now called a SandForce fanboy, but I believe compression has a huge impact on the performance of a full SF drive. Since you have read the AnandTech articals on this subject, you know that when the SF controller saves disk space through compression, it doesn't report any savings to the operating system. The controller is the only entity that knows about this extra, saved space. Because, like Intel, the controller uses all available empty space as spare area, I don't see how this saved space would go unused by the controller. I simply can't imagine the guys at SF being so slow-witted that they would allow this saved nand to sit on the drive, serving no purpose, when it can be used to improve performance.
I believe the ability of the SF controller to use empty space beyond the over-alocated amount is very much influenced by compression. The Intel drive also uses all unused space, but it doesn't compress, so it has only the default reserve space when the user space is filled.
Last edited:
