Tutorial [Scripts][2025-12-01] SSD TRIM, IPSet-based Firewall & Tunnel Director, IPv6 Enhancements, WG Port Forwarder, and more

[kuchkovsky]

Thanks for the update! Just tried out the new ssd_trim.sh script... sadly, it failed to see my Samsung SSD which is running inside a JMicron drive enclosure:

ViktorJp@GT-AX6000-3C88:/jffs/scripts/ssd# sh ssd_trim.sh
ssd_trim: Scanning /proc/mounts for USB-backed filesystems under /tmp/mnt
ssd_trim: Skipping drive=/dev/sda (marked non-SSD) for label=ASUS-SSD mount=/tmp/mnt/ASUS-SSD part=/dev/sda1 fs=ext4 vendor_id=152d vendor_name=JMicron
ssd_trim: No suitable USB-backed mountpoints detected under /tmp/mnt; nothing to trim. Supported filesystems: ext2, ext3, ext4

Is there still a way to force it to assume that this vendor_id is a legit SSD?

Interesting, maybe some enclosures incorrectly report that they are rotational drives. Can you try rerunning the script with this check removed?

asuswrt-merlin-scripts/jffs/scripts/ssd/ssd_trim.sh at 0263feb06a1de1d8a6e469353efba448e45c6f62 · kuchkovsky/asuswrt-merlin-scripts

Contribute to kuchkovsky/asuswrt-merlin-scripts development by creating an account on GitHub.

github.com

If it works fine, I will remove this check completely. It’s not really required.

 

[Viktor Jaep]

Interesting, maybe some enclosures incorrectly report that they are rotational drives. Can you try rerunning the script with this check removed?

asuswrt-merlin-scripts/jffs/scripts/ssd/ssd_trim.sh at 0263feb06a1de1d8a6e469353efba448e45c6f62 · kuchkovsky/asuswrt-merlin-scripts

Contribute to kuchkovsky/asuswrt-merlin-scripts development by creating an account on GitHub.

github.com

If it works fine, I will remove this check completely. It’s not really required.

Thanks for the help! Yep, that worked fine:

ViktorJp@GT-AX6000-3C88:/jffs/scripts/ssd# sh ssd_trim.sh
ssd_trim: Scanning /proc/mounts for USB-backed filesystems under /tmp/mnt
ssd_trim: Detected SSD candidate: label=ASUS-SSD mount=/tmp/mnt/ASUS-SSD part=/dev/sda1 fs=ext4 vendor_id=152d vendor_name=JMicron
ssd_trim: Running fstrim on /tmp/mnt/ASUS-SSD...
ssd_trim: fstrim succeeded: /tmp/mnt/ASUS-SSD: 238916677632 bytes trimmed
ssd_trim: Successfully trimmed all selected SSD mountpoints

Changes made:

            # Build rich context (we'll reuse it for all checks)
            context="label=${label} mount=${m} part=${dev} fs=${fstype} vendor_id=${vid}"
            [ -n "$manufacturer" ] && context="${context} vendor_name=${manufacturer}"

            # 2) Rotational check (skip HDDs / "rotational" devices)
 #           if ! disk_passes_rotational_check "$disk_name" "$context"; then
 #               continue
 #           fi

            # 3) Filesystem support check (TRIM only on ext2/ext3/ext4)
            if ! filesystem_supports_trim "$dev" "$fstype" "$context"; then
                continue
            fi

 

[kuchkovsky]

Thanks for the help! Yep, that worked fine

Thanks for the feedback. I've merged the fix. The script will now immediately skip the disk only in cases of an unsupported filesystem.

 

[Viktor Jaep]

Thanks for the feedback. I've merged the fix. The script will now immediately skip the disk only in cases of an unsupported filesystem.

Happy to help. Quick question... What would happen now in a situation where a rotational harddrive is being used if this check was removed? Will it fail elsewhere trying to run fstrim on that?

 

[kuchkovsky]

Happy to help. Quick question... What would happen now in a situation where a rotational harddrive is being used if this check was removed? Will it fail elsewhere trying to run fstrim on that?

It will try to trim the drive, fail, mark it in nvram as disabled (by generating a unique drive ID), and skip it during all subsequent runs.

