Paul, It's a fine heuristic. I'm still concerned that we read a small file on NFS at the beginning of the archive, which happens to be in cache, and decide at that point that O_NOATIME works for the entire filesystem, when actually, it doesn't. I don't see any way around this, other than second-guessing yourself all the time.
Another, possibly more reliable way of detecting this, would just be to do statfs(), and see if the filesystem type is one known to not work. Then you (probably) don't have to worry about false negatives; the only way O_NOATIME won't work in that case is if the kernel doesn't support it, so the only bad behavior allowed by the heuristic is to call utimes() on possibly several files at the beginning of the archive, until it finds one that isn't being accessed, at which time it would switch to O_NOATIME. Another approach might just be to ask the kernel (via uname()) if it supports O_NOATIME -- that is, if it is at least version 2.6.8. If that's too much of a hack, a sysctl could be addde to ask this question to a future kernel, so that we would only nede to use uname() for, say, kernels 2.6.8 - 2.6.14. Cheers, --Ian On Wednesday 21 September 2005 16:02, you wrote: > Ian Turner <[EMAIL PROTECTED]> writes: > > Ah, so you're thinking of something like stat, read the whole file, and > > stat again. > > No, I wasn't thinking of adding any more system calls in the usual > case. Tar already records the time that it starts up. > > Here is the heuristic I was thinking of, to be done just after we've > finished reading the file: > > * If the file is empty, stop. > > * If we have already detected that O_NOATIME works for this file system, > stop. > > * If the final fstat (which tar is already doing) reports a > last-access time that is older than tar's startup time, then > O_NOATIME worked; record this fact for the current file system, > and stop. > > * Fall back on the existing --preserve-atime method. I.e., use > futimes etc. > > This heuristic never uses more system calls than the existing > --preserve-atime method. In the usual case it never uses more system > calls than the existing code without --preserve-atime. It's not > perfect, but it's better than the existing --preserve-atime in all > cases. > > The heuristic can be made a bit fancier, if you like, to make the race > condition smaller, by checking the current time and rereading a small > part of the file before falling back on --preserve-atime. _______________________________________________ Bug-tar mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-tar
