Linux EXT4 FS development
 help / color / mirror / Atom feed
From: Baokun Li <libaokun@linux.alibaba.com>
To: linux-ext4@vger.kernel.org
Cc: tytso@mit.edu, adilger.kernel@dilger.ca, jack@suse.cz,
	yi.zhang@huawei.com, ojaswin@linux.ibm.com,
	ritesh.list@gmail.com
Subject: [PATCH e2fsprogs 3/5] e2fsck: flush superblock immediately after orphan cleanup
Date: Tue, 14 Jul 2026 14:31:34 +0800	[thread overview]
Message-ID: <20260714063136.1284287-4-libaokun@linux.alibaba.com> (raw)
In-Reply-To: <20260714063136.1284287-1-libaokun@linux.alibaba.com>

When e2fsck aborts after processing orphan inodes but before the
final superblock flush, the kernel reports "bad orphan inode" errors
on next mount. This happens when e2fsck encounters fatal errors
(e.g., bad_blocks_file open failures) after orphan cleanup completes.

The root cause is a timing issue in release_orphan_inodes(). For each
orphan it rewrites the inode (updating i_dtime from the next-orphan
pointer to a timestamp, and for a delete also clearing the inode bitmap
and freeing blocks) and zeroes s_last_orphan in memory. The inode
writes go through the io cache and may be written back to disk at any
point as the cache fills during later passes, but the superblock update
(s_last_orphan = 0) is only marked dirty and is not written until the
end of the fsck run. If e2fsck aborts in between, the on-disk inode has
already been rewritten while the on-disk superblock still points to it
via the stale s_last_orphan.

When the kernel mounts such a filesystem, it follows the stale
s_last_orphan pointer and finds an inode whose i_dtime field now
contains a timestamp instead of a valid inode number. The kernel
interprets this as an invalid next-orphan pointer and reports the
error.

Fix this by flushing the superblock and bitmaps via ext2fs_flush()
(which also flushes the io cache) right after a successful orphan
cleanup, keeping on-disk state consistent regardless of what happens
later. We only flush on success; if release_orphan_inodes() fails, the
filesystem is already marked as needing a full fsck.

Signed-off-by: Baokun Li <libaokun@linux.alibaba.com>
---
 e2fsck/super.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/e2fsck/super.c b/e2fsck/super.c
index 22af1b72684d..e8e4239fc037 100644
--- a/e2fsck/super.c
+++ b/e2fsck/super.c
@@ -570,6 +570,17 @@ static int release_orphan_inodes(e2fsck_t ctx)
 
 	ext2fs_free_mem(&block_buf);
 	pctx.errcode = e2fsck_write_all_quotas(ctx);
+	if (pctx.errcode)
+		goto err;
+	/*
+	 * Orphan cleanup is a consistency point: force the superblock and
+	 * bitmaps to disk now.  Otherwise a later abnormal exit could leave
+	 * a stale s_last_orphan on disk while the orphan inodes it points to
+	 * have already been written back, which the kernel rejects as a
+	 * "bad orphan inode".  On error, fall through so the caller marks
+	 * the filesystem as needing a full fsck.
+	 */
+	pctx.errcode = ext2fs_flush(fs);
 	if (pctx.errcode)
 		goto err;
 	return 0;
-- 
2.43.7


  parent reply	other threads:[~2026-07-14  6:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-14  6:31 [PATCH e2fsprogs 0/5] fsck: fix stale "bad orphan inode" after fsck runs Baokun Li
2026-07-14  6:31 ` [PATCH e2fsprogs 1/5] fsck: consume -l option instead of passing to e2fsck Baokun Li
2026-07-14  6:31 ` [PATCH e2fsprogs 2/5] fsck: fix -C fd option parsing when fd is a separate argument Baokun Li
2026-07-14  6:31 ` Baokun Li [this message]
2026-07-14  6:31 ` [PATCH e2fsprogs 4/5] tests: add fsck option-parsing regression test Baokun Li
2026-07-14  6:31 ` [PATCH e2fsprogs 5/5] tests: add orphan-cleanup flush " Baokun Li

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=20260714063136.1284287-4-libaokun@linux.alibaba.com \
    --to=libaokun@linux.alibaba.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=ojaswin@linux.ibm.com \
    --cc=ritesh.list@gmail.com \
    --cc=tytso@mit.edu \
    --cc=yi.zhang@huawei.com \
    /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