4 ms·

what is the exact protocol to "recharge" an ssd which was offline for months? do I just plug it in and let the computer on for a few minutes? does it needs to

by testartr 10mo ago

what is the exact protocol to "recharge" an ssd which was offline for months? do I just plug it in and let the computer on for a few minutes? does it needs to stay on for hours? do I need to run a special command or TRIM it?

PunchyHamster 10mo ago
I'd imagine full read of the whole device might trigger any self-preservation, but I'd also imagine it's heavily dependent on manufacturer and firmware
PaulKeeble 10mo ago
We really don't know. One thing I wish some of these sites would do is actually test how long it takes for the drives to decay and also do a retest after they have been left powered for say 10 minutes to an hour, read completely, written to a bit etc and see if they can determine what a likely requirement is. The problem is the test will take years, be out of date by the time its released and new controllers will be out with potentially different needs/algorithms.
- unsnap_biceps 10mo ago
  There was one guy who tested this https://www.tomshardware.com/pc-components/storage/unpowered-ssd-endurance-investigation-finds-severe-data-loss-and-performance-issues-reminds-us-of-the-importance-of-refreshing-backups https://www.tomshardware.com/pc-components/storage/unpowered... The data on this SSD, which hadn't been used or powered up for two years, was 100% good on initial inspection. All the data hashes verified, but it was noted that the verification time took a smidgen longer than two years previously. HD Sentinel tests also showed good, consistent performance for a SATA SSD. Digging deeper, all isn't well, though. Firing up Crystal Disk Info, HTWingNut noted that this SSD had a Hardware ECC Recovered value of over 400. In other words, the disk's error correction had to step in to fix hundreds of data-based parity bits. ... As the worn SSD's data was being verified, there were already signs of performance degradation. The hashing audit eventually revealed that four files were corrupt (hash not matching). Looking at the elapsed time, it was observed that this operation astonishingly took over 4x longer, up from 10 minutes and 3 seconds to 42 minutes and 43 seconds. Further investigations in HD Sentinel showed that three out of 10,000 sectors were bad and performance was 'spiky.' Returning to Crystal Disk Info, things look even worse. HTWingNut notes that the uncorrectable sectors count went from 0 to 12 on this drive, and the hardware ECC recovered value went from 11,745 before to 201,273 after tests on the day.
  - zozbot234 10mo ago
    Note that the SSD that showed corrupted files was the one that had been worn out well beyond the manufacturer's max TBW rating (4× the TBW or so). There was a difference of two-to-three orders of magnitude in the ECC count between the "fresh" and the worn-out SSD; I'd call that very significant. It will be interesting to see if there's any update for late 2025.
antisthenes 10mo ago
I would run something like CHKDSK, or write a script to calculate a hash of every file on disk. No idea if that's enough, but it seems like a reasonable place to start.
nixpulvis 10mo ago
I too wonder about this. I'd love to see someone build a simulated "fast decay" SSD which can show how various firmware actually behaves.
nrhrjrjrjtntbt 10mo ago
Back it up. 1 2 3.
beefnugs 10mo ago
If you are using a backup program like "kopia" there are special commands to recheck all hash blocks. You just can't trust the hardware to know how to do this, need backup software with multiple backup locations, it will know how to recheck integrity
reflexe 10mo ago
I think that reading all of the information from the SSD should “recharge” it in most cases. The SSD controller should detect any bit flips and be able to correct them. However, this is implementation detail in the SSD FW. For Linux UBI devices, this will suffice.
tensility 10mo ago
Read off all live data on the drive. This should cause the nand management firmware to detect degrading cells via ECC and move the data in order to refresh isolated cell voltage levels.

PunchyHamster 10mo ago

I'd imagine full read of the whole device might trigger any self-preservation, but I'd also imagine it's heavily dependent on manufacturer and firmware

PaulKeeble 10mo ago

We really don't know. One thing I wish some of these sites would do is actually test how long it takes for the drives to decay and also do a retest after they have been left powered for say 10 minutes to an hour, read completely, written to a bit etc and see if they can determine what a likely requirement is. The problem is the test will take years, be out of date by the time its released and new controllers will be out with potentially different needs/algorithms.

unsnap_biceps 10mo ago
There was one guy who tested this https://www.tomshardware.com/pc-components/storage/unpowered-ssd-endurance-investigation-finds-severe-data-loss-and-performance-issues-reminds-us-of-the-importance-of-refreshing-backups https://www.tomshardware.com/pc-components/storage/unpowered... The data on this SSD, which hadn't been used or powered up for two years, was 100% good on initial inspection. All the data hashes verified, but it was noted that the verification time took a smidgen longer than two years previously. HD Sentinel tests also showed good, consistent performance for a SATA SSD. Digging deeper, all isn't well, though. Firing up Crystal Disk Info, HTWingNut noted that this SSD had a Hardware ECC Recovered value of over 400. In other words, the disk's error correction had to step in to fix hundreds of data-based parity bits. ... As the worn SSD's data was being verified, there were already signs of performance degradation. The hashing audit eventually revealed that four files were corrupt (hash not matching). Looking at the elapsed time, it was observed that this operation astonishingly took over 4x longer, up from 10 minutes and 3 seconds to 42 minutes and 43 seconds. Further investigations in HD Sentinel showed that three out of 10,000 sectors were bad and performance was 'spiky.' Returning to Crystal Disk Info, things look even worse. HTWingNut notes that the uncorrectable sectors count went from 0 to 12 on this drive, and the hardware ECC recovered value went from 11,745 before to 201,273 after tests on the day.
- zozbot234 10mo ago
  Note that the SSD that showed corrupted files was the one that had been worn out well beyond the manufacturer's max TBW rating (4× the TBW or so). There was a difference of two-to-three orders of magnitude in the ECC count between the "fresh" and the worn-out SSD; I'd call that very significant. It will be interesting to see if there's any update for late 2025.

antisthenes 10mo ago

I would run something like CHKDSK, or write a script to calculate a hash of every file on disk. No idea if that's enough, but it seems like a reasonable place to start.

nixpulvis 10mo ago

I too wonder about this. I'd love to see someone build a simulated "fast decay" SSD which can show how various firmware actually behaves.

nrhrjrjrjtntbt 10mo ago

Back it up. 1 2 3.

beefnugs 10mo ago

If you are using a backup program like "kopia" there are special commands to recheck all hash blocks. You just can't trust the hardware to know how to do this, need backup software with multiple backup locations, it will know how to recheck integrity

reflexe 10mo ago

I think that reading all of the information from the SSD should “recharge” it in most cases. The SSD controller should detect any bit flips and be able to correct them. However, this is implementation detail in the SSD FW. For Linux UBI devices, this will suffice.

tensility 10mo ago

Read off all live data on the drive. This should cause the nand management firmware to detect degrading cells via ECC and move the data in order to refresh isolated cell voltage levels.