Re: Filesystem errors on armv7 -current

On Fri, Oct 23, 2026 at 11:23:44AM -0700, Mark Millard wrote:
> On 10/23/26 09:37, bob prohaska wrote:
> > 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/
> 
> Your oscilloscope images are not comparable because they do not use
> basically the same trigger threshold (presuming probing of the same
> signal or one with same nominal values in the signaling standard):
> 
> bad  case's threshold: -88 mV falling edge
> good case's threshold: -12 mV falling edge
> 
> They visibly have significantly different relationships to the displayed
> signal segment in each case.
> 
> The appropriate threshold to use should be able to be basically the same
> for both contexts. As I understand, it should set to be more like the
> nominal mid-edge figure for such for the signaling standard for the
> specific probed signal, not notably tailored to individual signals that
> may be well off from nominal values. (That wording is not biased to a
> relatively constant power line.)
> 
> It is also not clear which actual signal you are probing in each case.
> It does not look like some sort of relatively constant power level in
> either picture. Sampling multiple signals is appropriate, not just power.
> 

It's just the USB positive bus, picked off inside the powered hub.
I ended up watching single traces and selecting two examples that
reasonably representative of the disturbances on the supply rail.
It was necessary to use AC coupling to make the disturbances fit
on-screen, which is why I reported the actual DC level via DVM.
What you're seeing is essentiall snaphosts of noise.  

To my eye the "bad" signal has deeper disturbances,
but the difference isn't all that big, not usually
more than plus or minus 5% of 5V but sometimes close. 

> > 
> > 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
> > 
> > 
> > 
> 
> 
> -- 
> ===
> Mark Millard
> marklmi at yahoo.com
>