Hola :) On Friday 24 July 2009 21:51:58 Camaleón wrote:
El 2009-07-24 a las 21:11 +0200, Rafa Grimán escribió:
On Friday 24 July 2009 20:19:11 Camaleón wrote:
Hoy por hoy, con la tecnología y conocimientos que tenemos no se puede hacer otra cosa: o sacrificas velocidad o sacrificas datos (vidas en el caso del coche). En ambos casos la sociedad ha decidido sacrificar datos (vidas), ¡pero que no le quiten la velocidad!
Debido a esto, hay que hacer workarounds: cachés, baterías, ... Que, en el caso del coche, son cinturones, airbags, ...
Bueno, precisamente en los coches siguen intentando mejorar sus carencias que son, casualmente, hacerlos inmunes a las burradas que hacen los conductores (que en la analogía con los discos duros y los sistemas de archivos son los usuarios).
Sip usuario = conductor. Y en el diseño y desarrollo de sistemas de ficheros también se intentan mejorar (copio y pego lo que has escrito "hacerlos inmunes a las burradas que hacen los conductores"). Ni en un caso (coches) ni en otro (sistemas de ficheros) se ha conseguido resolver nada.
Hombre, algo sí ha mejorado, en los coches, digo :-P.
¿No hay menos accidentes con resultados de muerte? :-?
Para las mejoras, leyes, concienciación, ... introducidas, no (MHO).
Y lo hacen añadiendo sensores de todo tipo: paradas automáticas en caso de peligro de colisisón, redireccionamiento automático para evitar una salida de pista, se aparcan de manera automática, lo despierta si detecta que se está durmiendo o que pierde la concentración, vamos, que el usuario es el primer "enemigo" que tiene la carretera, así que, dejemos que los sistemas computerizados se encarguen... de todo.
Dentro de poco hasta conducirán solos.
Lo mismo hacen con los sistemas de ficehros: [B|B+|H]-Trees, checksums, herramientas de depuración (xfs_db, xfs_io, ...), fscheck, ...
Pero no resulta efectivo. O no todo lo que debería.
Igual que en los coches :(
Es decir, el sistema de archivos no puede depender de lo que el usuario crea que es lo mejor (sai, controladora raid con batería, etc...) ni de pensar que se encuentra en un entorno "óptimo" de funcionamiento. Eso son entornos utópicos, irreales, que se dan en un porcentaje muy bajo :-)
El sistema de ficheros no depende de lo que el usuario crea que es mejor, de hecho tiene las herrmaientas/features que he comentado anteriormente como "medida de seguridad", que a eso le añades/aconsejas el uso de SAI, baterías, ... mejor que mejor. Es como el coche:
- lleva los airbags, cinturones, ... (features implementadas en el propio fs como xfs_db, checksums, ...)
- y además, te recomiendan que no bebas, que no fumes, que no toquitees el navegador, ... (SAI, baterías, ...)
Entonces, ¿de qué depende para que sea más fiable ante imprevistos?
Si lo supiera no estaría aquí, estaría ganando minolles y minolles !!!! Ahora en serio, hay de todo: hardware, electricidad, ...
Las de Intel tienen un MTBF de 2 millones de horas. Creo que eso es más que cualquier disco duro convencional.
En discos enterprise tienes ese MTBF, por ejemplo, Seagate te pone a partir de 1.6 millones de horas. Cuando veas MTBF en HDD que no llegan al millon de horas ... eso son discos no eterprise. Voy a buscar cuál es la "definición" o separación entre unos y otros porque no me acuerdo, creo que estaba por encima del millón pero no me hagas mucho caso porque es de memoria.
Hum... no sabía que había un número determinado para catalogarlos en uno u otro bando :-)
Sip, pero no me sé el número 0:)
Y ojo, no es sólo el MTBF, sino el número de escrituras soportadas. El # de escrituras soportadas es muy bajo:
http://blog.enterprisestoragesense.com/category/mtbf/
Copio y pego un párrafo, epro es interesante leer desde el párrafo 3, donde se explica lo del # de escrituras.
"As an example, a well-known supplier of SSDs advertises an ECC that corrects up to 8 bytes in 1024 bytes, while another supplier advertises 6 bytes in 528 bytes. At the same time, both talk about program erase/write cycles well in excess of 1 million. However, tests show that both ECC levels would frequently result in non-recoverable errors after as few as 200,000 write/erase cycles. These error rates result in SSD reliability falling far short of disk drive reliability in terms of non-recoverable error rate. At the same time, overall capacity begins to erode and eventually falls below the device specification, resulting in an MTBF failure."
200k write/erase cycles para una BBDD es nada. Un servidor de ficheros (depende de la tralla que le des) posiblemente tenga muchos menos IOPS por loq ue el SSD sobreviva más. Calcula los IOPS que hacen tus máquinas y luego haz la regla de 3 a ver cuánto te dura cada celda del SSD.
Hum... tampoco sé si eso es lo mismo que comentan en las SSD de Intel. Pongo la hoja de datos del producto de donde estoy sacando la información:
*** Intel® X25-E Extreme SATA Solid-State Drive http://download.intel.com/design/flash/nand/extreme/319984.pdf
Write Endurance 32 GB drive supports 1 petabyte of lifetime random writes and 64 GB drive supports 2 petabyte of lifetime random writes. ***
Qué tíos. Los "random writes" no es lo mismo porque son escrituras al azar en el disco. En el otro caso a lo que se refieren es a 200k escrituras/modificaciones/borrados en la misma cleda. Obviamente, escribir 2 PB en celdas al azar no es lo mismo que escribir 200k veces en la misma celda.
En fin, no sé. No me suelo fijar en esos datos de manera tan detallada, pero no parecen malas cifras... ¿o sí? :-?.
Como todo, depende. 200k modificaciones en una BBDD con tráfico es quemar una celda en un par de días o menos. Si haces streaming de vídeo, es como decir que la celda te va a durar toda la vida porque al hacer streaming, lo que haces son lecturas (no se hacen modificaciones=escrituras) de la celda. En el mundo HPC donde tengas muchos IOPS (creo que algunas aplicaciones de CFD) las celdas te duran un abrir y cerrar de ojos. Lo más sencillo es hacer la regla de tres con el # de IOPS que hace tu aplicación o que sufren tus discos. Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org