Re: Filesystem errors on armv7 -current

On Thu, Oct 29, 2026 at 12:16:55PM -0700, Mark Millard wrote:
> On 10/29/26 09:50, bob prohaska wrote:
> 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:

Ascii art snipped 

> > 
> > I'm going to re-run the original diskscan using the Jmicron bridge.
> > Maybe re-seating the SATA connector will change something.
> > 

After putting the offending disk back in the offending enclosure
and re-running a default diskscan, the results have been put at
http://www.zefox.net/~fbsd/rpi2/disktrouble/jmicron+diskscan

The graph looks less noisy, but the max latency is still large.
However, it'x much prettier than the runs taken before disturbing
the SATA connector. Once again, diskscan reports "success", whatever
tha means.

In the meantime, a second Pi, a Pi3 running:
bob@ns2:/usr/local/share/doc/db18 % uname -apKU
FreeBSD ns2.zefox.net 14.4-RELEASE-p6 FreeBSD 14.4-RELEASE-p6 GENERIC arm64 aarch64 1404000 1404000

just reported:
Checking setuid files and devices:
find: /usr/local/share/doc/db18/api_reference: Input/output error

Checking negative group permissions:
find: /usr/local/share/doc/db18/api_reference: Input/output error

however ls reports
bob@ns2:/usr/local/share/doc/db18 % ls -l
total 72
drwxr-xr-x  5 root wheel   512 Feb 25  2024 api_reference
drwxr-xr-x  4 root wheel   512 Feb 25  2024 articles
drwxr-xr-x  3 root wheel   512 Feb 25  2024 collections
drwxr-xr-x  7 root wheel  1024 Feb 25  2024 csharp
drwxr-xr-x  4 root wheel   512 Feb 25  2024 gsg
drwxr-xr-x  4 root wheel   512 Feb 25  2024 gsg_db_rep
drwxr-xr-x  4 root wheel   512 Feb 25  2024 gsg_txn
-rw-r--r--  1 root wheel 10434 Jun  1  2020 index.html
drwxr-xr-x  2 root wheel  5632 Feb 25  2024 installation
drwxr-xr-x  2 root wheel   512 Feb 25  2024 license
drwxr-xr-x  2 root wheel   512 Feb 25  2024 porting
drwxr-xr-x  2 root wheel  6144 Feb 25  2024 programmer_reference
drwxr-xr-x  2 root wheel  6656 Feb 25  2024 upgrading

with no errors. 

The host is a microSD-based binary-only setup that 
hasn't been recently updated, so no recent writes that 
might have gone wrong. It hasn't been physically disturbed
in at least a year.

In the distant past a Pi2 developed boot problems that
were remedied by re-seating the microSD card in the slot.

Taken together, I wonder if both machines might simply
be suffering from "stale" connections. I don't think 
the Pi's designers anticipated multi-year uptimes.  

In the meantime, I let badblocks (the RasPiOS version)
run on the USB hard disk overnight. It generated no
output, which I'm tempted to think means it found no
errors worth reporting. In looking at the FreeBSD man
page for badblocks it appears to be a clone of the 
Linux version, intended for use under Linux filechecking.
Is it even meaningful to use badblocks FreeBSD? 

Thanks for everybody's help and patience!

bob prohaska