From nobody Sun Feb 8 05:47:56 2026 Received: from sender4-pp-f112.zoho.com (sender4-pp-f112.zoho.com [136.143.188.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ECB9A30B53F; Thu, 11 Dec 2025 11:52:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=136.143.188.112 ARC-Seal: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765453943; cv=pass; b=b8a7NpOIr6M2eCqOB+ZTbcGaxpGaNutTYCudJTKIvP4U5SQNyTbnldFhM2D/6psi93LkPFMKbnwYD3le6Nxb43fl/FfXUmKW2t840BVfWLNOXgLVbZCDHxAf1eSZOMdNKh1Ofp3yOZ0TosINh0ylnxx9z/gCBZD9fF/3nChY0ks= ARC-Message-Signature: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765453943; c=relaxed/simple; bh=twfB4plazS4WvJL/P1q8iPRCkN/uIuEiWgcWA3wpIrE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=guQBTb2dt2MIYN3LLWB0ZhcrNvidLK6nn/RJN7oMm5J3hCS++WJKH9bUxTDvo9BRuWOlCY++D4a5flXmLk8p5As8qmhbbnQ+QDz48uASB8QnA1NIiTiV1tJDAlW1JFwM++9OfaCAtNhyPxOq2zP3ujhs02TlpF+lEzQcqRE4qgI= ARC-Authentication-Results: i=2; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux.beauty; spf=pass smtp.mailfrom=linux.beauty; dkim=pass (1024-bit key) header.d=linux.beauty header.i=me@linux.beauty header.b=nqPzH7E4; arc=pass smtp.client-ip=136.143.188.112 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux.beauty Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.beauty Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.beauty header.i=me@linux.beauty header.b="nqPzH7E4" ARC-Seal: i=1; a=rsa-sha256; t=1765453923; cv=none; d=zohomail.com; s=zohoarc; b=KP1MwBEaEK4WrfPAbd16O0p6t7VhzE3bzp9rvA8QFFWqxApwPzfaounG7w2fqu6PWx5SS4oxAI6iqOXDz58ttvy1mY9RmHWp44pgF4LV6MuKykEaNSU8Lf0rZC2afIx2H3KZ59dG6XHQOtoxxDAQHck28QZssj31O/5XRizmfIA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1765453923; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=yaSHHyzU8BiqIAmZkb2Y/Ax90MKyBX6O15rxos4mRPg=; b=h2nY39k7QJVElYEWCzYl47gW0RUNUeRRajfGXpchAkC4peDRdEP3Hgxj8XpFu3svMNA6NZymOpFinEn3WnHLipK8PW3X048WgjK/kwAgjcZnOpALjLnT+6L7tuTKjZ0c2xUsIbdCaJXvBNUwu1Cqajp/WKCHOkKpLcVoK0cR82E= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=linux.beauty; spf=pass smtp.mailfrom=me@linux.beauty; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1765453923; s=zmail; d=linux.beauty; i=me@linux.beauty; h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-ID:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Message-Id:Reply-To; bh=yaSHHyzU8BiqIAmZkb2Y/Ax90MKyBX6O15rxos4mRPg=; b=nqPzH7E4JxYdy2h7CntwpL5pE/ku1ltMdGUpgNHcrRHdlumJqfpgFykyDEXjwL01 207K+CgBECXm5dmgxu3J5k3QNp7OE+9CVhMkRpWBVxF+yij/W5WOsCVSigWA9FEO/PG 8UoMZ3lQp/Uv1Os7Jx6RuUUGpmyY6X+tOTXkn1OM= Received: by mx.zohomail.com with SMTPS id 1765453920624800.3067390930065; Thu, 11 Dec 2025 03:52:00 -0800 (PST) From: Li Chen To: "Theodore Ts'o" , Andreas Dilger , Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org Cc: Li Chen Subject: [RFC 1/5] ext4: mark inode format migration fast-commit ineligible Date: Thu, 11 Dec 2025 19:51:38 +0800 Message-ID: <20251211115146.897420-2-me@linux.beauty> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20251211115146.897420-1-me@linux.beauty> References: <20251211115146.897420-1-me@linux.beauty> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMailClient: External Content-Type: text/plain; charset="utf-8" Fast commits only log operations that have dedicated replay support. Inode format migration (indirect<->extent layout changes via EXT4_IOC_MIGRATE or toggling EXT4_EXTENTS_FL) rewrites the block mapping representation without going through the fast commit tracking paths. In practice these migrations are rare and usually followed by further updates, but mixing them into a fast commit makes the overall semantics harder to reason about and risks replay gaps if new call sites appear. Teach ext4 to mark the filesystem fast-commit ineligible when ext4_ext_migrate() or ext4_ind_migrate() start their journal transactions. This forces those transactions to fall back to a full commit, ensuring that the entire inode layout change is captured by the normal journal rather than partially encoded in fast commit TLVs. This change should not affect common workloads but makes format migrations safer and easier to reason about under fast commit. Testing: 1. prepare: dd if=3D/dev/zero of=3D/root/fc.img bs=3D1M count=3D0 seek=3D128 mkfs.ext4 -O fast_commit -F /root/fc.img mkdir -p /mnt/fc && mount -t ext4 -o loop /root/fc.img /mnt/fc 2. Created a test file and toggled the extents flag to exercise both ext4_ind_migrate() and ext4_ext_migrate(): touch /mnt/fc/migtest chattr -e /mnt/fc/migtest chattr +e /mnt/fc/migtest 3. Verified fast-commit ineligible statistics: tail -n 1 /proc/fs/ext4/loop0/fc_info "Inode format migration": 2 Signed-off-by: Li Chen --- fs/ext4/fast_commit.c | 1 + fs/ext4/fast_commit.h | 1 + fs/ext4/migrate.c | 12 ++++++++++++ include/trace/events/ext4.h | 4 +++- 4 files changed, 17 insertions(+), 1 deletion(-) diff --git a/fs/ext4/fast_commit.c b/fs/ext4/fast_commit.c index fa66b08de999..afb28b3e52bb 100644 --- a/fs/ext4/fast_commit.c +++ b/fs/ext4/fast_commit.c @@ -2302,6 +2302,7 @@ static const char * const fc_ineligible_reasons[] =3D= { [EXT4_FC_REASON_FALLOC_RANGE] =3D "Falloc range op", [EXT4_FC_REASON_INODE_JOURNAL_DATA] =3D "Data journalling", [EXT4_FC_REASON_ENCRYPTED_FILENAME] =3D "Encrypted filename", + [EXT4_FC_REASON_MIGRATE] =3D "Inode format migration", }; =20 int ext4_fc_info_show(struct seq_file *seq, void *v) diff --git a/fs/ext4/fast_commit.h b/fs/ext4/fast_commit.h index 3bd534e4dbbf..be3b84a74c32 100644 --- a/fs/ext4/fast_commit.h +++ b/fs/ext4/fast_commit.h @@ -97,6 +97,7 @@ enum { EXT4_FC_REASON_FALLOC_RANGE, EXT4_FC_REASON_INODE_JOURNAL_DATA, EXT4_FC_REASON_ENCRYPTED_FILENAME, + EXT4_FC_REASON_MIGRATE, EXT4_FC_REASON_MAX }; =20 diff --git a/fs/ext4/migrate.c b/fs/ext4/migrate.c index 1b0dfd963d3f..96ab95167bd6 100644 --- a/fs/ext4/migrate.c +++ b/fs/ext4/migrate.c @@ -449,6 +449,12 @@ int ext4_ext_migrate(struct inode *inode) retval =3D PTR_ERR(handle); goto out_unlock; } + /* + * This operation rewrites the inode's block mapping layout + * (indirect to extents) and is not tracked in the fast commit + * log, so disable fast commits for this transaction. + */ + ext4_fc_mark_ineligible(inode->i_sb, EXT4_FC_REASON_MIGRATE, handle); goal =3D (((inode->i_ino - 1) / EXT4_INODES_PER_GROUP(inode->i_sb)) * EXT4_INODES_PER_GROUP(inode->i_sb)) + 1; owner[0] =3D i_uid_read(inode); @@ -630,6 +636,12 @@ int ext4_ind_migrate(struct inode *inode) ret =3D PTR_ERR(handle); goto out_unlock; } + /* + * This operation rewrites the inode's block mapping layout + * (extents to indirect blocks) and is not tracked in the fast + * commit log, so disable fast commits for this transaction. + */ + ext4_fc_mark_ineligible(inode->i_sb, EXT4_FC_REASON_MIGRATE, handle); =20 down_write(&EXT4_I(inode)->i_data_sem); ret =3D ext4_ext_check_inode(inode); diff --git a/include/trace/events/ext4.h b/include/trace/events/ext4.h index a374e7ea7e57..8f75d41ae5ef 100644 --- a/include/trace/events/ext4.h +++ b/include/trace/events/ext4.h @@ -102,6 +102,7 @@ TRACE_DEFINE_ENUM(EXT4_FC_REASON_RENAME_DIR); TRACE_DEFINE_ENUM(EXT4_FC_REASON_FALLOC_RANGE); TRACE_DEFINE_ENUM(EXT4_FC_REASON_INODE_JOURNAL_DATA); TRACE_DEFINE_ENUM(EXT4_FC_REASON_ENCRYPTED_FILENAME); +TRACE_DEFINE_ENUM(EXT4_FC_REASON_MIGRATE); TRACE_DEFINE_ENUM(EXT4_FC_REASON_MAX); =20 #define show_fc_reason(reason) \ @@ -115,7 +116,8 @@ TRACE_DEFINE_ENUM(EXT4_FC_REASON_MAX); { EXT4_FC_REASON_RENAME_DIR, "RENAME_DIR"}, \ { EXT4_FC_REASON_FALLOC_RANGE, "FALLOC_RANGE"}, \ { EXT4_FC_REASON_INODE_JOURNAL_DATA, "INODE_JOURNAL_DATA"}, \ - { EXT4_FC_REASON_ENCRYPTED_FILENAME, "ENCRYPTED_FILENAME"}) + { EXT4_FC_REASON_ENCRYPTED_FILENAME, "ENCRYPTED_FILENAME"}, \ + { EXT4_FC_REASON_MIGRATE, "MIGRATE"}) =20 TRACE_DEFINE_ENUM(CR_POWER2_ALIGNED); TRACE_DEFINE_ENUM(CR_GOAL_LEN_FAST); --=20 2.51.0 From nobody Sun Feb 8 05:47:56 2026 Received: from sender4-pp-f112.zoho.com (sender4-pp-f112.zoho.com [136.143.188.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1783530BBAB; Thu, 11 Dec 2025 11:52:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=136.143.188.112 ARC-Seal: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765453954; cv=pass; b=Rmfy9SlDrzm+3hytk4KF+yCpSybOoq/MgGdUjWu/KkYAgN41MusyaQMOGempSgDw+oqS+eACxrE+2KjOTFbVB7+E7/8cbqgv4ADOJyecPq4oZad5MYa+EdgzKxD+MjNX12q00pvYlMVyR/K56Iat5qysdXcJ2eLQmiJbnUcRndg= ARC-Message-Signature: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765453954; c=relaxed/simple; bh=85XEeevtOSpwM1Boim97Wf6SCbBneHtUAKXqB2mSzEo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=AlF8mh1hL+Fj/jjfesnQQg9VGvVKgzNBPjva3f9JcwG8YhRSl14YZP6o7euLHm3A2C147aIpdFpcBhbhHLTX33pzzO2sW2QGmDjt8GcVitMBhfH4cIEw3aCtmbi5ve8Bqwc0ZFvhcWFHHi3VYlkazM62oi5ywrRjsW7HnOw23N4= ARC-Authentication-Results: i=2; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux.beauty; spf=pass smtp.mailfrom=linux.beauty; dkim=pass (1024-bit key) header.d=linux.beauty header.i=me@linux.beauty header.b=qijPJXYj; arc=pass smtp.client-ip=136.143.188.112 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux.beauty Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.beauty Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.beauty header.i=me@linux.beauty header.b="qijPJXYj" ARC-Seal: i=1; a=rsa-sha256; t=1765453925; cv=none; d=zohomail.com; s=zohoarc; b=UkwISEmd0rOCt0DRWQKVcutLA4LF6uiFiL1cUsJEhYO6h/RQTneGgjY4MMTdfxZ7Xn+UhQzPs+8TdvIyHyvfOznVaLFCMYba5FRaQgqH5OlUpoaInvVfxVA+17fRuMzOINNj2T6ayW0V2/PJO7rBvB8DtImScozByGz0phZICd8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1765453925; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=ZYsHAtlu0/Nh/4tTe93G6ofE2omOgTDyMODHn/a3bok=; b=mP0qWVkb9HIvz57mbVSeeoYZhhXkBCPOmpuledJliPtpu9aAj/xqbC8DcWGexTuOjOH2ZfyLZkc5udEOb/uyhVowAFm+VfvGCGEhToJ/TYJbeq60kFXuW3/xwUdRmtOPf6mRGhmdKp7ibd+lgbnQ5W0dvb/1cuzv0UiKP2kzC8Q= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=linux.beauty; spf=pass smtp.mailfrom=me@linux.beauty; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1765453925; s=zmail; d=linux.beauty; i=me@linux.beauty; h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-ID:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Message-Id:Reply-To; bh=ZYsHAtlu0/Nh/4tTe93G6ofE2omOgTDyMODHn/a3bok=; b=qijPJXYjd1qq2DPJV/SG6yACjJLRAQx/BWtHPZfLhE6yIlIGG9p0WcVyVVxRxqPU HD+v146RQRcP8NaWSOm+tCcPYJNR/xmpplUmXq//TJSWuBAFpH9f8MPrcWJznLRTByM XPOhwv/C5KLvMDvNv0wz6e5dhoQS0LJQKh/jhbos= Received: by mx.zohomail.com with SMTPS id 1765453923455759.6378657352764; Thu, 11 Dec 2025 03:52:03 -0800 (PST) From: Li Chen To: "Theodore Ts'o" , Andreas Dilger , Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org Cc: Li Chen Subject: [RFC 2/5] ext4: mark fs-verity enable fast-commit ineligible Date: Thu, 11 Dec 2025 19:51:39 +0800 Message-ID: <20251211115146.897420-3-me@linux.beauty> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20251211115146.897420-1-me@linux.beauty> References: <20251211115146.897420-1-me@linux.beauty> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMailClient: External Content-Type: text/plain; charset="utf-8" Fast commits only log operations that have dedicated replay support. Enabling fs-verity builds a Merkle tree and updates inode and orphan state in ways that are not described by the fast commit replay tags. In practice these operations are rare and usually followed by further updates, but mixing them into a fast commit makes the overall semantics harder to reason about and risks replay gaps if new call sites appear. Teach ext4 to mark the filesystem fast-commit ineligible when ext4_end_enable_verity() starts its journal transaction. This forces that transaction to fall back to a full commit, ensuring that the fs-verity enable changes are captured by the normal journal rather than partially encoded in fast commit TLVs. This change should not affect common workloads but makes fs-verity enable safer and easier to reason about under fast commit. Testing: 1. prepare: dd if=3D/dev/zero of=3D/root/fc_verity.img bs=3D1M count=3D0 seek=3D128 mkfs.ext4 -O fast_commit,verity -F /root/fc_verity.img mkdir -p /mnt/fc_verity && mount -t ext4 -o loop /root/fc_verity.img /m= nt/fc_verity 2. Enabled fs-verity on a file and verified reason accounting: echo "data" > /mnt/fc_verity/verityfile /root/enable_verity /mnt/fc_verity/verityfile sync tail -n 1 /proc/fs/ext4/loop0/fc_info "fs-verity enable": 1 3. Enabled fs-verity on a second file, fsynced it, and checked that the ineligible commit counter is updated too: echo "data2" > /mnt/fc_verity/verityfile2 /root/enable_verity /mnt/fc_verity/verityfile2 /root/fsync_file /mnt/fc_verity/verityfile2 sync /proc/fs/ext4/loop0/fc_info shows "fs-verity enable" incremented and fc stats ineligible increased accordingly. Signed-off-by: Li Chen --- fs/ext4/fast_commit.c | 1 + fs/ext4/fast_commit.h | 1 + fs/ext4/verity.c | 2 ++ include/trace/events/ext4.h | 4 +++- 4 files changed, 7 insertions(+), 1 deletion(-) diff --git a/fs/ext4/fast_commit.c b/fs/ext4/fast_commit.c index afb28b3e52bb..242b69e5fe13 100644 --- a/fs/ext4/fast_commit.c +++ b/fs/ext4/fast_commit.c @@ -2303,6 +2303,7 @@ static const char * const fc_ineligible_reasons[] =3D= { [EXT4_FC_REASON_INODE_JOURNAL_DATA] =3D "Data journalling", [EXT4_FC_REASON_ENCRYPTED_FILENAME] =3D "Encrypted filename", [EXT4_FC_REASON_MIGRATE] =3D "Inode format migration", + [EXT4_FC_REASON_VERITY] =3D "fs-verity enable", }; =20 int ext4_fc_info_show(struct seq_file *seq, void *v) diff --git a/fs/ext4/fast_commit.h b/fs/ext4/fast_commit.h index be3b84a74c32..20f65135208f 100644 --- a/fs/ext4/fast_commit.h +++ b/fs/ext4/fast_commit.h @@ -98,6 +98,7 @@ enum { EXT4_FC_REASON_INODE_JOURNAL_DATA, EXT4_FC_REASON_ENCRYPTED_FILENAME, EXT4_FC_REASON_MIGRATE, + EXT4_FC_REASON_VERITY, EXT4_FC_REASON_MAX }; =20 diff --git a/fs/ext4/verity.c b/fs/ext4/verity.c index b0acb0c50313..6115a365d491 100644 --- a/fs/ext4/verity.c +++ b/fs/ext4/verity.c @@ -231,6 +231,8 @@ static int ext4_end_enable_verity(struct file *filp, co= nst void *desc, goto cleanup; } =20 + ext4_fc_mark_ineligible(inode->i_sb, EXT4_FC_REASON_VERITY, handle); + err =3D ext4_orphan_del(handle, inode); if (err) goto stop_and_cleanup; diff --git a/include/trace/events/ext4.h b/include/trace/events/ext4.h index 8f75d41ae5ef..224ab12ee83f 100644 --- a/include/trace/events/ext4.h +++ b/include/trace/events/ext4.h @@ -103,6 +103,7 @@ TRACE_DEFINE_ENUM(EXT4_FC_REASON_FALLOC_RANGE); TRACE_DEFINE_ENUM(EXT4_FC_REASON_INODE_JOURNAL_DATA); TRACE_DEFINE_ENUM(EXT4_FC_REASON_ENCRYPTED_FILENAME); TRACE_DEFINE_ENUM(EXT4_FC_REASON_MIGRATE); +TRACE_DEFINE_ENUM(EXT4_FC_REASON_VERITY); TRACE_DEFINE_ENUM(EXT4_FC_REASON_MAX); =20 #define show_fc_reason(reason) \ @@ -117,7 +118,8 @@ TRACE_DEFINE_ENUM(EXT4_FC_REASON_MAX); { EXT4_FC_REASON_FALLOC_RANGE, "FALLOC_RANGE"}, \ { EXT4_FC_REASON_INODE_JOURNAL_DATA, "INODE_JOURNAL_DATA"}, \ { EXT4_FC_REASON_ENCRYPTED_FILENAME, "ENCRYPTED_FILENAME"}, \ - { EXT4_FC_REASON_MIGRATE, "MIGRATE"}) + { EXT4_FC_REASON_MIGRATE, "MIGRATE"}, \ + { EXT4_FC_REASON_VERITY, "VERITY"}) =20 TRACE_DEFINE_ENUM(CR_POWER2_ALIGNED); TRACE_DEFINE_ENUM(CR_GOAL_LEN_FAST); --=20 2.51.0 From nobody Sun Feb 8 05:47:56 2026 Received: from sender4-pp-f112.zoho.com (sender4-pp-f112.zoho.com [136.143.188.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1530130BB9D; Thu, 11 Dec 2025 11:52:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=136.143.188.112 ARC-Seal: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765453966; cv=pass; b=R/MB5VvVybVUA9r0XzbbbShNTNeUX48p1b57u+KZcn1QHpg5z6iMpdVArcBGhUTxmxuS34FHd0ndohK3F2ydiwEmF9EN7htZWzrLohV81E+ttW+9s47pf0/o7UepK8j03EAsFxwAGJn/aueHpo1bJOnc1bHlOYxvpSXcSi1Vp1o= ARC-Message-Signature: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765453966; c=relaxed/simple; bh=BJiEsVsgBvPe1EE9g+BPKGivio01VW7e5T4FilSbmhs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=YZGO+TGNMp8TyrnrT//5Y+XyhOHvlHGTVwPVRekD/h4DZUUs22bkiqvabPpk0Pty/V/8uANaVW96QAvy/h23s63hVBt6fMAjHR++BaTJ1wvsxiH3tcM5TBePq0sCoCaMONVjAZ9c3WU0VOY6whWd1RN8Nhnb3vKZVnmOfnk2p0M= ARC-Authentication-Results: i=2; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux.beauty; spf=pass smtp.mailfrom=linux.beauty; dkim=pass (1024-bit key) header.d=linux.beauty header.i=me@linux.beauty header.b=Xxz+8Hq+; arc=pass smtp.client-ip=136.143.188.112 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux.beauty Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.beauty Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.beauty header.i=me@linux.beauty header.b="Xxz+8Hq+" ARC-Seal: i=1; a=rsa-sha256; t=1765453929; cv=none; d=zohomail.com; s=zohoarc; b=JiXuc4wIoQbBeRKUf/5k31qEB4lufeQe2cjX5jVyaRW+gixb24Vgd1B3tp2J8vMAXYS/MSlCjz5IrOLdS4wKibMksbHIgiWeNDN6REZOWRTIybvvPNcpk3fgvjnO1Rp5D+kZdyS32J5Vz53/dJckekNzmukPkLBWhuHf5RgWTfA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1765453929; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=ZiAmebCOX2a0l5Lf0sVmmghFrZEljlFpwT9BGvKl8Kw=; b=ZdmDG9JpuaaGmGUMPKYBGBzZtblLQReN1oYtkjmoU4tfT1go6rrX/sjHLANXIc/436l3PeVMAk/sTwpfzGjBwr++cbOL6wpsU2EizhAqYx+HBQU4fle+Iucor5FsszZKsOtEVTxvwA9ZrxAf0Tif4/J8Lo+6b/mng7sD5M6kzHU= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=linux.beauty; spf=pass smtp.mailfrom=me@linux.beauty; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1765453929; s=zmail; d=linux.beauty; i=me@linux.beauty; h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-ID:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Message-Id:Reply-To; bh=ZiAmebCOX2a0l5Lf0sVmmghFrZEljlFpwT9BGvKl8Kw=; b=Xxz+8Hq+zzzUoj/o+k1h2r4fQU1Jm4yDfMcHcXM91zEan14T1tzEAJtfK/yBMqLt YQa4XMVAef72HdIIUZ87iaLnwNqxJiZjCdTo541F8kT68fnDWLuESev6oP3KKTWiQLU MJQhHCPcLwFKPuTfvhYTMEOGHsqcTpQ7TK8u5a9o= Received: by mx.zohomail.com with SMTPS id 176545392704675.76481354032035; Thu, 11 Dec 2025 03:52:07 -0800 (PST) From: Li Chen To: "Theodore Ts'o" , Andreas Dilger , Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org Cc: Li Chen Subject: [RFC 3/5] ext4: mark move extents fast-commit ineligible Date: Thu, 11 Dec 2025 19:51:40 +0800 Message-ID: <20251211115146.897420-4-me@linux.beauty> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20251211115146.897420-1-me@linux.beauty> References: <20251211115146.897420-1-me@linux.beauty> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMailClient: External Content-Type: text/plain; charset="utf-8" Fast commits only log operations that have dedicated replay support. EXT4_IOC_MOVE_EXT swaps extents between regular files and may copy data, rewriting the affected inodes' block mapping layout without going through the fast commit tracking paths. In practice these operations are rare and usually followed by further updates, but mixing them into a fast commit makes the overall semantics harder to reason about and risks replay gaps if new call sites appear. Teach ext4 to mark the filesystem fast-commit ineligible for the journal transactions used by move_extent_per_page() when EXT4_IOC_MOVE_EXT runs. This forces those transactions to fall back to a full commit, ensuring that these multi-inode extent swaps are captured by the normal journal rather than partially encoded in fast commit TLVs. This change should not affect common workloads but makes online defragmentation safer and easier to reason about under fast commit. Testing: 1. prepare: dd if=3D/dev/zero of=3D/root/fc_move.img bs=3D1M count=3D0 seek=3D2= 56 mkfs.ext4 -O fast_commit -F /root/fc_move.img mkdir -p /mnt/fc_move && mount -t ext4 -o loop \ /root/fc_move.img /mnt/fc_move 2. Created two files, ran EXT4_IOC_MOVE_EXT via e4defrag, and checked the ineligible reason statistics: fallocate -l 64M /mnt/fc_move/file1 cp /mnt/fc_move/file1 /mnt/fc_move/file2 e4defrag /mnt/fc_move/file1 cat /proc/fs/ext4/loop0/fc_info shows "Move extents": > 0 and fc stats ineligible > 0. Signed-off-by: Li Chen --- fs/ext4/fast_commit.c | 1 + fs/ext4/fast_commit.h | 1 + fs/ext4/move_extent.c | 1 + include/trace/events/ext4.h | 4 +++- 4 files changed, 6 insertions(+), 1 deletion(-) diff --git a/fs/ext4/fast_commit.c b/fs/ext4/fast_commit.c index 242b69e5fe13..0ef2154a2b1f 100644 --- a/fs/ext4/fast_commit.c +++ b/fs/ext4/fast_commit.c @@ -2304,6 +2304,7 @@ static const char * const fc_ineligible_reasons[] =3D= { [EXT4_FC_REASON_ENCRYPTED_FILENAME] =3D "Encrypted filename", [EXT4_FC_REASON_MIGRATE] =3D "Inode format migration", [EXT4_FC_REASON_VERITY] =3D "fs-verity enable", + [EXT4_FC_REASON_MOVE_EXT] =3D "Move extents", }; =20 int ext4_fc_info_show(struct seq_file *seq, void *v) diff --git a/fs/ext4/fast_commit.h b/fs/ext4/fast_commit.h index 20f65135208f..2f77a37fb101 100644 --- a/fs/ext4/fast_commit.h +++ b/fs/ext4/fast_commit.h @@ -99,6 +99,7 @@ enum { EXT4_FC_REASON_ENCRYPTED_FILENAME, EXT4_FC_REASON_MIGRATE, EXT4_FC_REASON_VERITY, + EXT4_FC_REASON_MOVE_EXT, EXT4_FC_REASON_MAX }; =20 diff --git a/fs/ext4/move_extent.c b/fs/ext4/move_extent.c index 4b091c21908f..5a5e91078528 100644 --- a/fs/ext4/move_extent.c +++ b/fs/ext4/move_extent.c @@ -287,6 +287,7 @@ move_extent_per_page(struct file *o_filp, struct inode = *donor_inode, *err =3D PTR_ERR(handle); return 0; } + ext4_fc_mark_ineligible(sb, EXT4_FC_REASON_MOVE_EXT, handle); =20 orig_blk_offset =3D orig_page_offset * blocks_per_page + data_offset_in_page; diff --git a/include/trace/events/ext4.h b/include/trace/events/ext4.h index 224ab12ee83f..56e60080e759 100644 --- a/include/trace/events/ext4.h +++ b/include/trace/events/ext4.h @@ -104,6 +104,7 @@ TRACE_DEFINE_ENUM(EXT4_FC_REASON_INODE_JOURNAL_DATA); TRACE_DEFINE_ENUM(EXT4_FC_REASON_ENCRYPTED_FILENAME); TRACE_DEFINE_ENUM(EXT4_FC_REASON_MIGRATE); TRACE_DEFINE_ENUM(EXT4_FC_REASON_VERITY); +TRACE_DEFINE_ENUM(EXT4_FC_REASON_MOVE_EXT); TRACE_DEFINE_ENUM(EXT4_FC_REASON_MAX); =20 #define show_fc_reason(reason) \ @@ -119,7 +120,8 @@ TRACE_DEFINE_ENUM(EXT4_FC_REASON_MAX); { EXT4_FC_REASON_INODE_JOURNAL_DATA, "INODE_JOURNAL_DATA"}, \ { EXT4_FC_REASON_ENCRYPTED_FILENAME, "ENCRYPTED_FILENAME"}, \ { EXT4_FC_REASON_MIGRATE, "MIGRATE"}, \ - { EXT4_FC_REASON_VERITY, "VERITY"}) + { EXT4_FC_REASON_VERITY, "VERITY"}, \ + { EXT4_FC_REASON_MOVE_EXT, "MOVE_EXT"}) =20 TRACE_DEFINE_ENUM(CR_POWER2_ALIGNED); TRACE_DEFINE_ENUM(CR_GOAL_LEN_FAST); --=20 2.51.0 From nobody Sun Feb 8 05:47:56 2026 Received: from sender4-pp-f112.zoho.com (sender4-pp-f112.zoho.com [136.143.188.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 39F5930C344; Thu, 11 Dec 2025 11:52:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=136.143.188.112 ARC-Seal: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765453978; cv=pass; b=TML60y2Dfu6I87/CYAXBlBzy8xYRxmaxhRnft4MnpErZqee22/013+sCZIdAXk5NKsSqws3nbLAvifGxoibLX2gB2ztxTmKkxWwzUu9FZ8JxwxxTp/YNODe/iuIlRFWaY8XZ2DeXch7Qh73328D9V99ntLPq731JKwuHkVVBi+g= ARC-Message-Signature: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765453978; c=relaxed/simple; bh=bbF+b0TqA2KDpVd4df3EjhwLQXMixlh8mu1jC8tXUcc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=W3gxi3AP2Rp10BFQtwpzjuWjAR8v1yx+SYiXJed3qK6fNtC+1YDHhxxHyVSG46wxBTz+SW1c/NehtWmhrjIGIk8ElnKCkLFsjHiMZAIpADdCz6PruzOEXvo2Ldo8XA8XXCJhSX2zjbRKxKxQDP7wJ7WzUCyTjV0TeeWfDUV/YuA= ARC-Authentication-Results: i=2; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux.beauty; spf=pass smtp.mailfrom=linux.beauty; dkim=pass (1024-bit key) header.d=linux.beauty header.i=me@linux.beauty header.b=LLrZEcTU; arc=pass smtp.client-ip=136.143.188.112 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux.beauty Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.beauty Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.beauty header.i=me@linux.beauty header.b="LLrZEcTU" ARC-Seal: i=1; a=rsa-sha256; t=1765453931; cv=none; d=zohomail.com; s=zohoarc; b=TUwQdPtmSuAN4EEf7lda+roXdy7muybkuXGbt6HstraA2SkyUwkzfXZ/qeswT78AIINWsaBeic/4ki+FkblcTC6CXEoccp7mR45Lyx7p6qNZAr5esWAddI3Di7oPE8BR129qgySWvtt416xBRms60G1VILVEAFUQbwK2QyryQ1Q= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1765453931; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=vG83/ngcRcACF4tz1GPHGb6JSWUP/wRNZv0bkUKhuJs=; b=BRPh4HuB+zdlPQp5CrOx3uyusVQ/7sUhXxop/GTnNyF1CqgteCLvyyTGptdb8TqBNprwoMXRGPM2OZGMBv/3MBqyzkTz4CR+MOAioOz9jFKgzl6BJOVq4EB2oXK34n+ZtKnRyMxXvLxcXsizTkPxjz8V3ROfgAo3IOSgjmXFWTg= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=linux.beauty; spf=pass smtp.mailfrom=me@linux.beauty; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1765453931; s=zmail; d=linux.beauty; i=me@linux.beauty; h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-ID:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Message-Id:Reply-To; bh=vG83/ngcRcACF4tz1GPHGb6JSWUP/wRNZv0bkUKhuJs=; b=LLrZEcTUBTooS5tn0Xv7fzfvo8F/LdzovBQxjyAxCrlLW7YQcGBWhLkOnrOIH4lF 5m2qWPu9V8mzOfk/7H624Us3qiPIprO/tVjyqkDVXd0/eOUm6aCDcPGS32SGrhnJN3j 0p/kMHEXZfUDB8qaipKJca5SS1ZIMDU2DWP3jrN0= Received: by mx.zohomail.com with SMTPS id 1765453930381288.50213733743146; Thu, 11 Dec 2025 03:52:10 -0800 (PST) From: Li Chen To: "Theodore Ts'o" , Andreas Dilger , Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org Cc: Li Chen Subject: [RFC 4/5] ext4: mark group add fast-commit ineligible Date: Thu, 11 Dec 2025 19:51:41 +0800 Message-ID: <20251211115146.897420-5-me@linux.beauty> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20251211115146.897420-1-me@linux.beauty> References: <20251211115146.897420-1-me@linux.beauty> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMailClient: External Content-Type: text/plain; charset="utf-8" Fast commits only log operations that have dedicated replay support. Online resize via EXT4_IOC_GROUP_ADD updates the superblock and group descriptor metadata without going through the fast commit tracking paths. In practice these operations are rare and usually followed by further updates, but mixing them into a fast commit makes the overall semantics harder to reason about and risks replay gaps if new call sites appear. Teach ext4 to mark the filesystem fast-commit ineligible when ext4_ioctl_group_add() adds new block groups. This forces those transactions to fall back to a full commit, ensuring that the filesystem geometry updates are captured by the normal journal rather than partially encoded in fast commit TLVs. This change should not affect common workloads but makes online resize via GROUP_ADD safer and easier to reason about under fast commit. Testing: 1. prepare: dd if=3D/dev/zero of=3D/root/fc_resize.img bs=3D1M count=3D0 seek=3D256 mkfs.ext4 -O fast_commit -F /root/fc_resize.img mkdir -p /mnt/fc_resize && mount -t ext4 -o loop /root/fc_resize.img /m= nt/fc_resize 2. Ran a helper that issues EXT4_IOC_GROUP_ADD on the mounted filesystem and checked the resize ineligible reason: ./group_add_helper /mnt/fc_resize cat /proc/fs/ext4/loop0/fc_info shows "Resize": > 0. 3. Fsynced a file on the resized filesystem and verified that the fast commit stats report at least one ineligible commit: touch /mnt/fc_resize/file /root/fsync_file /mnt/fc_resize/file sync cat /proc/fs/ext4/loop0/fc_info shows fc stats ineligible > 0. Signed-off-by: Li Chen --- fs/ext4/ioctl.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c index a93a7baae990..57b47b9843f3 100644 --- a/fs/ext4/ioctl.c +++ b/fs/ext4/ioctl.c @@ -966,6 +966,7 @@ static long ext4_ioctl_group_add(struct file *file, =20 err =3D ext4_group_add(sb, input); if (EXT4_SB(sb)->s_journal) { + ext4_fc_mark_ineligible(sb, EXT4_FC_REASON_RESIZE, NULL); jbd2_journal_lock_updates(EXT4_SB(sb)->s_journal); err2 =3D jbd2_journal_flush(EXT4_SB(sb)->s_journal, 0); jbd2_journal_unlock_updates(EXT4_SB(sb)->s_journal); --=20 2.51.0 From nobody Sun Feb 8 05:47:56 2026 Received: from sender4-pp-f112.zoho.com (sender4-pp-f112.zoho.com [136.143.188.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6BFAA3019C7; Thu, 11 Dec 2025 11:53:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=136.143.188.112 ARC-Seal: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765453988; cv=pass; b=GcjzLAvyxAfVpqHD8rHUF/ACiQxLE3Fl2vrJOMgyp+D9CFpUsk9pI8KPFLUF4jlcPWCocM6saYteVl+R6SSvrgRyw0aBedivnJI8co9bPMPGZhLSke25mKVK69HYEIRBcCtHrIlv/3sFHx78e3ia3scAKLIM0dAHppJbm8cHiH4= ARC-Message-Signature: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765453988; c=relaxed/simple; bh=+HUSdOr8NWWRkdYoDBZEOdwvEx8lxuLm9f5q4yRmgvc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=OMDPHzBMrOVrsPV8xoeGJwoEvpHQrlSRsRVEqzm4K9mqK15kJfNgozVuHKL6JHUsiNyfRk7mY/q+O8+rJs1H9lBPrR23k4wzRKBSQWgALPpiLhFwovydorJA3Sf+nVE17abNSE4p9niJ/UxHjXzcCpYgsqc7Fd63rziPIYFfT/k= ARC-Authentication-Results: i=2; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux.beauty; spf=unknown smtp.mailfrom=linux.beauty; dkim=pass (1024-bit key) header.d=linux.beauty header.i=me@linux.beauty header.b=YVjCLbge; arc=pass smtp.client-ip=136.143.188.112 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux.beauty Authentication-Results: smtp.subspace.kernel.org; spf=tempfail smtp.mailfrom=linux.beauty Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.beauty header.i=me@linux.beauty header.b="YVjCLbge" ARC-Seal: i=1; a=rsa-sha256; t=1765453935; cv=none; d=zohomail.com; s=zohoarc; b=ORxm8/LZA6Ek4RFD0Yk/xyVxl8p4PMR+rQA1C8MrAH302PYnKfJwl4fxKXd1X39q6SJjA+FRRBwvf7wP+HjeUnpLiQGef0/WLdOvM356cHgI9DygEXGbLBmCTpLKOpOKCvWO4tD990NEut73vUGKXbv8Eluv3/31laJTXHXo2wE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1765453935; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=UHHv0+HlKFGfny4sGBUCRmGh7ywqTRASV5X/HQmso7w=; b=e0aKXh2NtwYWsN4uCjBCWMlXmBOgHamIAX5+2ZousBsb/YhzqTMRDP8Al5f7zv9gyaaurHi1mSbMvWkRfg++raXNMhZSKXlZ7n0mMbb7TgpJDAf45jpZKE7Na4lAhtz8Cu+zwsN5iXjoJJGA+f0ydfQBh8Ay1eXpKgGQLCs+8ro= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=linux.beauty; spf=pass smtp.mailfrom=me@linux.beauty; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1765453935; s=zmail; d=linux.beauty; i=me@linux.beauty; h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-ID:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Message-Id:Reply-To; bh=UHHv0+HlKFGfny4sGBUCRmGh7ywqTRASV5X/HQmso7w=; b=YVjCLbgex6qnLs4AunHhPZOJAPmWiN+LAjG1yBY3ZfRfxSeVY40RH+ChOHc2Qvfi JIReWJN2YWsKaSxOpbX2rPJG/r4kXMJXfgV/uXNzCO/Akjft32/MCEMhqWHPEGjuj/G u56OkGZztE1kTNVBCX+gm/rc2//1HSjsN0B89pTQ= Received: by mx.zohomail.com with SMTPS id 176545393326719.79287948199783; Thu, 11 Dec 2025 03:52:13 -0800 (PST) From: Li Chen To: "Theodore Ts'o" , Andreas Dilger , Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org Cc: Li Chen Subject: [RFC 5/5] ext4: mark group extend fast-commit ineligible Date: Thu, 11 Dec 2025 19:51:42 +0800 Message-ID: <20251211115146.897420-6-me@linux.beauty> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20251211115146.897420-1-me@linux.beauty> References: <20251211115146.897420-1-me@linux.beauty> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMailClient: External Content-Type: text/plain; charset="utf-8" Fast commits only log operations that have dedicated replay support. EXT4_IOC_GROUP_EXTEND grows the filesystem to the end of the last block group and updates the same on-disk metadata without going through the fast commit tracking paths. In practice these operations are rare and usually followed by further updates, but mixing them into a fast commit makes the overall semantics harder to reason about and risks replay gaps if new call sites appear. Teach ext4 to mark the filesystem fast-commit ineligible when EXT4_IOC_GROUP_EXTEND grows the filesystem. This forces those transactions to fall back to a full commit, ensuring that the group extension changes are captured by the normal journal rather than partially encoded in fast commit TLVs. This change should not affect common workloads but makes online resize via GROUP_EXTEND safer and easier to reason about under fast commit. Testing: 1. prepare: dd if=3D/dev/zero of=3D/root/fc_resize.img bs=3D1M count=3D0 seek=3D256 mkfs.ext4 -O fast_commit -F /root/fc_resize.img mkdir -p /mnt/fc_resize && mount -t ext4 -o loop /root/fc_resize.img /m= nt/fc_resize 2. Extended the filesystem to the end of the last block group using a helper that calls EXT4_IOC_GROUP_EXTEND on the mounted filesystem and checked fc_info: ./group_extend_helper /mnt/fc_resize cat /proc/fs/ext4/loop0/fc_info shows the "Resize" ineligible reason increased. 3. Fsynced a file on the resized filesystem and confirmed that the fast commit ineligible counter incremented for the resize transaction: touch /mnt/fc_resize/file /root/fsync_file /mnt/fc_resize/file sync cat /proc/fs/ext4/loop0/fc_info Signed-off-by: Li Chen --- fs/ext4/ioctl.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c index 57b47b9843f3..ce92652f8332 100644 --- a/fs/ext4/ioctl.c +++ b/fs/ext4/ioctl.c @@ -1608,6 +1608,8 @@ static long __ext4_ioctl(struct file *filp, unsigned = int cmd, unsigned long arg) =20 err =3D ext4_group_extend(sb, EXT4_SB(sb)->s_es, n_blocks_count); if (EXT4_SB(sb)->s_journal) { + ext4_fc_mark_ineligible(sb, EXT4_FC_REASON_RESIZE, + NULL); jbd2_journal_lock_updates(EXT4_SB(sb)->s_journal); err2 =3D jbd2_journal_flush(EXT4_SB(sb)->s_journal, 0); jbd2_journal_unlock_updates(EXT4_SB(sb)->s_journal); --=20 2.51.0