Re: Filesystem errors on armv7 -current

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.

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

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