Have been using SSD drives on retro systems for years and never once bothered with Trim, its simply not required. Many will try and argue otherwise but for a system being used rarely with a drive that will never reach capacity and with as many pointless services turned off that write to the disk .. the drive will never need it, modern SSD drives have amazingly good garbage and provisioning firmware and can handle what little cleanup is required on any retro system without the need for 3rd party tools.

I dare say the SSD will outlive the retro system its placed into with little to no intervention from the user.

Naturally their arguments apply if the drive will be in a heavy drive use environment or the retro rig is being used 24/7...but I cant see that ever being the case since we all know retro enthusiasts are not stupid enough to subject any retro system to that.

IIRC there is also an Intel Trim tool that is available for Intel SSD drives, IIRC Crucial also has one.

There is also one from Rlowe which I believe still works that can be run from DOS.

I dont know of any that can handle Trim for a Fat16 SSD.

I couldn't agree with you more. The controllers and firmware in today's Ssds are perfectly fine in ensuring that those drives will work flawlessly on older Oses that don't natively support Trim. In all but the most extreme cases one shouldn't worry about his Ssd perfoming just fine and having a long lifespan, without the need to do anything in particular to ensure that. Despite this, having the ability to Trim your Sdd or tweaking some settings (e.g. disable Firefox disk caching ) is definitely a plus. Of course there are a couple of proprietary tools from Ssd manufacturers that were released mostly in the early days of Ssd wider commercial availability that probably give you the option to Trim your disk, but these are mostly working each with a specific vendor drive and with specific controllers found mostly on Ssds from those days.

Dimos wrote on 2025-03-24, 14:14:

I couldn't agree with you more. The controllers and firmware in today's Ssds are perfectly fine in ensuring that those drives will work flawlessly on older Oses that don't natively support Trim. In all but the most extreme cases one shouldn't worry about his Ssd perfoming just fine and having a long lifespan, without the need to do anything in particular to ensure that. Despite this, having the ability to Trim your Sdd or tweaking some settings (e.g. disable Firefox disk caching ) is definitely a plus. Of course there are a couple of proprietary tools from Ssd manufacturers that were released mostly in the early days of Ssd wider commercial availability that probably give you the option to Trim your disk, but these are mostly working each with a specific vendor drive and with specific controllers found mostly on Ssds from those days.

The Rlowe one works on any drive but only for Fat32, not entirely sure why it wouldn't also work for Fat16 but I assume there is some shenanigans going on with Fat16 and SSDs in general . .its a rather odd partition format for them.

As for NTFS your tool should work just fine.

The other way is to boot via Linux which IIRC has Trim support and should Trim the SSD without damaging the partition on it.

ThereBeDragons when using 'garbage tier' flash though, like SD->IDE devices.

(Or driving a microSD card in the slot like it was a normal disk, such as on a reflashed chromebook. Legacy Bios equipped versions of custom firmware exist, and in theory, sbemu and pals would let these run as low cost dos pseudo-retro machines)

These systems would benefit from write behind caching for the write-combining features of such caching, because this kind of flash often lacks the kind of garbage collection and wear levelling found in a proper SSD, and get nuked very fast from write amplification.

Caveat emptor.

Yeah SD cards are not SSD drives and really really shouldn't be treated like they are, not sure about Compact Flash however, its got a bit more robust firmware but still I wouldn't treat it like its a full SSD.

I like them both as DOS drive replacements though, DOS is pretty easy on NAND due to its fairly low writes to the drive, Win 3.11 should be fine too so long as the system has plenty of ram and you turn off swapping.

Still buyer beware, if a deal is too good to be true then it usually is.. especially with Nand.

Booting a live Linux distro to Trim your Ssd is of course another option, but (if i am not mistaken) most of these distros support only Fat32 Trimming, so you have to pick one that does this on Ntfs also. Another way to do this would also be dual booting, with the second Os being Windows 7 and newer and using the newer OS to Trim your drive. As far as Fat16 is concerned, i have absolutely no idea. I also agree about SD.

Not TRIM, but garbage collection..
Wasn't there that "trick" that the SSD could be encouraged to do a "clean up" by entering CMOS Setup straight after powering on the PC?
The way I remember, the PC is simply left running Setup for a while and then the SSD would do its job because it's idling without being talked to by an OS.

Yes. For a real SSD, that would do.

Again, SDcard is not a real SSD, and has no such function. It's designed to be as cheap to manufacture as possible, meaning the nand controller inside is hyper simplistic.

That's why they die so easily from abuse, and need to be treated special. (And why the SDCard Assn demands they be formatted with exfat, which enforces that treatment.)

Ah, okay. I know not much about SD cards, except that they're sisters of MMC cards and also being known as TF cards in the far east.
I vaguely remember that they have (had) a microcontroller comparable to a PIC16F84, also. But that was 20+ years ago.
CF cards are more like IDE drives and are physically bigger, so they have more room for a possible controller.

Older SSDs may work more reliably sans trim. That is because TRIM appeared decades after SSDs did. Most of my flash-based do not support trim at all. It was the era when controllers would try to do intelligent/stupid things (included but not limited to seaching for FATs). In addition, older SSDs have just way more PE cycles anyway.

