Thread (24 messages) 24 messages, 10 authors, 2023-10-01

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

From: Gabriel Paubert <hidden>
Date: 2023-10-01 05:39:24
Also in: autofs, bpf, ceph-devel, gfs2, linux-btrfs, linux-cifs, linux-efi, linux-f2fs-devel, linux-fsdevel, linux-hardening, linux-mm, linux-nfs, linux-rdma, linux-s390, linux-security-module, linux-serial, linux-trace-kernel, linux-um, linux-unionfs, linux-usb, linux-xfs, linuxppc-dev, lkml, ntfs3, ocfs2-devel, selinux

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
[off-list ref] wrote:
quoted

Jeff Layton [off-list ref] wrote:
quoted
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
 
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help