[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180316025928.GB2254@thunk.org>
Date: Thu, 15 Mar 2018 22:59:28 -0400
From: "Theodore Y. Ts'o" <tytso@....edu>
To: Arnd Bergmann <arnd@...db.de>
Cc: Andiry Xu <jix024@....ucsd.edu>,
"Darrick J. Wong" <darrick.wong@...cle.com>,
Linux FS Devel <linux-fsdevel@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
Dan Williams <dan.j.williams@...el.com>,
"Rudoff, Andy" <andy.rudoff@...el.com>, coughlan@...hat.com,
Steven Swanson <swanson@...ucsd.edu>,
Dave Chinner <david@...morbit.com>, Jan Kara <jack@...e.com>,
swhiteho@...hat.com, miklos@...redi.hu,
Jian Xu <andiry.xu@...il.com>, Andiry Xu <jix024@...ucsd.edu>
Subject: Re: [RFC v2 03/83] Add super.h.
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
Powered by blists - more mailing lists