¿Cuál es la diferencia entre "tamaño de inodo" y "Bytes por inodo"

Debajo de la información se toma de la página del manual, me gustaría saber la diferencia entre bytes por inodo y tamaño de inodo?

-i bytes-per-inode

Especifique la relación bytes / inodo. mke2fs crea un inodo por cada byte de bytes por inodo de espacio en el disco. Cuanto mayor sea la relación bytes por inodo, se crearán menos inodos. Este valor generalmente no debería ser menor que el tamaño de bloque del sistema de archivos, ya que entonces se crearán demasiados inodes. Tenga en cuenta que no es posible expandir el número de inodos en un sistema de archivos después de que se crea, así que tenga cuidado al decidir el correcto valor para este parámetro.

-I inode-size

Especifique el tamaño de cada inodo en bytes.mke2fs crea inodos de 256 bytes de forma predeterminada. En los núcleos posteriores a 2.6.10 y algunos núcleos de proveedores anteriores, es posible utilizar inodos de más de 128 bytes para almacenar atributos extendidos para mejorar el rendimiento. El valor del tamaño del inodo debe ser una potencia de 2 mayor o igual a 128. -tamaño más espacio consumirá la tabla de inodo, y esto reduce el espacio utilizable en el sistema de archivos y también puede afectar negativamente el rendimiento. Los atributos extendidos almacenados en inodos grandes no son visibles con los núcleos más antiguos, y dichos sistemas de archivos no se podrán montar con 2.4 núcleos No es posible cambiar este valor después de crear el sistema de archivos.

Bueno, primero, ¿qué es un inodo? En el mundo de Unix, un inodo es un tipo de entrada de archivo. Un nombre de archivo en un directorio es solo una etiqueta (¡un enlace!) A un inodo. Se puede hacer referencia a un inodo en múltiples ubicaciones (enlaces duros).

-i bytes por inodo (también conocido como inode_ratio)

Por alguna razón desconocida, este parámetro se documenta en ocasiones como bytes por inodo y en ocasiones como inode_ratio . De acuerdo con la documentación, esta es la relación bytes / inodo . La mayoría de los humanos comprenderán mejor cuando se indique como (disculpe mi inglés):

• 1 inodo por cada X bytes de almacenamiento (donde X es bytes por inodo).
• El tamaño de archivo promedio más bajo que puede caber.

La fórmula (tomada del mke2fs código fuente ):

inode_count = (blocks_count * blocksize) / inode_ratio

O incluso simplificado (suponiendo que el "tamaño de partición" sea más o menos equivalente a blocks_count * blocksize, no he verificado la asignación):

inode_count = (partition_size_in_bytes) / inode_ratio

Nota 1: incluso si proporciona un número fijo de inodo en el momento de creación de FS ( mkfs -N ...), el valor se convierte en una relación, por lo que puede ajustar más inodo a medida que amplía el tamaño del sistema de archivos.

Nota 2: Si ajusta esta proporción, asegúrese de asignar significativamente más inodo del que planea usar ... realmente no desea reformatear su sistema de archivos.

-I tamaño inode

Este es el número de bytes que el sistema de archivos asignará / reservará para cada inodo que pueda tener el sistema de archivos. El espacio se usa para almacenar los atributos del inodo (lea Introducción a Inodes ). En Ext3, el tamaño predeterminado era 128. En Ext4, el tamaño predeterminado es 256 (para almacenar extra_isizey proporcionar espacio para atributos extendidos en línea). lea Linux: ¿Por qué cambiar el tamaño del inodo?

Nota: X bytes de espacio disjks se asignan para cada inodo asignado, ya sea libre o utilizado, donde X = tamaño de inodo.

bytes por inodo determina cuántos inodes se crean para ese sistema de archivos; tamaño de inodo determina qué tan grande es cada uno de esos inodos.

Necesita muchos inodos si tiene la intención de colocar muchos archivos pequeños (y / o muchos directorios) en el sistema de archivos.

