Mailinglist Archive: opensuse-es (1064 mails)

[Camaleón <noelamac@xxxxxxxxx>]

El 2009-07-24 a las 18:14 +0200, Rafa Grimán escribió:

> On Friday 24 July 2009 11:57:47 Camaleón wrote:

> > 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".
>
>
> Vamos a imaginar que tienes montado un RAID (da igual que sea por hw o por 
> sw, 
> el comportamiento es el mismo). Lo que ocurre:
>       1.- arrancas el equipo y uno de los discos ha desaparecido

O.K.

>       2.- el RAID se pone a pitar y te dice que un disco ha casacado (el
>           RAID no sabe si ha cascado o lo has sacado o tiene un bug y es
>           que la BIOS no lo detecta, lo único que sabe es que algo falla
>           y lo avisa)

O.K.

>       3.- sacas el disco

O.K.

>       4.- vamos a suponer que es un RAID con protección de datos (RAID 1,
>           5, 6, 10, 50). Si es un RAID 0 ... bye, bye, datos

No hay bye, bye... si es un raid0 (ya lo he comentado antes) NO inicias
el equipo y punto final. Pero no iniciar no significa que los datos se 
pierdan, se eliminen o se borren.

El bug del firmware _no_ es destructivo. Sólo "oculta" el disco al 
sistema o controladora de turno. Repito, no elimina datos.

>       5.- el sistema de almacenamiento sigue funcionando en modo degradado

Bueno, eso dependerá del tipo de administrador que seas. Debes tener un 
siempre disco de repuesto si tienes un raid :-). Pero vale, te sigo.

>       6.- actualizas el firmware del disco

O.K.

>       7.- insertas el disco de nuevo en el RAID (el mismo disco al que
>           has actualizado el firmware)

Ah, oye, eso no se puede hacer. Lo pone en las instrucciones de 
Seagate. Es decir, que si eres consciente de que el disco tiene un bug, 
y lo quieres actualizar también eres consciente (o debes serlo) de cuál 
es el procedimiento correcto e indicado por el fabricante para actualizar 
el firmware.

En este caso, Seagate recomienda que hagas una copia de seguridad de 
los datos ANTES de actualizar el firmware del disco si lo tienes en 
Raid. 

El proceso concreto para actualizar el firmware SIN perder datos, aquí:

http://seagate.custkb.com/seagate/crm/selfservice/search.jsp?DocId=207963

>       8.- el RAID detecta que has introducido un disco y lo inicializa
>           (~ "formatear"). Al inicializar el disco ... borra todo lo que
>           hay en él -> pierdes los datos que hay en él

>       9.- con la info de la paridad y los datos escritos en los otros discos,
>           se compone la info y se escribe en el "nuevo" disco

Puntos 8 y 9 invalidados, Rafa. Revisa en enlace anterior.

El bug no destruye datos. Obviamente, si omites las indicaciones del 
fabricante y vas por tu cuenta y además, tienes una configuración "X" 
(raid con controladora susceptible de reiniciar el array y formatear), 
pues entonces está claro que te quedas sin datos, pero no por culpa del 
bug sino por no saber administrar un sistema. Eso es otro tema.

> En este caso, la pérdida de datos del disco dañado es irrelevante porque 
> tenemos un RAID con protección de datos que re-escribe los datos al disco.
>
> El problema que tenemos aquí es que falle más de un disco por el mismo bug, 
> es 
> decir, que arrancas y el RAID 5 no encuentra 2 de los discos ... adios datos. 
> No se puede reconstruir el RAID ni recuperar los datos.
>
> El "formateo"/inicialización de los RAID lo que hace es escribir la info del 
> RAID como por ejemplo el stripe unit (sería algo equivalente al "tamaño de 
> bloque" en un disco que no es un RAID).

Ya te digo, eso NO es problema del bug. Es problema del usuario que 
maneja el raid y no sabe o desconoce los pasos correctos a seguir para 
actualizar el firmware del disco duro.

El supuesto que tú indicas es válido igualmente para cualquier 
actualización de cualquier firmware de cualquier disco duro de 
cualquier fabricante ;-)

Si el bug del firmware fuera destructivo, Seagate no habría 
tenido más remedio que reconocerlo, pero no es el caso.

> > > Como siempre, no es por ser alarmista ni meter miedo en el cuerpo a la
> > > gente. 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" ;-)
>
>
> Hubiera "atacado" aunque no hubieras nombrado XFS ;)

Fale :-)

> > 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.
>
>
> ¿Qué es lo que no cuela?

Pues que los sistemas de archivos deben ser "a prueba de bombas". Sin 
excusas, sin pedir que el usuario tenga "x" hardware o que tenga "x" 
configuración. Deben poner más empeño en la fiabilidad de los datos.

> > 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" ;-)
>
>
> No tiene nada que ver con precios desorbitantes ni hw específico. Tiene que 
> ver que la velocidad (o ancho de banda e IOPS) de los discos ya que no han 
> evolucionado a la misma velocidad que el resto de los componentes (CPU, RAM, 
> Buses). Como el disco duro sigue siendo un trasto antiguo que "va a pedales", 
> los desarrolladores de sistemas de ficheros han tenido que ingeniárselas para 
> poder solventar un problema hardware. por lo que han echado mano de la RAM y 
> ha aparecido un problema nuevo: la volatilidad de los datos.
>
> Si los fabricantes de discos duros hubieran sacado los SSD hace muchos años, 
> posiblemente esto no hubiese ocurrido o no sería tan grave. Ahora que han 
> aparecido los SSD, aparece un nuevo problema: las celdas se estropean "muy 
> rápido". Lo de "muy rápido" lo pongo porque son muy sensibles al número de 
> escrituras que realices. Si es un sistema de ficheros read-only, los SSD te 
> duran una eternidad, pero si es read-write ... ya puedes ir comprando los SSD 
> por kilos.

El tema del número de "escrituras limitadas" en los SSD ha cambiado un 
poco. No sé en qué estado concreto se encuentran ahora pero los discos 
SSD de Intel tienen también un MTBF como los de los discos magnéticos, 
de horas.
 
> En cuanto a FAT, IIRC, es de tipo sync. Es decir, en el momento que guardas a 
> disco, se guarda el dato. Eso estaba muy bien en la época del MS-DOS porque 
> los discos estaban a la par en cuanto a velocidad al resto de los 
> componentes. 
> Si hoy en día montas un sistema de ficheros con sync ... la cantidad de 
> gritos 
> que oyes de los usuarios es innumerable. Recuerda la que se lió hace unos 
> años 
> porque SUSE montaba los USB con sync y el copiar algo a un USB era eterno. 
> Pues ahora imagínate si se lo aplicas a un sistema que lleva un motor (aka 
> disco duro;)
>
> El almacenamiento es el gran cuello de botella y la gran lacra que tiene la 
> informática hoy en día. Por poner un ejemplo, es como si los coches aún 
> llevasen ruedas de madera de esas de las que llevan los carruajes del 
> "Salvaje 
> Oeste".

Saludos,

-- 
Camaleón 
-- 
Para dar de baja la suscripción, mande un mensaje a:
   opensuse-es+unsubscribe@xxxxxxxxxxxx
Para obtener el resto de direcciones-comando, mande
un mensaje a:
   opensuse-es+help@xxxxxxxxxxxx