Re: [PATCH 86/87] fs: switch timespec64 fields in inode to discrete integers
Jeff Layton <[email protected]> Fri, 29 Sep 2023 06:16:57 -0400
| Newsgroups | org.kernel.vger.reiserfs-devel,dev.linux.lists.gfs2,dev.linux.lists.ntfs3,dev.linux.lists.ocfs2-devel,dev.linux.lists.v9fs,net.sourceforge.lists.linux-f2fs-devel,org.infradead.lists.linux-mtd,org.infradead.lists.linux-um,org.kernel.vger.autofs,org.kernel.vger.bpf,org.kernel.vger.ceph-devel,org.kernel.vger.linux-btrfs,org.kernel.vger.linux-cifs,org.kernel.vger.linux-efi,org.kernel.vger.linux-ext4,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-hardening,org.kernel.vger.linux-kernel,org.kernel.vger.linux-nfs,org.kernel.vger.linux-nilfs,org.kernel.vger.linux-rdma,org.kernel.vger.linux-s390,org.kernel.vger.linux-security-module,org.kernel.vger.linux-serial,org.kernel.vger.linux-trace-kernel,org.kernel.vger.linux-unionfs,org.kernel.vger.linux-usb,org.kernel.vger.linux-xfs,org.kernel.vger.netdev,org.kernel.vger.platform-driver-x86,org.kernel.vger.selinux,org.kvack.linux-mm,org.ozlabs.lists.linux-erofs,org.ozlabs.lists.linuxppc-dev |
|---|---|
| Message-ID | <[email protected]> |
On Fri, 2023-09-29 at 11:44 +0200, Christian Brauner wrote:
> > It is a lot of churn though.
>
> I think that i_{a,c,m}time shouldn't be accessed directly by
> filesystems same as no filesystem should really access i_{g,u}id which
> we also provide i_{g,u}id_{read,write}() accessors for. The mode is
> another example where really most often should use helpers because of all
> the set*id stripping that we need to do (and the bugs that we had
> because of this...).
>
> The interdependency between ctime and mtime is enough to hide this in
> accessors. The other big advantage is simply grepability. So really I
> would like to see this change even without the type switch.
>
> In other words, there's no need to lump the two changes together. Do the
> conversion part and we can argue about the switch to discrete integers
> separately.
>
> The other adavantage is that we have a cycle to see any possible
> regression from the conversion.
>
> Thoughts anyone?
That works for me, and sort of what I was planning anyway. I mostly just
did the change to timestamp storage to see what it would look like
afterward.
FWIW, I'm planning to do a v2 patchbomb early next week, with the
changes that Chuck suggested (specific helpers for fetching the _sec and
_nsec fields). For now, I'll drop the change from timespec64 to discrete
fields. We can do that in a separate follow-on set.
--
Jeff Layton <[email protected]>