From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756993AbcBQJcT (ORCPT ); Wed, 17 Feb 2016 04:32:19 -0500 Received: from mout.kundenserver.de ([212.227.17.13]:62389 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754242AbcBQJcP (ORCPT ); Wed, 17 Feb 2016 04:32:15 -0500 From: Arnd Bergmann To: Dave Chinner Cc: Deepa Dinamani , linux-fsdevel@vger.kernel.org, y2038@lists.linaro.org, "Theodore Ts'o" , linux-kernel@vger.kernel.org, tglx@linutronix.de Subject: Re: [RFC v2a 11/12] net: ceph: use vfs_time data type instead of timespec Date: Wed, 17 Feb 2016 10:32 +0100 Message-ID: <2438729.xkTi4inPN7@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20160214210050.GS19486@dastard> References: <20160212092153.GA2368@deepa-ubuntu> <20160214210050.GS19486@dastard> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:xOrD7W0yIFgoJizoOAE37aRKGlVvWHukEmPGkYDSUFkRPILCSZp j9P6rrkvfjIpidoM+8SpgAzZyc8Hf9SLifsNJOWslQikbKt4bItQf/QEsYQjJFoNh5aJUGD 1Ka7vGPyQnS7vtTSjU+Vccm43sH4evfR9sxNlbieICAm+QY+FMRsXWiTcDLK7Il0KD8e68i H5BMUcB3CJN/gISUZ13tA== X-UI-Out-Filterresults: notjunk:1;V01:K0:i3PIJasVlRs=:BvRkezPmFc+S8Gklv0/E3V wpfuHRxZkoq5KUFq1NIZBwsf3w2gQmk3LvC7sk+Dywlh40alDvDQpyAOmabXB0d1/7AktvbeW Kr1HkwJQ0l4rm4sNyqCfWQMDgjn9207wJodb51EAbO3yqxKbavKqMsKkBhIJAJRAb0WjE72Qg DQbB2YzMq9WLWzYrQgKsHVL7j8aQt4xkdS2ksZ4ZxuPuHmmdEkd0jvkFYVq6k0AbIfRfZ5pls oVFjBpkklJBq3r3ANYxXP4IppDww9yp5yB9NoTlnJ+JGC3M5gN2DYDFZXb0NXRLeNWrYNElaq K0O1FLktwegiFD4bwKVT1Ellb2PyrSSpO8BmBIShgwZl7wNRVm6gW02asLagytHphvQEUKLoM 4toNERFvSpteg7fNUg+YXlZTNLZiWVAbIK/gPvxZORzM29hbN32K0ga1x4lBzmW6Z8CM95cNL qaOGRcybyG1G2kwTyc5wyEyqUGop69JsAcpSBWHNs/1GDtrVIVeboMD6vE5dUaY2V4KgXhu8T ujldrlyj8mZ6GJu4pOMXIlliia5kqDG+P1gWVq2iFrafdmd8i8FpQOUuNGah14yj30tRP/yRb fcARms+FikSZrfYHlUqB6jiLjwl1P4ArpJJlfAEad9ycdT0R9OpjI/YHpnlMATOBmURoh3eWj WJC14isnLKHoHIHub901wefNkvBhuF88pzeAA4ZJJvAD8unlnnzzmCm6RmL8snZmTCOWvGUUF 1+Ve8eQBLchwmT/X Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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