Hacker News Reader

Comment by haunter | Hacker News Reader

How fast do modern SSDs die in older systems without TRIM?

I am yet to hear about 1 dying from a customer. But I can't give you a scientific answer to that and I've only been doing this since April. There's a whole community of people doing these upgrades. You can find them at https://macos9lives.com

That's where the hacked Mac OS 9 comes from and there are threads about Mac mini SSDs. There are also threads at https://68kmla.org

I would ask there.

This is the patch that I wrote to make the “Mac OS ROM” file bootable on the mini. The original development happened at MacOS9Lives. Anyone interested in Classic Mac OS hacking is very welcome to join us at #mac68k on Libera.

https://github.com/elliotnunn/tbxi-patches/blob/master/macmi...

Old OSes like MacOS 9 barely touch your disk with writes at all, they typically don't have any log files they're writing to, they barely use any virtual memory. These things are never going to see the terabytes of writes they're rated for.

Lots of people (me included) use SD card or Compact Flash adapters in old machines without wearing them out and those have way worse endurance than SSDs.

I have a PowerBook that's been running 24/7 for the past year as an Apple Internet Router and AppleShare file server on GlobalTalk off an SD card in a SCSI2SD adapter with no issues.

You also have to account for the expected writes. Modern SSDs may perform better (over time) with TRIM, but if you just create (or leave) an erased partition to bump the effective over-provisioning even cheap consumer SSDs should outlast the expected usage for a cute little retro computing system.

It would be different if you used them them 24/7 to keep some old, but demanding peripheral alive (e.g. a large old printing machine) running. If you can schedule the downtime you could still, image the disk, erase it, and restore the disk every few months under the guise of preventive maintenance. Heck if you (net-)boot Linux or *BSD depending on the IDE<->SATA bridge used you may be able to send TRIM/UNMAP commands to the SSD without opening case. Of course each such backup/erase/restore cycle would be equivalent to a full drive write.

Given the tiny filesizes of the games involved, if durability is a worry I’d just overprovision space. SATA SSDs are dirt cheap these days and it’d take ages for an OS 9 install to write to all the cells in a 256GB drive (assuming adequate RAM + disabled virtual memory), let alone with 500GB+ drives.

There exist (very cheap) SSDs without TRIM support at all currently for sale. I own one. It won’t die, but writes will suck if you’re writing more than the overprovisioned space all at once. For this use case, that’ll probably never happen (and it’ll probably still be faster than the original HDD both in throughput and random I/O).

Some SSDs also support primitive garbage collection if sequences of 1s are written to the disk in unused spaces. I don’t know how to accomplish that on OS 9, but it might be possible with 10.4 or 10.5’s disk utility. If I remember correctly, there’s an “erase free space” function. Whether that writes 1s or 0s I’m not sure, though.

Most good/modern SSD's should have built in capabilities for at least the bare minimum of garbage cleanup

Is this actually enough? I've never been able to find a clear answer on this - it's become increasingly common to install SATA SSDs in retro game consoles, for example, but nobody seems to have ever done any testing to see if the functionality on newer SSDs is adequate to handle systems without TRIM support.

You used to hear all kinds of horror stories about people who threw a SSD into their PS3 and found their whole system grinding to a halt within a year.

Can you work around it by massively overprovision by partitioning the drive and leaving half of it unallocated? The amount of space you need for an older system like this should be tiny compared to modern storage.

That works as long as you prepare the drive on a machine that does support TRIM, to ensure the unpartitioned area gets TRIMed one last time before the drive is moved to the old machine. Then it should remain in that state as long as it's never written to.

Even if you didn’t do that, I wouldn’t expect the partitioning to write to the unallocated space. If you start with a fresh drive I’d think it should work.

Yes if you trim it after making that partition and system correctly informs SSD about empty space. Secure Erase before making partition would be the safest bet - that way SSD firmware has full control over free unallocated space.

While internally managed garbage collection is less efficient than TRIM managed, it's significantly better than unmanaged.

"Enough" is a relative term and is up to you to decide. The alternative is significantly less performant coupled with unpredictable reliability (outside of expensive enterprise options), but a higher overall lifetime.

While a year of lifetime would suck, does it ultimately matter? This is old equipment not used for anything critical in the context of the discussion in this thread.

It only matters insofar as it has the potential to cause people some annoyance down the line which they'd likely prefer to avoid.

People don't tend to want to have to actively maintain their old tech any more than they absolutely have to.

Oh absolutely, do not disagree.

Though I do think that if one is using old tech, they should be aware of the pitfalls. There was a good run of the capacitor plague, for example. I avoid this equipment in general as I don't have soldering skills (but man oh man, I would love to have a working SE/30! People trying to sell repaired SE/30s on eBay for $1400USD!) to repair them. I know the VRM on my G4 Cube can potentially have issues, as can the power brick. Fortunately there are small batch available replacements should I need them.

It’s still cheaper than actually having pay for the games that’s going unpaid for with these systems, so it all comes out in the wash for the user

How can the SSD controller do any garbage collection if it isn't told which blocks are no longer in use?

While it's true that mechanisms like TRIM can in many cases improve performance and extend drive lifespan, the only thing that's required for SSD garbage collection is for the SSD to be aware of which internal blocks map to logical blocks written by the OS (obviously always true for any standard SSD where garbage collection is even conceptually possible).

In practice, all SSDs have internal capacity greater than the nameplate capacity exposed to the OS, so all SSDs start with a reasonable amount of spare capacity; enabling TRIM merely increases the available spare capacity in proportion to the number of currently unused logical blocks vs. never written logical blocks — blocks outside all allocated partitions (unless written by something other than a filesystem [e.g., manually, or via a naïve disk imaging, diagnostic, or RAID rebuilding tool]) and blocks that allocated filesystems have never had the need to use (unlike SSD firmware, traditional filesystems don't practice "wear leveling" when allocating space, so, e.g., a 1TB filesystem that has never contained more than, say, 100GB worth of data at any point will probably contain a large number of LBAs that have never been written, independent of how much data has been deleted and overwritten).

The SSD may not know which logical blocks are no longer in use, but it's quite easy to simply have lots more logical blocks that never get used in the first place. Not having TRIM is only an issue if your OS actually touches the whole drive. A vintage MacOS game library would be tens of gigabytes at most, and any SATA SSD you buy these days is going to be at least double the capacity of a first-gen Mac Mini's hard drive.

Reply on news.ycombinator.com