sistema de archivos para archivar

Tengo algunos datos complejos de solo lectura en mi sistema de archivos. Contiene miles de instantáneas de ciertas revisiones de un repositorio svn y el resultado de las pruebas de regresión. Los archivos idénticos entre instantáneas ya están deduplicados mediante enlaces duros. De esta manera, la capacidad de almacenamiento no necesita ser grande, pero aún consume muchos inodes, y esto hace que fsck sea dolorosamente largo para mi sistema de archivos principal.

Me gustaría mover estos datos a otro sistema de archivos, para que no afecten demasiado al sistema de archivos principal. ¿Tienes sugerencias? Squashfs parece ser una opción posible, pero tendré que comprobar si puede manejar enlaces duros de manera eficiente.

Si se trata de la lentitud de fsck, ¿probaste ext4? Agregaron algunas características que hacen que fsck sea realmente rápido al no mirar los inodos no utilizados :

Fsck es una operación muy lenta, especialmente el primer paso: verificar todos los inodos en el sistema de archivos. En Ext4, al final de la tabla de inodos de cada grupo se almacenará una lista de inodos no utilizados (con una suma de control, por seguridad), por lo que fsck no verificará esos inodos. El resultado es que el tiempo total de fsck mejora de 2 a 20 veces, dependiendo del número de inodos utilizados (http://kerneltrap.org/Linux/Improving_fsck_Speeds_in_Ext4). Debe notarse que es fsck, y no Ext4, quien construirá la lista de inodos no utilizados. Esto significa que debe ejecutar fsck para obtener la lista de inodos no utilizados, y solo la próxima ejecución de fsck será más rápida (de todos modos, debe pasar un fsck para convertir un sistema de archivos Ext3 a Ext4). También hay una característica que participa en esta velocidad de fsck: "grupos de bloques flexibles"

Btrfs tiene soporte nativo para instantáneas, por lo que no tendría que usar enlaces duros para la deduplicación. Puede recrear su configuración actual creando un sistema de archivos btrfs y cargándolo con la revisión más temprana que necesite, y tomando una instantánea, y luego acelerando el repositorio hacia cada punto en el tiempo que necesita una instantánea y tomando una instantánea en cada paso. Esto debería ser más eficiente que los enlaces duros, y también más sencillo de configurar.

También creo (aunque no estoy seguro de esto) que squashfs deduplica los archivos de forma transparente, por lo que incluso si no maneja enlaces duros, aún vería beneficios. Si nunca necesita cambiar los datos en el sistema de archivos, entonces squashfs es probablemente el camino a seguir, ya que fsck podría reemplazarse por md5sum;)

Preferiría XFS ya que tengo muy buenas experiencias con este sistema de archivos. Pero realmente recomiendo que hagas una prueba con tus datos y todos los sistemas de archivos sugeridos.

Sé de varias tiendas que usan un DataDomain para exactamente ese propósito.

Su script de archivo puede ser muy simple (tar o rsync y cron, por ejemplo), y no necesita preocuparse por administrar enlaces duros o directorios que no se pueden vincular en la mayoría de los sistemas de archivos. No es necesario realizar copias incrementales, excepto para conservar el ancho de banda. Toda la magia ocurre debajo de la capa de bloques. No es inusual alojar datos virtuales por un valor de 15-20 TB mientras se utiliza solo un espacio en disco real de 1-2 TB. Todavía le quedará mucho para las copias de seguridad de su disco.

Los datos se servirían a través de NFS o iSCSI, pero no estoy seguro de si eso es un problema

Cuando FreeBSD obtenga ZFS v23, la deduplicación estará disponible para el resto de nosotros.