Re: [PATCH] btrfs: fix unnecessary flush on close when truncating zero-sized files

[David Sterba <dsterba@suse.cz>]

On Mon, Mar 23, 2026 at 11:43:22AM +0800, Dave Chen wrote:
> In btrfs_setsize(), when a file is truncated to size 0, the
> BTRFS_INODE_FLUSH_ON_CLOSE flag is unconditionally set to ensure
> pending writes get flushed on close. This flag was designed to protect
> the "truncate-then-rewrite" pattern, where an application truncates a
> file with existing data down to zero and writes new content, ensuring
> the new data reaches disk on close.
> 
> However, when a file already has a size of 0 (e.g., a newly created
> file opened with O_CREAT | O_TRUNC), oldsize and newsize are both 0.
> In this case, setting BTRFS_INODE_FLUSH_ON_CLOSE is unnecessary because
> no "good data" was truncated away. The subsequent filemap_flush() in
> btrfs_release_file() then triggers avoidable writeback that disrupts
> the normal delayed writeback batching, adding I/O overhead.

Does this have a measurable impact? Truncating 0 -> 0 without any
intermediate writes could happen but I kind of doubt it's worth
optimizing. I'm not against adding the patch but would like to know if
it's fixing some problem for you. Thanks.