On Saturday 31 May 2014 11:14:50 Dave Chinner wrote:
> On Fri, May 30, 2014 at 05:41:14PM -0700, H. Peter Anvin wrote:
> > 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."
> I think having the new systems calls being able to
> return EINVAL if the value cannot be stored permanently on disk
> correctly is the right thing to do. Having it silently mangled
> by the filesystem and returning "everything is just fine, trust me"
> is close to the worst solution I can think of. That's exactly what
> leads to overflow bugs occurring....
While going through the file systems, I was wondering whether
we should have the times stop at the end of each file systems
epoch rather than wrap around.
> > > 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.
> Sure, but all filesystems are supposed to handle at least the
> current unix epoch.
In my list at http://kernelnewbies.org/y2038, I found that almost
all file systems at least times until 2106, because they treat
the on-disk value as unsigned on 64-bit systems, or they use
a completely different representation. My guess is that somebody
earlier spent a lot of work on making that happen.
The exceptions are:
* exofs uses signed values, which can probably be changed to be
consistent with the others.
* isofs has a bug that limits it until 2027 on architectures with
a signed 'char' type (otherwise it's 2155).
* udf can represent times for many thousands of years through a
16-bit year representation, but the code to convert to epoch
uses a const array that ends at 2038.
* afs uses signed seconds and can probably be fixed
* coda relies on user space time representation getting passed
through an ioctl.
* I miscategorized xfs/ext2/ext3 as having unsigned 32-bit seconds,
where they really use signed.
I was confused about XFS since I didn't noticed that there are
separate xfs_ictimestamp_t and xfs_timestamp_t types, so I expected
XFS to also use the 1970-2106 time range on 64-bit systems today.
If we are using the variant of my patch that extends
indode_time->tv_sec to s64, nothing should change for XFS
at all, the main difference is that we if it gets extended
to wider on-disk timestamps, they will work the same way on
32-bit and 64-bit kernels.