Jorge Barreiro Gonzalez escribió:
Aquí está el problema, al pasarle el e2fsck -f /dev/vgtest/lvm1 , me dice lo siguiente: "El tamaño del sistema de ficheros de acuerdo al super bloque es de XXXX y el tamaño físico del dispositivo es de XXX Puede que el super bloque o la partición estén corrompidos"O Martes 22 Xaneiro 2008 19:03, Adrian Chapela escribiu:Siempre te advierte, por si no te has acordado de reducir antes el sistema de ficheros.Snip!pvmove sólo tiene control sobre volúmenes lógicos. Para él, extents utilizados son extents asignados a un volúmen lógico. Voy a poner datos de ejemplo. Si tienes dos discos, de 40GB cada uno, podrás hacer un volúmen lógico de 80GB, que és lo que has hecho. Ahí no puedes mover nada a ningún lado, tienes todo el espacio asignado (aunque en realidad los ficheros ocupen mucho menos, o incluso el sistema de ficheros ocupe menos). Tienes que reducir el espacio asignado a los volúmenes lógicos hasta que éstos cojan por completo en el disco que se va a quedar. Para esto, ANTES de reducir el volúmen lógico debes reducir el sistema de ficheros que hay en él, o lo machacará. # resize2fs /dev/vgtest/lvm1 40M # lvmresize /dev/vgtest/lvm1 (no le paso parámetros, debería sacar el tamaño del sisema de ficheros, no estoy seguro de que esto funciona. Si no, le pones el tamaño y punto).Vale hasta aquí estamos casi de acuerdo., pero me ocurre algo curioso. Yo tengo dos PV de 100 MB cada uno. Escribo un fichero de 70 MB, luego uno de 20 MB y por último 3 de 10 MB. Así tengo: file1 -> 70 MB file2 -> 20 MB file3 -> 10 MB file4 -> 10 MB file5 -> 10 MB Total > 100MB , con lo cual tiene que escribir en los dos PV. Luego borro el file1 70 MB (ya tengo espacio suficiente para almacenar en un solo PV todo). Luego hago lo siguiente: umount proba_vg (estaba montada ;)) e2fsck -f /dev/vgtest/lvm1 (Para forzar el chequeo, si no no vale, para preparar el hacer el sistema de ficheros más pequeño...) resize2fs /dev/vgtest/lvm1 100M lvresize --extents 25 /dev/vgtest/lvm1 (lo hago por extents porque como es un número fácil, cada PV tiene 25 así que reduzco de 50 a 25. Al ejecutar este comando me advierte que se pueden perder datos al reducir, pero bueno , me da igual y lo hago. Esto no se si es normal)En realidad no se ha reorganizado nada. Cuando creas un LV los extents se asignan linealmente, cuando lo reduces los extents se desasignan por el final, con lo que al final te queda el PV2 libre. De todas formas, esto es implementación interna y no te puedes fiar de que siempre es así, por lo que es mejor hacer todos los pasos. Al crear un LV puedes pasar opciones para que los distribuya de otra forma (que empiece a asignar en PV2, o que los asigne alternos, consiguiendo algo parecido a un raid0) y esto ya no se cumplirá.Por último hago un pvdisplay y ya aparece como que todos los extents ocupados son los del PV1 y del PV2 están todos libres. Al hacer el pvmove me dice que el PV1 no tiene extents libres claro. A donde quiero llegar es, es normal que reorganice el automáticamente ??Si te lo preguntas por lo de los archivos, eso va a nivel del sistema de ficheros. Cuando creas file4 y file5 efectivamente se graba en el PV2. Cuando haces el resize2fs, éste no entiende de extents ni nada, solo ve un disco grande. resize2fs mantiene siempre el inicio del sistema de ficheros en el mismo sitio. Es él quien reorganiza los ficheros para que cojan con el nuevo tamaño. De forma que tras ejecutar resize2fs, los extents que están en el PV2, aunque siguen asignados al LV, ya no tienen ningún dato del sistema de ficheros.Luego quito el PV sin problemas.Me alegro. Hazle otro chequeo, por si acaso.
Esto me ha pasado después de eliminar el PV y pasarle el e2fsck en la segunda prueba. La segunda prueba consiste en crear dos PV uno de 100 MB y otro de 300 MB y crear sobre 320 MB de datos. Luego elimino 20 MB y me quedo por debajo de los 300MB y reduzco y trato de eliminar el primer PV1. Así me quedo como antes pero con el segundo PV.Aquí es donde puede estar el problema. El super bloque va al inicio no ?? Yo al sacar el segundo PV ya no tengo el super bloque no ?? Y eso es lo que provoca que parezca que está corrupto. No me fío ni un pelo.
y ahora deberías poder usar pvmove. Comprueba con "vgdisplay -v" que el número de "PE"s libres del grupo es igual o mayor al número de "PE"s del volumen físico que queires quitar. Saludos.