Re: Filesystem errors on armv7 -current

On 10/23/26 11:28, Warner Losh wrote:
> 
> 
> On Fri, Oct 23, 2026 at 11:42 AM Mark Millard <marklmi@yahoo.com
> <mailto: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
>     <mailto: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/ <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.

Thanks for the notes.

> 
> 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 <http://yahoo.com>
> 


-- 
===
Mark Millard
marklmi at yahoo.com