5 ms·

Not actually true; SSDs experience "read disturbance" caused by application of read voltages. Essentially, the cells being read, and those nearby, experience a

by kabdib 9y ago

Not actually true; SSDs experience "read disturbance" caused by application of read voltages. Essentially, the cells being read, and those nearby, experience a little wear on each read operation. It's a lot less wear than a write, but it's still there. When I last looked at this, devices could suffer (say) 3K writes, and once written a cell would have to be re-written after 3K reads in order to maintain proper voltage levels.

ricardobeat 9y ago
How do you keep a counter for each cell? Who keeps a counter for the cell that stores the counter?
- gruez 9y ago
  usually a more durable form of memory (SLC as opposed to TLC or MLC)
- baruch 9y ago
  Some of the meta data is only kept in ram and updated from time to time to special regions. These special regions can also suffer from endurance issues but are usually are SLC-use-MLC so they wear slower but it is a known failure mode for the metadata locations to wear and we've had it happen to us during testing, especially if we did lots of firmware upgrade/downgrade testing.
- kabdib 9y ago
  You can't really individually address a cell; a single read will drag in a bunch of cells, if only for ECC. Write granularity varies from device to device, but is often on the order of 256 or 512 bytes (though "append only" operations to blocks are sometimes supported). Erase granularity is what really matters, with values on the order of 64K being popular. So really you just need to keep track of erase block counts, which is relatively easy, and just maintain a "guess" as to read counts. It's much, much harder to keep track of logical block location, especially if you need to handle surprise removal of power.
  - derefr 9y ago
    > It's much, much harder to keep track of logical block location, especially if you need to handle surprise removal of power. Is there a good reason at this point for Flash controllers to bother doing this part at all, instead of: 1. maintaining the per-block erase count metrics internally; 2. exposing the raw physical blocks over ATA; 3. adding an ATA protocol extension that returns the erase-count for a block whenever it's read/written? Under such a system, the OS would maintain the logical block map (probably as a "layer" in logical volume management, mapping a wear-prone PV to a wearless, but gradually shrinking LV.) It could even put the logical-block-map metadata on a different disk, or pool the logical block maps for a bunch of disks together for a RAID-set and then RAID-mirror the pool, or whatever else. Basically you could play around with such maps the way you can play around with Linux's thin-pool metadata volumes.
    - baruch 9y ago
      There are quite a bit more complicated issues that require handling than just the erase count for each erase block. One part is that there are many things that the SSD controller does and keeps track of in order to increase the endurance to the maximum, things like: 1. How many bits of error did we detect in the read? Maybe it's time to relocate the data before it dies completely? 2. How long does the write takes? Maybe it is time to retire this block because it is near dead for unknown reasons? 3. How many times was this block read? Maybe it is time to relocate it before we risk read-disturb issues? 4. Try to distribute data evenly across the flash dies? 5. Ensure we have enough erased blocks to write into to avoid blocking new writes. 6. Can I do some background operation? I really need to garbage collect and rescue some nearly lost data. What you suggest (and I entertained for a while too) is to return to the pre-IDE (RLL/MFM) days where the OS would do all the hard work and get all the flexibility. But the OS vendors do not want that complexity, with the more advanced technologies involved it is hard work and more importantly, it varies between vendors and for flash it can even need tuning for different flash generations or even batches. The OSes don't want that complexity. On the other side, the different SSD vendors want to use the lowest flash chips and get maximum revenue. The algorithms that they implement are their trade secrets and the thing that makes them able to charge more for the better devices. If they were reduced to a flash dealer they would find themselves getting less money. I do think that having a nearly raw flash interface and having a better processor above with possibly better algorithms would yield better results (especially if you integrate it deeper into the user application) but the complexity gets that much higher as well for the entire app and when (not if) there will be another technology the entire app will need to be rewritten which sucks.

by kabdib 9y ago

ricardobeat 9y ago

How do you keep a counter for each cell? Who keeps a counter for the cell that stores the counter?

gruez 9y ago
usually a more durable form of memory (SLC as opposed to TLC or MLC)
baruch 9y ago
Some of the meta data is only kept in ram and updated from time to time to special regions. These special regions can also suffer from endurance issues but are usually are SLC-use-MLC so they wear slower but it is a known failure mode for the metadata locations to wear and we've had it happen to us during testing, especially if we did lots of firmware upgrade/downgrade testing.
kabdib 9y ago
You can't really individually address a cell; a single read will drag in a bunch of cells, if only for ECC. Write granularity varies from device to device, but is often on the order of 256 or 512 bytes (though "append only" operations to blocks are sometimes supported). Erase granularity is what really matters, with values on the order of 64K being popular. So really you just need to keep track of erase block counts, which is relatively easy, and just maintain a "guess" as to read counts. It's much, much harder to keep track of logical block location, especially if you need to handle surprise removal of power.
- derefr 9y ago
  > It's much, much harder to keep track of logical block location, especially if you need to handle surprise removal of power. Is there a good reason at this point for Flash controllers to bother doing this part at all, instead of: 1. maintaining the per-block erase count metrics internally; 2. exposing the raw physical blocks over ATA; 3. adding an ATA protocol extension that returns the erase-count for a block whenever it's read/written? Under such a system, the OS would maintain the logical block map (probably as a "layer" in logical volume management, mapping a wear-prone PV to a wearless, but gradually shrinking LV.) It could even put the logical-block-map metadata on a different disk, or pool the logical block maps for a bunch of disks together for a RAID-set and then RAID-mirror the pool, or whatever else. Basically you could play around with such maps the way you can play around with Linux's thin-pool metadata volumes.
  - baruch 9y ago
    There are quite a bit more complicated issues that require handling than just the erase count for each erase block. One part is that there are many things that the SSD controller does and keeps track of in order to increase the endurance to the maximum, things like: 1. How many bits of error did we detect in the read? Maybe it's time to relocate the data before it dies completely? 2. How long does the write takes? Maybe it is time to retire this block because it is near dead for unknown reasons? 3. How many times was this block read? Maybe it is time to relocate it before we risk read-disturb issues? 4. Try to distribute data evenly across the flash dies? 5. Ensure we have enough erased blocks to write into to avoid blocking new writes. 6. Can I do some background operation? I really need to garbage collect and rescue some nearly lost data. What you suggest (and I entertained for a while too) is to return to the pre-IDE (RLL/MFM) days where the OS would do all the hard work and get all the flexibility. But the OS vendors do not want that complexity, with the more advanced technologies involved it is hard work and more importantly, it varies between vendors and for flash it can even need tuning for different flash generations or even batches. The OSes don't want that complexity. On the other side, the different SSD vendors want to use the lowest flash chips and get maximum revenue. The algorithms that they implement are their trade secrets and the thing that makes them able to charge more for the better devices. If they were reduced to a flash dealer they would find themselves getting less money. I do think that having a nearly raw flash interface and having a better processor above with possibly better algorithms would yield better results (especially if you integrate it deeper into the user application) but the complexity gets that much higher as well for the entire app and when (not if) there will be another technology the entire app will need to be rewritten which sucks.