Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am making use of the access time to analyse some build process, but it is not working the way I want: the access time is updated the first time I read the file, then it stays the same for a long while, or until the next reboot. For instance:

$ ll -u some_file
-rw-r--r-- 1 root root 1.3M 2010-04-07 10:03 some_file
$ grep abcdef some_file
$ ll -u some_file
-rw-r--r-- 1 root root 1.3M 2010-04-07 11:24 some_file
# The access time is updated

# waiting a few minutes...
$ grep abcdef some_file
$ ll -u some_file
-rw-r--r-- 1 root root 1.3M 2010-04-07 11:24 some_file
# The access time has not been updated :(

I suppose that the file is buffered by Linux in the free memory, the only this copy is accessed the subsequent times for speed reasons. A solution would be to discard the buffers in memory. After searching some forums, I found:

sync
echo 1 > /proc/sys/vm/drop_caches
echo 2 > /proc/sys/vm/drop_caches
echo 3 > /proc/sys/vm/drop_caches

But it is not working, it seems that it only sync up the write buffers, not the read ones. May be it is due to some custom kernel configuration on my distro (fedora 9)?

Or I am missing something here? Is there a way to achieve this access time refresh?

Note also that I do not want to simulate some writes on my entire file tree. Because I am using some makefile based build system, this will cause the entire project to be build again.

edit:

I am using a standard ext3 filesystem, without special options.

/dev/sda1 on / type ext3 (rw)

I tried to remount it with strictatime (not recognized) and atime (no difference, I guess it was the default value).

share|improve this question
    
I guess this behaviour is file-system-dependant. So, tell us what exact file system you are using and with what mount options. Caching should not influence ls output. Even if the data is in the cache and not written to the disk, it is still the data visible to the applications. –  Jacek Konieczny Apr 7 '10 at 11:14
add comment

2 Answers

Are you using the noatime or relatime mount options? You can see if you are with the mount command:

[kbrandt@kbrandt-opadmin: ~] mount
/dev/sda1 on / type ext3 (rw,relatime,errors=remount-ro)

If so, remount the filesystem without those options (or probably better for this case would be to edit the option out of /etc/fstab and just reboot). These options are filesystem independent. Description of these options are under "FILESYSTEM INDEPENDENT MOUNT OPTIONS" in man mount, but basically they prevent or limit atime from being updated to increase performance.

I'm not sure if this is the solution to your problem, but since you are depending on access time I recommend you do this anyways.


As an aside, you might want to ask here or on stackoverflow about analyzing your particular build process to make sure atime is the right path to take.


Update:
Does stat -c "%x" filename show the same thing? (Ignore my last update, didn't notice the -u option...), but maybe there is something going on with your ll alias, so I would check with stat to make sure.

Also, you said / doesn't have noatime, but are you doing these tests on the root system and not another filesystem, like a nfs mount or something?

Does touch -a -t 199812130530 manage to change the access time?

share|improve this answer
1  
Note that relatime recently became the default, so you may need to force it using the strictatime mount option. mount -o remount,strictatime MOUNTPOINT lets you change this online –  LapTop006 Apr 7 '10 at 11:51
    
Yes, "stat" gives the same result, and I am accessing my root filesystem. But did you check on your system? Does the atime is always refresh at each file read access? I would like to know if the trouble is due to my linux flavor, rather than to a standard linux behavior. –  calandoa Apr 7 '10 at 12:52
    
On my Ubuntu desktop, Yes, grep updates the access time if remount without relatime or noatime. –  Kyle Brandt Apr 7 '10 at 12:52
    
Thx, this info gave me a big hint... it seems it is due to a kernel compilation option, I need to reboot to confirm and I will give more details. –  calandoa Apr 7 '10 at 13:05
add comment
up vote 2 down vote accepted

Ok, this behavior was actually due to the specific Fedora 9 kernel which disable the standard access time update for optimisation reasons (writing the disk for each read is very time consuming).

The option DEFAULT_RELATIME (in my case kernel 2.6.27.25) was set, which disable the access time refresh if the last refresh occured less than one day ago.

The kernel compilation option doc gives the kernel boot option norelatime which disables this feature... but it did not work!

To modify succesfully this behavior, I actually did:

echo 60 > /proc/sys/fs/relatime_interval

which decrease this interval to 1 minute.

Thanks for the help which lead me to this solution.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.