LVM peligros y advertencias

Recientemente comencé a usar LVM en algunos servidores para discos duros de más de 1 TB. Son útiles, ampliables y bastante fáciles de instalar. Sin embargo, no pude encontrar ningún dato sobre los peligros y las advertencias de LVM.

¿Cuáles son las desventajas de usar LVM?

Resumen

Riesgos de usar LVM:

• Vulnerable para escribir problemas de almacenamiento en caché con SSD o hipervisor VM
• Es más difícil recuperar datos debido a estructuras en disco más complejas
• Es 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 dos primeros 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 PSU o el UPS), es posible que tenga que 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 que la configuración de almacenamiento en caché de escritura sea correcta para evitar que LVM realmente reduzca el tiempo de actividad.

- Actualizado en diciembre de 2018: material de instantáneas actualizado, incluida la estabilidad de ZFS y btrfs como alternativas a las instantáneas de LVM

Mitigar los riesgos.

LVM aún puede funcionar bien si usted:

• Obtenga su configuración de almacenamiento en caché de escritura directamente en hipervisor, kernel y SSD
• Evite las instantáneas de LVM
• Use 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 en el disco duro debido a hipervisores de VM, almacenamiento en caché de disco o antiguos núcleos de Linux , y hace que sea más difícil recuperar datos debido a estructuras en disco más complejas; consulte a continuación para obtener más detalles. He visto que las configuraciones completas de LVM en varios discos se corrompen sin ninguna posibilidad de recuperación, y LVM más el almacenamiento en caché de escritura en el disco duro es una combinación peligrosa.

• El almacenamiento en caché de escritura y el reordenamiento de escritura por parte del disco duro son importantes para un buen rendimiento, pero pueden fallar al limpiar correctamente los bloques en el disco debido a los hipervisores de VM, el almacenamiento en caché de escritura del disco duro, los viejos núcleos de Linux, etc.
  • Las barreras de escritura significan que el núcleo 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 bloqueo. Dichas barreras pueden usar una operación FUA (Force Unit Access) 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 una cola eficiente de comandos etiquetados / nativos (emitiendo múltiples solicitudes de E / S de disco a la vez) para permitir que el disco duro realice un pedido inteligente de escritura sin aumentar el riesgo de pérdida de datos.
• Los hipervisores de VM pueden tener problemas similares: ejecutar LVM en un invitado Linux encima de un hipervisor de VM como VMware, Xen , KVM, Hyper-V o VirtualBox puede crear problemas similares a un kernel sin barreras de escritura, debido al almacenamiento en caché de escritura y re escritura -ordenar. Verifique cuidadosamente la documentación de su hipervisor para una opción de "vaciado al disco" o de caché de escritura (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 cualquier descarga de disco del invitado.
• Los servidores empresariales con LVM siempre deben usar un controlador RAID con respaldo de batería y deshabilitar el almacenamiento en caché de escritura en el disco duro (el controlador tiene caché de escritura con respaldo de batería que es rápido y seguro) - vea este comentario del autor de esta entrada de preguntas frecuentes de XFS . También puede ser seguro desactivar las barreras de escritura en el núcleo, pero se recomienda realizar pruebas.
• Si no tiene un controlador RAID respaldado por batería, deshabilitar el almacenamiento en caché de escritura del disco duro disminuirá significativamente las escrituras pero hará que LVM sea seguro. También debe usar el equivalente de la data=orderedopción de ext3 (o data=journalpara mayor seguridad), además barrier=1de asegurarse de que el almacenamiento en caché del núcleo no afecte la integridad. (O utilice ext4 que habilita las barreras de forma predeterminada ). Esta es la opción más simple y proporciona una buena integridad de los datos al costo del rendimiento. (Linux cambió la opción ext3 predeterminada a la más peligrosa hace data=writebackun tiempo, así que no confíe en la configuración predeterminada para el FS).
• Para deshabilitar el almacenamiento en caché de escritura en el disco duro : agregue hdparm -q -W0 /dev/sdXtodas 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 bueno sobre este tema), una unidad SATA puede olvidar esta configuración después de una recuperación de error de unidad, por lo que debe usar SCSI / SAS, o si debe usar SATA, coloque el comando hdparm en un trabajo cron que se ejecuta cada minuto más o menos.
• Para mantener el almacenamiento en caché de escritura SSD / disco duro habilitado 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.
• El UPS es crítico tanto para la empresa como para SOHO, pero no lo suficiente como para hacer que LVM sea seguro: cualquier cosa que cause un bloqueo duro o una pérdida de energía (por ejemplo, falla del UPS, falla de la PSU o agotamiento de la batería de la computadora portátil) puede perder datos en los cachés del disco duro.
• Núcleos de Linux muy antiguos (2.6.x de 2009) : existe un soporte de barrera de escritura incompleto en versiones de kernel muy antiguas, 2.6.32 y anteriores ( 2.6.31 tiene algún 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 están parcheados para estos problemas, una gran cantidad de metadatos FS (incluidas las publicaciones periódicas) podrían perderse por un bloqueo duro que deja datos en los búferes de escritura de los discos duros (por ejemplo, 32 MB por unidad para unidades SATA comunes). La pérdida de 32 MB de los metadatos FS y los datos del diario escritos más recientemente, que el núcleo cree que ya está en el disco, generalmente significa mucha corrupción FS y, por lo tanto, pérdida de datos.
• Resumen: debe tener cuidado con el sistema de archivos, RAID, hipervisor VM y la configuración del disco duro / SSD utilizados con LVM. Debe tener copias de seguridad muy buenas si está utilizando LVM, y asegúrese de hacer una copia de seguridad específica de los metadatos de LVM, configuración de partición física, MBR y sectores de inicio de volumen. También es aconsejable 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 hacer frente a unidades mentirosas)

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

