[OT] Re: [PATCH 86/87] fs: switch timespec64 fields in inode to discrete integers

Gabriel Paubert <[email protected]> Sun, 1 Oct 2023 07:01:56 +0200

Newsgroups	gmane.comp.file-systems.btrfs,gmane.linux.uml.devel,gmane.linux.usb.general,gmane.linux.kernel,gmane.network.samba.internals,gmane.comp.file-systems.nilfs.user,gmane.comp.file-systems.coda.general,gmane.comp.file-systems.reiserfs.general,gmane.linux.file-systems.ntfs.devel,gmane.linux.file-systems.f2fs,gmane.linux.kernel.efi,gmane.linux.drivers.mtd,gmane.linux.drivers.rdma,gmane.linux.kernel.autofs,gmane.comp.file-systems.ceph.devel,gmane.linux.nfs,gmane.linux.file-systems,gmane.linux.kernel.bpf,gmane.linux.kernel.mm,gmane.linux.serial,gmane.linux.kernel.cifs,gmane.comp.security.apparmor,gmane.linux.network,gmane.linux.file-systems.union,gmane.linux.kernel.lsm,gmane.linux.ports.ppc64.devel,gmane.linux.hardware.karma.devel
Message-ID	<[email protected]>

Newsgroups

gmane.comp.file-systems.btrfs,gmane.linux.uml.devel,gmane.linux.usb.general,gmane.linux.kernel,gmane.network.samba.internals,gmane.comp.file-systems.nilfs.user,gmane.comp.file-systems.coda.general,gmane.comp.file-systems.reiserfs.general,gmane.linux.file-systems.ntfs.devel,gmane.linux.file-systems.f2fs,gmane.linux.kernel.efi,gmane.linux.drivers.mtd,gmane.linux.drivers.rdma,gmane.linux.kernel.autofs,gmane.comp.file-systems.ceph.devel,gmane.linux.nfs,gmane.linux.file-systems,gmane.linux.kernel.bpf,gmane.linux.kernel.mm,gmane.linux.serial,gmane.linux.kernel.cifs,gmane.comp.security.apparmor,gmane.linux.network,gmane.linux.file-systems.union,gmane.linux.kernel.lsm,gmane.linux.ports.ppc64.devel,gmane.linux.hardware.karma.devel

Message-ID

<[email protected]>

On Sat, Sep 30, 2023 at 09:50:41AM -0500, Steve French wrote:
> On Fri, Sep 29, 2023 at 3:06 AM David Howells via samba-technical
> <[email protected]> wrote:
> >
> >
> > Jeff Layton <[email protected]> wrote:
> >
> > > Correct. We'd lose some fidelity in currently stored timestamps, but as
> > > Linus and Ted pointed out, anything below ~100ns granularity is
> > > effectively just noise, as that's the floor overhead for calling into
> > > the kernel. It's hard to argue that any application needs that sort of
> > > timestamp resolution, at least with contemporary hardware.
> >
> > Albeit with the danger of making Steve French very happy;-), would it make
> > sense to switch internally to Microsoft-style 64-bit timestamps with their
> > 100ns granularity?
> 
> 100ns granularity does seem to make sense and IIRC was used by various
> DCE standards in the 90s and 2000s (not just used for SMB2/SMB3 protocol and
> various Windows filesystems)

Historically it probably comes from VMS, where system time and file
timestamps were a 64 bit integer counting in 100ns units starting on MJD
2400000.5 (Nov 17th 1858).

Gabriel

> 
> 
> -- 
> Thanks,
> 
> Steve