I'm trying to understand this. Say I have a 256GB SSD, 180GB of which are already occupied by permanent files (OS, installed programs etc.). The remaining 70GB or so gets new files created and deleted. Doesn't this mean the the NAND chips of that portion will get weared out earlier than the area whose files are not modified? Or does SSD move the non-changing files too over the course of time?

  • The short answer is that SSDs move blocks around all the time, and don't really care if the data is actively referenced or not. Consider that deleting files normally only removes the pointer to the blocks from the file system, it doesn't actually clear the data blocks. I don't have enough time to compose a proper answer right now, but that'll most likely be the gist of an answer also with references. – user Apr 17 '15 at 9:58
  • If your OS does use the TRIM command from time to time, it will certainly clear the data blocks after you deleted a file. At least periodically. And even if it doesn't: the blocks need to be cleared the next time you want to write to it. – Slizzered Apr 17 '15 at 10:29
  • The same way it always does just with the cells that are not marked as having data on them by the filesystem. – Ramhound Apr 17 '15 at 10:59
  • I would say that the correct answer is 'it depends' ... mainly on the SSD, or more specifically its controller and firmware. Wearleveling algorithms will differ for different sillicon and different manufacturers. – Fox Apr 17 '15 at 13:15

The SSD moves non-changing files around over the course of time.

First of all, you have the virtual sectors that are exposed to the operating system (not to be confused with file system clusters), and then you have the physical cells in the flash chips. As the flash controller allocates/deallocates cells, it remaps the virtual sectors accordingly so it is transparent to the operating system (the same virtual sectors may appear at different locations in the flash cells at different times).

Second of all, SSDs actually have spare cells that are not usable as free space. They're specifically set aside for the purpose of wear leveling, mitigating write amplification, and remapping dead cells. That way, even if your SSD has zero bytes of free space on it, the flash controller still has room to perform wear leveling.

Let's say you have a 500 GB SSD that is 100% full. Now let's say that 499 GB of that data is a file that never changes, but you have a 1GB file that changes all the time. If you delete that 1GB file and then copy over another 1GB file, the flash controller will do one of two things at that moment:

  • All or some of the new data will be allocated to spare cells, leaving the old cells in a still-trimmed state.
  • 1 GB worth of cells within the 499 GB of data that never changes will be copied to other available cells. The old cells will then be erased and rewritten with the new data.

In both cases, the virtual sectors presented to the operating system never change, so the OS is unaware of what's actually happening. The flash controller keeps a mapping table of memory cells to virtual sectors.

The wear leveling algorithm's goal in life is to try and exercise all the cells evenly, even if that involves moving data around to achieve it. This process does slow the drive down, and it does (ironically) cause additional wear to the flash cells. It's called write amplification and it's a significant problem with SSDs. The actual wear leveling algorithms employed by SSDs and the ways they mitigate write amplification are proprietary trade secrets among SSD manufacturers, so this is just a general descripton of the process.

| improve this answer | |
  • "The SSD moves non-changing files around over the course of time." Or at least they are supposed to, but it depends on the controller of course. If SSDs always moved stale data around (like say installed OS and program files), then we should've never encountered the Samsung 840 Evo slow-down issue. – Karan Apr 17 '15 at 21:16
  • Not necessarily. It does depend on the controller, but we'll never know the details about how the firmware makes its reallocation decisions. If the drive spends most of its time doing reads (as is the case with an OS drive), very little wear-leveling needs to occur. Presumably, the firmware knows the cycle count of every cell, and it's logical to assume that the firmware would prefer to use a "fresh" cell rather than a used, but trimmed one. For a large SSD, it's conceivable that it could be years before a reallocation needs to happen, depending on use of course. – Wes Sayeed Apr 17 '15 at 21:39
  • The 840 EVO problem was caused by a firmware bug. As we discovered, voltage drift over time causes cells to become weak and they need to be refreshed occasionally whether there's data to be written or not. Samsung's problem was that the wear-leveling algorithm wasn't reallocating cells when it needed to -- probably because the voltage drift was happening faster than Samsung predicted it would. Of course, this is a guess, because Samsung isn't getting into the gritty details of the bug, and it only affects that model drive (other TLC-based drives are unaffected). – Wes Sayeed Apr 17 '15 at 21:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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