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.
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.