Re-freezing is also critical, the container should contain no humid air when it goes into the freezer, because the water will condense and freeze as the container cools. A tightly wrapped bag, desiccant and/or purging the container with dry gas would prevent that.

Color changing desiccant is a good idea to monitor it.

There are ways to keep water out of frozen/re-frozen items, of course, but if you mess up you have water everywhere.

I suspect that 2035 years time, hardware from 2010 will work, while that from 2020 will be less reliable.

CRTs from 1994 and 2002 still going strong. LCD tvs from 2012 and 2022 just went kaput for no reason.

Old hardware rocks.

Most likely bad capacitors. The https://en.wikipedia.org/wiki/Capacitor_plague may have passed, but electrolytic capacitors are still the major life-limiting component in electronics.

They still degrade with time, but in a very predictable way.

That makes it possible to build a version of your design with all capacitors '50 year aged' and check it still works.

Sadly no engineering firm I know does this, despite it being very cheap and easy to do.

https://www.badcaps.net/forum/troubleshooting-hardware-devic...

For logic and DRAM the biggest factors are how far they're being pushed with voltage and heat, which is a thing that trends back and forth over the years. So I could see that go either way.

The only MLC I use today are Samsungs best industrial drives and they work sort of... but no promises. And SanDisc SD cards that if you buy the cheapest ones last a surprising amount of time. 32GB lasted 11-12 years for me. Now I mostly install 500GB-1TB ones (recently = only been running for 2-3 years) after installing some 200-400GB ones that work still after 7 years.

As a counter anecdote, I have a lot of SSDs from the late 2010s that are still going strong, but I lost some early SSD drives to mysterious and unexpected failures (not near the wear-out level).

So literally put your data in cold storage.

I much rather have 64GB of SLC at 100K WpB than 4TB of MLC at less than 10K WpB.

The spread functions that move bits around to even the writes or caches will also fail.

The best compromise is of course to use both kinds for different purposes: SLC for small main OS (that will inevitably have logs and other writes) and MLC for slowly changing large data like a user database or files.

The problem is now you cannot choose because the factories/machines that make SLC are all gone.

You can still get pure SLC flash in smaller sizes, or use TLC/QLC in SLC mode.

I much rather have 64GB of SLC at 100K WpB than 4TB of MLC at less than 10K WpB.

It's more like 1TB of SLC vs. 3TB of TLC or 4TB of QLC. All three take the same die area, but the SLC will last a few orders of magnitude longer.

It turns out that a few extra bytes can turn a 1 year endurance into a 100 year endurance.

SSDs know which blocks have been written to a lot, have been giving a lot of read errors before etc., and often even have heterogeneous storages (such as a bit of SLC for burst writing next to a bunch of MLC for density).

They can spend ECC bits much more efficiently with that information than a file system ever could, which usually sees the storage as a flat, linear array of blocks.

For any important data you should have your own file hashes, for corruption detection, and you should add some form of redundancy for file repair, either with a specialized tool or simply by duplicating the file on separate storage media.

A database with file hashes can also serve other purposes than corruption detection, e.g. it can be used to find duplicate data without physically accessing the archival storage media.

There's a lot of potential for errors when the storage controller processes and turns the data into analog magic to transmit it.

In practice, this is a solved problem, but only until someone makes a mistake, then there will be a lot of trouble debugging it between the manufacturer certainly denying their mistake and people getting caught up on the usual suspects.

Doing all the ECC stuff right on the CPU gives you all the benefits against bitrot and resilience against all errors in transmission for free.

And if all things go just right we might even be getting better instruction support for ECC stuff. That'd be a nice bonus

That's a physical layer, and as such should obviously have end-to-end ECC appropriate to the task. But the error distribution shape is probably very different from that of bytes in NAND data at rest, which is different from that of DRAM and PCI again.

For the same reason, IP does not do error correction, but rather relies on lower layers to present error-free datagram semantics to it: Ethernet, Wi-Fi, and (managed-spectrum) 5G all have dramatically different properties that higher layers have no business worrying about. And sticking with that example, once it becomes TCP's job to handle packet loss due to transmission errors (instead of just congestion), things go south pretty quickly.

