Announcement

Collapse
No announcement yet.

XFS File-System With Linux 5.10 Punts Year 2038 Problem To The Year 2486

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

  • XFS File-System With Linux 5.10 Punts Year 2038 Problem To The Year 2486

    Phoronix: XFS File-System With Linux 5.10 Punts Year 2038 Problem To The Year 2486

    Not only is Btrfs seeing notable improvements with the in-development Linux 5.10 kernel but the XFS file-system also has some prominent changes of its own...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Only to the year 2486?

    Comment


    • #3
      Originally posted by Duff~ View Post
      Only to the year 2486?
      Yeah, with nanosecond timestamps, even at 64-bit, that's about what you get.

      (Quick check : (2^64 nanoseconds / (about 10^9*3600*24*365.25 nanoseconds in a year) = 584.542 years, add 1970 years to account for the Unix epoch and you get a max year of 2554, which is just a little bit above what's announced but when manipulating such large numbers it may just be a rounding error of my calculator or imprecision caused by my approximation of the number of days in a year)

      You can go beyond that with more timestamp bits or less precision, but honestly it would be sad if we were still using XFS in 2554 (assuming there are still humans around at that time).
      Last edited by HadrienG; 15 October 2020, 01:31 AM.

      Comment


      • #4
        Note: The upper limit is 2486 (and not 2554) because the XFS timestamp epoch still starts in December 1901 (aka ~2 billion seconds before 1970). I hope we're not still using XFS in the 25th century.

        I wanted to stretch it to 2525 just so I could sing "In the year 2525, if man is still alive, and XFS can survive..." but nobody thought it was acceptable to lose support for timestamps that worked on the old filesystems just for the sake of a song. (Myself included.)

        I mean, if you designed your fs so that the timestamp epoch started the day that song came out, you actually /can/ get to 2525 with a 64-bit nanosecond counter. :P

        Comment


        • #5
          ^ a man who has never read Seveneves ^

          Comment


          • #6
            Leave it to developers to make sure they have some more work to do later..

            Comment


            • #7
              We need a file system that can count at least 10,000 years and a billion tears.

              Comment


              • #8
                Is this a backward compatible change or does it require reformatting?

                Comment


                • #9
                  Originally posted by djwong View Post
                  Note: The upper limit is 2486 (and not 2554) because the XFS timestamp epoch still starts in December 1901 (aka ~2 billion seconds before 1970). I hope we're not still using XFS in the 25th century.

                  I wanted to stretch it to 2525 just so I could sing "In the year 2525, if man is still alive, and XFS can survive..." but nobody thought it was acceptable to lose support for timestamps that worked on the old filesystems just for the sake of a song. (Myself included.)

                  I mean, if you designed your fs so that the timestamp epoch started the day that song came out, you actually /can/ get to 2525 with a 64-bit nanosecond counter. :P
                  Out of pure curiosity, are nanoseconds really needed? Why microseconds aren't enough?

                  Comment


                  • #10
                    Originally posted by jaxa View Post
                    We need a file system that can count at least 10,000 years and a billion tears.
                    I remember reading that, when they moved from 68k to PPC, Apple upped the date limit from 2040 to 29,940.

                    Comment

                    Working...
                    X