# data=writeback en ext4 ¿cómo?

## Stolz

Quiero desactivar el journaling de mi partición /, que usa ext4.

Si añado a mi /etc/fstab la opción data=writeback no me monta / al inicial, con el siguiente mensaje:

```
 * Checking root filesystem ...

/dev/sda3: clean, ...

 * Remounting root filesystem read/write ...

 * Root filesystem could not be mounted read/write 

```

El caso es que sin dicha opción arranca bien y si hago un 

```
tune2fs -l /dev/sda3 | grep features
```

No aparece la opción has_journal ¿significa esto que aunque no lo indique en /etc/fstab ya tengo el journaling desactivado?

Si no es así, ¿cual es la opcion equivalente a data=writeback para ext4? En la documentación man y en la del kernel sigue apareciendo como opción correcta (aunque en la documentación de tune2fs parece que la han renombrado a journal_data_writeback)

Gracias.

----------

## gringo

por lo del journal creo que la única solución es hacerlo con el fs desmontado. 

Por el writeback es realmente lo mismo pero lo activé añadiendo rootflags=data=writeback a los parámetros del kernel. Entiendo que asi sólo se aplica a root y no a las demás particiones, a mi me valía porque gentoo lo tengo metido en una única partición.

En el mount no aparece pero dmesg confirma que se ha activado :

```
2.099712] EXT4-fs (sda3): mounted filesystem with writeback data mode. Opts: data=writeback
```

```
/dev/root on / type ext4 (rw,noatime,discard,nodelalloc,barrier=0,commit=0)
```

Supongo que lo del journal lo dices porque usas un ssd ( como yo), hice hace tiempo varias pruebas de rendimiento y yo al menos no fui capaz de ver diferencias notables con o sin journal.

Además tengo entendido que desde hace poco se ha tuneao ext4 para ser mucho menos agresivo con el journaling en caso de que haya un ssd ( ahora mismo no encuentro en el enlace ...).

 *Quote:*   

> tune2fs -l /dev/sda3 | grep features

 

a mi si me aparece has_journal, si no te aparece es que debes tenerlo desactivado.

```
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
```

saluetes

----------

## deovex

Por curiosidad, ¿Por que quieres desactivar el journaling en la partición /?

----------

## Stolz

deovex, uso un disco SSD y tener activado el journal reduce ligeramente el rendimiento y aumenta el número de escrituras en disco, algo desaconsejable para discos SSD. Como tengo una copia diaria en otros discos raid no me quita el sueño saber que estoy sin journaling. En general salvo que estés usando SSD y además tengas un buen respaldo, no recomiendo desactivarlo nunca. En cualquier caso, solo estoy de pruebas, no pensaba dejarlo así para siempre y más ahora sabiendo que no penaliza mucho en las últimas versiones.

gringo, he hecho todos los cambios para desactivar el journaling con el sistema de ficheros desmontado pero no caí en que /etc/init.d/ en realidad no monta "/", sino que lo "remonta" en modo escritura. Eso debe ser lo que lo fastidia todo.

En /proc/mounts no me aparece nada. Probaré con la opción del kernel y miraré dmesg.

----------

## Txema

Revisa esto: http://blog.loxal.net/2009/04/tuning-ext4-for-performance-with.html

Yo para activar el writeback ejecutaba un comando para la partición: tune2fs -o journal_data_writeback si mal no recuerdo pero tenía entendido que eso no era más que otro modo de journaling, vamos que al fin y al cabo seguirías teniendo journaling ¿no?

