SoylentNews is people
SoylentNews
https://www.xda-developers.com/your-unpowered-ssd-is-slowly-losing-your-data/
SSDs have all but replaced hard drives when it comes to primary storage. They're orders of magnitude faster, more convenient, and consume less power than mechanical hard drives. That said, if you're also using SSDs for cold storage, expecting the drives lying in your drawer to work perfectly after years, you might want to rethink your strategy. Your reliable SSD could suffer from corrupted or lost data if left unpowered for extended periods. This is why many users don't consider SSDs a reliable long-term storage medium, and prefer using hard drives, magnetic tape, or M-Disc instead.
Unlike hard drives that magnetize spinning discs to store data, SSDs modify the electrical charge in NAND flash cells to represent 0 and 1. NAND flash retains data in underlying transistors even when power is removed, similar to other forms of non-volatile memory. However, the duration for which your SSD can retain data without power is the key here. Even the cheapest SSDs, say those with QLC NAND, can safely store data for about a year of being completely unpowered. More expensive TLC NAND can retain data for up to 3 years, while MLC and SLC NAND are good for 5 years and 10 years of unpowered storage, respectively.
The problem is that most consumer SSDs use only TLC or QLC NAND, so users who leave their SSDs unpowered for over a year are risking the integrity of their data. The reliability of QLC NAND has improved over the years, so you should probably consider 2–3 years of unpowered usage as the guardrails. Without power, the voltage stored in the NAND cells can be lost, either resulting in missing data or completely useless drives.
This data retention deficiency of consumer SSDs makes them an unreliable medium for long-term data storage, especially for creative professionals and researchers. HDDs can suffer from bit rot, too, due to wear and tear, but they're still more resistant to power loss. If you haven't checked your archives in a while, I'd recommend doing so at the earliest.
(Score: 4, Interesting) by mrpg on Sunday November 30, @04:51PM (11 children)
What is the correct way to stop data degradation (the decay of electromagnetic charge in a computer's storage)? Rewrite all the data in a SSD (and also HDD)? I already have multiple backups, I ask about data degradation.
(Score: 1, Informative) by Anonymous Coward on Sunday November 30, @05:30PM
The other little surprise is there are a finite number of rewrites on a cell.
Doing too many writes will just reduce cell's usable lifetime.
(Score: 3, Interesting) by aafcac on Sunday November 30, @09:01PM (8 children)
That should be necessary, from what I understand, the SSDs will transparently move data around from time to time to avoid that issue, the stated capacity will oftentimes not include some extra space to deal with issues that arise from the data shuffling. The better strategy is to have good backup strategies and data integrity software like checksum or par2 to identify when rarely used, but important, files are starting to go bad. Par2 is great because it also allows you to repair some of the damage that might occur. I like ZFS, but from what I understand, it doesn't necessarily play well with flash memory.
(Score: 5, Interesting) by JoeMerchant on Sunday November 30, @10:02PM (7 children)
I have wanted to like ZFS for a very long time now.
Finally built a system with ZFS on the boot volume, ran it for a year and it imploded while half full - total meltdown of the filesystem, I could probably have salvaged most of the data if it was important but this was a "daily driver" system that didn't really have anything unique on it, all backed up elsewhere, so I just reformatted in disgust to ext4 and that system has been running strong for about a year since then now.
ZFS has been "not quite ready for production use" on Ubuntu for what seems like a decade now.
🌻🌻🌻 [google.com]
(Score: 3, Interesting) by aafcac on Sunday November 30, @11:18PM (6 children)
I liked ZFS on FreeBSD, but I'm not ready to really trust it on Linux even though it's probably fine. I was mostly using it with redundancy and without a lot of the more complicated things, so it was fine, but I'm likely to give it a go in the near future as I've got an external HDD case and I'm likely to primarily use it with video files from ripped DVDs, so replacing them wouldn't be any real effort if for some reason something does happen.
(Score: 3, Interesting) by JoeMerchant on Monday December 01, @01:51AM (3 children)
I get the impression it may work better for data volumes - somehow the load of being the root of the whole system boot volume just messed with ZFS a little too hard.
🌻🌻🌻 [google.com]
(Score: 4, Informative) by remote_worker on Monday December 01, @04:36AM (2 children)
I haven't tried ZFS on linux, but given that the licenses aren't compatible enough for ZFS to be in a distributed kernel I'd expect a few wrinkles with it. In particular, ZFS eats a lot of VM (as an ARC), and if the kernel isn't properly set up to handle that I would expect things to fall apart.
Where ZFS shines is FreeBSD (where ZFS is integrated into the kernel) and ZFS on root. Upgrades are no-risk:
1) make a zfs snapshot of your pre-upgrade system. Use bectl (bectl create ...) for the root (boot environment), and plain ZFS snapshots of any non-root filesystems that are going to be upgraded. This is fast. Leave the active boot environment alone, that's the one we want to upgrade.
2) perform the upgrade, by whichever method turns your crank
3) try the upgrade out.
4) if the upgrade is good, delete the snapshots from (1) and get on with your day :).
5) if the upgrade is bad, use the bootloader to boot the snapshot from (1), or if you can get to a shell in the upgrade, activate the root snapshot with "bectl activate ..." and reboot, then use plain ZFS to rollback to the snapshots from (1).
6) Once you're back in the pre-upgrade system you can delete the snapshots from (1) or leave them while you try some other upgrade approach.
One other thing that ZFS involves is that you should do a periodic "scrub" of every pool. I do it weekly, via crontab, at a time I'm pretty sure I'm going to be sleeping :). I expect monthly would be OK as well, but weekly is easier to fit into my timetable. The "zpool scrub ..." starts a background process that cleans up and checks a ZFS pool. My largest pool is a bit over 6Tb of spinning rust (mirrored drives), about 40% used, and scrub runs in 3.5 hours. The pool is perfectly usable while the scrub is running, but possibly a bit slower. A "zpool status ..." gives you the status of the scrub and lets you know if your drive is starting to show errors. If I paid more attention to the status I could probably have avoided the failures I talk about below :).
I have my ZFS root on a small drive or SSD, but all my user data on a separate mirrored ZFS pool, and do daily backups using borgbackup of both the root pool and the user data pool to another machine. I tend to prefer spinning rust for the user data, both becasue it's still cheaper, and because it doesn't have the decay issues of SSDs, but SSDs are nicer for booting.
I've had user data drives fail and root drives fail. I've never had ZFS fail. The failures in the mirrored pool were stressful because of the time it took to get replacement drives, but otherwise painless (not a single file lost, and the only downtime was the physical drive swap). I didn't lose any files in the root drive failures either, but things got slightly more complicated because a simple retsore from borgbackup to a new drive doesn't make the restored data bootable. Making things bootable again depends on how you like to set things up so I won't waste your time with details, but it isn't difficult.
Really, if you can handle all the variations in the different Linux distributions, FreeBSD is easy. There may be more new stuff going from Linux to FreeBSD than from one Linux distro to another, but none of it is hard stuff, just different stuff :).
(Score: 2) by JoeMerchant on Wednesday December 03, @12:55AM (1 child)
So, perhaps I didn't "scrub" my filesystem like I should have. I was doing an eval for a field deployment (thousands of machines in the field, nobody maintaining them) so, either I would have to setup scripts / cron jobs / whatever to do that for me, but it seems a bit absurd in this day and age that a filesystem that needs that kind of maintenance doesn't have something developed and ready to go in the default configurations.
🌻🌻🌻 [google.com]
(Score: 1) by remote_worker on Monday December 08, @04:00AM
It could be needing a scrub, or it could be the the virtual memory needs got too big as the amount of data grew. A ZFS on linux developer might know, but I don't.
However, you're right about the missing default, it does seem that there should be something for a default scrub setup. I didn't find out about scrub for several months after I started using ZFS. I didn't get a crash, or even a performance slowdown, but I might have if I'd gone longer.
A big field deployment is not the place you'd want to try out a different OS as well as a different FS :). I was living with a dual-boot setup on my desktop until I felt comfortable, so one machine and no travel or remote access issues.
(Score: 5, Informative) by Unixnut on Monday December 01, @12:15PM (1 child)
Seconded on not trusting ZFS on Linux. I've used ZFS for years on FreeBSD and it has been a godsend for data integrity. I've not lost a byte of data in the last decade despite multiple power/system/drive array failures thanks to ZFS.
Having had such success I tried bringing ZFS to Linux servers a few years ago, and it really was not a good idea. For one thing you get no support for the configuration (from example RedHat, if you are trying this in an enterprise Linux environment), secondly it feels clunkly, like ZFS is not so much integrated into Linux as much as "bolted on" in places. This includes bypassing and hacking around the Linux VFS Layer (as ZFS is not just a "filesystem" but a complete vertically integrated storage subsystem).
As a result at best I found ZFS on Linux to be clunky and fragile, and at worst it breaks in some horrific way that makes it impossible to recover without data loss. Perhaps this is due to the licencing incompatibilities preventing proper kernel integration, or it is just something about the way the Linux kernel is designed that prevents it to be reliably integrated.
Either way, for serious/production work on Linux you are better off with MDADM/LVM and ext4. If you want ZFS and all the goodies it brings then best use an OS that has it properly integrated and supported in the kernel.
(Score: 2) by aafcac on Tuesday December 02, @04:11PM
Having messed around with former ZFS based disks that I had decommissioned, one of the things that I came to realize is just how fragile they can be if they get damaged. It hasn't been an issue for me, as I've been generally using the disks as part of a zmirror or raidz configuration and haven't lost data due to that, but there's weird stuff that can happen to the label that makes it a right pain to work with if you don't already know how to do it and are prepared.
That's really the biggest worry I have as it can be relatively hard to push systems like this hard enough to really establish that they're reliable without putting data on there that could be annoying to have to restore. I'm curious about Btrfs which does play a bit better with Linux.
Side rant: But really, the whole thing is the result of some rather poor decisions made decades ago without any real consideration of the consequences. In practice, the difference between GPL and something more permissive like the BSD or MIT license is pretty much non-existent if you don't have attorneys, and even if you do have attorneys, the difference is still rather small. Sure, the GPL theoretically prevents people from taking the code and distributing binaries without providing the source in the same place, but it also means that code can't be easily contributed the way that it would be with a more open license.
I do like modern Linux in a lot of ways, but there's an awful lot of boneheaded decisions being made lately like things involving having so many different ways that programs can be packaged/managed, SystemD everything, Wayland and things that seem to be more or less the same sort of nonsense that MS used to engage in because everybody is special and we need to change things because we need to change them. Never mind that it's absolutely absurd to have to reload system services to issue a mount -a after modifying the fstab or that 17+ years for the nonsense that is Wayland is way too much time when all the necessary bits of Linux to be a functional OS took a fraction of that time.
(Score: 2, Interesting) by Anonymous Coward on Monday December 01, @01:23AM
According to a 10 year old article, if you're going to store SSDs, write at high temperature, store at low temperature, rewrite once in a while before the data fades too much:
https://archive.is/1lW1R [archive.is]
Note the link is about SSDs that have past their TBW but the principle should still be the same, just the actual numbers different.
Also that was 10 years ago, stuff might have changed since...