A newer SSD is unlikely to do anything fancy and will likely rely almost completely on the host, but here I'm just guessing. On the other hand newer SSDs have lot more capacity which also helps. Can't beat that.

But again, I would agree this is more SSD-related paranoia. A single Win10 install likely performs more writes to disk than a 9x install would during its entire lifetime...

To manually TRIM in XP I've used the bright and colorful "AData SSD Toolbox". It doesn't care what brand your SSD is.

It also shows SMART status and has other "optimization" and utility options like a "Secure Erase" function. I don't think I've used those.
Ironically my intended "high powered XP" system is the one where manual TRIM fails, and I think I have AMD's chipset drivers to blame for that. But it worked on every other system I've tried it with.

There's a workaround to mitigate the need for TRIM.
Without TRIM, the list of logical addresses that the SSD thinks represent real data is constantly growing, and never shrinking, because TRIM never tells it to drop any of them.
If(when) you reach the point where almost all logical addresses have been used by the OS at some point, then the drive thinks it needs to maintain essentially it's full capacity worth of data, associated to each of those addresses. "Garbage collection" becomes analogous to defragging a filled up hard drive. Dozens of rewrites trying to rearrange the data while keeping all of it intact. This heavy "write amplification" is the cause of bad performance and greatly accelerated wear when an SSD gets into this state.
That's the theory, and I agree on a retro gaming PC you could just ignore it, but I don't like that approach. The speed of this phenomenon is in proportion to how big the drive is vs how much data you churn. It might take 100 years - but why not prevent it anyway? There's a simple way to contain the issue to a healthy and stable boundary, and I see no reason not to.

Start with a fully TRIMmed drive. Then partition it for XP (use a modern utility that aligns partitions properly - XP does it wrong), but leave some of the space unpartitioned. If 20% of the space isn't partitioned, then 20% of the logical addresses will never be used. This ensures the actual Flash storage will never be more than 80% committed. The data can still go anywhere on the physical Flash (that's up to the SSD), but it won't think more than 80% of it's capacity is holding anything important. This prevents the drive from ever falling off a cliff into heavy "write amplification", which is what sends an overcommitted SSD into decline.

You can get away without limiting the partition size like this, but if the SSD is amply sized then I see no reason not to put this boundary in place. Leave some excess space unpartitioned and it prevents the scenario. If you fully partition the whole drive, you're just allowing the opportunity for it to get overcommitted. There's no reason to enable that IMO.

shamino wrote on 2025-03-25, 04:37:

Start with a fully TRIMmed drive. Then partition it for XP (use a modern utility that aligns partitions properly - XP does it wrong), but leave some of the space unpartitioned. If 20% of the space isn't partitioned, then 20% of the logical addresses will never be used. This ensures the actual Flash storage will never be more than 80% committed. The data can still go anywhere on the physical Flash (that's up to the SSD), but it won't think more than 80% of it's capacity is holding anything important. This prevents the drive from ever falling off a cliff into heavy "write amplification", which is what sends an overcommitted SSD into decline.

^^^ This.

Running fstrim on the mounted partition from time to time in linux would not hurt either.

Did not know about the dinky little adata program, that would make booting linux unnecessary if it works (which it probably does)

shamino wrote on 2025-03-25, 04:37:

but leave some of the space unpartitioned. If 20% of the space isn't partitioned, then 20% of the logical addresses will never be used. This ensures the actual Flash storage will never be more than 80% committed. The data can still go anywhere on the physical Flash (that's up to the SSD), but it won't think more than 80% of it's capacity is holding anything important. This prevents the drive from ever falling off a cliff into heavy "write amplification", which is what sends an overcommitted SSD into decline.

You can get away without limiting the partition size like this, but if the SSD is amply sized then I see no reason not to put this boundary in place. Leave some excess space unpartitioned and it prevents the scenario. If you fully partition the whole drive, you're just allowing the opportunity for it to get overcommitted. There's no reason to enable that IMO.

Is that really necessary when manufacturers already reserve part of the space for overprovisioning?
A link I posted in a similar thread a while ago:
https://www.kingston.com/en/blog/pc-performan … verprovisioning

lolo799 wrote on 2025-03-25, 09:41:

Is that really necessary when manufacturers already reserve part of the space for overprovisioning? A link I posted in a similar […]
Show full quote

shamino wrote on 2025-03-25, 04:37:

but leave some of the space unpartitioned. If 20% of the space isn't partitioned, then 20% of the logical addresses will never be used. This ensures the actual Flash storage will never be more than 80% committed. The data can still go anywhere on the physical Flash (that's up to the SSD), but it won't think more than 80% of it's capacity is holding anything important. This prevents the drive from ever falling off a cliff into heavy "write amplification", which is what sends an overcommitted SSD into decline.

You can get away without limiting the partition size like this, but if the SSD is amply sized then I see no reason not to put this boundary in place. Leave some excess space unpartitioned and it prevents the scenario. If you fully partition the whole drive, you're just allowing the opportunity for it to get overcommitted. There's no reason to enable that IMO.

Is that really necessary when manufacturers already reserve part of the space for overprovisioning?
A link I posted in a similar thread a while ago:
https://www.kingston.com/en/blog/pc-performan … verprovisioning

They do provide a bit of overprovisioning, but it's minimal on consumer tier drives. From their point of view it's a waste of money to add storage that can't be advertised as usable capacity.