SSDs made in the last few years don't require TRIM, it is all handled at the firmware level now.

TRIM is essential as otherwise the SSD will see ever increasing block usage even though they represent deleted files from the OS perspective. And don't you answer your own question .... clearly stating that such software did exist for XP?

Drive FW does do garbage collection, although it's generally a better idea for the OS to issue TRIM since it has insights into how FS allocate/deallocate blocks.

Can't garbage collect what it doesn't know is garbage. Hence TRIM.

so that I won't have to pop the drive out and TRIM it on a modern PC

Install and dual boot a modern minimal Linux, mount your Windows XP FAT32 partition(s) with -o discard, and then run 'fstrim' on them.
Linux's ntfs-3g doesn't support discard yet.
You will also be able to trim your dual-booted Linux filesystems (provided you use common ones like ext4, xfs, or btrfs).

mothergoose729 wrote:

SSDs made in the last few years don't require TRIM, it is all handled at the firmware level now.

Yes and no. AFAIK, TRIM is an OS-level command. There are no SSDs with built-in TRIM functionality. SSDs do have firmware-level garbage collection, but they are not the same thing. This article illustrates the differences and shows why TRIM is strongly desired.

kolderman wrote:

And don't you answer your own question .... clearly stating that such software did exist for XP?

It did exist, but only for specific SSDs. If I bought a Corsair SSD, I can only then use Corsair's software. At least that's what I have been able to gather. I actually should see if this software works with other brand's SSDs, but it would be nice to have software that wasn't.... custom-tailed to one brand of SSD.

krcroft wrote:

so that I won't have to pop the drive out and TRIM it on a modern PC

Install and dual boot a modern minimal Linux, mount your Windows XP FAT32 partition(s) with -o discard, and then run 'fstrim' on them.

Ah, good idea. Except I'm using an NTFS partition, one that I created under Windows 10, because according to this article, XP supposedly doesn't align its partitions correctly. However, I don't think doing that mattered much, since the bytes/sector (which I assume is the "disk block" size) is 512K for all for all of my SSDs under Windows 10, so if 10 runs SSDs just fine with that block size, why would SSDs need a block size of 4000K? I think there's some validity there, but I'm not so sure. Doesn't Windows 10 automatically align the partition it creates to an SSD's blocks? Sadly, I'm confused in this regard. 🤣

Anywho, I chose NTFS over FAT32 because, well, it's a more "advanced" file system, and it's what XP defaults to. shrug It works, so, why not use it?

Yeah, I would have gone with NTFS as well given no other constraints. (which now rules out using Linux as a once-a-month TRIM buddy).

Next best might be dual-booting Windows 7 or 10.

But given the 20 to 60GB of recommended storage these behemoths will consume, that's a bit like using a Honda Civic to tow a Ford 350 truck because it has nicer drink holders 😀

Maybe Microsoft offer a leaner stripped down 'infrastructure' version (for cloud or VM installs) that wouldn't eat up half your SSD?

Regarding block size, modern SSDs have the notion of fixed erase block size, or EBS, which can be though of as a single chunk of data that might be 2MB or even 16MB (perhaps even bigger now, depending on the make/model of SSD). If any byte within a given EBS chunk changes, then the controller will read in the entire chunk, change the requested bytes, and then write-back the entire chunk to NAND.

So it's ideal to have your OS filesystems' block size and block alignment (and RAID boundaries) also align and neatly fall within the SSD's alignment and EBS chunk sizes. Otherwise, if your filesystem's blocks stradle two EBS chunks, you will reduce your write rate for those portions by half and also double the wear.

(That said, only perfectionist tend to sweat these details as the performance hit and extra wear are not a problem for casual users).

krcroft wrote:

