我正在利用访问时间来分析一些构建过程，但它并没有按照我想要的方式工作：访问时间在我第一次读取文件时更新，然后它会保持不变很长一段时间，或者直到下次重新启动。例如：
$ 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 :(
我猜想 Linux 会将文件缓冲在空闲内存中，出于速度原因，后续只会访问此副本。一种解决方案是丢弃内存中的缓冲区。在搜索了一些论坛后，我发现：
sync
echo 1 > /proc/sys/vm/drop_caches
echo 2 > /proc/sys/vm/drop_caches
echo 3 > /proc/sys/vm/drop_caches
但它不起作用，似乎它只同步写入缓冲区，而不同步读取缓冲区。可能是由于我的发行版（fedora 9）上的一些自定义内核配置？
或者我这里漏掉了什么？有没有办法实现此访问时间刷新？
还要注意，我不想模拟对整个文件树的某些写入。因为我正在使用一些基于 makefile 的构建系统，这将导致整个项目重新构建。
编辑：
我正在使用标准的 ext3 文件系统，没有特殊选项。
/dev/sda1 on / type ext3 (rw)
我尝试使用strictatime（无法识别）和atime（没有区别，我猜这是默认值）重新安装它。
答案1
您是否使用了 noatime 或 relatime 挂载选项？您可以使用以下mount命令查看是否使用了：
[kbrandt@kbrandt-opadmin: ~] mount
/dev/sda1 on / type ext3 (rw,relatime,errors=remount-ro)
如果是这样，请重新挂载文件系统而不使用这些选项（或者在这种情况下更好的方法是编辑该选项/etc/fstab并重新启动）。这些选项是文件系统独立的这些选项的描述位于 中的“文件系统独立挂载选项”下man mount，但基本上它们会阻止或限制 atime 的更新以提高性能。
我不确定这是否能解决您的问题，但由于您依赖访问时间，所以我建议您无论如何都这样做。
顺便说一句，您可能想在这里或在 stackoverflow 上询问如何分析您的特定构建过程，以确保 atime 是正确的途径。
更新：
显示的内容相同吗stat -c "%x" filename？（忽略我上次的更新，没有注意到该-u选项......），但也许你的别名出了问题ll，所以我会检查 stat 以确保无误。
另外，您说 / 没有 noatime，但是您是否在根系统上而不是其他文件系统（如 nfs 挂载等）执行这些测试？
touch -a -t 199812130530可以更改访问时间吗？
答案2
好的，这种行为实际上是由于特定的 Fedora 9 内核出于优化原因禁用了标准访问时间更新（每次读取时写入磁盘非常耗时）。
设置了选项DEFAULT_RELATIME（在我的情况下是内核 2.6.27.25），如果上次刷新发生在不到一天之前，则禁用访问时间刷新。
内核编译选项文档提供了禁用此功能的内核启动选项norelatime ...但它不起作用！
为了成功修改此行为，我实际上这样做了：
echo 60 > /proc/sys/fs/relatime_interval
将此间隔减少到 1 分钟。
感谢您的帮助，让我找到了这个解决方案。