[HN Gopher] Unpowered SSD endurance investigation finds data los...
       ___________________________________________________________________
        
       Unpowered SSD endurance investigation finds data loss and
       performance issues
        
       Author : progval
       Score  : 55 points
       Date   : 2025-04-19 19:59 UTC (3 hours ago)
        
 (HTM) web link (www.tomshardware.com)
 (TXT) w3m dump (www.tomshardware.com)
        
       | csdvrx wrote:
       | For long term storage, prefer hard drives (careful about CMR vs
       | SMR)
       | 
       | If you have specific random IO high performance needs, you can
       | either
       | 
       | - get a SLC drive like https://news.solidigm.com/en-
       | WW/230095-introducing-the-solid...
       | 
       | - make one yourself by hacking the firmware:
       | https://news.ycombinator.com/item?id=40405578
       | 
       | Be careful when you use something "exotic", and do not trust
       | drives that are too recent to be fully tested: I learned my
       | lesson for M2 2230 drives
       | https://www.reddit.com/r/zfs/comments/17pztue/warning_you_ma...
       | which seems validated by the large numbers of similar experiences
       | like https://github.com/openzfs/zfs/discussions/14793
        
         | dragontamer wrote:
         | If you care about long term storage, make a NAS and run ZFS
         | scrub (or equivalent) every 6 months. That will check for
         | errors and fix them as they come up.
         | 
         | All error correction has a limit. If too many errors build up,
         | it becomes unrecoverable errors. But as long as you reread and
         | fix them within the error correction region, it's fine.
        
           | csdvrx wrote:
           | > run ZFS scrub (or equivalent) every 6 months
           | 
           | zfs in mirror mode offers redundancy at the block level but
           | scrub requires plugging the device
           | 
           | > All error correction has a limit. If too many errors build
           | up, it becomes unrecoverable errors
           | 
           | There are software solutions. You can specify the redundancy
           | you want.
           | 
           | For long term storage, if using a single media that you can't
           | plug and scrub, I recommend par2
           | (https://en.wikipedia.org/wiki/Parchive?useskin=vector) over
           | NTFS: there are many NTFS file recovery tools, and it
           | shouldn't be too hard to roll your own solution to use the
           | redundancy when a given sector can't be read
        
           | WalterGR wrote:
           | What hardware, though? I want to build a NAS / attached
           | storage array but after accidentally purchasing an SMR
           | drive[0] I'm a little hesitant to even confront the project.
           | 
           | A few tens of TBs. Local, not cloud.
           | 
           | [0] Maybe 7 years ago. I don't know if anything has changed
           | since, e.g. honest, up-front labeling.
           | 
           | [0*] For those unfamiliar, SMR is Shingled Magnetic
           | Recording.
           | https://en.m.wikipedia.org/wiki/Shingled_magnetic_recording
        
             | 3np wrote:
             | [delayed]
        
           | ErneX wrote:
           | I use TrueNAS and it does a weekly scrub IIRC.
        
         | AshamedCaptain wrote:
         | > (careful about CMR vs SMR)
         | 
         | Given the context of long term storage... why?
        
           | 0cf8612b2e1e wrote:
           | After I was bamboozled with a SMR drive, always great to just
           | make the callout to those who might be unaware. What a piece
           | of garbage to let vendors upsell higher numbers.
           | 
           | (Yes, I know some applications can be agnostic to SMR, but it
           | should never be used in a general purpose drive).
        
           | whoopdedo wrote:
           | Untested hypothesis, but I would expect the wider spacing
           | between tracks in CMR makes it more resilient against random
           | bit flips. I'm not aware of any experiments to prove this and
           | it may be worth doing. If the HD manufacture can convince us
           | that SMR is just as reliable for archival storage it would
           | help them sell those drives since right now lots of people
           | are avoiding SMR due to poor performance and the infamy of
           | the bait-and-switch that happened a few years back.
        
         | sitkack wrote:
         | Tape is extremely cheap now. I booted up a couple laptops that
         | have been sitting unpowered for over 7 years and the sata SSD
         | in one of them has missing sectors. It had zero issues when
         | shutdown.
        
           | seszett wrote:
           | Is tape actually cheap? Tape drives seem quite expensive to
           | me, unless I don't have the right references.
        
             | wtallis wrote:
             | Tapes are cheap, tape drives are expensive. Using tape for
             | backups only starts making economic sense when you have
             | enough data to fill dozens or hundreds of tapes. For
             | smaller data sets, hard drives are cheaper.
        
         | vlovich123 wrote:
         | > - make one yourself by hacking the firmware:
         | https://news.ycombinator.com/item?id=40405578 Be careful when
         | you use something "exotic", and do not trust drives that are
         | too recent to be fully tested
         | 
         | Do you realize the irony of cautioning about buying off the
         | shelf hardware but recommending hacking firmware yourself?
        
       | rkagerer wrote:
       | I would never buy a no-name SSD. Did it once long ago and got
       | bit, wrote a program to sequentially write a pseudorandom
       | sequence across the whole volume then read back and verify, and
       | proved all 8 Pacer SSD's I had suffered corruption.
        
         | WalterGR wrote:
         | That's also fairly common for cheap 'thumb drives', as I
         | understand it. I've been bitten by that before.
         | 
         | (Edit: Allegedly if you use low-numbered storage blocks you'll
         | be okay, but the advertised capacity (both packaging and what
         | it reports to OS) is a straight-up lie.)
        
       | gnabgib wrote:
       | Discussion on the original source: (20 points, 3 days ago, 5
       | comments) https://news.ycombinator.com/item?id=43702193
       | 
       | Related: _SSD as Long Term Storage Testing_ (132 points, 2023,
       | 101 comments) https://news.ycombinator.com/item?id=35382252
        
       | bityard wrote:
       | I didn't think it was controversial that SSDs are terrible at
       | long term storage?
        
         | wmf wrote:
         | I wouldn't say it's controversial but I suspect most people
         | don't know about it. There's been a lot of discussion about SSD
         | write endurance but almost none about retention.
        
       | jeffbee wrote:
       | Endurance is proportional to programming temperature. In the
       | video, when all four SSDs are installed at once, the composite
       | device temperature ranges over 12o. This should be expected to
       | influence the outcomes.
        
       | ein0p wrote:
       | 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.
        
       ___________________________________________________________________
       (page generated 2025-04-19 23:00 UTC)