Re: Filesystem errors on armv7 -current
- Reply: bob prohaska : "Re: Filesystem errors on armv7 -current"
- In reply to: bob prohaska : "Re: Filesystem errors on armv7 -current"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Thu, 29 Oct 2026 19:16:55 UTC
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