Mailinglist Archive: opensuse-es (1064 mails)

< Previous Next >
Re: [opensuse-es] PowerVault NF500, alguna solucion Linux.
  • From: "Carlos E. R." <robin.listas@xxxxxxxxxxxxxx>
  • Date: Fri, 24 Jul 2009 13:10:05 +0200 (CEST)
  • Message-id: <alpine.LSU.2.00.0907241258040.9407@xxxxxxxxxxxxxxxx>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



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.



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.


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 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.

- -- Saludos
Carlos E. R.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkpplo8ACgkQtTMYHG2NR9WDUwCgg1fA0I1Xm+fT2DCkmlclAvmk
GyoAnAgeODcpJ8zzIKXE1MUj36TXcfbE
=tW3T
-----END PGP SIGNATURE-----
< Previous Next >
Follow Ups