kuchkovsky@rt:/tmp/home/root# /jffs/scripts/ssd/ssd_trim.sh
ssd_trim: Scanning /proc/mounts for USB-backed filesystems under /tmp/mnt
ssd_trim: Detected SSD candidate: label=st5 mount=/tmp/mnt/st5 part=/dev/sda1 fs=ext4 vendor_id=04e8 vendor_name=Samsung
ssd_trim: Running fstrim on /tmp/mnt/st5...
ssd_trim: fstrim succeeded: /tmp/mnt/st5: 1319407616 bytes trimmed
ssd_trim: Detected SSD candidate: label=sdb1 mount=/tmp/mnt/sdb1 part=/dev/sdb1 fs=ext4 vendor_id=1058 vendor_name=Western Digital
ssd_trim: Set 'unmap' (was 'full') -> /sys/block/sdb/device/scsi_disk/1:0:0:0/provisioning_mode
ssd_trim: Running fstrim on /tmp/mnt/sdb1...
ssd_trim: ERROR: fstrim failed on /tmp/mnt/sdb1: Remote I/O error
ssd_trim: WARNING: No usable write_same_max_bytes for /dev/sdb; disabling TRIM (nvram ssd_trim_1058_25a3_3256474458584150_discard_max_bytes=0)
kuchkovsky@rt:/tmp/home/root# /jffs/scripts/ssd/ssd_trim.sh
ssd_trim: Scanning /proc/mounts for USB-backed filesystems under /tmp/mnt
ssd_trim: Detected SSD candidate: label=st5 mount=/tmp/mnt/st5 part=/dev/sda1 fs=ext4 vendor_id=04e8 vendor_name=Samsung
ssd_trim: Running fstrim on /tmp/mnt/st5...
ssd_trim: fstrim succeeded: /tmp/mnt/st5: 0 bytes trimmed
ssd_trim: Skipping drive=/dev/sdb (disabled via nvram: ssd_trim_1058_25a3_3256474458584150_discard_max_bytes=0) for label=sdb1 mount=/tmp/mnt/sdb1 part=/dev/sdb1 fs=ext4 vendor_id=1058 vendor_name=Western Digital
ssd_trim: No SSD mountpoints required trimming

This behavior corresponds to the new script strategy of attempting to trim all possible devices and permanently excluding those that fail during the trim process even after trying a smaller discard_max_bytes value. You can also exclude specific devices in advance by specifying their labels in config.sh.

 

[Viktor Jaep]

It will try to trim the drive, fail, mark it in nvram as disabled (by generating a unique drive ID), and skip it during all subsequent runs.

kuchkovsky@rt:/tmp/home/root# /jffs/scripts/ssd/ssd_trim.sh
ssd_trim: Scanning /proc/mounts for USB-backed filesystems under /tmp/mnt
ssd_trim: Detected SSD candidate: label=st5 mount=/tmp/mnt/st5 part=/dev/sda1 fs=ext4 vendor_id=04e8 vendor_name=Samsung
ssd_trim: Running fstrim on /tmp/mnt/st5...
ssd_trim: fstrim succeeded: /tmp/mnt/st5: 1319407616 bytes trimmed
ssd_trim: Detected SSD candidate: label=sdb1 mount=/tmp/mnt/sdb1 part=/dev/sdb1 fs=ext4 vendor_id=1058 vendor_name=Western Digital
ssd_trim: Set 'unmap' (was 'full') -> /sys/block/sdb/device/scsi_disk/1:0:0:0/provisioning_mode
ssd_trim: Running fstrim on /tmp/mnt/sdb1...
ssd_trim: ERROR: fstrim failed on /tmp/mnt/sdb1: Remote I/O error
ssd_trim: WARNING: No usable write_same_max_bytes for /dev/sdb; disabling TRIM (nvram ssd_trim_1058_25a3_3256474458584150_discard_max_bytes=0)
kuchkovsky@rt:/tmp/home/root# /jffs/scripts/ssd/ssd_trim.sh
ssd_trim: Scanning /proc/mounts for USB-backed filesystems under /tmp/mnt
ssd_trim: Detected SSD candidate: label=st5 mount=/tmp/mnt/st5 part=/dev/sda1 fs=ext4 vendor_id=04e8 vendor_name=Samsung
ssd_trim: Running fstrim on /tmp/mnt/st5...
ssd_trim: fstrim succeeded: /tmp/mnt/st5: 0 bytes trimmed
ssd_trim: Skipping drive=/dev/sdb (disabled via nvram: ssd_trim_1058_25a3_3256474458584150_discard_max_bytes=0) for label=sdb1 mount=/tmp/mnt/sdb1 part=/dev/sdb1 fs=ext4 vendor_id=1058 vendor_name=Western Digital
ssd_trim: No SSD mountpoints required trimming

This behavior corresponds to the new script strategy of attempting to trim all possible devices and permanently excluding those that fail during the trim process even after trying a smaller discard_max_bytes value. You can also exclude specific devices in advance by specifying their labels in config.sh.

Excellent work!!

 

[XIII]

@XIII could you please try the updated version of the SSD TRIM script with your drive? It should now automatically tune the discard_max_bytes value and remember it for subsequent runs.

I created my own super simplified version based on your previous version and no longer run yours...

(but will still look into your changes to see what I can learn this time)

 

[kuchkovsky]

(but will still look into your changes to see what I can learn this time)

Would be nice if you could run the script to check that it's working correctly on the first try on your side. Theoretically, it should detect and apply the fix on the first run, and then reuse it on subsequent runs. This way, it trims the device properly without any additional configuration.

 

[XIII]

My unmap script has already written 33550336 to /sys/block/"${drive}"/queue/discard_max_bytes.

What would I need to do to "reset" this to properly test your new script?

(I probably keep using my scripts; one has a hardcoded vendor ID and the other this "magic number" 33550336, but the unmap script is then only 3 lines and the trim only 1 line; both +1 line for the shebang)

Also, what should I do after testing (I don't know when I can do this; depends on the answer to the question above) to restore the previous state? (You save data in NVRAM that should be deleted?)