Peligros y advertencias de LVM

Solución 1:

Resumen

Riesgos de usar LVM:

• Vulnerable para escribir problemas de almacenamiento en caché con hipervisor SSD o VM
• Más difícil recuperar datos debido a estructuras en disco más complejas
• Más difícil cambiar el tamaño de los sistemas de archivos correctamente
• Las instantáneas son difíciles de usar, lentas y con errores
• Requiere cierta habilidad para configurar correctamente dados estos problemas

Los primeros dos problemas de LVM se combinan:si el almacenamiento en caché de escritura no funciona correctamente y tiene una pérdida de energía (por ejemplo, falla la fuente de alimentación o el UPS), es posible que deba recuperarse de la copia de seguridad, lo que significa un tiempo de inactividad significativo. Una razón clave para usar LVM es un mayor tiempo de actividad (al agregar discos, cambiar el tamaño de los sistemas de archivos, etc.), pero es importante configurar correctamente el almacenamiento en caché de escritura para evitar que LVM realmente reduzca el tiempo de actividad.

-- Actualizado en diciembre de 2019:actualización menor sobre btrfs y ZFS como alternativas a las instantáneas de LVM

Mitigar los riesgos

LVM aún puede funcionar bien si:

• Obtenga su configuración de almacenamiento en caché de escritura directamente en hipervisor, kernel y SSD
• Evite las instantáneas de LVM
• Utilice versiones recientes de LVM para cambiar el tamaño de los sistemas de archivos
• Tener buenas copias de seguridad

Detalles

He investigado esto bastante en el pasado después de haber experimentado alguna pérdida de datos asociada con LVM. Los principales riesgos y problemas de LVM que conozco son:

Vulnerable al almacenamiento en caché de escritura del disco duro debido a hipervisores de VM, almacenamiento en caché de disco o kernels de Linux antiguos , y dificulta la recuperación de datos debido a estructuras en disco más complejas; consulte los detalles a continuación. He visto configuraciones completas de LVM en varios discos que se corrompen sin ninguna posibilidad de recuperación, y LVM más el almacenamiento en caché de escritura del disco duro es una combinación peligrosa.

