View previous topic :: View next topic |
Author |
Message |
Stolz Moderator
Joined: 19 Oct 2003 Posts: 3028 Location: Hong Kong
|
Posted: Wed Oct 26, 2011 10:56 pm Post subject: data=writeback en ext4 ¿cómo? |
|
|
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 |
|
|
gringo Advocate
Joined: 27 Apr 2003 Posts: 3793
|
Posted: Thu Oct 27, 2011 8:09 am Post subject: |
|
|
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 |
|
|
deovex n00b
Joined: 27 Jun 2007 Posts: 74 Location: Buenos Aires, Argentina.
|
Posted: Thu Oct 27, 2011 1:22 pm Post subject: |
|
|
Por curiosidad, ¿Por que quieres desactivar el journaling en la partición /? |
|
Back to top |
|
|
Stolz Moderator
Joined: 19 Oct 2003 Posts: 3028 Location: Hong Kong
|
Posted: Thu Oct 27, 2011 2:16 pm Post subject: |
|
|
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 |
|
|
Txema l33t
Joined: 20 May 2008 Posts: 772 Location: Granada
|
|
Back to top |
|
|
gringo Advocate
Joined: 27 Apr 2003 Posts: 3793
|
Posted: Thu Oct 27, 2011 3:06 pm Post subject: |
|
|
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 |
|
|
gringo Advocate
Joined: 27 Apr 2003 Posts: 3793
|
Posted: Sat Oct 29, 2011 11:14 am Post subject: |
|
|
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 |
|
|
Stolz Moderator
Joined: 19 Oct 2003 Posts: 3028 Location: Hong Kong
|
Posted: Sat Oct 29, 2011 6:45 pm Post subject: |
|
|
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:
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 |
|
|
gringo Advocate
Joined: 27 Apr 2003 Posts: 3793
|
Posted: Sun Oct 30, 2011 7:36 am Post subject: |
|
|
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 |
|
|
gringo Advocate
Joined: 27 Apr 2003 Posts: 3793
|
Posted: Tue Nov 08, 2011 9:17 pm Post subject: |
|
|
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 |
|
|
opotonil l33t
Joined: 17 Jun 2005 Posts: 801 Location: 127.0.0.1
|
|
Back to top |
|
|
gringo Advocate
Joined: 27 Apr 2003 Posts: 3793
|
Posted: Fri Dec 16, 2011 2:10 pm Post subject: |
|
|
interesante, gracias.
Me alegra ver que ext4 está arriba en casi todas las pruebas
saluetes |
|
Back to top |
|
|
gringo Advocate
Joined: 27 Apr 2003 Posts: 3793
|
Posted: Thu Feb 02, 2012 10:48 am Post subject: |
|
|
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 |
|
|
|