Cover Letter Detail
Show a cover letter.
GET /api/1.1/covers/2220881/?format=api
{ "id": 2220881, "url": "http://patchwork.ozlabs.org/api/1.1/covers/2220881/?format=api", "web_url": "http://patchwork.ozlabs.org/project/linux-ext4/cover/20260408112020.716706-1-me@linux.beauty/", "project": { "id": 8, "url": "http://patchwork.ozlabs.org/api/1.1/projects/8/?format=api", "name": "Linux ext4 filesystem development", "link_name": "linux-ext4", "list_id": "linux-ext4.vger.kernel.org", "list_email": "linux-ext4@vger.kernel.org", "web_url": null, "scm_url": null, "webscm_url": null }, "msgid": "<20260408112020.716706-1-me@linux.beauty>", "date": "2026-04-08T11:20:11", "name": "[RFC,v6,0/7] ext4: fast commit: snapshot inode state for FC log", "submitter": { "id": 84264, "url": "http://patchwork.ozlabs.org/api/1.1/people/84264/?format=api", "name": "Li Chen", "email": "me@linux.beauty" }, "mbox": "http://patchwork.ozlabs.org/project/linux-ext4/cover/20260408112020.716706-1-me@linux.beauty/mbox/", "series": [ { "id": 499121, "url": "http://patchwork.ozlabs.org/api/1.1/series/499121/?format=api", "web_url": "http://patchwork.ozlabs.org/project/linux-ext4/list/?series=499121", "date": "2026-04-08T11:20:11", "name": "ext4: fast commit: snapshot inode state for FC log", "version": 6, "mbox": "http://patchwork.ozlabs.org/series/499121/mbox/" } ], "comments": "http://patchwork.ozlabs.org/api/covers/2220881/comments/", "headers": { "Return-Path": "\n <SRS0=4IW4=CH=vger.kernel.org=linux-ext4+bounces-15669-patchwork-incoming=ozlabs.org@ozlabs.org>", "X-Original-To": [ "incoming@patchwork.ozlabs.org", "linux-ext4@vger.kernel.org" ], "Delivered-To": [ "patchwork-incoming@legolas.ozlabs.org", "patchwork-incoming@ozlabs.org" ], "Authentication-Results": [ "legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=linux.beauty header.i=me@linux.beauty\n header.a=rsa-sha256 header.s=zmail header.b=Imihwy5r;\n\tdkim-atps=neutral", "legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=ozlabs.org\n (client-ip=2404:9400:2221:ea00::3; helo=mail.ozlabs.org;\n envelope-from=srs0=4iw4=ch=vger.kernel.org=linux-ext4+bounces-15669-patchwork-incoming=ozlabs.org@ozlabs.org;\n receiver=patchwork.ozlabs.org)", "gandalf.ozlabs.org;\n arc=pass smtp.remote-ip=\"2600:3c04:e001:36c::12fc:5321\"\n arc.chain=\"subspace.kernel.org:zohomail.com\"", "gandalf.ozlabs.org;\n dmarc=pass (p=none dis=none) header.from=linux.beauty", "gandalf.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=linux.beauty header.i=me@linux.beauty\n header.a=rsa-sha256 header.s=zmail header.b=Imihwy5r;\n\tdkim-atps=neutral", "gandalf.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c04:e001:36c::12fc:5321; helo=tor.lore.kernel.org;\n envelope-from=linux-ext4+bounces-15669-patchwork-incoming=ozlabs.org@vger.kernel.org;\n receiver=ozlabs.org)", "smtp.subspace.kernel.org;\n\tdkim=pass (1024-bit key) header.d=linux.beauty header.i=me@linux.beauty\n header.b=\"Imihwy5r\"", "smtp.subspace.kernel.org;\n arc=pass smtp.client-ip=136.143.188.15", "smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linux.beauty", "smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=linux.beauty" ], "Received": [ "from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1 raw public key)\n server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4frLGt4dl2z1xtJ\n\tfor <incoming@patchwork.ozlabs.org>; Wed, 08 Apr 2026 21:21:08 +1000 (AEST)", "from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3])\n\tby gandalf.ozlabs.org (Postfix) with ESMTP id 4frLGq6rYDz4wTL\n\tfor <incoming@patchwork.ozlabs.org>; Wed, 08 Apr 2026 21:21:07 +1000 (AEST)", "by gandalf.ozlabs.org (Postfix)\n\tid 4frLGq6knmz4wpy; Wed, 08 Apr 2026 21:21:07 +1000 (AEST)", "from tor.lore.kernel.org (tor.lore.kernel.org\n [IPv6:2600:3c04:e001:36c::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby gandalf.ozlabs.org (Postfix) with ESMTPS id 4frLGl4ZqMz4wTL\n\tfor <patchwork-incoming@ozlabs.org>; Wed, 08 Apr 2026 21:21:03 +1000 (AEST)", "from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby tor.lore.kernel.org (Postfix) with ESMTP id DBEDB300A516\n\tfor <patchwork-incoming@ozlabs.org>; Wed, 8 Apr 2026 11:21:01 +0000 (UTC)", "from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id DB30F386C26;\n\tWed, 8 Apr 2026 11:20:57 +0000 (UTC)", "from sender4-op-o15.zoho.com (sender4-op-o15.zoho.com\n [136.143.188.15])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id BCAA9386C16;\n\tWed, 8 Apr 2026 11:20:55 +0000 (UTC)", "by mx.zohomail.com with SMTPS id 17756472434711005.5213354066404;\n\tWed, 8 Apr 2026 04:20:43 -0700 (PDT)" ], "ARC-Seal": [ "i=3; a=rsa-sha256; d=ozlabs.org; s=201707; t=1775647267; cv=pass;\n\tb=H61ILkQptbxtIIqScEQkezCifqyCzNYJ8pkLqreOutvo+MbuGhFKMTyYd+pIQFLJ8wtmmdBDVoJCKTkAvBoGr7MuC7x/k4ec4Q0MWnjejCSmHkp/L6G/QVwSZbLPDqtPjIhaGkqBhDcS59u8GrXPUaz50aLLdSUniJPeP1SHbrHx4XcUiE4nREsLOT/F9YvjhRh2Oq7b5hiHwZFWYOg/QlM2J/7X6Ld4PrgvAWTvjLxszlGN0kwFRIEeCG5sQLwqOItXzZI67rCtPcMP42UKmFdZDakV8IFgQNbIpnAw1O6zzu59Iyk1DRTGVkrZddg+U5FF8jlIzRZpeP6+1Gyn1g==", "i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775647257; cv=pass;\n b=u4sClAoeAa5pbms3StvmRSuzZki7TemQvglE34n+B88o86BgTcOXrGGCOXVxsMad0zkkktVYUvpZ5OgAAHsaf9D2AWjK7jEVHGGaTjCgR7pNN3J35VnEKh2VwUfs5AMbZ9pv0aoT5Psn8pHrOhKTbkNiNJOtVsE/EE+0Xmw6sag=", "i=1; a=rsa-sha256; t=1775647246; cv=none;\n\td=zohomail.com; s=zohoarc;\n\tb=KtfO/2bSUjGwP1fr1KoclkXnVWL91217zQCYcj7P75UFixNghdEBihKOttFXZRg1PoJTsls17HqJficAuh64fZV84CjjLRZi3Uw3pveDFE2OnexDDULGA9R1THC7F8MU54TP2IXe6evvRvH/mDecd7+TmmYt5DQDytWEHO9ooKU=" ], "ARC-Message-Signature": [ "i=3; a=rsa-sha256; d=ozlabs.org; s=201707;\n\tt=1775647267; c=relaxed/relaxed;\n\tbh=N8WWDNZj0BNr5WoN5jqMucI0TmHuEKhkBR70lW04iYk=;\n\th=From:To:Cc:Subject:Date:Message-ID:MIME-Version;\n b=nLxEIMkRD36tsvqfuiSFNeeFdtKr2nRBPvphQfk5M0RHIideyCiHN8wSI5vjeXmXtRJhE1SQQwIDL3i5KY34qVBAXOlU44uXtMuAm82Jp5u039AsFMzOf2UsG/tKdRfhUgOXjgcVyzXQ0senLZ972KpeSfA/9RQ7Do8WC4lkFpNX78oif3WV+JO8IrGWl3TR3iSzANYT9VmWOWeifocteaqoxarUsRDlnezsRiLJTFbrCnKjHlzHXWy/cziEU0VMBzc62VAMG5/mFwqd5tHAniB3ubMIPqcsBxgkErCKMiWVP0ltX8Od04z5PIcmq1H18ofZFF73369bWzp/cIXcnw==", "i=2; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775647257; c=relaxed/simple;\n\tbh=xlsmvPzHdOqfIA+bb348yD95bQuH8/ecTreeHmZG+ps=;\n\th=From:To:Cc:Subject:Date:Message-ID:MIME-Version;\n b=TMTimEdghIaD1VFMwY5n4LhHSTVvsmbbPT+Zrnfhxn9t9fy5J+ZDHF0zkm9FCB+xKCipyBKC4RWbfbnybHAyBlcXEmcEwaOOeq3E6KTuQLCSAFqjCy6JnG/rr7V0GymV5u4Av8aupcddQf6yrKfrWeYedlgS0YVvkuikL1XTnH0=", "i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com;\n s=zohoarc;\n\tt=1775647246;\n h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To;\n\tbh=N8WWDNZj0BNr5WoN5jqMucI0TmHuEKhkBR70lW04iYk=;\n\tb=a8MjFu1MMqfS5p8u5T03ugt29uk/ZhsJOpFhWOxp7Tw0fjYKtxIV3ci8F7tYqw5y1aB54OGjads6jKJ6ZE0fRPcr1eFiNkrw5GotBxRSsV2At44DfF3VpC9fooM3S100KIrBWo+49L8rcPEiK1wuitlcb66LF1FBsBJCfw80j6A=" ], "ARC-Authentication-Results": [ "i=3; gandalf.ozlabs.org;\n dmarc=pass (p=none dis=none) header.from=linux.beauty;\n dkim=pass (1024-bit key;\n unprotected) header.d=linux.beauty header.i=me@linux.beauty\n header.a=rsa-sha256 header.s=zmail header.b=Imihwy5r; dkim-atps=neutral;\n spf=pass (client-ip=2600:3c04:e001:36c::12fc:5321; helo=tor.lore.kernel.org;\n envelope-from=linux-ext4+bounces-15669-patchwork-incoming=ozlabs.org@vger.kernel.org;\n receiver=ozlabs.org) smtp.mailfrom=vger.kernel.org", "i=2; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linux.beauty;\n spf=pass smtp.mailfrom=linux.beauty;\n dkim=pass (1024-bit key) header.d=linux.beauty header.i=me@linux.beauty\n header.b=Imihwy5r; arc=pass smtp.client-ip=136.143.188.15", "i=1; mx.zohomail.com;\n\tdkim=pass header.i=linux.beauty;\n\tspf=pass smtp.mailfrom=me@linux.beauty;\n\tdmarc=pass header.from=<me@linux.beauty>" ], "DKIM-Signature": "v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1775647245;\n\ts=zmail; d=linux.beauty; i=me@linux.beauty;\n\th=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-ID:MIME-Version:Content-Transfer-Encoding:Message-Id:Reply-To;\n\tbh=N8WWDNZj0BNr5WoN5jqMucI0TmHuEKhkBR70lW04iYk=;\n\tb=Imihwy5r+d6OO4n84tfT37pvxFIDICrwzN+tQx+xsZfMFv4TNTUmCJ4TVmis77TL\n\tHwh/woPgPMNEUHd07RvqsKuXSMmPj2c67ke6Qo/ZgI3Tk+Ju6nr5NIq3b3gFqPB2i7T\n\tkdhZfkhweLLzabOfVYn7kHXmaBKF6eYs2GwZZ8CY=", "From": "Li Chen <me@linux.beauty>", "To": "Zhang Yi <yi.zhang@huaweicloud.com>,\n\tTheodore Ts'o <tytso@mit.edu>,\n\tAndreas Dilger <adilger.kernel@dilger.ca>", "Cc": "Steven Rostedt <rostedt@goodmis.org>,\n\tMasami Hiramatsu <mhiramat@kernel.org>,\n\tMathieu Desnoyers <mathieu.desnoyers@efficios.com>,\n\tlinux-ext4@vger.kernel.org,\n\tlinux-trace-kernel@vger.kernel.org,\n\tlinux-kernel@vger.kernel.org", "Subject": "[RFC v6 0/7] ext4: fast commit: snapshot inode state for FC log", "Date": "Wed, 8 Apr 2026 19:20:11 +0800", "Message-ID": "<20260408112020.716706-1-me@linux.beauty>", "X-Mailer": "git-send-email 2.53.0", "Precedence": "bulk", "X-Mailing-List": "linux-ext4@vger.kernel.org", "List-Id": "<linux-ext4.vger.kernel.org>", "List-Subscribe": "<mailto:linux-ext4+subscribe@vger.kernel.org>", "List-Unsubscribe": "<mailto:linux-ext4+unsubscribe@vger.kernel.org>", "MIME-Version": "1.0", "Content-Transfer-Encoding": "8bit", "X-ZohoMailClient": "External", "X-Spam-Status": "No, score=-1.2 required=5.0 tests=ARC_SIGNED,ARC_VALID,\n\tDKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DMARC_PASS,\n\tHEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,\n\tSPF_PASS autolearn=disabled version=4.0.1", "X-Spam-Checker-Version": "SpamAssassin 4.0.1 (2024-03-25) on gandalf.ozlabs.org" }, "content": "Hi,\n\n(This RFC v6 series is rebased onto linux-next master as of 2026-04-08,\ncommit f3e6330d7fe4 (\"Add linux-next specific files for 20260407\").)\n\nZhang Yi in RFC v3 review pointed out that postponing lockdep assertions only\nmasks the issue, and that sleeping in ext4_fc_track_inode() while holding\ni_data_sem can form a real ABBA deadlock if the fast commit writer also needs\ni_data_sem while the inode is in FC_COMMITTING.\n\nZhang Yi suggested two possible directions to address the root cause:\n\n1. \"Ha, the solution seems to have already been listed in the TODOs in\nfast_commit.c.\n\n Change ext4_fc_commit() to lookup logical to physical mapping using extent\n status tree. This would get rid of the need to call ext4_fc_track_inode()\n before acquiring i_data_sem. To do that we would need to ensure that\n modified extents from the extent status tree are not evicted from memory.\"\n\n2. \"Alternatively, recording the mapped range of tracking might also be\nfeasible.\"\n\nThis series implements a hybrid way: it implements approach 2 by snapshotting inode image\nand mapped ranges at commit time, and consuming only snapshots during log\nwriting.\n\nApproach 2 still needs a mapping source while building the snapshot\n(logical-to-physical and unwritten/hole semantics). Calling ext4_map_blocks()\nthere would take i_data_sem and can block inside the\njbd2_journal_lock_updates() window, which risks deadlocks or unbounded stalls.\nSo the snapshot path uses approach 1's extent status lookups as a best-effort\nmapping source to avoid ext4_map_blocks().\n\nI did not fully implement approach 1 (making extent status lookups\nauthoritative by preventing reclaim of needed entries) because that would need\nadditional pinning/integration under memory pressure and a larger correctness\nsurface. Instead, the extent status tree is treated as a cache and the\nsnapshot path falls back to full commit on cache misses or unstable mappings\n(e.g. delayed allocation).\n\nLock inversion / deadlock model (before):\n\nCPU0 (metadata update) CPU1 (fast commit)\n-------------------- -----------------\n... hold i_data_sem (A) mutex_lock(s_fc_lock) (B)\n ext4_fc_track_inode() ext4_fc_write_inode_data()\n mutex_lock(s_fc_lock) (B) ext4_map_blocks()\n wait FC_COMMITTING (sleep) down_read(i_data_sem) (A)\n\nThis creates i_data_sem (A) -> s_fc_lock (B) on update paths, and\ns_fc_lock (B) -> i_data_sem (A) on commit paths. Once CPU0 sleeps while\nholding (A), CPU1 can block on (A) while holding (B), completing the ABBA\ncycle.\n\nNew model (this series):\n\nCPU0 (metadata update) CPU1 (fast commit)\n-------------------- -----------------\n... maybe hold i_data_sem (A) jbd2_journal_lock_updates()\n ext4_fc_track_*() snapshot inode + ranges (no map_blocks)\n mutex_lock(s_fc_lock) (B) jbd2_journal_unlock_updates()\n if FC_COMMITTING: set FC_REQUEUE s_fc_lock (B)\n no sleep write FC log from snapshots only\n cleanup: clear COMMITTING, requeue if set\n\nThe commit path no longer takes i_data_sem while holding s_fc_lock, and\ntracking no longer sleeps waiting for FC_COMMITTING. If an inode is updated\nduring a fast commit, EXT4_STATE_FC_REQUEUE records that fact and the inode\nis moved to FC_Q_STAGING for the next commit.\nThe only remaining FC_COMMITTING waiter is ext4_fc_del(), which drops\ns_fc_lock before sleeping.\n\nThis series snapshots the on-disk inode and tracked data ranges while journal\nupdates are locked and existing handles are drained. The log writing phase then\nserializes only snapshots, so it no longer needs to call ext4_map_blocks() and\ntake i_data_sem under s_fc_lock. This is done in two steps: patch 1 drops\next4_map_blocks() from log writing by introducing commit-time snapshots, and\npatch 5 drops ext4_map_blocks() from the snapshot path by using the extent\nstatus cache. The snapshot also records whether a mapped extent is unwritten,\nso the ADD_RANGE records (and replay) preserve unwritten semantics.\n\nSnapshotting runs under jbd2_journal_lock_updates(). Since a cache miss in\next4_get_inode_loc() can start synchronous inode table I/O and stall handle\nstarts for milliseconds, patch 1 uses ext4_get_inode_loc_noio() and falls back\nto full commit if the inode table block is not present or not uptodate.\n\next4_fc_track_inode() also stops waiting for FC_COMMITTING. Updates during an\nongoing fast commit are marked with EXT4_STATE_FC_REQUEUE and are replayed in\nthe next fast commit, while ext4_fc_del() waits for FC_COMMITTING so an inode\ncannot be removed while the commit thread is still using it.\n\nThe extent status tree is a cache, not an authoritative source, so the snapshot\npath falls back to full commit on cache misses or unstable mappings (e.g.\ndelayed allocation). This includes cases where extent status entries are not\npresent (or have been reclaimed) under memory pressure. The snapshot path does\nnot try to rebuild mappings by calling ext4_map_blocks(); instead it simply\nmarks the transaction fast commit ineligible.\n\nTo keep the updates-locked window bounded, the snapshot path caps the number of\nsnapshotted inodes and ranges per fast commit (currently 1024 inodes and 2048\nranges) and falls back to full commit when the cap is exceeded. The series also\nhandles the journal inode i_data_sem lockdep false positive via subclassing;\njournal inode mapping may still take i_data_sem even when data inode mapping is\navoided.\n\nPatch 6 adds the ext4_fc_lock_updates tracepoint to quantify the updates-locked\nwindow and snapshot fallback reasons. Patch 7 extends\n/proc/fs/ext4/<sb_id>/fc_info with best-effort snapshot counters. If the /proc\ninterface is undesirable, I can drop patch 7 and keep the tracepoint only, or\ndrop even both.\n\nTesting and measurement were done on a QEMU/KVM guest with virtio-pmem + dax\n(ext4 -O fast_commit, mounted dax,noatime). The workload does python3 500x\n{4K write + fsync}, fallocate 256M, and python3 500x {creat + fsync(dir)}.\nOver 3 cold boots, ext4_fc_lock_updates reported locked_ns p50 2.88-2.92 us,\np99 <= 6.71 us, and max <= 102.71 us, with snap_err always 0. Under stress-ng\nmemory pressure (stress-ng --vm 4 --vm-bytes 75% --timeout 60s), locked_ns p50\n2.94 us, p99 <= 4.97 us, and max <= 20.07 us. The fc_info snapshot failure\ncounters stayed at 0.\nThese hold times are in the low microseconds range, and the caps keep the\nworst case bounded.\n\nComments and guidance are very welcome. Please let me know if there are any\nconcerns about correctness, corner cases, or better approaches.\n\nRFC v5 -> RFC v6:\n- Rebase onto linux-next master as of 2026-04-08.\n- Address tracepoint review feedback by relying on enum auto-increment for\n snap_err values and by switching the guarded ext4_fc_lock_updates call site\n to trace_call__ext4_fc_lock_updates() to avoid the double static_branch. [1]\n- Keep lock window accounting unconditional for fc_info while using the guarded\n direct tracepoint call.\n- Fix the inode debug print format exposed by the rebase.\n\nRFC v4 -> RFC v5:\n- Patch 6: Make ext4_fc_lock_updates snap_err human readable via\n TRACE_DEFINE_ENUM() + __print_symbolic(), using a single TRACE_SNAP_ERR\n mapping while keeping the enum values stable for tooling.\n\nRFC v3 -> RFC v4:\n- Replace lockdep_assert movement with removing the wait in\n ext4_fc_track_inode() and using EXT4_STATE_FC_REQUEUE to capture updates\n during an ongoing fast commit.\n- Replace dropping s_fc_lock around log writing with commit-time snapshots of\n inode image and mapped ranges (recording the mapped range of tracking as\n suggested by Zhang Yi) so log writing consumes only snapshots.\n- Avoid inode table I/O under jbd2_journal_lock_updates() via\n ext4_get_inode_loc_noio() and fallback to full commit on cache misses.\n- Use the extent status cache for snapshot mappings and fall back to full\n commit on cache misses or unstable mappings (e.g. delayed allocation).\n- Add tracepoint and /proc snapshot stats to quantify the updates-locked window\n and snapshot fallback reasons.\n\nRFC v2 -> RFC v3:\n- rebase on top of\n https://lore.kernel.org/linux-ext4/20251223131342.287864-1-me@linux.beauty/T/#u\n\nRFC v1 -> RFC v2:\n- patch 1: move comments to correct place\n- patch 2: add it to patchset.\n- add missing RFC prefix\n\nRFC v1: https://lore.kernel.org/linux-ext4/20251222032655.87056-1-me@linux.beauty/T/#u\nRFC v2: https://lore.kernel.org/linux-ext4/20251222151906.24607-1-me@linux.beauty/T/#t\nRFC v3: https://lore.kernel.org/linux-ext4/20251224032943.134063-1-me@linux.beauty/\nRFC v4: https://lore.kernel.org/all/20260120112538.132774-1-me@linux.beauty/\nRFC v5: https://lore.kernel.org/all/20260317084624.457185-1-me@linux.beauty/t/#u\n\n[1]: https://lore.kernel.org/all/acZJl8QUYEq8voqQ@BLRRASHENOY1.amd.com/T/#u\n\nThanks,\n\nLi Chen (7):\n ext4: fast commit: snapshot inode state before writing log\n ext4: lockdep: handle i_data_sem subclassing for special inodes\n ext4: fast commit: avoid waiting for FC_COMMITTING\n ext4: fast commit: avoid self-deadlock in inode snapshotting\n ext4: fast commit: avoid i_data_sem by dropping ext4_map_blocks() in\n snapshots\n ext4: fast commit: add lock_updates tracepoint\n ext4: fast commit: export snapshot stats in fc_info\n\n fs/ext4/ext4.h | 73 +++-\n fs/ext4/fast_commit.c | 706 +++++++++++++++++++++++++++++-------\n fs/ext4/inode.c | 51 +++\n fs/ext4/super.c | 9 +\n include/trace/events/ext4.h | 61 ++++\n 5 files changed, 766 insertions(+), 134 deletions(-)" }