• Caché de escritura y reordenación de escritura en el disco duro es importante para un buen rendimiento, pero puede fallar al vaciar correctamente los bloques en el disco debido a hipervisores de VM, almacenamiento en caché de escritura del disco duro, kernels de Linux antiguos, etc.
• Las barreras de escritura significan que el kernel garantiza que completará ciertas escrituras de disco antes de la escritura de disco de "barrera", para garantizar que los sistemas de archivos y RAID puedan recuperarse en caso de una pérdida repentina de energía o falla. Tales barreras pueden usar una operación FUA (Acceso de unidad forzado) para escribir inmediatamente ciertos bloques en el disco, lo cual es más eficiente que un vaciado completo de caché. Las barreras se pueden combinar con colas de comandos nativos/etiquetados eficientes (que emiten varias solicitudes de E/S de disco a la vez) para permitir que el disco duro realice un reordenamiento de escritura inteligente sin aumentar el riesgo de pérdida de datos.
• Hipervisores de máquinas virtuales puede tener problemas similares:ejecutar LVM en un invitado de Linux sobre un hipervisor de VM como VMware, Xen, KVM, Hyper-V o VirtualBox puede crear problemas similares a los de un kernel sin barreras de escritura, debido al almacenamiento en caché de escritura y al reordenamiento de escritura . Revise cuidadosamente la documentación de su hipervisor para ver si hay una opción de caché de escritura simultánea o "vaciado en disco" (presente en KVM, VMware, Xen, VirtualBox y otros), y pruébelo con su configuración. Algunos hipervisores, como VirtualBox, tienen una configuración predeterminada que ignora los vaciados de disco del invitado.
• Los servidores empresariales con LVM siempre deben usar un controlador RAID respaldado por batería y deshabilite el almacenamiento en caché de escritura del disco duro (el controlador tiene un caché de escritura respaldado por batería que es rápido y seguro); consulte este comentario del autor de esta entrada de preguntas frecuentes sobre XFS. También puede ser seguro desactivar las barreras de escritura en el kernel, pero se recomienda probar.
• Si no tiene un controlador RAID respaldado por batería, deshabilitar el almacenamiento en caché de escritura del disco duro ralentizará significativamente las escrituras pero hará que LVM sea seguro. También debe usar el equivalente de data=ordered de ext3 opción (o data=journal para mayor seguridad), más barrier=1 para garantizar que el almacenamiento en caché del kernel no afecte la integridad. (O use ext4 que habilita las barreras de forma predeterminada). Esta es la opción más simple y proporciona una buena integridad de datos a costo de rendimiento. (Linux cambió la opción predeterminada ext3 a la más peligrosa data=writeback hace un tiempo, así que no confíe en la configuración predeterminada para el FS.)
• Para deshabilitar el almacenamiento en caché de escritura del disco duro :añadir hdparm -q -W0 /dev/sdX para todas las unidades en /etc/rc.local (para SATA) o use sdparm para SCSI/SAS. Sin embargo, de acuerdo con esta entrada en las preguntas frecuentes de XFS (que es muy buena en este tema), una unidad SATA puede olvidar esta configuración después de una recuperación de error de la unidad, por lo que debe usar SCSI/SAS, o si debe usar SATA, entonces coloque la Comando hdparm en un trabajo cron que se ejecuta cada minuto más o menos.
• Para mantener habilitado el almacenamiento en caché de escritura en SSD/disco duro para un mejor rendimiento:esta es un área compleja; consulte la sección a continuación.
• Si está utilizando unidades de formato avanzado es decir, sectores físicos de 4 KB, consulte a continuación:deshabilitar el almacenamiento en caché de escritura puede tener otros problemas.
• SAI es fundamental tanto para empresas como para SOHO, pero no lo suficiente para hacer que LVM sea seguro:cualquier cosa que provoque un bloqueo fuerte o una pérdida de energía (por ejemplo, falla del UPS, falla de la fuente de alimentación o agotamiento de la batería de la computadora portátil) puede perder datos en las memorias caché del disco duro.
• Kernels de Linux muy antiguos (2.6.x de 2009) :Hay soporte de barrera de escritura incompleto en versiones de kernel muy antiguas, 2.6.32 y anteriores (2.6.31 tiene algo de soporte, mientras que 2.6.33 funciona para todos los tipos de dispositivos de destino) - RHEL 6 usa 2.6.32 con muchos parches. Si estos antiguos núcleos 2.6 no se parchean para estos problemas, una gran cantidad de metadatos de FS (incluidos los diarios) podrían perderse debido a un bloqueo que deja los datos en los búferes de escritura de los discos duros (por ejemplo, 32 MB por unidad para las unidades SATA comunes). La pérdida de 32 MB de los metadatos de FS escritos más recientemente y los datos del diario, que el núcleo cree que ya están en el disco, generalmente significa una gran cantidad de corrupción de FS y, por lo tanto, pérdida de datos.
• Resumen: debe tener cuidado con el sistema de archivos, RAID, hipervisor de VM y configuración del disco duro/SSD que se usa con LVM. Debe tener muy buenas copias de seguridad si está utilizando LVM, y asegúrese de hacer una copia de seguridad específica de los metadatos de LVM, la configuración de la partición física, el MBR y los sectores de arranque de volumen. También es recomendable usar unidades SCSI/SAS, ya que es menos probable que mientan sobre cómo escriben el almacenamiento en caché; se requiere más cuidado para usar unidades SATA.

Mantener el almacenamiento en caché de escritura habilitado para el rendimiento (y para hacer frente a los impulsos mentirosos)