Outside of wireless links (where FEC of some degree is necessary regardless) this is mostly because TCP’s checksum is so weak. QUIC for example handles this much better, since the packet’s authenticated encryption doubles as a robust error detecting code. And unlike TLS over TCP, the connection is resilient to these failures: a TCP packet that is corrupted but passes the TCP checksum will kill the TLS connection on top of it instead of retransmitting.

This is why newer TCP variants that use different congestion signals can deal with networks that violate that assumption better, such as e.g. Starlink: https://blog.apnic.net/2024/05/17/a-transport-protocols-view...

Other than that, I didn't realize that TLS has no way of just retransmitting broken data without breaking the entire connection (and a potentially expensive request or response with it)! Makes sense at that layer, but I never thought about it in detail. Good to know, thank you.

There are potentially ways a filesystem could use heirarchical ECC to just store a small percentage extra, but it would be far from theoretically optimal and rely on the fact just a few logical blocks of the drive become unreadable, and those logical blocks aren't correlated in write time (which I imagine isn't true for most ssd firmware).

It would not be hard for a COW file system to use them, but it can easily get out of control paranoia wise. Ideally you’d need them for every bit of data, including metadata.

That said, I did have a computer that randomly bit flipped when writing to storage sometimes (eventually traced it to an iffy power supply), and PAR (a type of reed solomon coding forward error correction library) worked great for getting a working backup off the machine. Every other thing I tried would end up with at least a couple bit flip errors per GB, which make it impossible.

BTW, byte size during the history varied from 4 to 24 bit! Even now, based on interpretation, you can say 16 bit bytes do exist.

Char type can be 16 bit on some DSP systems.

I was curious, so I checked. Before this comment, I only knew about 7 bit bytes.

"Octet" has the advantage that it is not ambiguous. In old computer documentation, from the fifties to the late sixties, a "byte" could have meant any size between 6 bits and 16 bits, the same like "word", which could have meant anything between 8 bits and 64 bits, including values like 12 bits, 18 bits, 36 bits, 60 bits, or even 43 bits.

Traditionally, computer memory is divided in pages, which are divided in lines, which are divided in words, which are divided in bytes. However the sizes of any of those "units" has varied in very wide ranges in the early computers.

IBM System/360 has chosen the 8-bit byte, and the dominance of IBM has then forced this now ubiquitous meaning of "byte", but there were many computers before System/360 and many coexisting for some years with the IBM 360 and later mainframes, where byte meant something else.

FTR, ECMA-130 (the CD "yellow book" equivalent standard) is littered with the term "8-bit bytes", so it was certainly a thing then. Precision when simultaneously discussing eight-to-fourteen modulation, and the 17 encoding "bits" that hit the media for each octet as noted in a sibling comment.

Now, woktets on the other hand...

ZFS has "copies=2", but iirc there are no filesystems with support for single disk erasure codes, which is a huge shame because these can be several orders of magnitude more robust compared to a simple copy for the same space.

For instance, on Linux there is par2cmdline. For all my backups, I create pax archives, which are then compressed, then encrypted, then expanded with par2create, then aggregated again in a single pax file (the legacy tar file formats are not good for faithfully storing all metadata of modern file systems and each kind of tar program may have proprietary non-portable extensions to handle this, therefore I use only the pax file format).

Besides that, important data should be replicated and stored on 2 or even 3 SSDs/HDDs/tapes, which should preferably be stored themselves in different locations.

The issue being discussed is random blocks, yes?

If your entire drive is bricked, that is an entirely different issue.

If it decides, by some arbitrary measurement, as defined by some logic within its black box firmware, that it should stop returning all blocks, then it will do so, and you have almost no recourse.

This is a very common failure mode of SSDs. As a consequence of some failed blocks (likely exceeding a number of failed blocks, or perhaps the controller’s own storage failed), drives will commonly brick themselves.

Perhaps you haven’t seen it happen, or your SSD doesn’t do this, or perhaps certain models or firmwares don’t, but some certainly do, both from my own experience, and countless accounts I’ve read elsewhere, so this is more common than you might realise.

