From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from imap.thunk.org ([74.207.234.97]:46172 "EHLO imap.thunk.org"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1752244AbeCPDCc (ORCPT <rfc822;linux-fsdevel@vger.kernel.org>);
        Thu, 15 Mar 2018 23:02:32 -0400
Date: Thu, 15 Mar 2018 22:59:28 -0400
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Andiry Xu <jix024@eng.ucsd.edu>,
        "Darrick J. Wong" <darrick.wong@oracle.com>,
        Linux FS Devel <linux-fsdevel@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        "linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
        Dan Williams <dan.j.williams@intel.com>,
        "Rudoff, Andy" <andy.rudoff@intel.com>, coughlan@redhat.com,
        Steven Swanson <swanson@cs.ucsd.edu>,
        Dave Chinner <david@fromorbit.com>, Jan Kara <jack@suse.com>,
        swhiteho@redhat.com, miklos@szeredi.hu,
        Jian Xu <andiry.xu@gmail.com>, Andiry Xu <jix024@cs.ucsd.edu>
Subject: Re: [RFC v2 03/83] Add super.h.
Message-ID: <20180316025928.GB2254@thunk.org>
References: <1520705944-6723-1-git-send-email-jix024@eng.ucsd.edu>
 <1520705944-6723-4-git-send-email-jix024@eng.ucsd.edu>
 <20180315045401.GB4860@magnolia>
 <CAD4SzjtHmBTisX6vQYuEnJf0fKsF==w5GHqsdks6xGv1go7Lzw@mail.gmail.com>
 <CAK8P3a1OJqHEOgiHk1ZQytGW7b1c2Nam5xjSxxkfx=h2x7f_mg@mail.gmail.com>
 <CAD4Szjt6URWFEuB_qZcnoQMqCLNwyCns0CCP==Su7iQOt=ddMw@mail.gmail.com>
 <CAK8P3a2JgVVRsiBzTuUACwmCoVFkkJbF9zGfk4Yu0KzzRV=81Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAK8P3a2JgVVRsiBzTuUACwmCoVFkkJbF9zGfk4Yu0KzzRV=81Q@mail.gmail.com>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Thu, Mar 15, 2018 at 09:38:29PM +0100, Arnd Bergmann wrote:
> 
> You could also have a resolution of less than a nanosecond. Note
> that today, the file time stamps generated by the kernel are in
> jiffies resolution, so at best one millisecond. However, most modern
> file systems go with the 64+32 bit timestamps because it's not all
> that expensive.

It actually depends on the architecture and the accuracy/granularity
of the timekeeping hardware available to the system, but it's possible
for the granularity of file time stamps to be up to one nanosecond.
So you can get results like this:

% stat unix_io.o 
  File: unix_io.o
  Size: 55000     	Blocks: 112        IO Block: 4096   regular file
Device: fc01h/64513d	Inode: 19931278    Links: 1
Access: (0644/-rw-r--r--)  Uid: (15806/   tytso)   Gid: (15806/   tytso)
Access: 2018-03-15 18:09:21.679914182 -0400
Modify: 2018-03-15 18:09:21.639914089 -0400
Change: 2018-03-15 18:09:21.639914089 -0400

Cheers,

					- Ted