From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753325AbaFBTFj (ORCPT ); Mon, 2 Jun 2014 15:05:39 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:45866 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753022AbaFBTFg convert rfc822-to-8bit (ORCPT ); Mon, 2 Jun 2014 15:05:36 -0400 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: [RFC 11/32] xfs: convert to struct inode_time From: Chuck Lever In-Reply-To: <1401735504.6065.227.camel@montana.filmlight.ltd.uk> Date: Mon, 2 Jun 2014 15:04:27 -0400 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 Content-Transfer-Encoding: 8BIT Message-Id: References: <1401480116-1973111-1-git-send-email-arnd@arndb.de> <8618458.1EVJCoVbkH@wuerfel> <4178301.j9kWdGCRLC@wuerfel> <6868F108-F0B2-423F-AE31-90DF86A5B7DD@oracle.com> <1401735504.6065.227.camel@montana.filmlight.ltd.uk> To: Roger Willcocks X-Mailer: Apple Mail (2.1878.2) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Jun 2, 2014, at 2:58 PM, Roger Willcocks wrote: > > 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. You would have to get the IETF’s NFSv4 working group to sign off on this change. Otherwise, Linux would be the only NFSv3 implementation that supports the extension. But I suspect the answer you’d get is “Use NFSv4.” > 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.) There’s no reliable way in NFSv3 for clients and servers to identify the software running on the peer. Practically speaking, you should assume that the NFSv3 protocol is never going to change. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com