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

Valerie Aurora <[email protected]> Thu, 12 Mar 2026 12:04:21 +0100
Newsgroups dev.linux.lists.rpdfs-devel
Message-ID <CALGtELict9WKKOTDuRX5cskiXWi5SG+JaEqTLJctA3SEE63mPg@mail.gmail.com>
On Wed, Mar 11, 2026 at 6:59=E2=80=AFPM Zach Brown <[email protected]> wrote:
>
> On Tue, Mar 10, 2026 at 06:31:40PM +0100, Valerie Aurora wrote:
> > +/*
> > + * Set the inode creation time.
> > + */
> > +void rpdfs_inode_crtime_set(struct rpdfs_fs_info *rfi, struct rpdfs_tr=
ansaction *txn,
> > +                         struct inode *inode, struct timespec64 ts)
> > +{
> > +     struct rpdfs_block_handle *hnd =3D NULL;
> > +     struct rpdfs_inode *rinode;
> > +     int ret;
> > +
> > +     ret =3D rpdfs_txn_use_prepared(rfi, txn, rpdfs_inode_bnr(inode), =
&hnd, RBAF_WRITE);
> > +     BUG_ON(ret < 0); /* caller must have prepared */
> > +
> > +     rinode =3D hnd->data;
> > +     rinode->crtime_nsec =3D cpu_ts64_to_le64_ns(ts);
> > +}
>
> The pattern is that the in-memory inode (struct rpdfs_inode_info) is a
> struct that has private fs stuff along with the storage for the vfs
> inode.  This is the FOO_I() pattern found all over fs/*.  Refreshing the
> inode updates the in-memory version from the current block, and the "txn
> update" of the inode copies from memory to the block again.
>
> 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.

> Then in the apply phase that wants to update crtime it updates the
> in-memory copy with something like:
>
>         struct rpdfs_inode_info *ri =3D RPDFS_I(inode);
>         ri->crtime_nsec =3D inode_atime_to_u64_nsec_or_whatever(inode);
>
> This re-uses the current load from and store to the block and avoids
> another block hash lookup -- which is a bunch of rcu and spinlock
> barriers and will be a point of contention.

That's a good point. The other option I thought of is a
rpdfs_inode_txn_update_create() that takes a creation time arg and is
only used at inode creation.

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

Valerie