El problema
Una partición de disco no se monta después de un arranque del sistema, ya sea que el reinicio haya sido planificado o no. Antes del reinicio, la partición del disco estaba montada y funcionaba correctamente. El disco se ha montado correctamente después de que otros reinicios del sistema, pero ya no funciona.
Este comportamiento puede ocurrir independientemente del tipo de sistema de archivos en la partición y no está relacionado con el tipo de sistema de archivos. Se han informado fallas de discos con sistemas de archivos EXT4 u OCFS2, pero pueden ocurrir con cualquier tipo de sistema de archivos.
Una entrada típica en el archivo /etc/fstab podría ser similar a:
/dev/sda1 /mydir ext4 defaults 0 0 /dev/mapper/mpath2 /otherdir ocfs2 _netdev 0 0
o varias combinaciones de estos.
La solución
Las unidades de disco y las particiones se direccionan geográficamente en Linux, de acuerdo con su posición en el bus y el orden de detección. Los dispositivos SAN son especialmente vulnerables a los cambios en el orden de detección debido a la variación del tiempo de reinicio para la SAN o el cliente.
Los nombres de archivo en Linux, normalmente en el directorio /dev/, se asignan dinámicamente cada vez que se inicia el sistema. A medida que se inicia el kernel, se detecta cada dispositivo disponible y se envía una notificación al subsistema UDEV (administración de dispositivos de espacio de usuario). Al comparar la información en la identificación del dispositivo del kernel con los conjuntos de reglas de UDEV en el directorio /etc/udev/rules.d, UDEV asigna un nombre al dispositivo y crea un nodo de dispositivo como /dev/sda o /dev/mapper/mpath1 para que que las aplicaciones pueden acceder al dispositivo. Si el dispositivo detectado es un dispositivo con estructura de bloques, a menudo tiene particiones que contienen sistemas de archivos que se pueden montar de acuerdo con las especificaciones del archivo /etc/fstab.
Aunque Linux hace todo lo posible para mantener el mismo nombre de dispositivo en los reinicios del sistema, los cambios en el entorno externo pueden afectar las opciones de nombre reales. Por ejemplo:la misma partición SAN podría ser /dev/sda en un cliente, pero /dev/sdf en otro nodo de clúster, según el orden en que cada host detectó el dispositivo o en qué enlace de múltiples rutas se conecta primero. Un nodo suele descubrir sus dispositivos en el mismo orden en cada arranque, pero esto no está garantizado. Se necesita un método para garantizar una identificación persistente y predecible del dispositivo.
Aunque Linux intenta reasignar el mismo nombre de dispositivo en cada reinicio, no existe tal coordinación entre los nodos del clúster. Una partición que aparece de manera confiable como /dev/sda1 en un nodo de clúster podría aparecer fácil y legítimamente de manera consistente como /dev/sdj en otro nodo de clúster. Esto puede hacer que la administración del sistema en todo el clúster sea más difícil de lo necesario. La solución proporcionada a continuación también es aplicable en clústeres donde no ocurre este problema de reinicio.
Hay técnicas alternativas disponibles para tener un nombre de dispositivo persistente y predecible. Se presentan a continuación, en orden de dificultad.
Montaje por etiqueta
Muchos tipos de sistemas de archivos admiten la asociación de una cadena o etiqueta arbitraria con cada sistema de archivos. El sistema de archivos EXT3 es un ejemplo:
# /sbin/e2label /dev/sda5 /home
Es común ver una entrada en /etc/fstab similar a esta:
LABEL=/HOME /home auto defaults 0 0
para localizar la partición de disco etiquetada /HOME, independientemente del dispositivo en el que aparezca.
Los sistemas de archivos OCFS2 también proporcionan una etiqueta reconocible que se puede usar de manera similar. Consulte el ejemplo de OCFS2 a continuación para saber cómo determinar la etiqueta OCFS2.
Montaje por UUID
Muchos tipos de sistemas de archivos asignan un identificador único universal, o UUID, a cada partición de disco formateada. Los sistemas de archivos EXT3 y OCFS2 son ejemplos de esto. El UUID generalmente se asigna automáticamente y, por lo general, se desaconseja que los administradores del sistema cambien manualmente el valor.
En un EXT3 y otros tipos de sistemas de archivos, use la utilidad blkid provista como parte del paquete RPM e2fsprogs. Para nuestro ejemplo, la salida se ve así:
# /sbin/blkid /dev/sda5 /dev/sda5: LABEL="/home" UUID="0c960108-7649-4d8c-a28c-2f75e2f906d3" SEC_TYPE="ext2" TYPE="ext3"
Tenga en cuenta que el UUID es, estrictamente hablando, solo los dígitos hexadecimales. Los caracteres "-" son simplemente signos de puntuación que deben ignorarse.
En un sistema de archivos OCFS2, la utilidad fsck.ocfs2 siempre notifica el UUID. Esta utilidad se puede usar de manera segura en una partición de disco montada si se usa el interruptor "-n" para garantizar una prueba de solo lectura:
# /sbin/fsck.ocfs2 -n /dev/hda1 Checking OCFS2 filesystem in /dev/hda1: label: OCFS2 uuid: bc d0 de d0 58 ea 43 11 bd a9 e0 66 e6 cb 37 b4 number of blocks: 209632 bytes per block: 1024 number of clusters: 52408 bytes per cluster: 4096 max slots: 4 /dev/hda1 is clean. It will be checked after 20 additional mounts.
Nuevamente, tenga en cuenta que el UUID propiamente dicho es una cadena de dígitos hexadecimales. Aquí están puntuados por espacios, pero el UUID real son solo los dígitos. Para obtener solo el UUID, basta con un breve programa awk(1):
# /sbin/fsck.ocfs2 -n /dev/hda1 | /bin/awk '/uuid/ { $1 = ""; gsub( / /, "" ); print }'
bcd0ded058ea4311bda9e066e6cb37b4 Ahora que tenemos el UUID, una entrada de /etc/fstab como estas montaría las particiones EXT3 u OCFS2:
UUID=bcd0ded058ea4311bda9e066e6cb37b4 /ocfs2 ocfs2 _netdev 0 2 UUID=0c96010876494d8ca28c2f75e2f906d3 /home ext3 defaults 0 2
Dado que el UUID se almacena en la propia partición del disco, no importa si cambia el nombre real del dispositivo, tenemos un método predecible y persistente garantizado para acceder a él.
Uso de conjuntos de reglas UDEV
Otro método para tener nombres de dispositivos persistentes y predecibles es aprovechar el mismo servicio UDEV que usa el kernel para asignar los nombres de los dispositivos. Esto implica crear una regla de coincidencia de UDEV que utilice los atributos del dispositivo para identificar el dispositivo y luego crear un nodo de dispositivo para él. A menudo, la regla simplemente crea un enlace simbólico al nodo de dispositivo real de bajo nivel que asigna el kernel.
Esta es la técnica utilizada para implementar los dispositivos multirruta del mapeador de dispositivos. El kernel crea un dispositivo /dev/dm-X; luego, las reglas de UDEV y el demonio de rutas múltiples crean un enlace /dev/mpath/
El tipo de nombre de archivo /dev/mapper/ que se crea se controla mediante la configuración de nombres_de_usuario del archivo /etc/multipath.conf. La configuración predeterminada es:
default {
user_friendly_names yes
}
lo cual, por extraño que parezca, crea los nombres /dev/mapper/mpathN totalmente sin sentido. Al comentar esto, se utilizan los nombres de formulario /dev/mapper/
A continuación se muestra un ejemplo de una regla de coincidencia de UDEV. La línea comienza con una serie de predicados o expresiones coincidentes; estos están marcados por los operadores “==”. Si todos los predicados coinciden con los del dispositivo descubierto, se toman las acciones indicadas por las cláusulas "=".
SYSFS{vendor}=="iriver" SYSFS{model}=="T10" OWNER="user" MODE="0600" SYMLINK+="iriver%n" Este ejemplo crea el enlace simbólico /dev/iriver0 cuando el primer reproductor IRiver T10 se conecta a un puerto USB. El dispositivo será propiedad del usuario con permisos de acceso a archivos 0600. El subsistema USB nota que el dispositivo se ha conectado y notifica al kernel; los atributos descubiertos sobre el dispositivo también se pasan al kernel. Esta información eventualmente llega al subsistema UDEV que comienza a leer los conjuntos de reglas en /etc/udev/rules.d y hace coincidir los atributos del dispositivo con los predicados de cada regla. Si todos los predicados coinciden con una regla, se ejecuta cualquier acción especificada por esa regla.
La documentación sobre el sistema UDEV, incluida la sintaxis para escribir una regla UDEV, está disponible en línea a través de la página del manual de udev.
La parte desafiante de escribir una regla UDEV es saber qué atributos están disponibles para que la regla pueda identificar correctamente el dispositivo. La utilidad udevinfo mostrará el nombre del dispositivo y los atributos disponibles para la regla. Para nuestro ejemplo, verificar /var/log/messages muestra que el dispositivo IRiver se detectó como un dispositivo de bloque y se le asignó el nombre /dev/sdb. Ahora, podemos obtener toda la información y los atributos del dispositivo mirando debajo de la información del sistema /block/sdb:
# /usr/bin/udevinfo -q all -p /block/sdb P: /block/sdb N: sdb S: disk/by-id/usb-iriver_T10 S: disk/by-path/pci-0000:00:07.2-usb-0:1:1.0-scsi-0:0:0:0 E: ID_VENDOR=iriver E: ID_MODEL=T10 E: ID_REVISION=1.00 E: ID_SERIAL=iriver_T10 E: ID_TYPE=disk E: ID_BUS=usb E: ID_PATH=pci-0000:00:07.2-usb-0:1:1.0-scsi-0:0:0:0Nota que la ruta es relativa al directorio /sys/, no a la raíz tradicional. El nombre completo del archivo sería /sys/block/sdb pero udevinfo asume la parte /sys.
Elegir el conjunto mínimo de atributos puede ser complicado, pero evite la tentación de especificar en exceso. Nuestra elección aquí es usar el nombre del proveedor y el nombre del modelo, pero se puede usar cualquier conjunto de atributos que identifique el dispositivo objeto. Una vez que se eligen los predicados y las acciones, coloque sus reglas en sus propios archivos en el directorio /etc/udev/rules.d. No modifique un conjunto de reglas de la distribución o sus cambios pueden perderse cuando se actualice el paquete. En nuestro ejemplo, usamos /etc/udev/rules.d/49-iriver.rules para el nombre de archivo.
Con su regla UDEV implementada, use la utilidad udevtest para simular una ejecución de UDEV y mostrar lo que se haría.