Re: Filesystem errors on armv7 -current

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.)

> 
> Thanks for writing,
> 
> bob prohaska
> 
> 
> 


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