Tutorial [Script Collection][2025-08-29] IPSet-based Firewall & Tunnel Director, WireGuard Port Forwarder, SSD Trimming, and more

[XIII]

I have other values:

➜ cat /sys/block/sda/queue/discard_max_bytes

4294966784

➜ cat /sys/block/sda/queue/discard_granularity

4096

 

[kuchkovsky]

File systemp is ext4:
/dev/sda1 ext4 57431276 2203612 52280544 4% /tmp/mnt/SSD

cat /sys/block/sda/queue/discard_max_bytes
0
cat /sys/block/sda/queue/discard_granularity
0

The empty values for the queue mean that UNMAP was not properly applied to the device, even though the mode is set by the unmap script. I think it's either the enclosure or the SSD that isn't supported. I'll probably add an explicit error message for such cases to the script by checking these values.

What's odd is that it shows up as "VLI Manufacturer String" - it's just a generic name from the controller. The vendor should have given a specific name to the device to make it recognizable. What brand is your enclosure/SSD?

I have other values:

➜ cat /sys/block/sda/queue/discard_max_bytes

4294966784

➜ cat /sys/block/sda/queue/discard_granularity

4096

Your drive reports proper values. What file system are you using? ext4?

I tested TRIM on my second drive formatted as NTFS, and it didn't work (which was expected), but the error message was different:

ssd_trim: ERROR: fstrim: FITRIM: Inappropriate ioctl for device

 

[XIII]

What file system are you using? ext4?

Yes:

➜ mount | grep ssd
/dev/sda1 on /tmp/mnt/ssd type ext4 (rw,nodev,relatime)

 

[XIII]

Does this help determining whether TRIM is supported?

➜ lsblk -D /dev/sda1
NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda1        0        4K       4G         0

According to the link below a value greater than zero for DISC-MAX would mean that TRIM might be enabled?

Enabling TRIM on an external SSD on a Raspberry Pi | Jeff Geerling

www.jeffgeerling.com

 

[kuchkovsky]

According to the link below a value greater than zero for DISC-MAX would mean that TRIM might be enabled?

This is the same as reading discard_max_bytes directly from /sys/block, which we have already done.

Your case is quite interesting. The provisioning mode is successfully set to unmap, and you have discard_max_bytes > 0, but fstrim fails with FITRIM: Remote I/O error, which is different from FITRIM: Operation not supported. Basically, that means the discard command reaches the device, but the device or bridge fails while executing it. This looks like a buggy USB bridge (or firmware) that claims unmap but doesn't handle it correctly.

@hervon's case is different - the error message and discard_max_bytes = 0 simply indicate that TRIM is not supported.

@XIII I have one more idea for you to check - try trimming just 1 MB:

fstrim -v -o 4096 -l $((1024*1024)) /tmp/mnt/ssd

 

[XIII]

I have one more idea for you to check - try trimming just 1 MB:

fstrim -v -o 4096 -l $((1024*1024)) /tmp/mnt/ssd

Result:

➜ fstrim -v -o 4096 -l $((1024*1024)) /tmp/mnt/ssd
/tmp/mnt/ssd: 0 bytes trimmed

 

[XIII]

TRIM initially did not work for the same HW combo on my Raspberry Pi 4 B either, but using these instructions I got it to work on that platform:

Enabling TRIM on an external SSD on a Raspberry Pi | Jeff Geerling

www.jeffgeerling.com

Do we have similar tools for our ASUS routers?

 

[kuchkovsky]

TRIM initially did not work for the same HW combo on my Raspberry Pi 4 B either, but using these instructions I got it to work on that platform:

Enabling TRIM on an external SSD on a Raspberry Pi | Jeff Geerling

www.jeffgeerling.com

Do we have similar tools for our ASUS routers?

What did you change to make it start working? Did you modify discard_max_bytes to a custom value? Based on the output of the fstrim command set to 1 MB, TRIM reaches your disk, but it probably doesn’t know the correct number of bytes (the default may be wrong) and fails.

