From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753276AbaFBS61 (ORCPT ); Mon, 2 Jun 2014 14:58:27 -0400 Received: from b.mx.filmlight.ltd.uk ([77.107.81.251]:6833 "HELO b.mx.filmlight.ltd.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1753241AbaFBS6Z (ORCPT ); Mon, 2 Jun 2014 14:58:25 -0400 Subject: Re: [RFC 11/32] xfs: convert to struct inode_time From: Roger Willcocks To: Chuck Lever Cc: Arnd Bergmann , Nicolas Pitre , linux-arch@vger.kernel.org, Linux NFS Mailing List , LKML Kernel , lftan@altera.com, Christoph Hellwig , john.stultz@linaro.org, "H. Peter Anvin" , linux-fsdevel , geert@linux-m68k.org, tglx@linutronix.de, xfs@oss.sgi.com, joseph@codesourcery.com In-Reply-To: <6868F108-F0B2-423F-AE31-90DF86A5B7DD@oracle.com> References: <1401480116-1973111-1-git-send-email-arnd@arndb.de> <8618458.1EVJCoVbkH@wuerfel> <4178301.j9kWdGCRLC@wuerfel> <6868F108-F0B2-423F-AE31-90DF86A5B7DD@oracle.com> Content-Type: text/plain Date: Mon, 02 Jun 2014 19:58:24 +0100 Message-Id: <1401735504.6065.227.camel@montana.filmlight.ltd.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-19.el5) Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2014-06-02 at 11:04 -0400, Chuck Lever wrote: > NFSv2/3 timestamps are a pair of unsigned 32-bit values: one value for > seconds since midnight GMT Jan 1, 1970, and one value for nanoseconds. > (See the definition of nfstime3 in RFC 1813). > nfstime3 could be extended by redefining the otherwise unused nanoseconds bits{31,30} as seconds{33,32}, to give a (signed) 34-bit seconds field and an unsigned 30-bit nanoseconds field. This could represent 1970 +/- 272 years. Servers could indicate they can understand the extended time format by adding a new FSINFO capability - FSF3_CANSETTIME_EX. Clients would use a new SET_TO_CLIENT_TIME_EX time_how enum when sending timestamps so old servers would be protected from new clients. Old clients don't need to be protected from new servers because the on-the-wire bit pattern for dates between 1970 and 2106 stays the same, so they're no worse off than they were before. Arguably the new server ought to clamp out-of-range timestamps before sending them to old clients but that would need per-client state (and nfs3 is stateless.) -- Roger