I have a OWC thunder bay mini connected to a Mac Studio with 4 Samsung EVO SSD's. The connection is thunderbolt 3. I have had this setup for a while and it working OK. I just realized that trim is not supported. ChatGPT recommends I enable it through the terminal. But I thought I recall reading a while back that trim is not necessary on Samsung SSD because of Samsung's built in garbage collection. Any thoughts?
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Enable trim on TB external SSD Yes or No
- Thread starter dimme
- Start date
- Sort by reaction score
If you can enable TRIM you should. Saying that garbage collection replaces TRIM is garbage, pun intended, because:
The drive's garbage collection needs to know which data is garbage that can be collected, and of the two ways how data becomes garbage, only one works without TRIM.
In other words, without TRIM your drive doesn't know what half the garbage is, and therefore can't "collect" it!
The drive's garbage collection needs to know which data is garbage that can be collected, and of the two ways how data becomes garbage, only one works without TRIM.
In other words, without TRIM your drive doesn't know what half the garbage is, and therefore can't "collect" it!
It may depend on what file system in use on the SSDs.
If you are using APFS:
Two important features of APFS are its Space Manager (Spaceman) and the Reaper.
eclecticlight.co
If you are using APFS:
Two important features of APFS are its Space Manager (Spaceman) and the Reaper.
- There is no documented need or use for trimming SSDs formatted in APFS.
- The trimforce command is inadequate, and may not work any more.
- APFS appears to automatically perform trimming on at least some SSDs when they’re mounted.
- Although I suspect that enabling trimming is no longer necessary for SSDs using APFS, there is no documentation that we can rely on to establish whether it might still be required.
Should you trim external SSDs?
Enabling the TRIM command was once thought important to maintain good write performance on SSDs. What has happened to it? Should we still be enabling it?
eclecticlight.co
The article you linked also concludes with "Recently, when I’ve been looking at how macOS mounts APFS volumes in disk imagesand Thunderbolt SSDs, I’ve discovered that Spaceman scans for free blocks and trims APFS containers when they’re mounted."
Even with APFS, if you delete a large file it's beneficial if somebody, the filesystem or the space manager, informs the SSD via TRIM that the data blocks are no longer valid, and consequently that the data blocks don't need to be preserved during write and/or wear leveling operations.
If I'm wrong please explain how and why.
Apple TRIM the internal drive. To me that suggests that Apple see some benefit. The nearest we will get to documented need.
I have never had to use
trimforce. When TRIM is supported, it is run without any user intervention.Yes, macOS performs TRIM at boot time on all SSDs which are capable.
Same as first dot point.
I believe that is a limitation of the Thunderbay. But ask OWC. With any Thunderbolt connected SSD, the controller determines what is supported.
My limited experience:
1) Internal disk TRIMs at boot time.
2) My external Thunderbolt 3 SSD also TRIMs at boot time - with no intervention on my part.
3) It is a universal belief that all USB 3, 3.1, 3.2 can not be TRIMed with macOS. But/surprise, with Samsung software (a kext), my USB 3.1 Samsung T5 and T7 perform TRIM at boot time. TRIM rejuvenated the performance of the T7. I didn't test the T5.
To determine whether an SSD is being TRIMed, use this command shortly after reboot:
log show --debug --last boot --predicate "processID == 0" | grep trimor maybe
grep spaceman (a bit more output). There will be lines like this if TRIM is being done:
2025-11-03 12:19:17.757450+1100 0x1872 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:4119: disk8 144153527 blocks trimmed in 759476 extents (489 us/trim, 2041 trims/s)For my Samsung T7 that last line is 8 minutes after boot and login. In terms of trims/s it is 20 times slower than the internal and TB3 drives.
To add to the conversation, the ThunderBay Mini 4 I own supports UASP and as such does indeed perform TRIM (on reboot only). I am also pleasantly surprised to find my OWC Mercury Elite Pro Mini USB 3.1 enclosures also support UASP and thus also TRIM on reboot. (Confirmed via the grep spaceman Terminal log scan mentioned above by Gilby101)
PS. I did enable trimforce via Terminal but have not tested to see if MacOS will perform TRIM on these external drives otherwise. ie. In 2025, is trimforce still required for performing TRIM on external drives?
PS. I did enable trimforce via Terminal but have not tested to see if MacOS will perform TRIM on these external drives otherwise. ie. In 2025, is trimforce still required for performing TRIM on external drives?
Last edited:
My understanding from recent posts elsewhere and from my experience is that
trimforce is not needed and most likely is irrelevant but not harmful.That was pleasant surprise. OWC make quality products.
That seems to be how macOS works for all SSDs.
I just tried the "log show --debug --last boot --predicate "processID == 0" | grep trim" after boot and my Thunderbay 4 mini does not support trim. I have not run the trim force command.
2025-12-02 14:50:52.727671-0800 0x133d Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:4449: disk7 scan took 0.136471 s (no trims)
2025-12-02 14:50:52.752844-0800 0x134a Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:4449: disk15 scan took 0.142591 s (no trims)
2025-12-02 14:50:52.912057-0800 0x1346 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:4449: disk11 scan took 0.303893 s (no trims)
2025-12-02 14:50:52.972772-0800 0x134f Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:4449: disk10 scan took 0.315705 s (no trims)
2025-12-02 14:50:56.067311-0800 0x1359 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:4449: disk13 scan took 2.680298 s (no trims)
2025-12-02 14:50:57.030293-0800 0x1365 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:4449: disk17 scan took 2.022361 s (no trims)
2025-12-02 14:51:11.269952-0800 0x1e69 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:4449: disk7 scan took 0.214625 s (no trims)
2025-12-02 14:51:11.279047-0800 0x1e71 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:4449: disk15 scan took 0.220193 s (no trims)
2025-12-02 14:51:11.336004-0800 0x1e67 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:4449: disk10 scan took 0.281953 s (no trims)
2025-12-02 14:51:11.427658-0800 0x1e76 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:4449: disk11 scan took 0.365994 s (no trims)
2025-12-02 14:51:12.605343-0800 0x1e88 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:4449: disk13 scan took 1.537541 s (no trims)
2025-12-02 14:51:13.385192-0800 0x1e9f Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:4449: disk17 scan took 2.292452 s (no trims)
Strange. I definitely have trim response and Trim Support in MacOS System Report does list all drives as "Trim Support: Yes".
Running your command, I just got this for disk7, which is one of the Samsung SSDs (a 1TB 870 EVO) in my Thunderbay Mini:
2025-12-02 19:58:02.411994-0500 0x19c5 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:4106: disk9 scan took 8.237922 s, trims took 7.994066 s
2025-12-02 19:58:02.412005-0500 0x19c5 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:4119: disk9 143114929 blocks trimmed in 10613 extents (753 us/trim, 1327 trims/s)
2025-12-02 19:58:02.412007-0500 0x19c5 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:4122: disk9 trim distribution 1:1382 2+:872 4+:1081 16+:1141 64+:2247 256+:3890
2025-12-02 19:58:02.412010-0500 0x19c5 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:4130: disk9 trims dropped: 840 blocks 771 extents, avg 1.08
FYI, my Thunderbay Mini is connected via Apple Thunderbolt 2 to TB 3 adapter with TB cable directly to my Mac Studio M4 Max running MacOS 15.6.1. TB Mini SSDs are all 1 TB in size. (2 different Samsung models and a SanDisk.) In MacOS system report, the Thunderbay Mini firmware version is listed as 25.1 with "Link Controller Firmware Version" listed as 0.14.0. I DO have trimforce enabled, although I swear the TB Mini could trim before. Might be worth a shot to enable it?
I hope this helps you track down the issue with your device.
Interesting the Thunderbay Mini4 I have is the TB# version and is connected directly to a Mac Studio. I also have a OWC Gemini connected via TB3 and it also reports no trim.
MacOS version aside(?), it would appear the primary difference between our setup is that I have trimforce enabled.