Qué tamaños de bloque para millones de archivos pequeños

Tengo 2x 4TB Disks en hardware RAID1 (podría ser un LSI MegaRaid) en Debian Wheezy. El tamaño del bloque físico es de 4kB. Voy a almacenar 150-200 millones de archivos pequeños (entre 3 y 10kB). No estoy pidiendo rendimiento, sino el mejor sistema de archivos y tamaños de bloque para ahorrar almacenamiento. Copié un archivo de 8200 bytes en un ext4 con un tamaño de bloque de 4kB. ¿Esto tomó 32kB de disco? ¿Es el diario la razón de eso? Entonces, ¿qué opciones hay para guardar la mayoría del almacenamiento para archivos tan pequeños?

— rabudde
fuente

Consulte también: ¿Cómo determino el tamaño de bloque de una partición ext3 en Linux?

— Chris S

Si estuviera en esa situación, estaría mirando una base de datos que puede almacenar todos los datos en un solo archivo con un índice compacto basado en desplazamiento, en lugar de archivos separados. Tal vez una base de datos que tenga un controlador FUSE disponible para interactuar con él como archivos cuando sea necesario, sin que en realidad todos sean archivos separados.

Alternativamente, podría mirar, por ejemplo, el percentil 60-70 de los tamaños de archivo, y tratar de ajustar ese tamaño de archivo directamente en los nodos del árbol del sistema de archivos, en lugar de como bloques separados en el disco. Almacenar 10k en cada nodo es probablemente una gran pregunta, pero si pudiera obtener el 60% -70% de los archivos allí, probablemente sería una gran victoria.

Solo ciertos sistemas de archivos pueden hacer eso (reiserfs es uno), y supongo que todo depende del tamaño de ese percentil, si encajará en el árbol. Es posible que pueda sintonizarlo. Supongo que intenta encajar el resto en un bloque.

Y no te preocupes por las revistas; tienen un límite de tamaño superior de todos modos.

No no no no no no no no solo ... no a su primer párrafo. Cometí este error hace años y tuve que deshacerlo más tarde. También heredé sistemas que usan este patrón de diseño. Los archivos pertenecen al sistema de archivos, o como compromiso, en un objeto FileStream de SQL Server si debe combinarlos (por lo tanto, tal vez su controlador FUSE, pero aún así no). Hay otras consideraciones al trabajar en el sistema de archivos, como no colocar 4 millones de archivos en una carpeta (también he cometido ese error).

— Mark Henderson el

@MarkHenderson, pero el problema es definir qué DEBE ser un archivo y qué debe ser un registro. Sin más detalles, cientos de millones de cosas pequeñas me parecen MUCHO más como discos. El hecho de que actualmente los tenga como archivos, no significa que deban permanecer así, o deberían haber sido así. Además, nunca sugerí por un segundo usar SQL Server para el trabajo;)

Hace 5 años heredé un sistema con 1 millón de archivos en una sola carpeta, y alrededor de 10,000 nuevos archivos de 1-4 KB cada día. Decidí tirarlos a todos en una tabla ISAM porque "¡Hey, son solo texto para analizar!" y luego resultó ser un gran error porque ahora tenía una sola mesa de 12GB con un grupo de filas que en su mayoría no hacían nada después de que fueron procesadas. Así que volví a colocarlos en un sistema de archivos con carpetas heiraquiales basadas en el GUID del nombre de archivo.

— Mark Henderson el

(por qué una sola tabla de 12GB con filas squllion era un problema era un asunto diferente en el que no voy a entrar aquí)

— Mark Henderson

@ MarkHenderson: No es un problema diferente, por eso dijiste que era la solución incorrecta ("... gran error porque ahora tenía una sola mesa de 12 GB con un grupo de filas ..."). Eliges el formato de tabla / motor de base de datos incorrecto, pero el concepto de poner muchas cosas pequeñas en un solo archivo con un ÍNDICE es sólido, siempre que lo hagas bien. Lo que desea es una base de datos que se destaque en las tiendas de clave / valor para millones de objetos pequeños, con fragmentación automática. También tenga en cuenta que específicamente ni siquiera se preocupa por el rendimiento, solo por el espacio.