el bandido
Forum Supporter
- Joined
- Dec 22, 2013
- Messages
- 228
- Reaction score
- 46
- Points
- 28
FWIW:
The SF8008 M.2 slot connects to the
HiSilicon SoC via a JMicron JMS583 USB 3.1 to NVMe bridge chip. The drive appears
to Linux as a USB SCSI device (sdd), not a native NVMe device (nvme0n1). This is
confirmed by the Enigma2 log:
[Harddisk][Init] Device 'sdd' (Internal (SSD) - JMicron (Generic))
physicalDevice: .../f9890000.ehci/usb1/...
The kernel uses the LBPME bit (Logical Block Provisioning Management Enabled) from
the READ CAPACITY(16) SCSI command as its gate for enabling discard support. The JMicron
bridge does NOT set this bit, so the kernel sets discard_granularity=0 and refuses all
discard operations regardless of what the drive itself supports:
sg_readcap -l /dev/sdd
Logical block provisioning: lbpme=0, lbprz=0
This blocks every standard TRIM path — including the OpenATV cron approach.
Everything That Was Tried (and Why Each Failed)
1. Fstrim:
fstrim -v /media/hdd
fstrim: /media/hdd: the discard operation is not supported
Blocked by discard_granularity=0 at kernel level.
2. Provisioning_mode=unmap (sysfs):
echo unmap > /sys/block/sdd/device/scsi_disk/*/provisioning_mode
sh: echo: write error: Invalid argument
Kernel 4.4.35 checks lbpme=0 before allowing the write. Rejected regardless of
VPD page 0xB0 advertising full UNMAP support.
3. Mount -o discard:
Accepted by the kernel but silently dropped at the block layer. No UNMAP commands
reach the drive. Kernel 4.4.35 drops discard commands for USB-attached storage.
4. Udev rule for provisioning_mode:
Same result as #2: The kernel rejects the write before the udev rule can take effect.
5. OpenATV fstrim-cron package:
Their fstrim-all simply runs `fstrim -v "$mnt" 2>/dev/null` on SF8008 this returns
an error to stderr which is suppressed, $out is empty, nothing is logged, nothing is
trimmed. The cron job runs silently every week and does absolutely nothing on this
hardware.
The kernel CANNOT be updated on these receivers.
HiSilicon SoC drivers are proprietary binary blobs tied to kernel 4.4.35. Any
solution must work within that constraint.
What Actually Appears to Work:
The JMicron bridge DOES support SCSI UNMAP commands — this can be verified with:
sg_vpd -p bl /dev/sdd
unlimited: Maximum unmap LBA count blocks
Maximum unmap block descriptor count: 0x3f
The sg_unmap tool from sg3-utils bypasses the kernel block layer entirely and sends
UNMAP commands directly. However and this is critical, you cannot simply unmap
the whole partition as that destroys all data including the filesystem metadata.
You must only unmap blocks that the filesystem has marked as FREE.
Since no standard tool (e2freefrag, debugfs, filefrag) is available on these images
to enumerate free blocks, a Python script was written that reads the ext4 block group
bitmaps directly from the raw partition to identify free block extents, then sends
targeted sg_unmap commands only for those extents.
This is essentially re-implementing what fstrim does internally, but in userspace,
bypassing the kernel's blocked ioctl path.
fstrim-cron_1.0-r10_all.ipk
ext4trim.py: Python 3 script that reads ext4 bitmaps and sends safe UNMAP
commands only for free blocks. Compatible with Python 3.6+.
fstrim-all: Shell wrapper with dual-path logic: uses standard fstrim for SATA
receivers, ext4trim.py for SF8008. Automatically detects which path to use.
fstrim-boot: Init script that checks on every boot whether a weekly trim was
missed (receiver was off on scheduled day) and runs trim if overdue.
Automatic cron setup on install, automatic removal on uninstall.
Confirmed working on:
Octagon SF8008 running TNAP image (OpenViX also confirmed working)
Installation:
More or less for OpenVix 6.8: opkg update && opkg install fstrim-cron
Sample Log Output (SF8008, Crucial P310 1TB)
(fstrim-cron: running initial trim in background -- check /var/log/fstrim.log
root@sf8008:~# )
See: /var/log/fstrim.log
The "drive reclaimed: 0 bytes" is expected on a freshly formatted drive. After normal
recorder use, recordings written and deleted over weeks, this will show actual
reclaimed bytes, which is the metric that demonstrates the trim is genuinely working.
TRIM often fails over USB-to-NVMe enclosures. The
reason it works here is that the SF8008's JMicron bridge runs under the UAS
(USB Attached SCSI) driver rather than the generic usb-storage driver. UAS passes
SCSI commands more directly to the device. Combined with the userspace bitmap approach
that bypasses the kernel's blocked discard ioctl entirely, this makes a safe TRIM possible where the standard tools fail.
The SF8008 has a perfectly capable NVMe drive that can be trimmed. It just needs a smarter approach than fstrim.
Disclaimer:
The attached fstrim solution for SF8008 M.2 has been ran on my receiver. It has not received wide-spread esting.
Addtions, Sutracttions, or Tweaks to the installed files may be needed. Safety and unwanted wping of the dirve have been considered.
Therefore, Use at your own risk!
The SF8008 M.2 slot connects to the
HiSilicon SoC via a JMicron JMS583 USB 3.1 to NVMe bridge chip. The drive appears
to Linux as a USB SCSI device (sdd), not a native NVMe device (nvme0n1). This is
confirmed by the Enigma2 log:
[Harddisk][Init] Device 'sdd' (Internal (SSD) - JMicron (Generic))
physicalDevice: .../f9890000.ehci/usb1/...
The kernel uses the LBPME bit (Logical Block Provisioning Management Enabled) from
the READ CAPACITY(16) SCSI command as its gate for enabling discard support. The JMicron
bridge does NOT set this bit, so the kernel sets discard_granularity=0 and refuses all
discard operations regardless of what the drive itself supports:
sg_readcap -l /dev/sdd
Logical block provisioning: lbpme=0, lbprz=0
This blocks every standard TRIM path — including the OpenATV cron approach.
Everything That Was Tried (and Why Each Failed)
1. Fstrim:
fstrim -v /media/hdd
fstrim: /media/hdd: the discard operation is not supported
Blocked by discard_granularity=0 at kernel level.
2. Provisioning_mode=unmap (sysfs):
echo unmap > /sys/block/sdd/device/scsi_disk/*/provisioning_mode
sh: echo: write error: Invalid argument
Kernel 4.4.35 checks lbpme=0 before allowing the write. Rejected regardless of
VPD page 0xB0 advertising full UNMAP support.
3. Mount -o discard:
Accepted by the kernel but silently dropped at the block layer. No UNMAP commands
reach the drive. Kernel 4.4.35 drops discard commands for USB-attached storage.
4. Udev rule for provisioning_mode:
Same result as #2: The kernel rejects the write before the udev rule can take effect.
5. OpenATV fstrim-cron package:
Their fstrim-all simply runs `fstrim -v "$mnt" 2>/dev/null` on SF8008 this returns
an error to stderr which is suppressed, $out is empty, nothing is logged, nothing is
trimmed. The cron job runs silently every week and does absolutely nothing on this
hardware.
The kernel CANNOT be updated on these receivers.
HiSilicon SoC drivers are proprietary binary blobs tied to kernel 4.4.35. Any
solution must work within that constraint.
What Actually Appears to Work:
The JMicron bridge DOES support SCSI UNMAP commands — this can be verified with:
sg_vpd -p bl /dev/sdd
unlimited: Maximum unmap LBA count blocks
Maximum unmap block descriptor count: 0x3f
The sg_unmap tool from sg3-utils bypasses the kernel block layer entirely and sends
UNMAP commands directly. However and this is critical, you cannot simply unmap
the whole partition as that destroys all data including the filesystem metadata.
You must only unmap blocks that the filesystem has marked as FREE.
Since no standard tool (e2freefrag, debugfs, filefrag) is available on these images
to enumerate free blocks, a Python script was written that reads the ext4 block group
bitmaps directly from the raw partition to identify free block extents, then sends
targeted sg_unmap commands only for those extents.
This is essentially re-implementing what fstrim does internally, but in userspace,
bypassing the kernel's blocked ioctl path.
fstrim-cron_1.0-r10_all.ipk
ext4trim.py: Python 3 script that reads ext4 bitmaps and sends safe UNMAP
commands only for free blocks. Compatible with Python 3.6+.
fstrim-all: Shell wrapper with dual-path logic: uses standard fstrim for SATA
receivers, ext4trim.py for SF8008. Automatically detects which path to use.
fstrim-boot: Init script that checks on every boot whether a weekly trim was
missed (receiver was off on scheduled day) and runs trim if overdue.
Automatic cron setup on install, automatic removal on uninstall.
Confirmed working on:
Octagon SF8008 running TNAP image (OpenViX also confirmed working)
Installation:
More or less for OpenVix 6.8: opkg update && opkg install fstrim-cron
Sample Log Output (SF8008, Crucial P310 1TB)
(fstrim-cron: running initial trim in background -- check /var/log/fstrim.log
root@sf8008:~# )
See: /var/log/fstrim.log
Code:
2026-03-05 11:28:48 fstrim-all: starting
2026-03-05 11:28:49 ext4trim: =======================================================
2026-03-05 11:28:49 ext4trim: device : /dev/sdd (partition: /dev/sdd1)
2026-03-05 11:28:49 ext4trim: size : 915 GiB (983,351,099,392 bytes)
2026-03-05 11:28:49 ext4trim: used : 4 GiB (5,131,632,640 bytes)
2026-03-05 11:28:49 ext4trim: free : 911 GiB (978,202,689,536 bytes)
2026-03-05 11:28:49 ext4trim: =======================================================
2026-03-05 11:28:49 ext4trim: partition start LBA: 40
2026-03-05 11:28:49 ext4trim: ext4: 7453 groups, block_size=4096, total_blocks=244190636 (64-bit)
2026-03-05 11:28:50 ext4trim: filesystem frozen: /media/hdd (FIFREEZE ioctl)
2026-03-05 11:28:50 ext4trim: freeze watchdog armed: 900s timeout
2026-03-05 11:28:50 ext4trim: scanning block bitmaps -- this may take several minutes ...
2026-03-05 11:29:27 ext4trim: scanning group 500/7453 (6%) ...
2026-03-05 11:30:04 ext4trim: scanning group 1000/7453 (13%) ...
2026-03-05 11:30:41 ext4trim: scanning group 1500/7453 (20%) ...
2026-03-05 11:31:18 ext4trim: scanning group 2000/7453 (26%) ...
2026-03-05 11:31:55 ext4trim: scanning group 2500/7453 (33%) ...
2026-03-05 11:32:32 ext4trim: scanning group 3000/7453 (40%) ...
2026-03-05 11:33:09 ext4trim: scanning group 3500/7453 (46%) ...
2026-03-05 11:33:46 ext4trim: scanning group 4000/7453 (53%) ...
2026-03-05 11:34:23 ext4trim: scanning group 4500/7453 (60%) ...
2026-03-05 11:35:00 ext4trim: scanning group 5000/7453 (67%) ...
2026-03-05 11:35:38 ext4trim: scanning group 5500/7453 (73%) ...
2026-03-05 11:36:15 ext4trim: scanning group 6000/7453 (80%) ...
2026-03-05 11:36:52 ext4trim: scanning group 6500/7453 (87%) ...
2026-03-05 11:37:29 ext4trim: scanning group 7000/7453 (93%) ...
2026-03-05 11:38:03 ext4trim: filesystem thawed: /media/hdd (FITHAW ioctl)
2026-03-05 11:38:03 ext4trim: =======================================================
2026-03-05 11:38:03 ext4trim: scan complete in 9m 14s
2026-03-05 11:38:03 ext4trim: free extents found : 8827 (each >= 32KB)
2026-03-05 11:38:03 ext4trim: free space before : 911 GiB (978,202,689,536 bytes)
2026-03-05 11:38:03 ext4trim: free space after : 911 GiB (978,202,689,536 bytes)
2026-03-05 11:38:03 ext4trim: trimmed : 910 GiB (978,117,951,488 bytes)
2026-03-05 11:38:03 ext4trim: drive reclaimed : 0 bytes (drive was already clean)
2026-03-05 11:38:03 ext4trim: =======================================================
2026-03-05 11:38:03 fstrim-all: doneThe "drive reclaimed: 0 bytes" is expected on a freshly formatted drive. After normal
recorder use, recordings written and deleted over weeks, this will show actual
reclaimed bytes, which is the metric that demonstrates the trim is genuinely working.
TRIM often fails over USB-to-NVMe enclosures. The
reason it works here is that the SF8008's JMicron bridge runs under the UAS
(USB Attached SCSI) driver rather than the generic usb-storage driver. UAS passes
SCSI commands more directly to the device. Combined with the userspace bitmap approach
that bypasses the kernel's blocked discard ioctl entirely, this makes a safe TRIM possible where the standard tools fail.
The SF8008 has a perfectly capable NVMe drive that can be trimmed. It just needs a smarter approach than fstrim.
Disclaimer:
The attached fstrim solution for SF8008 M.2 has been ran on my receiver. It has not received wide-spread esting.
Addtions, Sutracttions, or Tweaks to the installed files may be needed. Safety and unwanted wping of the dirve have been considered.
Therefore, Use at your own risk!
