# [FS] Tamaño de inodos (abierto)

## the incredible hurd

El valor por defecto del tamaño de inodos es de 128bytes para ext3, en el caso de xfs se recomienda que sea de 2048bytes o 2K; debian se me autoinstaló con un tamaño de inodo de 256bytes y...

Estoy haciendo pruebas, estoy buscando en google aunque quizá con los términos de búsqueda equivocados, peeeero no encuentro nada referente al rendimiento; ¿alguien sabe si se obtiene un mayor rendimiento con inodos de 256bytes?, ¿el tamaño adicional únicamente sirve para los EA (extended attributes)? No sé que me hace pensar que a la larga será conveniente incrementarlo... No uso ningún 2.4 ya, por lo que los 128bytes no me resultaría estrictamente necesario.

Bueno, expongo mi duda por si alguien tiene ya resultados concluyentes al respecto y porque yo jamás me he creído eso de que el tamaño no importa.

----------

## opotonil

Espero no estar diciendo tonterias, pero por lo que yo entiendo el tamaño de los inodos mas que mejorar o empeorar el rendimiento lo que mejora o empeora es el aprovechamiento del disco siendo mejor un tamaño pequeño para particiones con ficheros de pequeño tamaño y un tamaño mayor para particiones con ficheros grandes. Resumiendo que el tamaño adecuado de inodos vendra definido por el tamaño de los ficheros que se almacenaran en la particion.

Pero casi mejor que esperes a ver si responde alguien que sepa de verdad del tema.

Salu2.

----------

## kalcetoh

 *opotonil wrote:*   

> 
> 
> Pero casi mejor que esperes a ver si responde alguien que sepa de verdad del tema.
> 
> 

 

Si, mejor   :Wink: 

A lo que te refieres es al tamaño de bloque, que es distinto del tamaño de inodo. En el tamaño de bloque sí que es cierto lo que dices, más o menos, de todas formas cuando creas el sistema de ficheros se usa el mejor tamaño de bloque según el dispositivo.

En los inodos se guarda información relativa cada fichero o directorio (existe un inodo por cada fichero o directorio). Entonces cada inodo tiene un tamaño mínimo de 128 bytes, y puede ser 256, 512, etc.

Para lo único que sirve aumentar el tamaño del inodo es para en el propio inodo guardar los atributos extendidos (extended  attributes). Evidentemente mientras más grandes sean los inodos más espacio desperdiciado tienes y parece que aumenta el rendimiento cuando se usan estos atributos extendidos.

No tengo muy claro para qué se usan los atributos extendidos, pero sé que Beagle y demás software para indexar contenido los usa, así que si vas a usar el sistema de ficheros para el home, puede ser interesante.

Te copio la parte correspondiente al man (man mkfs.ext2):

 *Quote:*   

> 
> 
> -I inode-size
> 
>               Specify the  size  of  each  inode  in  bytes.   mke2fs  creates
> ...

 

----------

## jgascon

 *kalcetoh wrote:*   

> 
> 
> A lo que te refieres es al tamaño de bloque, que es distinto del tamaño de inodo.
> 
> 

 

No, en xfs se puede definir también el tamaño del inodo no sólo del bloque. La utilidad mkfs.xfs que crea los sistemas de archivos xfs es bastante "inteligente" y suele escoger los valores adecuados para el dispositivo en el cual se va a crear el filesystem. Una cita de http://lxer.com/module/forums/t/26605/ (aunque hablan del tamaño del bloque):

 *Quote:*   

> 
> 
> On top of that, the mkfs.xfs tool detects when you create an XFS filesystem on an mdadm software RAID and will automagically use the right stripe size and all that.
> 
> All I had to benchmark was different blocksizes for XFS. It turns out that a blocksize of 4K was the best, with 82 Mb/s sustained write as opposed to 79.8 Mb/s for 1K blocks. With 1K blocks it was however much faster to create/delete many small files. I used bonnie++ and `time dd` with 1 Gb files and 10 Gb files to benchmark this.
> ...

 

Supongo que ya la habrás leido hurd, pero en el man de mkfs.xfs hay mucha información...

----------

## i92guboj

 *jgascon wrote:*   

>  *kalcetoh wrote:*   
> 
> A lo que te refieres es al tamaño de bloque, que es distinto del tamaño de inodo.
> 
>  
> ...

 

Y en ext3, como dicen por ahí arriba. Si recuerdo bien los parámetros son -m y -I para tamaño de bloque y de i-nodo respectivamente. Y si, ambas cosas son totalmente distintas. El concepto de bloque es lo que en fat se denomina cluster, y es la unidad mínima de espacio que un fichero ocupa en disco. El concepto de inodo es lo que en sistemas no basados en árboles, sino en tablas, conrrespondería a una entrada en la tabla de asignación de archivos (por ejemplo en FAT). Los bloques son subdivisiones del disco que almacenan pedacitos de nuestros archivos, mientras que los inodos son estructuras de información que solo contienen meta-información relevante para el sistema de archivos.

