Avec les versions précédentes d’Ubuntu (utilisant le système de fichiers Ext3), je l’accordais pour obtenir de meilleures performances avec des résultats remarquables en définissant le noatimeparamètre dans /etc/fstab.
Cela vaut-il toujours la peine de le faire avec le système de fichiers Ext4, qui est maintenant le système par défaut dans Ubuntu? Si oui, la procédure a-t-elle changé d'une manière ou d'une autre?
Un exemple de cet accord peut être trouvé ici.
Réponses:
Sous Ubuntu 10.04, relatimefait partie des options de montage par défaut, sauf substitution dans /etc/fstab. Les quelques versions précédentes avaient relatimeexplicitement en /etc/fstab. relatimeoffre les mêmes avantages en termes de rapidité (et de conservation du cycle d'écriture flash) que les noatimeavertisseurs de courrier à l'ancienne.
L'article que vous citez recommande data=writeback. Ubuntu a la valeur par défaut data=ordered. Le paramétrage d'Ubuntu est plus lent en cas de charge de disque importante, mais présente un risque beaucoup moins grand de perte de données en cas de panne ou de panne de courant. Donc, je ne recommanderais pas de changer de la valeur par défaut Ubuntu.
Passer commit=5à commit=100augmente la fenêtre de temps pendant laquelle les données seront perdues en cas de crash, sans grand bénéfice dans la plupart des circonstances.
Résumé: laissez les paramètres tels quels, ils ont été choisis pour une raison.
AJOUTÉ: Il y a d'autres choses que les options de montage qui peuvent faire la différence. Passer de ext3à ext4est souvent une amélioration visible. Voici quelques conseils supplémentaires pour les utilisateurs d'ordinateurs portables.
Si vous avez un SSD lent, consultez ce fil sur SU . Les conseils importants sont à utiliser tmpfspour /tmpet pour le cache du navigateur (et peut-être l'historique).
Si vous avez un disque dur et que vous voulez qu'il arrête de tourner pendant de longues périodes, installez noflushd , qui permet au disque de s'éteindre en retardant toutes les écritures jusqu'à ce que la RAM soit pleine. (Bien sûr, les lectures peuvent provoquer une rotation du disque; vous voudrez prendre l'habitude de fonctionner cat /files/I/m/likely/to/need >/dev/nullavant que le disque ne s'essouffle .) Pour que noflushd soit efficace, désactivez tous les échanges et montez vos systèmes de fichiers avec quelque chose comme: commit=3600.
L'utilisation efficace de noflushd signifie que vos données peuvent rester non écrites sur le disque pendant une période prolongée. Ceci est un risque, à comparer aux avantages de ne pas avoir de bruit ou de chaleur provenant du disque pendant un moment. N'utilisez pas noflushd si vous n'êtes pas à l'aise avec ce risque.
noatimevs atimepeut faire une différence visible, mais je serais surpris que noatimevs le relatimefasse. J'ai ajouté quelques astuces spécifiques aux ordinateurs portables à ma réponse. J'ai personnellement observé des améliorations visibles de ces conseils. Noflushd comporte un risque que j'étais disposé à prendre quand je l'ai utilisé.
data=writebackce sujet . Il écrit simplement les données de fichier et les métadonnées dans un ordre aléatoire (par opposition à orderedce qui écrit toujours des métadonnées après les données) . Cela signifie qu'en cas de panne de courant, vous pouvez trouver votre fichier α octets de long, où 0 octets ont été réellement écrits. Eh bien… Mais c'est absolument naturel! J'ai toujours pensé que le système de fichiers augmente d'abord la taille du fichier, puis écrit les données. Trouver qu'il peut être dans l'ordre inverse nécessite de transformer ce modèle pour ajouter la mise en cache dans la RAM. Je ne suis pas convaincu pourquoi ne pas utiliser writebacksi cela peut aider à améliorer la latence.
Oui, il peut toujours être judicieux d'utiliser à noatimepartir d'Ubuntu 12.10
relatimeest une option de montage par défaut. Et relatimec'est bien mieux que atime. Le premier nécessite une écriture pour la première lecture après une écriture, le dernier nécessite une écriture pour chaque lecture. Mais à noatimechaque lecture est libre d'une écriture.
Cela signifie fondamentalement que le nombre d'écritures sur un disque pour le relatimemontage est presque doublé par rapport à un noatimemontage identique. C'est une préoccupation sérieuse pour les partitions sur des périphériques de mémoire flash.
La discussion détaillée par la communauté du noyau Linux est à http://kerneltrap.org/node/14148
relatimeinconvénients et le partage de la discussion kerneltrap, mais en disant « il n'y a pas de point dans les fichiers d'écriture seule » est un non - sens: tous /usret /libsont des fichiers en lecture seule. En fait, la plupart des arbres, sans /homeet /var, sont en lecture seule. Les fichiers /etcchangent également très rarement.
relatimerapport à noatimepour le fichier. Pour tout le reste, il y a une écriture supplémentaire lors de la lecture du fichier.
comit=100que vous avez également mentionnée. Mais je suis prêt à prendre des risques modérés pour améliorer les performances, car j'utilise un ordinateur portable et effectue des sauvegardes (presque) régulières.