Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
data=writeback en ext4 ¿cómo?
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Spanish
View previous topic :: View next topic  
Author Message
Stolz
Moderator
Moderator


Joined: 19 Oct 2003
Posts: 2953
Location: Valencia, Spain

PostPosted: Wed Oct 26, 2011 10:56 pm    Post subject: data=writeback en ext4 ¿cómo? Reply with quote

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:

Code:
 * 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
Code:
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.
Back to top
View user's profile Send private message
gringo
Advocate
Advocate


Joined: 27 Apr 2003
Posts: 3726

PostPosted: Thu Oct 27, 2011 8:09 am    Post subject: Reply with quote

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 :

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


Code:
/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.

Code:
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
Back to top
View user's profile Send private message
deovex
n00b
n00b


Joined: 27 Jun 2007
Posts: 74
Location: Buenos Aires, Argentina.

PostPosted: Thu Oct 27, 2011 1:22 pm    Post subject: Reply with quote

Por curiosidad, ¿Por que quieres desactivar el journaling en la partición /?
Back to top
View user's profile Send private message
Stolz
Moderator
Moderator


Joined: 19 Oct 2003
Posts: 2953
Location: Valencia, Spain

PostPosted: Thu Oct 27, 2011 2:16 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Txema
l33t
l33t


Joined: 20 May 2008
Posts: 767
Location: Granada

PostPosted: Thu Oct 27, 2011 2:59 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
gringo
Advocate
Advocate


Joined: 27 Apr 2003
Posts: 3726

PostPosted: Thu Oct 27, 2011 3:06 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
gringo
Advocate
Advocate


Joined: 27 Apr 2003
Posts: 3726

PostPosted: Sat Oct 29, 2011 11:14 am    Post subject: Reply with quote

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)

Code:
/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

Code:
/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
Back to top
View user's profile Send private message
Stolz
Moderator
Moderator


Joined: 19 Oct 2003
Posts: 2953
Location: Valencia, Spain

PostPosted: Sat Oct 29, 2011 6:45 pm    Post subject: Reply with quote

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)


Un saludo.


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:
Code:
# 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:
Code:

# 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?
Back to top
View user's profile Send private message
gringo
Advocate
Advocate


Joined: 27 Apr 2003
Posts: 3726

PostPosted: Sun Oct 30, 2011 7:36 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
gringo
Advocate
Advocate


Joined: 27 Apr 2003
Posts: 3726

PostPosted: Tue Nov 08, 2011 9:17 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
opotonil
l33t
l33t


Joined: 17 Jun 2005
Posts: 788
Location: 127.0.0.1

PostPosted: Thu Dec 15, 2011 8:20 pm    Post subject: Reply with quote

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

Salu2.
Back to top
View user's profile Send private message
gringo
Advocate
Advocate


Joined: 27 Apr 2003
Posts: 3726

PostPosted: Fri Dec 16, 2011 2:10 pm    Post subject: Reply with quote

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 :-)

saluetes
Back to top
View user's profile Send private message
gringo
Advocate
Advocate


Joined: 27 Apr 2003
Posts: 3726

PostPosted: Thu Feb 02, 2012 10:48 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Spanish All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum