Solid State Disk drives (SSDs) have a short life and worse: manufacturers nanny users after blocking write access to old drives

SSDs can only tolerate a certain number of writes to each block. And the number is low. I have a 64gb SSD that went into a permanent read-only mode. 64gb is still today a very useful capacity. Thus the usefulness is cut short by hardware design deficiencies.

Contrast that with magnetic hard drives which often live beyond the usefulness of their capacity. That is, people toss out working 80mb mechanical drives now because they’re too small to justify the physical space they occupy, not because of premature failure ending the device’s useful life.

Nannying

When an SSD crosses a line whereby the manufacturer considers it unreliable, it goes into a read-only mode which (I believe) is passworded with a key that is not disclosed to consumers. The read-only mode is reasonable as it protects users from data loss. But the problem is the nannying that denies “owners”¹ ultimate control over their own property.

When I try to dd if=/dev/zero of=/dev/mydrive, dd is lied to and will write zeros all day and report success, but dd’s instructions are merely ignored and have no effect.

The best fix in that scenario would generally be to tell the drive to erase itself using a special ATA command, like this:

 undefined

    
$ hdparm --security-erase $'\0' /dev/sdb
      security_password: ""

      /dev/sdb:
       Issuing SECURITY_ERASE command, password="", user=user
      SG_IO: bad/missing sense data, sb[]:  70 00 01 00 00 00 00 0a 00 00 00 00 00 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      SG_IO: bad/missing sense data, sb[]:  70 00 0b 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Not sure why my null char got converted to a yen symbol, but as you can see the ATA instruction is blocked.

Here is a take from someone who endorses the nannying. The problem is that there is a presumption on how the drive will be used. Give me a special switch like:

 undefined

    
$ hdparm --security-erase $'\0' --I-know-what-I-am-doing-please-let-me-shoot-myself-in-the-foot /dev/sdb

and this is what I would do:

 undefined

    
$ dd if=KNOPPIX_V8.2-2018-05-10-EN.iso of=/dev/foo
$ hdparm --make-read-only /dev/foo

When the drive crosses whatever arbitrary line of reliability, it’s of course perfectly reasonable to do one last write operation to control what content is used in read-only mode.

5 years later when a different live distro is needed, it would of course be reasonable to repeat the process. One write every ~5 years would at least keep the hardware somewhat useful in the long term.

¹ “owners” is in scare quotes because of the sensible viewpoint “if you don’t control it, you don’t own it”. We are not in control as a consequence of nannying.

10 comments

64gb? Your SSD sounds pretty old and is at the end of its fairly short lifespan. Modern SSDs will last much longer than a comparable HDD under average user conditions.
If you're writing TB on a regular schedule, yeah it will probably die sooner because that's not what it's designed for. It's just a different tool for a different job. If longevity and capacity was the only concern we'd all still be using tape.
- Yeah, I think OP expects the same longevity from their ancient 64GB drive as a new 2TB one. Although I agree you should be able to disable the lock and continue using a drive how you want, but I would never recommend doing that.
  
  Yeah, I think OP expects the same longevity from their ancient 64GB drive as a new 2TB one.
  I simply “expect” manufacturers to allow product owners to have control over their own property. It’s a political problem not a technical one. Whatever the limitations of the hardware are, it’s an injustice with the supplier denies the paying customer control and artificially forces a storage device into a needlessly irreversible read-only state.
- 64gb? Your SSD sounds pretty old and is at the end of its fairly short lifespan.
  Indeed.
  Modern SSDs will last much longer than a comparable HDD under average user conditions.
  I have seen countless mechanical HDDs long outlast the usefulness of their capacity. This is not the case with SSDs. SSDs are fragile. They also need to be powered on periodically just to prevent data loss. Note cases where police put SSDs into an evidence room where they sat until the court needed the evidence, at which point data loss destroyed their forensic usefulness -- which would not have been a problem with magnetic drives.
  If you’re writing TB on a regular schedule, yeah it will probably die sooner because that’s not what it’s designed for. It’s just a different tool for a different job. If longevity and capacity was the only concern we’d all still be using tape.
  Really a red herring here. It does not matter how the drive reached EOL. The useful life is being cut short (shorter than it could be) by an act of policy.

