4 ms·
Flash is frightening. I wrote a transactional flash file system (well, object store) in the early 90s. It used NOR flash, which allows you slam individual bits
by kabdib 14y ago
Flash is frightening.
I wrote a transactional flash file system (well, object store) in the early 90s. It used NOR flash, which allows you slam individual bits from 1 to zero in any order. Basic strategy for doing a write: Write the payload, verify it, then clear some "commit" bits, and have enough infrastructure bits around that you can handle commit failure from stuck-at-1 errors. My failure model was probably pretty stupid, but it seemed to work well and I never heard of someone losing data. Of course, flash parts were a lot clunkier back then.
Fast-forward 20 years and they're playing terrifying games with those flash cells. I worry that the people writing the firmware are willing to trade off reliability for capacity or speed. Or they make crazy risks ("Hey, this window is only for ten milliseconds, what are the chances?"). I know too many lame firmware engineers to be really comfortable.
The failure modes are not block-by-block now, either. The whole device can go dead just because the firmware lost a lookup table to a bad bit. Something like this very clearly happened to Intel a couple years ago, and I know of other manufacturers who weren't very careful with their firmware quality (along the lines of "If we bump the version number on every fix, this will just make our customers nervous." Wow).
I'd love to see an eMMC spec that:
- Allows raw access to the underlying flash (useful for data recovery, in any event)
- Provides metadata describing the treatment of that flash (how many reads / erases, leveling requirements, geometry info, etc.)
- Provdes access to ECC engines, buffers and other support hardware (to reduce bus traffic and host computation)
... then we could push the data management into a FOSS layer in the host, where people can inspect it, fix it, and improve it.
The combination of a hot commodity, pressure to make it perfom, complex management algorithms and opacity of implementation do not make me feel very happy about flash.
[edit: typos]
- meaty 14y agoSome great ideas there. Agree about complexity - its usually a sign of something dodgy being hidden. Perhaps a flash raid 1 device would suffice?
- kabdib 14y agoThe scary thing is that you lose the whole device, and flash seems more fragile this way that disks are. Perhaps we just understand disk failure modes better, and are more comfortable with them.
- meaty 14y agoGood point. Mechanical disks usually start exhibiting warning signs when failing (the disk in my T61 started clicking about a month ago is being replaced tomorrow). I'm not sure I'll get away with that in the Samsung 840 that is going in it instead. (yes I do backups and rsync hourly before anyone slates me for working on a cranky machine).
- nwh 14y ago> Perhaps we just understand disk failure modes better, and are more comfortable with them. In some ways, predictability is an issue too. SSD typically fail after a relatively set number of write cycles, which doesn't seem too much of an issue until you try to put them into a RAID5 array. I've heard stories of a couple of people trying this, and having multiple drives all fail within hours of each other (usually during the array rebuild). It's something I'd never have thought about had I not been prompted.
- nwh 14y ago> Provides metadata describing the treatment of that flash (how many reads / erases, leveling requirements, geometry info, etc.) My Corsair SSD seems to return some SMART information regarding wear levels, though I'm not altogether sure how to interpret most of it. #177 "Wear Level Count" seems to return the most relevant value, in my case 4% of the total rated write cycles. Not as bad as I expected for a MacBook with 4300 hours of use under it's belt.