Hola :) On Friday 24 July 2009 13:44:13 Camaleón wrote:
El 2009-07-24 a las 13:10 +0200, Carlos E. R. escribió:
El 2009-07-24 a las 11:57 +0200, Camaleón escribió:
No inicia, pero te borra los datos del disco nuevo (reinicializa el disco), igual que lo hace el RAID por sw. Es como si lo formatease.
No borra nada. No puede borrar lo que no sabe que existe :-)
Explico: el fallo no se produce "en caliente" (con el sistema iniciado y en marcha), sino al encender el equipo. Y si lo enciendes y se activa el bug, la bios no reconoce al disco, no sabe que hay "algo" pinchado. El efecto es el mismo que si no hubiera conectado ningún dispositivo, luego no hay borrado de datos porque no hay raid, no hay discos. No hay nada que borrar ni duplicar a "cero".
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:) 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.
Hay gente que no ha perdido datos nunca y otros que, usen lo que suen, pierden datos (Carlos Robinson es un buen ejemplo: ha tenido problemas con todos los sistemas de ficheros, IIRC).
Je, je... sabía que "atacarías" ;-)
Sí, lo recuerdo de un hilo más antiguo dodne comentabas eso mismo, que la culpa es del los "hardwares" (discos y controladoras "mentirosillas" que cuando dicen "sí, he copiado al disco" en realidad es "no, no hay datos, están en la caché") y que los sistemas de archivos poco pueden hacer.
Vale X-)
Pero desde el punto de vista del usuario casero, que no usa raid, no usa sais, no hace backups tan a menudo como debería... y que un apagón le deje tieso, pues no cuela.
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.
Ni con el Fat32 he perdido nunca ni un sólo archivo (tanto en entornos caseros como en empresa), luego espero "algo más" de sistemas de archivos de alto rendimiento como puedan ser XFS, ReiserFS, o ZFS, la verdad, y sin necesidad de comprar hierros a precios desorbitantes para evitar que una corrupción del sistema de archivos me deje los datos a "0" ;-)
Yo si he perdido en FAT. Como bien dice Rafa, con todos he tenido desastres. El otro día perdí unos cuantos en un llavero USB, que es FAT. Todo con copia en el disco duro, así que nada importante.
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.
El sistema FAT tiene un problema inherente distinto a los problemas inherentes de ext3/4. En ext3, la lista de bloques que componen un fichero se guarda en un pseudo fichero distinto para cada fichero, y que se llama "inodo". Al grabar un inodo e irse la luz o desenchufar el llavero, se fastidia ese inodo, y ese fichero, pero no más. En FAT, es una tabla única para todos los ficheros. Si hay un fallo en el momento de grabar la FAT (o las FAT), se corrompen todos los ficheros.
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. Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org -- 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