From: Christian Brauner <brauner@kernel.org>
To: linux-fsdevel@vger.kernel.org, Jan Kara <jack@suse.cz>
Cc: Josef Bacik <josef@toxicpanda.com>,
Chris Mason <mason@kernel.org>,
linux-ext4@vger.kernel.org,
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Baokun Li <libaokun@linux.alibaba.com>,
Ojaswin Mujoo <ojaswin@linux.ibm.com>,
"Ritesh Harjani (IBM)" <ritesh.list@gmail.com>,
Namjae Jeon <namjae.jeon@samsung.com>,
"Christian Brauner (Amutable)" <brauner@kernel.org>,
stable@vger.kernel.org
Subject: [PATCH RFC v3 08/14] fs: set I_METADATA_WRITEBACK in mmb_mark_buffer_dirty()
Date: Mon, 09 Nov 2026 17:51:23 +0100 [thread overview]
Message-ID: <20261109-work-inode-metadata_writeback-v3-8-91ac6c024018@kernel.org> (raw)
In-Reply-To: <20261109-work-inode-metadata_writeback-v3-0-91ac6c024018@kernel.org>
ext2, ext4 without a journal, fat, udf and minix track the metadata
buffers of an inode in a mapping_metadata_bhs list and sync them from
->sync_inode_metadata() and ->evict_inode(). The inode block itself is
only tracked by I_METADATA_WRITEBACK which ->write_inode() sets after
copying the inode into its buffer.
Set the bit in mmb_mark_buffer_dirty() as well so that it covers all
the metadata an inode may still have to write out. Set it after the
buffer is on the list. An fsync() that sees the bit then also finds the
buffer when it walks the list, and one that cleared the bit before we
set it leaves it set for the next one.
The inode itself may never have been dirtied. fat for example tracks
the FAT buffers on a private inode that nothing marks dirty. So attach
the inode to a wb before setting the bit, the way ext4_mark_iloc_dirty()
does, or writeback_single_inode() has no wb to lock once evict() syncs
it.
That lets evict() write out everything the bit tracks in one place
instead of every ->evict_inode() calling mmb_sync() itself.
Suggested-by: Jan Kara <jack@suse.cz>
Cc: stable@vger.kernel.org # v7.3
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
---
fs/buffer.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/fs/buffer.c b/fs/buffer.c
index 5d3852b726d6..f951559e7d32 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -621,12 +621,15 @@ void write_boundary_block(struct block_device *bdev,
* @bh: The buffer to mark dirty.
* @mmb: The list of buffers to add the buffer to.
*
- * Mark the buffer dirty and add it to the list if it is not already on
- * a list.
+ * Mark the buffer dirty, add it to the list if it is not already on a list
+ * and set I_METADATA_WRITEBACK on the inode so that fsync() and eviction
+ * write it out.
*/
void mmb_mark_buffer_dirty(struct buffer_head *bh,
struct mapping_metadata_bhs *mmb)
{
+ struct inode *inode = mmb->mapping->host;
+
mark_buffer_dirty(bh);
if (!bh->b_mmb) {
spin_lock(&mmb->lock);
@@ -641,6 +644,15 @@ void mmb_mark_buffer_dirty(struct buffer_head *bh,
list_move_tail(&bh->b_assoc_buffers, &mmb->list);
spin_unlock(&mmb->lock);
}
+ /*
+ * The inode itself may never have been dirtied, so attach it to a wb
+ * before setting the bit or writeback_single_inode() has nothing to
+ * lock when evict() syncs it.
+ */
+ spin_lock(&inode->i_lock);
+ inode_attach_wb(inode, NULL);
+ inode_state_set(inode, I_METADATA_WRITEBACK);
+ spin_unlock(&inode->i_lock);
}
EXPORT_SYMBOL(mmb_mark_buffer_dirty);
--
2.53.0
next prev parent reply other threads:[~2026-11-09 16:52 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-09 16:51 [PATCH RFC v3 00/14] fs: reclaim inodes with I_METADATA_WRITEBACK Christian Brauner
2026-11-09 16:51 ` [PATCH RFC v3 01/14] ext2: add ext2_inode_block() helper Christian Brauner
2026-11-09 16:57 ` sashiko-bot
2026-11-09 16:51 ` [PATCH RFC v3 02/14] ext2: don't read the inode block in ext2_sync_inode_metadata() Christian Brauner
2026-11-09 17:02 ` sashiko-bot
2026-11-09 16:51 ` [PATCH RFC v3 03/14] ext4: use sb_find_get_block_nonatomic() in ext4_get_inode_loc_noio() Christian Brauner
2026-11-09 17:06 ` sashiko-bot
2026-11-09 16:51 ` [PATCH RFC v3 04/14] ext4: don't read the inode block in ext4_sync_inode_metadata() Christian Brauner
2026-11-09 17:11 ` sashiko-bot
2026-11-09 16:51 ` [PATCH RFC v3 05/14] minix: add minix_inode_block() helper Christian Brauner
2026-11-09 17:13 ` sashiko-bot
2026-11-09 16:51 ` [PATCH RFC v3 06/14] minix: don't read the inode block in minix_sync_inode_metadata() Christian Brauner
2026-11-09 17:16 ` sashiko-bot
2026-11-09 16:51 ` [PATCH RFC v3 07/14] udf: don't allocate the inode block in udf_sync_inode_metadata() Christian Brauner
2026-11-09 17:24 ` sashiko-bot
2026-11-09 16:51 ` Christian Brauner [this message]
2026-11-09 17:50 ` [PATCH RFC v3 08/14] fs: set I_METADATA_WRITEBACK in mmb_mark_buffer_dirty() sashiko-bot
2026-11-10 10:33 ` Jan Kara
2026-11-09 16:51 ` [PATCH RFC v3 09/14] fs: don't strand I_METADATA_WRITEBACK inodes outside the LRU Christian Brauner
2026-11-09 18:18 ` sashiko-bot
2026-11-10 10:28 ` Jan Kara
2026-11-09 16:51 ` [PATCH RFC v3 10/14] ext2: drop mmb_sync() from ext2_evict_inode() Christian Brauner
2026-11-09 18:36 ` sashiko-bot
2026-11-10 10:28 ` Jan Kara
2026-11-09 16:51 ` [PATCH RFC v3 11/14] ext4: drop mmb_sync() from ext4_evict_inode() Christian Brauner
2026-11-09 18:55 ` sashiko-bot
2026-11-10 10:28 ` Jan Kara
2026-11-09 16:51 ` [PATCH RFC v3 12/14] minix: drop mmb_sync() from minix_evict_inode() Christian Brauner
2026-11-09 18:58 ` sashiko-bot
2026-11-10 10:28 ` Jan Kara
2026-11-09 16:51 ` [PATCH RFC v3 13/14] udf: drop mmb_sync() from udf_evict_inode() Christian Brauner
2026-11-09 19:03 ` sashiko-bot
2026-11-10 10:29 ` Jan Kara
2026-11-09 16:51 ` [PATCH RFC v3 14/14] fat: drop mmb_sync() from fat_evict_inode() Christian Brauner
2026-11-09 19:08 ` sashiko-bot
2026-11-10 10:29 ` Jan Kara
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=20261109-work-inode-metadata_writeback-v3-8-91ac6c024018@kernel.org \
--to=brauner@kernel.org \
--cc=adilger.kernel@dilger.ca \
--cc=hirofumi@mail.parknet.co.jp \
--cc=jack@suse.cz \
--cc=josef@toxicpanda.com \
--cc=libaokun@linux.alibaba.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=mason@kernel.org \
--cc=namjae.jeon@samsung.com \
--cc=ojaswin@linux.ibm.com \
--cc=ritesh.list@gmail.com \
--cc=stable@vger.kernel.org \
/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