Tiempo ext3 fsck versus tamaño de partición

Estoy haciendo la configuración para una granja de almacenamiento a gran escala, y para evitar la necesidad de fscks de un mes, mi plan es dividir el almacenamiento en numerosos sistemas de archivos más pequeños (esto está bien, ya que tengo un árbol de archivos bien guardado , por lo que puede fácilmente tener sistemas de archivos separados montados sobre 1/, 2/, 3/, 4/, etc).

Mi dificultad es encontrar una enumeración de lo que es un tamaño "razonable" para un sistema de archivos, para mantener fsck veces similarmente "razonable". Si bien soy plenamente consciente de que el tiempo absoluto para un tamaño determinado dependerá en gran medida del hardware, parece que no puedo encontrar ninguna descripción de la forma de la curva para los tiempos ext3 fsck con diferentes tamaños de sistema de archivos, y cuáles son las otras variables ( ¿Un sistema de archivos lleno de archivos en un solo directorio tarda más de uno con 10 archivos en cada uno de los miles de directorios en un árbol; archivos grandes vs archivos pequeños; sistema de archivos completo vs sistema de archivos vacío, y así sucesivamente).

¿Alguien tiene referencias a números bien investigados sobre esto? De lo contrario, cualquier anécdota sobre estos temas debería al menos ayudar a guiar mi propia experimentación, si fuera necesario.

EDITAR : Para aclarar: independientemente del sistema de archivos, si algo sale mal con los metadatos, será necesario verificarlo. Si los re-fscks basados ​​en tiempo o montaje están habilitados o necesarios no es un problema, y ​​la única razón por la que pido números específicamente relacionados con ext3 es porque ese es el sistema de archivos más probable para elegir. Si conoce un sistema de archivos que tiene un proceso fsck particularmente rápido, estoy abierto a sugerencias, pero debe ser una opción sólida (afirma que "¡el sistema de archivos X nunca necesita fscking!" Se reirá y se burlará por completo) . También soy consciente de la necesidad de copias de seguridad, y el deseo de fsck no es un sustituto de las copias de seguridad, sin embargo, simplemente descartar el sistema de archivos y restaurar la copia de seguridad cuando falla, en lugar de fscking, parece realmente un

Según un artículo de Mathur et al. (p. 29), el tiempo e2fsck crece linealmente con la cantidad de inodes en un sistema de archivos después de cierto punto. Si el gráfico es adecuado, es más efectivo con sistemas de archivos de hasta 10 millones de inodos.

Cambiar a ext4 ayudaría, bajo la condición de que su sistema de archivos no esté cargado hasta el borde, donde la ganancia de rendimiento (debido a no verificar los inodos marcados como no utilizados) no tiene un efecto perceptible.

Creo que tendrás que hacer tu propio benchmarking. Una búsqueda rápida en Google no reveló nada, excepto que ext4 funciona mucho más rápido que ext3.

Entonces, cree algunas particiones ext3, 100GB, 200GB, etc. hasta el tamaño del disco que usará. Luego llénalos con datos. Si puede usar datos que se parezcan a sus datos de producción (archivos por directorio, distribución de tamaño de archivo, etc.), entonces será lo mejor. Tenga en cuenta que simplemente copiando archivos desde otra partición desde un dispositivo de copia de seguridad los colocará en el disco perfectamente distribuido y desfragmentado, por lo que sus pruebas carecerán de muchos tiempos de búsqueda de cabezales de disco que vendrán de muchas escrituras / modificaciones / eliminaciones.

También deberás pensar un poco en fscks paralelos. Vea el último par de campos en / etc / fstab. Las particiones en el mismo disco físico deben hacerse en secuencia; Se pueden hacer varios discos en el mismo controlador en paralelo, pero tenga cuidado de no sobrecargar el controlador y ralentizarlos.

http://lmgtfy.com/?q=fsck+benchmark

parece que fsck en ext4 filesystems es significativamente más rápido que en ext3, con algunos informes de ext4 fsck siendo 10 o incluso más veces más rápido que ext3.

Dos artículos bastante interesantes de esa búsqueda son:

http://thunk.org/tytso/blog/2008/08/08/fast-ext4-fsck-times/ yhttp://thunk.org/tytso/blog/2009/02/26/fast-ext4-fsck-times-revisited/

¿Hay alguna razón por la que no pueda usar un sistema de archivos que no fuerce el tiempo o los fscks basados ​​en el recuento de montaje cuando reinicie?

(los fscks basados ​​en el tiempo realmente me molestan: para un servidor de tiempo de funcionamiento prolongado, prácticamente garantiza que tendrá que hacer un fsck completo cada vez que actualice el kernel).

de todos modos, XFS es uno de los sistemas de archivos de registro en diario que no fuerzan un fsck. digno de una mirada.