Bad file access on the rise

[Doug Ledford]

On 06/08/2013 10:10 AM, Steve Grubb wrote:
> On Saturday, June 08, 2013 09:57:03 AM Doug Ledford wrote:
>> Bad test.  The first run took the hit for getting the file info into
>> page cache, after that, everything was run from cache and you got the
>> second result above and the results below.  You have to make sure that
>> from run to run the cache state of the file in question is identical.
> 
> Try it yourself.  :-)  I know what you are saying and run the test probably 8 
> times before posting results. I also have the audit rule loaded...so removing 
> it:
> 
> [sgrubb at x2 noatime]$ time ./test noatime
> 
> real	0m0.031s
> user	0m0.006s
> sys	0m0.024s
> [sgrubb at x2 noatime]$ time ./test noatime
> 
> real	0m0.033s
> user	0m0.002s
> sys	0m0.032s
> [sgrubb at x2 noatime]$ time ./test noatime
> 
> real	0m0.036s
> user	0m0.002s
> sys	0m0.031s
> [sgrubb at x2 noatime]$ time ./test atime
> 
> real	0m0.023s
> user	0m0.001s
> sys	0m0.021s
> [sgrubb at x2 noatime]$ time ./test atime
> 
> real	0m0.022s
> user	0m0.003s
> sys	0m0.019s
> [sgrubb at x2 noatime]$ time ./test atime
> 
> real	0m0.023s
> user	0m0.002s
> sys	0m0.019s
> 
> Without the audit rules, it is faster. But again opening with noatime 
> attempted is measurably slower.

Yes, but none of these results show the .12s time that your first
noatime test run showed in your original post.  If you are now saying
that atime is faster than noatime by about .005 to .010s, then these
results seem to show that.  But your original post was from .019 to .12,
or a difference of .10+s.  That was cache load time, not just the
syscall difference.