lkml.org 
[lkml]   [2014]   [Jun]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC 00/32] making inode time stamps y2038 ready
    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@fromorbit.com


    \
     
     \ /
      Last update: 2014-06-04 00:21    [W:4.814 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site