El sistema crea más o menos inodos dependiendo del tamaño de bloque y es por eso que yo formateo mi portage con un tamaño de bloque de 1k, lo cual hace que portage ocupe mucho menos espacio, y además permite que quepa en una partición de menos de 1 giga, porque con el tamaño de bloque normal me quedo sin inodos aunque quede espacio libre. Nunca he probado un tamaño de inodo mayor, así que no se realmente como de grande puede ser el impacto medio en la capacidad libre y en el rendimiento.

----------

## lanshor

Ante todo, perdón por si digo alguna tontería.

Hasta donde yo sé, el tamaño de los nodos-i y bloques no te afectará directamente en el rendimiento.

Respecto a los bloques: Un tamaño mayor de bloque te producirá fragmentación interna (que no degrada el rendimiento, pero desaprovecha mucho espacio del disco, sobretodo si se tratan de muchos archivos con tamaño menor al tamaño del bloque) y un tamaño pequeño te producirá fragmentación externa (aprovechas mejor el espacio, pero si los archivos son muy grandes te degradará el rendimiento (aunque se supone que con los schedulers de e/s del kernel eso apenas debería de notarse)).

Lo adecuado entonces es tener un tamaño de bloque pequeño cuando sean muchos archivos pequeños, y grande cuando sean pocos grandes: en otras condiciones (pocos pequeños/muchos grandes) es complicado dar consejos generales (¿cuántos son muchos?, ¿cuánto es grande?, ¿te importa realmente perder espacio?).

El tema de los i-nodos me es más abstracto, no se como funcionan en ext3 ni concretamente en ningún sistema de archivos común, pero supongo que no diferirán mucho de los clásicos i-nodos unix de toda la vida.

En los i-nodos clásicos se guardan los atributos del archivo/directorio (modo,enlaces,id propietario,id grupo...) y una serie de punteros directos + una serie de punteros indirectos simples + una serie de punteros indirectos dobles. El tamaño de i-nodo depende del número de punteros, así que aumentar el tamaño del nodo significa aumentar el número de punteros a bloques, y esto se traduce en un mayor tamaño máximo de archivo permitido. Supongo que también se podrá modificar el tamaño de los punteros (afectando al tamaño final del i-nodo), pero en este caso debes asegurarte de que tengan la longitud suficiente como para poder direccionar a tantos bloques como haya en la partición.

Y por último está la lista de nodos-i y su tamaño, que te restringe el número máximo de archivos que puede haber en esa partición (uno por cada nodo-i, los enlaces no cuentan ya que varios enlaces a un archivo comparten el mismo nodo-i). Esta lista te quitará espacio del disco conforme más elementos tenga y conforme más ocupen los nodos-i.

En resumen: en redimiento poco tienes que perder o que ganar, si quieres optimizar una partición hazlo de cara a aprovechar el espacio lo máximo posible; pero al precio que tiene el giga hoy en día... yo no me complicaría (a no ser que sea por gusto y amor al arte  :Smile: ).

----------

## the incredible hurd

 *jgascon wrote:*   

>  *kalcetoh wrote:*   
> 
> A lo que te refieres es al tamaño de bloque, que es distinto del tamaño de inodo.
> 
>  
> ...

 

Cierto, y en ext3, pero kalcetoh contestaba a opotonil y muy acertadamente además.

 *jgascon wrote:*   

> Supongo que ya la habrás leido hurd, pero en el man de mkfs.xfs hay mucha información...

 

Leí en un enlace que no logro volver a encontrar y buscar en el historial de mi navegador es una tarea de chinos   :Confused:   que el tamaño de inodo con xfs de 2048bytes era el que mejor rendimiento alcanzaba.

 *i92guboj wrote:*   

> así que no se realmente como de grande puede ser el impacto medio en la capacidad libre y en el rendimiento.

 

Menuda he liado, restauré mi backup de gentoo en un sistema de ficheros con inodos de 256bytes y no analicé el impacto en la capacidad libre, claro que me hubiera sido imposible, dado que cambié de reiserfs a ext3. En reiserfs sólo se usan inodos si uno quiere y por lo que sé el 3.6 no lo hace por defecto.

Ahora he actualizado Gentoo y bueno, no esperaré al cron para realizar otra copia de seguridad y hacer pruebas con bonnie++ e inodos de 128 y 256bytes.

 *lanshor wrote:*   

> Hasta donde yo sé, el tamaño de los nodos-i y bloques no te afectará directamente en el rendimiento.

 

Nota que no uso el correctísimo término i-nodo, sino inodo siguiendo la explicación de Dennis Ritchie: http://es.wikipedia.org/wiki/Inodo  :Wink: 

La cuestión es que leí (al final me vais a hacer buscar en el historial de mi navegador   :Crying or Very sad:  ) en el artículo aquel sobre XFS que se obtenía el mejor rendimiento con inodos de 2048bytes, no menores.

Todo este quebradero de cabeza ha surgido a partir de Linux: Inode Cache Performance. Te sugiero que vuelvas a leer la cita del manual de kalcetoh y busca "improved performance" tal y como él sugiere beagle se acelera y mucho.

No veo por qué no intentar aumentar al máximo el rendimiento de los sistemas de ficheros, lentamente y con copias de 

seguridad iré haciendo pruebas para ver que resultados obtengo, aumentar el readahead de la unidad, dependiendo de la controladora y del RAID también parece otra opción: Double your disk read performance in a single command.

Si teneis la suficiente paciencia iré publicando los resultados (que yo buscaba) en este mismo hilo.

Mucho cuidado grub solo soporta ext2 con inodos de 128bytes y no soporta en absoluto enlaces simbólicos. Por si a alguien se le ocurre probar con la partición de menor tamaño (/boot).

----------

## i92guboj

 *the incredible hurd wrote:*   

> 
> 
>  *i92guboj wrote:*   Hasta donde yo sé, el tamaño de los nodos-i y bloques no te afectará directamente en el rendimiento. 
> 
> 

 

Ya estaba yo preguntándome "qué es lo que me había fumado cuando escribí eso", pero no jeje, esa cita no es mía. Mira más arriba. En realidad es de lanshor.

Dicho eso, como (y esto si es mío) ya dije más arriba, no se cual pueda ser la magnitud de dicho impacto en el rendimiento neto.

----------

## the incredible hurd

 *i92guboj wrote:*   

> Ya estaba yo preguntándome "qué es lo que me había fumado cuando escribí eso", pero no jeje, esa cita no es mía. Mira más arriba. En realidad es de lanshor.
> 
> Dicho eso, como (y esto si es mío) ya dije más arriba, no se cual pueda ser la magnitud de dicho impacto en el rendimiento neto.

 

Mis más sinceras disculpas, i92guboj, lo edito y corrijo...

Por cierto, tras lo comentado en mi anterior mensaje, 

```
blockdev --setfra <doble del tamaño del buffer o cache de la unidad>
```

 resulta en una mejora increíble. ¿Por qué el doble?, porque hace referencia a bloques de 512bytes.

Y sin pruebas en la mano aún, pero noto el sistema de ficheros mucho más rápido, más fluido y haciendo cosas descabelladas que implican a miles de ficheros.... Claro que antes no me había dado por hacer estas cosas, por lo tanto puede ser psicológico   :Rolling Eyes: 

----------

## jgascon

 *the incredible hurd wrote:*   

> 
> 
> Y sin pruebas en la mano aún, pero noto el sistema de ficheros mucho más rápido, más fluido y haciendo cosas descabelladas que implican a miles de ficheros.... Claro que antes no me había dado por hacer estas cosas, por lo tanto puede ser psicológico
> 
> 

 

Yo me estoy haciendo una serie de pequeños scripts para testear el rendimiento de diferentes configuraciones/combinaciones de RAID y sistemas de archivos... Ya sé que hay muchos benchmarkings en Internet y herramientas (como bonnie++), pero por diferentes motivos no he encontrado nada que me termine de convencer... Si te interesan aquí tienes una muestra...

La idea es realizar los tests que indican aquí usando herramientas del sistema como dd o cp. Como son pruebas para un desktop y no para un servidor yo creo que es lo más adecuado...

----------

## lanshor

 *the incredible hurd wrote:*   

> 
> 
>  *lanshor wrote:*   Hasta donde yo sé, el tamaño de los nodos-i y bloques no te afectará directamente en el rendimiento. 
> 
> Nota que no uso el correctísimo término i-nodo, sino inodo siguiendo la explicación de Dennis Ritchie: http://es.wikipedia.org/wiki/Inodo 
> ...

 

 *i92guboj wrote:*   

> 
> 
> Ya estaba yo preguntándome "qué es lo que me había fumado cuando escribí eso", pero no jeje, esa cita no es mía. Mira más arriba. En realidad es de lanshor.
> 
> 

 

Me he perdido un poco  :Sad: 

¿Qué estaba mal de lo que dije?

----------

## i92guboj

 *lanshor wrote:*   

> 
> 
> ¿Qué estaba mal de lo que dije?

 

Sobre el tamaño de i-nodo, tan solo me puedo fiar de la página man de mkfs.ext2, que dice textualmente:

 *mkfs.ext2 man page wrote:*   

