* [XFS SUMMIT] 64bit timestamps
@ 2020-04-22 23:03 Darrick J. Wong
2020-04-23 6:23 ` Amir Goldstein
0 siblings, 1 reply; 3+ messages in thread
From: Darrick J. Wong @ 2020-04-22 23:03 UTC (permalink / raw)
To: xfs; +Cc: amir73il
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [XFS SUMMIT] 64bit timestamps
2020-04-22 23:03 [XFS SUMMIT] 64bit timestamps Darrick J. Wong
@ 2020-04-23 6:23 ` Amir Goldstein
2020-04-23 16:23 ` Darrick J. Wong
0 siblings, 1 reply; 3+ messages in thread
From: Amir Goldstein @ 2020-04-23 6:23 UTC (permalink / raw)
To: Darrick J. Wong; +Cc: xfs
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [XFS SUMMIT] 64bit timestamps
2020-04-23 6:23 ` Amir Goldstein
@ 2020-04-23 16:23 ` Darrick J. Wong
0 siblings, 0 replies; 3+ messages in thread
From: Darrick J. Wong @ 2020-04-23 16:23 UTC (permalink / raw)
To: Amir Goldstein; +Cc: xfs
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-04-23 16:25 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-04-22 23:03 [XFS SUMMIT] 64bit timestamps Darrick J. Wong
2020-04-23 6:23 ` Amir Goldstein
2020-04-23 16:23 ` Darrick J. Wong
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).