4 ms·

AFAIK, there is no need to do "wear leveling" for reads, SSDs have "unlimited" life cycle reads. So the first SSD seeing ten times the reads will not make it fa

AFAIK, there is no need to do "wear leveling" for reads, SSDs have "unlimited" life cycle reads. So the first SSD seeing ten times the reads will not make it fail sooner.

rcthompson 9y ago
Even if reads did wear out an SSD, wouldn't it be better to wear them out one at a time rather then wear them all out equally so they all fail in rapid succession once they reach the end of their life cycles?
- gist 9y ago
  > wouldn't it be better to wear them out one at a time rather then wear them all out equally Agree and this would seem to make sense. It is like having two rolls of paper towels in the kitchen. If you use both of them you are only extending the time till empty. If you use one of them only you can then replace that when it runs out running on the 2nd in the time it takes to replace.
- baruch 9y ago
  On one hand this is true, on the other, if you have two devices that can work for 5 years and then you anyway replace them because they are now too small and never failed you have one device that you replaced and the other hardly in use and you have an increase TCO since you had to buy another device in the middle of the life cycle. Not that it is really critical, read-disturb exists but it is on a far lower scale compared to erase endurance.
- xorgar831 9y ago
  I would say no, you'd want the whole disk to fail then so you can just replace it vs. it getting smaller over time, which would make capacity planning pretty complex.
  - rcthompson 9y ago
    We're talking about RAID1 here, so multiple SSDs. I'm saying you don't want multiple disks to fail in rapid succession, which is what you'd maybe get if you exactly equalized the wear on them.
    - xorgar831 9y ago
      That makes sense, and you actually do see RAIDs fail like that in the real world sometimes even on non-SSDs.
- pkaye 9y ago
  If the SSD has mechanisms to protect against read disturb, they should also factor that into the life remaining indicator to plan for replacement.
  - wtallis 9y ago
    There's no need. If a page has been read enough times to produce a read disturb, the remedy is to re-write the page, which moves the write endurance indicator (by the smallest possible increment).
microcolonel 9y ago
This is not necessarily about NAND wear leveling, it could be about load balancing. SSDs have limited ability to service requests, and they dissipate heat when they do so. At high load, one of the disks is going to be hotter for longer, and wear out faster as a result. Then again, not sure if author was really thinking about these sorts of things, who knows.
- loeg 9y ago
  If both SSDs are idle most of the time, this isn't exactly a high load scenario, is it?
- sn 9y ago
  The last thing you want to happen in a RAID is for all the drives to wear out simultaneously, so this could be a feature rather than a bug.
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.
    - 9y ago
Avernar 9y ago
One benefit of spreading out reads is detecting bad sectors on the drives that were normally not going to see much reads. Then the good data can be copied from the other mirror.
- sn 9y ago
  You're better off running a weekly SMART long test https://linux.die.net/man/5/smartd.conf https://linux.die.net/man/5/smartd.conf and/or a periodic RAID check https://raid.wiki.kernel.org/index.php/RAID_Administration https://raid.wiki.kernel.org/index.php/RAID_Administration

AFAIK, there is no need to do "wear leveling" for reads, SSDs have "unlimited" life cycle reads. So the first SSD seeing ten times the reads will not make it fail sooner.

rcthompson 9y ago

Even if reads did wear out an SSD, wouldn't it be better to wear them out one at a time rather then wear them all out equally so they all fail in rapid succession once they reach the end of their life cycles?

gist 9y ago
> wouldn't it be better to wear them out one at a time rather then wear them all out equally Agree and this would seem to make sense. It is like having two rolls of paper towels in the kitchen. If you use both of them you are only extending the time till empty. If you use one of them only you can then replace that when it runs out running on the 2nd in the time it takes to replace.
baruch 9y ago
On one hand this is true, on the other, if you have two devices that can work for 5 years and then you anyway replace them because they are now too small and never failed you have one device that you replaced and the other hardly in use and you have an increase TCO since you had to buy another device in the middle of the life cycle. Not that it is really critical, read-disturb exists but it is on a far lower scale compared to erase endurance.
xorgar831 9y ago
I would say no, you'd want the whole disk to fail then so you can just replace it vs. it getting smaller over time, which would make capacity planning pretty complex.
- rcthompson 9y ago
  We're talking about RAID1 here, so multiple SSDs. I'm saying you don't want multiple disks to fail in rapid succession, which is what you'd maybe get if you exactly equalized the wear on them.
  - xorgar831 9y ago
    That makes sense, and you actually do see RAIDs fail like that in the real world sometimes even on non-SSDs.
pkaye 9y ago
If the SSD has mechanisms to protect against read disturb, they should also factor that into the life remaining indicator to plan for replacement.
- wtallis 9y ago
  There's no need. If a page has been read enough times to produce a read disturb, the remedy is to re-write the page, which moves the write endurance indicator (by the smallest possible increment).

microcolonel 9y ago

This is not necessarily about NAND wear leveling, it could be about load balancing. SSDs have limited ability to service requests, and they dissipate heat when they do so. At high load, one of the disks is going to be hotter for longer, and wear out faster as a result. Then again, not sure if author was really thinking about these sorts of things, who knows.

loeg 9y ago
If both SSDs are idle most of the time, this isn't exactly a high load scenario, is it?
sn 9y ago
The last thing you want to happen in a RAID is for all the drives to wear out simultaneously, so this could be a feature rather than a bug.

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.
  - 9y ago

Avernar 9y ago

One benefit of spreading out reads is detecting bad sectors on the drives that were normally not going to see much reads. Then the good data can be copied from the other mirror.

sn 9y ago
You're better off running a weekly SMART long test https://linux.die.net/man/5/smartd.conf https://linux.die.net/man/5/smartd.conf and/or a periodic RAID check https://raid.wiki.kernel.org/index.php/RAID_Administration https://raid.wiki.kernel.org/index.php/RAID_Administration