Thanks,
@chrcoluk ! That's a great summary of the current state of things. I just learned some new commands, too.
I'm using an Intel DC S3520 (or rather, according to
smartctl, a:
Code:
Model Family: Dell Certified Intel S3520 Series SSDs
Device Model: SSDSC2BB120G7R
TRIM Command: Available, deterministic, zeroed
SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
SATA 3.1 does include queued TRIM, but it's not included on every drive, so here's how I checked it using the above commands.
Looking up the kernel-reported TRIM support is a bit confusing if you haven't done it before, as it's based on the disk's PCIe path. At least, I was confused.
- Start by getting the logical device name (e.g.,
/dev/sda in my case) from, e.g., lsblk.
- Find the disk's PCIe path:
ls /dev/disk/by-path -al | grep -i "sda"
- That will get you a scary device list.
Bash:
root@pisces1:/sys/class/ata_device# ls /dev/disk/by-path -al | grep -i "sda"
lrwxrwxrwx 1 root root 9 Sep 21 13:57 pci-0000:00:17.0-ata-3 -> ../../sda
lrwxrwxrwx 1 root root 9 Sep 21 13:57 pci-0000:00:17.0-ata-3.0 -> ../../sda
lrwxrwxrwx 1 root root 10 Sep 21 13:57 pci-0000:00:17.0-ata-3.0-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 Sep 21 13:57 pci-0000:00:17.0-ata-3.0-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 Sep 21 13:57 pci-0000:00:17.0-ata-3.0-part3 -> ../../sda3
lrwxrwxrwx 1 root root 10 Sep 21 13:57 pci-0000:00:17.0-ata-3-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 Sep 21 13:57 pci-0000:00:17.0-ata-3-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 Sep 21 13:57 pci-0000:00:17.0-ata-3-part3 -> ../../sda3
- Be glad you don't have to know why it's like that. I don't know why it's like that.
- Print the kernel's queued TRIM support:
# cat /sys/class/ata_device/dev3.0/trim
Mine outputs
unqueued , which isn't the answer I wanted, but, alas.
That's not quite the end of the story.
PVE/ZFS uses cron to perform scheduled, manual TRIMs, as we've discussed.
Bash:
/etc/cron.d# cat zfsutils-linux
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# TRIM the first Sunday of every month.
24 0 1-7 * * root if [ $(date +\%w) -eq 0 ] && [ -x /usr/lib/zfs-linux/trim ]; then /usr/lib/zfs-linux/trim; fi
# Scrub the second Sunday of every month.
24 0 8-14 * * root if [ $(date +\%w) -eq 0 ] && [ -x /usr/lib/zfs-linux/scrub ]; then /usr/lib/zfs-linux/scrub; fi
If you'd like to see when that's happening, to which drives, try:
Bash:
root@pisces1:/etc/cron.d# zpool status -t
pool: pisces1VirtStore
state: ONLINE
scan: scrub repaired 0B in 00:00:06 with 0 errors on Sun Sep 13 00:24:07 2026
config:
NAME STATE READ WRITE CKSUM
pisces1VirtStore ONLINE 0 0 0
nvme-Samsung_SSD_970_EVO_Plus_1TB_S6S1NS0T805122H ONLINE 0 0 0 (100% trimmed, completed at Sun Sep 6 00:24:09 2026)
root@pisces1:/etc/cron.d# zpool status -t rpool
pool: rpool
state: ONLINE
scan: scrub repaired 0B in 00:00:31 with 0 errors on Sun Sep 13 00:24:32 2026
config:
NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
ata-SSDSC2BB120G7R_PHDV809404DJ150MGN-part3 ONLINE 0 0 0 (untrimmed)
Well, the NVME that I keep my guests on is TRIM'ing on a schedule,, at least.
But, my SATA SSD isn't getting trimmed at all, presumably because it doesn't supported queued TRIM operations (?).
I was hoping it would still manually TRIM.
However, it has no issues with a manual TRIM, which it completes in about 5-10 seconds. You can watch it go in real time with
zfs trim $pool && watch zpool status -t $pool
Diff:
Every 2.0s: zpool status -t pisces1: Wed Sep 23 20:05:18 2026
pool: pisces1VirtStore
state: ONLINE
scan: scrub repaired 0B in 00:00:06 with 0 errors on Sun Sep 13 00:24:07 2026
config:
NAME STATE READ WRITE CKSUM
pisces1VirtStore ONLINE 0 0 0
nvme-Samsung_SSD_970_EVO_Plus_1TB_S6S1NS0T805122H ONLINE 0 0 0 (100% trimmed, completed at Sun Sep 6 00:24:09 2026)
errors: No known data errors
pool: rpool
state: ONLINE
scan: scrub repaired 0B in 00:00:31 with 0 errors on Sun Sep 13 00:24:32 2026
config:
NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
ata-SSDSC2BB120G7R_PHDV809404DJ150MGN-part3 ONLINE 0 0 0 (100% trimmed, completed at Wed Sep 23 20:04:10 2026)
errors: No known data errors
Does anyone know why the ZFS cron job doesn't pick up this SSD? I assumed the ZFS cron'd TRIM would still catch it even if it doesn't support queued TRIM.
I might end up enabling zfs autotrim on this pool. It's my boot device and guests don't live on it. I don't like the idea of never TRIMing the drive at all, and its I/O is pretty low as it is. What do y'all think?
