Re: Filesystem errors on armv7 -current

On Thu, Oct 22, 2026 at 11:23:35PM -0700, Mark Millard wrote:
> On 10/22/26 19:26, bob prohaska wrote:
> > On Thu, Oct 22, 2026 at 06:40:02PM -0700, Mark Millard wrote:
> >> On 10/22/26 18:03, bob prohaska wrote:
> >>> On Thu, Oct 22, 2026 at 02:45:53PM -0700, Bakul Shah wrote:
> >>>> On Oct 22, 2026, at 6:35 AM, bob prohaska <fbsd@www.zefox.net> wrote:
> >>>>>
> >>>>> On Wed, Oct 21, 2026 at 10:32:07PM -0700, Bakul Shah wrote:
> >>>>>>
> >>>>>> One can buy a cheap inline USB power meter or tester to see
> >>>>>> what sort of voltage/current is in use. Fancier ones such as
> >>>>>> FNIRSI FNB48P that will let you see a realtime graph of
> >>>>>> voltage/current at various sampling rates + you can upload
> >>>>>> this data (+ there is vibe coded s/w to run on linux/mac for
> >>>>>> this as well). Very useful for debugging this sort of
> >>>>>> problems.
> >>>>>
> >>>>> I have chopped a USB cable to bring out the power leads and
> >>>>> connected them to a voltmeter in the past. That would seem
> >>>>> adequate to identify a faulty power supply. I haven't tried
> >>>>> it in this specific case, but  given the absence of messages
> >>>>> from umass other than those at boot, is there any point?
> >>>>
> >>>> The boot umass messages were fine.
> >>>>
> >>>> The problem is you are dealing with potentially marginal
> >>>> devices that may misbehave under load and no guarantee that
> >>>> software or firmware will catch such errors. By default the
> >>>> pi2b  limits total current (across all 4 USB ports) to 600
> >>>> mA.  You can add 'max_usb_current=1' to config.txt to
> >>>> increase it to 1.2A (IIRC) - provided Pi's power supply is
> >>>> capable.  [Some earlier HDD USB disks came up with weird USB
> >>>> cables for plugging into *two* ports to get enough power!]
> >>>>
> >>>> It may be that the problem you're seeing is software related
> >>>> but such USB measurements can clearly eliminate power as an
> >>>> issue.
> >>>
> >>> The disk is not powered by the Pi2, but rather by its own 
> >>> powered hub.  A USB cable plugged into the hub shows 5.15 
> >>> volts on a DVM, an oscilloscope reveals fluctuations down 
> >>> to about 4.86 volts over tens of milliseconds. ISTR the Pi
> >>> should work down to about 4.75 volts, haven't found a number
> >>> for the disk.
> >>>
> >>> Just for fun, I wiggled the DC jack on the powered hub and
> >>> the DC voltage came up to 5.23 volts with about 70 mV P-P
> >>> of roughly 2 kHz hash on the line. Maybe that's the switching
> >>> frequency, I've never made this measurement before.
> >>>
> >>> The machine is still running buildworld, so far without obvious
> >>> errors or faults.
> >>
> >> Failing parts of the disk that are supposed to have directory related
> >> content but that are not being accessed are not going to report those
> >> known errors.
> >>
> >> A more effective test would be something that would read every (most
> >> every?) block of the disk and report any failed-to-read blocks. (I limit
> >> to read only testing to avoid destroying data. Other than if you have
> >> atime updating enabled, find likely would be complaining about read
> >> activity to exclusion as well --but on a subset of the blocks.)
> > 
> > For the moment I'm more concerned about the amount of noise/hash
> > on the power supply lines. A similar measurement on a second Pi2B
> > setup seems to show about an order of magnitude less rubbish. I
> > don't know how much is too much, but the troublesome Pi/hub/disk
> > is quite noticeably worse than the second one tested. The comparison
> > hasn't been done with enough care yet to have much confidence
> > either way, I hope to remedy that situation in the next few days.
> > 
> > If you're suggesting the disk itself might be the culprit, that's
> > something I hadn't considered until just now....hmmmm.
> 
> I've been suggesting that since you supplied a log file that showed
> multiple, distinct find commands getting the same error messages for the
> same files, the messages indicating EIO class errors. The repetition via
> ls then indicating more repeatability and that the disk space for such
> examples happens to be for directory related  information, not data file
> content.
> 
> You also had reported corrupt data file content.
> 
> Warner also suggested such, if I remember right.
> 
> (None of that addresses how the errors got there, just that they are now
> there --and visible as long as you do not delete the files or cause them
> to land in lost+found/ or such.)

To address the "how" issue I've put traces of power supply voltage
from both the troublesome host  and one that seems to work better.
The traces and a readme file are at
http://www.zefox.net/~fbsd/rpi2/disktrouble/

There's a definite difference in waveform, but never having looked
at this sort of data before it's unclear to me if the difference
matters, it's much less than I initially thought. 

Thanks for reading!

bob prohaska