Re: Filesystem errors on armv7 -current

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.
 
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.

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