[XFS SUMMIT] 64bit timestamps

[XFS SUMMIT] 64bit timestamps

[Darrick J. Wong]

Hi all,

Here's a thread to talk about the remainder of 64-bit timestamp support
on XFS.  I have a series[1] that redefines the inode timestamps to be
64-bit nanosecond counters and decreases the accuracy of the ondisk
quota timers to 4s so that both will last until 2446.

--D

[1] https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=bigtime

Re: [XFS SUMMIT] 64bit timestamps

[Amir Goldstein]

On Thu, Apr 23, 2020 at 2:03 AM Darrick J. Wong <darrick.wong@oracle.com> wrote:
>
> Hi all,
>
> Here's a thread to talk about the remainder of 64-bit timestamp support
> on XFS.  I have a series[1] that redefines the inode timestamps to be
> 64-bit nanosecond counters and decreases the accuracy of the ondisk
> quota timers to 4s so that both will last until 2446.
>
> --D
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=bigtime

This looks great.

What's the plan w.r.t. enabling bigtime on existing fs?
In the end, it is just a administrative flag saying "point of no return".
Everyone do realize that fixing y2038 by requiring to reformat
existing filesystems is unacceptable for most of the deployments out there,
right?

Thanks,
Amir.

Re: [XFS SUMMIT] 64bit timestamps

[Darrick J. Wong]

On Thu, Apr 23, 2020 at 09:23:51AM +0300, Amir Goldstein wrote:
> On Thu, Apr 23, 2020 at 2:03 AM Darrick J. Wong <darrick.wong@oracle.com> wrote:
> >
> > Hi all,
> >
> > Here's a thread to talk about the remainder of 64-bit timestamp support
> > on XFS.  I have a series[1] that redefines the inode timestamps to be
> > 64-bit nanosecond counters and decreases the accuracy of the ondisk
> > quota timers to 4s so that both will last until 2446.
> >
> > --D
> >
> > [1] https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=bigtime
> 
> This looks great.
> 
> What's the plan w.r.t. enabling bigtime on existing fs?
> In the end, it is just a administrative flag saying "point of no return".
> Everyone do realize that fixing y2038 by requiring to reformat
> existing filesystems is unacceptable for most of the deployments out there,
> right?

Ah, right, I neglected to post a link to the userspace counterpart:

https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfsprogs-dev.git/log/?h=bigtime

xfs_admin will be able to flip on the feature flag, after which the
kernel will start upgrading files to use the bigtime format.

--D

> Thanks,
> Amir.