Re: d_time and d_fsdata

On Mon, 06 Jul 2026, Miklos Szeredi wrote:
> On Thu, 2 Jul 2026 at 04:11, NeilBrown <[email protected]> wrote:
> 
> > 10 years ago cifs *did* use ->d_time but was changed to use ->d_fsdata
> > by Miklos with no justification (a00be0e31f8d).  Miklos: do you have any
> > memory of why that was done?
> 
> 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?

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.

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.

Thanks,
NeilBrown