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 | 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 | <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