From: Jan Kara <jack@suse.cz>
To: Luis Chamberlain <mcgrof@kernel.org>
Cc: Jan Kara <jack@suse.cz>,
brauner@kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca,
linux-ext4@vger.kernel.org, riel@surriel.com, dave@stgolabs.net,
willy@infradead.org, hannes@cmpxchg.org, oliver.sang@intel.com,
david@redhat.com, axboe@kernel.dk, hare@suse.de,
david@fromorbit.com, djwong@kernel.org, ritesh.list@gmail.com,
linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org,
linux-mm@kvack.org, gost.dev@samsung.com, p.raghav@samsung.com,
da.gomez@samsung.com,
syzbot+f3c6fda1297c748a7076@syzkaller.appspotmail.com
Subject: Re: [PATCH v2 1/8] migrate: fix skipping metadata buffer heads on migration
Date: Tue, 15 Apr 2025 18:28:55 +0200 [thread overview]
Message-ID: <mxmnbr6gni2lupljf7pzkhs6f3hynr2lq2nshbgcmzg77jduwk@wn76alaoxjts> (raw)
In-Reply-To: <Z_6Gwl6nowYnsO3w@bombadil.infradead.org>
On Tue 15-04-25 09:18:10, Luis Chamberlain wrote:
> On Thu, Apr 10, 2025 at 02:05:38PM +0200, Jan Kara wrote:
> > On Wed 09-04-25 18:49:38, Luis Chamberlain wrote:
> > > ** Reproduced on vanilla Linux with udelay(2000) **
> > >
> > > Call trace (ENOSPC journal failure):
> > > do_writepages()
> > > → ext4_do_writepages()
> > > → ext4_map_blocks()
> > > → ext4_ext_map_blocks()
> > > → ext4_ext_insert_extent()
> > > → __ext4_handle_dirty_metadata()
> > > → jbd2_journal_dirty_metadata() → ERROR -28 (ENOSPC)
> >
> > Curious. Did you try running e2fsck after the filesystem complained like
> > this? This complains about journal handle not having enough credits for
> > needed metadata update. Either we've lost some update to the journal_head
> > structure (b_modified got accidentally cleared) or some update to extent
> > tree.
>
> Just tried it after pkill fsstress and stopping the test:
>
> root@e1-ext4-2k /var/lib/xfstests # umount /dev/loop5
> root@e1-ext4-2k /var/lib/xfstests # fsck /dev/loop5
> fsck from util-linux 2.41
> e2fsck 1.47.2 (1-Jan-2025)
> /dev/loop5 contains a file system with errors, check forced.
> Pass 1: Checking inodes, blocks, and sizes
> Inode 26 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 129 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 592 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 1095 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 1416 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 1653 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 1929 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 1965 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 2538 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 2765 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 2831 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 2838 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 3595 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 4659 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 5268 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 6400 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 6830 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 8490 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 8555 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 8658 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 8754 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 8996 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 9168 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 9430 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 9468 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 9543 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 9632 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 9746 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 10043 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 10280 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 10623 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 10651 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 10691 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 10708 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 11389 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 11564 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 11578 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 11842 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 11900 extent tree (at level 1) could be shorter. Optimize<y>? yes
> yInode 12721 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 12831 extent tree (at level 1) could be shorter. Optimize<y>? yes
> yInode 13531 extent tree (at level 1) could be shorter. Optimize<y>? yes
> yyyyInode 16580 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 16740 extent tree (at level 1) could be shorter. Optimize<y>? yes
> yInode 17123 extent tree (at level 1) could be shorter. Optimize<y>? yes
> yInode 17192 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 17412 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 17519 extent tree (at level 1) could be shorter. Optimize<y>? yes
> yyInode 18730 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 18974 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 19118 extent tree (at level 1) could be shorter. Optimize<y>? yes
> yyInode 19806 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 19942 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 20303 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 20323 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 21047 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 21919 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 22180 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 22856 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 23462 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 23587 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 23775 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 23916 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 24046 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 24161 extent tree (at level 1) could be shorter. Optimize<y>? yes
> yInode 25576 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 25666 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 25992 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 26404 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 26795 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 26862 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 26868 extent tree (at level 1) could be shorter. Optimize<y>? yes
> yInode 27627 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 27959 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 28014 extent tree (at level 1) could be shorter. Optimize<y>? yes
> yInode 29120 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 29308 extent tree (at level 1) could be shorter. Optimize<y>? yes
> yyyyInode 30673 extent tree (at level 1) could be shorter. Optimize<y>? yes
> yInode 31127 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 31332 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 31547 extent tree (at level 1) could be shorter. Optimize<y>? yes
> yyInode 32727 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 32888 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 33062 extent tree (at level 1) could be shorter. Optimize<y>? yes
> yyyInode 34421 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 34508 extent tree (at level 1) could be shorter. Optimize<y>? yes
> yyyyInode 35996 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 36258 extent tree (at level 1) could be shorter. Optimize<y>? yes
> yyInode 36867 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 37166 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 37171 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 37548 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 37732 extent tree (at level 1) could be shorter. Optimize<y>? yes
> yInode 38028 extent tree (at level 1) could be shorter. Optimize<y>? yes
> Inode 38099 extent tree (at level 1) could be shorter. Optimize<y>? yes
> ....
These are harmless. They are not errors, just opportunities for
optimization of the extent tree e2fsck can make.
> So I tried:
>
> root@e1-ext4-2k /var/lib/xfstests # fsck /dev/loop5 -y 2>&1 > log
> e2fsck 1.47.2 (1-Jan-2025)
> root@e1-ext4-2k /var/lib/xfstests # wc -l log
> 16411 log
Can you share the log please?
> root@e1-ext4-2k /var/lib/xfstests # tail log
>
> Free blocks count wrong for group #609 (62, counted=63).
> Fix? yes
>
> Free blocks count wrong (12289, counted=12293).
> Fix? yes
These could potentially indicate some interesting issues but it depends on
what the above e2fsck messages are...
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2025-04-15 16:29 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-10 1:49 [PATCH v2 0/8] mm: enhance migration work around on noref buffer-heads Luis Chamberlain
2025-04-10 1:49 ` [PATCH v2 1/8] migrate: fix skipping metadata buffer heads on migration Luis Chamberlain
2025-04-10 3:18 ` Matthew Wilcox
2025-04-10 12:05 ` Jan Kara
2025-04-14 21:09 ` Luis Chamberlain
2025-04-14 22:19 ` Luis Chamberlain
2025-04-15 9:05 ` Christian Brauner
2025-04-15 15:47 ` Luis Chamberlain
2025-04-15 16:23 ` Jan Kara
2025-04-15 21:06 ` Luis Chamberlain
2025-04-16 2:02 ` Davidlohr Bueso
2025-04-15 11:17 ` Jan Kara
2025-04-15 11:23 ` Jan Kara
2025-04-15 16:18 ` Luis Chamberlain
2025-04-15 16:28 ` Jan Kara [this message]
2025-04-16 16:58 ` Luis Chamberlain
2025-04-23 17:09 ` Jan Kara
2025-04-23 20:30 ` Luis Chamberlain
2025-04-25 22:51 ` Luis Chamberlain
2025-04-28 23:08 ` Luis Chamberlain
2025-04-29 9:32 ` Jan Kara
2025-04-15 1:36 ` Davidlohr Bueso
2025-04-15 11:25 ` Jan Kara
2025-04-15 18:14 ` Davidlohr Bueso
2025-04-10 1:49 ` [PATCH v2 2/8] fs/buffer: try to use folio lock for pagecache lookups Luis Chamberlain
2025-04-10 14:38 ` Jan Kara
2025-04-10 17:38 ` Davidlohr Bueso
2025-04-10 1:49 ` [PATCH v2 3/8] fs/buffer: introduce __find_get_block_nonatomic() Luis Chamberlain
2025-04-10 1:49 ` [PATCH v2 4/8] fs/ocfs2: use sleeping version of __find_get_block() Luis Chamberlain
2025-04-10 1:49 ` [PATCH v2 5/8] fs/jbd2: " Luis Chamberlain
2025-04-10 1:49 ` [PATCH v2 6/8] fs/ext4: " Luis Chamberlain
2025-04-10 13:36 ` Jan Kara
2025-04-10 17:32 ` Davidlohr Bueso
2025-04-10 1:49 ` [PATCH v2 7/8] mm/migrate: enable noref migration for jbd2 Luis Chamberlain
2025-04-10 13:40 ` Jan Kara
2025-04-10 17:30 ` Davidlohr Bueso
2025-04-14 12:12 ` Jan Kara
2025-04-10 1:49 ` [PATCH v2 8/8] mm: add migration buffer-head debugfs interface Luis Chamberlain
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=mxmnbr6gni2lupljf7pzkhs6f3hynr2lq2nshbgcmzg77jduwk@wn76alaoxjts \
--to=jack@suse.cz \
--cc=adilger.kernel@dilger.ca \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=da.gomez@samsung.com \
--cc=dave@stgolabs.net \
--cc=david@fromorbit.com \
--cc=david@redhat.com \
--cc=djwong@kernel.org \
--cc=gost.dev@samsung.com \
--cc=hannes@cmpxchg.org \
--cc=hare@suse.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mcgrof@kernel.org \
--cc=oliver.sang@intel.com \
--cc=p.raghav@samsung.com \
--cc=riel@surriel.com \
--cc=ritesh.list@gmail.com \
--cc=syzbot+f3c6fda1297c748a7076@syzkaller.appspotmail.com \
--cc=tytso@mit.edu \
--cc=willy@infradead.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