3 ms·

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

by 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.
  - kabdib 9y ago
    I thought about moving the work that a flash controller did to an OS, on a game console. Would have saved some money (high tens to low hundreds of millions of dollars over the product lifetime). Just too damned risky and complicated to make work, given the ship schedule. The controllers do a lot of work, and provide a pretty clean abstraction over a bunch of complexity and dirty business under the hood.
- nitrogen 9y ago
  UBI does this already for raw flash devices: http://linux-mtd.infradead.org/doc/ubi.html http://linux-mtd.infradead.org/doc/ubi.html

by kabdib 9y ago

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.
- kabdib 9y ago
  I thought about moving the work that a flash controller did to an OS, on a game console. Would have saved some money (high tens to low hundreds of millions of dollars over the product lifetime). Just too damned risky and complicated to make work, given the ship schedule. The controllers do a lot of work, and provide a pretty clean abstraction over a bunch of complexity and dirty business under the hood.
nitrogen 9y ago
UBI does this already for raw flash devices: http://linux-mtd.infradead.org/doc/ubi.html http://linux-mtd.infradead.org/doc/ubi.html