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

Steve French <[email protected]> Sat, 30 Sep 2023 09:50:41 -0500
Newsgroups gmane.comp.file-systems.btrfs,gmane.linux.uml.devel,gmane.linux.usb.general,gmane.linux.kernel,gmane.linux.kernel.mm,gmane.comp.file-systems.nilfs.user,gmane.comp.file-systems.coda.general,gmane.linux.ports.ppc64.devel,gmane.comp.file-systems.reiserfs.general,gmane.linux.file-systems.ntfs.devel,gmane.linux.file-systems.f2fs,gmane.linux.kernel.efi,gmane.linux.drivers.platform.x86.devel,gmane.linux.drivers.mtd,gmane.linux.drivers.rdma,gmane.linux.kernel.autofs,gmane.comp.file-systems.ceph.devel,gmane.linux.nfs,gmane.comp.file-systems.ext4,gmane.network.samba.internals,gmane.linux.network,gmane.linux.file-systems,gmane.linux.kernel.bpf,gmane.linux.file-systems.union,gmane.linux.serial,gmane.linux.kernel.cifs,gmane.comp.security.apparmor,gmane.linux.kernel.lsm,gmane.linux.hardware.karma.devel
Message-ID <CAH2r5ms14hPaz=Ex2a=Dj0Hz3XxYLRKFj_rHHekznTbNJ_wABQ@mail.gmail.com>
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)


-- 
Thanks,

Steve