Home / server / Questions / 130046
Accepted
calandoa
Asked: 2010-04-08 02:05:45 +0800 CST

Refresh file access time under Linux / Discard disk read cache

  • 772

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).

linux time cache filesystems

2 Answers

  1. 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?

    • 3
  2. Best Answer

    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.

    • 2