-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
Hola :)
El Tuesday 30 December 2008, Carlos E. R. escribió:
El 2008-12-30 a las 04:08 +0100, Rafa Grimán escribió:
En el caso de RAID por sw no lo he probado nunca, pero si son particiones de discos, puedes usar:
blockdev --rereadpt
para releer la tabla de particiones después de particionar. Mira a ver si te vale.
Podría ser... pero no tiene importancia, ya rebotaré cuando pueda. Es habitual cuando particionas que el fdisk se queje: informa al kernel de que ha hecho cambios en la tabla, y a veces se queja de que ha fallado y que necesitas rebotar.
Este comando debería valer porque informa al kenrel de la nueva tabla de particiones, claro que con RAID no sé si se comportará igual.
Pero se supone que el fdisk intentó esa operación y le falló. O eso dijo. Bueno, probaré ese comando, pero cuando no tenga cosas que escriban a disco en ejecución, por si las moscas.
De todas maneras, particionar un RAID no es algo habitual. Ten en cuenta que si te falla un disco del RAID, se verán afectas todas las particiones del RAID que se encuentran en ese disco por lo que es peor el remedio que la enfermedad.
Bueno, vale, pero es que tu te mueves en una liga distinta ;-)
No me refería tanto al tamaño del RAID o el número de discos 0;) Me refería a que cuando se hacen ciertas configuraciones hay que tener en cuenta las consecuencias de si algo falla. Tenemos un cliente que tiene el disco del sistema de la siguiente forma: sda1 sda2 sda3 sdb1 sdb2 sbd3
sda1 y sb1 son un sw RAID 1. sda2 es un "dd" de sda1 antes de aplicar actualizaciones y sdb2 es un "dd" de sda1 después de aplicar una actualización. Creo que sda3 era una imagen del sistema original y sdb3 era otra instalación.
Vamos que el tío quiere protegerse de "cualquier" fallo, cosa que es imposible, pero bueno es lo que él diseñó y es lo que le tranquiliza.
Bueno, tiene cierto sentido. Yo he visto sistemas parecidos en los ordenadores que controlan las macrocentrales telefonicas: el sistema está en una partición, y otra partición duplica los datos y no está montada. Hay algún comando para iniciar de uno o de otro. Y además, el disco entero está duplicado: pero no es un raid, es el ordenador entero el que está duplicado, cpu y memoria y buses y de todo, en hot swap entero o por trozos. Tecnología del tipo de los de la nasa, tamaño armario ropero. Pueden hacer cosas como parar una de las mitades del ordenador, dejarla congelada, y correr una actualización de sistema en la mitad activa. Si funciona, al dia siguiente reactivan la otra mitad para que replique todo. Si falla, lo que hacen es conmutar lado, y replicar al revés, la antigua en la nueva. Y todo eso sin parar el servicio ni un minuto: da miedo. Y no era yo, porque podía aparecer el jefe del proyecto por la sala a las tres de la madrugada para verlo... Hay una pagina en la wikipedia, si recordara el nombre... ah, si: http://en.wikipedia.org/wiki/5ESS y el ordenador en "suelto": http://en.wikipedia.org/wiki/3B21D
Es habitual en ordenadores "menores" hacer varias particiones, de sistema, de datos, de home... y en raid por software habitualmente cada una es un raid distinto: mdo, md1, md2... y esos cuatro o cinco raids realmente están en los mismos discos. Es decir, tu haces hda1, hda2, hda3, y hdc1, hdc2, hdc3; luego unes los unos haciendo md0, los doses haciendo md1, etc. Logicamente si falla el hda, se te van al carajo todos los raids, y tienes tres operaciones de reconstrucción.
Esa es la puñeta. Es parecido a lo que tiene este cliente nuestro. Nosotros generalmente aconsejamos RAID 1 para / y RAID 5 ó 6 ó 10 ó 50 (dependiendo del tipo de datos) para /home o /datos o el pto de montaje que quiera el cliente.
Si es un cliente HPC tenemos un /scratch como RAID 0.
Mi propuesta es ligeramente distinta: hacer un unico array, y luego particionarlo. En caso de fallo de disco, es un solo raid el que falla, aunque contenga varias particiones, y un solo hilo de reconstrucción.
Eso sí es mucho mejor. Como dices: una única reconstrucción. Más efectivo y consume menos recursos.
Sin embargo comentó francisco que las hacen en secuencia, no simultaneas. A no ser que sea capaz de reconstruir varios arreglos si están en discos distintos.
En tu liga, cada raid es una cabina o lo que sea, y albergará un unico sistema de ficheros de varios teras con replicaciones a varios niveles :-P
Depende, puede haber varios sistemas de ficheros en varios RAIDs diferentes. Depende un poco de lo que vaya a hacer el cliente. Luego a lo mejor hay que unir los LUNs con un gestor de volúmenes. Por ejemplo, si el cliente va a montar 100 TB, no es aconsejable hacer un único LUN de 100 TB. Es aconsejable hacer varios LUNS (RAID 5 ó 6 o el que sea) y luego con un gestor de volúmenes hacer un stripe sobre esos LUNs creando un único sistema de ficheros. De esta manera te proteges frente a caídas de múltiples discos simultáneamente.
Me estaba preguntando si existirá una manera de juntar sistemas de ficheros en un macrosistema de ficheros. Incluso en caso de corrupción de datos, sería uno de los sistemas el corrompido, no el resto. es decir, no juntar raids y luego formatear el conjunto, sino raids con su formateo independiente, y luego unidos de alguna manera. En MsDOS existía un comando para unir un directorio a otro, pero me parece que tampoco es esto que digo.
Por cierto, si no es mucha indiscreción: ¿cuántos discos tienes y de qué capacidades? Lo pregunto porque hablas de muchas particiones y me tienes intrigado 0:)
Uno de 40GB, otro de 160GB, y otro de 320GB, 6, 16 y 20 particiones, en orden de adquisición: como son de distintas añadas, las capacidades cambian. Sin contar los externos para backups o cosas guardadas a largo plazo, encriptadas a veces. Y no, no tengo ninguno de tera ni quiero. Les tengo miedo todavía. Ultimamente me fijo en el precio por megabyte para decidirme. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAklaRtoACgkQtTMYHG2NR9X7tgCfY5zd/4L2lR6amvzgMpM12NrB 5VEAnjOdhotwqjo0cvemwNHWQQgO+VDH =wcwD -----END PGP SIGNATURE-----