El 2009-07-24 a las 18:33 +0200, Rafa Grimán escribió:
On Friday 24 July 2009 13:44:13 Camaleón wrote:
El 2009-07-24 a las 13:10 +0200, Carlos E. R. escribió:
No es eso.
El sistema no arranca, correcto. Detectas el fallo de un disco (si no son todos los del array, que serán igualitos), por lo que reemplazas ese disco, pones otro, y vuelves a arrancar... mientras, envías a reparar el antiguo. Pero el sistema mientras tanto repone lo datos "perdidos" en el nuevo disco. Cuando vuelva el disco original, el sistema lo borrará y reescribirá.
Rafa se refiere a eso.
Únicamente no pasaría si mandases a reparar el disco sin volver a arrancar el sistema hasta que el disco volviese un mes o dos más tarde.
Creo que no. A ver, a ver. Por partes...
En un raid 0 No podría iniciar si uno de los dos discos no está disponible porque no hay redundancia de datos. No hay pérdida de datos, sólo de tiempo :-)
En un raid 1 Matriz con discos igualitos. No inicia, no se detectan los discos debido al bug. No hay pérdida de datos, sólo de tiempo :-)
Si tienes una matriz con discos distintos (a uno le afecta el bug y al otro no) el sistema inicia y te salta la bios de la controladora indicando que un miembro se ha caído (el del bug). En este punto, los dos discos duros contienen datos (el del bug y el bueno). Cambia el disco del bug y pone otro nuevo. Los datos del disco bueno se usan para la reconstrucción de la matriz, no hay pérdida de datos, sólo pérdida de tiempo :-)
En un raid5 Lo mismo que en el raid1 pero si se caen 2 miembros tampoco podría iniciar el sistema, tendría que esperar a que los dos discos afectados por el bug vengan del SAT. Idem anterior.
Para el resto de supuestos de raid ya lo pensáis vosotros >:-)
Yo os digo lo que decían en Seagate, que *en ningún caso* había pérdida de datos debido al bug del firmware (salvo que en un ataque de locura te dé por lanzar el disco afectado por la ventana y entonces sí podría haber que recurrir a técnicas forenses de recuperación) :-P.
Cierto, te doy la razón. Ya lo he pillado. No sé por qué no leo los hilos enteros antes de contestar ... 0:)
¡Ah, por fin! Ya me veía todo lo que queda del viernes intentando explicar el bug del Seagate :-)
A lo que me refería es que si metes el disco, el RAID lo inicializa y es cuando se carga los datos que hay en ese disco, aunque luego los "reastaura" a partir de la paridad y los otros datos.
Eso es. Pero nada que ver con que el bug te "borre" los datos "sin más".
Bueno... la cosa es más compleja de lo que parece. Está implicado el desarrollo del kernel y la discusión sobre si usar sync es bueno o malo y si hace falta otra cosa que la gente del kernel no quiere poner.
Ya, pero esos temas para los usuarios son como "cánticos gregorianos", vamos, que les gusta oírlos de vez en cuando pero no tenerlos 24 horas en su casa canturreando. Espero que se entienda la metáfora :-)
Que sí, que vale, que el sai es necesario y el "sync" ralentiza el proceso de escritura, etc... pero que ellos lo que dicen que un apagón les ha "borrao er dijco".
Pero ... tu no eres "un usuario" ;) Ya, estás haciendo de "traductor" de los usuarios.
O:-) pero no por eso podemos ignorar el problema. No lo digo yo, en el pdf que he enviado antes sobre la gestión de errores en los sistemas de archivos (hablaba de XFS), concluían con lo siguiente: *** 6 Conclusions Modern day file system designers have paid little attention to localized disk failures. More generally commodity operating systems assume the presence of reliable hardware. As disks increasingly fail in a non fail stop manner, we believe there is a need for a more uniform failure handling policy. File systems should be paranoid and should not trust the layers below. One solution that has been recently proposed is to maintain internal redundancy for important structure and checksum over the data. This way the file system will be able to detect and recover from most errors. Internal redundancy for critical struc- tures like the root inode, inode B+trees is needed to prevent sector faults from rendering the entire file system inaccessible. So does the solution lie in an IRON XFS? If so, what should be the level of redun- dancy? What low-overhead detection and recovery mechanisms can these systems employ? Many of these need to be answered, as we try and build more resilient and robust file systems. *** Lo cual suscribo :-P.
El llavero USB no cuenta como "disco duro" :-P
Como te oigan los fabricantes de SSDs ... Básicamente un SSD es lo mismo que un "pincho" USB, pero al que le han quitado la interfaz USB y le han puesto una interfaz SATA o SAS.
Anda ya... :-) ¿Tú crees que el proceso de fabricación, los materiales utilizados y la calidad en general de una llave usb _es la misma_ que la de los discos SSD? Enga ya. Que una vale 10 EUR y la otra 500 EUR >>:-)
Ni un dato perdido en todo este tiempo con fat32, ntfs, ext3 o reiserfs. De momento >:-)
Yo sólo he perdido datos con reiserfs 3 y JFS. El FAT es que lo he usado muy poco y el NTFS menos aún.
Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org