Linux's Multi-Grain Timestamps Short-Lived: Removed From The Kernel After A Few Weeks

[phoronix]

Phoronix: Linux's Multi-Grain Timestamps Short-Lived: Removed From The Kernel After A Few Weeks

One of the new features merged for the Linux 6.6 kernel was multi-grained timestamps for the VFS layer and wiring it up for the EXT4, Btrfs, XFS, and Tmpfs file-systems. This alternative though to coarse-grained timestamps ended up exposing some problems and this week ahead of Linux 6.6-rc3, the feature has been stripped entirely from the kernel...

https://www.phoronix.com/news/Linux-Revert-MG-Timestamps

[timofonic]

Yes, but he didn't propose a future alternative.

What about new syscalls or whatever for fine grained?

[stormcrow]

Yes, but he didn't propose a future alternative.

What about new syscalls or whatever for fine grained?

So? Removing a poorly thought out feature before it can be rolled out to the point of being irretrievable is the right call regardless of whether there's an immediate alternative. Did you even read the quoted post?

[fitzie]

Yes, but he didn't propose a future alternative.

What about new syscalls or whatever for fine grained?

There's some discussion on fsdevel about 100ns granularity 64bit time, to replace the separate sec/nsec format in use today. From here: https://lore.kernel.org/linux-fsdevel/CAHk-=whAwTJduUZTrsLFnj1creZMfO7eCNERHXZQmzX+qLqZMA@mai l.gmail.com/

...

But if we were to say that "a tenth of microsecond resolution is
sufficient for inode timestamps", then suddenly 64 bits is *enormous*.
So we could do a

// tenth of a microseconds since Jan 1, 1970
typedef s64 fstime_t;

and have a nice dense timestamp format with reasonable - but not
nanosecond - accuracy. Now that 292 year range has become 29,247
years, and filesystem people *might* find the "year-31k" problem
acceptable.

I happen to think that "100ns timestamp resolution on files is
sufficient" is a very reasonable statement, but I suspect that we'll
still find lots of people who say "that's completely unacceptable"
both to that resolution, and to the 31k-year problem.

But wouldn't it be nice to have just one single "fstime_t" for file
timestamps, the same way we have "ktime_t" for CPU timestamps?

Then we'd save even more space in the 'struct inode'....

Linus

[timofonic]

So? Removing a poorly thought out feature before it can be rolled out to the point of being irretrievable is the right call regardless of whether there's an immediate alternative. Did you even read the quoted post?

I did read the quoted post. I'm aware of this.

I was just waiting for someone perceptive and proactive like you to address it!

I wonder WHY that feature got merged so prematurely!

He just mentioned some alternatives. He should have opened the debate and do a lot more thoroughly testing processes before merging. That's a very critical part of the kernel code.

It's interesting how some PoC get merged swiftly, while technically superior ones often face prolonged review and debates.

Its extremely hard to ignore the substantial funding Microsoft provides to organizations like the Linux Foundation and many others. Who knows, maybe that may indeed influence to have what some refer to as «preferencial treatment»

Let's brainstorm solutions! Share your insights on context-driven timestamps, smarter I/O scheduling, or other game-changing ideas. Your input is the key to progress!

fitzie Thanks a lot for your reply!

[JEBjames]

Michael

typo

"current corarse-grained" should probably be "current coarse-grained"

[zexelon]

Okay Christian Brauner is clearly one of a very small handful of reasonable Linux devs left after the last couple of months of sandbox fighting we have seen. Even better he works for Microsoft! This culture of quality expectations must clearly come from within Microsoft... because if this was a true Linux dev, they would have died on the hill to keep this code in!

To boot this code doesn't even cause any significant bugs today... it was pulled due to the realization that it could cause edge case future bugs! I wish I could get to know Christian better, clearly he is not the norm in the Linux community.

Kudos to Christian and his team for putting quality first and having the strength of character to pull something that did not meet their final quality desires.

[NotMine999]

fitzie I am not going to re-quote your fine post, but it got me wondering. If Linus' proposal, as shown in your post, were adopted, are there any timestamp-able Linux functions within the Linux OS that occur in a timeframe less than a tenth of a microsecond?

And I ask the question a different way - "If a tree fell in the forest and nobody was around to hear it fall, would anyone care that it even fell down?"

[fitzie]

fitzie I am not going to re-quote your fine post, but it got me wondering. If Linus' proposal, as shown in your post, were adopted, are there any timestamp-able Linux functions within the Linux OS that occur in a timeframe less than a tenth of a microsecond?

And I ask the question a different way - "If a tree fell in the forest and nobody was around to hear it fall, would anyone care that it even fell down?"

cpu instructions are running in the sub nanosecond range (1ghz == 1 ns clock cycle), so the question is more about what's sufficient for the time fields of filesystems. if a save a file now, and it ends up with a timestamp in the past due to this truncation, something will notice it. and it's really a question of breaking the rules once, and letting the dust settle. filesystems should probably still allocation nanosecond or greater precision in their on disk format, for whatever the future holes, but the vfs should do fine with less granularity until computers get so fast, things like make start to break.

[rogerx]

Wish they'd do the same with all the ludicrously simple "How to install (package name)" articles.