También debe asegurarse de que la configuración RAID, la configuración del hipervisor VM y el sistema de archivos utilizan barreras de escritura (es decir, requiere que la unidad elimine las escrituras pendientes antes y después de las metadatos / escrituras de diario clave). XFS usa barreras por defecto, pero ext3 no , por lo que con ext3 debe usar barrier=1en las opciones de montaje, y aún usar data=orderedo data=journalcomo se indicó anteriormente.

• Desafortunadamente, algunos discos duros y SSD mienten sobre si realmente han vaciado su caché en el disco (particularmente unidades más antiguas, pero incluyendo 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 de disco (script Perl), o vea este fondo con otra herramienta de prueba para reordenar la 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 RAID de software; estas pruebas realmente ejercitan toda la pila de almacenamiento.
• Las unidades SATA más recientes que admiten Native Command Queuing (NCQ) pueden ser menos propensas a mentir , 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 la cola de comandos etiquetados SCSI , similar al NCQ de SATA).
• Si sus discos duros o SSD mienten sobre vaciar su caché al 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 volúmenes y RAID de software , no solo LVM.

Los SSD son problemáticos porque el uso de caché de escritura es crítico para la vida útil del SSD. Es mejor usar un SSD que tenga un supercondensador (para permitir el vaciado de la memoria caché en caso de falla de energía, y por lo tanto, permitir que la memoria caché sea reescrita y no reescrita).

• 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 Escrituras confiables son buenas fuentes de información. Los SSD del consumidor pueden tener problemas importantes de almacenamiento en caché de escritura que causarán la pérdida de datos, y no incluyen supercondensadores, por lo que son vulnerables a fallas de alimentación que causan corrupción.

Configuración de unidad de formato avanzado : almacenamiento en caché de escritura, alineación, RAID, GPT

• Con las unidades de formato avanzado más nuevas que usan 4 sectores físicos de KiB, puede ser importante mantener habilitado el almacenamiento en caché de escritura de unidades, ya que la mayoría de estas unidades emulan actualmente sectores lógicos de 512 bytes ( "emulación de 512" ), y algunos incluso afirman tener 512 bytes físicos. sectores mientras realmente usa 4 KiB.
• Apagar la memoria caché de escritura de una unidad de formato avanzado puede causar un impacto muy grande en el rendimiento si la aplicación / kernel está haciendo escrituras de 512 bytes, ya que estas unidades dependen de la memoria caché para acumular 8 x 512 bytes de escritura antes de hacer un solo 4 KiB físico escribir. Se recomienda realizar pruebas para confirmar cualquier impacto si deshabilita la memoria caché.
• Alinear los LV en un límite de 4 KiB es importante para el rendimiento, pero debe suceder automáticamente siempre que las particiones subyacentes para los PV estén alineadas, ya que las extensiones físicas (PE) de LVM son 4 MiB por defecto. Aquí se debe considerar RAID: esta página de configuración de RAID de software y LVM sugiere colocar el superbloque RAID al final del volumen y (si es necesario) usar una opción pvcreatepara alinear los PV. Este hilo de la lista de correo electrónico de LVM apunta al trabajo realizado en los núcleos durante 2011 y al problema de las escrituras de bloque parcial al mezclar discos con 512 bytes y 4 sectores KiB en un solo LV.
• La partición GPT con formato avanzado necesita cuidados, especialmente para los discos de arranque + raíz, para garantizar que la primera partición LVM (PV) comience en un límite de 4 KiB.

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

• Cualquier recuperación de los datos de LVM requerida después de un bloqueo o pérdida de energía (debido al 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 respaldar sus metadatos /etc/lvm, lo 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 de la copia de seguridad. Esto implica mucho más tiempo de inactividad que un fsck rápido basado en el 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 tallado de archivos como PhotoRec y muchas otras funcionarían ya que omiten el sistema de archivos para volver a ensamblar archivos de bloques de datos, pero este es un enfoque de último nivel y bajo nivel para datos valiosos, y funciona menos bien con archivos fragmentados.
• La recuperación manual de LVM es posible en algunos casos, pero es compleja y lleva mucho tiempo; vea este ejemplo y esto , esto y esto para saber cómo recuperarse.

Es más difícil cambiar el tamaño de los sistemas de archivos correctamente : el cambio de tamaño del sistema de archivos fácil a menudo se brinda como un beneficio de LVM, pero debe 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 todavía activo, y en algunos casos con el FS montado, pero nunca me arriesgaría a este último sin copias de seguridad actualizadas y utilizando comandos previamente probados en un servidor equivalente (por ejemplo, clon de recuperación ante desastres del servidor de producción).

• Actualización: las versiones más recientes lvextendadmiten la opción -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 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 algo 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 de la herramienta de cambio de tamaño de FS, por ejemplo, resize2fspara ext3, y para lvextendo 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 diferentes herramientas redondean los tamaños hacia arriba o hacia abajo.
• Si no realiza los cálculos correctamente (o usa algunos pasos adicionales más allá de los más obvios), puede terminar con un FS que es demasiado grande para el LV. Todo parecerá bien durante meses o años, hasta que complete completamente el FS, momento en el que obtendrá una corrupción grave, y a menos que sea consciente de este problema, es difícil averiguar por qué, ya que para entonces también puede tener errores de disco reales. eso nubla la situación. (Es posible que este problema solo afecte a 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 del LV debería ser mayor que el tamaño del FS en 2 veces el tamaño de la extensión física (PE) del LVM, pero revise el enlace de arriba para obtener detalles ya que la fuente de esto no es autorizada. A menudo, permitir 8 MiB es suficiente, pero puede ser mejor permitir más, por ejemplo, 100 MiB o 1 GiB, solo para estar seguro. Para verificar el tamaño de PE y su volumen lógico + tamaños de FS, usando 4 KiB = 4096 bloques de 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, supone 4 tamaños de bloque de KiB FS:
  tune2fs -l /dev/myVGname/myLVname | grep 'Block count'

• Por el contrario, una configuración que no es 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 parteddesde el shell.

  • A menudo es mejor usar Gparted Live CD o Parted Magic , ya que estos tienen un Gparted y kernel reciente y a menudo más libre de errores que la versión de distribución. núcleo. Si usa la distribución Gparted de la distribución, asegúrese de reiniciar justo después de cambiar las particiones para que la vista del núcleo sea correcta.

Las instantáneas son difíciles de usar, lentas y con errores : si la instantánea se queda sin espacio preasignado, se descarta automáticamente . Cada instantánea de un LV dado es un delta contra ese LV (no contra las instantáneas anteriores) que puede requerir mucho espacio cuando se capturan 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 sea del 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 (es decir, 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 importantes, por ejemplo, en algunos casos pueden hacer que el arranque sea muy lento o hacer que el arranque falle por completo (porque el núcleo puede agotar el tiempo de espera del FS raíz cuando es una instantánea LVM [corregido en la initramfs-toolsactualización de Debian , marzo de 2015] )

• Sin embargo, muchos errores de condición de carrera de instantánea aparentemente se solucionaron en 2015.
• LVM sin instantáneas generalmente parece bastante depurado, tal vez porque las instantáneas no se usan tanto como las características principales.

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

Instantáneas de VM / nube:

• Si está utilizando un hipervisor VM o un proveedor de nube IaaS (por ejemplo, VMware, VirtualBox o Amazon EC2 / EBS), sus instantáneas son a menudo una alternativa mucho mejor a las instantáneas LVM. Puede tomar fácilmente una instantánea con fines de respaldo (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 el metal desnudo (pero ZFS parece mucho más maduro, solo más problemas para instalar):

  • ZFS: ahora hay una implementación de kernel ZFS , que ha estado en uso durante algunos años
  • btrfs : todavía no está listo para su uso en producción ( incluso en openSUSE que lo envía por defecto y tiene un equipo dedicado a btrfs), mientras que RHEL ha dejado de admitirlo), y sus herramientas fsck y de reparación aún están en desarrollo.

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

Las instantáneas se pueden usar para proporcionar una fuente consistente para las copias de seguridad, siempre que tenga cuidado con el espacio asignado (idealmente, la instantánea es del mismo tamaño que el LV que se está respaldando). La excelente rsnapshot (desde 1.3.1) incluso gestiona la creación / eliminación de instantáneas LVM por usted; vea este CÓMO en 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: tome una instantánea del LV y fsck de la instantánea, mientras sigue usando el FS principal sin 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.

Debería "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 cree la instantánea.

Conclusiones

A pesar de todo esto, todavía uso LVM en algunos sistemas, pero para una configuración de escritorio prefiero 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 en la configuración de almacenamiento en caché de escritura debido a hipervisores VM, almacenamiento en caché de 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 ( gpartedincluidos los cálculos de tamaño crítico, testdisketc.) 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 btrs sea lo suficientemente maduro 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.

Yo [+1] esa publicación, y al menos para mí creo que la mayoría de los problemas existen. Los vi mientras ejecutaban unos 100 servidores y unos 100 TB de datos. Para mí, el LVM2 en Linux se siente como una "idea inteligente" que alguien tuvo. Como algunos de estos, a veces resultan ser "no inteligentes". Es decir, no haber separado estrictamente los estados del kernel y del espacio de usuario (lvmtab) podría haber sido realmente inteligente de eliminar, porque puede haber problemas de corrupción (si no obtiene el código correcto)

Bueno, solo que esta separación estaba allí por una razón : las diferencias se muestran con el manejo de la pérdida de PV y la reactivación en línea de un VG con, por ejemplo, PV faltantes para volver a ponerlos en juego: ¿Qué es una brisa en los "LVM originales" (AIX , HP-UX) se convierte en basura en LVM2 ya que el manejo del estado no es lo suficientemente bueno. Y ni siquiera me hable de detección de pérdida de quórum (jaja) o manejo de estado (si elimino un disco, eso no se marcará como no disponible. Ni siquiera tiene la maldita columna de estado)

Re: estabilidad pvmove ... porque es

pvmove pérdida de datos

un artículo tan destacado en mi blog, ¿hmmm? Justo ahora miro un disco donde los datos de lvm físicos todavía están colgados en el estado desde mediados de movimiento. Creo que ha habido algunos memleaks, y la idea general de que es bueno copiar datos de bloque en vivo desde el espacio de usuario es simplemente triste. Buena cita de la lista lvm "parece que vgreduce --missing no maneja pvmove" Significa, 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. WTF?

Re: Instantáneas El CoW se realiza de manera insegura, actualizando los NUEVOS datos en el área de la instantánea lv y luego fusionándolos una vez que elimine el complemento. Esto significa que tiene fuertes picos de E / S 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 no se romperá la instantánea una vez que golpee el pared, pero la original.

La ventaja está en el rendimiento, haciendo 1 escritura en lugar de 3. Elegir el algoritmo rápido pero inseguro es algo que obviamente se espera de personas como VMware y MS, en "Unix" Prefiero adivinar que las cosas se "harían bien". No vi muchos problemas de rendimiento siempre que tenga el almacén de copias de seguridad de instantáneas en una unidad de disco diferente a la de los datos primarios (y, por supuesto, haga una copia de seguridad en otra unidad)

Re: Barreras No estoy seguro si se puede culpar a LVM. Era un problema de devmapper, que yo sepa. Pero puede haber algo de culpa por no preocuparse realmente por este problema desde al menos el kernel 2.6 hasta 2.6.33. AFAIK Xen es el único hipervisor que usa O_DIRECT para las máquinas virtuales, el problema solía ser cuando se usaba "loop" porque el kernel aún se 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 tienen problemas allí (no O_DIRECT)

Re: Tamaños Creo que LVM hace "redondeo" del 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. Se agrava por los sistemas de archivos que no notan tal cosa durante fsck / mount (hello, ext3) o no tienen un "fsck -n" en línea que funciona (hello, ext3)

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

En comparación con el original, LVM2 es el principal ejemplo de "Aquellos que no entienden UNIX están condenados a reinventarlo, mal".

Actualización unos meses más tarde: hasta ahora he llegado al 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 lo había entendido. En mis configuraciones siempre había sido muy paranoico para no dejar que se llenaran, por lo que nunca terminé corregido. También es posible ampliar / reducir las instantáneas, lo cual es una delicia.

Lo que aún 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 sea más lenta con cada instantánea. No sé cómo lo están implementando.

si planea usar instantáneas para copias de seguridad, esté preparado para un mayor impacto en el rendimiento cuando esté presente la instantánea. Lea más aquí . 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 usar una unidad de 1TB, recuerde la alineación de la partición: esta unidad probablemente tenga sectores físicos de 4kB.

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 pronunciada 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, puede encontrar la complejidad adicional abrumadora para su equipo en general. Los equipos más grandes dedicados al trabajo de TI generalmente no tendrán ese problema.

Por ejemplo, lo usamos ampliamente aquí en mi trabajo y nos hemos tomado el tiempo para enseñarle a todo el equipo los conceptos básicos, el lenguaje y los elementos esenciales esenciales para recuperar sistemas que no se inician 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 falla. 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.