So can the cells simply degrade from QLC to a TLC and then down to a MLC and finally SLC with the controller somehow knowing what the cell is capable of?
I suppose it might not be that simple.
QLC flash is tricky stuff to make and use, so here's a primer
QLC flash primer Quad-level cell (QLC) flash stores 4 bits per NAND cell and is very tricky stuff to use, far trickier than TLC (3 bits/cell) which is harder to user than 2 bits/cell MLC which, you guessed it, is more difficult to use than 1bit/cell SLC. Why is QLC the hardest of all to use? It is the slowest to read and write …
-
-
Thursday 28th July 2016 15:30 GMT chris 143
I was wondering something similar
I guess it's possible, but then the storage capacity of the cell drops too.
If it turned out you had a very small quantity of regularly written data on a drive of mostly static data perhaps it'd allow you to squeeze a bit more endurance out of the drive, but it probably suggests that you're buying the wrong grade of flash
-
-
Thursday 28th July 2016 16:13 GMT toughluck
What's the point?
I could understand the move from SLC to MLC -- twice the capacity without significant downsides (although SLC continued to be developed until it achieved 100,000 P/E cycles), as MLC wasn't that much slower.
Already with TLC the move seemed forced -- just 50% more capacity, but bit error rates went up, double digit percentage wise, so a lot of the extra capacity needed to be used for ECC, overprovisioning, etc.. It really felt like putting the cart before the horse.
And now, moving from TLC to QLC increases raw capacity by 33%. But nobody mentions what happens to error rate. I mean, if it shoots up by 40%, you're adding capacity that you can't even take any advantage of because you need to add error correction and even then you're unsure if it works.
Why bother with it at all? Where will it end up? 8LC that has barely twice as much capacity than QLC, but 0.01 P/E cycles per cell, which means you have 1% chance that the data was written correctly? And then it takes half a second to read data and a full second to write it? This sounds sooooo useful.
-
Thursday 28th July 2016 17:53 GMT Anonymous Coward
Bit value to level mapping
I wouldn't mind betting that they encode the levels somewhat differently using Gray code or similar, as this would produce only a single-bit error between adjacent "levels".
i.e. for MLKC it's more probable they use the order 00 01 11 10 than 00 01 10 11 because if a voltage was supposed to be sitting at the 01 level and it instead was a bit high, 11 is only a one-bit error, 10 is a two-bit error.
-
Thursday 28th July 2016 22:08 GMT toughluck
Re: Bit value to level mapping
It probably is Gray code, since a single bit error will be caught by parity and corrected by ECC, while a two bit error would be undetectable by parity and detectable, but not fixable by ECC, and three bit errors would be detected by parity, but typically not detected or fixable by ECC.
It's also likely that data in a block is written using RLL algorithms to make sure there's as much variance as possible to feed to Maximum Likelihood and Viterbi algorithms, even though there's no analog to digital intermediate step controlled directly by the controller.
-
-
Friday 29th July 2016 13:28 GMT DCFusor
And then spinning rust
Too much specsmanship and too many MBAs falling for it. I use both flash (various level counts) and rust here. I predict that after not too long, when a lot of flash starts failing all too often (with the usual lousy, missing, or inoperable backups) the reliability of not-ridiculously-high density spinning rust will become attractive again. You might guess I'm not so fond of some of the later tricks spinning rust has employed to try to keep pace. Hey guys, don't forget your real selling point is far better reliability and not too ridiculously slow speed.
Speed/dollar is one thing, but most of the monkeys don't figure in speed-to-failure either, don't even know what their read/write situation is (much less amplification) along with the ooh-shiney usual issue.
Heck, there's even *read* disturbance in this stuff. Shame on me for being an EE for most of 5 decades and understanding that sort of thing. And oh, what they are calling tunneling is not that - give me a break, in the real world we call that arcing. Tunneling doesn't do damage..
Pretty decent video on how bad it was even at single layer lives here (Bunnie Huang) http://www.bunniestudios.com/blog/?p=3554
-
Monday 15th August 2016 15:33 GMT Equals42
Re: And then spinning rust
The power and space savings of 60 and 100TB 3.5" flash is hard to beat with spinning rust. I have an affinity with it as well having spent some time up on the hill above Almaden Valley where a lot of good research was done. However, >1 watt at idle vs 8 watts is huge especially when you have to have 10 or more spinning disks to get the same capacity. That's nearly 2RU in a typical 12 disk per 2RU config (though I know you can get denser) and 80 watts vs ONE 3.5' drive and <1 watt for your typical archive storage where it should be idle quite a bit. Even when busy you save power just not as dramatically. Add in the crap durability of SMR and I don't see how spinning disk even competes going forward. if your needs are more in the speed and capabilities range, then MLC is your buddy.
I'm not going to argue about tunneling vs arcing. Call it what you want. It works and is proven. You worried about arcing while you fill your tank at the gas/petrol station and read email?
-
Biting the hand that feeds IT
