On 28/11/25 01:57, George N. White III wrote:
On Wed, Nov 26, 2025 at 9:16 AM <[email protected] 
<mailto:[email protected]>> wrote:

    On 25/11/25 17:13, [email protected] <mailto:[email protected]> 
wrote:
     > Short story:
     >      $ sudo debugfs -R "ncheck 23666852" /dev/md127
     > fails with
     >      /dev/md127: Block bitmap checksum does not match bitmap while 
reading allocation bitmaps
     >      ncheck: Filesystem not open
     > even after a (clean) fsck. 23666852 is a known good inode.
     >      $ ls -li /data1/tmp/zzz
     >      23666852 -rw-rw-r-- 1 eyal eyal 544 Aug 12  2020 /data1/tmp/zzz
     > Same issue with other inodes.

    Update:

    Running  this (-n = Disables metadata checksum verification) does work:

    $ sudo debugfs -n -R "ncheck 23666852" /dev/md127
    debugfs 1.47.2 (1-Jan-2025)
    Inode   Pathname
    23666852        /tmp/zzz

    The result is correct.

    After more testing I did the original failing run (without '-n') and it 
does not fail anymore!

    $ sudo debugfs -R "ncheck 23666852" /dev/md127
    debugfs 1.47.2 (1-Jan-2025)
    Inode   Pathname
    23666852        /tmp/zzz
    [...]
    Should I relax now? Why did this happen in the first place?


We are in a peak solar activity period.  I used to work with SGI systems that
had ECC memory and would see errors being corrected during peak solar activity.
It is possible that the error reports were due to bits flipped in RAM, so data 
on RAID
may be OK.  I would look for anomalies in processing done when the errors 
occurred.

Thanks George,

Possibly, however it survived a reboot, so the problem was on a disk. Maybe 
started in RAM.
As for the source...

May be unrelated, but only a few days ago I had another disk error (in this fs, 
Pending Sectors)
that magically disappeared after surviving a few days and two reboots.
This debugfs kept failing for two more days after that issue was "resolved".

We live in interesting times.

Regards,
        Eyal

--
George N. White III
--
Eyal at Home ([email protected])
--
_______________________________________________
users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to