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

From: Joseph S. Myers
Date: Mon Jun 02 2014 - 10:00:26 EST

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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at