I have samsungs and sandisk ssd's with 50k+ hours. I've used XP on boards with working sata from the custom install CD for the last decade and never have had an issue. I never use any software helpers, never trim, etc. One simple trick is I always put only the OS on the OS drive, preferably smaller than 120GB, much smaller. I use extra drives for data. I image them on linux, and now use generic dramless since that's all that is small enough... In cow form the images are 4-10GB. Tidy. Never had an issue, still waiting, and ready.

kasfruit wrote on 2020-08-05, 10:57:

ADATA SSD manger does support XP and TRIM but all their SSD's with Realtek controllers and DRMless are really a piece of junk. h […]
Show full quote

ADATA SSD manger does support XP and TRIM but all their SSD's with Realtek controllers and DRMless are really a piece of junk.
has anyone tested the TRIM function from ADATA with another SSD brand ?

Yes, I've used that on every XP machine that had/has an SSD in it. My grab bag of small SSDs are Micron, it doesn't care.
I have one machine that refuses to TRIM but I think that's because of the chipset drivers, not because of the utility.
[edit: just realized that question was a year ago, but whatever, response still holds.]

But for any OS where TRIM is inconvenient, I agree with kepstin that you can basically nullify the issue with overprovisioning.

Pre-TRIM the drive somewhere (secure erase will work, even if it's technically overkill), then make your partitions with a utility that properly aligns them (I like gParted with the "1MB alignment" option), leaving unused space to serve as overprovisioning.
If you leave 20-25% of the disk's logical address range unpartitioned and "unused" (the drive controller knows it's unused because it was previously TRIMmed) then the problem of write amplification can't ever get significant and the drive will be as healthy with Windows 95 or DOS or whatever as it would be under a modern OS.

As long as you set it up this way, it means that ~25% of the disk's logical addresses won't ever be associated to any data writes. This means the drive will always be guaranteed to have ~25-30% more Flash capacity than the amount of data that it believes it needs to retain, so the drive controller will be able to easily shuffle and reorganize the physical Flash storage without getting logjammed.

The "write amplification" death spiral that can occur in the absence of TRIM happens when the Flash storage is almost fully committed with data that the drive thinks is relevant (because it was never TRIMmed). That leads to a performance breakdown where garbage collection thrashes the drive, much like when you try to defrag a full hard disk. Overprovisioning prevents that from ever happening.

In practice many get away without paying any attention to overprovisioning, because you're unlikely to churn enough data through the drive to start seeing the problem.
But the "right way" to set it up IMO is like described above. There's no reason to leave 100% of the logical storage addresses exposed to an OS that doesn't TRIM. If you ever actually use all that space it'll just create a bad scenario. Cap it at 75% or whatever you find sufficient and then there's nothing to worry about even with very heavy usage.

I'm such a fanatic about this that I don't ever like to fully partition an SSD, even if TRIM is supported (but in those cases I'm not as aggressive about it). In practical effect this adds to the factory overprovisioning in the drive, which is generally skimpy on consumer drives (they don't like putting in Flash storage that the consumer doesn't see as usable capacity).

I agree with kepstin that you can basically nullify the issue with overprovisioning.

Overprovisioning is used primarily to reduce write amplification on flash. TRIM is used primarily to keep read/write performance in good condition. You easily can have sizable chunk of SSD for overprovision and still have garbage performance without TRIM (cough cough Sandforce).

O&O Defrag supports TRIM on Windows XP and could run as Service.