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.
