-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-05-21 a las 16:29 +0200, Rafa Grimán escribió:
¡Exacto!
La gente no se cosca de eso. Y afecta mucho a los beta-testers y experimentadores.
A mi me hizo un poco la puñeta porque estaba experimentando con volúmenes y RAIDs y necesitaba muchas particiones porque tengo pocos discos. Así que me hizo un poco la puñeta :(
Ya ves... Ahora, reza para que le pase lo mismo a un tal Linus Torvalds ;-)
De las primarias, tienes sólo tres usables, porque una es la extendida. Y logicas sólo quedan 11, luego son un total de 14 particiones. Y si has llegado a la numero 15 sin declarar las primarias, pues tienes un problema...
Yo lo tuve :( La verdad es que nunca me hubiera imaginado usando tantas particiones, pero heme aquí inventando otras cosas para salir del paso aka enchufar como puedo más discos ;)
No estoy seguro, no he tenido oportunidad de probar si un /dev/md se puede particionar.
¿Inseguro? No lo es si pones un RAID por debajo, claro que si pones RAID por software y luego LVM por encima ... necesitas bastante RAM y CPU ;)
Hay varios tipos de seguridad, y esa no es la que me preocupa.
El particionamiento en este sentido es como las mamparas estancas en los barcos: limitas los daños a una sección. Si el software se vuelve loco y te fastidia una partición (me ha pasado) es muy facil que los daños se limiten a una partición. Eso me ha pasado varias veces, y perdido totalmente particiones fat, xfs (si, xfs :-p), reiser, y ext3. En el caso de la reiser fué un bug reconocido en el código del reiserfs. Si hubiera tenido una partición gigante con todo, hubiera perdido _todo_. Con particiones pequeñas, pues una vez perdí home, otra root, etc, pero me quedaban otros root y otros home con los que rescatar (si tienes particiones, una o dos son de rescate).
De eso no protege un raid: pierdes todas las copias al mismo tiempo.
No sé si lo he entendido. A lo que me refería es que LVM lo montas encima de un RAID (me da igual construir un RAID con discos o particiones). Si se pierde una partición o un disco (siempre y cuando _NO_ sea RAID 0), puedes quitar esa partición o disco estropeado del RAID y cambiarlo por otro. Una vez hecho, los datos de la paridad reconstruirán la información que tenías en ese disco/partición.
Si hay un problema que afecta al software el cual escribe datos incorrectos en la partición, lo hará en ambas copias del raid. Eso me ha pasado varias veces; no tenía raid, pero ese tipo de fallo lo jod^Hroba entero, todas las mitades o slices como se llamen.
Y el LVM es más inseguro en ese aspecto. Depende de una tabla que reside en algún sitio de /etc. Si no es legible, pierdes todo el lvm. Varias veces ha pasado que los discos de rescate de SuSE han fallado en la recuperación de sistemas con LVM, o han habido problemas entre distintas versiones incompatibles en algo.
Eso sí, si pierdes el ficherín ... a recrearlo ;) Ahhhh!! Acabo de caer en la cuenta: NO TIENES BACKUPS!!! Qué invento es este!! Sin backups =:0
Je, je, je, ... ;)
Exacto. Con particiones físicas puedes encontrarlas a las malas con "guesspart". O imprimes la tabla en papel y la guardas bien guardadita. ¿Y con LVM?
Yo desconozco que sistemas de rescate manual de sistemas LVM existen. Estoy pez, y eso me da _pánico_.
¿Tienes garantías de que puedes acceder y podrás seguir accediendo a esas particiones LVM (que es software) tanto desde 10.2, 10.3, 11.0, y más?
Teóricamente sí. Claro que en teoría no hay diferencia entre teoría y práctica, en la práctica sí ;)
Ja.
Lo malo es al pasar de una versión a otra, por ejemplo si tienes uno con LVM1 y otro con LVM2.
Claro, eso digo.
¿Y desde windows en el mismo ordenador?
Si quitas el MS-Windows sí ;) Si mantienes el MS-Windows no.
¿Y desde ubuntu o mandrake?
Lo mismo que en el caso de openSUSE 10.x.
Pues eso... las particiones son cosa estandard industrial, el LVM no lo es.
Porque si el LVM está definido en una tabla en /etc, ¿como hago para que todos los sistemas la compartan?
Lo copias.
Vale, estoy en suse, hago un cambio, me meto en... ubuntu... ¡uich, se me ha olvidado que cambié la tabla! ¡CATAPAF! Seguro que me quedo sin disco.
¿Que garantías hay de que la compartición estanca de particiones se respeta? ¿De que un fallo en el kernel no destroce todas las particiones al mismo tiempo?
Ninguna. Pero esto te pasa a nivel de filesystem y de RAID por sw. De ahí que tengas backups, DR y BC, además de todos los datos impresos en ASCII, 1s y 0s, en color y en B/N. Sin olvidarnos que lo has memorizado todo (cifrado y sin cifrar, por si vienen los malos ;)
¡Grrr! Yo he reconstruido sistemas destrozados, a manuense, quemandome las cejas. ¿Podría hacer lo mismo con LVM? NO. Tendría que tirar de backup y reconstruir todo.
Ahora mismo llevo un Bugzilla que afecta al filesystem tirandolo entero abajo, varios meses con el "bug". Apareció con la 10.3 y continua en la 11.0, y tengo pocas esperanzas de que se resuelva. Sabemos que es un parche que ha metido suse/novell, porque el kernel vainilla no tiene ese problema, pero no sabemos cual, y las respuestas al bugzilla se dilatan varios meses entre sí (ah, y afecta a sistemas de ficheros encriptados metidos en XFS sobre fichero imagen).
Jarl. ¿Cuál es el problema?
Que la parte del kernel que escribe en ese filesystem encriptado se para. El programa que está escribiendo se congela en un "wait" eterno (¿no se si puedo mirar la función? Ah, si, se queda en "xfs_ilock" según el mc: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ WCHAN Flags COMMAND 10628 crypt 20 0 6688 2836 1956 D 0.0 0.3 0:03.12 xfs_ilock ..4.2... mc A partir de ahí, puedes usar el sistema, pero diversos programas no son capaces de salir, se quedan bloqueados: por ejemplo las X. No puedes hacer halt ni reboot, se paran. No puedes desmontar diversas particiones (otras si). Tengo que hacer cosas como: umount -l /cosa & O sea, lazy umount en background, para que no me bloquee el terminal. Y al final, apagar a lo bruto y rezar.
¿Destrozaría un fallo en el filesystem un sistema LVM?
Sí, pero te lo destrozaría también en un RAID y en un backup. Por si eso fuera poco, pueden aparecer ... no me acuerdo cómo se llaman. Da igual, ya me acordaré. Son unos errores que aparecen de pronto y resulta que así, por las buenas, un bit cambia y los sistemas de chequeo lo pasan por alto (RAID, paridad, CRCs, MD5s, ...). Es una puñeta, pero no hay solución ... bueno, crear de nuevo el fichero.
Jupe. Bueno, lo que yo quiero decir es que no se que nivel de seguridad tengo que de que no haya fallos que corrompan el LVM entero. Hasta ahora, en particiones normales, lo peor que me ha pasado es una partición irrecuperable por completo, y el resto unas intactas y otras con pocos daños. Si esto me viene de lejos... mira. msdos. disquete, leyendo. grabar. saco, meto otro, continuar grabar... rayos, graba el directorio del primero encima del segundo. Segundo disquete perdido. Murphy: ese disquete era la práctica de progrmación en pascal que tenía que entregar esa misma tarde. Creo recordar que conseguí reconstruirlo.
Francamente, a mi el LVM me da MIEDO. Llevo tiempo tratando de estudiarlo, pero voy lento y sigue sin convencerme. La gente de Novell son muy rápidos en recomendar la migración a LVM, pero no tienen un plan de migración para un sistema existente con más de 15 particiones. Y no te contestan cuando se lo dices.
Los gestores de volúmenes son muy habituales cuando se trata de grandes volúmenes de datos. No es recomendable, por ejemplo tener un RAID 5 de más de 8 discos porque hay más probabilidad de que fallen dos discos en el RAID 5 y se te vaya todo al carajo. Entonces lo que haces es montar varios RAID 5 y unirlos con un gestor de volúmenes, sea LVM o el que sea.
Sí, ha salido RIAD 6, pero ocurre lo mismo salvo que en vez de 2 discos, son 3 los que se tienen que jorungar.
A esto hay que sumar que los discos son cada vez más grandes y menos fiables (además de lentos). Lo cual suma otra variable más (negativa) a nuestra ecuación :(
Si no digo que no tengan utilidad. Son muy utiles. Pero tiene una serie de inconvenientes que no me compensan. No son una solución válida para tener varias particiones. No tengo un montón de particiones por capricho, sino para compartimentar daños y para hacer probatinas de sistemas. El LVM no me lo soluciona, lo empeora. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFINDtHtTMYHG2NR9URAuctAKCOv6cbkzc8FoKhSizWhlMjNv9vPgCeOeIg nGQGsYV03Hk+QL+TIEgEJVw= =eCl4 -----END PGP SIGNATURE-----