What about the `find / ...' that updatedb does nightly? That's a pretty
big operation, and there's no desire to have the directory atimes
touched by that surely? All that does is slow the operation down, and
write a lot of inodes to disk (none are required with noatime)
And backups using tar, often it makes more sense to preserve the atimes
rather than change them. GNU tar has an option `--preserve-atimes' to
do just this. It isn't perfect though: if tar crashes mid-file, the
file's atime will be changed. And there's still the I/O overhead of
writing out all the inodes. Which is sometimes quite substantial.
For these situations, now that we have capabilities, how about a
CAP_NOATIME capability to allow noatime for special processes?
Practical usage:
setcap +CAP_NOATIME find / ...
setcap +CAP_NOATIME tar ...
su - news -c setcap +CAP_NOATIME /usr/sbin/texpire
setcap +CAP_NOATIME -i -CAP_NOATIME crond
etc.
Or a program `noatime' if it's deemed a common enough thing to have its
own name.
Semantics #1: any file or directory read by a process while CAP_NOATIME
is set does not have its atime updated. This is optional; some
filesystems will update atimes anyway (e.g., NFS).
Semantics #2: a file or directory *opened by a process with CAP_NOATIME
set* does not have its atime updated via those file descriptors. Again
optional, as not supported by NFS.
#2 pros:
- allows some files to be opened in the noatime mode, and some
not (by toggling CAP_NOATIME in the process).
- allows a parent shell to redirect input of a child that has
CAP_NOATIME, and expect the redirected file to have its atimes
updated in the normal way.
- allows temporary noatime read from files opened by the process.
#2 cons:
- may be a lot more complex to implemented than #1.
- perhaps all the interesting processes (news & web servers,
news & proxy expiry, updatedb, backup) only ever write
to log files etc., they don't read anything so no need to
support updating atimes on miscellaneous files.
Having thought this through, I prefer #1 but am not firmly convinced
either way.
Thoughts?
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html