Re: [PATCH 0/4] btrfs: fix FMODE_NOCMTIME handling in btrfs

[Jeff Layton <jlayton@kernel.org>]

On Mon, 2026-11-09 at 17:10 +0100, David Sterba wrote:
> On Thu, Nov 05, 2026 at 03:07:41PM -0500, Jeff Layton wrote:
> > I tested the delegated timestamp support in nfsd recently. That support
> > relies heavily on FMODE_NOCMTIME, and I found several places where btrfs
> > didn't handle that flag properly. This series seems to fix them for me.
> > I tested mostly with the git regression testsuite, because it is very
> > sensitive to subtle bugs in timestamp handling.
> > 
> > Please consider for v7.5.
> > 
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > ---
> > Jeff Layton (4):
> >       btrfs: honor FMODE_NOCMTIME in btrfs_write_check()
> >       btrfs: honor FMODE_NOCMTIME when punching holes
> >       btrfs: honor FMODE_NOCMTIME in fallocate
> >       btrfs: honor FMODE_NOCMTIME when cloning
> 
> There's a comment from sashiko for patch 4 regarding the unconditional
> i_version update but this is mentioned in patch 3 as intentional. I
> can't tell if it's a problem, it seems more like a suggestion for
> cleanup. I'll add the series to for-next, please check if the question
> is valid. Thanks.

Thanks, I think the suggestion from sashiko is a false positive and we
should just merge this set as-is. That said, the kernel _is_
inconsistent in how it treats i_version under FMODE_NOCMTIME:

The generic VFS layer (so ext4, tmpfs, etc.) suppresses i_version
updates when FMODE_NOCMTIME is set.

XFS keeps incrementing it. This is because i_version behavior is a bit
different there (historical reasons). IIRC they more or less keep it in
lockstep with the LSN.

btrfs is mixed -- the write path suppresses it (like the generic VFS
does) but hole punching, fallocate, clone, etc. bump i_version anyway.
This is probably accidental.

In practice, it's harmless for nfsd. While there is a delegation
outstanding, it doesn't consult i_version anyway, and i_version is
updated when the delegation is released.

It might be worth making this more consistent at some point just for
neatness sake though, or in case we want to use i_version some other
way. I'll think about it.
-- 
Jeff Layton <jlayton@kernel.org>