Недостатки монтирования файловой системы с noatime?
Считайте в реальном времени:
Если у Вас есть довольно новая установка (~2008), можно использовать опцию монтирования в реальном времени. Это - хороший компромисс для atime, я думаю. Из kerneltrap дискуссии о реализации этой новой опции:
"относительный atime только обновляет atime, если предыдущий atime является более старым, чем mtime или ctime. Как noatime, но полезный для приложений как дурак, который должен знать, когда файл был считан, так как он был в последний раз изменен".
Это делает его так большинство приложений, для которых нужен atime, будет все еще работать, но уменьшает загрузку диска - таким образом, это - компромисс. Это - значение по умолчанию с недавними настольными дистрибутивами Ubuntu.
Относительно noatime и nodiratime:
Если Вы идете noatime для файлов, интересно, существует ли причина не использовать nodiratime в дополнение к noatime, таким образом, Вы не обновляете время доступа на каталогах также.
Другая причина сохранить atime включила, который не был упомянут, для аудита целей. Но так как то, кто получил доступ к нему, не сохранено и только когда, это, вероятно, не настолько полезно для журнала аудита.
Все эти опции могут быть найдены в 'человеке, монтируются 8'.
-
1+1 в реальном времени имеют преимущества noatime и ни один из недостатков. – David Pashley 29 July 2009 в 14:49
-
2Читая еще немного об этом, кажется, что noatime также включает nodiratime (это didn' t, много много лет назад, хотя) – nos 30 July 2009 в 02:59
Там существуйте приложения, которые переместят файлы прочь во внешнюю память, если к ним не получили доступ в течение определенного периода времени. Очевидно, им нужен atime.
Кроме этого, я не вижу много использования для этого (больше), тем более, что файловые менеджеры в эти дни имеют тенденцию открыть файлы для генерации предварительных просмотров, поэтому modifiying atime только при просмотре каталога.
Я всегда монтируюсь с noatime в эти дни.
Существуют очень мало существуют некоторые приложения, которые полагаются на это, например, Дурак не может определить, получила ли папка новую почту, так как в последний раз посещается.
Обычно я и другие думаем, что монтирование noatime является хорошей идеей.
-
1Даже затем это только относится к хранилищам mbox. Некоторые могли бы сказать, что Вы получаете то, чего Вы заслуживаете. – Dan Carley 29 July 2009 в 14:06
-
2Don' t используют noatime; используйте в реальном времени вместо этого. См. Kyle' s ответ. – David Pashley 29 July 2009 в 14:50
-
3Обратите внимание, что в реальном времени относительно новое дополнение к опциям. Если у Вас есть более старое ядро (т.е. если у Вас все еще есть базирующееся выполнение машин какого-либо Debian/Sarge), у Вас не могло бы быть его. – David Spillett 29 July 2009 в 15:43
основной недостаток, который не был упомянут еще, - то, что, если у Вас есть процесс tmpreaper (т.е. программа, которая удаляет файлы в/tmp, к которым не получили доступ некоторое время), это могло удалить tmp файлы, которые все еще используются.
в реальном времени более оптимальный вариант, чем noatime., он только обновляет atime, если файл был изменен начиная с последнего обновления atime. это обладает очевидными преимуществами для почтовых клиентов. это все еще не устраняет tmpreaper проблему (файл может быть считан из/tmp целую вечность, не будучи записанным в).
в целом, недостатки незначительны (несуществующий за исключением нескольких особых случаев), и выигрыш в производительности является значительным.