# [HOWTO] Optimizando particiones

## pacho2

Puesto que en este tema no estoy muy ducho, agradeceré enormemente las contribuciones que queráis hacer.

El proposito de este hilo es que vayamos contando las opciones que consideremos "mejores" (bien por rendimiento, o bien por seguridad) para:

1. Montar las particiones

2. Crear las particiones

Se analizarán, en principio, los siguientes sistemas de archivos: ReiserFS, EXT2, EXT3, XFS y JFS (si queréis añadir alguno no tenéis más que pedirlo).

(este hilo esta en permanente desarrollo)

......

Saludos y gracias

----------

## aj2r

Pues voy a hacer la primera contribución, y si me equivoco en lo que digo corregidme   :Razz: 

Para reiserfs, a la hora de montarlo, existe la opción notail, que lo hace un poco más rápido y menos consumidor de CPU a cambio de no realizar el empaquetado de colas, una de las características que más me gustan de reiserfs y que hace que sea el sistema de ficheros que mejor aprovecha el espacio físico (aunque reiser4 lo hace aún mejor).

Para reiserfs y ext3 existe la opción de montaje data que puede tomar tres valores:

data=writeback

En el modo data=writeback, no se hace journalling de los datos, sólo de los metadatos. Aunque con esta opción se consigue el mejor rendimiento, si se produce un apagón repentino es probable que los últimos ficheros modificados se corrompan.

data=ordered (modo por defecto)

En este modo sólo se hace journalling de los metadatos, pero agrupa de forma lógica metadatos y bloques de datos en unidades llamadas transacciones. A la hora de escribir los metadatos al disco, primero se escriben los datos asociados. Este modo solventa la corrupción de datos y sin requerir el journalling de todos los datos. En general es un poco menos eficiente que writeback, pero significativamente más rápidp que un journalling completo.

data=journal mode

En este método se realiza journal de todos los datos y metadatos. Todos los datos son escritos primero en el "journal" y luego en su localización final.

----------

## pacho2

Muchas gracias por tu contribución  :Smile: 

Saludos

----------

## aj2r

Añadir que reiserfs no sólo mete en un mismo nodo hoja varias colas(tails) sino que también las comprime, y por eso principalmente consume más CPU y tiempo y consigue tan buenos resultados.

EDITO-> Una opción muy interesante para ext3 es ala hoar de dar formato a la partición usar la opción -O dir_index, que lo que hace básicamente es que se usen b-trees con tablas de referencia (hashed b-trees) para acelerar las búsquedas en directorios grandes. Puede aplicarse a una partición ya formateada con datos dentro haciendo 

```
tune2fs -O dir_index /dev/hdXX

e2fsck -D /dev/hdXX
```

 y reiniciando.

Se nota la diferencia a costa de perder un poco de espacio.

VUELVO A EDITAR-> Se me ocurre que podrías poner además al principio una breve descripción de los sistemas de ficheros, si quieres puedes copiar lo que tengo al principio de mi benchmark   :Wink: 

----------

## LinuxBlues

 *aj2r wrote:*   

> 
> 
> ```
> tune2fs -O dir_index /dev/hdXX
> 
> ...

 

Si no añades -Df a e2fsck el sistema de ficheros se queda sin modificar, a no ser que le toque revisión en el siguiente montaje. Cuidado con esto: pruébalo y verás. Muchas gracias por tu apoyo aj2r.

----------

## aj2r

 *LinuxBlues wrote:*   

> Muchas gracias por tu apoyo aj2r.

 

No se merecen   :Smile: 

Por cierto LinuxBlues ¿podrías explicar por aquí lo de que reiserfs en los núcleos 2.6 usa bloques de 128kB, y cómo hacer para que use 4kB y si se no ta la diferencia?

----------

## pacho2

 *LinuxBlues wrote:*   

>  *aj2r wrote:*   
> 
> ```
> tune2fs -O dir_index /dev/hdXX
> 
> ...

 

Gracias por el apunte  :Smile: 

 *aj2r wrote:*   

>  *LinuxBlues wrote:*   Muchas gracias por tu apoyo aj2r. 
> 
> No se merecen  
> 
> Por cierto LinuxBlues ¿podrías explicar por aquí lo de que reiserfs en los núcleos 2.6 usa bloques de 128kB, y cómo hacer para que use 4kB y si se no ta la diferencia?

 

Cuantos más colaboremos mejor  :Smile: 

Saludos y muchas gracias a los dos  :Wink: 

----------

## LinuxBlues

 *aj2r wrote:*   

> Por cierto LinuxBlues ¿podrías explicar por aquí lo de que reiserfs en los núcleos 2.6 usa bloques de 128kB, y cómo hacer para que use 4kB y si se no ta la diferencia?

 

Estás en plenas pruebas de sistemas de ficheros, he aquí la puerta de entrada a mi casa:

 */etc/fstab wrote:*   

> 
> 
> /dev/hdb3               /home           reiserfs        noatime,nodiratime,nolargeio=1,data=writeback   0 0
> 
> 

 

Estoy por jurar que el data=writeback es redundante ya que reiserfs sólo usa caché de metadatos, pero de lo contrario el kernel me lo monta en ordered data mode   :Confused: 

----------

## aj2r

 *LinuxBlues wrote:*   

> 
> 
> Estoy por jurar que el data=writeback es redundante ya que reiserfs sólo usa caché de metadatos, pero de lo contrario el kernel me lo monta en ordered data mode  

 