Una opción más compleja pero eficaz es mantener habilitado el almacenamiento en caché de escritura SSD/disco duro y confiar en las barreras de escritura del kernel que funcionan con LVM en el kernel 2.6.33+ (verifique dos veces buscando mensajes de "barrera" en los registros).

También debe asegurarse de que la configuración de RAID, la configuración del hipervisor de la VM y el sistema de archivos utilicen barreras de escritura (es decir, requiere que la unidad elimine las escrituras pendientes antes y después de las escrituras de diario/metadatos clave). XFS usa barreras por defecto, pero ext3 no, así que con ext3 deberías usar barrier=1 en las opciones de montaje, y seguir usando data=ordered o data=journal como arriba.

• Desafortunadamente, algunos discos duros y SSD mienten sobre si realmente han vaciado su caché al disco (particularmente unidades más antiguas, pero incluidas algunas unidades SATA y algunas SSD empresariales); más detalles aquí. Hay un gran resumen de un desarrollador de XFS.
• Hay una herramienta de prueba simple para unidades mentirosas (secuencia de comandos de Perl), o vea este fondo con otra herramienta de prueba para reordenar escritura como resultado de la memoria caché de la unidad. Esta respuesta cubrió pruebas similares de unidades SATA que descubrieron un problema de barrera de escritura en software RAID:estas pruebas en realidad ejercitan toda la pila de almacenamiento.
• Es menos probable que las unidades SATA más recientes que admiten Native Command Queuing (NCQ) mientan, o tal vez funcionen bien sin almacenamiento en caché de escritura debido a NCQ, y muy pocas unidades no pueden desactivar el almacenamiento en caché de escritura.
• Las unidades SCSI/SAS generalmente están bien, ya que no necesitan almacenamiento en caché de escritura para funcionar bien (a través de SCSI Tagged Command Queuing, similar a NCQ de SATA).
• Si sus discos duros o SSD mienten acerca de vaciar su caché en el disco, realmente no puede confiar en las barreras de escritura y debe deshabilitar el almacenamiento en caché de escritura. Este es un problema para todos los sistemas de archivos, bases de datos, administradores de volumen y software RAID, no solo para LVM.

SSD son problemáticos porque el uso de la memoria caché de escritura es fundamental para la vida útil de la SSD. Lo mejor es usar un SSD que tenga un supercondensador (para habilitar el vaciado de la memoria caché en caso de corte de energía y, por lo tanto, permitir que la memoria caché sea reescritura no simultánea).

• La mayoría de los SSD empresariales deberían estar bien en el control de caché de escritura y algunos incluyen supercondensadores.
• Algunos SSD más baratos tienen problemas que no se pueden solucionar con la configuración de caché de escritura:la lista de correo del proyecto PostgreSQL y la página wiki de Reliable Writes son buenas fuentes de información. Los SSD de consumo pueden tener importantes problemas de almacenamiento en caché de escritura que provocarán la pérdida de datos y no incluyen supercondensadores, por lo que son vulnerables a fallas de energía que causan daños.

Formato avanzado configuración de la unidad:almacenamiento en caché de escritura, alineación, RAID, GPT

• Con las unidades de formato avanzado más nuevas que usan sectores físicos de 4 KiB, puede ser importante mantener habilitado el almacenamiento en caché de escritura de la unidad, ya que la mayoría de estas unidades actualmente emulan sectores lógicos de 512 bytes ("emulación 512"), y algunas incluso afirman tener 512 -sectores físicos de bytes mientras realmente usa 4 KiB.
• Desactivar la memoria caché de escritura de una unidad de formato avanzado puede causar un gran impacto en el rendimiento si la aplicación o el núcleo realizan escrituras de 512 bytes, ya que estas unidades dependen de la memoria caché para acumular 8 escrituras de 512 bytes antes de realizar una sola operación. Escritura física de 4 KiB. Se recomienda realizar pruebas para confirmar cualquier impacto si deshabilita el caché.
• La alineación de los LV en un límite de 4 KiB es importante para el rendimiento, pero debería ocurrir automáticamente siempre que las particiones subyacentes para los PV estén alineadas, ya que las extensiones físicas (PE) de LVM tienen 4 MiB de forma predeterminada. RAID debe tenerse en cuenta aquí:esta página de configuración de LVM y RAID de software sugiere colocar el superbloque RAID al final del volumen y (si es necesario) usar una opción en pvcreate para alinear los PV. Este hilo de la lista de correo electrónico de LVM señala el trabajo realizado en los núcleos durante 2011 y el problema de las escrituras de bloques parciales al mezclar discos con sectores de 512 bytes y 4 KiB en un solo LV.
• La partición GPT con formato avanzado necesita cuidado, especialmente para los discos de arranque y raíz, para garantizar que la primera partición LVM (PV) comience en un límite de 4 KiB.

