On Sun, 5 Aug 2007, Ingo Molnar wrote:
>
> you mean tmpwatch? The trivial change below fixes this. And with that
> we've come to the end of an extremely short list of atime dependencies.
You wouldn't even need these kinds of games.
What we could do is to make "relatime" updates a bit smarter.
A bit smarter would be:
- update atime if the old atime is <= than mtime/ctime
Logic: things like mailers can care about whether some new state has
been read or not. This is the current relatime.
- update atime if the old atime is more than X seconds in the past
(defaulting to one day or something)
Logic: things like tmpwatch and backup software may want to remove
stuff that hasn't been touched in a long time, but they sure don't care
about "exact" atime.
Now, you could also make the rule be that "X" depends on mtime/ctime, ie
if a file has been "recently" created or modified, we keep more exact
track of it and use one hour instead of one day, but if it's some old file
that hasn't been modified in the last six months, we change X to a week.
IOW, the "exactness" of atime is relative to how old the inode
modifications are.
We could obviously do with an additional rule:
- update atime if the inode is dirty anyway. Logic: there's no downside.
which just says that we'll make it exact if there is no reason not to.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