Creo que ya he escrito antes por aquí la diferencia entre ordered y writeback. Ordered es prácticamente tan seguro como un journal completo de los datos, mientras que writeback en un apagón o cuelgue del sistema probablemente hará que surjan inconsistencias en el sistema de ficheros. Los dos hacen sólo journalling de los metadatos, pero el algoritmo de escritura en disco es diferente.

----------

## pacho2

 *LinuxBlues wrote:*   

>  *aj2r wrote:*   Por cierto LinuxBlues ¿podrías explicar por aquí lo de que reiserfs en los núcleos 2.6 usa bloques de 128kB, y cómo hacer para que use 4kB y si se no ta la diferencia? 
> 
> Estás en plenas pruebas de sistemas de ficheros, he aquí la puerta de entrada a mi casa:
> 
>  */etc/fstab wrote:*   
> ...

 

Entonces lo de los bloques de 128kb u 4kb, se "regula" con la opción nolargeio?

¿tiene alguna ventaja que use los de 4kb en lugar de 128kb? ¿alguna desventaja?

Saludos y gracias por la información

----------

## aj2r

 *pacho2 wrote:*   

> 
> 
> Entonces lo de los bloques de 128kb u 4kb, se "regula" con la opción nolargeio?
> 
> 

 

Así es, con nolargeio=1 se usan bloques de 4kB

 *pacho2 wrote:*   

> 
> 
> ¿tiene alguna ventaja que use los de 4kb en lugar de 128kb? ¿alguna desventaja?
> 
> 

 

Según tengo entendido, el principal motivo de usar 128kB es para poder manejar particiones de tamaños superiores, el inconveniente por el que alguien podría querer desactivarlo es que a la hora de posicionarte en un fichero (seek) y leer de él, obviamente no es lo mismo leer 128kB que 4kB cada vez que te posiciones y leas. Si me equivoco corregidme.

----------

## Kensai

# tune2fs -O dir_index /dev/hdx#

# tune2fs -O has_journal -o journal_data /dev/hdx#

# tune2fs -m 1 /dev/hdx#

En verdad no se explicarlas todas pero dan el mejor performance y estabilidad. La ultima cambia el numero de blockes reservados a 1.

----------

## MarcosLuis

 *LinuxBlues wrote:*   

>  *aj2r wrote:*   Por cierto LinuxBlues ¿podrías explicar por aquí lo de que reiserfs en los núcleos 2.6 usa bloques de 128kB, y cómo hacer para que use 4kB y si se no ta la diferencia? 
> 
> Estás en plenas pruebas de sistemas de ficheros, he aquí la puerta de entrada a mi casa:
> 
>  */etc/fstab wrote:*   
> ...

 

Porqué en vez de montar la partición en /mnt/ como se hace normalmente la montas en /home ? Esto es recomendable? Otra cosa: cuando uno agrega al fstab data=writeback no tiene que hacer mas nada en otro fichero?

Esta modificacion no afecta otros ficheros del sistema ? Cuales son?

Saludos

----------

## pacho2

Creo que la monta en home porque su /dev/hdb3 es su partición para home (eso depende de cada instalación  :Wink: )

----------

## MarcosLuis

Cuando tu vas a opmizar con data=writeback, no habia que ageagar estas lineas al  /boot/grub/menu.lst

noaltoptions=quiet splash rootflags=data=writeback

altoptions=(recovery mode) single rootflags=data=writeback

despues en la consola: #tune2fs -o journal-data_writeback /dev/hda3 

y reinicio después para aplicar los cambios.

Esto yo lo hice en Ubuntu, en Gentoo hay que hacerlo tambien?

----------

## LinuxBlues

 *MarcosLuis wrote:*   

> #tune2fs -o journal-data_writeback /dev/hda3

 

Con respecto a lo de grub es innecesario, [supongo que te referías a la partición root (/)] dado que con este comando estás aplicando el journaling en modo writeback por defecto, y se aplicará cada vez que montes la partición. (Consulta dmesg si tienes dudas).

De cualquier modo si estás hablando de tune2fs, supongo que estás hablando de una partición ext3, en cuyo caso, curiosamente, el modo más rápido de hacerlas operar es con data=journal (por increíble que parezca, dado que en teoría deberá escribir los datos dos veces). Consulta este artículo de Daniel Robbins:

http://www-128.ibm.com/developerworks/linux/library/l-fs8.html#4

En cuanto a ext3 estoy pensando en escribir un apartado en este mismo hilo del foro, dado que he descubierto que tiene features no documentadas. Últimamente me ha dado por estudiar ext4 y estoy descubriendo muchas cosas acerca de ext3, usando bajo RedHat tune2fs -l /dev/hdXY (L minúscula), he visto la gran cantidad de features que se le puede añadir a ext3.

Bueno, no prometo nada, cada vez visito menos estos foros... Quizá más adelante publique una guía que vaya mucho más allá del dir_index. De momento no voy a decir absolutamente nada de las cosas que he descubierto acerca de ext3 porque he de hacer muchas pruebas y sé que proporcionar información incompleta puede ocasionar pérdidas de datos muy dolorosas para cualquiera... Por ello no diré nada más. Si alguna vez me pongo a sacar las conclusiones de todos mis tests, lo haré también en este hilo del foro.

----------

## MarcosLuis

Buenos LinuxBlues vamos a estar esperando con ansiedad tus pruebas y tus features, ya que , por lo menos en ambas distros que tengo,uso como FS Ext3,asi que cuando más rápido puedas publicar la guia te lo voy a agradecer.

Saludos

----------

