Я использую время доступа для анализа некоторого процесса сборки, но он работает не так, как я хочу: время доступа обновляется при первом чтении файла, затем оно остается неизменным в течение длительного времени или до тех пор, пока следующая перезагрузка. Например:
$ 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)?
Или мне что-то здесь не хватает? Есть ли способ добиться этого обновления времени доступа?
Также обратите внимание, что я не хочу имитировать некоторые записи во всем дереве файлов. Поскольку я использую некоторую систему сборки на основе make-файлов, это приведет к повторной сборке всего проекта.
Я использую стандартную файловую систему ext3 без специальных опций.
/dev/sda1 on / type ext3 (rw)
Пытался перемонтировать с strictatime (не распознается) и atime (без разницы, я думаю, это было значение по умолчанию).
Вы используете опции монтирования noatime или relatime? Вы можете увидеть, если вы с mount команда:
[kbrandt@kbrandt-opadmin: ~] mount
/dev/sda1 on / type ext3 (rw,relatime,errors=remount-ro)
Если это так, перемонтируйте файловую систему без этих параметров (или, возможно, в этом случае лучше было бы отредактировать параметр вне /etc/fstab и просто перезагрузитесь). Эти параметры являются файловой системой независимый. Описание этих опций находится в разделе «НЕЗАВИСИМЫЕ ОПЦИИ МОНТАЖА ФАЙЛЕСИСТЕМЫ» в man mount, но в основном они предотвращают или ограничивают время обновления для повышения производительности.
Я не уверен, что это решение вашей проблемы, но, поскольку вы зависите от времени доступа, я все равно рекомендую вам это сделать.
В стороне, вы можете спросить здесь или в stackoverflow об анализе вашего конкретного процесса сборки, чтобы убедиться, что atime - правильный путь.
Обновить:
Делает stat -c "%x" filename показать то же самое? (Игнорируйте мое последнее обновление, не заметил -u вариант ...), но, возможно, что-то происходит с вашим ll псевдоним, поэтому я хотел бы проверить с помощью stat, чтобы убедиться.
Кроме того, вы сказали, что / не имеет noatime, но выполняете ли вы эти тесты в корневой системе, а не в другой файловой системе, например, при монтировании nfs или в чем-то еще?
Делает touch -a -t 199812130530 удается изменить время доступа?
Хорошо, такое поведение на самом деле было связано с конкретным ядром Fedora 9, которое отключило стандартное обновление времени доступа по причинам оптимизации (запись на диск при каждом чтении занимает очень много времени).
Опция DEFAULT_RELATIME (в моем случае ядро 2.6.27.25) было установлено, что отключает обновление времени доступа, если последнее обновление произошло менее одного дня назад.
Параметр компиляции ядра doc дает возможность загрузки ядра norelatime который отключает эту функцию ... но это не сработало!
Чтобы успешно изменить это поведение, я действительно сделал:
echo 60 > /proc/sys/fs/relatime_interval
которые уменьшают этот интервал до 1 минуты.
Спасибо за помощь, которая привела меня к этому решению.