[Tux3] Time fields in Tux3

Shapor Naghibzadeh shapor at gmail.com
Mon Aug 25 15:26:03 PDT 2008


On Mon, Aug 25, 2008 at 2:51 PM, Daniel Phillips <phillips at phunq.net> wrote:

> I plan to store atimes as 32 bit quantities with one second resolution,
> less than ctime and mtime.  This is because atime has always had that
> resolution and was a poorly conceived idea from the start.  It is not
> my intention to improve atime, but simply to support it as a legacy
> feature.

One problem I can think of with having a different resolution for
atime and ctime is that it might confuse programs attempting to check
if a file has been read since it was last changed by checking for
equivalence.

Googling around points to some discussion here:
http://lwn.net/Articles/244829/ specifically:

'Another approach was added in 2.6.20: the relatime mount option. If
this flag is set, access times are only updated if they are (before
the update) earlier than the modification time. This change allows
utilities to see if the current version of a file has been read, but
still cuts down significantly on atime updates. This option is not
heavily used, perhaps because few people have heard of it and many
distributions lack a version of mount which is new enough to know
about it. Using relatime can still confuse tools which want to ask
questions like "has this file been accessed in the last week?"'

ext3 only seems to have 1-second resolution which has always been
sufficient for me.  Why not make this the default and add an mkfs
option to crank it up to full nanosecond resolution if thats what the
user desires?  The only downside being eating up a couple more
attribute types.

Shapor

_______________________________________________
Tux3 mailing list
Tux3 at tux3.org
http://tux3.org/cgi-bin/mailman/listinfo/tux3



More information about the Tux3 mailing list