You can sidestep this by bypassing the controller on a test bench though. Pinning wires to the chips. At that point it’s no longer an SSD.

At least in the ‘bricked’ case it’s a trivial RMA - corrupt blocks tend to be a harder fight. And since ‘bricked’ is such a trivial RMA, manufacturers have more of an incentive to fix it or go broke, or avoid it in the first place.

This is why backups are important now; and always have been.

Some would (enterprise maybe), but even then they’d want deterministic data deletes too, which doesn’t sound like are happening.

Not some abstract notion.

Still a big problem if backup is to the "..same technology..."

That work can't be done because there is no free blocks. However, no space can be freed up because every spare writable block is bad or is in some other unusable state.

The drive is therefore dead - it will enumerate, but neither read nor write anything.

It's ridiculous (IMO) that SSD firmware is doing so much transparent work just to keep the illusion that the drive is actually spinning metal with similar sector write performance.

For instance, if you have a 40 GB backup archive with 10% redundancy, 4 GB of data, i.e. one million 4 kB data blocks can be unreadable and you can still repair the archive and recover the complete content.

It is true that the entire SSD or HDD can become bricked. The solution for this, as I have already written in my previous comment, is to duplicate any SSD/HDD used for archival purposes, which I always do.

Personally, I keep backups of critical data on a platter disk NAS, so I'm not concerned about losing critical data off of an SSD. However, I did recently have to reinstall Windows on a computer because of a randomly corrupted system file. Which is something this feature would have prevented.

I had no knowledge of pax, or that par was an open standard, and I care about what they help with. Going to switch over to using both in my backups.

Among other utilities, it installs the "bsdtar" program, which you can use in your scripts like this:

  bsdtar --create --verbose --format=pax --file="${DIRECTORY}".pax "${DIRECTORY}" || exit

  bsdtar --extract --preserve-permissions --verbose --file="${DIRECTORY}".pax

"par2create" creates multiple files from the (normally compressed and encrypted) archive file, for storing the added redundancy. I make a directory where I move those files, then I use a second time bsdtar (obviously without any compression or encryption) to aggregate those files in a single archive with redundancy.

The libarchive package can also be taken directly from:

https://github.com/libarchive/libarchive

"libarchive" handles correctly all kinds of file metadata, e.g. extended file attributes and high-resolution file timestamps, which not all archiving utilities do. Many Linux utilities, with the default command-line options or when they have not been compiled from their source with adequate compilation options, which happens in some Linux distributions, may silently lose some of the file metadata, when copying, moving or archiving.

Those QLC NAND chips? Pretty much all of them have an "SLC mode", which treats each cell as 1 bit, and increases both write speeds and reliability massively. But who wants to have 4 times less capacity for the same price?

Plenty of people would be willing to pay for SLC mode. There is an unofficial firmware hack that enables it: https://news.ycombinator.com/item?id=40405578

1TB QLC SSDs are <$100 now. If the industry was sane, we would have 1TB SLC SSDs for less than $400, or 256GB ones for <$100, and in fact SLC requires less ECC and can function with simpler (cheaper, less buggy, faster) firmware and controllers.

But why won't the manufacturers let you choose? The real answer is clearly planned obsolescence.

I have an old SLC USB drive which is only 512MB, but it's nearly 20 years old and some of the very first files I wrote to it are still intact (I last checked several months ago, and don't expect it's changed since then.) It has probably had a few hundred full-drive-writes over the years --- well worn-out by modern QLC/TLC standards, but barely-broken-in for SLC.

Very few people have the technical understanding required to make such a choice. And of those, fewer people still would actually pick SLC over QLC.

At the same time: a lot of people would, if facing a choice between a $50 1TB SSD and a $40 1TB SSD, pick the latter. So there's a big incentive to optimize on cost, and not a lot of incentive to optimize on anything else.

This "SLC only" mode exists in the firmware for the sake of a few very specific customers with very specific needs - the few B2B customers that are actually willing to pay that fee. And they don't get the $50 1TB SSD with a settings bit flipped - they pay a lot more, and with that, they get better QC, a better grade of NAND flash chips, extended thermal envelopes, performance guarantees, etc.

