Re: [PATCH 2/2] rpdfs: Set the inode creation time

On Thu, Mar 12, 2026 at 12:04:21PM +0100, Valerie Aurora wrote:
> On Wed, Mar 11, 2026 at 6:59 PM Zach Brown <[email protected]> wrote:
> >
> > On Tue, Mar 10, 2026 at 06:31:40PM +0100, Valerie Aurora wrote:

> > > +     rinode = hnd->data;
> > > +     rinode->crtime_nsec = cpu_ts64_to_le64_ns(ts);
> > > +}

[...]

> > So the way to do this is to have a local copy of the crtime in the
> > rpdfs_inode_info.  Copy it back and forth in copy_vfs_inode_to_rinode()
> > and vice versa.
> 
> The reason I didn't do this is that creation time is only set at inode
> creation time and almost never read, so it seems like a waste of
> memory to put it in the rpdfs_inode_info. It's only accessed through
> getattr, so that needs to do its own separate block lookup anyway.

I like the instinct but I think in this case the memory savings isn't
worth the special case and additional code.  VFS inodes are immense, I
imagine we're down in the single digit percentages.  (ish, yeah, say
around 8/728)

There's also some forward-looking context that might not be obvious and
which is probably nudging my preference.

While it takes a block lookup today to validate the cached inode
contents, that's not necessarily always going to be the case.  We're
going to get cached vfs objects (dentries -> d_revalidate) where the
validation frequency is so bonkers that we'll probably want to modify
the cached object on invalidation rather than always doing block
lookups.  The revalidate test could be a local seqlock test, or
something, rather than the global hash table lookup.

> But if you prefer, we can keep creation time in rpdfs_inode_info. Let
> me know what you want.

Yes please!  I like the consistency across this class of inode metadata.

- z