All of lore.kernel.org
 help / color / mirror / Atom feed
From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
To: Jan Kara <jack@suse.cz>
Cc: linux-fsdevel@vger.kernel.org,
	 Christian Brauner <brauner@kernel.org>,
	aivazian.tigran@gmail.com,  Ted Tso <tytso@mit.edu>,
	linux-ext4@vger.kernel.org
Subject: Re: [PATCH 6/9] fat: Fix possibly missing inode write on fsync(2)
Date: Tue, 12 May 2026 23:17:55 +0900	[thread overview]
Message-ID: <877bp8yang.fsf@mail.parknet.co.jp> (raw)
In-Reply-To: <jb536ihpuajtk4dcpxquos5fmmllfs7uiq3ryvnsfl4tesiidj@jwhnlrdiaih3>

Jan Kara <jack@suse.cz> writes:

>> I didn't check the case of rename completely, just recalled it when I
>> saw this code, need confirm/check.  But at least, the case of remove
>> will leave it even after the block is reused.
>
> Right. fat_detach() should set i_metadata_bhs.inode_blk to INVALID_BLK,
> thanks for catching that. I was thinking whether we should set
> i_metadata_bhs.inode_blk in fat_attach() instead of during inode dirtying.
> It would be somewhat more obviously correct but it could lead to
> unnecessary flushing in case the directory block gets dirtied by some other
> entry in it while the inode we are fsyncing got never dirtied. IMHO that's
> a sensible tradeoff so I'd do that but what is your opinion?

IMO, the marker should be cleared like b_assoc_buffers or I_DIRTY_*
flags after each sync. Otherwise, because the block is shared with other
inodes, it would sync/wait the unrelated dirty easily.

[And more serious implementation, looks like it should be cleared at
similar points or such with b_assoc_buffers is cleared to minimize
unrelated sync/wait.]
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

  reply	other threads:[~2026-05-12 14:17 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-11 12:13 [PATCH 0/9] fs: Fix missed inode write during fsync Jan Kara
2026-05-11 12:13 ` [PATCH 1/9] affs: Drop support for metadata bh tracking Jan Kara
2026-05-11 12:13 ` [PATCH 2/9] ext4: Allocate mapping_metadata_bhs struct on demand Jan Kara
2026-05-11 12:13 ` [PATCH 3/9] fs: Writeout inode buffer from mmb_sync() Jan Kara
2026-05-11 13:27   ` Christian Brauner
2026-05-11 12:13 ` [PATCH 4/9] ext2: Fix possibly missing inode write on fsync(2) Jan Kara
2026-05-11 12:13 ` [PATCH 5/9] udf: " Jan Kara
2026-05-11 12:13 ` [PATCH 6/9] fat: " Jan Kara
2026-05-11 14:32   ` OGAWA Hirofumi
2026-05-11 17:03     ` Jan Kara
2026-05-11 18:02       ` OGAWA Hirofumi
2026-05-12  7:29         ` Jan Kara
2026-05-12 14:17           ` OGAWA Hirofumi [this message]
2026-05-13  9:41             ` Jan Kara
2026-05-11 12:13 ` [PATCH 7/9] minix: " Jan Kara
2026-05-11 12:13 ` [PATCH 8/9] bfs: " Jan Kara
2026-05-11 12:13 ` [PATCH 9/9] ext4: Use mmb infrastructure for inode buffer writeout Jan Kara
2026-05-11 13:30   ` Christian Brauner
2026-05-13 10:45     ` Jan Kara
2026-05-11 20:49 ` [syzbot ci] Re: fs: Fix missed inode write during fsync syzbot ci

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=877bp8yang.fsf@mail.parknet.co.jp \
    --to=hirofumi@mail.parknet.co.jp \
    --cc=aivazian.tigran@gmail.com \
    --cc=brauner@kernel.org \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --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.