Re: [PATCH] ext4: Fix spurious message about orphan cleanup on RO fs
Tigran Aivazian <[email protected]> Tue, 4 Aug 2026 08:06:57 +0100
| Newsgroups | org.kernel.vger.linux-ext4 |
|---|---|
| Message-ID | <CAK+_RL=VnbYo9LV+exxP4R2UsCjmmn6G3qK5CXiB7e1at+UxqA@mail.gmail.com> |
On Mon, 3 Aug 2026 at 17:01, Jan Kara <[email protected]> wrote: > diff --git a/fs/ext4/orphan.c b/fs/ext4/orphan.c > index 64ea47624233..2a44998a6c2e 100644 > --- a/fs/ext4/orphan.c > +++ b/fs/ext4/orphan.c > @@ -388,7 +388,7 @@ void ext4_orphan_cleanup(struct super_block *sb, struct ext4_super_block *es) > struct ext4_orphan_info *oi = &EXT4_SB(sb)->s_orphan_info; > int inodes_per_ob = ext4_inodes_per_orphan_block(sb); > > - if (!es->s_last_orphan && !oi->of_blocks) { > + if (!es->s_last_orphan && ext4_orphan_file_empty(sb)) { > ext4_debug("no orphan inodes to clean up\n"); > return; > } I have just re-tested my original scenario and confirm what you asserted in the second half of your earlier email: the "remount,ro" step in my testing was indeed irrelevant. We would get the spurious "orphan cleanup on readonly fs" message even with just a normal "umount /mnt" intervening between the rw and ro mounts of the filesystem in question. Therefore, your patch above appears to be the most sensible thing to do in this situation, especially as that code path uses ext4_debug() but the spurious message is using a stronger ext4_msg(sb, KERN_INFO,...). Kind regards, Tigran