Más difícil recuperar datos debido a estructuras en disco más complejas :

• Cualquier recuperación de datos LVM requerida después de un bloqueo fuerte o una pérdida de energía (debido a un almacenamiento en caché de escritura incorrecto) es un proceso manual en el mejor de los casos, porque aparentemente no hay herramientas adecuadas. LVM es bueno para hacer copias de seguridad de sus metadatos bajo /etc/lvm , que puede ayudar a restaurar la estructura básica de LV, VG y PV, pero no ayudará con la pérdida de metadatos del sistema de archivos.
• Por lo tanto, es probable que se requiera una restauración completa desde la copia de seguridad. Esto implica mucho más tiempo de inactividad que un fsck rápido basado en diario cuando no se usa LVM, y los datos escritos desde la última copia de seguridad se perderán.
• TestDisk, ext3grep, ext3undel y otras herramientas pueden recuperar particiones y archivos de discos que no son LVM, pero no admiten directamente la recuperación de datos LVM. TestDisk puede descubrir que una partición física perdida contiene un PV LVM, pero ninguna de estas herramientas comprende los volúmenes lógicos LVM. Las herramientas de creación de archivos, como PhotoRec y muchas otras, funcionarían al pasar por alto el sistema de archivos para volver a ensamblar archivos a partir de bloques de datos, pero este es un enfoque de bajo nivel y de último recurso para datos valiosos, y no funciona tan bien con archivos fragmentados.
• La recuperación manual de LVM es posible en algunos casos, pero es compleja y lleva mucho tiempo. Consulte este ejemplo y este, este y este para saber cómo recuperarse.

Más difícil cambiar el tamaño de los sistemas de archivos correctamente - El cambio de tamaño fácil del sistema de archivos a menudo se brinda como un beneficio de LVM, pero necesita ejecutar media docena de comandos de shell para cambiar el tamaño de un FS basado en LVM; esto se puede hacer con todo el servidor aún activo y, en algunos casos, con el FS montado, pero nunca me arriesgaría a esto último sin copias de seguridad actualizadas y usando comandos probados previamente en un servidor equivalente (por ejemplo, un clon de recuperación ante desastres del servidor de producción).

• Actualización: Versiones más recientes de lvextend apoyar el -r (--resizefs ) - si está disponible, es una forma más segura y rápida de cambiar el tamaño del LV y el sistema de archivos, especialmente si está reduciendo el FS, y en su mayoría puede omitir esta sección.

• La mayoría de las guías para cambiar el tamaño de los FS basados ​​en LVM no tienen en cuenta el hecho de que el FS debe ser un poco más pequeño que el tamaño del LV:explicación detallada aquí. Al reducir un sistema de archivos, deberá especificar el nuevo tamaño en la herramienta de cambio de tamaño de FS, p. resize2fs para ext3, y para lvextend o lvreduce . Sin mucho cuidado, los tamaños pueden ser ligeramente diferentes debido a la diferencia entre 1 GB (10 ^ 9) y 1 GiB (2 ^ 30), o la forma en que las distintas herramientas redondean los tamaños hacia arriba o hacia abajo.

