From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Joseph S. Myers" Subject: Re: [RFC 11/32] xfs: convert to struct inode_time Date: Mon, 2 Jun 2014 14:00:11 +0000 Message-ID: References: <1401480116-1973111-1-git-send-email-arnd@arndb.de> <1401480116-1973111-12-git-send-email-arnd@arndb.de> <20140531003712.GH14410@dastard> <5389252A.5050503@zytor.com> <20140531011450.GJ14410@dastard> <20140531055457.GK14410@dastard> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20140531055457.GK14410@dastard> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: xfs-bounces@oss.sgi.com Sender: xfs-bounces@oss.sgi.com To: Dave Chinner Cc: linux-arch@vger.kernel.org, Arnd Bergmann , linux-kernel@vger.kernel.org, lftan@altera.com, hch@infradead.org, john.stultz@linaro.org, "H. Peter Anvin" , linux-fsdevel@vger.kernel.org, geert@linux-m68k.org, tglx@linutronix.de, xfs@oss.sgi.com List-Id: linux-arch.vger.kernel.org On Sat, 31 May 2014, Dave Chinner wrote: > If we are changing the in-kernel timestamp to have a greater dynamic > range that anything we current support on disk, then we need support > for all filesystems for similar translation and constraint. The > filesystems need to be able to tell the kernel what they timestamp > range they support, and then the kernel needs to follow those > guidelines. And if the filesystem is mounted on a kernel that > doesn't support the current filesystem's timestamp format, then at > minimum that filesystem cannot do anything that writes a > timestamp.... > > Put simply: the filesystem defines the timestamp range that can be > used safely, not the userspace API. If the filesystem can't support > the date it is handed then that is an out-of-range error. Since > when have we accepted that it's OK to handle out-of-range data with > silent overflows or corruption of the data that we are attempting to > store? We're defining a new API to support a wider date range - > there is nothing that prevents us from saying ERANGE can be returned > to a timestamp that the file cannot store correctly.... I don't see anything new about this issue. All problems that could arise from the kernel being able to represent a timestamp some filesystems can't are problems that already apply with 64-bit kernels using 64-bit time_t internally. So while as part of Y2038-preparedness we do need a clear understanding of which filesystems have what timestamp limits and what happens with timestamps beyond those limits, I think this is a separate strand of the problem - one that applies to both 32-bit and 64-bit systems - from the more general issue for 32-bit systems. -- Joseph S. Myers joseph@codesourcery.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay1.mentorg.com ([192.94.38.131]:38421 "EHLO relay1.mentorg.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754640AbaFBOAP (ORCPT ); Mon, 2 Jun 2014 10:00:15 -0400 Date: Mon, 2 Jun 2014 14:00:11 +0000 From: "Joseph S. Myers" Subject: Re: [RFC 11/32] xfs: convert to struct inode_time In-Reply-To: <20140531055457.GK14410@dastard> Message-ID: References: <1401480116-1973111-1-git-send-email-arnd@arndb.de> <1401480116-1973111-12-git-send-email-arnd@arndb.de> <20140531003712.GH14410@dastard> <5389252A.5050503@zytor.com> <20140531011450.GJ14410@dastard> <20140531055457.GK14410@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: linux-arch-owner@vger.kernel.org List-ID: To: Dave Chinner Cc: "H. Peter Anvin" , Arnd Bergmann , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, john.stultz@linaro.org, hch@infradead.org, tglx@linutronix.de, geert@linux-m68k.org, lftan@altera.com, linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com Message-ID: <20140602140011.2kw57dgMmta6M2MfEEH9AI6PB9HWKVeAdmD5mUneY2s@z> On Sat, 31 May 2014, Dave Chinner wrote: > If we are changing the in-kernel timestamp to have a greater dynamic > range that anything we current support on disk, then we need support > for all filesystems for similar translation and constraint. The > filesystems need to be able to tell the kernel what they timestamp > range they support, and then the kernel needs to follow those > guidelines. And if the filesystem is mounted on a kernel that > doesn't support the current filesystem's timestamp format, then at > minimum that filesystem cannot do anything that writes a > timestamp.... > > Put simply: the filesystem defines the timestamp range that can be > used safely, not the userspace API. If the filesystem can't support > the date it is handed then that is an out-of-range error. Since > when have we accepted that it's OK to handle out-of-range data with > silent overflows or corruption of the data that we are attempting to > store? We're defining a new API to support a wider date range - > there is nothing that prevents us from saying ERANGE can be returned > to a timestamp that the file cannot store correctly.... I don't see anything new about this issue. All problems that could arise from the kernel being able to represent a timestamp some filesystems can't are problems that already apply with 64-bit kernels using 64-bit time_t internally. So while as part of Y2038-preparedness we do need a clear understanding of which filesystems have what timestamp limits and what happens with timestamps beyond those limits, I think this is a separate strand of the problem - one that applies to both 32-bit and 64-bit systems - from the more general issue for 32-bit systems. -- Joseph S. Myers joseph@codesourcery.com