> 
> 
>        -I inode-size
> 
>               Specify the size of each inode in bytes.  mke2fs creates 128-byte inodes  by
> ...

 

Por tanto, tu afirmación de que el tamaño de inodo no impacta en el rendimiento, no es cierta. Como ya dije más arriba, no tengo experiencia personal con el tema, ni se como de grande es el impacto, pero si lo dice en la página man es que alguna base debe de tener.

En cuanto al tamaño de bloque (y aquí si puedo hablar con experiencia) todo depende. El tamaño de bloque influye en el rendimiento y mucho, dependiendo del tamaño medio por archivo. En particiones con miles de archivos pequeños, un tamaño de bloque grande va a desperdiciar mucho espacio. Y en particiones con archivos gigantescos, un tamaño de bloque pequeño degrada el rendimiento de forma más que perceptible. Ésto también se contradice con tu afirmación.

Por tanto, tanto el tamaño de bloque como el de i-nodo, en principio, afectan al rendimiento, aunque no hayan sido diseñados para ajustar el rendimiento, sino para definir la forma en que se almacena la información. En ambos casos, la alteración en el rendimiento es un efecto colateral, pero está ahí, y es perceptible.

----------

## lanshor

Lamento entonces lo dicho. Como ya suponía que podría equivocarme pedí perdón de antemano, aunque supongo que en estos casos es mejor no decir nada sin estar seguro antes (¡así lo haré la siguiente vez!). Tampoco os lo toméis mal, sólo quería ayudar.

De todas formas quiero aclarar que no me expresé correctamente con esa frase, cuando dije "directamente" quizás tendría que haber dicho "de forma evidente" o algo así, aunque puede que me hubiera equivocado igualmente.

Y en mi defensa de que no todo estaba tan mal...   :Twisted Evil: 

Lo de los bloques que comentas es básicamente lo mismo que digo yo, sé que con bloques pequeños y archivos grandes el rendimiento se degrada (es lo que digo en el comentario), pero como he oído tantas veces que los schedulers del kernel son tan maravillosos y hacen que la fragmentación producida no se note... pues me lo he creído sin pruebas, así que no lo tuve cuenta como pérdida de rendimiento.

Respecto a la página del man en realidad creo que tampoco iba tan desencaminado... te hablan del hecho de perder espacio por la lista (tabla en este caso) y de una posible pérdida de rendimiento que yo desconocía y que supongo que se debe a la naturaleza de ese sistema de ficheros concreto (al menos en los que yo he estudiado (sistemas teóricos o de hace 20 años) eso no pasa).

En cualquier caso, perdón una vez más   :Wink: 

----------

## i92guboj

No es necesario pedir perdón por eso. No creo que nadie se lo haya tomado mal, yo al menos no lo hice.

Tan solo comenté arriba que la cita no era mía, porque le habían puesto mi nombre. Pero nada más. Lo último que deseo es que nadie deje de dar su aportación o de colaborar por un simple error que puede tener cualquiera, y, como tu mismo dices, muchas veces las cosas no son ni blancas ni negras.

Por cierto, yo también me equivoco montones de veces  :Wink: 

----------

## Coghan

¡Me encanta este foro!.

Todo lo que quise saber sobre lo i-nodos y nunca me atreví a preguntar. Cada vez que leo un hilo de este tipo doy gracias por descubriros.

Ya se que no aporto nada, pero tenía que soltarlo.  :Wink: 

----------

## Inodoro_Pereyra

Interesantísimo...

Salud!

----------

## opotonil

Si ya sabia yo que estaba abriendo demasiado la bocaza   :Embarassed:  , bueno por lo menos avise. Como dice kalcetoh me estaba refiriendo al tamaño de bloque que esto de oir campanas y no saber donde me pasa demasiado a menudo...

Bueno a ver si me vuelvo a leer el post que esta muy interesante y es demasiado espeso como para enterarse con una lectura rapida.

Salu2.

----------

## gringo

ya puestos a hablar del tema, si se combinan readahead y hdparm se puede conseguir escuchar un mp3 sin acceder para nada al disco duro durante la reproducción, lo que es bastante interesante para los portátiles p.ej.

Además, no sé desde que versión del kernel, creo que desde el 2.6.22 o algo similar, hay una nueva infraestrcutura en el kernel, el así llamado adaptative readahead que al menos en teoría debería ajustar el readahead según la carga de transacciones y al parecer ha demostrado ser bastante eficiente en servidores de bases de datos de cargas elevadas.

No sé si la implementación llegó tal cual al kernel, creo que no, pero por si a alguien le interesa leer sobre el tema -> http://lwn.net/Articles/155510/

saluetes

----------

