Slashdot Mirror
Israeli Startup Claims SSD Breakthrough
Lucas123 writes "Anobit Technologies announced it has come to market with its first solid state drive using a proprietary processor intended to boost reliability in a big way. In addition to the usual hardware-based ECC already present on most non-volatile memory products, the new drive's processor will add an additional layer of error correction, boosting the reliability of consumer-class (multi-level cell) NAND to that of expensive, data center-class (single-level cell) NAND. 'Anobit is the first company to commercialize its signal-processing technology, which uses software in the controller to increase the signal-to-noise ratio, making it possible to continue reading data even as electrical interference increases.' The company claims its processor, which is already being used by other SSD manufacturers, can sustain up to 4TB worth of writes per day for five years, or more than 50,000 program/erase cycles — as contrasted with the 3,000 cycles typically achieved by MLC drives. The company is not revealing pricing yet."
You have an interesting point there.
Several years ago, maybe back in 2005, Anobit visited us and showed off what they were working on. They were little guys in the flash/solid state business and had come out with this nifty algorithm that would allow the flash with really low read/writes with perform like today's current SSDs.
They were the first (that I know of) to come up with a way to spread the writes across unused portions of memory so that on average, every bit of memory would have the same amount of wear on them. It wasn't until several years later that I saw on Slashdot that Intel had come up with this "new" idea in their SSDs.
Back at the time, the Anobit technology was really cool. But unfortunately, they were prohibitively expensive and we could not use them in our rugged systems.
Seems that they have still been hard at work over there. Very cool. They deserve the success.
I suspect this will eventually bring down the manufacturing costs of Enterprise class drives, rather than making consumer drives "more reliable". I think reliability concerns with current consumer-oriented MLC designs to be overstated.
Anecdotally, my Intel 160GB G2 drive is going on 7 months of usage as a primary drive on a daily used Win7-64 box, and has averaged about 6GB per day of writes over that period (according to Intel's SSD toolbox utility). Given that rate of use over a sustained period (which theoretically means it could last decades, assuming that some as yet undiscovered manufacturing defect doesn't cut it short) combined with the fact that even when SSDs fail, they do so gracefully on the next write operation, I just don't see the need for consumer-oriented drives to sport such fancy reliability tricks.
there are x-MB where they are labeled bad blocks, always. The firmware updater (which can be written in a script since writes to these bad blocks are just a dd in a specific place), the controller checks a signature, and if passed then halts all writes and reads while it upgrades the firmware.
Then when it completes all reads and writes resume. ;) Yes I know that can be disastrous but that seems like a good way to live update.
Several years ago, I wrote an ATA drive firmware flash driver and utility, to allow my company's customers to upgrade firmware in the field. Let me explain how drive firmware flash works.
Most/all modern drives (or at least Enterprise versions) support the ATA DOWNLOAD_MICROCODE command. The flash chips on the electronics board (or reserved sectors on the platters, depending on the implementation) have sufficient capacity to hold the running firmware, and to hold the new version. The new version is buffered in the drive, validated, then written to the chips/spindle, validated again, then activated and the drive reset.
Modulo some minor drive-specific quirks, the DOWNLOAD_MICROCODE command works as specified. Other than adding model strings to the utility's whitelist, the Intel X25-Es worked without issue. While we've always recommended performing the flash from single-user mode and immediately rebooting, I've done it during normal operations plenty of times. The main things are to remember to quiesce the channel before the doing the flash, and properly reinitializing it afterwards.
Posting anonymously because I'm revealing details about my job.