Hola :) On Saturday 25 July 2009 14:05:45 Carlos E. R. wrote:
El 2009-07-24 a las 18:14 +0200, Rafa Griman escribió:
Je, je... sabía que "atacarías" ;-)
Hubiera "atacado" aunque no hubieras nombrado XFS ;)
Cierto O:-)
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.
Bueno, es un problema porque ambos bandos desarrollan sin tener en cuenta al otro.
Podrías tener un sistema de ficheros fiable compuesto de dos discos: uno "normal", y otro de "journal" o histórico en modo "sync". Cuando se puede, se actualiza el principal con los cambios del log (que podría ser ssd).
Con ext3/4 y XFS puedes tener el journal separado en otro disco. Nosotros solemos recomendarlo pero el cliente lo entiende como: "Dos discos en RAID 1 para el journal = venga, déjate timar y compras estos dos discos aunque no haga falta". No es que hagan falta, pero pueden (depende del caso) quitarle carga al almacenamiento ya que el journal hace muchas escrituras pequeñas (metadatos). Esto interfiere a la hora de acceder a los datos y leerlos o escribirlos.
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;)
Pero es la solución que proponen los del bando del kernel con el problema que vieron las aplicaciones con lo del ext4. No, todavía no he visto el video, se está descargando.
IIRC, lo que proponían eran varias cosas: trabajar con ficheros temporales, hacer sync, ... No sé en qué habrá quedado la cosa.
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".
Los discos podrían tener cabezas independientes en cada plato, incluso varias cabezas por plato. ¿Te lo imaginas?
Es verdad, lo has comentado un par de veces en la lista. Pues estaría bien. También podríamos los usuarios no guardar tanta m^H basura de forma que los discos no tengan que ser tan grandes, las empresas podrían invertir más en código/programas mejor depurados para no ocupar esas ingentes cantidades de disco, ... 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