¿Cuál es el sistema de archivos más rápido para compilaciones de desarrolladores?

Estoy armando una caja de Linux que actuará como un servidor de compilación de integración continua; construiremos principalmente cosas de Java, pero creo que esta pregunta se aplica a cualquier lenguaje compilado.

¿Qué sistema de archivos y opciones de configuración debo usar? (Por ejemplo, ¡sé que no necesitaré un tiempo para esto!) El servidor de compilación pasará mucho tiempo leyendo y escribiendo archivos pequeños y escaneando directorios para ver qué archivos se han modificado.

ACTUALIZACIÓN: La integridad de los datos es de baja prioridad en este caso; es solo una máquina de construcción ... los artefactos finales serán comprimidos y archivados en otro lugar. Si el sistema de archivos en la máquina de compilación se corrompe y pierde todos los datos, simplemente podemos borrar y volver a crear imágenes; Las compilaciones continuarán ejecutándose como antes.

Use ext4fs como el sistema de archivos base con algunas opciones de aceleración como

noatime,data=writeback,nobh,barrier=0,commit=300

Luego, monte un ramdisk tmpfs encima para que los archivos escritos durante las compilaciones obtengan los beneficios del ramdisk. Cambie el procedimiento de compilación para mover los binarios resultantes de tmpfs al final de la compilación, o fusione los tmpfs nuevamente en ext4fs antes de desmontar.

¿El sistema de archivos más rápido? tmpfs montado fuera de RAM disponible, con noatimeset.

Esto solo es viable si tiene un procedimiento para verificar todo lo necesario para construir su árbol fuente (ya que el contenido de un sistema de archivos tmpfs desaparecerá cuando reinicie), y si la fuente y los objetos encajan en una esquina razonable de su RAM disponible ( con suficiente para ejecutar su compilador y enlazador sin intercambiar). Dicho esto, no puedes superar el trabajo sin RAM para la velocidad ...

A la respuesta de Michael Dillon, puedo agregar que puede crear un sistema de archivos ext4 con pocas opciones:

mkfs.ext4 -O dir_index,extent -i 8096 /dev/<disk>


dir_index
    Use hashed b-trees to speed up lookups in large directories.

extent 
    Instead of using the indirect block scheme for storing the location of data blocks in an inode, use extents instead.  This is a  much  more  efficient  encoding  which  speeds  up filesystem access, especially for large files.

-i 8096 le proporciona más inodos por tamaño, útil porque los entornos de creación crean muchos archivos.

Para las fuentes, sería preferible tener soporte de compresión sobre la marcha, que es Reiser4 o Btrfs . Ambos "todavía no son para producción", aunque he oído hablar de personas que usan ambos FSes en gran medida y felizmente. :-)

La siguiente opción (generalmente lo hago) es Reiser3 , no Ext3 . Ext3 puede ser un poco más rápido hoy en día, pero Reiser3 no tiene límites de tiempo de formato de nodos i, admite el cambio en línea de la opción "data =". Tiene soporte de "cola" que permite el empaquetado de archivos más pequeños, pero si le preocupa la velocidad, "anótelo".

Tanto XFS como JFS serían una molestia para el caso de "muchos archivos pequeños", especialmente si necesitara resolverlos.

(Olvidé mencionar EXT4: Sí, es aún más rápido, entonces EXT3. Pero todas las limitaciones de EXT3 mencionadas anteriormente son EXT4 también).

Las operaciones que describe brindan algunos consejos clave sobre lo que el sistema de archivos ideal debe poder hacer:

• Accesos r / w masivos al azar durante el proceso de construcción
• Muchos, muchos archivos se actualizan en poco tiempo, por lo que las operaciones rápidas de metadatos son críticas.
• Manejo eficiente de muchos archivos pequeños en sistemas de archivos posiblemente muy pesados.
• Lo suficientemente maduro como para no arriesgar la pérdida de datos en casos poco frecuentes y oscuros.

Btrfs y Ext4 son tres de los anteriores, y el cuarto es cuestionable. Ext4 probablemente sea lo suficientemente maduro para eso, pero btrfs aún no se ha horneado. noatimeayuda a que las operaciones de metadatos sean más eficientes, pero cuando está creando un montón de archivos nuevos, aún necesita operaciones de metadatos para ser extremadamente rápido.

Es entonces cuando el almacenamiento subyacente comienza a convertirse en un factor. Las operaciones de metadatos XFS tienden a concentrarse en unos pocos bloques, lo que puede dificultar las operaciones. Los sistemas de archivos de estilo Ext son mejores para acercar los metadatos a los datos que describe. Sin embargo, si su almacenamiento es lo suficientemente abstracto (está ejecutando en un VPS o conectado a una SAN) , no importa significativamente .

Cada sistema de archivos tiene pequeñas aceleraciones que se pueden hacer para obtener algunos puntos porcentuales más. El rendimiento del almacenamiento subyacente afectará en gran medida la ganancia que verá.

En términos de almacenamiento, si tiene suficientes gastos generales de operación de E / S en su almacenamiento, las ineficiencias del sistema de archivos comienzan a no ser tan importantes. Si usa un SSD para su partición de compilación, la elección del sistema de archivos es menos importante que con lo que se siente más cómodo trabajando.

Para muchos archivos pequeños, recomendaría Reiser sobre ext3, xfs, jfs ..., aunque he escuchado que ext4 es mucho mejor (es decir, al contrario de lo que dice poise) que sus encarnaciones anteriores para este patrón de acceso.

Reiser empuja muchos de los archivos hacia arriba en el árbol de inodo, por lo que funciona muy bien cuando se trata de archivos pequeños.

Sin embargo, las diferencias de comportamiento entre los principales sistemas de archivos son relativamente pequeñas en comparación con los beneficios que obtendrá al tener suficiente memoria física para almacenar en caché / buffer de manera efectiva.

y escanear directorios para ver qué archivos se han modificado.

Esta es una manera horrible de resolver el problema, aunque es relativamente simple. Si es tan importante, piense en escribir un controlador inotify para indexar las modificaciones.

OTOH, si está utilizando SSD flash (lo que le dará tiempos de búsqueda muy bajos), recomendaría usar un fs que distribuya la escritura de manera más efectiva por razones de longevidad, por ejemplo, JFFS2