• Si no hace los cálculos correctamente (o usa algunos pasos adicionales más allá de los más obvios), puede terminar con un FS demasiado grande para el LV. Todo parecerá estar bien durante meses o años, hasta que llene por completo el FS, momento en el que obtendrá una corrupción grave y, a menos que esté al tanto de este problema, es difícil averiguar por qué, ya que también puede tener errores de disco reales para entonces. que nublan la situación. (Es posible que este problema solo afecte la reducción del tamaño de los sistemas de archivos; sin embargo, está claro que cambiar el tamaño de los sistemas de archivos en cualquier dirección aumenta el riesgo de pérdida de datos, posiblemente debido a un error del usuario).

• Parece que el tamaño de LV debe ser mayor que el tamaño de FS por 2 veces el tamaño de extensión física (PE) de LVM, pero consulte el enlace anterior para obtener más detalles, ya que la fuente de esto no tiene autoridad. A menudo, permitir 8 MiB es suficiente, pero puede ser mejor permitir más, p. 100 MiB o 1 GiB, solo para estar seguros. Para verificar el tamaño de PE y su volumen lógico + tamaños de FS, use bloques de 4 KiB =4096 bytes:

  Muestra el tamaño de PE en KiB:
  vgdisplay --units k myVGname | grep "PE Size"
  
  Tamaño de todos los LV:
  lvs --units 4096b
  
  Tamaño de (ext3) FS, asume un tamaño de bloque de 4 KiB FS:
  tune2fs -l /dev/myVGname/myLVname | grep 'Block count'

• Por el contrario, una configuración que no sea LVM hace que cambiar el tamaño del FS sea muy confiable y fácil:ejecute Gparted y cambie el tamaño de los FS requeridos, luego hará todo por usted. En los servidores, puede usar parted del caparazón.

• A menudo es mejor usar Gparted Live CD o Parted Magic, ya que estos tienen un Gparted &kernel reciente y, a menudo, más libre de errores que la versión de distribución. Una vez perdí un FS completo debido a que Gparted de la distribución no actualizaba las particiones correctamente en ejecución. núcleo. Si usa Gparted de la distribución, asegúrese de reiniciar inmediatamente después de cambiar las particiones para que la vista del kernel sea correcta.

Las instantáneas son difíciles de usar, lentas y con errores - si la instantánea se queda sin espacio preasignado, se elimina automáticamente. Cada instantánea de un LV dado es un delta contra ese LV (no contra las instantáneas anteriores), lo que puede requerir mucho espacio al tomar instantáneas de sistemas de archivos con una actividad de escritura significativa (cada instantánea es más grande que la anterior). Es seguro crear un LV de instantánea que tenga el mismo tamaño que el LV original, ya que la instantánea nunca se quedará sin espacio libre.

Las instantáneas también pueden ser muy lentas (lo que significa de 3 a 6 veces más lentas que sin LVM para estas pruebas de MySQL); consulte esta respuesta que cubre varios problemas de instantáneas. La lentitud se debe en parte a que las instantáneas requieren muchas escrituras sincrónicas.

Las instantáneas han tenido algunos errores significativos, p. en algunos casos, pueden hacer que el arranque sea muy lento o que el arranque falle por completo (porque el kernel puede agotar el tiempo de espera del FS raíz cuando es una instantánea de LVM [corregido en Debian initramfs-tools actualización, marzo de 2015]).

• Sin embargo, muchos errores de condiciones de carrera de instantáneas aparentemente se solucionaron en 2015.
• LVM sin instantáneas generalmente parece bastante bien depurado, quizás porque las instantáneas no se usan tanto como las funciones principales.

Alternativas de instantáneas - sistemas de archivos e hipervisores de VM

Instantáneas de VM/nube:

• Si utiliza un hipervisor de VM o un proveedor de nube de IaaS (p. ej., VMware, VirtualBox o Amazon EC2/EBS), sus instantáneas suelen ser una alternativa mucho mejor que las instantáneas de LVM. Puede tomar una instantánea con bastante facilidad con fines de copia de seguridad (pero considere congelar el FS antes de hacerlo).

