> > 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 :-) Thanks, Amir.