You're assuming it's gone read only because it's predicting a failure or an internal counter got too low, but SD cards aren't very smart. There's a good chance it actually did fail when performing a write. You can't override hardware failure with a command line switch.
Somehow overriding the lockout would just lead to a Knoppix image that has corrupt data silently scattered through it as bits of it fail to write. This is the sort of thing that you spend days troubleshooting hardware trying to work out why something's crashing only to eventually figure out it's because a program has 4kb of german midget porn in the middle of its executable. Just spend the $10 on an SD card that isn't broken.
Nobody wants a storage device that will silently corrupt data instead of failing safely as soon as it's known to be faulty. Do you remove nanny fuses from your electronics so that they'll keep running until flames actually shoot out?
- There’s a good chance it actually did fail when performing a write.
  And? Failed writes happen all the time, even on new drives. The drive keeps track of bad blocks in a list and relocates them. There are bad blocks before a device even leaves the factory. This is not justification for scrapping the drive as the design accommodates.
  The list of bad blocks can over-run the storage space of the metadata itself, but that also fails to justify scrapping a drive when a clever filesystem or middleware can implement redundancy.
  You can’t override hardware failure with a command line switch.
  Have a look at the par2 command, for example. Tech has existed for decades that overcomes corruption.
  Would you ban optical media considering a scratch can cause data loss? It would be a similar case of nannying considering advanced users can fill the rest of the media with redundant parity data.
  Somehow overriding the lockout would just lead to a Knoppix image that has corrupt data silently scattered through it as bits of it fail to write.
  Then you’re doing it wrong. I used dd in the example as a simplification, but obviously the diligent approach is to use the syslinux command and use rsync to copy the files to enable the data to be written to known good areas of the media rather than trying to force a linear bit-by-bit copy.
  This is the sort of thing that you spend days troubleshooting hardware trying to work out why something’s crashing
  If you write a final live CD to a known dodgy drive after being warned and it gives you problems, why would you spend days troubleshooting? The incompetence of forgetting the history of drive condition and how you installed the OS is your problem and it would be your choice to take that path. If you know you cannot handle it, or that you cannot find a use case for such situations, then of course hacking is not for you and you’re better off with a nanny.
  Your proposal that everyone be denied the hacker option is nanny advocacy to the extreme.
  only to eventually figure out it’s because a program has 4kb of german midget porn in the middle of its executable. Just spend the $10 on an SD card that isn’t broken.
  This is really terrible advice. An SD card is no substitute for a SATA drive in most situations. Sure, you could get an obscure SD→SATA adapter imported from China if you are willing to shop online, but SD cards are extremely unreliable and poor performers. Of course no one is stopping you from doing that, but it’s an absurdity to bully others into foolishness.
  SD cards have an even shorter life than SATA SSDs. They have no SMART capability and no telemetry. They can’t even detect their own corruption. One day out of the pure blue they become unmountable. They are utter garbage. In 4 out of 5 cases I have seen SD cards corrupt in less than 1 year.
  Everyone has different budgets and use cases but you are not only promoting nannying but also consumerism and e-waste and dodgy tech in a forum that opposes disposable products with short lives.
  Nobody wants a storage device that will silently corrupt data instead of failing safely as soon as it’s known to be faulty.
  You’ve misunderstood. Nobody here proposed that. Of course it should fail safely when bad blocks reach an significant threshold. The contention is whether owners should be nannied after such failure -- whether it’s justified to block people (including experts) from having control over their own property.

Happened with a microSD card when I was using it to flash an Android ROM. It was very annoying to find out what the problem was (when using an SD adapter, this can be caused by a mechanical problem with the slot's leaf switch that checks the slidable write-protect notch that despite common belief, does not close electrical contacts in the card). There is a lot I could have done with 64GiB of read-only memory if I could see it coming!
- Worth noting that SD cards are much more vulnerable to bit wear than a SATA drive. Very early SATA drives pre-date tech advancements on wear reduction and wear leveling. I seem to recall SATA drives became more resilient and longer lasting -- but still far to short of a lifetime in the end.
  SD cards use different technology IIRC. Did they ever get a handle on that? Interesting to know SD cards also have a forced read-only state at EOL, but I guess it must be implemented differently because SD is sdio not SATA.
  
  SDIO is an extension of the SD spec for non-storage devices. AFAIK, the term never referred to the original (storage) protocol.
  I have no idea about the implementation but in all devices, drives and OSs I tried, it acted the same as an SD card with the write-protect switch enabled. Obviously a SSD can be maliciously programmed to fake writes or time them out but this was not the case. A quick glance at the incomplete spec does not suggest a write-protect implementation from the SD side. The SD can check a register in the host controller (Cat.C 0x024 bit 19 active LOW) for the notch status but it's not allowed to write into it.

Modern SSDs are more suitable for long term storage when compared. to HDDs. but there is a mix opinion. I think your SSD died from some serious amount of writes and reads done which is not normal
https://www.reddit.com/r/DataHoarder/comments/zpt6es/long_term_storage_ssds_vs_hdd/

10 comments