cannot trim: no devices in pool support trim operations on Samsung 870 EVO

[iio7]

Arch Linux 5.16.9-arch1-1 running with ZFS DKMS 2.1.2-2.

I am running with a mirror pool of 2 Samsung 870 EVO 500GB.

NAME                                             STATE     READ WRITE CKSUM
pool2                                            ONLINE       0     0     0
    ata-Samsung_SSD_870_EVO_500GB_S62BNF0R835776Z  ONLINE       0     0     0
    ata-Samsung_SSD_870_EVO_500GB_S6PYNM0RB02979V  ONLINE       0     0     0

errors: No known data errors

From the Samsung website, all Samsung SSD supports TRIM.

# zpool trim pool2
cannot trim: no devices in pool support trim operations

Other than that everything works well. I can enable the autotrim option on the pool, but suspect it isn't working.

[rincebrain]

5.16 remains broken with all released versions. It would not surprise me if this was just one more brokenness.

[mabod]

It is working fine for me with zfs-dkms 2.1.2-2 which is using some patches for 5.16:

# uname -r
5.16.9-arch1-1
                                                                                                                              
Mi 16. Feb 15:26:35 CET 2022
root@rakete://root
# zpool status zM2
  pool: zM2
 state: ONLINE
  scan: scrub repaired 0B in 00:02:31 with 0 errors on Mon Feb 14 08:09:54 2022
config:

	NAME             STATE     READ WRITE CKSUM
	zM2              ONLINE       0     0     0
	  Samsung-500GB  ONLINE       0     0     0  (trimming)
	  Kingston-1TB   ONLINE       0     0     0  (trimming)

errors: No known data errors

This is with a Samsung SSD 970 EVO Plus 500GB and a KINGSTON SA2000M81000G.

Extra 5.16 patches used by zfs-dkms 2.1.2-2:

0002-check-slabh-for-kvmalloc.patch::https://github.com/openzfs/zfs/commit/e86f88aa0b4f4e2784980d6d5c04f397e4839493.patch
0003-added-add_disk-check-for-return.patch::https://github.com/openzfs/zfs/commit/12fa250d84c0a96b95fd0ff70509c43dd8b640a0.patch
0004-added-mapping-for-iov_iter_fault_in_readable.patch::https://github.com/openzfs/zfs/commit/299fbf75ecf302e790908d8098a8cd215125a6b5.patch
0005-add-support-for-falloc_fl_zero_range.patch::https://github.com/openzfs/zfs/commit/4372e96f4b4b21c8e79c0c961589f61b11859e07.patch

[rincebrain]

k.

My other thought would be that I believe Linux relatively recently blacklisted at least some kinds of TRIM for all Samsung SATA SSDs for misbehaving; perhaps see if things that aren't ZFS think they can currently use TRIM on them?

[iio7]

I have just edited my original comment as I am also running with zfs-dkms 2.1.2-2 with the same patches.

$ yay -Ss zfs-dkms
aur/zfs-dkms 2.1.2-2 (+124 1.21) (Installed)

Testing support for TRIM...

# fdisk -l

Disk /dev/sdd: 465.76 GiB, 500107862016 bytes, 976773168 sectors
Disk model: SSD 870 EVO 500G

Disk /dev/sde: 465.76 GiB, 500107862016 bytes, 976773168 sectors
Disk model: SSD 870 EVO 500G

Then with hdparm:

# hdparm -I /dev/sdd | grep TRIM
           *    Data Set Management TRIM supported (limit 8 blocks)
           *    Deterministic read ZEROs after TRIM
# hdparm -I /dev/sde | grep TRIM
           *    Data Set Management TRIM supported (limit 8 blocks)
           *    Deterministic read ZEROs after TRIM

I am tempted to test the pool on FreeBSD, but as I recall FreeBSD is only on ZFS 2.0.

[iio7]

It seems the problem was a local one with the SATA controller.

I had a hunch about the SATA controller on the box, so I moved the pool to another machine also running Arch and zfs-dkms 2.1.2-2 and trimming is working on that on the disks.