Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • coder
    replied
    Originally posted by fitzie View Post
    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/

    ...
    Now that 292 year range has become 29,247
    years, and filesystem people *might* find the "year-31k" problem
    acceptable.​
    ...

    LOL. I have no time for people who insist on solving the "year 2262" problem, today.

    The thing I like about nanosecond timestamps is that it gives you the ability to do much finer-grained synchronization than 0.1 microsecond. If this is only concerning filesystem timestamps, then I'd agree that 0.1 microsecond might be okay, however I doubt these timestamps will stay limited to filesystems.

    Originally posted by NotMine999 View Post
    are there any timestamp-able Linux functions within the Linux OS that occur in a timeframe less than a tenth of a microsecond?
    Within the kernel or using io_uring, sure!

    If you're going to insist on including syscall overhead, then no. Not today, at least.
    Last edited by coder; 25 September 2023, 05:45 AM.

    Leave a comment:


  • Sonadow
    replied
    Originally posted by fitzie View Post

    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/
    Maybe the smarter thing to do is to just ask Christian how the Windows kernel does it, and then implement something similar yet slightly different.

    Leave a comment:


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

    Leave a comment:


  • fitzie
    replied
    Originally posted by NotMine999 View Post
    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.

    Leave a comment:


  • NotMine999
    replied
    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?"

    Leave a comment:


  • zexelon
    replied
    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.

    Leave a comment:


  • JEBjames
    replied
    Michael

    typo

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

    Leave a comment:


  • timofonic
    replied
    Originally posted by stormcrow View Post

    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!
    Last edited by timofonic; 24 September 2023, 11:41 AM.

    Leave a comment:


  • fitzie
    replied
    Originally posted by timofonic View Post
    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
    Last edited by fitzie; 24 September 2023, 11:17 AM. Reason: fix url

    Leave a comment:


  • stormcrow
    replied
    Originally posted by timofonic View Post
    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?

    Leave a comment:

Working...
X