Yeah, I would have gone with NTFS as well given no other constraints. (which now rules out using Linux as a once-a-month TRIM b […]
Show full quote

Yeah, I would have gone with NTFS as well given no other constraints. (which now rules out using Linux as a once-a-month TRIM buddy).

Next best might be dual-booting Windows 7 or 10.

But given the 20 to 60GB of recommended storage these behemoths will consume, that's a bit like using a Honda Civic to tow a Ford 350 truck because it has nicer drink holders 😀

Maybe Microsoft offer a leaner stripped down 'infrastructure' version (for cloud or VM installs) that wouldn't eat up half your SSD?

Yeah, but remember, this is on my Pentium 4 machine. With a Pentium 4 672 and soon to be 4GB of RAM. That's asking a lot from the hardware to run the newer software (okay, 7 should be fine, but 10 is really stretching it). No, I have a better idea. This system has both the 98 and XP installs on two different SSDs of the same model, and both can be easily removed from a 2x2.5" drive hot-swappable 5.25" bay at the front of the case. I have an old Toshiba laptop with a DVD drive. I'll replace the optical drive with a hot-swap 2.5" drive and have Windows 10 on that system to TRIM the SSDs... if I don't find software for XP to do it.

krcroft wrote:

Regarding block size, modern SSDs have the notion of erase block size, or EBS, which can be though of as a single chunk of data rangeling from 2MB to 16MB (perhaps even bigger now, depending on the make/model of SSD). If any byte within a given chunk changes, then the controller will read in the entire chunck, change the desired peices, and then write-back the entire piece to NAND.

So it's ideal to have your filesystem's block size and block alignment also align and neatly fall within the SSD's alignment and EBS chunk sizes. Otherwise, if your filesystem's blocks stradle two EBS chunks, you will reduce your write rate for those portions by half and also double the wear.

(That said, only perfectionist tend to sweat these details as the performance hit and extra wear are not a problem for casual users).

Noted. Thing is, though, how would I find out what the EBS is on a given SSD, and does Windows 10 do a good job at aligning file systems to the EBS?

kolderman wrote:

Can't garbage collect what it doesn't know is garbage. Hence TRIM.

actually it does, up to a point. when drive receive cmd to overwrite a block, it'll allocate a fresh block and store the new data in that block, and old block is typically place in a pool to be bulk erased when drive is idle or some other threshold is reached (different vendor will use different algorithm for this.) however if the FS deletes a file, non-secure FS typically only update the meta data, but does not erase the file content on the media. this is when trim/umap can explicitly instruct the drive to discard the blocks for erasure.

how would I find out what the EBS is on a given SSD

If the drive is popular, google will get you there, but if not, contact your drive's support desk. Might take a couple calls to find the right person who either knows or cares enough.

For example: https://forums.anandtech.com/threads/samsung- … -sizes.2448833/

Also, the OS cannot determine EBS dynamically as there is no interface to query it. (But custom software can come with a canned table of EBS sizes that are used for a given make/model of drive).

krcroft wrote:

If the drive is popular, google will get you there, but if not, contact your drive's support desk. Might take a couple calls to […]
Show full quote

how would I find out what the EBS is on a given SSD

If the drive is popular, google will get you there, but if not, contact your drive's support desk. Might take a couple calls to find the right person who either knows or cares enough.

For example: https://forums.anandtech.com/threads/samsung- … -sizes.2448833/

Also, the OS cannot determine EBS dynamically as there is no interface to query it. (But custom software can come with a canned table of EBS sizes that are used for a given make/model of drive).

Interesting article. Yeah, I can look into it. But what I was able to garner from the article is that EBS relates to the size of Windows page files, no? It is in fact not equal to bytes/sector, correct?

In other news, I decided to experiment a bit with some SSD utilities, and the results were sad to say the least.

The Corsair SSD Toolbox installed without issue, but sadly did not allow for any TRIM support with my drive:

Surprisingly, the latest version of Teamgroup's SSD utility worked under XP. Well... "worked."

Yeah, no, not really. It was pretty broken, probably relying on Windows 7+ OS components to get some of the data.

The final utility that I could get to work was SSD Tweaker. Sadly, any TRIM functionality is locked behind a paywall, and in the log tab, it said "TRIM could not be detected."

So far, it's looking like there might not be any such software out there. Again, that's why I'm trying to pull from the entire VOGONS community. Maybe somebody knows something.

I don't you'll see any issues even if you don't trim it.

Have you tried
https://sourceforge.net/projects/naraeon-ssd/
https://www.naraeon.net/en/latest-naraeon-ssd-tools/

EBS relates to the size of Windows page files, no? It is in fact not equal to bytes/sector, correct?

The EBS for a given model of SSD is a permanent physical constant defined (and likely optimized) by the manufacturer. It not changeable nor does it have anything to do with the operating system.

It's the opposite - that is, if you understand the SSDs alignment and EBS, you can optimize your effective performance by how you layout your partitions and how you configure your filesystems.

I've been using this, can't remember where I got it but it seems to work to me...even if it doesn't I feel better.

First of all, new development. I figured out that when this article mentioned "disk blocks," it probably meant cluster size. In which case, my install of XP already has the recommended cluster size. At least, it appears that way.

All of this terminology is very new to me, though. If it wasn't already apparent I'm a massive noob, well, you know now. 🤣

Moving on

DosFreak wrote:

I don't you'll see any issues even if you don't trim it. […]
Show full quote

I don't you'll see any issues even if you don't trim it.

Have you tried
https://sourceforge.net/projects/naraeon-ssd/
https://www.naraeon.net/en/latest-naraeon-ssd-tools/

Yeah, there shouldn't be any massive issues if I never TRIM the drive, but it most likely helps to do so.

In regards to that tool, I just tried it out. It appears to do something when I manually TRIM the SSD, but, I mean, there doesn't feel like anything happens. Also, there's a silly time/date error when I start the program.

krcroft wrote:

EBS relates to the size of Windows page files, no? It is in fact not equal to bytes/sector, correct?

The EBS for a given model of SSD is a permanent physical constant defined (and likely optimized) by the manufacturer. It not changeable nor does it have anything to do with the operating system.

It's the opposite - that is, if you understand the SSDs alignment and EBS, you can optimize your effective performance by how you layout your partitions and how you configure your filesystems.

Noted. Although, it's going to take a lot more research on my part to understand these concepts.

Shagittarius wrote:

I've been using this, can't remember where I got it but it seems to work to me...even if it doesn't I feel better.

ssdtool.exe

A quick search for the tool on Google led me to this website. Apparently the author of the program was a user on the Crucial SSD Forum, which now ceases to exist as a forum.

Just like the previous tool, in fact on a greater scale, this tool also felt... underwhelming. I know, TRIMing under Windows 10 feels about the same way, but at least under 10 when you "optimize" your drive and you see the percentage of the drive currently TRIMed, you feel like it did something. This? No such feeling. 🤣

I'd say with both of these SSD tools, there is no way that I know of to measure whether or not they did their job or not. If there is some way I can verify that they actually work, especially compared to Windows 10's TRIM functionality, then I'd be willing to test them and do a comparison.

I think, though, that these tools must do something, so I'll run these tools once in a while, and then once in a blue-moon (a few months) I'll pop the drives out of the machine and throw it into my old craptop to let Windows 10 "officially" TRIM it. Can't hurt, right?

Any who, I'd be happy to find more alternatives to these two pieces of software. Maybe something with a bigger name behind it might hold more weight.

I think you need AHCI for TRIM. You say you're using a Pentium 4. Yes, there are combinations of southbridges and P4 chips which support AHCI, but is this something you have?

mockingbird wrote:

I think you need AHCI for TRIM.

You actually don't.
https://forums.intel.com/s/question/0D50P0000 … in-ide-and-ahci

However, apparently Win7 may not enable it properly in IDE mode, or if you clone from HDD to SSD:
https://forums.tomshardware.com/threads/windo … g-trim.2142892/

Since we are talking about XP here, Win7's behavior is irrelevant. The manufacturer toolbox (if available) should manually send TRIM just fine.