From: Ryusuke Konishi <konishi.ryusuke@gmail.com>
To: Christopher Zimmermann <christopher@gmerlin.de>
Cc: linux-nilfs@vger.kernel.org
Subject: Re: nilfs_readdir: bad page in #
Date: Wed, 5 Nov 2025 00:28:54 +0900 [thread overview]
Message-ID: <CAKFNMonYLKSikthtoGP9z6Loetu0LxrUsGC6vMSAwaCPE6muqQ@mail.gmail.com> (raw)
In-Reply-To: <aQoHEXBY9tusAkQ9@merari.gmerlin.de>
On Tue, Nov 4, 2025 at 11:00 PM Christopher Zimmermann wrote:
>
> On Sat, Oct 18, 2025 at 08:04:28PM +0900, Ryusuke Konishi wrote:
> >On Sat, Oct 18, 2025 at 7:01 AM Christopher Zimmermann wrote:
> >>
> >> Hi,
> >>
> >> this is what I saw today:
> >>
> >> Oct 17 09:44:27 merari.gmerlin.de kernel: NILFS version 2 loaded
> >> Oct 17 09:44:27 merari.gmerlin.de kernel: NILFS (nvme0n1p5): segctord starting. Construction interval = 5 seconds, CP frequency < 30 seconds
> >> Oct 17 09:44:27 merari.gmerlin.de nilfs_cleanerd[715]: start
> >> Oct 17 09:44:27 merari.gmerlin.de nilfs_cleanerd[715]: pause (clean check)
> >> Oct 17 15:05:45 merari.gmerlin.de kernel: NILFS error (device nvme0n1p5): nilfs_readdir: bad page in #235406
> >> Oct 17 15:10:06 merari.gmerlin.de kernel: NILFS error (device nvme0n1p5): nilfs_bmap_lookup_contig: broken bmap (inode number=257)
> >...
> >> Oct 17 15:10:48 merari.gmerlin.de kernel: NILFS error (device nvme0n1p5): nilfs_bmap_lookup_contig: broken bmap (inode number=257)
> >> Oct 17 15:10:49 merari.gmerlin.de nilfs_cleanerd[715]: shutdown
> >> Oct 17 15:10:52 merari.gmerlin.de kernel: NILFS (nvme0n1p5): disposed unprocessed dirty file(s) when detaching log writer
> >>
> >> [reboot]
> >>
> >> Oct 17 15:11:09 merari.gmerlin.de kernel: NILFS version 2 loaded
> >> Oct 17 15:11:09 merari.gmerlin.de kernel: NILFS (nvme0n1p5): mounting unchecked fs
> >> Oct 17 15:11:09 merari.gmerlin.de kernel: NILFS (nvme0n1p5): recovery complete
> >> Oct 17 15:11:09 merari.gmerlin.de kernel: NILFS (nvme0n1p5): segctord starting. Construction interval = 5 seconds, CP frequency < 30 seconds
> >> Oct 17 15:11:09 merari.gmerlin.de kernel: NILFS (nvme0n1p5): mounting fs with errors
> >> Oct 17 15:11:09 merari.gmerlin.de nilfs_cleanerd[704]: start
> >> Oct 17 15:11:09 merari.gmerlin.de nilfs_cleanerd[704]: pause (clean check)
> >> Oct 17 15:51:11 merari.gmerlin.de kernel: NILFS error (device nvme0n1p5): nilfs_readdir: bad page in #488967
> >> Oct 17 15:53:04 merari.gmerlin.de kernel: NILFS error (device nvme0n1p5): nilfs_bmap_lookup_contig: broken bmap (inode number=258)
> >...
> >> Oct 17 15:53:04 merari.gmerlin.de kernel: NILFS error (device nvme0n1p5): nilfs_bmap_lookup_contig: broken bmap (inode number=258)
> >> Oct 17 15:53:19 merari.gmerlin.de kernel: NILFS error (device nvme0n1p5): nilfs_bmap_lookup_contig: broken bmap (inode number=258)
> >> Oct 17 15:53:20 merari.gmerlin.de nilfs_cleanerd[704]: shutdown
> >> Oct 17 15:53:20 merari.gmerlin.de kernel: NILFS (nvme0n1p5): disposed unprocessed dirty file(s) when detaching log writer
> >>
> >> [reboot]
> >>
> >> Oct 17 15:53:39 merari.gmerlin.de kernel: NILFS version 2 loaded
> >> Oct 17 15:53:39 merari.gmerlin.de kernel: NILFS (nvme0n1p5): mounting unchecked fs
> >> Oct 17 15:53:39 merari.gmerlin.de kernel: NILFS (nvme0n1p5): recovery complete
> >> Oct 17 15:53:39 merari.gmerlin.de kernel: NILFS (nvme0n1p5): segctord starting. Construction interval = 5 seconds, CP frequency < 30 seconds
> >> Oct 17 15:53:39 merari.gmerlin.de kernel: NILFS (nvme0n1p5): mounting fs with errors
> >> Oct 17 15:53:39 merari.gmerlin.de nilfs_cleanerd[717]: start
> >> Oct 17 15:53:39 merari.gmerlin.de nilfs_cleanerd[717]: pause (clean
> >> check)
> >>
> >> Both, inode 257 and inode 258 were ~/.xsession-errors.old
> >>
> >> What to think of "mounting fs with errors"?
> >> Especially since there is no fsck?
> >
> >For reference, I would like to ask under what circumstances did this
> >occur?
>
> It occured running debian trixie kernel 6.12.48+deb13-amd64
>
> /home was on a nilfs2 filesystem:
> /dev/nvme0n1p5 on /home type nilfs2 (rw,noatime,nodiratime,discard)
>
> >If this happens easily, I am concerned that there may be a new regression.
>
> Now I had some weeks without the issue re-occuring. Now it happened
> again (after formatting the fs and restoring from backup a few weeks
> ago) :-(
>
> Nov 04 14:31:01 merari.gmerlin.de kernel: NILFS error (device nvme0n1p5): nilfs_readdir: bad page in #170719
> Nov 04 14:34:07 merari.gmerlin.de kernel: NILFS error (device nvme0n1p5): nilfs_bmap_lookup_contig: broken bmap (inode number=259)
> Nov 04 14:34:07 merari.gmerlin.de kernel: NILFS error (device nvme0n1p5): nilfs_bmap_lookup_contig: broken bmap (inode number=259)
> Nov 04 14:34:07 merari.gmerlin.de kernel: NILFS error (device nvme0n1p5): nilfs_bmap_lookup_contig: broken bmap (inode number=259)
> Nov 04 14:34:07 merari.gmerlin.de kernel: NILFS error (device nvme0n1p5): nilfs_bmap_lookup_contig: broken bmap (inode number=259)
> Nov 04 14:34:07 merari.gmerlin.de kernel: NILFS error (device nvme0n1p5): nilfs_bmap_lookup_contig: broken bmap (inode number=259)
>
> want to take a wild guess which file had inode 259 at the time of the
> error? - ~/.xsession-error again.
>
> >The error message suggests a corrupted btree, which is causing the
> >directory read to fail.
> >
> >I'm also concerned about the problem with .xsession-errors, a file
> >that seems to have a short lifespan and involves rename.
> >
> >For reference, what version of your kernel are you using?
>
> 6.12.48+deb13-amd64
HI Christopher,
I appreciate your feedback despite the frustration caused by the
repeated issues.
It's becoming more likely that what I feared is occurring.
I suspect that an issue (probably a regression) that shouldn't occur
during normal operation has occurred.
6.12 is a well-maintained kernel series, and 6.12.48 is fairly
up-to-date, except for two stable fixes that are unrelated to this
issue.
Therefore, it's likely that this issue can be reproduced even with the
latest mainline kernel.
6.12.48 has backported nearly a dozen stable patches for nilfs2,
including important bug fixes for rename, bmap/btree, and preventing
the reuse of deleted inodes. It's possible that one of these patches
is backfiring.
Based on what's happening with the .xsession-errors file, I guess that
the problem is indeed occurring with files that are renamed or have a
short lifespan.
I'll try to create an environment that reproduces these conditions.
Thanks,
Ryusuke Konishi
next prev parent reply other threads:[~2025-11-04 15:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-17 14:06 nilfs_readdir: bad page in # Christopher Zimmermann
2025-10-18 11:04 ` Ryusuke Konishi
2025-11-04 14:00 ` Christopher Zimmermann
2025-11-04 15:28 ` Ryusuke Konishi [this message]
2025-11-04 16:04 ` Christopher Zimmermann
2025-11-04 16:43 ` Christopher Zimmermann
2025-11-05 15:01 ` Hideki EIRAKU
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAKFNMonYLKSikthtoGP9z6Loetu0LxrUsGC6vMSAwaCPE6muqQ@mail.gmail.com \
--to=konishi.ryusuke@gmail.com \
--cc=christopher@gmerlin.de \
--cc=linux-nilfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).