AFAIK, realmente solo necesita inodos que sean más grandes que el tamaño predeterminado de 256 bytes si desea almacenar atributos extendidos para sus archivos. psusi dice en los comentarios que eso no es correcto.

Esquema de sistema de archivos extremadamente tosco:

|_|__inodes__|_______________________DATA_________________________________|

• inode-ratio / bytes-per-inode = cantidad de inodes para el área DATA
• inode-tamaño = tamaño de cada inodo en el ínodos área

Realmente me gustó la respuesta de sjas, da la esencia de la diferencia.

Esta es solo mi propia expansión (ya que no puedo comentar ni votar, solo comenzando con este intercambio de pila) y quería una respuesta para mí expresada de manera equilibrada en términos no técnicos comprensibles para el usuario que necesita tomar la decisión durante el volumen de datos configuración pero no necesariamente conoce todos los detalles detrás de la implementación.

Personas / Objetos: - volumen (s) de datos en dispositivos de almacenamiento - archivos en volumen (s) - dispositivos de almacenamiento, están formateados y proporcionan bloques de bytes y sus direcciones - ubicaciones de archivos en el almacenamiento

Acciones: crear / eliminar / renombrar archivos y carpetas por el sistema operativo en el almacenamiento, lecturas / escrituras / movimientos de archivos, cambios de permisos, etc.

El archivo de tamaño de N bytes debe crearse en "fragmentos" (bloques). Aunque en teoría uno puede pensar que los archivos podrían administrarse como secuencias de bytes individuales (lógicamente pueden), todo lo que necesitaríamos para administrar archivos en el espacio sería un índice designado que indicara algunas propiedades del archivo (nombre, etc.) y dónde comienza cada archivo el almacenamiento. Sin embargo, debido a la forma en que el hardware está diseñado con los "buses" y los "bloques" y las consideraciones de rendimiento, esos "fragmentos" tienen un tamaño particular y un múltiplo del tamaño de bloque de los medios (por ejemplo, 512 bytes, 4096 bytes) y administrado por la capa de inodes que le dice a la siguiente capa sobre las ubicaciones de los archivos y cómo se agrupan los fragmentos cuando se necesitan encontrar, cargar en la memoria, etc.

Si uno tuviera un gran rollo de papel (volumen) y tuviera que diseñar un almacenamiento de información para documentos hechos de páginas (de caracteres o bits de información) para almacenar documentos de varias páginas, lo que se necesita es un índice (para encontrar documentos), espacio de almacenamiento para las páginas (con algunas posiciones simples de páginas). En mecanismo de clasificación Unix (inodes) y corte real en páginas. tamaño de inodo es el tamaño de entrada de índice (más o menos) bytes por inodo es el tamaño de página

Efectos de cambiar las dos configuraciones en cuestión:

cambiar el tamaño del inodo: por lo general, no hay necesidad de cambiar, quédese con el valor predeterminado (según el enlace publicado en la respuesta anterior a una discusión)

bytes por inodo: afecta el número máximo de archivos que uno puede crear en el volumen (posiblemente el rendimiento y el "desperdicio" de bytes no utilizados)

Volviendo a la analogía del rollo de papel: imagine que tiene que escribir y almacenar un documento de tamaño particular (un archivo) en dicho sistema (o muchos documentos de varios tamaños), si el tamaño de la página, que se presiona durante el "sistema de escritura y almacenamiento" "definición y no es flexible, es el mismo documento que puede requerir muchas páginas, si el tamaño de página del" sistema "es muy grande y el tamaño del documento es pequeño, podría desperdiciarse mucho papel al tener espacios en blanco y colocar archivos pequeños en una página. Si el tamaño de la página es grande, hay menos páginas que deben usarse para el documento, pero podría haber mucho "espacio en blanco perdido" en la última página utilizada. Entonces, todo depende ... del tamaño de los archivos que se utilizarán y cuántos. La otra consideración es la velocidad de encontrar y traer el documento de muchas páginas.

Espero que tenga sentido (lo tiene para mí) y comente si he abusado seriamente de alguna parte del diseño de ext o de las opciones de mkfs.