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@xxxxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
