Re: [RFC][PATCH] xfs: extended timestamp range

["Darrick J. Wong" <darrick.wong@oracle.com>]

On Wed, Nov 13, 2019 at 07:17:06AM +0200, Amir Goldstein wrote:
> >
> > Practically speaking I'd almost rather drop the precision in order to
> > extend the seconds range, since timestamp updates are only precise to
> > HZ anyway.
> >
> 
> FWIW, NTFS and CIFS standard is unsigned 64bit of 100 nanoseconds
> counting from Jan 1, 1601.
> 
> >
> > Heh, ok.  I'll add an inode flag and kernel auto-upgrade of timestamps
> > to the feature list.  It's not like we're trying to add an rmap btree to
> > the filesystem. :)
> >
> 
> Exactly.
> 
> > >
> > > All right, so how do we proceed?
> > > Arnd, do you want to re-work your series according to this scheme?
> >
> > Lemme read them over again. :)
> >
> > > Is there any core xfs developer that was going to tackle this?
> > >
> > > I'm here, so if you need my help moving things forward let me know.
> >
> > I wrote a trivial garbage version this afternoon, will have something
> > more polished tomorrow.  None of this is 5.6 material, we have time.
> >
> 
> I wonder if your version has struct xfs_dinode_v3 or it could avoid it.
> There is a benefit in terms of code complexity and test coverage
> to keep the only difference between inode versions in the on-disk
> parsers, while reading into the same struct, the same way as
> old inode versions are read into struct xfs_dinode.
> 
> Oh well, I can wait for tomorrow to see the polished version :-)

Well now we noticed that Arnd also changed the disk quota structure
format too, so that'll slow things down as we try to figure out how to
reconcile 34-bit inode seconds vs. 40-bit quota timer seconds.

(Or whatever happens with that)

--D

> Thanks,
> Amir.