← Back to context

Comment by ein0p

7 months ago

This is a known issue. You have to power up your SSDs (and flash cards, which are based on even more flimsy/cost optimized version of the same tech) every now and then for them to keep data. SSDs are not suitable for long term cold storage or archiving. Corollary: don't lose that recovery passphrase you've printed out for your hardware crypto key, the flash memory in it is also not eternal.

19 comments

ein0p

Reply
jsheard  7 months ago

A not-so-fun fact is that this even applies to modern read-only media, most notably Nintendo game carts. Back in the day they used mask ROMs which ought to last more or less forever, but with the DS they started using cheaper NOR or NAND flash for larger games, and then for all games with the 3DS onwards. Those carts will bit-rot eventually if left unpowered for a long time.

  • vel0city  7 months ago

    I've noticed a number of GBA carts I've picked up used (and probably not played in a long while) fail to load on the first read. Sometimes no logo, sometimes corrupted logo. Turning it off and on a couple of times solved the issue, and once it boots OK it'll boot OK pretty much every time after. Probably until it sits on the shelf for a long while.

    • jsheard  7 months ago

      I think GBA games were all MaskROMs, so with those it's probably just due to the contacts oxidizing or something.

computator  7 months ago

> You have to power up your SSDs every now and then for them to keep data.

What is the protocol you should use with SSDs that you’re storing? Should you:

- power up the SSD for an instant (or for some minutes?) without needing to read anything?

- or power up the cells where your data resides by reading the files you had created on the SSD?

- or rewrite the cells by reading your files, deleting them, and writing them back to the SSD?

  • gblargg  7 months ago

    I'd at least just read all the used blocks on the drive. partclone is the most efficient that comes to mind, because it just copies used sectors. Just redirect to /dev/null.

        partclone.filesystem --source /dev/sdx --clone --output /dev/null

    • justinclift  7 months ago

      If you just need to read all of the sectors, then couldn't you just dd or cat the source drive instead?

  • mikequinlan  7 months ago

    >What is the protocol you should use with SSDs that you’re storing?

    The correct protocol is to copy the data to a more durable medium and store that.

    • hedora  7 months ago

      Or leave the drive on all the time in an enclosure that keeps the nand cool (near room temperature).

      Any decent SSD will background rewrite itself over time at an appropriate rate. Detecting that it needs to do so after 2 years in storage seems trickier to get right (no realtime clock) and trickier to test.

      I’d be curious to know how quickly the drives in the article “heal” themselves if left plugged in. There’s nothing wrong with the hardware, even if they did lose a few sectors.

      If you really want to create a correct protocol, you can accelerate nand aging by sticking them in an oven at an appropriate temperature. (Aging speedup vs temperature curves are available for most nand devices.)

  • rapjr9  7 months ago

    Maybe someone should design and sell a "drivekeeper" that you can plug all your backup SSD's into and it will power them up on a time table and do whatever is necessary to cause them to maintain integrity. Could be something like a Raspberry Pi with a many-port USB hub, or with a PCB with a bunch of connectors the raw drives can plug into. Could maybe even give a warning if a drive is degrading. Possibly it could be a small device with a simple MCU and a battery that you snap directly onto the SSD's connector?

zamadatix  7 months ago

The article states as much but to sum it all up as just that is leaving most of the good stuff out.

Perhaps the most interesting part of the experiment series has been just how much longer these cheap drives with tons of writes have been lasting compared to the testing requirements (especially with so much past write endurance on the one just now starting to exhibit trouble). Part of the impetus for the series seemed to be lots of claims on how quickly to expect massive problems without any actual experimental tests of consumer drives to actually back it up. Of course n=4 with 1 model of 1 brand drives but it's taken ~20x longer than some common assumptions to start seeing problems on a drive at 5x its endurance rating.

RicoElectrico  7 months ago

Please explain to me how is that supposed to work. For all I know the floating gate is, well, isolated and only writes (which SSDs don't like if they're repeated on the same spot) touch it through mechanisms not unlike MOSFET aging i.e. carrier injection. Reading on the other hand depends on the charge in floating gate altering Vt of the transistor below, this action not being able to drain any charge from the floating gate.

  • ein0p  7 months ago

    If you at least read the data from the drive from time to time, the controller will "refresh" the charge by effectively re-writing data that can't be read without errors. Controllers will also tolerate and correct _some_ bit flips on the fly, topping up cells, or re-mapping bad pages. Think of it as ZFS scrub, basically, except you never see most of the errors.

  • wmf  7 months ago

    According to a local expert (ahem), leakage can occur through mechanisms like Fowler-Nordheim tunneling or Poole-Frenkel emission, often facilitated by defects in the oxide layers.

matheusmoreira  7 months ago

> don't lose that recovery passphrase you've printed out for your hardware crypto key, the flash memory in it is also not eternal

Yeah. Paper is the best long term storage medium, known to last for centuries.

https://wiki.archlinux.org/title/Paperkey

It's a good idea to have a backup copy of the encryption keys. Losing signing keys is not a big deal but losing encryption keys can lead to severe data loss.