On 10/29/26 09:50, bob prohaska wrote: > On Thu, Oct 29, 2026 at 02:36:22PM +0000, void wrote: >> On Wed, Oct 28, 2026 at 08:09:15AM -0700, bob prohaska wrote: >>> On Wed, Oct 28, 2026 at 04:11:02AM +0000, void wrote: >>>> On Wed, Oct 21, 2026 at 11:33:06AM -0700, bob prohaska wrote: >>>> [filesystem errors] >>>> >>>> Have you tried making an nfs server on a more powerful box >>>> and exporting /usr/src ports obj and optionally ccache to your rpi2b? >>>> >>>> I have a setup like this and it works well. >>>> -- >>> >>> I haven't, simply because I'd like to understand what went wrong, >>> to the extent of my ability. >>> >>> In the meantime I've added a few files to the repository of errors at >>> http://www.zefox.net/~fbsd/rpi2/disktrouble/ >>> >>> In particular, there are now two diskscan reports taken while accessing >>> the disk via the same powered hub (and hub power supply) that presided >>> over the initial problem. Near as I can tell, the hub does not interfere >>> with the performance of the disk. >> >> The reason I suggested (nfs) was that long ago I had issues with both the >> pi2b & pi3b read/writing to usb in an OS context. >> The breakage becoming particulatly obvious in a read/write of small >> files situation, like git clone. >> > I had reasonable success using git on microSD-based self-hosted > Pi2 and Pi3 systems but it appeared the microSD cards didn't age > very well. They seemed to work until garbage collection started, > and then become unreliable. As "write once" devices they worked. > >> I put it down to the usb2 ports [1] on both boards not really being >> up to this OS task. nfs negates this issue, even though the port is only >> 100Mbit. >> >> The issue is not present on fast media plugged into the usb3 port of >> a pi4. I have not tested something like a git update on the microsd >> but I'd expect the same issues as encountered on the pi2b & pi3b usb, >> because the microsd media isn't designed for fast small reads/writes. >> I'd expect errors. >> >> [1] maybe the boards in general. > > I've long felt that USB is somewhat flaky on FreeBSD, though exactly > where or how I can't begin to guess. USB behavior on RasPiOS is sometimes > surprising too. 8-) > > Just for comparison, I connected the troublesome disk via a Startech > USB3S2SATCB bridge and re-ran diskscan. It took about 10 hours instead > of 9 and the latency graph looks very different: > http://www.zefox.net/~fbsd/rpi2/disktrouble/startech_discscan > That bridge was bought in 2020, IIRC it was usb2. Now the same > item is sold as usb3. It uses an ASMedia bridge chip.
Ignoring the odd latency graph because of mismatched scaling and looking at the data instead . . . http://www.zefox.net/~fbsd/rpi2/disktrouble/hub_diskscan1 vs.: http://www.zefox.net/~fbsd/rpi2/disktrouble/startech_discscan look rather similar: Disk scan |======================================================| ETA:10h50m58s . . . 2.233 0.000000 1 1.00 2.451 0.100000 1533297 1.11 2.491 0.200000 3293949 1.25 2.503 0.300000 4775281 1.43 2.517 0.400000 6138449 1.67 2.531 0.500000 7762924 2.00 . . . 2.543 0.600000 9322321 2.50 . . . 2.555 0.700000 10696040 3.33 . . . 2.579 0.800000 12279122 5.00 . . . 2.683 0.900000 13737446 10.00 . . . 4.231 0.999316 15251534 1462.86 4.519 0.999414 15253025 1706.67 5.215 0.999512 15254509 2048.00 6.427 0.999561 15255255 2275.56 8.703 0.999609 15256004 2560.00 11.007 0.999658 15256746 2925.71 . . . 1329.151 1.000000 15261960 16777216.00 1329.151 1.000000 15261960 inf #[Mean = 2.552, StdDeviation = 1.444] #[Max = 1329.151, Total count = 15261960] #[Buckets = 16, SubBuckets = 2048] vs. Disk scan |======================================================| ETA:10h55m38s . . . 2.259 0.000000 1 1.00 2.483 0.100000 1553722 1.11 2.503 0.200000 3103798 1.25 2.521 0.300000 4625732 1.43 2.535 0.400000 6330687 1.67 2.545 0.500000 7896138 2.00 . . . 2.555 0.600000 9354429 2.50 . . . 2.565 0.700000 10731515 3.33 . . . 2.581 0.800000 12321897 5.00 . . . 2.673 0.900000 13744362 10.00 . . . 4.843 0.999316 15251544 1462.86 5.195 0.999414 15253019 1706.67 6.351 0.999512 15254507 2048.00 7.707 0.999561 15255255 2275.56 9.407 0.999609 15255998 2560.00 11.319 0.999658 15256744 2925.71 . . . 1328.127 1.000000 15261959 16777216.00 1328.127 1.000000 15261959 inf #[Mean = 2.571, StdDeviation = 1.432] #[Max = 1328.127, Total count = 15261959] #[Buckets = 16, SubBuckets = 2048] In other words, it does not look like the Startech USB3S2SATCB bridge would lead to different conclusions: The bridge is not likely to be the specific source of the specific problem. > > In particular, the "latency" axis on the left has substntially larger > values. There also a single gap in the data with no variation in value. > Can't tell if that's real or a plotting error. The copy/paste to the > web page faithfully represents the original ascii art. The plot should be of the presented data. Thus, the scaling diffrence should not have happened . . . Latency graph: 1470 | | | ^ | | ^ 1225 | . . . (1329.151 falls in the top range) . . . vs.: Latency graph: 300000 | | | | | 250000 | . . . (1328.127 falls outside the top range) . . . > > I'm going to re-run the original diskscan using the Jmicron bridge. > Maybe re-seating the SATA connector will change something. > > Thanks for writing! > > bob prohaska > > > > -- === Mark Millard marklmi at yahoo.com
