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

Re: LVM2, ampliando para luego quitar



O Martes 22 Xaneiro 2008 19:55, Adrian Chapela escribiu:
> Jorge Barreiro Gonzalez escribió:
> > 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.
>
> 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"
>
> 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.
>

Sólo corres riesgo de perder datos al hacer el lvreduce. Si reduces por debajo 
del tamaño del sistema de ficheros te estarás cargando datos. Si reduces por 
encima saldrá igual el mensaje ese, pero no habrás perdido nada.
Esto puede pasar por el redondeo. Los LV tienen un tamaño múltiplo del tamaño 
de los extents. Si los extents son de 4MB y pides un LV de 7MB, se creará uno 
de 8MB (aunque este no parece ser tu caso). Al sistema de ficheros también le 
pasa algo parecido, pero ya no sé decirte de qué depende.
En cualquier caso, si haces resize2fs /dev/vgtest/lvm1, sin indicar ninguna 
cantidad, el sistema de ficheros se adapta a su contenedor y se acabó el 
problema.
He encontrado la opción --resizefs para el comando lvresize. No está muy 
documentada, pero ya que estás con pruebas, puedes probarla. Debería evitar 
errores de diferencias de tamaños entre el LV y el sistema de ficheros. Yo no 
la he probado nunca, así que no puedo decirte.
El superbloque se fué del PV1 al PV2 al hacer pvmove (porque lo has hecho, 
no?).

De todas formas, me parece raro que hayas conseguido meter un archivo de 300MB 
en un LV de 300MB, ya que el sistema de ficheros suele comer algo de espacio. 
Dices que te quedas por debajo de los 300MB, pero 300 - 20 son justo 300. El 
resize2fs debería decirte que nanai.

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