Instantáneas del sistema de archivos:

• Las instantáneas a nivel del sistema de archivos con ZFS o btrfs son fáciles de usar y, en general, mejores que LVM, si está en un sistema básico (pero ZFS parece mucho más maduro, solo que es más complicado de instalar):

• ZFS:ahora hay una implementación de kernel ZFS, que ha estado en uso durante algunos años, y parece que ZFS está ganando adopción. Ubuntu ahora tiene ZFS como una opción 'lista para usar', incluido ZFS experimental en la raíz en 19.10.

• btrfs:todavía no está listo para su uso en producción (incluso en openSUSE, que lo envía de forma predeterminada y tiene un equipo dedicado a btrfs), mientras que RHEL dejó de admitirlo). btrfs ahora tiene una herramienta fsck (FAQ), pero las preguntas frecuentes recomiendan consultar a un desarrollador si necesita fsck un sistema de archivos dañado.

Instantáneas para copias de seguridad en línea y fsck

Las instantáneas se pueden utilizar para proporcionar una fuente coherente para las copias de seguridad, siempre que tenga cuidado con el espacio asignado (lo ideal es que la instantánea sea del mismo tamaño que el LV del que se realiza la copia de seguridad). El excelente rsnapshot (desde 1.3.1) incluso administra la creación/eliminación de instantáneas LVM por usted; consulte este CÓMO sobre rsnapshot usando LVM. Sin embargo, tenga en cuenta los problemas generales con las instantáneas y que una instantánea no debe considerarse una copia de seguridad en sí misma.

También puede usar instantáneas de LVM para hacer un fsck en línea:tomar una instantánea del LV y fsck de la instantánea, sin dejar de usar el FS principal que no es una instantánea, descrito aquí. Sin embargo, no es del todo sencillo, por lo que es mejor usar e2croncheck como lo describe Ted Ts. 'o, mantenedor de ext3.

Debe "congelar" el sistema de archivos temporalmente mientras toma la instantánea; algunos sistemas de archivos como ext3 y XFS lo harán automáticamente cuando LVM crea la instantánea.

Conclusiones

A pesar de todo esto, todavía uso LVM en algunos sistemas, pero para una configuración de escritorio prefiero las particiones sin formato. El principal beneficio que puedo ver de LVM es la flexibilidad de mover y cambiar el tamaño de los FS cuando debe tener un alto tiempo de actividad en un servidor - si no lo necesita, gparted es más fácil y tiene menos riesgo de pérdida de datos.

LVM requiere mucho cuidado con la configuración del almacenamiento en caché de escritura debido a los hipervisores de VM, el almacenamiento en caché de escritura del disco duro/SSD, etc., pero lo mismo se aplica al uso de Linux como servidor de base de datos. La falta de soporte de la mayoría de las herramientas (gparted incluidos los cálculos de tamaño crítico, y testdisk etc.) hace que sea más difícil de usar de lo que debería ser.

Si usa LVM, tenga mucho cuidado con las instantáneas:use instantáneas de VM/nube si es posible, o investigue ZFS/btrfs para evitar LVM por completo; es posible que ZFS o btrfs estén lo suficientemente maduros en comparación con LVM con instantáneas.

En pocas palabras:si no conoce los problemas enumerados anteriormente y cómo abordarlos, es mejor no usar LVM.

Solución 2:

Yo [+1] en esa publicación, y al menos para mí, creo que la mayoría de los problemas existen. Los he visto mientras ejecutaba unos 100 servidores y unos 100 TB de datos. Para mí, el LVM2 en Linux se siente como una "idea inteligente" que alguien tuvo. Al igual que algunos de estos, a veces resultan "no inteligentes". no tener estados estrictamente separados del kernel y del espacio de usuario (lvmtab) podría haberse sentido muy inteligente para eliminarlo, porque puede haber problemas de corrupción (si no obtiene el código correcto)

Bueno, solo que esta separación estaba ahí por una razón - las diferencias se muestran con el manejo de pérdida de PV y la reactivación en línea de un VG con, por ejemplo, PV faltantes para volver a ponerlos en funcionamiento el manejo del estado no es lo suficientemente bueno. Y ni siquiera me hagan hablar sobre la detección de pérdida de quórum (jaja) o el manejo del estado (si elimino un disco, no se marcará como no disponible. Ni siquiera tener la maldita columna de estado)

Re:estabilidad movimiento de pv ... por qué es

pvmove pérdida de datos

un artículo tan alto en mi blog, ¿hmmm? Justo ahora miro un disco donde los datos físicos de lvm todavía están colgados en el estado desde mediados de pvmove. Creo que ha habido algunas filtraciones, y la idea general es algo bueno. copiar datos de bloque en vivo desde el espacio de usuario es simplemente triste. Una buena cita de la lista de lvm "parece que vgreduce --missing no maneja pvmove" Significa que, de hecho, si un disco se desconecta durante pvmove, la herramienta de administración de lvm cambia de lvm a vi. Ah, y también ha habido un error en el que pvmove continúa después de un error de lectura/escritura de bloque y, de hecho, ya no escribe datos en el dispositivo de destino. ¿Qué diablos?

Re:Instantáneas El CoW se realiza de manera insegura, al actualizar los NUEVOS datos en el área de instantánea lv y luego volver a fusionarse una vez que elimina la instantánea. Esto significa que tiene fuertes picos de IO durante la fusión final de nuevos datos en el LV original y, mucho más importante, por supuesto, también tiene un riesgo mucho mayor de corrupción de datos, porque la instantánea no se romperá una vez que toque el LV original. pared, pero el original.

La ventaja está en el rendimiento, hacer 1 escritura en lugar de 3. Elegir el algoritmo rápido pero menos seguro es algo que obviamente uno espera de personas como VMware y MS, en "Unix" prefiero suponer que las cosas se "hacen bien". no vi muchos problemas de rendimiento siempre que tenga el almacén de respaldo de instantáneas en un diferente unidad de disco que los datos principales (y una copia de seguridad en otra, por supuesto)

Re:Barreras No estoy seguro de si se puede culpar a LVM por eso. Fue un problema de devmapper, hasta donde yo sé. Pero puede haber algo de culpa por no preocuparse realmente por este problema desde al menos el kernel 2.6 hasta el 2.6.33AFAIK Xen es el único hipervisor que usa O_DIRECT para las máquinas virtuales, el problema usado para ser cuando se usó "loop" porque el kernel aún almacenaría en caché usando eso. Virtualbox al menos tiene alguna configuración para deshabilitar cosas como esta y Qemu / KVM generalmente parece permitir el almacenamiento en caché. Todos los FUSE FS también están teniendo problemas allí (sin O_DIRECT)

Re:Tallas Creo que LVM "redondea" el tamaño mostrado. O usa GiB. De todos modos, debe usar el tamaño VG Pe y multiplicarlo por el número LE del LV. Eso debería dar el tamaño de red correcto, y ese problema siempre es un problema de uso. Empeora los sistemas de archivos que no notan tal cosa durante fsck/mount (hola, ext3) o no tienen un "fsck" en línea que funcione -n" (hola, ext3)

Por supuesto, dice que no puede encontrar buenas fuentes para dicha información. "¿Cuántos LE para el VRA?" "¿Cuál es la compensación física para PVRA, VGDA, ... etc"

Comparado con el original, LVM2 es el mejor ejemplo de "Aquellos que no entienden UNIX están condenados a reinventarlo, mal".

