On Tue, Jun 03, 2014 at 04:22:19PM +0200, Arnd Bergmann wrote: > On Monday 02 June 2014 14:57:26 H. Peter Anvin wrote: > > On 06/02/2014 12:55 PM, Arnd Bergmann wrote: > The possible uses I can see for non-ktime_t types in the kernel are: > * inodes need 96 bit timestamps to represent the full range of values > that can be stored in a file system, you made a convincing argument > for that. Almost everything else can fit into 64 bit on a 32-bit > kernel, in theory also on a 64-bit kernel if we want that. Just ot be pedantic, inodes don't *need* 96 bit timestamps - some filesystems can *support up to* 96 bit timestamps. If the kernel only supports 64 bit timestamps and that's all the kernel can represent, then the upper bits of the 96 bit on-disk inode timestamps simply remain zero. If you move the filesystem between kernels with different time ranges, then the filesystem needs to be able to tell the kernel what it's supported range is. This is where having the VFS limit the range of supported timestamps is important: the limit is the min(kernel range, filesystem range). This allows the filesystems to be indepenent of the kernel time representation, and the kernel to be independent of the physical filesystem time encoding.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
