AB-Com PULSe 4K SE. Crazy offer only £99! FREE UK DELIVERY!
Superb quality and spec AB-Com PULSe 4K SE. Crazy offer! Only £99! FREE UK DELIVERY! 4K UHD, Enigma 2, Multiboot 4 images & more!...
AB-Com PULSe 4k Rev II Twin tuner only £149! FREE UK DELIVERY!
Superb quality and spec AB-Com PULSe 4K Rev II Twin Satellite tuner only £149! FREE UK DELIVERY! 4K UHD, Enigma 2, SATA HDD facility, Multiboot 4 images & more!...

[SF8008] Small issue with fstrim on my internal SSD - It doesn't work

For me... I will download the new version of the PY file and use it. It can do no harm to have it running and may do a lot of good right?

el bandido - is the file available now as a package if I run
opkg update && opkg install fstrim-cron

or do I need to install again the origianl IPK in post #41 and then overwrite the py file with the latest py file in post #60?

Many thanks
Paul
 
Attached is an Updated .ipk plugin when installed does 2 things. (1) Immediately runs TRIM and outputs to: /var/log/fstrim.log. (2) sets a cron job to repeat this process every Sunday at 2 AM.

Install it and forget about it. Maybe check the log once a month or whenever to see that it is running? We are supposed to have log rotation built in to keep from having fstrim.log files greater than 1MB in size.

A person could get fancier with the plugin and create a user screen that displays the log and provides a way to set the cron and or disable - enable the cron. Anyone is welcome to use or improve the script(s) as it is Open Source. It can be easily unpacked using "ar x fstrim-cron_1.0-r12_all.ipk".



Indexing builds a map of where things are so they can be found faster. It's about read performance, knowing the location of content.

TRIM builds a map of where things are not so the drive can prepare those locations for future writes. It's about write performance, knowing which cells are available to erase in advance.

Defragmentation is another maintenance operation that tells the drive something about the state of its free space. Defragmentation or Defrag moves data around to consolidate free space into contiguous blocks. This process changes the layout.

TRIM Does Not change the layout nor does it increase or decrease space. TRIM just communicates "these blocks are empty" without moving anything. It's purely informational.

The best plain-English description is probably: TRIM is housekeeping. The filesystem deleted some files and told the OS those blocks are free, but never bothered to tell the drive. The drive still thinks those cells contain valid data and works around them. TRIM is the note you leave the drive saying "those rooms are vacant now, you can clean them out whenever you're ready."

The P310's Garbage Collector could be compared to the housekeeping staff of a Hotel. TRIM is the checkout notification that lets them know which rooms to service. Without it they're guessing.

What is attached is functional and should work. But it has only been tested on a grand total of 2 SF8008 receivers.
 

Attachments

Admins. Is this a function that should/could be incorporated into the standard build of openVIX? Looks like el bandido has done a good deal of work on this and it is of use to anyone with an SSD - which is possibly quite a few users.

Thanks
Paul
 
@el bandido - thanks for the utility. I installed it just now on my AX61HD which has an internal SSD. It seems to think it's a removable device! I'll have a look at the mount options.


Code: 
2026-03-10 17:49:07 fstrim-all: starting
2026-03-10 17:49:07 fstrim-all: skipping /media/hdd (sda) -- removable device
2026-03-10 17:49:08 fstrim-all: done
 
Still having issues:

Code: 
root@ax61:/# ext4trim.py /dev/sda1

ext4trim.py - Safe filesystem-aware TRIM for USB-bridged NVMe (SF8008)
Reads ext4 block bitmaps to find FREE blocks only, then sends SCSI UNMAP
commands for those ranges via sg_unmap. Data blocks are never touched.
Compatible with Python 3.6+.

Usage:
    ext4trim.py [--dry-run] [--verbose] <partition> <device>

Examples:
    ext4trim.py /dev/sdd1 /dev/sdd
    ext4trim.py --dry-run /dev/sdd1 /dev/sdd
    ext4trim.py --dry-run --verbose /dev/sdd1 /dev/sdd

Options:
    --dry-run   Analyse free blocks and log what WOULD be trimmed, no UNMAP sent
    --verbose   Show each free extent found during bitmap scan

When I run it manually as ext4trim.py it just displays as above and does nothing.

edit! - I've tried /dev/sda also, and the mount point /media.hdd. which works with the standard fstrim command.
 
Last edited:
Let's see if it can be repaired or made to work on something besides a SF8008
Try the attached Joe. Some adjustments to drive recognition have been made.
 

