Dimos wrote on 2025-03-24, 12:43:

Greetings to all! A couple of days ago i finally installed an Ssd drive on my Windows XP build. Knowing of course that from Wind […]
Show full quote

Greetings to all! A couple of days ago i finally installed an Ssd drive on my Windows XP build. Knowing of course that from Windows Vista and before no Microsoft OS natively supports the Trim command for Ssd drives i have spent quite some time searching for some kind of software that could manually Trim an Sdd drive. Of course modern Ssds work so well that even without Trim you could use one on an old Os and don't have to worry about performance reduction or premature wear (Garbage Collection works at the firmware level, independently from the OS, Trim just makes this procedure easier, more efficient). After several hours searching various forums, including Vogons, i have found a couple of software utilities that had a manual Trim option. I installed and tested three of them (Anvil's Storage Utilities, Iobit Smart Defrag and Elpamsoft Ssd Tweaker) but none of them provided any kind of documentation concerning the Trim option (if it works only for OSes that natively support Trim and the only thing they do is manually sending the command or they somehow work on older OSes and in which way do they do that exactly) and i was uncertain if they did anything really for Windows XP. Until yesterday i came across some info that suggested that Acronis True Image 2014 also has an option that enables Trim and the person mentioning that also verified that it was indeed working on XP after using Trimcheck. So intrigued by this i searched a little further and came across this document: https://dl.acronis.com/u/pdf/ATIH2014_userguide_en-US.pdf
In this it is mentioned that:

Note: The utility uses the standard TRIM command to inform an SSD about blocks of data that are no longer in
use and can be erased. Please make sure that your SSD has necessary firmware to support it.

and also:

Trimming an SSD by means of Acronis True Image 2014 is reasonable only if you use Windows Vista or earlier. Windows 7 supports […]
Show full quote

Trimming an SSD by means of Acronis True Image 2014 is reasonable only if you use Windows Vista
or earlier. Windows 7 supports the standard TRIM command right out of the box and erases cells as
soon as data is deleted.
To trim an SSD:
1. On the sidebar or on the toolbar, click Tools & Utilities and select Trim SSD.
This opens the wizard.
2. From the list of available drives, select the SSD(s) that you want to trim and click Next.
3. Review the summary page and click Proceed.
4. If you have run the wizard under Windows, click Reboot when prompted.
After the reboot, the operation will automatically proceed in the standalone Linux-based
environment. When the operation is complete, the wizard will boot up Windows again.

So it explicitly says that what it does is to send the standard Trim command and that this function actually is provided in order to be used with older OSes that don't natively support Trim. So as you can imagine i installed the specific version (2014) of the software (newer versions seem to lack the Trim option, haven't verified that myself), found the Trim option, selected my drive and everything went as expected, the pc restarted, it entered into the linux based boot environment, Trim completed and computer restarted again. To be absolutely certain that it worked i run Trimcheck (very useful tool btw): https://files.thecybershadow.net/trimcheck/ before and after the procedure and verified that Trim actually works! So that's it, there is at least one completely verified third party tool that actually does this job and thought that it would be useful to share this with anybody that might be interested!

You need Garbage Collection, not TRIM. New SSDs have excellent GC algorithms, but they are very reluctant to activate their GC. They wait for TRIM signals that never come - that is the problem you face.

Early SSDs predate TRIM. What they did differently is continuous GC. But, it trying to do its GC while you are trying read and write data hurts performance. To mask the performance problem they demanded massive over provisioning.

On a SSD, overwriting logical addresses creates garbage that can be GC'd, while deleting files without trim creates deadweight, blocks that the SSD counts as valid and have to be preserved and moved during GC, they will be garbaged if other files write to the same logical addresses.
A key limitation of NAND flash in SSD is that it is erased (in erase blocks) to set the data one way, and then written the other way, and then those bits cannot be reversed other than by erase.
Under partitioning does mitigate the issue, space within a partition that NEVER gets touched also helps, but file system allocation rules prefer fresh space unless already uncomfortably full

The reason TRIM matters at all is because it enables the OS to tell the SSD that a delete is not an overwrite. Without TRIM, the SSD doesn't know the difference between an overwrite and a delete.

The always changing metadata (e.g. time a file was last accessed) means the NTFS index file is constantly rewritten - this is the source of delete garbage that grows faster than the GC can clean up. EDIT: You can disable NTFS access-time updates, but conceptually NTFS concentrates the description of your disk in one small area of the disk so each time you touch any file on the disk there is a delete of old records creating a high concentration of garbage in one small disk area.

FAT32 distributes the metadata as lots of little files throughout the disk - that is a big source of seek delays on HDDs, but SSDs don't seek - and it creates only tiny amounts of delete garbage in random locations that old style GC can keep clean.

But a new SSD is still going to assume TRIM exists, and won't start its GC aggressively enough to keep on top of FAT32 garbage. This where mixing old and new doesn't work.

With old signals, the best way forward is to use old SSD and old FAT32 file system. That is three things to align. Mixing them up creates problems. EDIT: Win2K/WinXP can boot from FAT32 partitions and Vista+ requires NTFS partition.

Logic wrote on 2026-01-09, 17:02:

IIRC the SD Card Association's Formatter does use FAT32 IF the card is 32GB or smaller. (Also USB flash drives. I dont kno […]
Show full quote

wierd_w wrote on 2025-03-24, 20:46:

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.)

IIRC the SD Card Association's Formatter does use FAT32
IF
the card is 32GB or smaller.
(Also USB flash drives. I dont know/doubt about SATA connected drives?)

The long format (whatever they call it) is about as close as one can get to a Secure Erase for SD Cards and flash drives:
A cheap USB flash drive went from 1MB/s writes to 6MB/s here,
until filled once that is..!

It also has an uncanny ability to fix troublesome drives.
IIRC; Marks 'bad sectors' as such. etc?

(If the SD card is going into a half decent card slot for a OS type long stay;
Some non conductive thermal compound helps surprisingly well to avoid Heat Death and ctlr slowdowns!
It takes some applying to the slot (with a sized bit of cardboard) And to the SD Card itself. (That's so it does not all just get wiped away/off upon insertion...)
Then a wipe off of the excess around the inserted card/holder.
(A small heatsink also helps, As does a bit of airflow)

A messy business to clean when you do remove the card, to be sure, but worth it IMHO.
I recommend 1st cleaning/wiping off the excess, before removing the card, to Avoid filling the slot with dusty old TC.
Then more cleaning.)

The Samsung Evo+ (not Evo Plus) cards have a good rep for fast R4K (writes) in Raspberry Pi circles.

For the 32gb and smaller devices, the page and erase block sizes are within the capabilities of the FAT32 filesystem, and the factory format uses that size. It's 'the same thing*'.

* For these smaller cards, the FAT32 cluster size is set to the eraseblock size. Usually someplace between 4k and 32k. For the larger cards, that are SDHC or SDXC, the SDCard Assn wants you to use eXFAT, and the cluster size is *STILL* factory formatted to be equal to the erase block size. (usually someplace in the neighborhood of 4mb) In both cases, it is "The Same Thing"-- The computer only writes in atomic sizes that match the erase block, and this is done to prevent the card from getting nuked by amplified writes. It *ALSO* gives faster read accesses, because the card can return that many logical 512 byte sectors on a single read operation. If the card is formatted with a crappy cluster size, then the computer will dispatch multiple read operations for several clusters, and will want acknowledgements for these transactions. This increases the overhead, and slows the card down with traffic it does not actually need to be doing.