Most drives out there just use this "SLC" mode for caches, "hot spot" data and internal needs.

There was a period of time when you could still by consumer SLC drives and pay a premium for them. I still have one.

Anyone assuming the manufacturers are missing out on a golden market opportunity of hidden SLC drive demand is missing the fact that they already offered these. They know how well (or rather, how poorly) they sell.

Even if consumers had full technical knowledge to make decisions, most would pick the TLC and QLC anyway. Some of these comments are talking about optimizing 20 year old drives for being used again two decades later, but ignoring the fact that a 20 year old drive is nearly useless and could be replaced by a superior option for $20 on eBay.

The only thing that would change, practically speaking, is that people looking for really old files on drives they haven’t powered up for 20 years wouldn’t be surprised that the were missing.

The rest of us will do just fine with our TLC drives and actual backups to backup services or backup mediums.

I’ll happily upgrade my SSD every 4-5 years and enjoy the extra capacity over SLC while still coming out money ahead and not losing data.

Though what make me wonder is that some reviews of modern SSDs certainly mention that that pSCL is somewhat less than 25% of capacity, like 400GB pSLC cache for 2TB SSD:

https://www.tomshardware.com/pc-components/ssds/crucial-p310...

So you get more like 20% of SLC capacity at least on some SSDs

Industry is sane in both the common and capitalist sense.

The year 2025 and people still buy 256Tb USB thumbdrives for $30, because nobody cares except for the price.

It's not about age of drive. It's how much time it spent without power.

If the original drive has sufficient reliability, then yes I do want that.

And the majority of consumers do, too.

Chasing absolute extreme highest powered off durability is not a priority for 99% of people when the drives work properly for typical use cases. I have 5 year old SSDs where the wear data is still in the single digit percentages despite what I consider moderately heavy use.

> I have an old SLC USB drive which is only 512MB, but it's nearly 20 years old and some of the very first files I wrote to it are still intact (I last checked several months ago, and don't expect it's changed since then.) It has probably had a few hundred full-drive-writes over the years --- well worn-out by modern QLC/TLC standards, but barely-broken-in for SLC.

Barely broken in, but also only 512MB, very slow, and virtually useless by modern standards. The only positive is that the files are still intact on that old drive you dusted off.

This is why the market doesn’t care and why manufacturers are shipping TLC and QLC: They aren’t doing a planned obsolescence conspiracy. They know that 20 years from now or even 10 years from now that drive is going to be so outdated that you can get a faster, bigger new one for pocket change.

WTF? That is the only reason to have non-volatile storage.

faster, bigger

I don't care one bit if it doesn't hold data long enough to not worry about while off. Otherwise it's just like RAM.

No, it's not. The real answer is that customers (Even B2B) are extremely price sensitive.

Look, I know the prevailing view is that lower quality is some evil corporate plan to get you to purchase replacements on a more frequent basis, but the real truth is that consumers are price sensitive, short sighted, and often purchasing without full knowledge. There's a race to the bottom on price, which means quality suffers. You put your typical customer in front of two blenders at the appliance store, one is $20 and the other is $50, most customers will pick the $20 one, even when armed with the knowledge that the $50 version will last longer.

When it comes to QLC vs SLC, buyers don't care. They just want the maximum storage for the smallest price.

Having built computers casually for some time, I never recall being told by the marketing department or retailer that one kind of SSD was more reliable than another. The only thing that is ever advertised blatantly is speed and capacity. I saw the kind of SSD sometimes, but it was never explained what that meant to a consumer (the same way SMR hard drives were never advertised as having slow reads)

If I saw "this kind of SSD is reliable for 10 years and the other one is reliable for 2" then I may have made a decision based on that.

Yes.

QLC SSDs are reliable enough for my day-to-day use, but even QLC storage is quite expensive and I wouldn't want to pay 4x (or realistically, way more than 4x) to get 2TB SLC M.2 drives instead of 2TB QLC M.2 drives.