Is it so that read/data-fetch cycles don't have any effect on the memory wear and the program-erase cycles are only related to the amount/number of times of write/erase operations?

Here I consider read operation/cycle as fetching or viewing some kind of a file stored on the flash storage device/SSD and write as editing an existing file/creating a new file; and erase as permanently deleting some files.

  • \$\begingroup\$ Bytes Written is only related to Write (and Erase) operations, not Read ops. Otherwise it would be called Bytes Read/Written. (Background : writing involves stressing the cells with relatively high voltage to charge them : reading does not) \$\endgroup\$
    – user16324
    Aug 19, 2021 at 14:35
  • 1
    \$\begingroup\$ It's the erase/program cycle that is limited. Read does not matter. \$\endgroup\$ Aug 19, 2021 at 14:51

1 Answer 1


Flash memory contains an insulating layer (typically silicon dioxide), which insulates a floating polysilicon (or nitride) gate that holds a stored charge. The write and erase process must tunnel electrons through the oxide, which involves high voltages and leads to oxide degradation, leading to permanent cell wear. As these cells become unusable beyond the point that error correction and recovery can occur, the flash controller puts spare cells (not initially used to store user data) into service.

The warrantied TBW (Terabytes Written) value is a statistical value, where we expect the controller to run out of those spare cells and the SSD to fail.

On the other hand, reading leads to a different effect called read disturb, where the moderately high voltages needed to read one cell may slowly disturb adjacent cells. This may eventually be expected to require a re-write of disturbed cells; an example flash-translation-layer implementation in the above paper does a rewrite after 50k reads.

However, the actual wear from read disturb still comes mostly from the indirectly incurred writes, and at a much lower rate. Assuming that 50k disturbing reads cause enough disturb to put the flash page into an erase-rewrite cycle, we can expect an SSD rated for 600 TBW to reach 600-TBW-by-read-disturb-only after 600 TBW * 25000 = somewhere on the order of 15 exabytes (!) of reads. (I also assumed that the actual read disturb itself did an equal amount of oxide damage as the subsequent rewrite, which is why I use 25000 and not 50000).

I'd also like to clear up some misconceptions:

Here I consider read operation/cycle as fetching or viewing some kind of a file stored on the flash storage device/SSD

Yes, this makes sense. Reading files, the filesystem header, directory lists on the filesystem, etc are all read operations. They produce read disturb.

and write as editing an existing file/creating a new file;

Not necessarily. Creating a new file will cause writes assuming that the data is being written to an already-erased block. It may also cause reads if the filesystem metadata needs to be read to find open spots for the data (e.g. if the filesystem bitmap is not cached in RAM).

If the flash translation layer decides to write to a block that already has programmed contents, it must be erased; this can occur if there are no unused blocks (e.g. if you filled the drive up thus programming all flash blocks, and then deleted files to make space int the filesystem). If it writes to a free block, it might only be a write.

and erase as permanently deleting some files.

Not quite, see above. A permanent deletion is usually a write and possibly an erase to remove the file from the filesystem listing. A full disk wipe might just be the deletion of an onboard encryption key (called PSID revert), or it may just tell the FTL to treat all blocks as unused, meaning that they will undergo a write-erase cycle when they're needed for a write.

  • 1
    \$\begingroup\$ Impressed! I have not thought "disturb" can be a trouble. \$\endgroup\$
    – jay
    Aug 19, 2021 at 14:53
  • 1
    \$\begingroup\$ I hadnt expected that reads can degrade the data. Thats disturbing ! (pun intented!) \$\endgroup\$ Aug 19, 2021 at 17:05
  • 1
    \$\begingroup\$ @lousycoder The 25000 factor comes from the fact that I expect 50000 reads to induce two writes worth of degradation (a factor of 25000:1) for the particular flash memory in the paper. It's probably a conservative estimate - I assume that the reads themselves disturb the cell for a write's worth of damage, plus of course rewriting the cell to fix the disturb counts as a write. If you assumed that only the rewrite counted and read disturb didn't itself wear the cell, you'd end up with 30 exabytes which is similarly absurdly large. \$\endgroup\$
    – nanofarad
    Nov 26, 2021 at 18:56
  • 1
    \$\begingroup\$ @lousycoder According to the paper, it's the neighbor cells within the same block. I also make a fairly major assumption: An entire block is read at once. This isn't necessarily a bad assumption as the entire block might include ECC bits, and chances are you'll want to prefetch the rest of the block anyway. \$\endgroup\$
    – nanofarad
    Nov 26, 2021 at 19:00
  • 1
    \$\begingroup\$ @lousycoder startup is reads. Shutdown isn't much of anything, maybe some small writes depending on the OS. \$\endgroup\$
    – nanofarad
    Nov 28, 2021 at 13:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.