The OCZ Trion 100 SSD Is Running Well On Linux

[phoronix]

Phoronix: The OCZ Trion 100 SSD Is Running Well On Linux

Recently you may have heard of OCZ launching their new Trion 100 series, which is the latest example of low-cost solid-state storage. The OCZ Trion 240GB costs just $90 USD and the larger capacities are also around $0.375 per GB. In having picked up one of these cheap SSDs for another Linux test system recently, I ran some basic open-source Linux benchmarks on the Trion 100...

http://www.phoronix.com/scan.php?page=news_item&px=OCZ-TRION-100-SSD-Linux

[SystemCrasher]

Just 30Tb of writes for 240Gb drive? This TLC nand stuff seems to be really-really bad in terms of write cycling. It barely alive after about 150 rewrite cycles or so. Yikes!

[computerquip]

Just 30Tb of writes for 240Gb drive? This TLC nand stuff seems to be really-really bad in terms of write cycling. It barely alive after about 150 rewrite cycles or so. Yikes!

How are you determining "barely alive"?

[CuriousTommy]

Ever since I heard of the trim issues that Samsung drives have on Linux, I have been looking for an alternative ssd for linux. This Drive could be my new Linux ssd.

http://ocz.com/consumer/trion-100-ssd/specifications

Looking at the specs, it supports trim. Hopefully there is no bugs that messes up trim support.

I am also glad that there is a Linux binary for updating the drivers. Hopefully the process is straight forward unlike the Samsung tools I tried to use... Have you tried updating the firmware Mr. Larabel?

Edit: I took a look at the tool and it's in a nice GUI, Cool! Also on a side note, I found that the firmware currently installed on the drive is the latest one.

[-MacNuke-]

Ever since I heard of the trim issues that Samsung drives have on Linux, I have been looking for an alternative ssd for linux. This Drive could be my new Linux ssd.

Samsung says that it is a bug in the Linux Kernel. They can reproduce it and seems to have a patch.

https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/#july17

[joh22n]

Ever since I heard of the trim issues that Samsung drives have on Linux, I have been looking for an alternative ssd for linux. This Drive could be my new Linux ssd.

Thanks for the info! I checked the Launchpad bug report and considering Samsung 8-series drives are now blacklisted (queued TRIM usage at least) in the kernel it seems that I have to reconsider buying an 850 EVO as my next drive.

[CuriousTommy]

Samsung says that it is a bug in the Linux Kernel. They can reproduce it and seems to have a patch.

https://blog.algolia.com/when-solid-...-solid/#july17

Thanks for telling me that! I feel more better about buying the Samsung SSD. Although I might still get a different SSD just so I can tell which SSD has the OS I want to boot from.

Thanks for the info! I checked the Launchpad bug report and considering Samsung 8-series drives are now blacklisted (queued TRIM usage at least) in the kernel it seems that I have to reconsider buying an 850 EVO as my next drive.

Well the post above has said that it is a Kernel bug. When it gets fixed, the Samsung drive probably get removed from the blacklist, assuming there is no issues. So it might not be a bad idea to get an EVO.


On a off topic note, does the trim issues apply to mac users also?

[joh22n]

Well the post above has said that it is a Kernel bug. When it gets fixed, the Samsung drive probably get removed from the blacklist, assuming there is no issues. So it might not be a bad idea to get an EVO.

I'll wait for the fix and then decide. In the Launchpad bug report, people seem to be quite sure that this is a Samsung firmware bug, but I'll wait and see.

[CuriousTommy]

I'll wait for the fix and then decide. In the Launchpad bug report, people seem to be quite sure that this is a Samsung firmware bug, but I'll wait and see.

Yeah, that seems like the best choice for now.

[SystemCrasher]

How are you determining "barely alive"?

"Barely alive" for flash? Hmm, this requires some knowledge on how flash memory works (Wikipedia can help a lot in this regard). But, it's basically like this: in flash, each cell keeps data as charge trapped in insulated area. In oldest, single-level (SLC) flash, each cell holds one bit. Either charge presents or it is not. Zero or one - one bit of storage. Reading circuitry is simple and memory is quite robust, etc. But people want to store more data. So what's next? Let's store TWO bits in the very same cell. Almost twice as much stroage "for nothing" on more or less the same silicon area. Great, isn't it? Yet there is some price: now reading circuitry should distinguish between 4 charge levels (2^2, two bits, two possible states each). Obviously, reading circuitry should be more smart and overall whole process is much more fragile. TLC flash goes even further. Now it stores THREE bits in same cell. Three times as much storage on the very same die area. But what about levels? Three bits are 2^3 == 8 possible states. So reading circuitry must be able to distinguish 8 various levels of charge to be able to correctly decode 3-bit combo.

That's where we have some nasty catch. Erase-write cycles are not free. They are destructive. Once cell cycled between states, cell parameters change. Some leftovers of charge could remain in cell even if charge is not supposed to be in cell at all, cell could start leaking charge, etc. As memory cycled, these factors are getting worse. At some point, reading cuitry would incorrectly read some bits of stored data. Or charges would leak in foreseeable future, causing data loss. Bit error happens, either immediately after you erased or written or is just loses stored data in unacceptably short timeframe. Needless to say, SLC haves largest margins, being able to withstand about 100 000 or even up to 1 000 000 rewrites before bit errors due to mentioned factors would become frequent. That's why enterprise-level SSDs are still manuactured using SLC, even if it means increased price. But write endurance is MUCH better, makings such SSDs good chouce for frequently updated caches, etc. Two-bit MLCs are much more fragile and would generally fail in about 1000 to 10 000 cycles. This already sucks for most enterpise cache applications, but more or less acceptable for common desktop PC. But TLC SSD? Well, simple and rough calculation for this drive gives idea TLC it uses only rated for about 150 cycles or so. Not much at all to my taste.

Read errors in NAND are not fatal: there is some ECC and it would try to recover failed read using some small amount of data stored "out of band". But it only can handle certain number of errors. If there was too much errors, ECC would fail either and user finally faces inevitable: lost or corrupt data.

But what is "barely alive" for SSD? This is all about heavily cycled cells which are likely to fail very soon. Either due to inability to erase or write properly or due to charge leaks causing data loss in unacceptably short timeframe. That's how "barely alive" looks for SSD. And just about 150 cycles for whole device lifetime does not sounds like a good reliability margin.

What's next? Let's make FLC, FourLevelCell . 10 rewrites should be enough for everyone