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

[David Sterba]

On Mon, Nov 09, 2026 at 11:48:12AM -0500, Jeff Layton wrote:
> 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@xxxxxxxxxx>
> > > ---
> > > 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.

Thanks for the exmpalation, this seems nuanced enough for the AI review
to miss something.