Hola :) El Friday 13 March 2009, admin-listas escribió:

Rafa Grimán escribió:

...

Hola :)

El Friday 13 March 2009, admin-listas escribió:

...

en opensuse 11.1 con kde 3.5 Ha desaparecido la configuracion de las cuentas, ¿alguien sabe en que fichero se guarda eso?

.kde/share/config/kmailrc

Aunque tambien tienes estos otros:

.kde/share/config/kmailcvtrc

.kde/share/config/kmail.eventsrc

.kde/share/config/kmailsnippetrc

Y tienes este otro directorio:

.kde/share/apps/kmail/

Por cierto, ¿qué sistema de ficheros estás usando?

Rafa

En esos sitios no queda rastro de la configuracion de los servidores, es lo que se borro. XFS, y si, se fue la corriente y to a cascala. Tambien perdi el tamaño de los iconos del escritorio, pero el resto (colores, fondo,sonidos.....) sigue igual.

Esto es lo que está ocurriendo con ext4 también. No tienes ningún tipo de protección frente a caídas de luz, ¿verdad? Por ejemplo: SAI. En la lista de OT (y en muchas otras) se está comentando mucho esto. En las de XFS también ha salido el tema. XFS lleva desde el 95 (creo) y tenemos soluciones a esto en nuestros servidores (a nivel hardware) y algunas de las mejoras que va a introducir en ext4 ya las tenemos nosotros en XFS. Te recomiendo leer el hilo que hay sobre este tema en la lista OT. Básicamente hay que tener en cuenta: - los sistemas de ficheros "modernos" hacen un sync a disco tarde (delayed allocation). Es decir, guardan en buffers y cachés datos y no escriben a disco inmediatamente - esto lo hacen porque el disco duro es MUUUUUUUUUUUUYYYYYY lento - el hardware suele ser de mala calidad, es decir, sobre todo memorias que fallan (típico de componentes de PC y no de servidor o de estación de trabajo), fuentes de alimentación poco fiables, no utilizar SAI, cachés de discos duros que no son fiables, ... - cachés del disco duro que fallan, aka discos duros no enterprise ¿Por qué no ocurre con otros sistemas de ficheros? Respuestas: 1.- sí ocurre 2.- otros sistemas de ficheros te hacen un sync a disco cada pocos segundos con lo que: a) está mintiendo, porque la caché del disco no ha hecho sync, pero el disco le ha dicho que sí por lo que el sistema de ficheros se lo ha creído b) el rendimiento de tu almacenamiento es lento Opciones: 1.- desarrolladores de sistemas de ficheros: usar delayed allocation para hacer frente a la lentitud de los discos duros (sí, los SSD TAMBIÉN son lentos y son AÚN MENOS fiables que los de toda la vida) 2.- usar hw bueno 3.- usar SAI bueno 4.- hacer backups 5.- hacer más backups 6.- volver a hacer backups 7.- jugar a la lotería, ganar y vivir una vida contemplativa ;) 8.- hacer backups 9.- casi se me olvida: haced backups de vuestros datos Un consejo de colegas, si queréis "garantizar" que el dato se ha escrito a disco, teclead el comando: sync Tecleado unas 100 veces. Da igual el sistema de ficheros que uséis, el probelma con el que os vais a encontrar es la caché del propio disco duro y su firmware. Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- 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

Hola :) El Friday 13 March 2009, admin-listas escribió:

Rafa Grimán escribió:

...

Tecleado unas 100 veces. Da igual el sistema de ficheros que uséis, el probelma con el que os vais a encontrar es la caché del propio disco duro y su firmware.

Rafa

Antes que nada, en mi lista he metido humor ;)

si, pero no da tiempo cuando se va la luz.

Ya, para el sync no te vale. Como comentaba, en nuestros servidores añadimos (no sé el término en castellano) power-fail interrupts y capacitadores más grandes. No es un SAI, pero alivia algo y permite que el sistema operativo reaccione. Algo es algo ;) A nivel de sw (XFS) también hemos introducido mejoras que intentan evitar o aliviar este tipo de cosas. Hablando de si se va la luz. Ocurre, por ejemplo, en las cabinas de discos que tienes una caché por controladora protegida por una batería (~ mini-SAI). Pero, ¿qué ocurre si hay un fallo eléctrico interno y uno de los discos pierde durante un breve período de tiempo alimentación? Pues que los datos que había en la caché del disco ese ... se han esfumado !!! La caché de la controladora de la cabina está bien protegida por la batería, pero la del disco no. Nopes, el RAID no protege ante esto. Tened en cuenta los pasos: 1.- la controladora le dice al RAID: te paso estos datos que tengo en caché 2.- el RAID dice: OK, ya se lo he pasado a los discos 3.- el disco dice: OK, ya lo he escrito 4.- el RAID le dice a la controladora: el disco ya lo ha escrito 5.- la controladora dice: OK, marco ese dato como "stale" en mi caché Si os fijáis, en el paso 3, el disco dice que lo ha escrito, pero está en la caché, no en el disco físico (platter). Si ese disco no llega a escribir de su caché al platter (fallo en la corriente), la paridad no sirve de nada porque no hay que reconstruir nada. Teóricamente el dato está en disco. Pero realmente no está por lo que el RAID no reconstruye nada y nunca lo hará. Sólo verás este error cuando vayas a recuperar el fichero y veas que está corrupto. El RAID sólo reconstruye cuando sabe que hay un fallo (cuando el disco le dice: no puedo escribir o el disco simplemente no contesta), pero en esta situación, para el RAID todo ha salido bien. Solución: desactivar las cachés propios de los discos, no de la controladora RAID. Problema nuevo: pierdes rendimiento. Ventaja: ganas en seguridad.

La Sai, pos no da pa mas el presupuesto.

Ya, hay veces que (la gran mayoría de ellas) que es un problema económico. En tu caso, no lo sé, pero en otros que sí sé, se gastan un dineral en SAI y alta disponibilidad ... y luego resulta que lo enchufan todo al mismo sitio y sólo tienen 1 proveedor de electricidad, están en una zona de mucha humedad, ... Por lo que está mal invertido el dinero. Otro ejemplo: tenemos un posible cliente que tiene todo distribuido. Dice que eso de consolidar es muy incómodo y que si se te cae el único almacenamiento/servidor que tienes ... se te va todo al carajo. Sí, es cierto, pero no es ni uno ni lo otro. Es decir, puedes consolidar y tener alta disponibilidad/redundancia y evitar lo que llaman los gringos: "server sprawl". Para que te hagas una idea, esta empresa monta servidores con 8 discos en los que cada disco es un sistema de ficheros: no hay protección de datos de ningún tipo. Cuando falla un disco (obviamente) el sistema se queda con un iowait eterno porque no puede montar el sistema de ficheros ... tiene que reiniciar el servidor entero. Luego, por culpa de perder un disco ... deja de servir 8 sistemas de ficheros: mal invertido el dinero. IMHO, no hay que ser demasiado radical en las cosas y ver que a lo mejor no hace falta invertir tanto en una cosa e invertir en otra.

Las copias , ni ganas (eso que me pierdo)

Todo eran recomendaciones. Cada uno es libre de proceder como crea más correcto/conveniente.

La curiosidad :que solo se ha perdido el tamaño de los iconos y la configuracion de las cuentas de correo, de las 4, pero el resto de configuraciones del kontac esta bien, asi como las carpetas.

Puede ser porque determinados ficheros sí se han escrito o porque a lo mejor KDE no manda guardar determinados ficheros hasta que se cierra la sesión y otros sí. Esto ya es cosa propia de la aplicación y de cómo y cuándo guarda los ficheros.

En fin las volveremos a meter y que no pase otra vez.

Suerte :) Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- 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

Hola :) El Friday 13 March 2009, Carlos E. R. escribió:

El 2009-03-13 a las 11:57 +0100, Rafa Grimán escribió:

...

...

Hablando de si se va la luz. Ocurre, por ejemplo, en las cabinas de discos que tienes una caché por controladora protegida por una batería (~ mini-SAI). Pero, ¿qué ocurre si hay un fallo eléctrico interno y uno de los discos pierde durante un breve período de tiempo alimentación? Pues que los datos que había en la caché del disco ese ... se han esfumado !!! La caché de la controladora de la cabina está bien protegida por la batería, pero la del disco no.

Nopes, el RAID no protege ante esto. Tened en cuenta los pasos:

1.- la controladora le dice al RAID: te paso estos datos que tengo en caché

2.- el RAID dice: OK, ya se lo he pasado a los discos

3.- el disco dice: OK, ya lo he escrito

4.- el RAID le dice a la controladora: el disco ya lo ha escrito

5.- la controladora dice: OK, marco ese dato como "stale" en mi caché

Si os fijáis, en el paso 3, el disco dice que lo ha escrito, pero está en la caché, no en el disco físico (platter). Si ese disco no llega a escribir de su caché al platter (fallo en la corriente), la paridad no sirve de nada porque no hay que reconstruir nada. Teóricamente el dato está en disco. Pero realmente no está por lo que el RAID no reconstruye nada y nunca lo hará. Sólo verás este error cuando vayas a recuperar el fichero y veas que está corrupto.

Me parece que aquí el raid por software tiene ventaja, porque manda los datos por separado a cada disco. >:-)

Sí, pero los datos que se envíen a un disco que falle ... no se pueden recuperar. Ten en cuenta que el disco ha dicho: "Ya lo tengo, ya lo he guardado", pero no es cierto. Dicho "OK" se envía cuando llega a la caché del disco, no cuando el firmware del disco hace un flush de la caché al platter. Luego el sw de RAID "pensará" que el dato es correcto y se ha guardado correctamente. Sólo te das cuenta de que el dato no se ha guardado correctamente al recuperarlo.

Es decir, el disco fallado tendrá unos datos, pero el resto tendrán otros.

Luego el fichero está corrupto :(

...

El RAID sólo reconstruye cuando sabe que hay un fallo (cuando el disco le dice: no puedo escribir o el disco simplemente no contesta), pero en esta situación, para el RAID todo ha salido bien.

Solución: desactivar las cachés propios de los discos, no de la controladora RAID. Problema nuevo: pierdes rendimiento. Ventaja: ganas en seguridad.

- Cachés con pila.

Discos más grandes y más caros ;) Pero es una solución.

- Añadir comando PATA/SATA para volcado de cache de disco de emergencia. El sistema operativo sabe que se va la corriente, o que va a apagar el sistema. Es el momento de ordenarle volcar la caché.

Existen esos comandos y/o funciones: sync, fsync(), O_SYNC, ... Que hacen un flush de la RAM del servidor/PC/estación al disco (realmente se envía a la cahcé del disco). Pero cuando llegas al disco ... te encuentras con el firmware del disco. Los fabricantes de discos tendrían que implementar un comando a nivel de firmware que se pueda llamar desde cualquier sistema operativo (aka estándar ... BIEN!!!, Otro "estándar" ;) Es una idea interesante.

- Añadir comando para volcado rutinario de cache de disco, que sería usado por el kernel como parte de un "sync".

Hay una cosa que se llama "barriers" que facilita algo la tarea. Al activar los barriers. El sistema d eficheros lo qu ehace es decirle al disco: "No puedes mezclar los datos entre este barrier y este otro" Es decir, facilita de alguna manera una escritura ordenado de los datos. ütil, por ejemplo para bases de datos y vídeo o audio en los qu eel orden de escritura de los datos es importante.

...

...

La Sai, pos no da pa mas el presupuesto.

Ya, hay veces que (la gran mayoría de ellas) que es un problema económico. En tu caso, no lo sé, pero en otros que sí sé, se gastan un dineral en SAI y alta disponibilidad ... y luego resulta que lo enchufan todo al mismo sitio y sólo tienen 1 proveedor de electricidad, están en una zona de mucha humedad, ... Por lo que está mal invertido el dinero.

Eso también. Pero una SAI te puede salvar la "vida": no se trata de mantener el centro funcionando, sino de poder cerrar (o mejor hibernar) el sistema adecuadamente.

"Sacto". Un SAI, "pequeñajo" que dé el tiempo justo para guardar los datos y apagar. Lo siento Carlos, a mi eso de hibernar ... me pilla ya mayor ;)

...

...

La curiosidad :que solo se ha perdido el tamaño de los iconos y la configuracion de las cuentas de correo, de las 4, pero el resto de configuraciones del kontac esta bien, asi como las carpetas.

Puede ser porque determinados ficheros sí se han escrito o porque a lo mejor KDE no manda guardar determinados ficheros hasta que se cierra la sesión y otros sí. Esto ya es cosa propia de la aplicación y de cómo y cuándo guarda los ficheros.

Si, yo creo que es más fallo de la aplicación que del sistema de ficheros. Es probable que tuviera las cosas en memoria, no en disco, o en fichero temporal.

...

...

En fin las volveremos a meter y que no pase otra vez.

Al menos hay que hacer backup de las configuraciones y datos. Es mucho menos que copiar todo.

Hay backups baratos (sw libre) y el almacenamiento cada día está más barato. Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- 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

Hola :) El Monday 16 March 2009, Carlos E. R. escribió:

El 2009-03-16 a las 08:33 +0100, Rafa Grimán escribió:

...

Hola :)

El Friday 13 March 2009, Carlos E. R. escribió:

...

El 2009-03-13 a las 11:57 +0100, Rafa Grimán escribió:

...

...

5.- la controladora dice: OK, marco ese dato como "stale" en mi caché

Si os fijáis, en el paso 3, el disco dice que lo ha escrito, pero está en la caché, no en el disco físico (platter). Si ese disco no llega a escribir de su caché al platter (fallo en la corriente), la paridad no sirve de nada porque no hay que reconstruir nada. Teóricamente el dato está en disco. Pero realmente no está por lo que el RAID no reconstruye nada y nunca lo hará. Sólo verás este error cuando vayas a recuperar el fichero y veas que está corrupto.

Me parece que aquí el raid por software tiene ventaja, porque manda los datos por separado a cada disco. >:-)

Sí, pero los datos que se envíen a un disco que falle ... no se pueden recuperar. Ten en cuenta que el disco ha dicho: "Ya lo tengo, ya lo he guardado", pero no es cierto. Dicho "OK" se envía cuando llega a la caché del disco, no cuando el firmware del disco hace un flush de la caché al platter. Luego el sw de RAID "pensará" que el dato es correcto y se ha guardado correctamente. Sólo te das cuenta de que el dato no se ha guardado correctamente al recuperarlo.

Pero la paridad no coincide.

Sí coincide. La paridad se ha calculado cuando el disco ha dicho: "OK, ya lo tengo", aunque no lo haya escrito al platter.

Posiblemente ese disco falle en bastantes más grabaciones, el software se dará cuenta, y lo retirará, reconstruyendo todo a partir de los otros.

Pero es que el disco no ha dado fallo de grabación. Todo lo contrario. Dice que sí lo tiene (lo tiene en la caché), pero justo antes de escribirlo al platter ... pierde un poco de electricidad y la caché se borra. El disco no está defectuoso. Puede que lo defectuoso se la fuente de alimentación y no le envía potencia suficiente al disco. En el momento que le llegue corriente, sigue como nuevo el disco ... pero sin los datos de la caché :( Estás pensando que el disco está defectuoso, pero no lo está. no es culpa del disco el que no le haya llegado corriente. Es más, no tiene ni que perder toda la corriente, basta que pierda la caché temporalmente la corriente para que se borre. Ya, son casos "raros" o especiales. Pero se dan más habitualmente de lo que pensamos, tanto en empresa como en casa. Fíjate en el caso que ha iniciado este hilo: el disco no ha fallado, no está mal el disco. Ha sido un fallo eléctrico. Si eso mismo le pasa en un RAID, el RAID no hubiera detectado error de paridad ya que el disco ha dicho: "Ya lo tengo".

...

...

Es decir, el disco fallado tendrá unos datos, pero el resto tendrán otros.

Luego el fichero está corrupto :(

Depende de si ese disco es reconocido como fallado o no.

Recuerda que el disco está perfectamente, lo que le ha ocurrido es que se ha quedado momentáneamente sin electricidad.

...

...

...

El RAID sólo reconstruye cuando sabe que hay un fallo (cuando el disco le dice: no puedo escribir o el disco simplemente no contesta), pero en esta situación, para el RAID todo ha salido bien.

También se puede detectar con grabaciones de control: grabas algo y recuperas todas las copias, para ver si coinciden.

Sí, puedes usar CRCs también.

...

...

...

Solución: desactivar las cachés propios de los discos, no de la controladora RAID. Problema nuevo: pierdes rendimiento. Ventaja: ganas en seguridad.

- Cachés con pila.

Discos más grandes y más caros ;) Pero es una solución.

En servidores me parece razonable. En caseros... pff.

¿Mas grandes? A ver... puede ser una batería de respaldo tipo recargable, que son tamaño botón. No es tanto. O pueden ser condensadores de respaldo, de esos de tamaño "1 F". También puede ser una flash: el condensador usa su carga para grabar una flash a partir de la ram. O incluso a disco, mientras falla la corriente, en una pista reservada para grabar sólo la ram.

Lo de la flash se está empezando a usar. Nosotros (en los servidores) hacemos lo de los condensadores.

...

...

- Añadir comando PATA/SATA para volcado de cache de disco de emergencia. El sistema operativo sabe que se va la corriente, o que va a apagar el sistema. Es el momento de ordenarle volcar la caché.

Existen esos comandos y/o funciones: sync, fsync(), O_SYNC, ... Que hacen un flush de la RAM del servidor/PC/estación al disco (realmente se envía a la cahcé del disco). Pero cuando llegas al disco ... te encuentras con el firmware del disco. Los fabricantes de discos tendrían que implementar un comando a nivel de firmware que se pueda llamar desde cualquier sistema operativo (aka estándar ... BIEN!!!, Otro "estándar" ;)

Es una idea interesante.

Es que me refiero a comandos del firmware, en el estándar SATA. No otro estándar, sino una revisión. Y francamente, dudo que eso no exista.

Ni idea.

...

...

- Añadir comando para volcado rutinario de cache de disco, que sería usado por el kernel como parte de un "sync".

Hay una cosa que se llama "barriers" que facilita algo la tarea. Al activar los barriers. El sistema d eficheros lo qu ehace es decirle al disco:

"No puedes mezclar los datos entre este barrier y este otro"

Es decir, facilita de alguna manera una escritura ordenado de los datos. ütil, por ejemplo para bases de datos y vídeo o audio en los qu eel orden de escritura de los datos es importante.

Sí, he oído menciones de "barrier" varias veces, a ver si leo algo con más detalle.

http://en.wikipedia.org/wiki/Barrier_(computer_science)

no es eso...

Una vez vi una página muy buena donde se explicaba con dibujos y todo, pero no me acuerdo cuál es :( Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- 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

Hablando del kmail.... No voy a poner un bugzilla ni dar la coña buscando a un desarollador, espero que el problema se resuelva con la madurez del software y el sentido común, el caso es que la configuracion del kmail es un desastre!! A veces al kmail se le va la olla y sacar lo que hay el la conf es caso imposible , además los filtros podian estar en un fichero aparte o algo asi... no creo que sea el único que lo piensa.... En fin, ya se lo que vais a decir, que arrime el hombro o blah blah blah Pero bueno bastante tiene los KDEs boys con sacar adelante la 4.x a.k.a "The ugly desktop" Salu2 PD: cuando la 11.x vaya bien me avisais pa' cambiar :-P El Viernes, 13 de Marzo de 2009 Camaleón escribió:

El 2009-03-13 a las 11:13 +0100, admin-listas escribió:

...

si, pero no da tiempo cuando se va la luz. La Sai, pos no da pa mas el presupuesto.

Un equipo sin sai... es como no tener equipo.

Yo diría que con un sai te evitas el 95% de los problemas de fallos en los componentes, no sólo de los discos duros sino del micro o la memoria que también son muy puñeteros.

Un sai es la mejor inversión que se puede hacer.

...

Las copias , ni ganas (eso que me pierdo)

¿Lo dices de broma, no? :-?

...

La curiosidad :que solo se ha perdido el tamaño de los iconos y la configuracion de las cuentas de correo, de las 4, pero el resto de configuraciones del kontac esta bien, asi como las carpetas.

En fin las volveremos a meter y que no pase otra vez.

Si no tomas medidas, volverá a pasar, claro. Y podría ser peor: la placa a la basura, algún componente dañado y el equipo parado durante días :-(

Saludos,

-- Camaleón

-- Ningún personajillo ha sido vilipendiado si no es necesario. El 'buen rollo' está en nuestras manos. ->>----------------------------------------------- Clist UAH a.k.a Angel ---------------------------------[www.uah.es]-<<-- Sex is a battle, love is war. -- 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

Mira ahora que estamos en faena Se le acaba de ir la olla a mi kmail.... Ahora el texto de los mensajes me sale en tipografia de ancho fijo y aunque he ido a la configuracion y lo he cambiado varias veces... ¡Ni caso! En fin... el problema ahora es que me junto mucho con la gente de RedIRIS, y sus bonitos Mcbooks..... ¡que tentación! La manzana en el paraiso del FOSS... Salu2 El Viernes, 13 de Marzo de 2009 Camaleón escribió:

El 2009-03-13 a las 16:44 +0100, Angel Alvarez escribió:

...

Hablando del kmail....

Y ya que pasaba por aquí... X-)

...

No voy a poner un bugzilla ni dar la coña buscando a un desarollador, espero que el problema se resuelva con la madurez del software y el sentido común, el caso es que la configuracion del kmail es un desastre!!

¿Mande? ¿Qué le pasa a la configuración? :-?

...

A veces al kmail se le va la olla y sacar lo que hay el la conf es caso imposible , además los filtros podian estar en un fichero aparte

o algo asi...

no creo que sea el único que lo piensa....

Se pueden exportar bastantes cosas del kmail, e importar también, no veo el problema. Hay otros clientes más restrictivos en este aspecto.

...

En fin, ya se lo que vais a decir, que arrime el hombro o blah blah blah

No, hombre, critica que es gratis :-P... pero si después de criticar te vas "pal" bugzilla y añades un bug de mejora de las cosas que no te gustan o crees que están mal, entoces tu conciencia estará más tranquila ;-)

...

Pero bueno bastante tiene los KDEs boys con sacar adelante la 4.x a.k.a "The ugly desktop"

Ah, vaya ¿tampoco te gusta la 4.2?

Está mejorando... va lenta, pero ya está empezando a coger el ritmo :-).

...

Salu2

PD: cuando la 11.x vaya bien me avisais pa' cambiar :-P

Yo no tengo prisa... hasta noviembre ni me planteo dejar la 10.3 >:-)

Saludos,

-- Camaleón

-- No imprima este correo si no es necesario. El medio ambiente está en nuestras manos. ->>----------------------------------------------- Clist UAH a.k.a Angel ---------------------------------[www.uah.es]-<<-- ...being the second biggest search engine in the world is good enough for us. Peter @ Pirate Bay.

En fin veremos si Suse llega a sacar la 4.3... Yo soy de los que no se fia de Novell (de la gente de Suse si pero de empresas americanas "subsidiarias" de M$...) Bien... lo de la RAM me ayuda a aguantar un poco más No obstante el dia que tenga un MCBook desos le meto KDE* disparao!!! *KDE 3.5 ó KDE 5.0 Salu2 El Viernes, 13 de Marzo de 2009 Camaleón escribió:

El 2009-03-13 a las 21:19 +0100, Angel Alvarez escribió:

...

Mira ahora que estamos en faena

Se le acaba de ir la olla a mi kmail....

Ahora el texto de los mensajes me sale en tipografia de ancho fijo y aunque he ido a la configuracion y lo he cambiado varias veces...

¡Ni caso!

Ah, bueno, pero esos son "pequeños glitches" :-P

A mi también se me pone el texto como le viene en gana, pero como estoy el kmail 3.5 y ya no se corrigen estas pequeñeces, pues no informo (a petición de suse, claro).

...

En fin... el problema ahora es que me junto mucho con la gente de RedIRIS,

y sus bonitos Mcbooks.....

¡que tentación! La manzana en el paraiso del FOSS...

¡Sacrílegos! O:-)

Ni caso. Seguro que a fin de mes ellos están haciendo sus cábalas para ver cómo pueden comprar ese módulo de ram adicional que les cuesta una pasta y tú en cambio, tan fresco, con tu kmail con el texto "deformado" X-)

Saludos,

-- Camaleón

-- Agua para todo? No, Agua para Todos. ->>----------------------------------------------- Clist UAH a.k.a Angel ---------------------------------[www.uah.es]-<<-- Warning: Microsoft_bribery.ISO contains OOXML code. -- 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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: El 2009-03-13 a las 10:32 +0100, Rafa Grimán escribió:

En la lista de OT (y en muchas otras) se está comentando mucho esto. En las de XFS también ha salido el tema. XFS lleva desde el 95 (creo) y tenemos soluciones a esto en nuestros servidores (a nivel hardware) y algunas de las mejoras que va a introducir en ext4 ya las tenemos nosotros en XFS.

Te recomiendo leer el hilo que hay sobre este tema en la lista OT.

¿Y porqué rayos hablais de esas cosas que son ON topic en la lista OFF topic? Es que esa lista no tiene archivo, no se puede leer a posteriori cuando te avisan de algo interesante. Ya os vale.

Básicamente hay que tener en cuenta:

- los sistemas de ficheros "modernos" hacen un sync a disco tarde (delayed allocation). Es decir, guardan en buffers y cachés datos y no escriben a disco inmediatamente

- esto lo hacen porque el disco duro es MUUUUUUUUUUUUYYYYYY lento

Comparativamente, claro.

- el hardware suele ser de mala calidad, es decir, sobre todo memorias que fallan (típico de componentes de PC y no de servidor o de estación de trabajo), fuentes de alimentación poco fiables, no utilizar SAI, cachés de discos duros que no son fiables, ...

- cachés del disco duro que fallan, aka discos duros no enterprise

¿Por qué no ocurre con otros sistemas de ficheros? Respuestas:

Yo no he perdido datos con XFS. Tengo una SAI, cierto, pero tengo petadas de sistema, y ultimamente, problemas con el cableado de un disco: Mar 8 12:42:24 nimrodel kernel: hda: status error: status=0x00 { } Mar 8 12:42:24 nimrodel kernel: ide: failed opcode was: unknown Mar 8 12:42:24 nimrodel kernel: hda: drive not ready for command Mar 8 12:42:24 nimrodel kernel: hda: status error: status=0x00 { } ... Mar 8 12:42:24 nimrodel kernel: hda: DMA disabled Mar 8 12:42:24 nimrodel kernel: hdb: DMA disabled Mar 8 12:42:24 nimrodel kernel: hda: drive not ready for command Mar 8 12:42:24 nimrodel kernel: ide0: reset: master: error (0x7f?) Mar 8 12:42:24 nimrodel kernel: hda: status error: status=0x00 { } Mar 8 12:42:24 nimrodel kernel: ide: failed opcode was: unknown Mar 8 12:42:24 nimrodel kernel: hda: drive not ready for command Mar 8 12:42:24 nimrodel kernel: hda: status error: status=0x00 { } ... Mar 8 12:42:24 nimrodel kernel: ide: failed opcode was: unknown Mar 8 12:42:24 nimrodel kernel: hda: drive not ready for command Mar 8 12:42:24 nimrodel kernel: ide0: reset: master: error (0x2b?) Mar 8 12:42:24 nimrodel kernel: end_request: I/O error, dev hda, sector 321457739 Mar 8 12:42:24 nimrodel kernel: end_request: I/O error, dev hda, sector 321457747 Mar 8 12:42:24 nimrodel kernel: end_request: I/O error, dev hda, sector 321457755 Mar 8 12:42:24 nimrodel kernel: end_request: I/O error, dev hda, sector 321457763 Mar 8 12:42:24 nimrodel kernel: end_request: I/O error, dev hda, sector 321457771 ... Mar 8 12:42:25 nimrodel kernel: I/O error in filesystem ("hda11") meta-data dev hda11 block 0xc0487a ("xlog_iodone") error 5 buf count 3584 Mar 8 12:42:25 nimrodel kernel: xfs_force_shutdown(hda11,0x2) called from line 1007 of file fs/xfs/xfs_log.c. Return address = 0xfa1d47d4 Mar 8 12:42:25 nimrodel kernel: Filesystem "hda11": Log I/O Error Detected. Shutting down filesystem: hda11 Mar 8 12:42:25 nimrodel kernel: Please umount the filesystem, and rectify the problem(s) ... Mar 8 12:42:25 nimrodel kernel: end_request: I/O error, dev hda, sector 315405891 Mar 8 12:42:25 nimrodel kernel: end_request: I/O error, dev hda, sector 315405899 Mar 8 12:42:25 nimrodel kernel: printk: 3 messages suppressed. Mar 8 12:42:25 nimrodel kernel: Buffer I/O error on device hda20, logical block 4428121 Mar 8 12:42:25 nimrodel kernel: lost page write due to I/O error on hda20 Mar 8 12:42:25 nimrodel kernel: Buffer I/O error on device hda20, logical block 4428122 Mar 8 12:42:25 nimrodel kernel: lost page write due to I/O error on hda20 ... Mar 8 12:42:25 nimrodel kernel: lost page write due to I/O error on hda20 Mar 8 12:42:25 nimrodel kernel: end_request: I/O error, dev hda, sector 315917795 Mar 8 12:42:25 nimrodel kernel: end_request: I/O error, dev hda, sector 315917795 Mar 8 12:42:25 nimrodel kernel: REISERFS warning (device dm-4): sh-2029: %s: bitmap block (#%u) reading failed reiserfs_read_bitmap_block: reiserfs_read_bitmap_block Mar 8 12:42:25 nimrodel kernel: end_request: I/O error, dev hda, sector 316179939 Mar 8 12:42:25 nimrodel kernel: end_request: I/O error, dev hda, sector 316179939 Mar 8 12:42:25 nimrodel kernel: REISERFS warning (device dm-4): sh-2029: %s: bitmap block (#%u) reading failed reiserfs_read_bitmap_block: reiserfs_read_bitmap_block ... muchos más ... Mar 8 12:42:26 nimrodel kernel: end_request: I/O error, dev hda, sector 44886809 Mar 8 12:42:26 nimrodel kernel: Read-error on swap-device (3:0:44886817) Mar 8 12:42:26 nimrodel kernel: end_request: I/O error, dev hda, sector 44886817 El log sobrevive porque está en hdd, no afectado. Al final reboté, pero no perdí nada. La partición de la que protesta es reiser, pero había una xfs montada en ese disco (las encriptadas son ficheros en su mayor parte en hda, montadas con loop, y la partición "anfitrión" es xfs). Apago, quito y pongo los cables, enciendo, y hala. No es el cable, ya lo he cambiado, me temo que puede ser el conector de la placa (muy mal arreglo) o el del disco (si intento arreglarlo y me lo cargo, no puedo acceder a los datos). Me temo que tendré que cambiar de ordenador. Y por cierto, lo que he descubierto el otro dia, en mi partición de pruebas, es alucinante: empieza a soltarme los avisos de que no puede acceder a hda, aunque el teclado o el ratón todavía no se han bloqueado. Se me ocurre abrir la caja y apretar los conectores del disco y la placa, sin sacarlos, y... ¡funciona! Pude continuar trabajando un dia entero sin apagarlo. Hoy estoy con la 11.0 en otra partición, y no he tocado los cables. Se que fallará, falla todas las semanas, pero ahora, si me pilla delante, probaré lo mismo. ¿No es alucinante? :-O Ah, luego tuve que usar hdparm para reactivar el DMA en los discos. Todavía no me lo creo.

5.- hacer más backups

6.- volver a hacer backups

7.- jugar a la lotería, ganar y vivir una vida contemplativa ;)

8.- hacer backups

X'-)

9.- casi se me olvida: haced backups de vuestros datos

Eso, hacer backups. Por cierto... en la 11.0 mi sistema de backup "me lo han roto". Lo hago a disco externo via USB, con sistema de ficheros reiser... pues bien, da errores: Mar 6 00:19:04 nimrodel kernel: sd 1:0:0:0: [sda] Sense Key : No Sense [current] Mar 6 00:19:04 nimrodel kernel: Info fld=0x0 Mar 6 00:19:04 nimrodel kernel: sd 1:0:0:0: [sda] Add. Sense: No additional sense information que terminan por provocar la corrupción del sistema de ficheros que requiere un rebuild tree, que tarda varias horas (aunque fuera en disco interno sería lento).

Un consejo de colegas, si queréis "garantizar" que el dato se ha escrito a disco, teclead el comando:

sync

Tecleado unas 100 veces. Da igual el sistema de ficheros que uséis, el probelma con el que os vais a encontrar es la caché del propio disco duro y su firmware.

Basta con grabar un fichero a disco mayor que la caché del disco, que sólo en los buenos llegan a 32 megas. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkm6ajkACgkQtTMYHG2NR9W0YACeNwocAwcKhnsDSpk6pSluScfz +8EAoJLz+17RVyhCuyXmSpra3cNGSsLt =hp+E -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-03-16 a las 08:43 +0100, Rafa Grimán escribió:

...

...

Te recomiendo leer el hilo que hay sobre este tema en la lista OT.

¿Y porqué rayos hablais de esas cosas que son ON topic en la lista OFF topic? Es que esa lista no tiene archivo, no se puede leer a posteriori cuando te avisan de algo interesante.

Ya os vale.

Que pacha ... ;) Por ahora no he contestado a la OT y en cuanto a lo de por qué se habla de algo ON Topic en la lista OT ... ni idea. Me he limitado a hacer de mensajero.

Fale, pero es que la lista OT es la única que no tiene archivo: si sale algo interesante es inutil decirselo a los demás, porque no hay manera de volver a leer esos artículos si no estabas subscrito antes.

...

...

Básicamente hay que tener en cuenta:

- los sistemas de ficheros "modernos" hacen un sync a disco tarde (delayed allocation). Es decir, guardan en buffers y cachés datos y no escriben a disco inmediatamente

- esto lo hacen porque el disco duro es MUUUUUUUUUUUUYYYYYY lento

Comparativamente, claro.

Comparativamente, claro 0:) Comparando tiempo de acceso y velocidad de lectura entre RAM y de HDD es asombroso.

Por cierto, que el otro dia vino un amigo a recoger unos cuantos ficheros que le había descargado (no tiene internet) a una flash, e iba lentísima. Me echaba la culpa a mi cable prolongador, así que tuve que hacer malabarismos para volver a enchufarla directamente en la tarjeta, detrás del armario. Nada, igual de lenta. Entonces yo le eché la culpa a que su flash marca "la pava" sería usb-1, así que hala, a mirar con usbview. Pues no, es versión 2, alta velocidad. O sea, que no, que las flashes son lentas de narices escribiendo. No te das cuenta cuando lo que grabas es un ficherito de word, pero cuando grabas unos cuantos gigas, canta. Nada que cambiamos a un disco duro externo de portatil, alimentado via usb. Formateado en NTFS. Al principio el linux decía que no, que no estaba bien cerrado, y que no lo podía montar. Que lo lo abrieramos en windows y cerrasemos adecuadamente. Vale, mi amigo saca su portatil, lo hace, se lo pasamos al linux, y voila, el gnome lo abre automáticamente. Primer NTFS que abro en linux en mi vida automáticamente. Eso si, el driver del ntfs 3g en userspace traga cpu que da gusto. Un 30%.

...

Yo no he perdido datos con XFS. Tengo una SAI, cierto, pero tengo petadas de sistema, y ultimamente, problemas con el cableado de un disco:

[...]

Eso de problemas de cableado también lo he sufrido yo :"( Es una lata >:-|

Me arden las ganas de probar SATA. Sólo 6 hilos... debería ser a prueba de bomba. Hala, cierro los ojos, ya puedes echarme el agua fria >:-)

...

El log sobrevive porque está en hdd, no afectado.

Al final reboté, pero no perdí nada. La partición de la que protesta es reiser, pero había una xfs montada en ese disco (las encriptadas son ficheros en su mayor parte en hda, montadas con loop, y la partición "anfitrión" es xfs). Apago, quito y pongo los cables, enciendo, y hala. No es el cable, ya lo he cambiado, me temo que puede ser el conector de la placa (muy mal arreglo) o el del disco (si intento arreglarlo y me lo cargo, no puedo acceder a los datos).

=:0

Sí, tengo los pelos de punta, si...

...

Me temo que tendré que cambiar de ordenador.

Mira este:

http://en.expreview.com/2009/03/05/cebit-2009-asus-shows-off-rog-cg6190-gami...

"Sólo" consume 1.1 KW x"D No estamos volviendo locos.

Oye, que yo no pongo estufas en me "cuarto" porque la instalación electrica es antigua y peta. Corrijo: ha petado, estoy a medio cambiarla, con prolongadores por los suelos. Me ducho con un quinqué. :-}

...

Y por cierto, lo que he descubierto el otro dia, en mi partición de pruebas, es alucinante: empieza a soltarme los avisos de que no puede acceder a hda, aunque el teclado o el ratón todavía no se han bloqueado. Se me ocurre abrir la caja y apretar los conectores del disco y la placa, sin sacarlos, y... ¡funciona! Pude continuar trabajando un dia entero sin apagarlo. Hoy estoy con la 11.0 en otra partición, y no he tocado los cables. Se que fallará, falla todas las semanas, pero ahora, si me pilla delante, probaré lo mismo.

¿No es alucinante? :-O

A ver Carlos, que ese equipo no es un portátil. Si lo mueves ... los cables se sueltan ;)

Eso sería entendible, pero que se suelten los conectores las micras suficientes para fallar con las vibraciones del ventilador, tiene guasa. Y que el ordenador sobreviva si los reasiento en caliente, más.

...

Por cierto... en la 11.0 mi sistema de backup "me lo han roto". Lo hago a disco externo via USB, con sistema de ficheros reiser... pues bien, da errores:

Mar 6 00:19:04 nimrodel kernel: sd 1:0:0:0: [sda] Sense Key : No Sense [current] Mar 6 00:19:04 nimrodel kernel: Info fld=0x0 Mar 6 00:19:04 nimrodel kernel: sd 1:0:0:0: [sda] Add. Sense: No additional sense information

que terminan por provocar la corrupción del sistema de ficheros que requiere un rebuild tree, que tarda varias horas (aunque fuera en disco interno sería lento).

=:0

Ya te digo. Es que hasta las cosas "inviolables" como la estabilidad de los sistemas de ficheros, ya no lo son. :-/ Se puede soportar que el ordenador se cuelgue, que se cuelguen los programas, que no funcionen tal o cual dispositivo... pero que los discos se corrompan, y por fallos de software... eso te rompe los esquemas. Que falle el ext4, es esperable. Que falle un sistema estable hace años... no tiene perdón.

...

...

Un consejo de colegas, si queréis "garantizar" que el dato se ha escrito a disco, teclead el comando:

sync

Tecleado unas 100 veces. Da igual el sistema de ficheros que uséis, el probelma con el que os vais a encontrar es la caché del propio disco duro y su firmware.

Basta con grabar un fichero a disco mayor que la caché del disco, que sólo en los buenos llegan a 32 megas.

Ya, pero si hablamos de ficheros de configuración ... 32+ MB ... peyacho de fichero de configuración !!! ;)

No, grabas cualquier fichero. O varios. Habría que saber que algoritmo usan esas caches, si van por particiones, por sectores, por fifo... pero se supone que si grabas algo que ocupa varias veces el tamaño de la cache es muy posible que los datos antiguos los tire. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkm+Ud8ACgkQtTMYHG2NR9XqwwCfe2VBBWmuDxWuBU3/xGySGbjM kjIAoJfah45aeOayHH1zDcplnDsaCa22 =Z42r -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-03-16 a las 14:55 +0100, Rafa Grimán escribió:

El Monday 16 March 2009, Carlos E. R. escribió:

...

O sea, que no, que las flashes son lentas de narices escribiendo. No te das cuenta cuando lo que grabas es un ficherito de word, pero cuando grabas unos cuantos gigas, canta.

Comprueba si se ha montado con sync. Si no recuerdo mal, en la 10.1, los dispositivos de bloques externos se montaban con sync activado y eso era eterno. La razón era que muchos usuarios desconectaban el USB sin que se hubieran escrito los datos ... qué malas son las prisas ;)

Creo que lo miré (mount), pero de todas formas, yo miraba la velocidad de transferencia en gkrelm, y estaba por debajo del mega por segundo. Es decir, el flujo de datos hacia el disco era inferior al m/s. Con mis propios discos suele llegar a los 10 m/s de media. Es mucha diferencia. Y de todas formas, el disco externo ntfs que pusimos después iba rápido. No tanto como los mios (por lo del uso de cpu del driver), pero bastante.

...

Eso si, el driver del ntfs 3g en userspace traga cpu que da gusto. Un 30%.

Vaya.

Me sorprendió. Es la primera vez que escribo en NTFS desde linux.

...

Me arden las ganas de probar SATA. Sólo 6 hilos... debería ser a prueba de bomba.

Hala, cierro los ojos, ya puedes echarme el agua fria >:-)

Yo no he tenido problemas.

Pues me alegro.

...

Ya te digo. Es que hasta las cosas "inviolables" como la estabilidad de los sistemas de ficheros, ya no lo son. :-/

Se puede soportar que el ordenador se cuelgue, que se cuelguen los programas, que no funcionen tal o cual dispositivo... pero que los discos se corrompan, y por fallos de software... eso te rompe los esquemas. Que falle el ext4, es esperable. Que falle un sistema estable hace años... no tiene perdón.

La verdad es que la "culpa" es del hardware. Me explico. La velocidad de los HDD casi no ha mejorado en los últimos 10 (¿20?) años (recordemos que los anchos de banda que dan los fabricantes son picos teóricos). Así que las mejoras en velocidad se tienen que hacer en el sistema de ficheros.

Ahora, con los SSD, parece que la cosa ha cambiado: ha mejorado la velocidad. Lo malo es que las celdas que usan los SSD tienen una vida media corta por lo que vas perdiendo espacio en el dispositivo poco a poco :( Ganas en una cosa y pierdes en otra. Claro que al principio, los HDD también sufrían de eso incluso llegando a marcar los fabricantes algunos sectores defectuosos en los discos que salían de fábrica.

Si, y ahora cuando la gente ve un sector fastidiado en un disco duro se asusta y compran otro. Yo tengo un disco duro que desarrolló errores al mes de comprarlo, y ahí sigue, ocho años después, funcionando tal cual. Pero yo me refiero a que me estoy topando con verdaderos bugs de software en la implementación de cosas que eran estables como reiserfs. Errores que, con exactamente el mismo hardware, funcionaban perfectamente con versiones anteriores de openSUSE. Sólo se están ocupando del ext3. A ver: · Reiser en USB: se corrompe en 11.0 · Reiser en 11.1 pristino: se cuelga cuando beagle usa cierta funcionalidad "rara". Corregido. · Reiser encriptado en DVD (sólo lectura): el kernel trata de escribir y falla al montar. Creo recordar que también pasa con XFS, pero este sobrevive y monta. LLeva un año sin corregir, detectado hace dos. · XFS encriptado: cuelga el sistema entero al escribir ficheros grandes. Lleva sin corregir dos años. Esos son los que recuerdo ahora mismo. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkm+YR0ACgkQtTMYHG2NR9XBVwCfV2vN6SovGwxLlYQla6cdzzsA sZAAn1/rcQG43kiLZ48cdc/VgFtekKa9 =Fv+j -----END PGP SIGNATURE-----

Hola :) El Monday 16 March 2009, Camaleón escribió: [...]

Entiendo que un disco duro se estropeé (por edad/tiempo de vida, por defecto de fabricación o por problemas externos -mecánicos o electrónicos-) pero entiendo *menos* que un sistema de archivos hoy en día no sepa (o pueda) gestionar un apagón forzoso y esporádico porque a veces no hay más remedio que apagar a lo bruto, se tenga SAI detrás o no.

Porque es algo incontrolable e impredecible. Si se pudiera predecir un apagón, caida de tensión, ... el sistema de ficheros (concretamente el kernel) sí podría reponder. Pero es algo completamente caótico, no puedes predecir un apagón. Bueno, a lo mejor una persona puede más o menos hacerse una idea si va a haber un apagón ya que sabe: el estado de la instalación eléctrica, si llueve o no, si hace viento, si hay guerra, ... Pero el pobre sistema operativo no sabe esas cosas ;) Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- 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

Camaleón escribió:

El 2009-03-17 a las 08:43 +0100, Rafa Grimán escribió:

...

El Monday 16 March 2009, Camaleón escribió:

...

...

Entiendo que un disco duro se estropeé (por edad/tiempo de vida, por defecto de fabricación o por problemas externos -mecánicos o electrónicos-) pero entiendo *menos* que un sistema de archivos hoy en día no sepa (o pueda) gestionar un apagón forzoso y esporádico porque a veces no hay más remedio que apagar a lo bruto, se tenga SAI detrás o no.

Porque es algo incontrolable e impredecible. Si se pudiera predecir un apagón, caida de tensión, ... el sistema de ficheros (concretamente el kernel) sí podría reponder. Pero es algo completamente caótico, no puedes predecir un apagón. Bueno, a lo mejor una persona puede más o menos hacerse una idea si va a haber un apagón ya que sabe: el estado de la instalación eléctrica, si llueve o no, si hace viento, si hay guerra, ... Pero el pobre sistema operativo no sabe esas cosas ;)

Pero Rafa, un equipo no sólo se apaga a lo bruto por un apagón. Se puede quedar colgado ¿qué hacemos? Tenemos un SAI enorme, raid con batería y el equipo hay que apagarlo a lo bruto porque no responde.

¿De qué sirven todas esas precauciones (fuente de alimentación redundante, sai, batería en controladora)? ¿De nada...? :-(

Esa situación la debe de gestionar el sistema operativo y la debe gestionar correctamente, al menos para evitar una pérdida de datos. Perder datos es la peor acción que podría hacer un sistema.

El caos también se gestiona o al menos se pueden hacer aproximaciones para evitar males mayores :-)

Saludos,

¿Y no sirve esperar unos minutos antes de apagar a lo bruto? Digamos 5. ¿Esto no haría que ya la caché o algún otro almacenamiento temporario escriba todo realmente al disco físico? Saludos -- 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

Rafa Grimán escribió:

Hola :)

El Tuesday 17 March 2009, Alberto Vicat escribió:

...

Camaleón escribió:

...

...

...

Entiendo que un disco duro se estropeé (por edad/tiempo de vida, por defecto de fabricación o por problemas externos -mecánicos o electrónicos-) pero entiendo *menos* que un sistema de archivos hoy en día no sepa (o pueda) gestionar un apagón forzoso y esporádico porque a veces no hay más remedio que apagar a lo bruto, se tenga SAI detrás o no. Porque es algo incontrolable e impredecible. Si se pudiera predecir un apagón, caida de tensión, ... el sistema de ficheros (concretamente el kernel) sí podría reponder. Pero es algo completamente caótico, no

El Monday 16 March 2009, Camaleón escribió: puedes predecir un apagón. Bueno, a lo mejor una persona puede más o menos hacerse una idea si va a haber un apagón ya que sabe: el estado de la instalación eléctrica, si llueve o no, si hace viento, si hay guerra, ... Pero el pobre sistema operativo no sabe esas cosas ;) Pero Rafa, un equipo no sólo se apaga a lo bruto por un apagón. Se

El 2009-03-17 a las 08:43 +0100, Rafa Grimán escribió: puede quedar colgado ¿qué hacemos? Tenemos un SAI enorme, raid con batería y el equipo hay que apagarlo a lo bruto porque no responde.

¿De qué sirven todas esas precauciones (fuente de alimentación redundante, sai, batería en controladora)? ¿De nada...? :-(

Esa situación la debe de gestionar el sistema operativo y la debe gestionar correctamente, al menos para evitar una pérdida de datos. Perder datos es la peor acción que podría hacer un sistema.

El caos también se gestiona o al menos se pueden hacer aproximaciones para evitar males mayores :-)

Saludos, ¿Y no sirve esperar unos minutos antes de apagar a lo bruto? Digamos 5. ¿Esto no haría que ya la caché o algún otro almacenamiento temporario escriba todo realmente al disco físico?

Sí, esto te podría "garantizar" que el dato en la caché del disco se ha escrito al platter, pero si ha habido cuelgue del sistema operativo: lo que hay en RAM se pierde.

Hombre, tienes el sysreq key que te permite recuperar de algunos cuelgues y puedes hacer sync a disco. Pero hay muy poca gente que usa sysreq key (incluyendo administradores).

Rafa

Llegamos entonces a lo que decías en otra respuesta: que siempre el culpable es el operador. Y sus dedos. Y creo que tenés mucha razón. Saludos -- 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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-03-17 a las 10:35 +0100, Rafa Grimán escribió:

Hombre, tienes el sysreq key que te permite recuperar de algunos cuelgues y puedes hacer sync a disco. Pero hay muy poca gente que usa sysreq key (incluyendo administradores).

Por la sencilla razón de que en ese momento no te acuerdas de qué combinación exacta de teclas es, y no puedes mirarla en el ordenador, que está colgado. Y si te acuerdas, resulta que no está activada. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkm/mNMACgkQtTMYHG2NR9XPGQCglENlkjzT5y2YDaur6r6a1/6s c9IAn0HRzVgf8xpmHvse0/9riOKENqq1 =6a8B -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-03-17 a las 14:58 +0100, Rafa Grimán escribió:

Hola :)

El Tuesday 17 March 2009, Carlos E. R. escribió:

...

El 2009-03-17 a las 10:35 +0100, Rafa Grimán escribió:

...

Hombre, tienes el sysreq key que te permite recuperar de algunos cuelgues y puedes hacer sync a disco. Pero hay muy poca gente que usa sysreq key (incluyendo administradores).

Por la sencilla razón de que en ese momento no te acuerdas de qué combinación exacta de teclas es, y no puedes mirarla en el ordenador, que está colgado.

Y si te acuerdas, resulta que no está activada.

Hombre Carlos, que los Post-it están (además de para escribir la contraseña) para apuntar este tipo de cosas ;"D

¿Pero es que te crees que me queda sitio para más postits en el borde del monitor? Con las contraseñas de los amigos y las de los silos de misiles y las cenas del 98, ya no quea una pulgada libre :-p

PD No, yo tampoco tengo apuntadas las combinaciones de teclas ni impresas ni nada ... es que me he quedado sin Post-it 0:)

Y si los compras de los chinos, que son más baratos, se te caen :-p - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkm/xlgACgkQtTMYHG2NR9XvOwCggFz2+HvdHCgoyxYGXA+VAnpU FygAoIfbFbajTEt95WM7Cdg3bjiocbJf =74Jh -----END PGP SIGNATURE-----

Hola :) El Tuesday 17 March 2009, Camaleón escribió:

El 2009-03-17 a las 08:43 +0100, Rafa Grimán escribió:

...

El Monday 16 March 2009, Camaleón escribió:

...

Entiendo que un disco duro se estropeé (por edad/tiempo de vida, por defecto de fabricación o por problemas externos -mecánicos o electrónicos-) pero entiendo *menos* que un sistema de archivos hoy en día no sepa (o pueda) gestionar un apagón forzoso y esporádico porque a veces no hay más remedio que apagar a lo bruto, se tenga SAI detrás o no.

Porque es algo incontrolable e impredecible. Si se pudiera predecir un apagón, caida de tensión, ... el sistema de ficheros (concretamente el kernel) sí podría reponder. Pero es algo completamente caótico, no puedes predecir un apagón. Bueno, a lo mejor una persona puede más o menos hacerse una idea si va a haber un apagón ya que sabe: el estado de la instalación eléctrica, si llueve o no, si hace viento, si hay guerra, ... Pero el pobre sistema operativo no sabe esas cosas ;)

Pero Rafa, un equipo no sólo se apaga a lo bruto por un apagón. Se puede quedar colgado ¿qué hacemos? Tenemos un SAI enorme, raid con batería y el equipo hay que apagarlo a lo bruto porque no responde.

Más caos ;) Puede colgarse el sistema por: - un driver defectuoso: impredecible por el sistema operativo. Aquí entra en juego la fase alpha y beta y los release candidates. Además de depuración y profiling (que cada vez se hace menos) y hardware bien documentado. - hardware defectuoso: predecible en algunos casos (SMART, por ejemplo), pero en otros no es tan fácil (RAM, aunque tiene sus posibles soluciones*) - usuario: NO hay solución. El usuario es EL peligro de cualquier sistema informático. El sistema operativo NO puede hacer frente a esto, los programadores NO pueden predecir el comportamiento de un usuario. La ÚNICA solución es que el usuario NO se acerque al sistema informático.** - hardware mal conectado: el sistema operativo no puede hacer frente a esto * FB-DIMM permite tener módulos de spare y mirroring de memoria (algo así como un RAID 1 de memoria y módulos de spare por si falla un módulo del RAID 1 de RAM). Ambas características son independientes por lo que puedes usar ambas a la vez o sólo una de ellas o no usar ninguna de ellas. También está la opción de comprobación de bits, Linux es capaz de recuperarse de errores de hasta 2 bits (creo, no recuerdo si son 2 ó 3 bits erróneos en un módulo de memoria). ** En un cliente vimos una vez un cartel puesto en un servidor que ponía: "No tocar con el dedo". Se conoce que eso de "No tocar" no especifica lo suficiente. Aunque "con el dedo" especifica demasiado, así que alguien lo podrá tocar con el codo, por ejemplo. Al programar algo (sea el kernel, un driver, un cliente de correo, ... lo que sea), para evitar ciertas cosas, hay que preveerlas. Algunas sí se pueden predecir, pero otras no. Todo lo que sea predecible (o que ya se haya sufrido) se puede intentar corregir a nivel hardware y software, lo demás no. Bueno ... también está el factor económico y el factor tiempo: si no se dispone de alguno de estos factores ... la calidad baja. En el caso del FLOSS hay que sumar las ganas de colaborar: betatesters, programadores, ... Si hay ganas de colaborar, nos irá mejor :)

¿De qué sirven todas esas precauciones (fuente de alimentación redundante, sai, batería en controladora)? ¿De nada...? :-(

Sirven para hacer frente a situaciones predecibles (apagón, por ejemplo) o situaciones por las que ya hemos pasado (tasa de fallo de módulos de memoria o de disco). Lo demás es caótico: impredecible, complejo, ...

Esa situación la debe de gestionar el sistema operativo y la debe gestionar correctamente, al menos para evitar una pérdida de datos. Perder datos es la peor acción que podría hacer un sistema.

Siempre y cuando se pueda predecir o se haya sufrido antes. En el caso de lo de las cachés de los discos duros. Carlos propuso ideas buenas (baterías, CRCs, funciones, ...), la cosa ahora depende de: - roadmaps - inversión - interés - nuevas tecnologías (aka discos SSD) - ... Pero de nuevo, te trae "nuevos" problemas: pérdida de celdas (antes eran sectores defectuosos). Y traerá otros problemas que no conocemos por lo que hasta que no se den ... no podremos resolver. A esto hay que añadir que en el caso de los discos duros y sistemas de ficheros, hay más cosas: - comportamiento de las aplicaciones - comportamiento de los usuarios - comportamiento de las librerías en las que se basa la aplicación - hardware "no relacionado" con el disco (como fuente de alimentación, placa base, controladora, bus de datos, CPU, registros de la CPU, ...) - etc. IMHO, debería haber más dedicación/inversión a/en: - debugging - profiling - betatesting Y no dar tanta importancia a las fechas. Gentoo, Debian, Slackware y otras no se dejan llevar tanto por la fecha de release sino más bien por su estabilidad y fiabilidad. Sí, ya sé: - no hay una empresa por detrás y, por tanto, no hay intereses económicos por lo que se pueden tomar el tiempo que les dé la gana - no son distros para el usuario casero que exige novedades cada X tiempo. No estoy muy de acuerdo con esto, conozco muchos usuarios que lo que quieren es que funcione y les da igual si hay o no novedades - también han tenido sus problemas - nadie es perfecto ;) Obviamente, esto supone invertir mucho tiempo y las empresas no están de acuerdo en invertir tiempo porque: - la competencia se te echa encima - el cliente se te echa encima - el tiempo es dinero - "ya lo arreglaremos" - es más importante anunciar una nueva funcionalidad que el corregir un error ya que una nueva funcionalidad siginifca "avance" y corregir un error significa "tu aplicación funciona mal".

El caos también se gestiona o al menos se pueden hacer aproximaciones para evitar males mayores :-)

Pero no se puede predecir (por ejemplo el comportamiento de la bolsa, el tiempo, ...). El azar sí es predecible (aka tasa de fallos de discos, de módulos de memoria, ... ;) Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- 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

Hola :) El Tuesday 17 March 2009, Camaleón escribió:

El 2009-03-17 a las 10:31 +0100, Rafa Grimán escribió:

...

El Tuesday 17 March 2009, Camaleón escribió:

...

Pero Rafa, un equipo no sólo se apaga a lo bruto por un apagón. Se puede quedar colgado ¿qué hacemos? Tenemos un SAI enorme, raid con batería y el equipo hay que apagarlo a lo bruto porque no responde.

Más caos ;) Puede colgarse el sistema por:

- un driver defectuoso: impredecible por el sistema operativo. Aquí entra en juego la fase alpha y beta y los release candidates. Además de depuración y profiling (que cada vez se hace menos) y hardware bien documentado.

- hardware defectuoso: predecible en algunos casos (SMART, por ejemplo), pero en otros no es tan fácil (RAM, aunque tiene sus posibles soluciones*)

- usuario: NO hay solución. El usuario es EL peligro de cualquier sistema informático. El sistema operativo NO puede hacer frente a esto, los programadores NO pueden predecir el comportamiento de un usuario. La ÚNICA solución es que el usuario NO se acerque al sistema informático.**

- hardware mal conectado: el sistema operativo no puede hacer frente a esto

Por eso mismo. Que el sistema se cuelgue, es normal.

Pero _NO_ debería serlo.

Que haya apagones, también. Que no haya un SAI, también.

No debería ser normal no tener un SAI.

Componentes en mal estado, pues también.

No debería ser normal tener componentes en mal estado. ¿Por qué estos ejemplos que pones se consideran "normal" o aceptables? En un coche _NO_ son aceptables. Por lo menos nadie en su sano juicio conduce un coche cuyas ruedas están lisas sin dibujo o cuyos frenos no funcionen o se "cuelguen". Nadie compra pantalones rotos (bueno, a menos que sea la última moda y quieras ser la super-estrella ... nunca he entendido las modas). Nadie compra comida caducada. Nadie va a un dentista cuyas manos huelen a pie. Esto es lo mismo. ¿Por qué en la informática es normal? ¿Por qué se acepta como normal que no haya SAI, que no haya backup, que las cosas se cuelgan? _NO_ señor. Sí, son inventos hechos por Humanos y, por tanto, imperfectos por lo que tienden a fallar (de ahí los MTBF). Se acepta que haya un % de error. Pero es que en la informática se acepta un % de error enorme: es "normal" Y ESO QUE _TODO_ DEPENDE DE LA INFORMÁTICA (banca, sanidad, ...).

¿Y cómo debe actuar el sistema en esos casos? Fácil: problemas de hardware, debe registrar errores de acceso (lectura y escritura). Problemas más serios, pues también debería regsitrarlos.

1º Ver rollo que he escrito más arriba ;) 2º Se podrán registrar los errores que no bloqueen el sistema, que sean "normales", que sean previsibles ... pero los que no entran en esas categorías ... va a ser difícil.

Si el usuario no tiene datos, no puede saber que hay un problema y no puede solucionarlo.

Pero si compras hardware (memoria RAM, por poner un ejemplo) malo y te falla (lo normal) ... ¿qué datos guardas si están todos corruptos o bien se han esfumado? Si la placa base es mala ... los datos que se transmiten pueden corromperse o bien un problema de tensión te puede dañar el disco de forma que NO puedes acceder al disco: ¿dónde guardo qué datos?

Si el sistema se cuelga, el sistema de archivos debería poder gestionarlo. Es un evento esperable, y tendrían que estar preparados para ese tipo de errores.

Si el cuelgue es por un módulo de RAM o controladora de disco defectuoso, ¿qué datos y dónde se guardan? Si el sistema de refirgeración del procesador es defectuoso y hace que el procesador realice cálculos erróneos, ¿me puedo fiar de ellos aunque los guarde?

No te digo hace 30 años, pero hoy en día, pues sí.

No digo que estés equivocada. Lo que digo es que no es tan fácil como te imaginas/piensas.

...

* FB-DIMM permite tener módulos de spare y mirroring de memoria (algo así como un RAID 1 de memoria y módulos de spare por si falla un módulo del RAID 1 de RAM). Ambas características son independientes por lo que puedes usar ambas a la vez o sólo una de ellas o no usar ninguna de ellas. También está la opción de comprobación de bits, Linux es capaz de recuperarse de errores de hasta 2 bits (creo, no recuerdo si son 2 ó 3 bits erróneos en un módulo de memoria).

Se avanza mucho en hardware pero poco en software :-(

IMHO, se avanza demasiado y se asienta (aka depura y profile) poco :( Es decir, se introducen demasiadas novedades (¿features?) sin asentar y depurar las que ya existen.

...

** En un cliente vimos una vez un cartel puesto en un servidor que ponía: "No tocar con el dedo". Se conoce que eso de "No tocar" no especifica lo suficiente. Aunque "con el dedo" especifica demasiado, así que alguien lo podrá tocar con el codo, por ejemplo.

Vale, estoy de acuerdo que ante el usuario no hay protección que valga. Si lo puede romper, lo romperá y si lo puede "colgar", lo "colgará" X-)

x"D

...

Al programar algo (sea el kernel, un driver, un cliente de correo, ... lo que sea), para evitar ciertas cosas, hay que preveerlas. Algunas sí se pueden predecir, pero otras no. Todo lo que sea predecible (o que ya se haya sufrido) se puede intentar corregir a nivel hardware y software, lo demás no. Bueno ... también está el factor económico y el factor tiempo: si no se dispone de alguno de estos factores ... la calidad baja.

Las cosas que no se pueden precedir, también se gestionan. Y eliminar datos del disco no es precisamente lo más deseable.

Pero es que a lo mejor esos datos nunca llegaron a disco, luego no estás eliminando los datos ... simplemente nunca existieron ;)

¿Qué datos se eliminan y en base a qué? ¿Archivos de configuración de programas, archivos necesarios para el inicio del sistema? ¿Se elimina al azar, no hay prioridades? Una cosa así no puede quedar al libre albedrío :-/

En el caso que nos atañe (KDE pierde ficheros de configuración). No es que se produzca al azar, es que KDE lo ha hecho mal. Es decir, no crea un fichero temporal en el que guarda los datos y luego renombra. Si hiciera esto (crear un fichero temporal, borrar el original y luego renombrar), la probabilidad de pérdida de datos sería mucho menor. En este enlace lo explican mejor: http://mjg59.livejournal.com/108257.html

...

En el caso del FLOSS hay que sumar las ganas de colaborar: betatesters, programadores, ... Si hay ganas de colaborar, nos irá mejor :)

Pero los sistemas de archivos se usan en muchos ámbitos y por muchas empresas (IBM, Oracle...) que tienen recursos. No sólo dependen de la comunidad libre.

Ver lo que he puesto más abajo sobre las empresas: tiempo y dinero, competencia, ...

...

...

¿De qué sirven todas esas precauciones (fuente de alimentación redundante, sai, batería en controladora)? ¿De nada...? :-(

Sirven para hacer frente a situaciones predecibles (apagón, por ejemplo) o situaciones por las que ya hemos pasado (tasa de fallo de módulos de memoria o de disco). Lo demás es caótico: impredecible, complejo, ...

Si se puede apagar, se apagará. Hay que programar con esa premisa, pensando siempre en sucesos probables. Hardware en mal estado, apagones, bloqueos o cuelgues son variables "posibles".

Sí, son predecibles, lo malo es ¿cuándo se van a dar? Si se sabe el cuándo, se puede programar al sistema de ficheros o al kernel o al driver o a quien sea para que guarde los datos al disco o a dónde sea. Por cierto, estoy de acuerdo contigo en que hay que mejorar el software.

...

...

Esa situación la debe de gestionar el sistema operativo y la debe gestionar correctamente, al menos para evitar una pérdida de datos. Perder datos es la peor acción que podría hacer un sistema.

Siempre y cuando se pueda predecir o se haya sufrido antes. En el caso de lo de las cachés de los discos duros. Carlos propuso ideas buenas (baterías, CRCs, funciones, ...), la cosa ahora depende de: - roadmaps - inversión - interés - nuevas tecnologías (aka discos SSD) - ...

Y de una buena programación. Ya te digo que de nada sirve prever y tener toda la seguridad si el sistema está mal diseñado porque no se ha previsto que el equipo se puede quedar colgado en cualquier momento. Y eso es algo que sucede a diario. No sabe "cuándo", pero se sabe "qué" y "cómo". Algo se podrá hacer para evitar esa pérdida de datos.

Para empezar, se puede intentar dirigir las medidas (inversión en desarrollo) a intentar evitar cuelgues porque el sw esté mal desarrollado. Pero esto no interesa: mola más añadir una nueva feature que depurar un driver (o una aplicación cualquiera). En cuanto a las empresas: tres cuartos de lo mismo, da más prestigio añadir una nueva funcionalidad que corregir cuelgues.

Puedo esperar perder datos si lanzo el equipo por la ventana, o si se quema en un incendio. Pero no espero perder datos si se va la luz :-)

Si se va la luz, hay que tener en cuenta una serie de cosas: - es un evento impredecible en cuanto a cuándo se va a producir. Que se va aproducir: sí, alguna vez se tiene que dar, pero cuándo ... es difícil predecir - la razón por la que se produce es impredecible también: ¿fenómeno atmosférico? ¿La señora de la limpieza ha desenchufado el servidor y ha enchufado la aspiradora? ¿El usuario ha pulsado el botón "sin querer"? - el material informático es 100% DEPENDIENTE de la electricidad por lo que a nivel sw no hay nada que se pueda hacer, la solución TIENE que ser por hardware: baterías, por ejemplo. Por sw NO se puede solucionar ya que si falla la luz -> falla el hw -> falla el sw ya que el sw DEPENDE del hw que a su vez depende de la luz.* * Por poner un ejemplo sencillo: una bombilla. Ya puedes tener el mejor de los filamentos o gas o lo que sea la bombilla que tienes que si se va la corriente ... adiós luz aka veo menos que un plátano liado en un trapo aka oscuridad. Es inmediato. Ahora diréis: "Ya, pero hay gases que permiten mantener una combustión durante X tiempo por lo que la luz (incandescencia) no desaparece de golpe y bla, bla, bla, ..." Esto es una solución hardware y sería similar a usar un SAI o una batería o un condensador o lo que sea, NO es una solución sw. Otro ejemplo: un coche. El conductor sería el sw, el coche el hardware y la gasolina la electricidad. Por muy buen conductor que seas, por muy previsor que seas, ... si pillas un bache y se te arranca el depósito de pronto (equivalente a se va la luz de pronto) o el motor se para. Sí, ya si vas cuesta abajo o vas a 270 KM/h no paras en seco, pero eso sería una solución HW (física, inercia) y no de sw (tu, conductor).

...

Pero de nuevo, te trae "nuevos" problemas: pérdida de celdas (antes eran sectores defectuosos). Y traerá otros problemas que no conocemos por lo que hasta que no se den ... no podremos resolver.

Las SSD basadas en DRAM tienen algunas ventajas.

Pero siguen DEPENDIENDO de la electricidad. Si falla la luz, es inmediato el fallo a menos que haya un HW por en medio que garantice cierta corriente (batería, por ejemplo). El sw no puede hacer nada porque es una capa superior que DEPENDE de las que hay abajo, por lo que si las de abajo fallan ... lo de arriba falla. Y si lo de abajo falla impredeciblemente ... lo de arriba no puede hacer nada.

...

A esto hay que añadir que en el caso de los discos duros y sistemas de ficheros, hay más cosas: - comportamiento de las aplicaciones - comportamiento de los usuarios - comportamiento de las librerías en las que se basa la aplicación - hardware "no relacionado" con el disco (como fuente de alimentación, placa base, controladora, bus de datos, CPU, registros de la CPU, ...) - etc.

IMHO, debería haber más dedicación/inversión a/en: - debugging - profiling - betatesting

Y en investigación :-P

También :)

...

Y no dar tanta importancia a las fechas. Gentoo, Debian, Slackware y otras no se dejan llevar tanto por la fecha de release sino más bien por su estabilidad y fiabilidad. Sí, ya sé: - no hay una empresa por detrás y, por tanto, no hay intereses económicos por lo que se pueden tomar el tiempo que les dé la gana - no son distros para el usuario casero que exige novedades cada X tiempo. No estoy muy de acuerdo con esto, conozco muchos usuarios que lo que quieren es que funcione y les da igual si hay o no novedades - también han tenido sus problemas - nadie es perfecto ;)

Este problema afecta a la mayoría de sistemas de archivo, así que nadie se libra, con empresa gorda detrás o sin ella.

Incluso afecta a sw que no es sistema de ficheros ;)

...

Obviamente, esto supone invertir mucho tiempo y las empresas no están de acuerdo en invertir tiempo porque: - la competencia se te echa encima - el cliente se te echa encima - el tiempo es dinero - "ya lo arreglaremos" - es más importante anunciar una nueva funcionalidad que el corregir un error ya que una nueva funcionalidad siginifca "avance" y corregir un error significa "tu aplicación funciona mal".

...

El caos también se gestiona o al menos se pueden hacer aproximaciones para evitar males mayores :-)

Pero no se puede predecir (por ejemplo el comportamiento de la bolsa, el tiempo, ...). El azar sí es predecible (aka tasa de fallos de discos, de módulos de memoria, ... ;)

No se puede precedir el factor tiempo (cuándo) pero sí qué es lo puede hacer (subir o bajar las acciones, si hará lluvia, sol o viento). Pero hay variables con las que sí se puede jugar. Sabes qué le puede afectar al sistema de archivos (apagón, bloqueo, hardarwe, componente lógico...) pues solucionemos las variables de las que sí tenemos información.

Pero es que lo que precisamente te interesa saber es cuándo para poder estar preparado en ese momento. Por ejemplo el tiempo, sé que va a llover (o al menos eso creo y espero ;), pero lo que me interesa saber es cuándo para saber si salir con paraguas o sembrar o ponerme chanclas o quedarme en casa y comprar un SAI por si cae un rayo y me estropea el ordenador ;) En cuanto al ordenador, también: me interesa saber cuándo va a fallar el componente (sea hw o sw) porque ya sé que va a fallar, lo que no sé es cuándo. De ahí que haya cosas como SMART, redundancia, alta disponibilidad, disaster recovery, business continuance, ... De lo contrario (si supiéramos cuándo va a fallar), no nos haría falta todo eso, lo haríamos por sw ;) Por cierto, sé que va a tocar la lotería, pero quiero saber cuándo y dónde ... para ir y comprarla !!!! Como decía Niels Bohr: "Es difícl hacer predicciones, especialmente si son en el futuro" ;) Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- 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

El 2009-03-17 a las 14:16 +0100, Camaleón escribió: (reenvío porque veo que no ha llegado a la lista) :-?

El 2009-03-17 a las 13:13 +0100, Rafa Grimán escribió:

...

...

...

El Tuesday 17 March 2009, Camaleón escribió:

...

...

Por eso mismo. Que el sistema se cuelgue, es normal.

Pero _NO_ debería serlo.

No, claro, pero sucede.

...

...

Que haya apagones, también. Que no haya un SAI, también.

No debería ser normal no tener un SAI.

Hombre, no todos tienen los recursos necesarios para tenerlo y no por ello tienen que arriesgar sus datos cada vez que encienden el equipo O:-)

...

...

Componentes en mal estado, pues también.

No debería ser normal tener componentes en mal estado.

¿Por qué estos ejemplos que pones se consideran "normal" o aceptables? En un coche _NO_ son aceptables. Por lo menos nadie en su sano juicio conduce un coche cuyas ruedas están lisas sin dibujo o cuyos frenos no funcionen o se "cuelguen". Nadie compra pantalones rotos (bueno, a menos que sea la última moda y quieras ser la super-estrella ... nunca he entendido las modas). Nadie compra comida caducada. Nadie va a un dentista cuyas manos huelen a pie.

Esto es lo mismo. ¿Por qué en la informática es normal? ¿Por qué se acepta como normal que no haya SAI, que no haya backup, que las cosas se cuelgan? _NO_ señor.

Sí, son inventos hechos por Humanos y, por tanto, imperfectos por lo que tienden a fallar (de ahí los MTBF). Se acepta que haya un % de error. Pero es que en la informática se acepta un % de error enorme: es "normal" Y ESO QUE _TODO_ DEPENDE DE LA INFORMÁTICA (banca, sanidad, ...).

A ver. Te pongo el ejemplo del sector que conozco. Ingeniería y construcción. ¿Las casas se caen? Hombre, pues no es lo normal. ¿Pero _no_se caen? pues sí, pero se contruye con teniendo en cuenta (ni te imagians) una cantidad de variables no "precedibles" (no sabes cuándo) pero si esperables (vientos, tipo de sulo, tipo de construcción, zona sísmica, etc...).

Nadie espera un terremoto en Valencia, pero hace poco hubo temblores de escala 4. No pasó nada porque la normativa actual es bastante clara, cocisa y segura.

Yo espero lo mismo en informática, espero la misma fiabilidad y que que el hecho de apagar el sistema a lo bruto no termine en una pérdida de datos.

La parte por el todo no puede ser, no es de rigor. Los problemas hay que aislarlos y no pueden afectar a todo el conjunto, sólo, claro está, en casos extremos. Por ejemplo, si quito el pilar central de un edificio, con el tiempo y factores externos se acabará por derrumbar. Pero no compares quitar un pilar base con apagar el sistema de forma abrupta :-)

Uno sucede (o puede suceder) a diario y el otro no, es un caso aislado y extremo.

...

...

¿Y cómo debe actuar el sistema en esos casos? Fácil: problemas de hardware, debe registrar errores de acceso (lectura y escritura). Problemas más serios, pues también debería regsitrarlos.

1º Ver rollo que he escrito más arriba ;)

2º Se podrán registrar los errores que no bloqueen el sistema, que sean "normales", que sean previsibles ... pero los que no entran en esas categorías ... va a ser difícil.

Bueno, me refería a los errores de hardware más que de software. Obviamente, si el sistema deja de responder, también deja de responder la gestión de ¿casi todo? :-) No sé qué nivel o rango de acción tienen los desarrolladores del kernel en ésto, es decir, qué es registrable y qué no :-?

...

...

Si el usuario no tiene datos, no puede saber que hay un problema y no puede solucionarlo.

Pero si compras hardware (memoria RAM, por poner un ejemplo) malo y te falla (lo normal) ... ¿qué datos guardas si están todos corruptos o bien se han esfumado? Si la placa base es mala ... los datos que se transmiten pueden corromperse o bien un problema de tensión te puede dañar el disco de forma que NO puedes acceder al disco: ¿dónde guardo qué datos?

Ya, pero te das cuenta en el momento, lo cambias y listo. En cambio, un fallo del sistema de archivos que no escribe los datos porque se piensa que están escritos pero realmente no lo están (eso es lo que comentabas hace poco) pues te deja a dos velas: ademaś de perder datos, no sabes el alcance de esa pérdida, que puede hacerte que tengas que volver a instalar de nuevo porque el equipo se cuelga de manera inesperada (por ejemplo) cuando antes no lo hacía y no sabés el motivo (¿será por el problema que tuve al apagarlo a lo bruto aquél día o fallará la fuente, o quizá el disco duro tenga algún problema...?)

¡No sabes nada! Si al menos registrara los datos que elimina :-P

...

...

Si el sistema se cuelga, el sistema de archivos debería poder gestionarlo. Es un evento esperable, y tendrían que estar preparados para ese tipo de errores.

Si el cuelgue es por un módulo de RAM o controladora de disco defectuoso, ¿qué datos y dónde se guardan? Si el sistema de refirgeración del procesador es defectuoso y hace que el procesador realice cálculos erróneos, ¿me puedo fiar de ellos aunque los guarde?

Pero si los hoy en día los componentes funcionan sin electricidad :-P. Está la hibernación, la suspensión y seguro que habrá algún otro estado más de ahorro. El disco duro debería tener incorprado algún sistema de seguridad adicional. A ver, no te digo que haga milagros, pero si todos los componentes del equipo están en buen estado ¿por qué un simple apagón hace que pierdas datos? No sólo le puedes echar la culpa al hardware sino también a la gestión que hace el sistema con los archivos.

¿Qué tenemos, memoria ram? Pues que la usen, que el disco vuelque los datos a la ram (a modo de buffer) y que pueda recuperarlos y volver a escribirlos en disco antes de desecharlos y dejar el archivo a 0 bytes.

...

...

No te digo hace 30 años, pero hoy en día, pues sí.

No digo que estés equivocada. Lo que digo es que no es tan fácil como te imaginas/piensas.

No, supongo que no lo es, pero merece la pena mejorar la seguridad de los datos.

...

...

Se avanza mucho en hardware pero poco en software :-(

IMHO, se avanza demasiado y se asienta (aka depura y profile) poco :( Es decir, se introducen demasiadas novedades (¿features?) sin asentar y depurar las que ya existen.

Sí, cierto. Hay mucha cantidad y poca calidad. Y lo que es peor, en algunos casos se pierden funcionalidades.

...

...

Las cosas que no se pueden precedir, también se gestionan. Y eliminar datos del disco no es precisamente lo más deseable.

Pero es que a lo mejor esos datos nunca llegaron a disco, luego no estás eliminando los datos ... simplemente nunca existieron ;)

Pues que los pases a algún sistema secundario de almacenamiento :-P

...

...

¿Qué datos se eliminan y en base a qué? ¿Archivos de configuración de programas, archivos necesarios para el inicio del sistema? ¿Se elimina al azar, no hay prioridades? Una cosa así no puede quedar al libre albedrío :-/

En el caso que nos atañe (KDE pierde ficheros de configuración). No es que se produzca al azar, es que KDE lo ha hecho mal. Es decir, no crea un fichero temporal en el que guarda los datos y luego renombra. Si hiciera esto (crear un fichero temporal, borrar el original y luego renombrar), la probabilidad de pérdida de datos sería mucho menor. En este enlace lo explican mejor:

http://mjg59.livejournal.com/108257.html

Los archivos de configuración de kde es lo que ha visto, sencillamente porque lo ha ido a utilizar y le había desaparecido ¿pero... qué más se ha perdido? :-?

...

...

Si se puede apagar, se apagará. Hay que programar con esa premisa, pensando siempre en sucesos probables. Hardware en mal estado, apagones, bloqueos o cuelgues son variables "posibles".

Sí, son predecibles, lo malo es ¿cuándo se van a dar? Si se sabe el cuándo, se puede programar al sistema de ficheros o al kernel o al driver o a quien sea para que guarde los datos al disco o a dónde sea.

Por cierto, estoy de acuerdo contigo en que hay que mejorar el software.

:-)

...

...

Y de una buena programación. Ya te digo que de nada sirve prever y tener toda la seguridad si el sistema está mal diseñado porque no se ha previsto que el equipo se puede quedar colgado en cualquier momento. Y eso es algo que sucede a diario. No sabe "cuándo", pero se sabe "qué" y "cómo". Algo se podrá hacer para evitar esa pérdida de datos.

Para empezar, se puede intentar dirigir las medidas (inversión en desarrollo) a intentar evitar cuelgues porque el sw esté mal desarrollado. Pero esto no interesa: mola más añadir una nueva feature que depurar un driver (o una aplicación cualquiera). En cuanto a las empresas: tres cuartos de lo mismo, da más prestigio añadir una nueva funcionalidad que corregir cuelgues.

Como pasa con los controladores de las tarjetas gráficas, no importa que se cuelguen o rendericen el 2D a paso de tortuga con tal de que el juego de última hornada les dé un benchmark bueno para las revistas :-(

...

...

Puedo esperar perder datos si lanzo el equipo por la ventana, o si se quema en un incendio. Pero no espero perder datos si se va la luz :-)

Si se va la luz, hay que tener en cuenta una serie de cosas:

- es un evento impredecible en cuanto a cuándo se va a producir. Que se va aproducir: sí, alguna vez se tiene que dar, pero cuándo ... es difícil predecir

- la razón por la que se produce es impredecible también: ¿fenómeno atmosférico? ¿La señora de la limpieza ha desenchufado el servidor y ha enchufado la aspiradora? ¿El usuario ha pulsado el botón "sin querer"?

- el material informático es 100% DEPENDIENTE de la electricidad por lo que a nivel sw no hay nada que se pueda hacer, la solución TIENE que ser por hardware: baterías, por ejemplo. Por sw NO se puede solucionar ya que si falla la luz -> falla el hw -> falla el sw ya que el sw DEPENDE del hw que a su vez depende de la luz.*

* Por poner un ejemplo sencillo: una bombilla. Ya puedes tener el mejor de los filamentos o gas o lo que sea la bombilla que tienes que si se va la corriente ... adiós luz aka veo menos que un plátano liado en un trapo aka oscuridad. Es inmediato. Ahora diréis: "Ya, pero hay gases que permiten mantener una combustión durante X tiempo por lo que la luz (incandescencia) no desaparece de golpe y bla, bla, bla, ..." Esto es una solución hardware y sería similar a usar un SAI o una batería o un condensador o lo que sea, NO es una solución sw.

Es que en una bombilla predomina hardware, o la cambias o la cambias. Además, las de bajo consumo o las led duran más >:-)

...

Otro ejemplo: un coche. El conductor sería el sw, el coche el hardware y la gasolina la electricidad. Por muy buen conductor que seas, por muy previsor que seas, ... si pillas un bache y se te arranca el depósito de pronto (equivalente a se va la luz de pronto) o el motor se para. Sí, ya si vas cuesta abajo o vas a 270 KM/h no paras en seco, pero eso sería una solución HW (física, inercia) y no de sw (tu, conductor).

Pero si el coche hubiera tenido algún sensor inteligente que detecte el firme, el bache lo hubiera evitado o le hubiera avisado al conductor ("oye, que tienes un desnivel a tantos metros, activa los amortiguadores o reduce la velocidad...") >:-)

...

...

Las SSD basadas en DRAM tienen algunas ventajas.

Pero siguen DEPENDIENDO de la electricidad. Si falla la luz, es inmediato el fallo a menos que haya un HW por en medio que garantice cierta corriente (batería, por ejemplo). El sw no puede hacer nada porque es una capa superior que DEPENDE de las que hay abajo, por lo que si las de abajo fallan ... lo de arriba falla. Y si lo de abajo falla impredeciblemente ... lo de arriba no puede hacer nada.

Suspendes a ram o suspendes a "poner-aquí-X-componente-que-permita-almacenar-datos-para-luego-recueprar los" :-P

...

...

Este problema afecta a la mayoría de sistemas de archivo, así que nadie se libra, con empresa gorda detrás o sin ella.

Incluso afecta a sw que no es sistema de ficheros ;)

También :-)

...

...

No se puede precedir el factor tiempo (cuándo) pero sí qué es lo puede hacer (subir o bajar las acciones, si hará lluvia, sol o viento). Pero hay variables con las que sí se puede jugar. Sabes qué le puede afectar al sistema de archivos (apagón, bloqueo, hardarwe, componente lógico...) pues solucionemos las variables de las que sí tenemos información.

Pero es que lo que precisamente te interesa saber es cuándo para poder estar preparado en ese momento. Por ejemplo el tiempo, sé que va a llover (o al menos eso creo y espero ;), pero lo que me interesa saber es cuándo para saber si salir con paraguas o sembrar o ponerme chanclas o quedarme en casa y comprar un SAI por si cae un rayo y me estropea el ordenador ;)

Pues llevas siempre el paraguas encima :-P

...

En cuanto al ordenador, también: me interesa saber cuándo va a fallar el componente (sea hw o sw) porque ya sé que va a fallar, lo que no sé es cuándo. De ahí que haya cosas como SMART, redundancia, alta disponibilidad, disaster recovery, business continuance, ... De lo contrario (si supiéramos cuándo va a fallar), no nos haría falta todo eso, lo haríamos por sw ;)

Por cierto, sé que va a tocar la lotería, pero quiero saber cuándo y dónde ... para ir y comprarla !!!!

Como decía Niels Bohr: "Es difícl hacer predicciones, especialmente si son en el futuro" ;)

Si no compras lotería seguro que nunca te toca ;-)

Saludos,

-- Camaleón

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

El 2009-03-17 a las 17:57 +0100, Rafa Grimán escribió: (A ver cuándo llega este correo...)

El Tuesday 17 March 2009, Camaleón escribió:

...

Yo espero lo mismo en informática, espero la misma fiabilidad y que que el hecho de apagar el sistema a lo bruto no termine en una pérdida de datos.

Pero volvemos a lo mismo. Un apagón es inmediato: la RAM y la CPU se quedan sin electricidad instantáneamente por lo que los datos que contienen se pierden inmediatamente por lo que el propio sistema operativo "desaparece". Lo único que se puede hacer frente a un apagón es mitigarlo con baterías.

Bueno, ahora mismo es lo único que se puede hacer. Vale. Pero eso no significa que sea lo idóneo. Por ejemplo, al reiniciar el equipo tras un corte de corriente, el sistema de archivos podría contener los datos anteriores y posteriores al corte, ambos, para que decida el usuario qué información es la quiere mantener. Es decir, debería tener una especie de registro de transacciones (a modo de cvs) propio. "Hola $user, he detectado un corte en el suministro de energía. Dispongo de los últimos datos que se iban a escribir a disco, que son A y B. A se almacenó el día xx-xx-xxxx a la hora yy:yy, ocupa z bytes y B se almacenó el día xx-xx-xxxx a la hora yy:yy, ocupa z bytes. ¿Cuál quieres mantener?" Por ejemplo O:-)

...

Uno sucede (o puede suceder) a diario y el otro no, es un caso aislado y extremo.

Efectivamente, un pilar no es como cortar la electricidad. La electricidad es la base de todo. Es como quitar de golpe la planta baja entera (puertas, ventanas, tabiques, muros, pilares, muros de carga, suelo, ... TODO). ¿Qué ocurre? Se caen los pisos de arriba ya que no se sustentan. Si a un equipo le quitas de golpe la luz, lo que hay en CPU y en RAM desaparece instantáneamente y ¿qué hay en RAM y en CPU? El kernel, que es el que gestiona el sistema de ficheros. No se puede ejecutar NINGÚN comando, no se pueden guardar datos, entre otras cosas porque ya no hay datos que guardar, se han esfumado.

Pero desparece porque es un error que está "mal gestionado". De acuerdo que todos tienen su parte de culpa: sistema operativo, aplicaciones, sistema de archivos y hadware, pero el hecho de recurrir a un sistema de baterías para mantener el flujo de corriente para evitar una corrupción de los archivos que conlleve a la pérdida de datos en un equipo (estamos hablando de un sistema de baterías que tiene... pues no sé ¿cuántos años tiene el sistema de baterías modernas, actuales? según la wikipedia ¡¡más de 200 años!! :-O), pues eso, que no me parece loable.

...

Ya, pero te das cuenta en el momento, lo cambias y listo. En cambio, un fallo del sistema de archivos que no escribe los datos porque se piensa que están escritos pero realmente no lo están (eso es lo que comentabas hace poco) pues te deja a dos velas: ademaś de perder datos, no sabes el alcance de esa pérdida,

Pero eso no es culpa del sistema de ficheros ni del kernel, es culpa de los discos duros:

a) han avanzado tan poco que tienen que "aumentar" la velocidad con cachés (aka RAM)

b) aún así, siguen siendo tan lentos que los sistemas de ficheros necesitan implementar cosas como delayed allocation

c) el firmware del disco duro es el que engaña al sistema de ficheros "mintiendo" y diciendo que los datos están guardados

El problema no es el sistema de ficheros. De hecho, el sistema de ficheros (sea cual sea) lo ha intentado mitigar/corregir/disimular mediante técnicas que, si se usa hw malo o no se dispone de SAIs ... se va al garete todo lo que no ha sido guardado.

¡Pues mal hecho! No se puede esperar una instalación eléctrica perfecta ni unos componentes perfectos, porque no existen. Al menos en el mundo real. Así que los sistemas de ficheros deben adecuarse al mundo real, no a su "mundo ideal" porque los resultados son desastrosos :-) ¿Crees que un ingeniero construye sobre "supuestas situaciones ideales"? Al menos, los ingenieros tienen la obligación de avisarlo y documentarlo. "Este aparato está preparado para funcionar en tales condiciones ambientales, con un rango máximo de tantos grados Cº y un porcentaje de humedad relativa del tanto %. Cumple la normativa de seguridad 'x' que determina 'y'..." ¿Quién se responsabiliza de la pérdida de datos? ¿"Nadie"? Por eso a la informática aún le falta cierta "rigurosidad" que tienen otras disciplinas científicas >:-)

Puedes pensar: "hombre tampoco se pierde tanto rendimiento ni son tan lentos los discos". Pues te propongo una demo: monta tu sistema de ficheros como sync y luego me cuentas. Verás lo que es la desesperación. Y eso que sigues usando la caché del disco duro, si encima la deshabilitas para poder garantizar la escritura a disco ... te veo en un charco de lágrimas.

Pues no lo he probado, la verdad :-?

...

¡No sabes nada! Si al menos registrara los datos que elimina :-P

Pero es que no es el sistema de ficheros, es el disco duro, es el hardware (bueno, el firmware de los discos duros) el "culpable". Si los discos fueran la décima parte de rápidos que la RAM, te aseguro que estos problemas no ocurrirían y que los sistemas de ficheros no implementarían estas técnicas. Pero como los fabricantes de discos duros no han avanzado NADA ... pues es lo que hay.

Por mucho que el sistema de ficheros implemente sync a disco y las aplicaciones un fflush() o fsync() o cualquier otra función, la caché del disco duro sigue allí y el firmware sigue funcionando de dicha manera. NO hay forma de garantizar la escritura a disco si se tiene la caché activada. Como dijo Carlos, falta algún tipo de comunicación entre firmware del disco y sistema operativo que te garantice que el dato se ha escrito a disco físicamente. Poder se puede hacer, pero te tira el rendimiento por debajo de los suelos. Probad lo que os he comentado de montar con sync.

Que garantice la escritura y que lleve un registro de las transacciones... ¿no hay ningún estándar definido para ésto?

Aún me acuerdo los gritos que dió la gente cuando SUSE 10.2 (o fue la 10.1) montaba los USB como sync. ¡¡¡ Y eso que eran USB !!! Que son más rápidos que un disco duro.

Sí, recuerdo mensajes de la lista con problemas en las llaves usb, que se ralentizaba la copia de archivos. Pero... ¿USB más rápido que un disco duro? :-? Si tienen que hacer la conversión de ide/ata o sata a usb ¿no?

...

Pero si los hoy en día los componentes funcionan sin electricidad :-P. Está la hibernación, la suspensión y seguro que habrá algún otro estado más de ahorro.

Siguen consumiendo energía y en los casos que no se consume, se guarda el estado en un fichero (swap) y no es un proceso inmediato.

Pues debería serlo >:-P

...

El disco duro debería tener incorprado algún sistema de seguridad adicional. A ver, no te digo que haga milagros, pero si todos los componentes del equipo están en buen estado ¿por qué un simple apagón hace que pierdas datos? No sólo le puedes echar la culpa al hardware sino también a la gestión que hace el sistema con los archivos.

Sí puedes porque (en el caso de los discos duros), el último responsable es el disco duro: su lentitud ha dado lugar a que se hagan estas "chapuzas".

Pero no se puede desarrollar ignorando ésto: si el hardware (en este caso, los discos duros) tienen esa limitación, no se puede pasar por alto. La fiabilidad e integridad de los datos es importante.

...

¿Qué tenemos, memoria ram? Pues que la usen, que el disco vuelque los datos a la ram (a modo de buffer) y que pueda recuperarlos y volver a escribirlos en disco antes de desecharlos y dejar el archivo a 0 bytes.

Sí, pero si se va la luz, TODO lo que hay en RAM se desvanece en tiempo real ;) Para luchar contra la pérdida de luz sólo hay soluciones hardware: pilas o baterías, como lo quieras llamar o similares.

Bueno... cuando la luz se va y el reproductor del dvd se para, al menos no "pierde" el disco :-P

Para luchar contra los problemas de los discos duros, lo único que se puede hacer hasta ahora es lo que se ha hecho al diseñar sistemas de ficheros.

Que es no tener la certeza de que los datos se han escrito y darlo por válido... con lo cual terminas por perder información.

Para luchar contra corrupción de datos por fallos en la CPU o en el disco, lo único que se puede hacer es CRC y similares

Eso sí :-)

...

Pues que los pases a algún sistema secundario de almacenamiento :-P

Caché/buffer ;)

La cosa, en el caso de los discos duros, es la velocidad penosa que tienen. Te pongo un ejemplo. En el mundo de media, de BBDD en tiempo real y de HPC (sí, incluyendo CAD/CAM/CAE ~ manufacturing). Cuando se requiere un ancho de banda determinado y garantizado ... hay veces que se llegan a poner 20 veces más discos de los necesarios porque si no lo haces ... simplemente no das el rendimiento.

(...)

El disco duro es el gran lastre de la informática :(

Computación distribuida... al menos para los ejemplos de las cantidades "mostruosas" que has puesto ;-) 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

Bueno, quizás para aplicaciones profesionales habría que usar ordenadores en lugar de PCs grandes. No se si existen, igual no tienen mercado, Rafa sabrá mas que yo. Pero desde el punto de vista electrónico, no hay ningún problema excepto el coste en hacer un ordenador inmune a los cortes de red. Mucha Ram con Batería( ojo el consumo de una CMOS estática es muy bajo), una buena NMI para detectar el fallo de alimentación y unos buenos condensadores en la F.A. para permitir guardar todo en la RAM CMOS. Los discos, pueden tener algo parecido, solo es un problema de precio, pero en eso quizás podría ayudar un buen S.O. que verificase al volver la alimentación. Hay cosas irrecuperables, pero pocas, por ejemplo un corte de red a mitad de la grabación de un CD. El resto es un problema de mercado y de presupuesto. -- Saludos Lluis

Hola :) El Thursday 19 March 2009, Carlos E. R. escribió:

El 2009-03-18 a las 21:13 +0100, Rafa Grimán escribió:

...

...

Para serlo, se debería hacer un sync a disco en cada escritura y eso es eterno. Es algo que no se pueden permitir determinados mercados y que el 99.999999999999999% de los usuarios si lo sufren ... dejan de usar un ordenador por la lentitud. Ten en cuenta que no es una única aplicación la que estaría haciendo sync a disco, piensa en todas las aplicaciones que lanzas y usas simultáneamente.

No es sync lo que se necesita, sino transacciones ordenadas, con barreras. Es decir, mandar una secuencia de operaciones de disco y garantizar que no se hace una hasta que la anterior está terminada - y eso no es posix -. Lo del enlace que pasaste el otro día. Es decir, otro API.

Mandar un sync continuamente es una barbaridad - salvo que puedas mandar un sync de un fichero determinado, de una operación de disco concreta, no de todas.

Ya, pero lo que quería reflejar es la velocidad del disco y lo que supondría eso en rendimiento. Los sistemas de ficheros modernos usan delayed allocation por lo que dejan todo en RAM hasta que tienen programado hacer el sync, en cuyo momento envían todo al disco (luego, lo que haga el disco con los datos es desconocido). El delayed allocation es lo que provoca este tipo de pérdida de datos (lo que le pasó al colistero con los ficheros de configuración de KDE). Si quieres evitar delayed allocation -> tienes que pasar por el sync. A menos que, como dices, se dearrolle una API o bien (IMHO es una solución mejor) saquen un nuevo dispositivo de almacenamiento más rápido y fiable.

...

...

Pero no se puede desarrollar ignorando ésto: si el hardware (en este caso, los discos duros) tienen esa limitación, no se puede pasar por alto. La fiabilidad e integridad de los datos es importante.

Ya, pero dile a un banco, a un hospital, a una televisión, ...: "Ná, esperate un rato que esque cada vez que se guarda un fichero, se hace sync a disco". Por experiencia, te puedo decir a dónde te mandan ;) Haz la prueba de trabajar con los sistemas de ficheros montados con sync y, si tienes tiempo, monta un SAMBA/NFS y haz lo mismo ... a ver cuánto tiempo tarda en responder el servidor.

...

:)

Yo te lo puedo decir, porque recuerdo el comportamiento del disco en msdos, y recuerdo la diferencia cuando inventaron el caché de escritura.

¿Echas de menos esas velocidades? ;)

...

...

...

hardware: pilas o baterías, como lo quieras llamar o similares.

Bueno... cuando la luz se va y el reproductor del dvd se para, al menos no "pierde" el disco :-P

Porque los datos están en un soporte que no se borra. Si sustituyes el DVD por un módulo de RAM, verás como los datos no siguen allí ;)

Si la RAM son ferritas, no se borran al apagar :-P

Pos ná ... a usar ferritas ;) Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- 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

Hola :) El Tuesday 17 March 2009, Shinji Ikari escribió:

Meh... bueno no se si estará bien que me meta en este hilo, considerando que mi conocimiento respecto a sistemas críticos o sistemas de negocios es null. Pero vale, fuerzas de flaqueza.

No te preocupes que todo el mundo tiene derecho a opinar ;)

On Tuesday 17 March 2009 08:16:14 Camaleón wrote:

...

El 2009-03-17 a las 13:13 +0100, Rafa Grimán escribió:

...

...

...

El Tuesday 17 March 2009, Camaleón escribió:

Por eso mismo. Que el sistema se cuelgue, es normal.

Pero _NO_ debería serlo.

No, claro, pero sucede.

¿Que sucede? ¿Los cuelgües? Es como pensar que el trabajador va a poder asistir todos los días a trabajar sin falta, sin enfermedad o problemas. Estamos en un mundo donde perfección es variable. =P

Cierto, pero me refería a que en la informática es demasiado habitual :(

...

...

...

Que haya apagones, también. Que no haya un SAI, también.

No debería ser normal no tener un SAI.

Hombre, no todos tienen los recursos necesarios para tenerlo y no por ello tienen que arriesgar sus datos cada vez que encienden el equipo O:-)

Vale, hay muchos que no los tienen, pero si aprecian su información y sus equipos deberían pensar en adquirirlos. Las utilidades que se les paga a los accionistas tienen poco valor para el crecimiento de la empresa. Inversión señores, inversión.

Eso es lo que hace falta. [...]

...

Yo espero lo mismo en informática, espero la misma fiabilidad y que que el hecho de apagar el sistema a lo bruto no termine en una pérdida de datos.

Eso se lo puede pedir a empresas grandes que garantizan sus soluciones, HP, IBM. Si recuerda, hace un tiempo atrás pasé una página web con vídeos donde prueban equipos. HP probó sus equipos contra disparos y una explosión (supuestamente recuperaron toda su información y se supongo minimizaron perdidas por la interrupción). No tengo idea de como serán esos contratos, tal vez el Sr. Griman pueda comentar al respecto, pero... me atrevo a considerar que perdidas por error en el sistema se menciona y la empresa prestadora no se hace responsable.

Eso son contratos muy personalizados porque claro, puede pasar que haya un terremoto y se hunda el edificio entero. Son contratos muy complicados en el que los abogados de ambos lados se tiran hablando mucho tiempo.

...

La parte por el todo no puede ser, no es de rigor. Los problemas hay que aislarlos y no pueden afectar a todo el conjunto, sólo, claro está, en casos extremos. Por ejemplo, si quito el pilar central de un edificio, con el tiempo y factores externos se acabará por derrumbar. Pero no compares quitar un pilar base con apagar el sistema de forma abrupta :-)

¿hmm? No conozco de sistemas que se autocorrijan, ¿y cuanto cuestan? =P Ni siquiera el cuerpo humano es inmune. Si se enferma una parte, el resto es afectado, sea por como es el sistema o la especialización y dependencia de cada parte.

Tome en consideración también que si retira o se encuentran fallos en la columna principal del edificio que menciona, el ente encargado de las construcciones lo califica como no habitable. Tal vez pueda resistir otro sismo, u desastre o que sea utilizado, pero... ¿se arriesgaría? =P~

Buen punto, en onformático no existe esto (al menos que yo conozca). No hay una entidad certificadora que garantice un nivel determinado de calidad. Bueno, sí hay estándares y cosas, pero todos sabemos cómo se cumplen ;) [...]

Según recuerdo Linux es un OS que por su construcción no es afectado por errores en las aplicaciones que se ejecutan sobre el. Aunque es una frase algo ligera, pues ya se han mencionado varios bugs existentes en los sistemas de archivos, que pueden causar problemas graves. =/ Nos acercamos peligrosamente a la paranoia. =P

Una pequeña aclaración: un sistema de ficheros es parte del kernel, no es una aplicación ;)

...

...

...

Si el usuario no tiene datos, no puede saber que hay un problema y no puede solucionarlo.

Pero si compras hardware (memoria RAM, por poner un ejemplo) malo y te falla (lo normal) ... ¿qué datos guardas si están todos corruptos o bien se han esfumado? Si la placa base es mala ... los datos que se transmiten pueden corromperse o bien un problema de tensión te puede dañar el disco de forma que NO puedes acceder al disco: ¿dónde guardo qué datos?