Actualización unos meses después:ya he estado en el escenario de "instantánea completa" para una prueba. Si se llenan, la instantánea se bloquea, no el LV original. Me equivoqué allí cuando publiqué esto por primera vez. Recogí información incorrecta de algún documento, o tal vez la había entendido. En mis setups siempre había sido muy paranoico de no dejar que se llenaran y por eso nunca terminé de corregir. También es posible ampliar/reducir las instantáneas, lo cual es una delicia.

Lo que todavía no he podido resolver es cómo identificar la edad de una instantánea. En cuanto a su rendimiento, hay una nota en la página del proyecto fedora "thinp" que dice que la técnica de la instantánea se está revisando para que no se vuelva más lenta. con cada instantánea. No sé cómo lo están implementando.

Solución 3:

Si planea usar instantáneas para las copias de seguridad, prepárese para un gran impacto en el rendimiento cuando la instantánea esté presente. de lo contrario, todo está bien. He estado usando lvm en producción durante un par de años en docenas de servidores, aunque mi razón principal para usarlo es la instantánea atómica, no la capacidad de expandir volúmenes fácilmente.

Por cierto, si va a utilizar una unidad de 1 TB, recuerde la alineación de la partición:esta unidad probablemente tenga sectores físicos de 4 kB.

Solución 4:

Si bien proporciona una ventana interesante sobre el estado de LVM hace más de 10 años, la respuesta aceptada ahora es totalmente obsoleta. Moderno (es decir, LVM posterior a 2012):

• honra las solicitudes de sincronización/barrera
• tiene capacidad de instantáneas rápidas y confiables en forma de lvmthin
• tener almacenamiento en caché SSD estable a través de lvmcache y una política de reescritura rápida para NVMe/NVDIMM/Optane a través de dm-writecache
• optimizador de datos virtuales (vdo ) soporte gracias a lvmvdo
• RAID integrado y por volumen gracias a lvmraid
• alineación automática a 1 MB o 4 MB (dependiendo de la versión), evitando por completo cualquier problema de alineación 4K (a menos que use LVM sobre una partición desalineada)
• excelente soporte para extender un volumen, especialmente al hacerlo agregando otros dispositivos de bloque (lo que simplemente no es posible cuando se usa un sistema de archivos clásico como ext4/xfs encima de una partición simple)
• una lista de correo excelente, amigable y extremadamente útil en [email protected]

Obviamente, esto no significa que siempre tienes para usar LVM:la regla de oro para el almacenamiento es evitar capas innecesarias. Por ejemplo, para máquinas virtuales simples, seguramente puede continuar con la partición clásica únicamente. Pero si valora alguna de las características anteriores, LVM es una herramienta extremadamente útil que debería estar en la caja de herramientas de cualquier administrador de sistemas Linux serio.

Solución 5:

Adán,

Otra ventaja:puede agregar un nuevo volumen físico (PV), mover todos los datos a ese PV y luego eliminar el PV anterior sin interrupciones del servicio. He usado esa capacidad al menos cuatro veces en los últimos cinco años.

Una desventaja que no vi señalada claramente todavía:hay una curva de aprendizaje algo empinada para LVM2. Principalmente en la abstracción que crea entre sus archivos y los medios subyacentes. Si trabaja con unas pocas personas que comparten tareas en un conjunto de servidores, es posible que la complejidad adicional le resulte abrumadora para todo el equipo. Los equipos más grandes dedicados al trabajo de TI generalmente no tendrán ese problema.

Por ejemplo, lo usamos mucho aquí en mi trabajo y nos hemos tomado el tiempo de enseñarle a todo el equipo los conceptos básicos, el lenguaje y los elementos básicos sobre la recuperación de sistemas que no arrancan correctamente.

Una advertencia específica para señalar:si arranca desde un volumen lógico LVM2, dificultará las operaciones de recuperación cuando el servidor se bloquee. Knoppix y sus amigos no siempre tienen las cosas adecuadas para eso. Entonces, decidimos que nuestro directorio /boot estaría en su propia partición y siempre sería pequeño y nativo.

En general, soy fanático de LVM2.