[Tux3] Time fields in Tux3

[Daniel Phillips]

On Monday 25 August 2008 15:26, Shapor Naghibzadeh wrote:
> 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.

Won't they just rely on the tv_sec field of timeval for that?
Everything will work.  If they rely on the tv_usec field knowing
they actually have 1 second resolution, isn't their algorithm
already broken?

> 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.

Option to crank it down I think.  One second has never been quite
enough, I have seen make miss file changes because of it.  You just
need more than one change to a source file per second, which I have
achieved interactively.  I doubt I can update a file more than once
per 66 thousandth of a second.

Regards,

Daniel

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