TRIM on USB External SSD Supported Now?

[macphoto861]

I know it's been long established that MacOS does not support TRIM for USB-connected SSDs. However, in searching for information about this, I came across this post:

Is it possible to manually TRIM the unused blocks (free space) for an existing APFS volume?

When migrating a MacBook from HDD to SSD, I did a block-level copy using dd. I believe for optimal flash lifetime and performance, it would be the best to issue a TRIM for every unused block in the...

apple.stackexchange.com

It mentions running a command to show "spaceman" entries in the log, which is apparently APFS's way of running TRIM on startup. When I do this, I find:

(My MBP's internal SSD is disk3)


However, I also see the following:

So, there are also these "trim" operations taking place for disk7 and disk9, which are external USB SSDs. Does this mean Apple now supports TRIM for these SSDs, or am I completely misunderstanding these log entries?

 

[Basic75]

That would be good news, can anybody confirm?

 

[Basic75]

So, there are also these "trim" operations taking place for disk7 and disk9, which are external USB SSDs. Does this mean Apple now supports TRIM for these SSDs, or am I completely misunderstanding these log entries?

Have you checked the System Report to see whether TRIM is enabled?

 

[macphoto861]

Have you checked the System Report to see whether TRIM is enabled?

System Report doesn't indicate that TRIM is enabled for these drives, but then again it doesn't seem to even indicate anymore that the built-in SSD has TRIM enabled either – was this line removed from System Report on Monterey perhaps?

 

[Mike Boreham]

System Report doesn't indicate that TRIM is enabled for these drives, but then again it doesn't seem to even indicate anymore that the built-in SSD has TRIM enabled either – was this line removed from System Report on Monterey perhaps?

Not removed but hard to find, below for my Apple internal, and a 2TB NVMe External connected by TB. Can't see any mention of TRIM on two USB SSDs also connected.

 

[mick2]

I know it's been long established that MacOS does not support TRIM for USB-connected SSDs. However, in searching for information about this, I came across this post:

Is it possible to manually TRIM the unused blocks (free space) for an existing APFS volume?

When migrating a MacBook from HDD to SSD, I did a block-level copy using dd. I believe for optimal flash lifetime and performance, it would be the best to issue a TRIM for every unused block in the...

apple.stackexchange.com

It mentions running a command to show "spaceman" entries in the log, which is apparently APFS's way of running TRIM on startup. When I do this, I find:

View attachment 1906756

(My MBP's internal SSD is disk3)


However, I also see the following:

View attachment 1906758

So, there are also these "trim" operations taking place for disk7 and disk9, which are external USB SSDs. Does this mean Apple now supports TRIM for these SSDs, or am I completely misunderstanding these log entries?

Well spotted, and can confirm similar results on an external APFS formatted Samsung T5. It does appear that this is indeed TRIM taking place. Also interesting to note that I don't see these messages with an external Crucial X8 drive when it's formatted as exFAT (exFAT doesnt support TRIM).

Looks like Macos now does support trim on suitably formatted external SSD drives.

 

[macphoto861]

Not removed but hard to find, below for my Apple internal, and a 2TB NVMe External connected by TB. Can't see any mention of TRIM on two USB SSDs also connected.

Ah yes, thanks, I see it now. So I wonder what those log entries mean? Either I'm completely misinterpreting them and they have nothing to do with what we consider to be TRIM, or Apple has quietly implemented TRIM (or, if not the official TRIM command, a TRIM-like feature, maybe that only occurs on startup).

 

[Basic75]

Well spotted, and can confirm similar results on an external APFS formatted Samsung T5. It does appear that this is indeed TRIM taking place. Also interesting to note that I don't see these messages with an external Crucial X8 drive when it's formatted as exFAT (exFAT doesnt support TRIM).

Looks like Macos now does support trim on suitably formatted external SSD drives.

Can you find any indication for TRIM, or, as it's called on UASP, Unmap, being enabled on the T5 in the output of ioreg or ioreg -l in the Terminal?

 

[mick2]

Can you find any indication for TRIM, or, as it's called on UASP, Unmap, being enabled on the T5 in the output of ioreg or ioreg -l in the Terminal?

nada. No mention of trim/unmap from ioreg. Nor is there any mention of it for the internal SSD either.

However, after connecting my T5 I get the following in my log:

2021-11-26 20:42:47.813020+0000 0x45564    Default     0x0                  0      0    kernel: (apfs) spaceman_scan_free_blocks:3155: disk5 91304513 blocks free in 445 extents
2021-11-26 20:42:47.813031+0000 0x45564    Default     0x0                  0      0    kernel: (apfs) spaceman_scan_free_blocks:3163: disk5 91304513 blocks trimmed in 445 extents (2944 us/trim, 339 trims/s)

Those 91304513 blocks x 4KiB block size gves me around 348GiB, which is exactly correct for the amount of freespace I have on that drive.

From that, I'm pretty confident that the Trim is taking place despite the lack of evidence from ioreg.

EDIT: I omitted the -l flag when I ran ioreg. When I ran with the flag, ioreg does indeed pickup device(s) with unmap enabled. Its hard to trace the device details that correspond with the unmap references, but I'm working on it. The number of unmap refs picked up by grep when the T5 is connected increases by 3 compared to when the T5 is not connected, so that's a good sign.

 

[mick2]

Got it:

+-o AppleAPFSMedia  <class AppleAPFSMedia, id 0x100023fb9, registered, matched, active, busy 0 (42 ms), retain 11>
    | |   | |                                 | {
    | |   | |                                 |   "Logical Block Size" = 4096
    | |   | |                                 |   "Open" = Yes
    | |   | |                                 |   "Preferred Block Size" = 4096
    | |   | |                                 |   "Writable" = Yes
    | |   | |                                 |   "IOBusyInterest" = "IOCommand is not serializable"
    | |   | |                                 |   "Size" = 499898105856
    | |   | |                                 |   "Content" = "EF57347C-0000-11AA-AA11-003******CAC"
    | |   | |                                 |   "BSD Minor" = 23
    | |   | |                                 |   "Whole" = Yes
    | |   | |                                 |   "IOStorageFeatures" = {"Unmap"=Yes,"UnmapCapable"=Yes}
    | |   | |                                 |   "Removable" = No
    | |   | |                                 |   "EncryptionBlockSize" = 512
    | |   | |                                 |   "UUID" = "E5158732-18BA-4FB7-9A72-214******FF2"
    | |   | |                                 |   "BSD Unit" = 5
    | |   | |                                 |   "BSD Major" = 1
    | |   | |                                 |   "Ejectable" = No
    | |   | |                                 |   "BSD Name" = "disk5"
    | |   | |                                 |   "Physical Block Size" = 4096
    | |   | |                                 |   "IOGeneralInterest" = "IOCommand is not serializable"
    | |   | |                                 |   "Content Hint" = "EF57347C-0000-11AA-AA11-003******CAC"
    | |   | |                                 |   "Leaf" = No
    | |   | |                                 | }

Note the "IOStorageFeatures" = {"Unmap"=Yes,"UnmapCapable"=Yes}.

Have confirmed this is the T5 via its UUID:

Container disk5 E5158732-18BA-4FB7-9A72-214******FF2
    ====================================================
    APFS Container Reference:     disk5
    Size (Capacity Ceiling):      499898105856 B (499.9 GB)
    Capacity In Use By Volumes:   125891461120 B (125.9 GB) (25.2% used)
    Capacity Not Allocated:       374006644736 B (374.0 GB) (74.8% free)
    |
    +-< Physical Store disk4s2 3F49259E-D4F0-442E-A230-537******242
    |   -----------------------------------------------------------
    |   APFS Physical Store Disk:   disk4s2
    |   Size:                       499898105856 B (499.9 GB)
    |
    +-> Volume disk5s1 F307180F-819D-46E1-A1AE-4A0******E98
        ---------------------------------------------------
        APFS Volume Disk (Role):   disk5s1 (No specific role)
        Name:                      CCC Backup (Case-insensitive)
        Mount Point:               /Volumes/CCC Backup
        Capacity Consumed:         125730603008 B (125.7 GB)
        Sealed:                    No
        FileVault:                 Yes (Unlocked)

So, this looks pretty definitive that MacOS now seems to be supporting Trim (unmap) on suitably formatted external USB SSDs.

 

[macphoto861]

So, this looks pretty definitive that MacOS now seems to be supporting Trim (unmap) on suitably formatted external USB SSDs.

Great investigative work... so "unmap" is the USB version of TRIM?

 

[mick2]

Great investigative work... so "unmap" is the USB version of TRIM?

Yes, Trim is actually an ATA command (sata drives, for example, use the ATA command set); unmap is its equivalent for SCSI devices. Most USB-C external SSDs have bridge chips that convert USB protocol into SCSI disk commands, hence the 'unmap' command (as identified by @Basic75 above).

 

[white7561]

Got it:

+-o AppleAPFSMedia  <class AppleAPFSMedia, id 0x100023fb9, registered, matched, active, busy 0 (42 ms), retain 11>
    | |   | |                                 | {
    | |   | |                                 |   "Logical Block Size" = 4096
    | |   | |                                 |   "Open" = Yes
    | |   | |                                 |   "Preferred Block Size" = 4096
    | |   | |                                 |   "Writable" = Yes
    | |   | |                                 |   "IOBusyInterest" = "IOCommand is not serializable"
    | |   | |                                 |   "Size" = 499898105856
    | |   | |                                 |   "Content" = "EF57347C-0000-11AA-AA11-003******CAC"
    | |   | |                                 |   "BSD Minor" = 23
    | |   | |                                 |   "Whole" = Yes
    | |   | |                                 |   "IOStorageFeatures" = {"Unmap"=Yes,"UnmapCapable"=Yes}
    | |   | |                                 |   "Removable" = No
    | |   | |                                 |   "EncryptionBlockSize" = 512
    | |   | |                                 |   "UUID" = "E5158732-18BA-4FB7-9A72-214******FF2"
    | |   | |                                 |   "BSD Unit" = 5
    | |   | |                                 |   "BSD Major" = 1
    | |   | |                                 |   "Ejectable" = No
    | |   | |                                 |   "BSD Name" = "disk5"
    | |   | |                                 |   "Physical Block Size" = 4096
    | |   | |                                 |   "IOGeneralInterest" = "IOCommand is not serializable"
    | |   | |                                 |   "Content Hint" = "EF57347C-0000-11AA-AA11-003******CAC"
    | |   | |                                 |   "Leaf" = No
    | |   | |                                 | }

Note the "IOStorageFeatures" = {"Unmap"=Yes,"UnmapCapable"=Yes}.

Have confirmed this is the T5 via its UUID:

Container disk5 E5158732-18BA-4FB7-9A72-214******FF2
    ====================================================
    APFS Container Reference:     disk5
    Size (Capacity Ceiling):      499898105856 B (499.9 GB)
    Capacity In Use By Volumes:   125891461120 B (125.9 GB) (25.2% used)
    Capacity Not Allocated:       374006644736 B (374.0 GB) (74.8% free)
    |
    +-< Physical Store disk4s2 3F49259E-D4F0-442E-A230-537******242
    |   -----------------------------------------------------------
    |   APFS Physical Store Disk:   disk4s2
    |   Size:                       499898105856 B (499.9 GB)
    |
    +-> Volume disk5s1 F307180F-819D-46E1-A1AE-4A0******E98
        ---------------------------------------------------
        APFS Volume Disk (Role):   disk5s1 (No specific role)
        Name:                      CCC Backup (Case-insensitive)
        Mount Point:               /Volumes/CCC Backup
        Capacity Consumed:         125730603008 B (125.7 GB)
        Sealed:                    No
        FileVault:                 Yes (Unlocked)

So, this looks pretty definitive that MacOS now seems to be supporting Trim (unmap) on suitably formatted external USB SSDs.

Interesting. Does this show up only when the disk utility says that the external drive is Solid State type?

Since for my external NVMe SSD. Disk utility says that it's a solid state while when I'm using a normal SATA enclosure. With both JMS and VL716 chips they all say it's a normal disk even though the sata drive connected is an SSD.

 

[mick2]

Interesting. Does this show up only when the disk utility says that the external drive is Solid State type?

Since for my external NVMe SSD. Disk utility says that it's a solid state while when I'm using a normal SATA enclosure. With both JMS and VL716 chips they all say it's a normal disk even though the sata drive connected is an SSD.

I don't have an enclosure like this to test with. The only enclosure I have is a SATA USB3.1 gen2 that uses an ASM1351 which supports trim and shows as a 'Solid State' type in DU.

As we don't know what logic Apple uses to determine the 'Solid State' property in DU this is possibly an unreliable guide to whether a given enclosure / external SSD supports trim.

Given the above thread, the quickest way to be sure would be to plug in the enclosure/drive, then in Terminal run

log show --predicate "processID == 0" \
  --start "2021-11-27" | grep spaceman

Substitute the date in the code above for the current date. Wait for the list to complete, then look at the most recent events, ie since you plugged your external in. Look for the BSD disk name (eg disk5) of your drive; DU will give you this if you aren't sure. And look for mention of blocks being trimmed, as per my example in post #9.

For trim to work, the bridge chip needs to support trim/unmap, as well as the OS itself and the filesystem in use too. In my experience on Linux, getting all these aligned with a given enclosure can be rather hit & miss, but at least there you can write a udev rule if the OS isn't aware of that chipset; with MacOS we have no such latitude ofc.

hth

 

[white7561]

I don't have an enclosure like this to test with. The only enclosure I have is a SATA USB3.1 gen2 that uses an ASM1351 which supports trim and shows as a 'Solid State' type in DU.

As we don't know what logic Apple uses to determine the 'Solid State' property in DU this is possibly an unreliable guide to whether a given enclosure / external SSD supports trim.

Given the above thread, the quickest way to be sure would be to plug in the enclosure/drive, then in Terminal run

log show --predicate "processID == 0" \
  --start "2021-11-27" | grep spaceman

Substitute the date in the code above for the current date. Wait for the list to complete, then look at the most recent events, ie since you plugged your external in. Look for the BSD disk name (eg disk5) of your drive; DU will give you this if you aren't sure. And look for mention of blocks being trimmed, as per my example in post #9.

For trim to work, the bridge chip needs to support trim/unmap, as well as the OS itself and the filesystem in use too. In my experience on Linux, getting all these aligned with a given enclosure can be rather hit & miss, but at least there you can write a udev rule if the OS isn't aware of that chipset; with MacOS we have no such latitude ofc.

hth

Yep that's the thing . With Linux I can just manually do it for chips like vl716 for example and it'll work just fine. But yeah. I'll check my NVMe enclosure later. It has an ASM2362 chipset which does show as solid state in disk utility. It should do trim with my encrypted apfs partition.

Hopefully when you format or do anything that destroys a partition or more. It trims it too .

 

[mick2]

Yep that's the thing . With Linux I can just manually do it for chips like vl716 for example and it'll work just fine. But yeah. I'll check my NVMe enclosure later. It has an ASM2362 chipset which does show as solid state in disk utility. It should do trim with my encrypted apfs partition.

Hopefully when you format or do anything that destroys a partition or more. It trims it too .

Yes encrypted apfs should work with trim.
From the logs, it seems that MacOS runs trim everytime the external SSD is connected, immediately after connection. I think I read somewhere that trim is run on the internal drive at boot, so between them that should be regular enough.

 

[white7561]

Yes encrypted apfs should work with trim.
From the logs, it seems that MacOS runs trim everytime the external SSD is connected, immediately after connection. I think I read somewhere that trim is run on the internal drive at boot, so between them that should be regular enough.

Yep. Explains why sometimes it takes a second for the drive to be accessible after mounting it. It's prob trimming it that's why it's sluggish at the first few seconds

 

[white7561]

I don't have an enclosure like this to test with. The only enclosure I have is a SATA USB3.1 gen2 that uses an ASM1351 which supports trim and shows as a 'Solid State' type in DU.

As we don't know what logic Apple uses to determine the 'Solid State' property in DU this is possibly an unreliable guide to whether a given enclosure / external SSD supports trim.

Given the above thread, the quickest way to be sure would be to plug in the enclosure/drive, then in Terminal run

log show --predicate "processID == 0" \
  --start "2021-11-27" | grep spaceman

Substitute the date in the code above for the current date. Wait for the list to complete, then look at the most recent events, ie since you plugged your external in. Look for the BSD disk name (eg disk5) of your drive; DU will give you this if you aren't sure. And look for mention of blocks being trimmed, as per my example in post #9.

For trim to work, the bridge chip needs to support trim/unmap, as well as the OS itself and the filesystem in use too. In my experience on Linux, getting all these aligned with a given enclosure can be rather hit & miss, but at least there you can write a udev rule if the OS isn't aware of that chipset; with MacOS we have no such latitude ofc.

hth

Here's mine. seems too fast to trim the free space? i mean it's been mounted and unmounted for many times without any data change. so it could be already trimmed or something

2021-11-27 20:52:09.441885+0700 0x101241 Default 0x0 0 0 kernel: (apfs) spaceman_metazone_init:191: disk5 metazone for device 0 of size 2739556 blocks (encrypted: 0-1369778 unencrypted: 1369778-2739556)
2021-11-27 20:52:09.441888+0700 0x101241 Default 0x0 0 0 kernel: (apfs) spaceman_datazone_init:625: disk5 allocation zone on dev 0 for allocations of 1 blocks starting at paddr 56098816
2021-11-27 20:52:09.441889+0700 0x101241 Default 0x0 0 0 kernel: (apfs) spaceman_datazone_init:625: disk5 allocation zone on dev 0 for allocations of 2 blocks starting at paddr 56131584
2021-11-27 20:52:09.441891+0700 0x101241 Default 0x0 0 0 kernel: (apfs) spaceman_datazone_init:625: disk5 allocation zone on dev 0 for allocations of 3 blocks starting at paddr 56164352
2021-11-27 20:52:09.441893+0700 0x101241 Default 0x0 0 0 kernel: (apfs) spaceman_datazone_init:625: disk5 allocation zone on dev 0 for allocations of 4 blocks starting at paddr 56197120
2021-11-27 20:52:09.447708+0700 0x101244 Default 0x0 0 0 kernel: (apfs) spaceman_iterate_free_extents_internal:2760: disk5 nx_unmount detected while processing dev=0 cib=2 out of 61 cibs
2021-11-27 20:52:09.447711+0700 0x101244 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3171: disk5 scan took 0.005802 s (no trims)
2021-11-27 20:52:09.447714+0700 0x101244 Default 0x0 0 0 kernel: (apfs) spaceman_iterate_free_extents_internal:2760: disk5 nx_unmount detected while processing dev=0 cib=0 out of 61 cibs
2021-11-27 20:52:09.447716+0700 0x101244 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3153: disk5 scan took 0.000003 s, trims took 0.000000 s
2021-11-27 20:52:09.447717+0700 0x101244 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3155: disk5 0 blocks free in 0 extents
2021-11-27 20:52:11.696064+0700 0x10126f Default 0x0 0 0 kernel: (apfs) spaceman_metazone_init:191: disk5 metazone for device 0 of size 2739556 blocks (encrypted: 0-1369778 unencrypted: 1369778-2739556)
2021-11-27 20:52:11.696067+0700 0x10126f Default 0x0 0 0 kernel: (apfs) spaceman_datazone_init:625: disk5 allocation zone on dev 0 for allocations of 1 blocks starting at paddr 56098816
2021-11-27 20:52:11.696069+0700 0x10126f Default 0x0 0 0 kernel: (apfs) spaceman_datazone_init:625: disk5 allocation zone on dev 0 for allocations of 2 blocks starting at paddr 56131584
2021-11-27 20:52:11.696071+0700 0x10126f Default 0x0 0 0 kernel: (apfs) spaceman_datazone_init:625: disk5 allocation zone on dev 0 for allocations of 3 blocks starting at paddr 56164352
2021-11-27 20:52:11.696072+0700 0x10126f Default 0x0 0 0 kernel: (apfs) spaceman_datazone_init:625: disk5 allocation zone on dev 0 for allocations of 4 blocks starting at paddr 56197120
2021-11-27 20:52:11.790019+0700 0x101271 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3171: disk5 scan took 0.093921 s (no trims)
2021-11-27 20:52:12.420221+0700 0x101271 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3153: disk5 scan took 0.630195 s, trims took 0.440307 s
2021-11-27 20:52:12.420224+0700 0x101271 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3155: disk5 193369896 blocks free in 940 extents
2021-11-27 20:52:12.420230+0700 0x101271 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3163: disk5 193369896 blocks trimmed in 940 extents (468 us/trim, 2134 trims/s)
2021-11-27 20:52:12.420233+0700 0x101271 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3166: disk5 trim distribution 1:194 2+:159 4+:209 16+:77 64+:63 256+:238

Interestingly ioreg -l says that it's only

"IOStorageFeatures" = {"Unmap"=Yes}

 

[mick2]

Here's mine. seems too fast to trim the free space? i mean it's been mounted and unmounted for many times without any data change. so it could be already trimmed or something

<snip>

My interpretation is that it does a scan at 20:52:09.447716 and finds nothing to trim...my guess is this is the UEFI partition on the disk...then at 20:52:12.420230 it trims the main parition of the drive (193369896 blocks).

The speeds look normal to me; this is only the OS sending the trim data to the SSD controller. The actual trimming of blocks is done in the background by the SSD controller according to its own schedule (drive must obv be powered) and can take minutes / hours. All the OS is concerned about is that the drive reports enough free space to complete writes as requested.

 

[white7561]

My interpretation is that it does a scan at 20:52:09.447716 and finds nothing to trim...my guess is this is the UEFI partition on the disk...then at 20:52:12.420230 it trims the main parition of the drive (193369896 blocks).

The speeds look normal to me; this is only the OS sending the trim data to the SSD controller. The actual trimming of blocks is done in the background by the SSD controller according to its own schedule (drive must obv be powered) and can take minutes / hours. All the OS is concerned about is that the drive reports enough free space to complete writes as requested.

it is kinda weird how its so fast though. since issuing a full on blkdiscard on linux takes awhile. which is the same as trimming the whole drive. and my free space is like 80% so it should've taken more time.

Anyways as i suspected on HFS+ usually when you do a first aid which runs fsck it automatically says trimming free blocks or something like that. we don't see that now with APFS. and it seems like it's running too . i checked on the logs command and yeah it does trim it when you run the fsck/first aid on the partition.

 

[mick2]

it is kinda weird how its so fast though. since issuing a full on blkdiscard on linux takes awhile. which is the same as trimming the whole drive. and my free space is like 80% so it should've taken more time.

You could be seeing the difference between queued and non-queued TRIM. A regular OS trim is sent (on modern OSs at least) as a queued TRIM; ie the OS sends the instructions, the command returns almost immediately, and the SSD controller does the actual processing in its own time.

I don't use blkdiscard and am not particularly familiar with it, but it could well be that it sends a non-queued TRIM (at block rather than FS level), meaning that the drive is locked for i/o until the blkdiscard returns as completed. This would make sense as it's designed as an SSD specific wipe utility, ie 'TRIM my whole SSD and only return when it's completed'.

I'm guessing here but to be sure you'd need to look in more detail into the blkdiscard utility. I know that regular fs.trims on my linux machines typically take from 0.5-5s on sata SSDs, so that's in keeping with the speeds I'm seeing on the M1s with their PCIE4 NVME drives.

 

[white7561]

You could be seeing the difference between queued and non-queued TRIM. A regular OS trim is sent (on modern OSs at least) as a queued TRIM; ie the OS sends the instructions, the command returns almost immediately, and the SSD controller does the actual processing in its own time.

I don't use blkdiscard and am not particularly familiar with it, but it could well be that it sends a non-queued TRIM (at block rather than FS level), meaning that the drive is locked for i/o until the blkdiscard returns as completed. This would make sense as it's designed as an SSD specific wipe utility, ie 'TRIM my whole SSD and only return when it's completed'.

I'm guessing here but to be sure you'd need to look in more detail into the blkdiscard utility. I know that regular fs.trims on my linux machines typically take from 0.5-5s on sata SSDs, so that's in keeping with the speeds I'm seeing on the M1s with their PCIE4 NVME drives.

Yeah it could be that. My data points to compare of systems trimming their FS are from Windows trimming an SSD and my raspberry pi trimming my ext4 partition on SDCard and external SSD drive.

But yeah. The only thing I kinda hate about using NVMe enclosure on Macs is that we can't see the smart data. You can if you use a windows VM though. But yeh on Mac OS you can't. It should work on thunderbolt based enclosure though. So that's good

 

[white7561]

Interesting. it does trim my TM drives. So i do know my TM backup drives enclosure supports UASP since i can see it's connected using UASP on my Mac. And since my drives (2.5inch Seagate with 2TB of capacity) is an SMR drive which supports trimming. It actually trims it. that's actually pretty cool.. I think that's actually one of the reasons why it takes a long time to format the drive back when i got the new MBP 2021.

2021-11-29 06:15:44.686475+0700 0xb7a35 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3153: disk7 scan took 78.020216 s, trims took 73.999477 s
2021-11-29 06:15:44.686481+0700 0xb7a35 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3155: disk7 395446431 blocks free in 3761 extents
2021-11-29 06:15:44.686485+0700 0xb7a35 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3163: disk7 395446431 blocks trimmed in 3761 extents (19675 us/trim, 50 trims/s)
2021-11-29 06:15:44.686495+0700 0xb7a35 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3166: disk7 trim distribution 1:908 2+:382 4+:840 16+:607 64+:435 256+:589

 

[Mike Boreham]

Given the above thread, the quickest way to be sure would be to plug in the enclosure/drive, then in Terminal run

log show --predicate "processID == 0" \
  --start "2021-11-27" | grep spaceman

Just did this with three external USB SSD connected. A Samsung T7 and Crucial X6 had been connected for some time, but I disconnected and reconnected before running the command. The Samsung T5 had not been regularly connected.

The output for the T7 and X6 seems to mention lots of spaceman scans which all end in "no trims". (I assume because no trims were needed). But the T5 had this:

2021-12-26 12:52:12.563503+0000 0x2952d9 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3163: disk12 63869543 blocks trimmed in 116250 extents (1163 us/trim, 859 trims/s)

So I am becoming convinced there is something real here....but puzzled it is receiving so little attention in the Mac world....especially as the link in the OP of this thread is 11 months old.

 

[gilby101]

But the T5 had this:

2021-12-26 12:52:12.563503+0000 0x2952d9 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3163: disk12 63869543 blocks trimmed in 116250 extents (1163 us/trim, 859 trims/s)

I get similar for my two T5s (and the boot SSD). But the disks referred too are all APFS containers - never the physical disk. So my question:

Are you sure (and why) that the log entries refer to SSD TRIMs rather than some trimming (not uppercase) of APFS space?