From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756603AbcARTxe (ORCPT ); Mon, 18 Jan 2016 14:53:34 -0500 Received: from mout.kundenserver.de ([212.227.126.134]:56660 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755979AbcARTx3 (ORCPT ); Mon, 18 Jan 2016 14:53:29 -0500 From: Arnd Bergmann To: Deepa Dinamani Cc: Andreas Dilger , "y2038@lists.linaro.org" , Dave Chinner , "linux-fsdevel@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [RFC 02/15] vfs: Change all structures to support 64 bit time Date: Mon, 18 Jan 2016 20:53:22 +0100 Message-ID: <16314879.ZTNSN2flN7@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20160118174012.GA17318@myubuntu.deepaubuntu.g7.internal.cloudapp.net> References: <1452144972-15802-1-git-send-email-deepa.kernel@gmail.com> <4660520.3fofykfu9a@wuerfel> <20160118174012.GA17318@myubuntu.deepaubuntu.g7.internal.cloudapp.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:0Q732FEpVvtxDsvGcwhMopESWLrL1hvpstkMk2w8HH+skMJnOI8 2YyZYk8zqnayPM6/KrGDsF3oYe6waaMRsFrkhRRHnhPIOxoBDPYm8JzQI1jVUnUiYxAkok4 HSeNe8lNgPgMPNb8fBEbUQ0Wll59yNyI8WEMrg9K8/Hzl7FDPFiUhkBC7YvVchuG4mKL7mt avZOf1DQ8y3SOHy2UFwMw== X-UI-Out-Filterresults: notjunk:1;V01:K0:SWb2PUqm868=:P0dZaMWWCnTv1R22KO03ol rG/0sKuBX2lKodCta4zF165rsm1BOiIHADmPnqYx7DesLJXd3omgiMUSXm4Cjb1izdTNfeAa9 RGwPN6qAkR+IqbM/ILXBUD5FFKerTZtalPLF9tePlY0SQ+xObcQ/9lARmnH6BXEm/Jzu7IIRg 5ykD1VZ+XybcdvsJiiN4rwKMPkXnFufglSyNI8FKQVeLSJyEg+ILAFnNp0Y5ujEsCotphPaRq +cPfAEbUvFWfA2J1Zq4qfZzEqgOGlcAaMSg2x8nOs3hngMPbJ8SBAzXOX0sTTpNaF3+PLfAgX 7K3JZ1LkkqiRKqVCszXS+glm89h7CBrZSgO6krSX/DE6sZliX9uss+ZQOTSgZjT+FKs1wiNrZ 0g8rmgL1Um9mXFBGxuJ3tfmvP7USVL3Phxc13Z4GHJqHkJyQZ30E1zfhOEHZXE+JUzqTkA+c1 VpwBauVe0MX6FC5993LsjcTrLAJEF1PQuyEPlqWJMvuty1iq8b2j9d3afaBNHSobr8LQkYu8Q M1U/OTeQLBc010rw2oEFFoFD8KE9a2NzzIa38czkT9xlbyKEmAKQ54Lghmiq96On4druG8HlI 1j9MMn2ll8bvCEDcZVk4SoUnN4VMpuK00arBP2TV7mFLalTUok1FVdRjpgO7Q8mAB6sVyYkfm VaqZpUPBVt8YAA0cA4F2jyw+UwkxLyD1nuGaBVzPMe3HmHKW21NQmyhyTH5INAjwr2TaNBDHQ llTsk1NTNlvkXRNz Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Monday 18 January 2016 09:40:12 Deepa Dinamani wrote: > On Mon, Jan 18, 2016 at 2:56 AM, Arnd Bergmann wrote: > > On Sunday 17 January 2016 22:09:26 Deepa Dinamani wrote: > >> Based on the discussion, here is how I propose to proceed: > > Sounds good to me. Step 3 of course is the hard one, and you may run into > > further problems with it, as we both have in our previous attempts to > > crack this nut, but with step 2 before it that may become manageable. > > Right, I don't agree with this approach and it will get very ugly. > I was just proposing a way to move forward because it looked like we are at > a stalemate. > > Maybe xfs doesn't have these problems but some of the other fs-es do. > And, these will need changing twice: before(to use 64 bit arithmetic > like cifs, use current_fs_time() like fat etc) and along with vfs. > > It will unnecessarily bloat the vfs switching to timespec64 code. > Below are 3 example filesystem changes that illustrates this problem: > > Ext4: > 1. cr_time > 2. Encode and Decode api's > > Both these ext4 changes need to made along with vfs change to ext4. > Many such fs exists and will make the vfs switch over very ugly. > > FAT: > 1. fat_time_fat2unix, fat_time_unix2fat > > Both the above 2 functions also will have to be modified along with vfs. > > CIFS: > 1. struct cifs_fscache_inode_auxdata - last_write_time, last_change_time > 2. cifs_fattr > 3. cifs_NTtimeToUnix, cifs_UnixTimeToNT, cnvrtDosUnixTm > > All the above cifs changes also need to be changed in the same patch as > vfs switch to timespec64. > > I don't think there is any nicer way to do this without having an > encapsulation layer like inode_timespec or accessors you mentioned to > change the underlying data type in the vfs. > > Also, this scheme is so outrageously ugly that you can easily miss > some change. There is no way of verifying the approach theoretically. > Of course, I will be using kernel tests like in other cases. I agree it's ugly and fragile to have one huge patch, but I think the best way to illustrate it is to make it as small as possible and then talk about whether that makes it acceptable or how we can work around the problems. Do you have an estimate what portion of the file systems need any changes at all before we can flip over VFS to the new types? If it's less than half, we you can try yet another variation (nothing new really, we are always dealing with the same few tricks): 1. add timestamp range checking and clamping 2. kill off CURRENT_TIME 3. for each file system that uses struct timespec internally to pass around inode timestamps, do one patch that adds a timespec_to_inode_time() and vice versa, which gets defined like static inline struct timespec timespec_to_inode(struct timespec t) { return t; } 4. change the internal representation in one patch that changes those helpers along with the struct members. 5. change the file systems to use timespec64 internally instead of timespec. Arnd