On Sat, Sep 23, 2023 at 01:03:56PM -0700, Linus Torvalds wrote: > > Except it looks like ext4 actually does full nanosecond resolution (30 > bits for nanoseconds, 34 bits for seconds). Thus the "only a couple of > hundred years of range". Hmm, yeah, sorry, I misremembered. We did talk about possibly going with 100ns, but if I recall correctly, I think there was a desire that an arbitrary timespec64 should be encodable into an on-disk timestamp, and then back again, and hundreds of years of range was considered Good Enough (tm). > Except we'd do it without the EXT4_EPOCH_MASK conditionals, and I > think it would be better to have a bigger range for seconds. If you > give the seconds field three extra bits, you're comfortable in the > "thousands of years", and you still have 27 bits that can encode a > decimal "100ns". I might be screweing my math, but I believe 24 bits should be enough to code 10,000,000 units of 100ns (it's enough for 16,777,216), which should be sufficient. What am I missing? As far as how many seconds are needed, that's an area where people of good will can disagree. Given that I don't really believe a machine is going to be up for decades before we will need to reboot and update the kernel to address zero days, and LTS kernels are going to be supported for two years going forward, if what we're talking about is the in-memory time type, my personal opinion is that hundreds of years is plenty, since it's not hard to change the encoding later. Cheers, - Ted