Ya, pero te das cuenta en el momento, lo cambias y listo. En cambio, un fallo del sistema de archivos que no escribe los datos porque se piensa que están escritos pero realmente no lo están (eso es lo que comentabas hace poco) pues te deja a dos velas: ademaś de perder datos, no sabes el alcance de esa pérdida, que puede hacerte que tengas que volver a instalar de nuevo porque el equipo se cuelga de manera inesperada (por ejemplo) cuando antes no lo hacía y no sabés el motivo (¿será por el problema que tuve al apagarlo a lo bruto aquél día o fallará la fuente, o quizá el disco duro tenga algún problema...?) ¡No sabes nada! Si al menos registrara los datos que elimina :-P

¿Un equipo que vigila el sistema central o que almacena los logs del sistema?

Syslog (y variantes -ng) permiten esto, lo malo es que si se produce un corte de luz ... no hay nada que loguear porque no hay datos. Si hay un cuelgue, el syslog no puede escribir porque se ha colgado el sistema :(

Alguien pregunto al respecto de eso hace un par de años creo... o fue el año pasado. Sin embargo cual es el problema, ¿tener un rápido diagnostico? o ¿no tener perdida de datos? solución vs consecuencia.

Bueno cabe insistir que de estos sistemas se poco o nada, sin embargo creo que esta discusión es nada nuevo y se ha presentado con anterioridad en otro lugar y en otro medio, por tanto debe de haber soluciones que, si bien no son perfectas, minimizan perdidas. Si alguien las conoce, que las mencione y si puede brindar algún enlace con la información, enhorabuena. Y si incluye el costo de estas, mejor aún.

Para minimizar péridadas o probabilidades, tienes SAI, redundancia, alta disponibilidad, disaster recovery, business continuance. [...]

=( Pero ya se mencionó lo del SAI y supongo que el sistema esta conectado al SAI y conoce cuanto jugo queda en caso de haber un corte de energía, se apagará adecuadamente y se grabará la información. Pero si el disco duro se "malea" de la nada. Pues hay sistemas contra eso ¿no?

Tienes RAID, pero no protege frente a todo. A parte de la pérdida de datos por la pérdida de caché, hay otro error que aparece en los discos duros (que no recuerdo cómo se llama) en el que un bit se cambia sólo (si era 1, pasa a 0 y a la inversa). Esto se debe a que son bloques inmantados muy sensibles y las corrientes eléctricas o campos electromagnéticos y pueden producir estos "flips" de bits. Si esto se produce una vez escrito el dato en el platter, el bit de paridad ya estaba escrito para el dato original por lo que el RAID no detecta estos errores ... volvemos a los CRCs, por ejemplo, para garantizar que el dato es el que se había escrito originariamente.

...

¿Qué tenemos, memoria ram? Pues que la usen, que el disco vuelque los datos a la ram (a modo de buffer) y que pueda recuperarlos y volver a escribirlos en disco antes de desecharlos y dejar el archivo a 0 bytes.

O.O? y si la memoria esta llena. =P Ya comenzamos a dar vueltas en circulo.

;)

...

...

...

No te digo hace 30 años, pero hoy en día, pues sí.

No digo que estés equivocada. Lo que digo es que no es tan fácil como te imaginas/piensas.

No, supongo que no lo es, pero merece la pena mejorar la seguridad de los datos.

Eso lo consideran ustedes los SysAdmins en el diseño de los sistema. ;P

Sí, pero el cliente o el jefe piensa^H^H^H^H^H^H opina que eso es muy caro y no se implementa y, al perder los datos, la culpa es nuestra.

...

...

...

Se avanza mucho en hardware pero poco en software :-(

IMHO, se avanza demasiado y se asienta (aka depura y profile) poco :( Es decir, se introducen demasiadas novedades (¿features?) sin asentar y depurar las que ya existen.

Sí, cierto. Hay mucha cantidad y poca calidad. Y lo que es peor, en algunos casos se pierden funcionalidades.

¿windows?

¿Cómo es que has pensado en Windows? ;) [...]

¿Hay algún log donde se pueda ver los accesos y cierres de archivos?

Que yo sepa no, puedes usar comandos como lsof o strace para ver qué ficheros se están usando. [...]

...

...

...

Las SSD basadas en DRAM tienen algunas ventajas.

Pero siguen DEPENDIENDO de la electricidad. Si falla la luz, es inmediato el fallo a menos que haya un HW por en medio que garantice cierta corriente (batería, por ejemplo). El sw no puede hacer nada porque es una capa superior que DEPENDE de las que hay abajo, por lo que si las de abajo fallan ... lo de arriba falla. Y si lo de abajo falla impredeciblemente ... lo de arriba no puede hacer nada.

Suspendes a ram o suspendes a "poner-aquí-X-componente-que-permita-almacenar-datos-para-luego-recueprar los" :-P

=P~ Nuevamente, ¿cuanto está dispuesto a pagar por esa solución? y recuerde que el espacio también cuesta.

Gracias por recordarlo, el espacio y el consumo son dos factore muy preocupante en los CPDs actualement :( [...]

Yo espero que no se hayan aburrido y creo que definiendo bien el problema y conociendo las soluciones que minimicen los problemas no harán hígado ni les explotará la cabeza cuando pierdan archivos. Tampoco les dará paro cuando les llegue la cuenta del mes. ;P

;) Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- 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

Y yo he trabajado con un ordenador de alta disponibilidad y alta fiabilidad con redundancia total de componentes. Ese hardware tiene la capacidad de hacerse autodiagnósticos y reportar sus propios errores. Donde trabajas? En la NASA?Ya me gustaria poder ver alguno de estos equipos

Alguna vez he comentado de una empresa británica que hace software certificado 100%. Es carísimo, pueden tardar un par de años antes de escribir una sola línea de código. Son programas relativamente pequeños, como el núcleo de autenticación de tarjetas de créditos.

Segun tengo entendido hay metodos matematicos para validar los algoritmos ya no solo en terminos de eficiencia sino en terminos de que no habra fallos -- 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

El Jueves, 19 de Marzo de 2009 01:19:15 Carlos E. R. escribió:

Content-ID:

El 2009-03-18 a las 20:46 +0100, Rafa Grimán escribió:

...

El Tuesday 17 March 2009, Shinji Ikari escribió:

...

...

¿hmm? No conozco de sistemas que se autocorrijan, ¿y cuanto cuestan? =P Ni siquiera el cuerpo humano es inmune. Si se enferma una parte, el resto es afectado, sea por como es el sistema o la especialización y dependencia de cada parte.

En cierto modo pensamos del cuerpo humanso que es imperfecto pues enferma y envejece, pero desde el punto de vista global esta diseñado para que se degrade con facilidad ¿no? Aqui la fiabilidad es a nivel de especie quizas donde el genoma se tranfiere en el acto reproducitvo y (nuestro genoma cultural) se tranfiere mediante tradicional oral, escrita, cibernetica etc.. Como dicen la gente del erlang: La fiabilidad y la disponiblidad empiezan con dos nodos Yo la unica cosa que he visto fiable a es la hipoteca, no hay quien se la quite de enmedio... Salu2

Si los hay.

Por ejemplo, la lanzadera espacial usa ordenadores por triplicado, y tienen que coincidir en sus decisiones o se aborta el despegue.

Y yo he trabajado con un ordenador de alta disponibilidad y alta fiabilidad con redundancia total de componentes. Ese hardware tiene la capacidad de hacerse autodiagnósticos y reportar sus propios errores.

Sí hay cosas que se puedan hacer. Pero no es barato.

...

...

Tome en consideración también que si retira o se encuentran fallos en la columna principal del edificio que menciona, el ente encargado de las construcciones lo califica como no habitable. Tal vez pueda resistir otro sismo, u desastre o que sea utilizado, pero... ¿se arriesgaría? =P~

Buen punto, en onformático no existe esto (al menos que yo conozca). No hay una entidad certificadora que garantice un nivel determinado de calidad. Bueno, sí hay estándares y cosas, pero todos sabemos cómo se cumplen ;)

Alguna vez he comentado de una empresa británica que hace software certificado 100%. Es carísimo, pueden tardar un par de años antes de escribir una sola línea de código. Son programas relativamente pequeños, como el núcleo de autenticación de tarjetas de créditos.

...

...

¿Un equipo que vigila el sistema central o que almacena los logs del sistema?

Syslog (y variantes -ng) permiten esto, lo malo es que si se produce un corte de luz ... no hay nada que loguear porque no hay datos. Si hay un cuelgue, el syslog no puede escribir porque se ha colgado el sistema :(

Na... Contrata unos cuantos ingenieros Cylones (Battlestar Galactica (reimagined): cuando los matas vuelcan su memoria en la nave resurrección, y les dan un nuevo cuerpo con toda su memoria intacta >:-)

Tecnológicamente sí es posible hacer sistemas (discos) que guarden toda la información en curso, completa, hasta el instante de pérdida de energía. Basta con que el disco tenga una memoria de transacciones completa con backup de pila, con un procesador que guarde toda esa info en el disco cuando vuelva la energía.

Y el proceso también se podría hacer con la ram del sistema.

En teoría, claro.

El truco es programar por transacciones completas por etapas: cada etapa no responde OK a la etapa anterior hasta que pueda garantizar que los datos se han transferido por completo y que están asegurados.

Ojo: no vale decir "ya los tengo". Tienes que tenerlos de verdad, como si fuera correo certificado: has firmado su recepción, luego _ya_ es tu problema.

El correo electrónico (smtp) funciona así, en teoría: cada servidor envía al siguiente, el cual confirma cuando tiene los datos a salvo, y es entonces cuando el anterior borra el correo. Se supone que la partición /var/mail está montada "sync", por lo cual es más lenta que las demás particiones - y de paso, es el motivo tradicional para que los administradores se cabreen al recibir correos de un mega o más, puesto que el disco es "sync" y muy lento.

...

...

¿Hay algún log donde se pueda ver los accesos y cierres de archivos?

Que yo sepa no, puedes usar comandos como lsof o strace para ver qué ficheros se están usando.

Algunas veces interesaría un log de apertura/cierre de ficheros, quizás mandados por red a otro ordenador. Permitiría descubrir algunos problemas puñeteros.

-- Este correo no tiene dibujos. Las formas extrañas en la pantalla son letras. __________________________________________ Clist UAH a.k.a Angel __________________________________________ Sex is a battle, love is war. -- 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

Hola :) El Tuesday 17 March 2009, Camaleón escribió:

El 2009-03-17 a las 13:13 +0100, Rafa Grimán escribió:

...

Hola :)

He intentado enviar el mensaje de respuesta a la lista pero lo rechaza (creo, porque no recibo nada pero tampoco aparece en el archivo).

Te envíe copia CC a tu dirección, si no lo has recibido, avisa :-)

Creo que los correos han llegados :) Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- 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

Hola :) El Tuesday 17 March 2009, Carlos E. R. escribió:

El 2009-03-17 a las 11:48 +0100, Camaleón escribió:

...

...

de las cachés de los discos duros. Carlos propuso ideas buenas (baterías, CRCs, funciones, ...), la cosa ahora depende de: - roadmaps - inversión - interés - nuevas tecnologías (aka discos SSD) - ...

Y de una buena programación. Ya te digo que de nada sirve prever y tener toda la seguridad si el sistema está mal diseñado porque no se ha previsto que el equipo se puede quedar colgado en cualquier momento. Y eso es algo que sucede a diario. No sabe "cuándo", pero se sabe "qué" y "cómo". Algo se podrá hacer para evitar esa pérdida de datos.

Puedo esperar perder datos si lanzo el equipo por la ventana, o si se quema en un incendio. Pero no espero perder datos si se va la luz :-)

Se puede esperar que los datos del ultimo segundo se pierdan. Lo que no se puede esperar es que se pierdan datos de hace un minuto.

Si la aplicación no envía la señal de guardar ... sólo está en memoria el fichero por lo que sí se puede perder todo. Esto, parece ser, es lo que le ocurre a KDE. KDE parece ser que da por hecho que tienes SAI, hardware decente, ... y que sabes lo que haces ;) Por eso modifica ficheros de configuración y no los guarda a disco hasta que cierras la sesión. ¿Error de programación? Posiblemente. ¿Confianza en que los usuarios tienen hw en condiciones? Posiblemente. ¿SW complejo con muchas dependencias y puede fallar cualquiera en cualquier momento? Puede. Más o menos lo que habemos dicho en los correos anteriores: - invertir más (tiempo, dinero y ganas) en mejores programas - depurar más - hacer más profiling - invertir en hw correctamente* Hablando de programación: ahora la cosa se complica aún más porque como los PCs tienen múltiples núcleos, se está empezando a implantar la programación paralela (sea multihebra o no) y eso es MUUUUUUUUYYYYYYY complicado. Así que id preparando los Kleenex, que va a haber mucho lloro. * correctamente no significa caro. Significa: si no vas a trabajar en 3D, manufacturing o juegos, cómprate un SAI en vez de una tarjeta 3D de última generación, por ejemplo.

Y sí, sí se pueden evitar perdidas si se hacen bien las cosas y se garantizan los pasos. Si el sistema le pasa unos datos al disco, y este reponde que los ha grabado bien, debe responsabilizarse de ellos así arda Troya. Sin excusas.

Efectivamente, pero eso no ocurre :( Como eso no ocurre, buscas alternativas como deshabilitar cachés.

Y si hay un error a posteriori, debe indicarselo al sistema operativo, a posteriori... y sí, sé la barbaridad que acabo de decir.

No lo veo una barbaridad. Si hay éxito o error: avisar después de haber completado la operación. Esto tiene un problema: el disco es MUY lento y determinados procesos no se pueden permitir ese retardo. Por ejemplo: vídeo en tiempo real.

...

...

Y no dar tanta importancia a las fechas. Gentoo, Debian, Slackware y otras no se dejan llevar tanto por la fecha de release sino más bien por su estabilidad y fiabilidad. Sí, ya sé: - no hay una empresa por detrás y, por tanto, no hay intereses económicos por lo que se pueden tomar el tiempo que les dé la gana - no son distros para el usuario casero que exige novedades cada X tiempo. No estoy muy de acuerdo con esto, conozco muchos usuarios que lo que quieren es que funcione y les da igual si hay o no novedades - también han tenido sus problemas - nadie es perfecto ;)

Este problema afecta a la mayoría de sistemas de archivo, así que nadie se libra, con empresa gorda detrás o sin ella.

En el mundo del software libre existe el problema de la falta de interés en resolver determinados problemas, aunque el bug esté documentado. En teoría cualquiera puede meterse y hacerlo, en realidad no es así.

Lo malo es tener los conocimientos y lo segundo es tener ganas. Como he dicho en un post anterior, lo que da estatus es añadir nuevas características, corregir errores no da caché :(

Una pieza de software usado por gente puede de repente quedarse sin mantenedor y dejar en la estacada a sus usuarios, que no necesariamente tienen los conocimientos (ni los recursos) para seguir manteniendolo.

Estoy pensando en reiserfs, por ejemplo.

Selección natural ;) Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- 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