On Monday 15 February 2016 08:00:50 Dave Chinner wrote: > On Sat, Feb 13, 2016 at 05:46:11PM -0800, Deepa Dinamani wrote: > > On Sat, Feb 13, 2016 at 2:08 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > > On Fri, Feb 12, 2016 at 01:36:05AM -0800, Deepa Dinamani wrote: > So, excuse me if I made a mistake and missed something in a patchset > that a) had 3 different versions posted, b) is way too fine-grained, > and c) being treated like a mountain when it's really a tiny > molehill. I do have much more important things to do with my time > than be dragged into another silly "oh this is so difficult and > hard" bikeshedding argument when I could easily write the entire > patchset to do a timespec64 changeover for the VFS in a couple of > hours. It's just not that hard to do. > > And, FWIW, I'm still waiting to hear how we're going to regression > test all this. Has anyone written any xfstests yet to ensure that > all the filesystems behave the same and we won't break anything in > future as we add 64 bit timestamp support to filesystem on-disk > formats? IMO, there's more work in writing the regression tests to > make sure everything works correctly in all the different possible > combinations of filesystem, kernel and userspace support (e.g. 32 on 32, > 32 on 64, 64 on 32 and 64 on 64). I'm much more concerned about > this aspect of the problem than actually changing the VFS > code, because without it we can't verify the changes we are making > are behaving correctly... You are mixing up way too many things here, for this series all we need is for you to say that one of the approaches is ok, and they are all to the point where they are simple enough that they don't really do much at all. Deepa is taking baby steps here because you complained about v1 being too complex. This series is not about changing the on-disk format, it is not even changing the VFS time format (yet), it's just a preparation so we can eventually change it. There are four different things that are going on at the same time, all independent of one another: 1. Changing the file systems so we are able to do the change in struct inode, this series. The *only* part we care about here is that this does not change the existing behavior on either 32-bit or 64-bit systems, and that should be trivial to review. 2. Changing the file systems to provide information to VFS about the time stamp ranges they support in order to do proper handling of overflows in VFS. Deepa has posted a first set of patches to always use current_fs_time() consistently, work on that is continuing and once done, we can debate the policy for what should happen in case of overflow. 3. Writing test cases in xfstests and/or LTP. Yes, we need them, and I think Deepa has started on those, but I don't think they are needed at this point as there is little to test before steps 1 and 2 are done. 4. Changing file systems to use longer on-disk timestamps where needed. This is completely independent of anything else and up to the individual file system developers. Anyone can test this now on 64-bit architectures, and most file systems we care about (xfs being the notable exception, ext4 also until very recently) already do this properly. After 1, 2 and 3 are done, the simple patch to switch over VFS can be implemented and tested, followed by whatever work remains to switch over file systems to use 64-bit timestamps in the kernel (independent of what they use on disk, again). My current line of thinking is that for step 1, I'd let Deepa pick one of the three approaches she posted (I don't think we found any showstoppers), and put the patches in my y2038 tree for merging in 4.6. We can easily leave out the file systems that have conflicts against linux-next, and you can put Deepa's patch or another implementation of that into 4.7. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
