[Top] [All Lists]

Re: [RFC 11/32] xfs: convert to struct inode_time

To: Dave Chinner <david@xxxxxxxxxxxxx>, Arnd Bergmann <arnd@xxxxxxxx>
Subject: Re: [RFC 11/32] xfs: convert to struct inode_time
From: "H. Peter Anvin" <hpa@xxxxxxxxx>
Date: Fri, 30 May 2014 17:41:14 -0700
Cc: linux-kernel@xxxxxxxxxxxxxxx, linux-arch@xxxxxxxxxxxxxxx, joseph@xxxxxxxxxxxxxxxx, john.stultz@xxxxxxxxxx, hch@xxxxxxxxxxxxx, tglx@xxxxxxxxxxxxx, geert@xxxxxxxxxxxxxx, lftan@xxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20140531003712.GH14410@dastard>
References: <1401480116-1973111-1-git-send-email-arnd@xxxxxxxx> <1401480116-1973111-12-git-send-email-arnd@xxxxxxxx> <20140531003712.GH14410@dastard>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
On 05/30/2014 05:37 PM, Dave Chinner wrote:
> IOWs, the filesystem has to be able to reject any attempt to set a
> timestamp that is can't represent on disk otherwise Bad Stuff will
> happen,

Actually it is questionable if it is worse to reject a timestamp or just
let it wrap.  Rejecting a valid timestamp is a bit like "You don't
exist, go away."

> and filesystems have to be able to specify in their on
> disk format what timestamp encoding is being used. The solution will
> be different for every filesystem that needs to support time beyond
> 2038.

Actually the cutoff can be really different for each filesystem, not
necessarily 2038.  However, I maintain the above still holds.

Consider a filesystem that kept timestamps in YYMMDDHHMMSS format.  What
would you have expected such a filesystem to do on Jan 1, 2000?


<Prev in Thread] Current Thread [Next in Thread>