mutt un client de messagerie, utilise les temps d'accès aux fichiers pour surveiller l'arrivée de nouveaux messages dans une boîte aux lettres au format mbox. Apparemment, ce problème n'est pas grave, et il est facile à contourner .
En dehors de cela, il est difficile de trouver des exemples de choses qui se cassent sur le terrain. noatime . Je gère un certain nombre de serveurs Linux avec noatime sur tous les systèmes de fichiers, et je ne me rappelle pas avoir jamais vu de problèmes attribuables aux noatime .
Si vous êtes préoccupé par l'utilisation noatime en général, vous pouvez consacrer un système de fichiers séparé pour votre matériel mongoDB, et monter uniquement ce système de fichiers avec la commande noatime .
EDIT
J'ai trouvé un blog intéressant à kerneltrap.org qui cite quelques discussions entre des développeurs de Linux (Linus Torvalds, Ingo Molnar, Alan Cox, et d'autres) sur le sujet suivant atime . Dans le deuxième courriel d'Ingo, il dit ceci :
... je n'ai pas vraiment à me plaindre de ext3 - avec la qualification obligatoire que "noatime,nodiratime" dans /etc/fstab est un must. Cela accélère les choses de manière très visible - surtout lorsque quand beaucoup de fichiers sont accédés. C'est assez bizarre que tous les ordinateurs et serveurs Linux soit affecté par un ralentissement notable des performances d'entrée-sortie dû aux à cause des mises à jour constantes de atime, alors qu'il n'y a que deux vrais utilisateurs : tmpwatch [qui peut être configuré pour utiliser ctime donc ce n'est pas un gros problème]. et quelques outils de sauvegarde. (Ok, et mail-notify aussi je suppose.) Sur des dizaines de milliers d'applications. Donc, pour la plupart des charges de travail sur les fichiers, nous donnons à Windows une note de 20%-30% de performance en plus, pour presque rien.
