From: sashiko-bot@kernel.org
To: "Mani Tofigh" <mt4022@columbia.edu>
Cc: linux-ext4@vger.kernel.org, tytso@mit.edu
Subject: Re: [PATCH 3/3] ext4: fix directory link counts after fast commit replay
Date: Thu, 12 Nov 2026 00:16:21 +0000 [thread overview]
Message-ID: <sashiko-outbox-209891@kernel.org> (raw)
In-Reply-To: <20261111-ext4-fc-replay-mkdir-v1-3-4b20be29aed8@columbia.edu>
> From: Mani Tofigh <mt4022@columbia.edu>
>
> After a crash, the fast commit replay of a mkdir leaves the new
> directory with one link and its parent with one link too few. e2fsck
> then reports:
>
> Inode 2 ref count is 3, should be 4.
> Inode 14 ref count is 1, should be 2.
>
> Fast commits don't track directories, so the replay of a CREAT tag has
> to redo what ext4_mkdir() does. ext4_fc_replay_create() sets the
> link count of the new inode to 1 even for a directory, and nothing
> counts the new ".." in the parent. The replay of an rmdir has the
> opposite problem. __ext4_unlink() drops only one link of the directory
> and the parent keeps the link of the removed "..":
>
> Inode 2 ref count is 4, should be 3.
>
> Give a new directory 2 links and count it in its parent once its entry
> is added. When an UNLINK tag removes a directory, drop all its links
> and one link of the parent like ext4_rmdir() does. Both halves have to
> go together since today a mkdir and an rmdir replayed in sequence
> cancel out.
>
> With the fix, e2fsck doesn't find wrong link counts after the replay
> anymore.
>
> Fixes: 8016e29f4362 ("ext4: fast commit recovery path")
> Cc: stable@vger.kernel.org
> Signed-off-by: Mani Tofigh <mt4022@columbia.edu>
Sashiko has reviewed this patch and found no issues.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261111-ext4-fc-replay-mkdir-v1-0-4b20be29aed8@columbia.edu?part=3
prev parent reply other threads:[~2026-11-12 0:16 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-11 23:02 [PATCH 0/3] ext4: fix counts left by fast commit replay of a mkdir Mani Tofigh
2026-11-11 23:02 ` Mani Tofigh via B4 Relay
2026-11-11 23:02 ` [PATCH 1/3] ext4: fix directory count after fast commit replay Mani Tofigh
2026-11-11 23:02 ` Mani Tofigh via B4 Relay
2026-11-12 0:13 ` sashiko-bot
2026-11-11 23:02 ` [PATCH 2/3] ext4: fix directory i_blocks " Mani Tofigh
2026-11-11 23:02 ` Mani Tofigh via B4 Relay
2026-11-12 0:26 ` sashiko-bot
2026-11-11 23:02 ` [PATCH 3/3] ext4: fix directory link counts " Mani Tofigh
2026-11-11 23:02 ` Mani Tofigh via B4 Relay
2026-11-12 0:16 ` sashiko-bot [this message]
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=sashiko-outbox-209891@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=mt4022@columbia.edu \
--cc=sashiko-reviews@lists.linux.dev \
--cc=tytso@mit.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.