-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
El Martes, 10 de Marzo de 2009, Carlos E. R. escribió:
Son circunstancias concretas, sí, pero no tan especiales.
Reiser: En la 11.1 provocaba caída del kernel en cuanto el beagle empezaba a indexar, si además se daba alguna otra circunstancia que no está clara (es posible que un error del sistema de ficheros que sin embargo no detecta el reiserfsck, según vimos en el bugzilla). En principio está corregido con la reciente actualización del kernel.
* No tiene por que ser un problema del sistema de ficheros, reiser esta fuera del kernel y en cuanto a beagle ahora se por que no me ha pasado.
Bueno, este lo han corregido, se trata del Bug 448007. En un punto pensaron en un bug de fs/reiserfs/journal.c A algunos le salían entradas como esta en el log: ReiserFS: sda2: warning: Invalid hash for xattr (user.Beagle) associated with [101 45992 0x0 SD] El comentario 20 de Jef Mahonney dice: I think it's probably the fsync load with firefox combined with the xattr access. The oops you posted is a different bug, though. It's because of the locking in prepare_error_bug. uniqueness2type ends up calling reiserfs_warning from insidereiserfs_warning, which causes a deadlock. Thanks for the report. I'll fix that one now. En el comentario #37 puse una traza del cuelgue: BUG: spinlock recursion on CPU#0, beagled/9113 lock: f90fd090, .magic: dead4ead, .owner: beagled/9113, .owner_cpu: 0 Pid: 9113, comm: beagled Tainted: G 2.6.27.13-HEAD_20090131033552_9af61a57-debug #1 [<c0105280>] dump_trace+0x68/0x22c [<c0105c6f>] show_trace+0x1a/0x2e [<c034c428>] dump_stack+0x60/0x6a [<c0237781>] spin_bug+0x7d/0x88 [<c0237833>] _raw_spin_lock+0x35/0x11a [<c034e733>] _spin_lock+0xd/0xf [<f90d634a>] prepare_error_buf+0x21/0x39b [reiserfs] [<f90d674f>] __reiserfs_warning+0x1f/0x7e [reiserfs] [<f90d6825>] le_type+0x77/0x25b [reiserfs] [<f90d6a2c>] sprintf_le_key+0x23/0x199 [reiserfs] [<f90d636f>] prepare_error_buf+0x46/0x39b [reiserfs] [<f90d674f>] __reiserfs_warning+0x1f/0x7e [reiserfs] [<f90e6748>] reiserfs_xattr_get+0x20f/0x231 [reiserfs] [<f90e7155>] user_get+0x48/0x55 [reiserfs] [<f90e64c2>] reiserfs_getxattr+0x5e/0x76 [reiserfs] [<c01ad1a8>] vfs_getxattr+0x87/0x90 [<c01ad248>] getxattr+0x97/0xdb [<c01ad331>] sys_lgetxattr+0x3d/0x52 [<c01039cd>] sysenter_do_call+0x12/0x21 [<ffffe430>] 0xffffe430 En el #45: Feb 3 21:01:52 minas-morgul kernel: REISERFS warning (device hdd14): jdm-20002 reiserfs_xattr_get: Invalid hash for xattr (user.Beagle) associated with [1919251317 1634026030 0x656c67 UNKNOWN] A lo que Jeff contestó: Ok, that confirms that you were running into the problem in comment #18, that has since been fixed. I suggest you run a reiserfsck on that partition. [1919251317 1634026030 0x656c67 UNKNOWN] ... is very wrong. Pero el fsck no descubrió nada de nada.
Reiser: En disco externo vía USB se corrompe bajo la 11.0, necesitando un reiserfsck --rebuild-tree que tarda varias horas. No pasa con la 10.3, y _creo_ que tampoco con la 11.1 - en la cual presenta a cambio otro bug del que ignoro la trascendencia todavía (BUG: sleeping function called from invalid context at mm/slab.c:3080). Y me parece haber leído de otro hoy en la lista de seguridad :-?
* Me temo que es mas de lo mismo un problema del manejo del modulo por parte del kernel, las versiones de reiserfs basicamente son las mismas en las 3 distribuciones y el kernel (desarrollos) no se lleva bien con extraños, evms por ejemplo el desarrollador lo ha pasado a espacio de usuario y me temo que es la tonica general de futuro.
Este es el Bug 47138. Sé que el 10.3 no lo tiene, y sospecho que el 11.1 tampoco. Pero el 11.0 desde luego que lo tiene. Ahora mismo lo estoy usando en RO en 11.0 y RW en 11.1 No se donde está el fallo. Te puedo contar sintomas. Aparece esto en el log: Mar 6 00:19:04 nimrodel kernel: sd 1:0:0:0: [sda] Sense Key : No Sense [current] Mar 6 00:19:04 nimrodel kernel: Info fld=0x0 Mar 6 00:19:04 nimrodel kernel: sd 1:0:0:0: [sda] Add. Sense: No additional sense information a veces por cientos. Una de las veces, poco después apareció esto mientras leía un fichero (en ese momento el disco estaba montado RO): Mar 6 00:19:04 nimrodel kernel: REISERFS warning: reiserfs-5090 is_tree_node: node level 5613 does not match to the expected one 1 Mar 6 00:19:04 nimrodel kernel: REISERFS error (device dm-5): vs-5150 search_by_key: invalid format found in block 13374638. Fsck? varias docenas o cientos de veces, y la copia (de bck a pc) de un fichero falló. Desmonté el disco, lo volví a montar, y ya no dió error, se copió perfectamente. Tengo la sospecha que es algún tipo de error durante la lectura, y al corregirlo se escribe metainformación incorrecta. Hasta ahora no he perdido información al reconstruir (fsck), pero tarda horas. Puede afectar a las cuatro particiones del disco si he escrito en las cuatro (dos encriptadas, dos normales).
Reiser: Cuando grabas una imagen encriptada en DVD, el kernel trata de _escribir_ en el DVD al montarlo para leerlo. Esto ya ocurría hace tiempo, creo que desde la 10.2, pero entonces conseguía montarse, y con la 11.0 falla. No recuerdo si lo consigue en la 11.1
* En principio esto es un problema de automatismo en los montajes, que al detectar un sistema de ficheros generalmente ubicado en disco fisico intenta montarlo rw, pero no creo que tenga la culpa el sistema de ficheros.
Bueno, sólo ocurre cuando el sistema de ficheros es reiser, no con los demás. Se trata del Bug 409504 - en ese momento con 10.3, donde el problema era sólo cosmético, se podía montar. Más tarde, en 11.0 lo volví a reportar como Bug 441062, donde el disco ya no funciona, no se puede montar. Con XFS también trata de escribir, pero consigue montarse.
Estos tres bugs denotan que están fallando en la implementación del reiserfs en el kernel, y que no sabemos cuanto tiempo seguirán funcionando.
XFS: Si está encriptado (con las opciones que le pone el YaST, al menos), el sistema se bloquea al grabar ficheros grandes (imagino que al usar los extents). No ocurre si no está encriptado. Está en el bugzilla desde hace años.
* Problema seguramente de dm-crypt, cryptosetup o lo que use y no de xfs.
No del todo, porque sólo se presenta cuando el sistema de ficheros es XFS, no con los demás. Es algo que ocurre con la combinación de ambos, encriptación y xfs. Y por cierto, ocurre tanto con LUKS como con el sistema anterior. Se trata del Bug 34503, que reporté en noviembre del 2007 (10.3), xfs y twofish256. Puede que sea alguna funcionalidad que necesita XFS que no soporte el transporte encriptado que esté por debajo. ¿extents? Ocurre al grabar ficheros grandes (cientos de megas), no con los pequeños.
Dirás: ¿Y para que rayos necesitas grabar ext2 en un DVD? Pues porque no conozco una manera de generar imágenes ISO encriptadas con LUKS o equivalente. Además, al montar en bucle la imagen RW, permite más juego al preparar el backup sin necesidad de usar k3b ni similar.
* no uso medios extraibles en backups, soy mas amigo de cifrar ficheros que no sistemas de ficheros, un script te haria la labor, ahora si no quieres usar, gnupg, split, par2, growisofs ni nada por el estilo pues es el asunto esta limitado.
Se trata simplemente de evitar miradas inoportunas en mis backups si alguien me pilla el DVD: si fuera material sensible entonces usaría PGP. Precisamente proque el backup a DVD me estaba dando problemas lo estaba haciendo a disco duro externo via USB, a reiser encriptado: y entonces me topé con el bug de más arriba. Par2 lo uso, por cierto. Pero encuentro más sencillo montar una imagen de DVD (residente en un fichero de 4.4 gigas en disco duro), donde puedo copiar ficheros mediante konqueror, nautilus, midnight comander, bash... si no, la alternativa es crear la imagen cada vez mediante growisofs o k3b, lo cual es mas lento al necesitar estimar el tamaño de la imagen cada vez. No es imprescindible quemar los discos como isos, me resulta más cómodo como cualquier otro sistema de ficheros tradicional.
Por ese motivo antes hacía esas copias de seguridad encriptadas como XFS, hasta que tuve que dejarlo porque colgaban el sistema. Entonces empecé a hacerlos con reiserfs, hasta que este también falló al montarlos para recuperar porque el kernel trata de escribirlos.
¿Que queda? Pues sí, ahora hago las copias de seguridad en DVD encriptados en /FAT/. Hay que joderse :-/
* Francamente mis opciones de backup no pasan por sistemas de ficheros pensados y con caracteristicas para otros mediosde meterlos en DVD y en mi opinion esta es una formula excepcional y no habitual.
* Mira a ver si encfs o loop-aes puede ser mas apropiado para aterrizar en un DVD al no escribir directamente, no vaya a ser un problema de luks, tambien hay otras herramientas, http://sd4l.sourceforge.net , en cualquier caso luks precisa manejo y configuracion y scripts para asuntos desatendidos, no pinta como mas facil la ausencia de un script de backup que cree el proceso de backup, compresion, cifrado, paridad y grabe en UDF, por ejemplo.
No digo que no. Echaré un vistazo a esos que dices. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkm2waYACgkQtTMYHG2NR9WHLgCglmE3NC3TO9T/b5lj2gITY9So rY4An0d7fBwSvrPg8qo70M/VcNJnXCPg =QoQ0 -----END PGP SIGNATURE-----