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

[David Sterba <dsterba@suse.cz>]

On Tue, Mar 24, 2026 at 01:40:39PM +0800, Dave Chen wrote:
> On Mon, Mar 23, 2026 at 03:07:48PM +0100, David Sterba wrote:
> > 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.
> 
> Yes, this comes from a real workload. We have a backup service that
> creates temporary files via mkstemp(), closes them, and later reopens
> them with O_TRUNC for writing. The O_TRUNC is defensive -- the file is
> always empty at that point, but the temp file creation and usage are in
> separate components, so removing it from userspace isn't straightforward.
> 
> This pattern repeats for a large number of files per backup job, and
> each close() triggers an unnecessary filemap_flush().
> 
> When oldsize is already 0, the flag provides no protection -- there is
> no data being truncated away, so the filemap_flush() on close serves
> no purpose. The fix simply makes the condition match what the comment
> already describes.

Thanks, I'll add the workload description to changelog.