Re: d_time and d_fsdata

On Mon, 6 Jul 2026 at 13:58, NeilBrown <[email protected]> wrote:
>
> On Mon, 06 Jul 2026, Miklos Szeredi wrote:

> > Wanted to get rid of d_time, as it is no longer used by VFS, only a
> > handful of filesystems.   Still a worthwhile goal, IMO.
>
> I thought it might have been that.  Do you recall why you didn't
> complete the job?

Probably got sidetracked and forgotten.

> There aren't many filesystems that use both ->d_time and ->d_fsdata.
> Just nfs and fuse I think, plus cifs and afs which I'm trying to change
> and could manage with a DCACHE_PRIVATE bit rather than ->d_fsdata.
>
> fuse could move the d_time field into fuse_dentry at the cost of an
> extra dereference.  That would mostly affect fuse_dentry_revalidate as
> other places that access d_time also access d_fsdata so it would just be
> another cache access.

This use was recently added and I didn't pay enough attention to this
when reviewing.  I'll tackle this.

> nfs is more complex.  It uses d_fsdata for 3 different things.
>   - the "block opens" flag that I added and could be in d_flags
>   - a path name - only for the IS_ROOT() dentry
>   - nfs_unlinkdata - only for DCACHE_NFSFS_RENAMED which need to
>     be unlinked on last close.  This is only ever present on
>     regular files, so we could repurpose d_children, but that is
>     a bit icky...  Maybe we don't need a d_time for DCACHE_NFSFS_RENAMED
>     dentries - they are quite special.
> Also nfs uses the lsb of d_time to indicate something about delegation,
> so it only uses 63 bits of d_time (31 on 32bit hosts).
>
> d_flags currently has 4 unused bits.  I want one more for locking
> changes.  Allocating 1 for fs-private use (e.g blocking opens) might be
> acceptable. 2 might be a hard sell.
>
> We could probably make it work, but I don't want to distract my self
> with it just now.

Fine.  But not adding new users when not absolutely necessary would be
a good thing, IMO.

Thanks,
Miklos