Attachments

Ah yes - that seems to have done it. Looks like the results from my normal fstrim

Code: 
2026-03-10 21:08:26 fstrim-all: starting
2026-03-10 21:08:26 fstrim: /media/hdd: 105926656 bytes trimmed
2026-03-10 21:08:26 fstrim-all: done

The number is a bit odd, though! My results from a regular fstrim:

Code: 
root@ax61:/# fstrim -v /media/hdd
/media/hdd: 980975497216 bytes trimmed


edit - Maybe the different number is because the trims were done at different times??? Both fstrim command and fstrim-all script are reporting zero bytes trimmed at the moment.
 
Last edited:
Joe, You have: an ax61hd with a SATA SSD, not an SF8008 with a JMicron USB bridge?
The ext4trim: lines only appear when ext4trim.py is called — and that only happens on the SF8008 path when discard_granularity=0 and the JMicron UAS bridge is detected.

On the ax61hd:
discard_granularity &gt; 0 — kernel discard works natively
fstrim-all takes the standard path and calls fstrim -v /media/hdd directly
Done in one second, three lines in the log

The verbose ext4trim: output with device info, bitmap scanning, progress groups, and summary is SF8008 only. SATA receivers will always produce the short three-line log. Two completely different code paths, two completely different log formats, both are correct.
 
@el bandido - yes, my AX61HD has a SATA SSD. I had checked through the lines in the script and had seen that there was a different path for standard SSD motherboard connections and fstrim was being called. I hadn't initially realised that the ext4trim.py was specific to USB bridge type connections. My AX61 will continue to use your script for the time being. The /var/log directory is volatile, though, isn't it? Won't survive a reboot or deep standby?
On my Vu+ I have just added a cron fstrim job to run each Monday with logging to /home/root/logs which will persist until I next do a flash.
 
Joe, your observations and points are valid. The logs will disappear on a reboot. We can change the location of the logs to fix that as it would take about 5 minutes to do. The question is do you want logs being written to a permanent location or simply leave it like it is? And are there any other changes or additions worthy of making?
 
Popping a line or two into the standard system log would be good for me as you then just have the one place to check everything.
 
Yes - the standard logfile might be an appropriate place for the messages. @el bandido - I'm not using your script on my Vu+ as the standard fstrim command is working for me and I have set up a cron job there. For SF008 users your script will handle their SSDs nicely. I think I saw a commit from @twol porting over the OpenATV trim code, so I'm not sure if it will handle all cases. He'll probably post here in any case.
 
fstrim has now been added as an automatically run script in /etc/cron.weekly as fstrim and will be in the next image.
This mean that the system will run this script every Sunday at midnight on devices that support trim.

System executable scripts like this do not appear in Menu/Cron timers.
 

Attachments

  • Screenshot from 2026-03-19 10-39-20.webp
    Screenshot from 2026-03-19 10-39-20.webp
    60.6 KB · Views: 3
twol said:
fstrim has now been added as an automatically run script in /etc/cron.weekly as fstrim and will be in the next image.
This mean that the system will run this script every Sunday at midnight on devices that support trim.

System executable scripts like this do not appear in Menu/Cron timers.
Click to expand...
Hi Twol, Is that the standard fstrim or el bandidi's enhanced offering for all SSD's including the NVME==>USB thing in the sf8008?

Thanks
Paul
 
smipx said:
Hi Twol, Is that the standard fstrim or el bandidi's enhanced offering for all SSD's including the NVME==>USB thing in the sf8008?

Thanks
Paul
Click to expand...
that is the standard trim used initially by OpenATV and is simple compared to el bandido's but sufficient for most SSD's used as HDD .
 
twol said:
that is the standard trim used initially by OpenATV and is simple compared to el bandido's but sufficient for most SSD's used as HDD .
Click to expand...
OK - good to know and not a fix for my original issue.

I wonder how many people who purchased SSD's for their shiny new sf8008 V3 Supreme will be aware that it will not be trimmed though. This is a thread in the "sf8008". And it was initiated by me who has one of the said SSD's like potentially hundreds of other customers who recently got the sf8008.
 
maybe it could be added to the plugin feeds? with an apprpriate description. not for myself obviously as i know about it but for others??
 
smipx said:
maybe it could be added to the plugin feeds? with an apprpriate description. not for myself obviously as i know about it but for others??
Click to expand...
i will look at it over the next week.
 
You must log in or register to reply here.

OpenViX Feeds Status

Back
Top