Message-ID: <2438729.xkTi4inPN7@wuerfel>
Date:	Wed, 17 Feb 2016 10:32 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Dave Chinner <david@...morbit.com>
Cc:	Deepa Dinamani <deepa.kernel@...il.com>,
	linux-fsdevel@...r.kernel.org, y2038@...ts.linaro.org,
	Theodore Ts'o <tytso@....edu>, linux-kernel@...r.kernel.org,
	tglx@...utronix.de
Subject: Re: [RFC v2a 11/12] net: ceph: use vfs_time data type instead of timespec

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@...morbit.com> 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

Powered by blists - more mailing lists