[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180316063045.GI4875@magnolia>
Date: Thu, 15 Mar 2018 23:30:45 -0700
From: "Darrick J. Wong" <darrick.wong@...cle.com>
To: Andiry Xu <jix024@....ucsd.edu>
Cc: "Theodore Y. Ts'o" <tytso@....edu>, Arnd Bergmann <arnd@...db.de>,
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 11:17:54PM -0700, Andiry Xu wrote:
> On Thu, Mar 15, 2018 at 7:59 PM, Theodore Y. Ts'o <tytso@....edu> wrote:
> > 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
> >
>
> Thanks for all the suggestions. I think I will follow ext4's time
> format. 2446 should be far away enough.
If you do, try to avoid the encoding problems that ext4 (still) has:
Not-fixed-by: a4dad1ae24f8 ("ext4: Fix handling of extended tv_sec")
--D
> Thanks,
> Andiry
Powered by blists - more mailing lists