SYSTEM ------ $ uname -r 6.18.39+rpt-rpi-2712 $ grep PRETTY /etc/os-release PRETTY_NAME="Debian GNU/Linux 13 (trixie)" umbrelOS 2.0.0-beta.1, upgraded from 1.7.4 on 2026-09-04 Raspberry Pi 5, 8 GB THE FINGERPRINT - kernel logs the bogus value at boot ----------------------------------------------------- $ dmesg | grep -E "Optimal transfer size|Preferred minimum" [ 1.428690] sd 0:0:0:0: [sda] Preferred minimum I/O size 512 bytes [ 1.428693] sd 0:0:0:0: [sda] Optimal transfer size 33553920 bytes 33553920 = 65535 x 512 = 0xFFFF blocks $ cat /sys/block/sda/queue/optimal_io_size 33553920 $ cat /sys/block/sda/queue/read_ahead_kb 65520 (before the fix; 128 after) $ cat /sys/block/sda/queue/nr_requests 60 $ cat /sys/block/sda/queue/max_sectors_kb 512 $ cat /sys/block/sda/device/queue_depth 30 one 64 MiB readahead = 65520/512 = 128 requests vs a 60-deep scheduler queue and a 30-deep device queue HARDWARE - and note there are TWO of them ------------------------------------------ $ lsusb | grep -i asmedia Bus 004 Device 002: ID 174c:235c ASMedia Technology Inc. Ugreen Storage Device ... enclosure replaced 2026-09-07, same drive and cable ... $ lsusb | grep -i asmedia Bus 004 Device 002: ID 174c:55aa ASMedia Technology Inc. ASM1051E/ASM1053E/ ASM1153 SATA 6Gb/s bridge $ cat /sys/bus/usb/devices/4-1/product USB3.0 External HDD $ cat /sys/block/sda/queue/optimal_io_size # on the NEW bridge 33553920 $ cat /sys/block/sda/queue/read_ahead_kb # on the NEW bridge, at boot 65520 Two different ASMedia parts, same drive, same cable, same host, same kernel, identical bogus value. This is a family behaviour, not one defective enclosure. $ cat /sys/block/sda/device/model ATA SSD THE VPD PAGE ITSELF - firmware stuffed 0xffff into every length field ---------------------------------------------------------------------- $ sudo sg_vpd -p bl /dev/sda Block limits VPD page (SBC) Optimal transfer length granularity: 0x1 Maximum transfer length: 0xffff <-- max value of the field Optimal transfer length: 0xffff <-- max value of the field Maximum prefetch length: 0xffff <-- max value of the field Maximum unmap LBA count: 0x3fffc0 Maximum unmap block descriptor count: 0x1 Optimal unmap granularity: 0x1 The fields firmware populates properly (granularity, unmap counts) look sane. The three length fields are all 0xffff. This is an unpopulated page, not a device describing a 32 MiB optimal transfer. TRIM IS SUPPORTED BUT DISABLED ------------------------------ $ sudo sg_vpd -p lbpv /dev/sda LBPU=1 <-- device DOES support UNMAP Provisioning type: not known or fully provisioned $ cat /sys/block/sda/device/scsi_disk/*/provisioning_mode full <-- so the kernel disables discard $ cat /sys/block/sda/queue/discard_max_bytes 0 HEALTH / THROTTLING RULED OUT ----------------------------- rpi_volt in0_lcrit_alarm = 0 no undervoltage thermal_zone0 = 47C, SSD = 40C no thermal throttling cpu0 scaling_cur_freq = 2400000 full clock usb speed = 5000 Mbps, rx/tx_lanes 1 link negotiated correctly SATA Version is: SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s) usb power/control = on usb runtime_suspended_time = 0 drive never autosuspends SECONDARY FINGERPRINT - same bogus value reaches the filesystem --------------------------------------------------------------- $ sudo tune2fs -l /dev/sda7 | grep -iE 'stripe|block size' Block size: 4096 RAID stripe width: 8191 (33553920 / 4096) THE DRIVE IS HEALTHY - this is not a failing SSD ------------------------------------------------- $ sudo smartctl -H /dev/sda SMART overall-health self-assessment test result: PASSED $ sudo smartctl -A /dev/sda | grep -Ei 'realloc|pending|uncorrect|crc|power_on' 5 Reallocated_Sector_Ct ... - 1 9 Power_On_Hours ... - 3940 196 Reallocated_Event_Count ... - 0 197 Current_Pending_Sector ... - 1 198 Offline_Uncorrectable ... - 0 199 UDMA_CRC_Error_Count ... - 0 $ sudo dmesg | grep -ciE 'I/O error|reset (high|super)-?speed|uas_eh' 0 zero I/O errors, zero USB resets since boot $ dmesg | grep -E 'uas|usb-storage|sd 0:' [ 0.382898] usbcore: registered new interface driver uas [ 1.371655] scsi host0: uas [ 1.376563] sd 0:0:0:0: [sda] 4000797360 512-byte logical blocks: (2.05 TB) [ 1.376881] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled [ 1.459528] sd 0:0:0:0: [sda] Attached SCSI disk UAS negotiated, SuperSpeed link, no fallback, no quirks BEFORE - read_ahead_kb 65520 ---------------------------- 2026-09-05T21:15:21Z Loaded best chain: height=961222 progress=0.991339 2026-09-05T21:15:21Z Verifying last 6 blocks at level 3 2026-09-05T21:15:21Z Verification progress: 0% 2026-09-05T21:24:12Z Verification progress: 16% ^ 8 min 51 s to reach 16%. Killed at 17 min, still unfinished. Six blocks. AFTER - read_ahead_kb 128, same six blocks, after a clean reboot ----------------------------------------------------------------- 2026-09-06T20:57:23Z Loaded best chain: height=965829 progress=1.000000 2026-09-06T20:57:23Z Verifying last 6 blocks at level 3 2026-09-06T20:57:23Z Verification progress: 0% 2026-09-06T20:57:26Z Verification progress: 16% 2026-09-06T20:57:26Z Verification progress: 33% 2026-09-06T20:57:26Z Verification progress: 50% 2026-09-06T20:57:27Z Verification progress: 66% 2026-09-06T20:57:27Z Verification progress: 83% 2026-09-06T20:57:27Z Verification progress: 99% 2026-09-06T20:57:28Z init message: Done loading ^ 5 seconds BLOCKS PER DAY - counted from UpdateTip lines in debug.log 2.0 upgrade was 2026-09-04. Readahead fix was 2026-09-05 ~22:50Z. ---------------------------------------------------------------- 2026-08-11 279 2026-08-25 1616 2026-08-12 1115 2026-08-26 666 2026-08-13 1579 2026-08-27 1146 2026-08-14 1136 2026-08-28 1735 2026-08-15 769 2026-08-29 1140 2026-08-16 753 2026-08-30 1378 2026-08-17 1105 2026-08-31 1980 2026-08-18 1943 2026-09-01 1073 2026-08-19 1358 2026-09-02 1690 2026-08-20 1828 2026-09-03 1684 2026-08-21 2187 2026-09-04 759 <-- upgraded to 2.0 2026-08-22 1460 2026-09-05 4230 <-- fix at ~22:50Z 2026-08-23 1376 2026-09-06 1092 <-- reached chain tip 2026-08-24 1625 24 logged days on 1.7.4: mean 1359/day, min 279, max 2187 after the fix: 1374 blocks per HOUR The rate is flat across the version boundary and changes only at the fix. The bug was costing ~24x on 1.7.4 too; it just did not take the dashboard down there, so it never looked like a bug. BOOT TIME AFTER THE FIX ----------------------- $ systemd-analyze Startup finished in 10.169s (kernel) + 14.036s (userspace) = 24.206s graphical.target reached after 14.035s in userspace. ^ was roughly 13 minutes before CONTROLLED A/B - identical background load, 25 s window, only read_ahead_kb differs. Foreground = 4 KiB random reads. ------------------------------------------------------------ RA 65520 RA 128 p50 latency 131.94 ms 7.03 ms p95 latency 619.56 ms 27.59 ms p99 latency 715.97 ms 63.99 ms ops completed in 25s 129 1945 background throughput 89.9 MiB/s 84.1 MiB/s (unchanged)