Otherwise, the logic of my script is basically the same. It changes the provisioning mode and runs fstrim, similar to the "Enabling TRIM" section in the tutorial.

 

[Milan]

How to set up the SSD trim for multiple drives?
And when all scripts are uploaded to the router, they are all enabled on next reboot?

 

[XIII]

What did you change to make it start working? Did you modify discard_max_bytes to a custom value?

I first had to change the provisioning mode from full to unmap, but I indeed also had to modify discard_max_bytes to a non-default value. I had to set discard_max_bytes to a multiple of discard_granularity, as Tom suggested in the comments. Using a corrected version of his script, the value for my HW combo apparently is 33550336, but I don't know how to try/set it on the router as well.

 

[kuchkovsky]

How to set up the SSD trim for multiple drives?

Duplicate this pre-mount block per device for unmap, specifying a different per-drive SSD_VOLUME_LABEL each time:

asuswrt-merlin-scripts/jffs/scripts/pre-mount at main · kuchkovsky/asuswrt-merlin-scripts

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

github.com

For example:

SSD_VOLUME_LABEL_1='ssd1'
SSD_VOLUME_LABEL_1='ssd2' 

if tune2fs -l "$1" 2>/dev/null |
    grep -q "Filesystem volume name: *$SSD_VOLUME_LABEL_1$";
then
    /jffs/scripts/ssd/ssd_unmap.sh # specify your Vendor ID here
fi

if tune2fs -l "$1" 2>/dev/null |
    grep -q "Filesystem volume name: *$SSD_VOLUME_LABEL_2$";
then
    /jffs/scripts/ssd/ssd_unmap.sh # specify your Vendor ID here
fi

Then add new lines to services-start per every device:

asuswrt-merlin-scripts/jffs/scripts/services-start at main · kuchkovsky/asuswrt-merlin-scripts

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

github.com

cru a trim_ssd_1           "0 4 * * 0 /jffs/scripts/ssd/ssd_trim.sh ssd1"
cru a trim_ssd_2           "0 4 * * 0 /jffs/scripts/ssd/ssd_trim.sh ssd2"

These changes will be enabled on the next reboot, yes.

I will add easier automated handling for multiple devices in the next version of the script, but for now you can make these changes. It will work fine.

 

[kuchkovsky]

I first had to change the provisioning mode from full to unmap, but I indeed also had to modify discard_max_bytes to a non-default value. I had to set discard_max_bytes to a multiple of discard_granularity, as Tom suggested in the comments. Using a corrected version of his script, the value for my HW combo apparently is 33550336, but I don't know how to try/set it on the router as well.

Simply add these lines to your ssd_unmap.sh:

echo <YOUR_VALUE> > /sys/block/sda/queue/discard_max_bytes
echo <YOUR_VALUE> > /sys/block/sda/queue/discard_granularity

Keep in mind that sda is not guaranteed if you have multiple USB devices attached, in that case you need to figure it out dynamically.

Try running these commands manually first and then running the trim script. It should work fine if these values are identical to the ones on your Raspberry.

If it works, can you please compare the custom values for both parameters that you set on your Raspberry Pi and the default values detected on Merlin, and post them here? If there's a clear algorithm for how to update them, I can implement the automatic correction in the next version of the script, along with easier handling of multiple disks.

 

[XIII]

Only needed to change /sys/block/sda/queue/discard_max_bytes and now it seems to work?!

➜ echo 33550336 > /sys/block/sda/queue/discard_max_bytes

➜ ./ssd_trim.sh ssd
ssd_trim: Running fstrim on /tmp/mnt/ssd...
ssd_trim: /opt/sbin/fstrim succeeded: /tmp/mnt/ssd: 243424014336 bytes trimmed

➜ ./ssd_trim.sh ssd
ssd_trim: Running fstrim on /tmp/mnt/ssd...
ssd_trim: /opt/sbin/fstrim succeeded: /tmp/mnt/ssd: 0 bytes trimmed