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 | gmane.comp.file-systems.btrfs,gmane.linux.file-systems,gmane.linux.kernel,gmane.linux.kernel.mm,gmane.linux.ports.ppc64.devel,gmane.linux.drivers.platform.x86.devel,gmane.linux.drivers.rdma,gmane.linux.serial,gmane.linux.usb.general,gmane.linux.kernel.autofs,gmane.comp.file-systems.ceph.devel,gmane.comp.file-systems.coda.general,gmane.linux.kernel.efi,gmane.comp.file-systems.ext4,gmane.linux.file-systems.f2fs,gmane.linux.uml.devel,gmane.linux.drivers.mtd,gmane.linux.nfs,gmane.comp.file-systems.nilfs.user,gmane.linux.file-systems.ntfs.devel,gmane.linux.hardware.karma.devel,gmane.linux.file-systems.union,gmane.comp.file-systems.reiserfs.general,gmane.linux.kernel.cifs,gmane.network.samba.internals,gmane.linux.kernel.bpf,gmane.linux.network,gmane.comp.security.apparmor,gmane.linux.kernel.lsm |
|---|---|
| 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]>