.png)
Estaba experimentando con instantáneas en LVM en Ubuntu 12.10. Creé un volumen lógico de instantánea de 6,5 GiB y, después de realizar algunos cambios en el origen, decidí volver a fusionar la instantánea para deshacerlos. Todo parecía ir bien, pero noté varios mensajes de error de segmentación relacionados con LVM en syslog.
Comandos ingresados:
sudo lvcreate -L6.5G -n backup_snapshot -s /dev/mapper/vg0-backup
# made some miscellaneous writes
sudo lvconvert --merge /dev/vg0/backup_snapshot
sudo umount /snapshot/backup
sudo umount /backup
sudo lvchange -an /dev/vg0/backup
sudo lvchange -ay /dev/vg0/backup
sudo mount /backup
Desde syslog:
Apr 12 04:57:10 bournemouth kernel: [ 5260.813253] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: errors=remount-ro
Apr 12 05:00:11 bournemouth kernel: [ 5441.841401] EXT4-fs (dm-5): mounted filesystem with ordered data mode. Opts: errors=remount-ro
Apr 12 05:02:00 bournemouth kernel: [ 5551.438487] show_signal_msg: 48 callbacks suppressed
Apr 12 05:02:00 bournemouth kernel: [ 5551.438495] lvm[5813]: segfault at 28 ip 000000000047f319 sp 00007fff60873de0 error 4 in lvm[400000+d9000]
Apr 12 05:02:01 bournemouth kernel: [ 5552.458797] lvchange[6449]: segfault at 28 ip 000000000047f319 sp 00007fff935f4380 error 4 in lvm[400000+d9000]
Luego desmonté el LV de origen, me aseguré de que la instantánea ya no existiera y fsck.ext4 -fla ejecuté; salió bien de esa manera. Pero todavía estoy preocupado por los fallos de segmento. ¿Es posible que mis datos se hayan estropeado de alguna manera que fsck no pueda detectar? El volumen con el que estaba experimentando era uno de respaldo, y todos los sistemas de archivos de los que hice una copia de seguridad todavía están en funcionamiento, por lo que podría comenzar de nuevo y hacer una copia de seguridad de ellos nuevamente. Pero, por otro lado, me gustaría conservar mi historial de copias de seguridad incrementales. Sólo me gustaría tener la seguridad de que puedo confiar en estas copias de seguridad.
Respuesta1
Sí, definitivamente es un error, pero no te preocupes, LVM es lo suficientemente inteligente como para manejar estas cosas. Una vez se cortó la energía en medio de un movimiento pv y todo lo que tuve que hacer fue básicamente encender nuevamente el servidor y "cancelar". el antiguo pvmove y empezar de nuevo.
En primer lugar, es importante saber que las herramientas que utiliza son sólo una interfaz de espacio de usuario para los procesos del kernel. LVM vive dentro del kernel, por lo que, a menos que su kernel entre en pánico, estará bien. Las herramientas de espacio de usuario como pvmove o lvchange simplemente interactúan con LVM por nosotros y luego simplemente se sientan y básicamente le preguntan al núcleo: "Oye, ¿ya terminaste con eso? ¿Cómo resultó?" o "Oye, ¿qué tan avanzado estamos con esto?" (Su problema específico es con la segmentación de lvchange después de que lvchange se completa con éxito,suena como un error arreglado recientementepor lo que es posible que desees asegurarte de tener todas las actualizaciones del sistema).
Como punto general, tampoco deberías ser tan resbaladizo o paranoico acerca de si tienes problemas con LVM, está diseñado para manejar bien errores inesperados como este (incluso cuando lo afectan directamente y no solo a la herramienta que estás usando). ) y esa garantía es parte del objetivo de utilizar un administrador de volúmenes en particiones tradicionales. Sólo estás en problemas si algoen realidadSucede algo malo o haces algo sin pensarlo bien. LVM opera por extensiones (en lugar de bloques) y no activa la extensión copiada y desactiva la original hasta que la operación de copia ya se haya completado con éxito. Al hacerlo, las extensiones medio copiadas permanecerán marcadas como no asignadas y cualquier herramienta posterior simplemente escribirá sobre ellas. Este es el caso de mi pvmove y de tu lvchange.
EDITAR:
Mirando aeste anuncio de la lista de correo, podemos obtener una descripción más detallada de cómo funciona realmente su combinación "debajo del capó":
Mientras la fusión está activa, cualquier acceso al dispositivo de origen se [dirige a] la instantánea que se está fusionando. Cuando finaliza la fusión, el destino de origen se recarga sin problemas y se elimina la instantánea de fusión. El sistema de archivos [sin instantáneas] puede permanecer montado durante este tiempo.
Pensé que podría ser interesante saberlo.
Respuesta2
Si bien el kernel (mapeador de dispositivos) maneja las cosas pesadas, sus datos como tales deberían estar seguros. Sin embargo, las herramientas del área de usuario de LVM todavía tienen funciones importantes; mantienen los metadatos de LVM, el qué se almacena, dónde y cómo, que el mapeador del dispositivo no conoce ni le importa.
Si la herramienta LVM falla en medio de la actualización de dichos metadatos, es posible que se pierdan datos. En cierto modo, LVM es un sistema de archivos para particiones; Los metadatos LVM dañados equivaldrían a perder un superbloque del sistema de archivos. Es por eso que casi todos los cambios se registran o se respaldan en /etc/lvm/....
Los Segfaults nunca son buenos: si tus herramientas LVM hacen esto, debes dejar de usarlas y cambiar a una versión LVM que funcione estable para ti. Y probablemente informe un error en su distribución, para que el problema pueda ser rastreado y solucionado para siempre.