11.7. Sistemas de archivos y almacenamiento
El sistema de archivos /boot no puede colocarse en LVM
No se puede colocar el sistema de archivos /boot en un volumen lógico LVM. Esta limitación existe por las siguientes razones:
-
En los sistemas EFI, el EFI System Partition sirve convencionalmente como sistema de archivos
/boot. El estándar uEFI requiere un tipo de partición GPT específico y un tipo de sistema de archivos específico para esta partición. -
RHEL 8 utiliza Boot Loader Specification (BLS) para las entradas de arranque del sistema. Esta especificación requiere que el sistema de archivos
/bootsea legible por el firmware de la plataforma. En los sistemas EFI, el firmware de la plataforma solo puede leer la configuración de/bootdefinida por el estándar uEFI. - El soporte para volúmenes lógicos LVM en el gestor de arranque GRUB 2 es incompleto. Red Hat no planea mejorar el soporte porque el número de casos de uso para la función está disminuyendo debido a estándares como uEFI y BLS.
Red Hat no planea soportar /boot en LVM. En su lugar, Red Hat proporciona herramientas para gestionar las instantáneas del sistema y la reversión que no necesitan que el sistema de archivos /boot se coloque en un volumen lógico LVM.
(BZ#1496229)
LVM ya no permite crear grupos de volúmenes con tamaños de bloque mixtos
Las utilidades de LVM como vgcreate o vgextend ya no permiten crear grupos de volúmenes (VG) en los que los volúmenes físicos (PV) tienen diferentes tamaños de bloque lógicos. LVM ha adoptado este cambio porque los sistemas de archivos no se pueden montar si se extiende el volumen lógico (LV) subyacente con un PV de un tamaño de bloque diferente.
Para volver a habilitar la creación de VGs con tamaños de bloque mixtos, establezca la opción allow_mixed_block_sizes=1 en el archivo lvm.conf.
DM Multipath podría no iniciarse cuando se conectan demasiados LUNs
El servicio multipathd puede agotarse y no iniciarse si hay demasiadas unidades lógicas (LUNs) conectadas al sistema. El número exacto de LUNs que causa el problema depende de varios factores, incluyendo el número de dispositivos, el tiempo de respuesta de la matriz de almacenamiento, la configuración de la memoria y la CPU, y la carga del sistema.
Para solucionar el problema, aumente el valor del tiempo de espera en el archivo de la unidad multipathd:
Abra la unidad
multipathden el editor de unidades:# systemctl edit multipathd
Introduzca la siguiente configuración para anular el valor del tiempo de espera:
[Service] TimeoutSec=300
Red Hat recomienda aumentar el valor a 300 desde el valor predeterminado de 90, pero también puede probar otros valores por encima de 90.
- Guarde el archivo en el editor.
Recarga las unidades
systemdpara aplicar el cambio:# systemctl daemon-reload
Como resultado, multipathd puede ahora arrancar con éxito con un mayor número de LUNs.
(BZ#1797660)
Limitaciones de la caché de escriturade LVM
El método de almacenamiento en caché de LVM tiene las siguientes limitaciones, que no están presentes en el método de caché:
-
No se puede tomar una instantánea de un volumen lógico mientras el volumen lógico esté utilizando
la caché de escritura. -
No se puede adjuntar o quitar
la caché de escrituramientras un volumen lógico está activo. Cuando se adjunta
la caché de escrituraa un volumen lógico inactivo, se debe utilizar un tamaño de bloquede caché de escrituraque coincida con el tamaño de bloque del sistema de archivos existente.Para más detalles, consulte la página man de
lvmcache(7).-
No se puede redimensionar un volumen lógico mientras
la caché de escrituraestá conectada a él. -
No se pueden utilizar los comandos
pvmoveen dispositivos que se utilizan conwritecache. -
No se pueden utilizar volúmenes lógicos con
writecacheen combinación con thin pools o VDO.
(JIRA:RHELPLAN-27987, BZ#1798631, BZ#1808012)
Los dispositivos de espejo LVM que almacenan un volumen LUKS a veces no responden
Los dispositivos LVM en espejo con un tipo de segmento en espejo que almacenan un volumen LUKS pueden dejar de responder bajo ciertas condiciones. Los dispositivos que no responden rechazan todas las operaciones de E/S.
Para solucionar el problema, Red Hat recomienda que utilice dispositivos RAID 1 de LVM con un tipo de segmento raid1 en lugar de espejo si necesita apilar volúmenes LUKS sobre el almacenamiento resistente definido por software.
El tipo de segmento raid1 es el tipo de configuración RAID por defecto y sustituye al espejo como solución recomendada.
Para convertir los dispositivos espejo en raid, consulte Convertir un dispositivo LVM espejo en un dispositivo RAID1.
(BZ#1730502)
Un parche de NFS 4.0 puede reducir el rendimiento con una carga de trabajo abierta
Anteriormente, se corrigió un error que, en algunos casos, podía hacer que una operación de apertura de NFS pasara por alto el hecho de que un archivo había sido eliminado o renombrado en el servidor. Sin embargo, la corrección puede causar un rendimiento más lento con cargas de trabajo que requieren muchas operaciones abiertas. Para solucionar este problema, puede ser útil utilizar la versión 4.1 o superior de NFS, que ha sido mejorada para conceder delegaciones a los clientes en más casos, permitiendo a los clientes realizar operaciones de apertura de forma local, rápida y segura.
(BZ#1748451)
