[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: LVM2, ampliando para luego quitar



O Martes 22 Xaneiro 2008 19:03, Adrian Chapela escribiu:
> 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)
Siempre te advierte, por si no te has acordado de reducir antes el sistema de 
ficheros.

> 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 ??
>
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á.

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.

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


Reply to: