For full details of how we conduct our Iometer tests, please refer to this article.
Random read performance is unchanged from the 1TB models, but as we already noticed in the Storage Bench tests the 2TB models are more power efficient.
Despite having equal performance at low queue depths, the 2TB models don't performance as well at QD8 and QD16. It's a marginal difference, but it's an interesting observation that further speaks for the controller not being ideal for over 1TB of NAND.
Random Write Performance
Random write performance is also equivalent to 1TB Pro and EVO, but power consumption decreases, resulting in increased power efficiency.
Similarly, queue depth scaling is identical to smaller capacities.
The bug turned out to be in the Linux kernel, not in Samsung SSDs, as you can see in the first link once you scroll down the updates. Samsung has developed a kernel patch to fix the issue too.
IF you follow through to the mailing list discussion for the bug fix, the problem is with the kernel overwriting a pointer when it shouldn't be. If I'm following it correctly, it impacts any SSD brand in RAID0 with trim enabled.
There are two forms of TRIM these days. The original, Windows-supported, inline TRIM and the latest, queued TRIM. The latter is what is the problem on Samsung drives. I encourage you to fully investigate the issue.
Inline TRIM is known to cause delays with certain drives and certain host systems because it can take over IO on a drive and freeze other commands until TRIM is complete. The number of drives and systems effected is quite low, but it is enough for some people to disable TRIM or use a nightly TRIM script (fstrim).
That was my first reaction, too. But judging from the message on the mailing list and the patch, it is indeed a kernel issue and not specific to Samsung drives. It seems so stem from using queued TRIM on software RAID0, which is a moderately questionable configuration anyway. I guess Algolia did not tell the whole (probably embarrassing) story since there is only one mention of Linux software RAID in the entire article. Maybe they didn't configure their Intel drives the same way?
I was set on an Intel 730 for a 7mm SATA role up until a few minutes ago because I had read about this, too. But in light of this, one can probably use Kristian's "best 6Gbps SATA SSD" without excessive worry.
We’ve updated our terms. By continuing to use the site and/or by logging into your account, you agree to the Site’s updated Terms of Use and Privacy Policy.
Facebook
Twitter
RSS
66 Comments
View All Comments
vFunct - Thursday, July 23, 2015 - link
Any info about the well known TRIM bug in these drives?vFunct - Thursday, July 23, 2015 - link
TRIM bug reported here: https://blog.algolia.com/when-solid-state-drives-a...and here:
https://bugs.launchpad.net/ubuntu/+source/fstrim/+...
Kristian Vättö - Thursday, July 23, 2015 - link
The bug turned out to be in the Linux kernel, not in Samsung SSDs, as you can see in the first link once you scroll down the updates. Samsung has developed a kernel patch to fix the issue too.BillyONeal - Thursday, July 23, 2015 - link
Well they patched the kernel to work around the firmware bug; but that doesn't mean it was a kernel bug.Kristian Vättö - Thursday, July 23, 2015 - link
There was never a problem with TRIM under Windows or OS X.DanNeely - Thursday, July 23, 2015 - link
IF you follow through to the mailing list discussion for the bug fix, the problem is with the kernel overwriting a pointer when it shouldn't be. If I'm following it correctly, it impacts any SSD brand in RAID0 with trim enabled.leexgx - Thursday, July 23, 2015 - link
did not affect the Intel SSDsmooninite - Thursday, July 23, 2015 - link
Kristian,There are two forms of TRIM these days. The original, Windows-supported, inline TRIM and the latest, queued TRIM. The latter is what is the problem on Samsung drives. I encourage you to fully investigate the issue.
Inline TRIM is known to cause delays with certain drives and certain host systems because it can take over IO on a drive and freeze other commands until TRIM is complete. The number of drives and systems effected is quite low, but it is enough for some people to disable TRIM or use a nightly TRIM script (fstrim).
sustainednotburst - Friday, July 24, 2015 - link
Algolia stated Queued Trim is disabled on their systems, so its not related to Queued Trim.editorsorgtfo - Thursday, July 23, 2015 - link
That was my first reaction, too. But judging from the message on the mailing list and the patch, it is indeed a kernel issue and not specific to Samsung drives. It seems so stem from using queued TRIM on software RAID0, which is a moderately questionable configuration anyway. I guess Algolia did not tell the whole (probably embarrassing) story since there is only one mention of Linux software RAID in the entire article. Maybe they didn't configure their Intel drives the same way?I was set on an Intel 730 for a 7mm SATA role up until a few minutes ago because I had read about this, too. But in light of this, one can probably use Kristian's "best 6Gbps SATA SSD" without excessive worry.