Re: Filesystem errors on armv7 -current

On Fri, Oct 23, 2026 at 11:42 AM Mark Millard <marklmi@yahoo.com> 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/
>
> QUOTE
> The "badpower" host seems to experience subtle corruption but not
> outright failures
> END QUOTE
>
> Getting EIO errors is not something that I would call subtle. As I
> understand, EIO indicates that the drive's internal controller reported
> that it could not deal with what is happening. The problem is not just
> some number of bits of user data having the wrong value compared to what
> was originally intended to be written. The problem is an outright error
> as I understand.
>

EIO is complicated. And comes from many sources. And knowing what the exact
details
matters.

EIO might mean that we tried and tried and the drive tried and tried and
that we just
couldn't read the sectors.

It could also mean that the connection to the drive had issues.


> Remember that you have repeatable EIO errors for the same directory
> accesses (as long as to do not change where the directories are stored).
>

I've not seen the CAM messages from these to know if this is a bad spot on
the disk, or if I'm postulating that the power needed to access those
sectors
is too much. But being repeatable biases towards the 'drive wrote the data
in a way it can't read it now' end of the spectrum.

Warner


> >
> > 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.
>
> An interesting test could be swapping which RPi2B is used with which USB
> drive: does the problem stay with the same RPi2B? With the same USB
> drive? (This wording is just suggestive since there are more stages of
> connections (USB and Power) and more swapping of combinations is
> possible than I listed.)
>
> If you can isolate a device/cable/power/??? that the signal noise level
> follows, it might contribute to learning some of what to replace.
>
> >
> > Thanks for reading!
> >
> > bob prohaska
> >
> >
> >
>
>
> --
> ===
> Mark Millard
> marklmi at yahoo.com
>
>