Con versiones anteriores de Ubuntu (usando el sistema de archivos Ext3) solía ajustarlo para un mejor rendimiento con resultados notables al configurar el noatimeparámetro /etc/fstab.
¿Todavía vale la pena hacerlo con el sistema de archivos Ext4, que ahora es el predeterminado en Ubuntu? Si es así, ¿el procedimiento cambió de alguna manera?
Un ejemplo de este ajuste se puede encontrar aquí.
Respuestas:
En Ubuntu 10.04, relatimeforma parte de las opciones de montaje predeterminadas, a menos que se anulen /etc/fstab. Los pocos lanzamientos anteriores habían aparecido relatimeexplícitamente /etc/fstab. relatimebrinda los mismos beneficios de velocidad (y conservación del ciclo de escritura flash) que noatime, sin causar problemas a los antiguos notificadores de correo.
El artículo que cita recomienda data=writeback. Ubuntu por defecto es data=ordered. La configuración de Ubuntu es más lenta en caso de una gran carga de disco, pero conlleva un riesgo significativamente menor de pérdida de datos en caso de bloqueo o falla de energía. Por lo tanto, no recomendaría cambiar el valor predeterminado de Ubuntu.
Cambiar commit=5a commit=100aumenta la ventana de tiempo durante la cual se perderán los datos en caso de un bloqueo, para poco beneficio en la mayoría de las circunstancias.
Resumen: deje la configuración como está, se eligió por algún motivo.
AGREGADO: Hay otras cosas más allá de las opciones de montaje que pueden marcar la diferencia. Cambiar de ext3a ext4es en sí mismo a menudo una mejora visible. Aquí hay algunos consejos más para usuarios de computadoras portátiles.
Si tiene un SSD lento, consulte este hilo en SU . Los consejos importantes son usar tmpfspara /tmpy para el caché del navegador (y tal vez el historial).
Si tiene un disco duro y desea que deje de girar durante largos períodos de tiempo, instale noflushd , que permite que el disco gire al retrasar todas las escrituras hasta que la RAM esté llena. (Por supuesto, las lecturas pueden hacer que el disco gire; querrás acostumbrarte a correr cat /files/I/m/likely/to/need >/dev/nullantes de que el disco gire hacia abajo). Para que noflushd sea efectivo, apaga todo el intercambio y monta tus sistemas de archivos con algo como commit=3600.
Usar noflushd efectivamente significa que sus datos pueden permanecer sin escribir en el disco durante un período prolongado de tiempo. Esto es un riesgo, que debe compararse con el beneficio de no tener ningún ruido o calor proveniente del disco por un tiempo. No use noflushd si no se siente cómodo con ese riesgo.
noatimevs atimepuede hacer una diferencia visible, pero me sorprendería que noatimevs lo relatimehiciera. He agregado algunos consejos específicos para computadoras portátiles a mi respuesta; Personalmente he observado mejoras visibles de estos consejos. Noflushd conlleva un riesgo que estaba dispuesto a tomar cuando lo usé.
data=writebackesto: simplemente escribe datos de archivos y metadatos en orden aleatorio (a diferencia de lo orderedque siempre escribe metadatos después de los datos) . Esto significa que, tras un corte de energía, puede encontrar el archivo α bytes de longitud, donde se escribieron 0 bytes. Bueno ... ¡Pero esto es absolutamente natural! Siempre he pensado que el sistema de archivos primero aumenta el tamaño del archivo y luego escribe los datos. Descubrir que puede estar en el orden inverso requiere transformar este patrón para agregar el almacenamiento en caché en la RAM. No estoy convencido de por qué no usarlo writebacksi puede ayudar a mejorar la latencia.
Sí, aún puede tener sentido usarlo a noatimepartir de Ubuntu 12.10
relatimees una opción de montaje predeterminada. Y relatimees mucho mejor que atime. El primero requiere una escritura para la primera lectura después de una escritura, el último requiere una escritura para cada lectura. Pero con noatimecada lectura es libre de una escritura.
Básicamente, esto significa que el número de escrituras en un disco para el relatimemontaje es casi el doble en relación con un noatimemontaje que es igual. Es una preocupación seria para las particiones en dispositivos de memoria flash.
La discusión detallada de la comunidad de kernel de Linux se encuentra en http://kerneltrap.org/node/14148
relatimeinconvenientes y compartir la discusión KernelTrap, pero diciendo " no hay ningún punto en los archivos de sólo escritura " es un disparate: todos /usry /libson archivos de sólo lectura. En realidad, la mayoría de los árboles, sans /homey /var, son de solo lectura. Los archivos /etctambién cambian muy raramente.
relatimecomparación con noatimeel archivo. Para todo lo demás, hay una escritura adicional cuando se lee el archivo.
comit=100que también mencionaste. Pero estoy dispuesto a tomar algunos riesgos moderados para aumentar el rendimiento, ya que uso una computadora portátil y (casi) copias de seguridad regularmente.