¿Para quitar el journaling no deberías usar esto: tune2fs -O ^has_journal? (http://fenidik.blogspot.com/2010/03/ext4-disable-journal.html)

Un saludo.

----------

## gringo

 *Stolz wrote:*   

> he hecho todos los cambios para desactivar el journaling con el sistema de ficheros desmontado pero no caí en que /etc/init.d/ en realidad no monta "/", sino que lo "remonta" en modo escritura. Eso debe ser lo que lo fastidia todo.
> 
> En /proc/mounts no me aparece nada. Probaré con la opción del kernel y miraré dmesg.

 

creo que el problema simplemente es que el journal necesita un "replay" para poder desactivarse, lo que necesariamente tiene que ser con el sistema de archivos demontado.

Lo del writeback creo que es algo similar, en ext4 ya no se permite cambiar la "bitácora" en caliente a menos que sea con el sistema de archivos desmontado.

Si quieres hacer pruebas : en mis resultados ( que era básicamente mover tanto bloques grandes como muchos archivos pequeños - las fuentes del kernel- a lo loco por doquier en el ssd hasta llenarlo y luego eliminarlo nuevamente), los ganadores fueron nilfs, ext2 y btrfs, por ese órden. Estas pruebas no las hice con este ssd de intel sino con un Runcore IV Pro que tengo en mi eeepc. 

Btrfs me gusta mucho por todo lo que ofrece como plus ( compresión p.ej.) pero se nota que está muy verde y además no tiene siquiera un fsck (WTF!!!).

NILFS fue el más rápido pero no se porque cada vez que se inciaba la máquina se pasaba como cosa de 10 minutos enviando del órden de 40Mb/s al disco duro, supongo que a modo de replay o algo similar, la verdad no me paré a mirarlo porque me parece inaceptable para un ssd.

saluetes

----------

## gringo

ugh, buscando por otras historias me he encontrado con un hilo en la lkml en el que se demuestra básicamente que data=writeback deshabilita TRIM.

lo he probado en mi ssd (Intel X25M) y efectivamente si deshabilito writeback TRIM funciona, sino, no :

SIN writeback habilitado :

- seq 1 1000 > testfile

- hdparm --fibmap testfile

- hdparm --read-sector 133144976 /dev/sda ( en mi caso)

```
/dev/sda:

reading sector 133144976: succeeded

0a31 0a32 0a33 0a34 0a35 0a36 0a37 0a38

0a39 3031 310a 0a31 3231 310a 0a33 3431

310a 0a35 3631 310a 0a37 3831 310a 0a39

3032 320a 0a31 3232 320a 0a33 3432 320a

0a35 3632 320a 0a37 3832 320a 0a39 3033

330a 0a31 3233 330a 0a33 3433 330a 0a35

3633 330a 0a37 3833 330a 0a39 3034 340a

0a31 3234 340a 0a33 3434 340a 0a35 3634

340a 0a37 3834 340a 0a39 3035 350a 0a31

3235 350a 0a33 3435 350a 0a35 3635 350a

0a37 3835 350a 0a39 3036 360a 0a31 3236

360a 0a33 3436 360a 0a35 3636 360a 0a37

3836 360a 0a39 3037 370a 0a31 3237 370a

0a33 3437 370a 0a35 3637 370a 0a37 3837

370a 0a39 3038 380a 0a31 3238 380a 0a33

3438 380a 0a35 3638 380a 0a37 3838 380a

0a39 3039 390a 0a31 3239 390a 0a33 3439

390a 0a35 3639 390a 0a37 3839 390a 0a39

3031 0a30 3031 0a31 3031 0a32 3031 0a33

3031 0a34 3031 0a35 3031 0a36 3031 0a37

3031 0a38 3031 0a39 3131 0a30 3131 0a31

3131 0a32 3131 0a33 3131 0a34 3131 0a35

3131 0a36 3131 0a37 3131 0a38 3131 0a39

3231 0a30 3231 0a31 3231 0a32 3231 0a33

3231 0a34 3231 0a35 3231 0a36 3231 0a37

3231 0a38 3231 0a39 3331 0a30 3331 0a31

3331 0a32 3331 0a33 3331 0a34 3331 0a35

3331 0a36 3331 0a37 3331 0a38 3331 0a39

3431 0a30 3431 0a31 3431 0a32 3431 0a33

3431 0a34 3431 0a35 3431 0a36 3431 0a37

3431 0a38 3431 0a39 3531 0a30 3531 0a31

3531 0a32 3531 0a33 3531 0a34 3531 0a35
```

- rm testfile

- sync && sync && echo 3 > /proc/sys/vm/drop_caches

- hdparm --read-sector 133144976 /dev/sda

```
/dev/sda:

reading sector 133144976: succeeded

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000
```

si hago lo mismo con writeback habiltado las salidas de hdparm --read-sector son idénticas en ambos casos.

Supongo que será un problema de firmware, al menos por lo que entiendo en el hilo el último firmware de mi ssd debería solucionarlo.

Alguien mas puede confirmar esto ?

saluetes

----------

## Stolz

 *Txema wrote:*   

> Revisa esto: http://blog.loxal.net/2009/04/tuning-ext4-for-performance-with.html
> 
> Yo para activar el writeback ejecutaba un comando para la partición: tune2fs -o journal_data_writeback si mal no recuerdo pero tenía entendido que eso no era más que otro modo de journaling, vamos que al fin y al cabo seguirías teniendo journaling ¿no?
> 
> ¿Para quitar el journaling no deberías usar esto: tune2fs -O ^has_journal? (http://fenidik.blogspot.com/2010/03/ext4-disable-journal.html)
> ...

 

Sí Txema, tienes razón, estaba hecho un lío y lo expresé mal. No es lo mismo desactivar el journal totalmente (-O ^has_journal) que desactivar el journal de los datos y dejar solo el de los metadatos (-O has_journal -o  journal_data_writeback y luego montar con data=writeback). El primero debería ser el que más rinde pero el más inseguro (posible corrupción de datos ante fallo inesperado de la alimentación). El segundo debería rendir un poco peor pero ser algo más seguro(pérdida de los últimos cambios pero sin producir corrupción de datos ante fallo inesperado de la alimentación). Dejar el comportamiento por defecto (data=ordered) debería ser el que peor rinde pero el más seguro ante fallos.

Mi idea era más que aumentar el rendimiento, minimizar las escrituras en disco. data=writeback me parecía la opción más equilibrada pero si se confirma que desactiva TRIM prefiero quedarme con el journaling desactivado. Ahora me surgen algunas dudas: Las opciones commit, nobh y nobarrier (equivalente a barrier=0) ¿tienen sentido en un sistema sin journaling (^has_journal)? ¿o solo son para sistemas con journal (has_journal && data=*)?

-- Edit

gringo, tanto con data=writeback como con data=ordered yo siempre veo las mismas cifras.

Con data=writeback:

```
# mkfs.ext4 -E discard -m 0 -O dir_index,has_journal /dev/sda1

# tune2fs -o journal_data_writeback,nobarrier,discard /dev/sda1

# mount /dev/sda1 /tmp/test -o data=writeback,discard

# tail /var/log/messages

EXT4-fs (sda1): mounted filesystem with writeback data mode. Opts: data=writeback,discard

# cd /tmp/test

# seq 1 1000 > testfile

# sync && sync

# hdparm --fibmap testfile

testfile:

 filesystem blocksize 1024, begins at LBA 2048; assuming 512 byte sectors.

 byte_offset  begin_LBA    end_LBA    sectors

           0      18954      18961          8

# hdparm --read-sector  18954  /dev/sda

/dev/sda:

reading sector 18954: succeeded

0a31 0a32 0a33 0a34 0a35 0a36 0a37 0a38

0a39 3031 310a 0a31 3231 310a 0a33 3431

...

# rm testfile

# sync && sync && echo 3 > /proc/sys/vm/drop_caches

# hdparm --read-sector  18954  /dev/sda

/dev/sda:

reading sector 18954: succeeded

0a31 0a32 0a33 0a34 0a35 0a36 0a37 0a38

0a39 3031 310a 0a31 3231 310a 0a33 3431

...

```

Con data=ordered:

```

# cd

# umount /tmp/test

# tune2fs -o journal_data_ordered,nobarrier,discard /dev/sda1

# mount /dev/sda1 /tmp/test -o data=ordered,discard

# tail /var/log/messages

EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: data=ordered,discard

# cd /tmp/test

# seq 1 1000 > testfile

# sync && sync

# hdparm --fibmap testfile

testfile:

 filesystem blocksize 1024, begins at LBA 2048; assuming 512 byte sectors.

 byte_offset  begin_LBA    end_LBA    sectors

           0      18962      18969          8

# hdparm --read-sector  18962  /dev/sda

/dev/sda:

reading sector 18962: succeeded

0a31 0a32 0a33 0a34 0a35 0a36 0a37 0a38

0a39 3031 310a 0a31 3231 310a 0a33 3431

...

# rm testfile

# sync && sync && echo 3 > /proc/sys/vm/drop_caches

# hdparm --read-sector  18962  /dev/sda

/dev/sda:

reading sector 18962: succeeded

0a31 0a32 0a33 0a34 0a35 0a36 0a37 0a38

0a39 3031 310a 0a31 3231 310a 0a33 3431

....
```

¿Significa que TRIM no está funcionando en mi sistema? Tengo entendido que si no está funcionado "dmesg | grep  discard" muestra algo como "discard not supported" pero no es mi caso. Se que con TRIM activado se marcan como disponibles los sectores de los ficheros borrados pero ¿también se ponen a cero?¿o ponerlos a cero es algo que cada disco gestiona a su manera?

----------

## gringo

 *Stolz wrote:*   

> ¿Significa que TRIM no está funcionando en mi sistema? Tengo entendido que si no está funcionado "dmesg | grep  discard" muestra algo como "discard not supported" pero no es mi caso. Se que con TRIM activado se marcan como disponibles los sectores de los ficheros borrados pero ¿también se ponen a cero?¿o ponerlos a cero es algo que cada disco gestiona a su manera?

 

por lo que tengo entendido si TRIM funciona los datos marcados como borrados por el usuario se quedan a cero en disco, marcándolos como disponibles.

Que te dice un hdparm -I /dev/sda | grep TRIM ??

De cualquier manera, esto lo controla el firmware del chisme en cuestión, los de intel por lo que tengo entendido son muy agresivos con el TRIM. Igual en tu modelo es de otra manera.

Hay dispositivos que directamente no soportan TRIM aunque digan al SO que si lo soportan, esto me pasó con el Runcore que mencioné antes.

que modelo tienes ?

 *Quote:*   

> commit, nobh y nobarrier

 

commit creo que no tiene mucho sentido en un ssd aunque no me he parado mucho a mirarlo. 

nobh por lo que tengo entendido está a punto de desaparecer y sólo funciona con writeback.

nobarrier creo que si tiene sentido para ssd en cuanto que simplifica el proceso para el ssd. Obviamente tb. tiene la desventaja de que puedes joder el fs.

de lo que se trata en los ssd ( creo yo) es de tener un sistema de archivos lo mas simple posible. De ahi que sacarle operaciones complejas como delalloc o barriers al ext4 deberían no sólo conseguir algo mas de rendimiento sino tb. ser mas benévolo con el ssd.

Por otra parte, sé que entre el kernel 2.6.31 y el 2.6.35 tanto en ext como en xfs se añadió mucho código diseñado para los ssd pero no he mirado que es lo que hace realmente.

saluetes

----------

## gringo

sólo escribo para comentar que he podido probar lo del writeback /TRIM en un vertex2 y en otro ssd de intel (320)y veo exactamente el mismo comportamiento que con mi ssd. Me he asegurado que el firmware estaba actualizado en los tres antes de hacer ninguna prueba.

saluetes

----------

## opotonil

Por si os puede interesar:

http://www.phoronix.com/scan.php?page=article&item=linux_32_nilfs2&num=1

Salu2.

----------

## gringo

 *opotonil wrote:*   

> Por si os puede interesar:
> 
> http://www.phoronix.com/scan.php?page=article&item=linux_32_nilfs2&num=1
> 
> Salu2.

 

interesante, gracias.

Me alegra ver que ext4 está arriba en casi todas las pruebas  :Smile: 

saluetes

----------

## gringo

perdón si esto no tiene nada que ver con el tema del hilo : se ha detectado un problema en kernels >2.6.38.x que provoca una degradación seria en el rendimiento de las ssd. Por lo que entiendo en el hilo no está claro aún cuál es el problema y tampoco parece que afecte por igual a todos los ssd.

Para el que quiera leer mas ( en inglés) : https://lkml.org/lkml/2012/1/27/40

saluetes

----------

