Red Hat Summit Red Hat SummitApoyoConsolaDesarrolladoresIniciar una pruebaContacto

Gestión de sistemas de archivos

Red Hat Enterprise Linux 8

Creación, modificación y administración de sistemas de archivos en Red Hat Enterprise Linux 8

Resumen

Esta colección de documentación proporciona instrucciones sobre cómo gestionar eficazmente los sistemas de archivos en Red Hat Enterprise Linux 8.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a sustituir el lenguaje problemático en nuestro código, documentación y propiedades web. Estamos empezando con estos cuatro términos: maestro, esclavo, lista negra y lista blanca. Debido a la enormidad de este esfuerzo, estos cambios se implementarán gradualmente a lo largo de varias versiones próximas. Para más detalles, consulte el mensaje de nuestro CTO Chris Wright.

Proporcionar comentarios sobre la documentación de Red Hat

Agradecemos su opinión sobre nuestra documentación. Por favor, díganos cómo podemos mejorarla. Para ello:

  • Para comentarios sencillos sobre pasajes concretos:

    1. Asegúrese de que está viendo la documentación en el formato Multi-page HTML. Además, asegúrese de ver el botón Feedback en la esquina superior derecha del documento.
    2. Utilice el cursor del ratón para resaltar la parte del texto que desea comentar.
    3. Haga clic en la ventana emergente Add Feedback que aparece debajo del texto resaltado.
    4. Siga las instrucciones mostradas.

  • Para enviar comentarios más complejos, cree un ticket de Bugzilla:

    1. Vaya al sitio web de Bugzilla.
    2. Como componente, utilice Documentation.
    3. Rellene el campo Description con su sugerencia de mejora. Incluya un enlace a la(s) parte(s) pertinente(s) de la documentación.
    4. Haga clic en Submit Bug.

Capítulo 1. Resumen de los sistemas de archivos disponibles

La elección del sistema de archivos apropiado para su aplicación es una decisión importante debido al gran número de opciones disponibles y las compensaciones involucradas. Este capítulo describe algunos de los sistemas de archivos que se entregan con Red Hat Enterprise Linux 8 y proporciona antecedentes históricos y recomendaciones sobre el sistema de archivos adecuado para su aplicación.

1.1. Tipos de sistemas de archivos

Red Hat Enterprise Linux 8 soporta una variedad de sistemas de archivos (FS). Los diferentes tipos de sistemas de archivos resuelven diferentes tipos de problemas y su uso es específico de la aplicación. En el nivel más general, los sistemas de archivos disponibles pueden ser agrupados en los siguientes tipos principales:

Tabla 1.1. Tipos de sistemas de archivos y sus casos de uso
TipoSistema de archivosAtributos y casos de uso

Disco o FS local

XFS

XFS es el sistema de archivos por defecto en RHEL. Debido a que presenta los archivos como extensiones, es menos vulnerable a la fragmentación que ext4. Red Hat recomienda desplegar XFS como su sistema de archivos local a menos que haya razones específicas para hacer lo contrario: por ejemplo, compatibilidad o casos de esquina en torno al rendimiento.

ext4

ext4 tiene la ventaja de la longevidad en Linux. Por lo tanto, es soportado por casi todas las aplicaciones de Linux. En la mayoría de los casos, rivaliza con XFS en cuanto a rendimiento. ext4 se utiliza habitualmente para los directorios personales.

FS en red o cliente-servidor

NFS

Utilice NFS para compartir archivos entre varios sistemas de la misma red.

SMB

Utiliza SMB para compartir archivos con sistemas Microsoft Windows.

Almacenamiento compartido o disco compartido FS

GFS2

GFS2 proporciona acceso de escritura compartido a los miembros de un clúster informático. El énfasis está en la estabilidad y la fiabilidad, con la experiencia funcional de un sistema de archivos local como sea posible. SAS Grid, Tibco MQ, IBM Websphere MQ y Red Hat Active MQ se han implantado con éxito en GFS2.

FS de gestión de volumen

Stratis (avance tecnológico)

Stratis es un gestor de volúmenes construido sobre una combinación de XFS y LVM. El propósito de Stratis es emular las capacidades ofrecidas por los sistemas de archivos de gestión de volúmenes como Btrfs y ZFS. Es posible construir esta pila manualmente, pero Stratis reduce la complejidad de la configuración, implementa las mejores prácticas y consolida la información de errores.

1.2. Sistemas de archivos locales

Los sistemas de archivos locales son sistemas de archivos que se ejecutan en un único servidor local y se conectan directamente al almacenamiento.

Por ejemplo, un sistema de archivos local es la única opción para los discos SATA o SAS internos, y se utiliza cuando su servidor tiene controladores RAID de hardware internos con unidades locales. Los sistemas de archivos locales son también los sistemas de archivos más comunes utilizados en el almacenamiento conectado a la SAN cuando el dispositivo exportado en la SAN no es compartido.

Todos los sistemas de archivos locales son compatibles con POSIX y son totalmente compatibles con todas las versiones de Red Hat Enterprise Linux. Los sistemas de archivos compatibles con POSIX proporcionan soporte para un conjunto bien definido de llamadas al sistema, tales como read(), write(), y seek().

Desde el punto de vista del programador de aplicaciones, hay relativamente pocas diferencias entre los sistemas de archivos locales. Las diferencias más notables desde la perspectiva del usuario están relacionadas con la escalabilidad y el rendimiento. Al considerar la elección de un sistema de archivos, hay que tener en cuenta el tamaño que debe tener el sistema de archivos, las características únicas que debe tener y el rendimiento bajo su carga de trabajo.

Sistemas de archivos locales disponibles
  • XFS
  • ext4

1.3. El sistema de archivos XFS

XFS es un sistema de archivos de 64 bits altamente escalable, de alto rendimiento, robusto y maduro que soporta archivos y sistemas de archivos muy grandes en un solo host. Es el sistema de archivos por defecto en Red Hat Enterprise Linux 8. XFS fue desarrollado originalmente a principios de los 90 por SGI y tiene una larga historia de funcionamiento en servidores y matrices de almacenamiento extremadamente grandes.

Las características de XFS incluyen:

Fiabilidad
  • El registro en el diario de los metadatos, que garantiza la integridad del sistema de archivos después de un fallo del sistema, ya que mantiene un registro de las operaciones del sistema de archivos que puede reproducirse cuando se reinicia el sistema y se vuelve a montar el sistema de archivos
  • Amplia comprobación de la coherencia de los metadatos en tiempo de ejecución
  • Utilidades de reparación escalables y rápidas
  • Registro de cuotas. Esto evita la necesidad de largas comprobaciones de consistencia de cuotas después de una caída.
Escalabilidad y rendimiento
  • Tamaño del sistema de archivos soportado hasta 1024 TiB
  • Capacidad para soportar un gran número de operaciones simultáneas
  • Indexación del árbol B para la escalabilidad de la gestión del espacio libre
  • Sofisticados algoritmos de lectura anticipada de metadatos
  • Optimizaciones para cargas de trabajo de vídeo en streaming
Regímenes de asignación
  • Asignación basada en la extensión
  • Políticas de asignación con conocimiento de las franjas
  • Asignación retardada
  • Pre-asignación de espacio
  • Inodos asignados dinámicamente
Otras características
  • Copias de archivos basadas en Reflink (nuevo en Red Hat Enterprise Linux 8)
  • Utilidades de copia de seguridad y restauración estrechamente integradas
  • Desfragmentación en línea
  • Crecimiento del sistema de archivos en línea
  • Amplia capacidad de diagnóstico
  • Atributos extendidos (xattr). Esto permite al sistema asociar varios pares nombre/valor adicionales por archivo.
  • Cuotas de proyectos o directorios. Esto permite restringir las cuotas sobre un árbol de directorios.
  • Marcas de tiempo de subsegundos
Características de rendimiento

XFS tiene un alto rendimiento en sistemas grandes con cargas de trabajo empresariales. Un sistema grande es aquel con un número relativamente alto de CPUs, múltiples HBAs y conexiones a matrices de discos externas. XFS también tiene un buen rendimiento en sistemas más pequeños que tienen una carga de trabajo de E/S paralela y multihilo.

XFS tiene un rendimiento relativamente bajo para cargas de trabajo intensivas en metadatos de un solo hilo: por ejemplo, una carga de trabajo que crea o borra un gran número de archivos pequeños en un solo hilo.

1.4. El sistema de archivos ext4

El sistema de archivos ext4 es la cuarta generación de la familia de sistemas de archivos ext. Fue el sistema de archivos por defecto en Red Hat Enterprise Linux 6.

El controlador ext4 puede leer y escribir en los sistemas de archivos ext2 y ext3, pero el formato del sistema de archivos ext4 no es compatible con los controladores ext2 y ext3.

ext4 añade varias características nuevas y mejoradas, como:

  • Tamaño del sistema de archivos soportado hasta 50 TiB
  • Metadatos basados en el alcance
  • Asignación retardada
  • Suma de comprobación del diario
  • Gran soporte de almacenamiento

Los metadatos basados en la extensión y las funciones de asignación retardada proporcionan una forma más compacta y eficiente de rastrear el espacio utilizado en un sistema de archivos. Estas características mejoran el rendimiento del sistema de archivos y reducen el espacio consumido por los metadatos. La asignación retardada permite que el sistema de archivos posponga la selección de la ubicación permanente para los datos de usuario recién escritos hasta que los datos se descarguen en el disco. Esto permite un mayor rendimiento, ya que puede permitir asignaciones más grandes y contiguas, lo que permite al sistema de archivos tomar decisiones con mucha más información.

El tiempo de reparación del sistema de archivos mediante la utilidad fsck en ext4 es mucho más rápido que en ext2 y ext3. Algunas reparaciones de sistemas de archivos han demostrado un aumento del rendimiento de hasta seis veces.

1.5. Comparación de XFS y ext4

XFS es el sistema de archivos por defecto en RHEL. Esta sección compara el uso y las características de XFS y ext4.

Comportamiento de los errores de metadatos
En ext4, se puede configurar el comportamiento cuando el sistema de archivos encuentra errores de metadatos. El comportamiento por defecto es simplemente continuar la operación. Cuando XFS encuentra un error de metadatos irrecuperable, cierra el sistema de archivos y devuelve el error EFSCORRUPTED.
Cuotas

En ext4, puedes habilitar las cuotas al crear el sistema de archivos o posteriormente en un sistema de archivos existente. A continuación, puede configurar la aplicación de cuotas mediante una opción de montaje.

Las cuotas XFS no son una opción remountable. Debes activar las cuotas en el montaje inicial.

La ejecución del comando quotacheck en un sistema de archivos XFS no tiene ningún efecto. La primera vez que se activa la contabilidad de cuotas, XFS comprueba las cuotas automáticamente.

Redimensionamiento del sistema de archivos
XFS no tiene ninguna utilidad para reducir el tamaño de un sistema de archivos. Sólo se puede aumentar el tamaño de un sistema de archivos XFS. En comparación, ext4 permite tanto ampliar como reducir el tamaño de un sistema de archivos.
Números de inodo

El sistema de archivos ext4 no admite más de232 inodos.

XFS asigna dinámicamente los inodos. Un sistema de archivos XFS no puede quedarse sin inodos mientras haya espacio libre en el sistema de archivos.

Algunas aplicaciones no pueden manejar correctamente números de inodo mayores que232 en un sistema de archivos XFS. Estas aplicaciones pueden provocar el fallo de las llamadas stat de 32 bits con el valor de retorno EOVERFLOW. El número de inodo es superior a232 en las siguientes condiciones:

  • El sistema de archivos es mayor de 1 TiB con inodos de 256 bytes.
  • El sistema de archivos es mayor de 2 TiB con inodos de 512 bytes.

Si su aplicación falla con números de inodo grandes, monte el sistema de archivos XFS con la opción -o inode32 para imponer números de inodo inferiores a232. Tenga en cuenta que el uso de inode32 no afecta a los inodos que ya están asignados con números de 64 bits.

Importante

Utilice la opción inode32 en not a menos que un entorno específico lo requiera. La opción inode32 cambia el comportamiento de la asignación. Como consecuencia, podría producirse el error ENOSPC si no hay espacio disponible para asignar inodos en los bloques de disco inferiores.

1.6. Elegir un sistema de archivos local

Para elegir un sistema de archivos que cumpla con los requisitos de su aplicación, debe entender el sistema de destino en el que va a desplegar el sistema de archivos. Puede utilizar las siguientes preguntas para informar su decisión:

  • ¿Tiene un servidor grande?
  • ¿Tiene grandes necesidades de almacenamiento o tiene una unidad SATA local y lenta?
  • ¿Qué tipo de carga de trabajo de E/S espera que presente su aplicación?
  • ¿Cuáles son sus requisitos de rendimiento y latencia?
  • ¿Cuál es la estabilidad de su servidor y hardware de almacenamiento?
  • ¿Cuál es el tamaño típico de sus archivos y conjuntos de datos?
  • Si el sistema falla, ¿cuánto tiempo de inactividad puede sufrir?

Si tanto tu servidor como tu dispositivo de almacenamiento son grandes, XFS es la mejor opción. Incluso con matrices de almacenamiento más pequeñas, XFS funciona muy bien cuando el tamaño medio de los archivos es grande (por ejemplo, de cientos de megabytes).

Si su carga de trabajo actual ha funcionado bien con ext4, permanecer con ext4 debería proporcionarle a usted y a sus aplicaciones un entorno muy familiar.

El sistema de archivos ext4 tiende a funcionar mejor en sistemas que tienen una capacidad de E/S limitada. Funciona mejor con un ancho de banda limitado (menos de 200MB/s) y hasta una capacidad de 1000 IOPS. Para cualquier cosa con mayor capacidad, XFS tiende a ser más rápido.

XFS consume aproximadamente el doble de CPU por operación de metadatos en comparación con ext4, por lo que si tienes una carga de trabajo limitada a la CPU con poca concurrencia, entonces ext4 será más rápido. En general, ext4 es mejor si una aplicación utiliza un único hilo de lectura/escritura y archivos pequeños, mientras que XFS brilla cuando una aplicación utiliza múltiples hilos de lectura/escritura y archivos más grandes.

No se puede reducir un sistema de archivos XFS. Si necesita poder reducir el sistema de archivos, considere utilizar ext4, que admite la reducción sin conexión.

En general, Red Hat recomienda que utilice XFS a menos que tenga un caso de uso específico para ext4. También debería medir el rendimiento de su aplicación específica en su servidor y sistema de almacenamiento de destino para asegurarse de que elige el tipo de sistema de archivos apropiado.

Tabla 1.2. Resumen de las recomendaciones del sistema de archivos local
EscenarioSistema de archivos recomendado

Ningún caso de uso especial

XFS

Servidor grande

XFS

Dispositivos de almacenamiento de gran tamaño

XFS

Archivos grandes

XFS

E/S multihilo

XFS

E/S de un solo hilo

ext4

Capacidad de E/S limitada (menos de 1000 IOPS)

ext4

Ancho de banda limitado (menos de 200 MB/s)

ext4

Carga de trabajo con CPU

ext4

Apoyo a la contracción fuera de línea

ext4

1.7. Sistemas de archivos en red

Los sistemas de archivos en red, también denominados sistemas de archivos cliente/servidor, permiten a los sistemas cliente acceder a los archivos almacenados en un servidor compartido. Esto hace posible que varios usuarios en varios sistemas compartan archivos y recursos de almacenamiento.

Estos sistemas de archivos se construyen a partir de uno o varios servidores que exportan un conjunto de sistemas de archivos a uno o varios clientes. Los nodos clientes no tienen acceso al almacenamiento de bloques subyacente, sino que interactúan con el almacenamiento utilizando un protocolo que permite un mejor control de acceso.

Sistemas de archivos de red disponibles
  • El sistema de archivos cliente/servidor más común para los clientes de RHEL es el sistema de archivos NFS. RHEL proporciona tanto un componente de servidor NFS para exportar un sistema de archivos local a través de la red como un cliente NFS para importar estos sistemas de archivos.
  • RHEL también incluye un cliente CIFS que soporta los populares servidores de archivos SMB de Microsoft para la interoperabilidad con Windows. El servidor Samba del espacio de usuario proporciona a los clientes de Windows un servicio SMB de Microsoft desde un servidor RHEL.

1.8. Sistemas de archivos de almacenamiento compartido

Los sistemas de archivos de almacenamiento compartido, a veces denominados sistemas de archivos de clúster, dan a cada servidor del clúster acceso directo a un dispositivo de bloques compartido a través de una red de área de almacenamiento local (SAN).

Comparación con los sistemas de archivos en red

Al igual que los sistemas de archivos cliente/servidor, los sistemas de archivos de almacenamiento compartido funcionan en un conjunto de servidores que son todos miembros de un clúster. Sin embargo, a diferencia de NFS, ningún servidor proporciona acceso a datos o metadatos a otros miembros: cada miembro del clúster tiene acceso directo al mismo dispositivo de almacenamiento (el shared storage), y todos los nodos miembros del clúster acceden al mismo conjunto de archivos.

Concurrencia

La coherencia de la caché es clave en un sistema de archivos en clúster para garantizar la consistencia e integridad de los datos. Debe haber una única versión de todos los archivos de un clúster visible para todos los nodos de un clúster. El sistema de archivos debe evitar que los miembros del clúster actualicen el mismo bloque de almacenamiento al mismo tiempo y provoquen la corrupción de los datos. Para ello, los sistemas de archivos de almacenamiento compartido utilizan un mecanismo de bloqueo de cluster para arbitrar el acceso al almacenamiento como mecanismo de control de concurrencia. Por ejemplo, antes de crear un nuevo archivo o escribir en un archivo abierto en varios servidores, el componente del sistema de archivos en el servidor debe obtener el bloqueo correcto.

El requisito de los sistemas de archivos en clúster es proporcionar un servicio de alta disponibilidad como un servidor web Apache. Cualquier miembro del clúster verá una vista totalmente coherente de los datos almacenados en su sistema de archivos de disco compartido, y todas las actualizaciones serán arbitradas correctamente por los mecanismos de bloqueo.

Características de rendimiento

Los sistemas de archivos de disco compartido no siempre funcionan tan bien como los sistemas de archivos locales que se ejecutan en el mismo sistema debido al coste computacional de la sobrecarga de bloqueo. Los sistemas de archivos de disco compartido funcionan bien con cargas de trabajo en las que cada nodo escribe casi exclusivamente en un conjunto concreto de archivos que no se comparten con otros nodos o en las que un conjunto de archivos se comparte casi exclusivamente en modo de lectura en un conjunto de nodos. Esto resulta en un mínimo de invalidación de la caché entre nodos y puede maximizar el rendimiento.

La configuración de un sistema de archivos de disco compartido es compleja, y el ajuste de una aplicación para que funcione bien en un sistema de archivos de disco compartido puede ser un reto.

Sistemas de archivos de almacenamiento compartido disponibles

  • Red Hat Enterprise Linux proporciona el sistema de archivos GFS2. GFS2 viene estrechamente integrado con el complemento de alta disponibilidad de Red Hat Enterprise Linux y el complemento de almacenamiento resistente.

    Red Hat Enterprise Linux admite GFS2 en clústeres cuyo tamaño oscila entre 2 y 16 nodos.

1.9. Elegir entre sistemas de archivos de red y de almacenamiento compartido

A la hora de elegir entre los sistemas de archivos de red y los de almacenamiento compartido, tenga en cuenta los siguientes puntos:

  • Los sistemas de archivos en red basados en NFS son una opción muy común y popular para los entornos que proporcionan servidores NFS.
  • Los sistemas de archivos en red pueden desplegarse utilizando tecnologías de red de muy alto rendimiento, como Infiniband o 10 Gigabit Ethernet. Esto significa que no debe recurrir a los sistemas de archivos de almacenamiento compartido sólo para obtener un ancho de banda bruto para su almacenamiento. Si la velocidad de acceso es lo más importante, utilice NFS para exportar un sistema de archivos local como XFS.
  • Los sistemas de archivos de almacenamiento compartido no son fáciles de configurar ni de mantener, por lo que sólo debe implementarlos cuando no pueda proporcionar la disponibilidad requerida con sistemas de archivos locales o de red.
  • Un sistema de archivos de almacenamiento compartido en un entorno de clúster ayuda a reducir el tiempo de inactividad al eliminar los pasos necesarios para el desmontaje y el montaje que deben realizarse durante un escenario típico de conmutación por error que implique la reubicación de un servicio de alta disponibilidad.

Red Hat recomienda que utilice sistemas de archivos de red a menos que tenga un caso de uso específico para sistemas de archivos de almacenamiento compartido. Utilice sistemas de archivos de almacenamiento compartido principalmente para implementaciones que necesiten proporcionar servicios de alta disponibilidad con un tiempo de inactividad mínimo y que tengan requisitos estrictos de nivel de servicio.

1.10. Sistemas de archivos con gestión de volumen

Los sistemas de archivos con gestión de volumen integran toda la pila de almacenamiento con el fin de simplificar y optimizar la pila.

Sistemas de archivos de gestión de volumen disponibles

  • Red Hat Enterprise Linux 8 proporciona el gestor de volúmenes Stratis como una Muestra de Tecnología. Stratis utiliza XFS para la capa del sistema de archivos y lo integra con LVM, Device Mapper y otros componentes.

    Stratis fue lanzado por primera vez en Red Hat Enterprise Linux 8.0. Fue concebido para llenar el vacío creado cuando Red Hat dejó de utilizar Btrfs. Stratis 1.0 es un gestor de volúmenes intuitivo, basado en la línea de comandos, que puede realizar importantes operaciones de gestión de almacenamiento ocultando la complejidad al usuario:

    • Gestión del volumen
    • Creación de piscinas
    • Grupos de almacenamiento ligero
    • Instantáneas
    • Caché de lectura automatizada

    Stratis ofrece potentes características, pero actualmente carece de ciertas capacidades de otras ofertas con las que podría compararse, como Btrfs o ZFS. La más notable es que no soporta CRCs con autocuración.

Capítulo 2. Gestión del almacenamiento local mediante los roles de sistema de RHEL

Para gestionar LVM y sistemas de archivos locales (FS) mediante Ansible, puede utilizar el rol storage, que es uno de los roles de sistema RHEL disponibles en RHEL 8.

El uso del rol storage le permite automatizar la administración de sistemas de archivos en discos y volúmenes lógicos en múltiples máquinas y en todas las versiones de RHEL a partir de RHEL 7.7.

Para más información sobre los Roles del Sistema RHEL y cómo aplicarlos, vea Introducción a los Roles del Sistema RHEL.

2.1. Introducción a la función de almacenamiento

La función storage puede gestionar:

  • Sistemas de archivos en discos que no han sido particionados
  • Grupos de volúmenes LVM completos, incluyendo sus volúmenes lógicos y sistemas de archivos

Con el rol storage puede realizar las siguientes tareas:

  • Crear un sistema de archivos
  • Eliminar un sistema de archivos
  • Montar un sistema de archivos
  • Desmontar un sistema de archivos
  • Crear grupos de volúmenes LVM
  • Eliminar grupos de volúmenes LVM
  • Crear volúmenes lógicos
  • Eliminar volúmenes lógicos
  • Crear volúmenes RAID
  • Eliminar volúmenes RAID
  • Crear pools LVM con RAID
  • Eliminar pools LVM con RAID

2.2. Parámetros que identifican un dispositivo de almacenamiento en el rol de sistema de almacenamiento

La configuración de su rol en storage afecta sólo a los sistemas de archivos, volúmenes y pools que se enumeran en las siguientes variables.

storage_volumes

Lista de sistemas de archivos en todos los discos no particionados que se van a gestionar.

Actualmente, las particiones no son compatibles.

storage_pools

Lista de piscinas a gestionar.

Actualmente el único tipo de pool soportado es LVM. Con LVM, los pools representan grupos de volúmenes (VGs). Bajo cada pool hay una lista de volúmenes que deben ser gestionados por el rol. Con LVM, cada volumen corresponde a un volumen lógico (LV) con un sistema de archivos.

2.3. Ejemplo de playbook de Ansible para crear un sistema de archivos XFS en un dispositivo de bloques

Esta sección proporciona un ejemplo de libro de jugadas de Ansible. Este libro de jugadas aplica el rol storage para crear un sistema de archivos XFS en un dispositivo de bloques utilizando los parámetros predeterminados.

Aviso

El rol storage puede crear un sistema de archivos sólo en un disco entero no particionado o en un volumen lógico (LV). No puede crear el sistema de archivos en una partición.

Ejemplo 2.1. Un playbook que crea XFS en /dev/sdb

---
- hosts: all
  vars:
    storage_volumes:
      - name: barefs
        type: disk
        disks:
          - sdb
        fs_type: xfs
  roles:
    - rhel-system-roles.storage
Copy to Clipboard
  • El nombre del volumen (barefs en el ejemplo) es actualmente arbitrario. El rol storage identifica el volumen por el dispositivo de disco listado bajo el atributo disks:.
  • Puede omitir la línea fs_type: xfs porque XFS es el sistema de archivos por defecto en RHEL 8.

  • Para crear el sistema de archivos en un LV, proporcione la configuración de LVM bajo el atributo disks:, incluyendo el grupo de volúmenes que lo rodea. Para obtener más detalles, consulte Ejemplo de libro de jugadas de Ansible para gestionar volúmenes lógicos.

    No proporcione la ruta de acceso al dispositivo LV.

Recursos adicionales

  • Para más detalles sobre los parámetros utilizados en el rol de sistema storage, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.storage/README.md.

2.4. Ejemplo de playbook de Ansible para montar persistentemente un sistema de archivos

Esta sección proporciona un ejemplo de libro de jugadas de Ansible. Este libro de jugadas aplica el rol storage para montar de forma inmediata y persistente un sistema de archivos XFS.

Ejemplo 2.2. Un playbook que monta un sistema de archivos en /dev/sdb a /mnt/data

---
- hosts: all
  vars:
    storage_volumes:
      - name: barefs
        type: disk
        disks:
          - sdb
        fs_type: xfs
        mount_point: /mnt/data
  roles:
    - rhel-system-roles.storage
Copy to Clipboard
  • Este libro de jugadas añade el sistema de archivos al archivo /etc/fstab, y monta el sistema de archivos inmediatamente.
  • Si el sistema de archivos del dispositivo /dev/sdb o el directorio del punto de montaje no existen, el libro de jugadas los crea.

Recursos adicionales

  • Para más detalles sobre los parámetros utilizados en el rol de sistema storage, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.storage/README.md.

2.5. Ejemplo de libro de jugadas de Ansible para gestionar volúmenes lógicos

Esta sección proporciona un ejemplo de libro de jugadas de Ansible. Este libro de jugadas aplica el rol storage para crear un volumen lógico LVM en un grupo de volúmenes.

Ejemplo 2.3. Un libro de jugadas que crea un volumen lógico mylv en el grupo de volúmenes myvg

- hosts: all
  vars:
    storage_pools:
      - name: myvg
        disks:
          - sda
          - sdb
          - sdc
        volumes:
          - name: mylv
            size: 2G
            fs_type: ext4
            mount_point: /mnt
  roles:
    - rhel-system-roles.storage
Copy to Clipboard

  • El grupo de volúmenes myvg está formado por los siguientes discos:

    • /dev/sda
    • /dev/sdb
    • /dev/sdc
  • Si el grupo de volumen myvg ya existe, el libro de jugadas añade el volumen lógico al grupo de volumen.
  • Si el grupo de volumen myvg no existe, el libro de jugadas lo crea.
  • El libro de jugadas crea un sistema de archivos Ext4 en el volumen lógico mylv, y monta persistentemente el sistema de archivos en /mnt.

Recursos adicionales

  • Para más detalles sobre los parámetros utilizados en el rol de sistema storage, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.storage/README.md.

2.6. Ejemplo de libro de jugadas de Ansible para activar el descarte de bloques en línea

Esta sección proporciona un ejemplo de libro de jugadas de Ansible. Este libro de jugadas aplica el rol storage para montar un sistema de archivos XFS con el descarte de bloques en línea activado.

Ejemplo 2.4. Un libro de jugadas que permite descartar bloques en línea en /mnt/data/

---
- hosts: all
  vars:
    storage_volumes:
      - name: barefs
        type: disk
        disks:
          - sdb
        fs_type: xfs
        mount_point: /mnt/data
        mount_options: discard
  roles:
    - rhel-system-roles.storage
Copy to Clipboard

Recursos adicionales

  • Para más detalles sobre los parámetros utilizados en el rol de sistema storage, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.storage/README.md.

2.7. Ejemplo de playbook Ansible para crear y montar un sistema de archivos Ext4

Esta sección proporciona un ejemplo de libro de jugadas de Ansible. Este libro de jugadas aplica el rol storage para crear y montar un sistema de archivos Ext4.

Ejemplo 2.5. Un playbook que crea Ext4 en /dev/sdb y lo monta en /mnt/data

---
- hosts: all
  vars:
    storage_volumes:
      - name: barefs
        type: disk
        disks:
          - sdb
        fs_type: ext4
        fs_label: label-name
        mount_point: /mnt/data
  roles:
    - rhel-system-roles.storage
Copy to Clipboard
  • El libro de jugadas crea el sistema de archivos en el disco /dev/sdb.
  • El libro de jugadas monta persistentemente el sistema de archivos en el directorio /mnt/data directorio.
  • La etiqueta del sistema de archivos es label-name.

Recursos adicionales

  • Para más detalles sobre los parámetros utilizados en el rol de sistema storage, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.storage/README.md.

2.8. Ejemplo de playbook de Ansible para crear y montar un sistema de archivos ext3

Esta sección proporciona un ejemplo de libro de jugadas de Ansible. Este libro de jugadas aplica el rol storage para crear y montar un sistema de archivos Ext3.

Ejemplo 2.6. Un playbook que crea Ext3 en /dev/sdb y lo monta en /mnt/data

---
- hosts: all
  vars:
    storage_volumes:
      - name: barefs
        type: disk
        disks:
          - sdb
        fs_type: ext3
        fs_label: label-name
        mount_point: /mnt/data
  roles:
    - rhel-system-roles.storage
Copy to Clipboard
  • El libro de jugadas crea el sistema de archivos en el disco /dev/sdb.
  • El libro de jugadas monta persistentemente el sistema de archivos en el directorio /mnt/data directorio.
  • La etiqueta del sistema de archivos es label-name.

Recursos adicionales

  • Para más detalles sobre los parámetros utilizados en el rol de sistema storage, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.storage/README.md.

2.9. Configuración de un volumen RAID mediante el rol de sistema de almacenamiento

Con el rol de sistema storage, puede configurar un volumen RAID en RHEL utilizando Red Hat Ansible Automation Platform. En esta sección aprenderá a configurar un playbook de Ansible con los parámetros disponibles para configurar un volumen RAID que se adapte a sus necesidades.

Requisitos previos

  • Tiene instalado Red Hat Ansible Engine en el sistema desde el que desea ejecutar el libro de jugadas.

    Nota

    No es necesario tener Red Hat Ansible Automation Platform instalado en los sistemas en los que se desea implementar la solución storage.

  • Tienes el paquete rhel-system-roles instalado en el sistema desde el que quieres ejecutar el playbook.
  • Tienes un archivo de inventario que detalla los sistemas en los que quieres desplegar un volumen RAID usando el rol de sistema storage.

Procedimiento

  1. Cree un nuevo playbook.yml archivo con el siguiente contenido: 

    - hosts: all
  vars:
    storage_safe_mode: false
    storage_volumes:
      - name: data
        type: raid
        disks: [sdd, sde, sdf, sdg]
        raid_level: raid0
        raid_chunk_size: 32 KiB
        mount_point: /mnt/data
        state: present
  roles:
    - name: rhel-system-roles.storage
    Copy to Clipboard
    Aviso

    Los nombres de los dispositivos pueden cambiar en determinadas circunstancias; por ejemplo, cuando se añade un nuevo disco a un sistema. Por lo tanto, para evitar la pérdida de datos, no se recomienda utilizar nombres de discos específicos en el libro de jugadas.

  2. Opcional. Verificar la sintaxis del libro de jugadas. 

    # ansible-playbook --syntax-check playbook.yml
    Copy to Clipboard

  3. Ejecute el libro de jugadas en su archivo de inventario: 

    # ansible-playbook -i inventory.file /path/to/file/playbook.yml
    Copy to Clipboard

Recursos adicionales

  • Para obtener más información sobre RAID, consulte Gestión de RAID.
  • Para obtener detalles sobre los parámetros utilizados en el rol del sistema de almacenamiento, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.storage/README.md.

2.10. Configuración de un pool LVM con RAID utilizando el rol de sistema de almacenamiento

Con el rol de sistema storage, puede configurar un pool LVM con RAID en RHEL utilizando Red Hat Ansible Automation Platform. En esta sección aprenderá a configurar un playbook Ansible con los parámetros disponibles para configurar un pool LVM con RAID.

Requisitos previos

  • Tiene instalado Red Hat Ansible Engine en el sistema desde el que desea ejecutar el libro de jugadas.

    Nota

    No es necesario tener Red Hat Ansible Automation Platform instalado en los sistemas en los que se desea implementar la solución storage.

  • Tienes el paquete rhel-system-roles instalado en el sistema desde el que quieres ejecutar el playbook.
  • Tienes un archivo de inventario que detalla los sistemas en los que quieres configurar un pool LVM con RAID utilizando el rol de sistema storage.

Procedimiento

  1. Cree un nuevo playbook.yml archivo con el siguiente contenido: 

    - hosts: all
  vars:
    storage_safe_mode: false
    storage_pools:
      - name: my_pool
        type: lvm
        disks: [sdh, sdi]
        raid_level: raid1
        volumes:
          - name: my_pool
            size: "1 GiB"
            mount_point: "/mnt/app/shared"
            fs_type: xfs
            state: present
  roles:
    - name: rhel-system-roles.storage
    Copy to Clipboard
    Nota

    Para crear un pool LVM con RAID, debes especificar el tipo de RAID utilizando el parámetro raid_level.

  2. Opcional. Verificar la sintaxis del libro de jugadas. 

    # ansible-playbook --syntax-check playbook.yml
    Copy to Clipboard

  3. Ejecute el libro de jugadas en su archivo de inventario: 

    # ansible-playbook -i inventory.file /path/to/file/playbook.yml
    Copy to Clipboard

Recursos adicionales

  • Para obtener más información sobre RAID, consulte Gestión de RAID.
  • Para obtener detalles sobre los parámetros utilizados en el rol del sistema de almacenamiento, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.storage/README.md.

2.11. Creación de un volumen encriptado LUKS utilizando el rol de almacenamiento

Puede utilizar el rol storage para crear y configurar un volumen encriptado con LUKS ejecutando un playbook de Ansible.

Requisitos previos

  • Tiene instalado Red Hat Ansible Engine en el sistema desde el que desea ejecutar el libro de jugadas.

    Nota

    No es necesario tener Red Hat Ansible Automation Platform instalado en los sistemas en los que se desea crear el volumen.

  • Tiene el paquete rhel-system-roles instalado en el controlador Ansible.
  • Dispone de un archivo de inventario en el que se detallan los sistemas en los que desea desplegar un volumen encriptado LUKS mediante el rol de sistema de almacenamiento.

Procedimiento

  1. Cree un nuevo playbook.yml archivo con el siguiente contenido: 

    - hosts: all
  vars:
    storage_volumes:
      - name: barefs
        type: disk
        disks:
         - sdb
        fs_type: xfs
        fs_label: label-name
        mount_point: /mnt/data
        encryption: true
        encryption_password: your-password
  roles:
   - rhel-system-roles.storage
    Copy to Clipboard

  2. Opcional. Verificar la sintaxis del libro de jugadas: 

    # ansible-playbook --syntax-check playbook.yml
    Copy to Clipboard

  3. Ejecute el libro de jugadas en su archivo de inventario: 

    # ansible-playbook -i inventory.file /path/to/file/playbook.yml
    Copy to Clipboard

Recursos adicionales

  • Para más información, instale el paquete rhel-system-roles y consulte los siguientes directorios:

    • /usr/share/doc/rhel-system-roles/storage/
    • /usr/share/ansible/roles/rhel-system-roles.storage/

Capítulo 3. Montaje de recursos compartidos NFS

Como administrador del sistema, puede montar recursos compartidos NFS remotos en su sistema para acceder a los datos compartidos.

3.1. Introducción a NFS

Esta sección explica los conceptos básicos del servicio NFS.

Un sistema de archivos de red (NFS) permite a los hosts remotos montar sistemas de archivos a través de una red e interactuar con esos sistemas de archivos como si estuvieran montados localmente. Esto permite consolidar los recursos en servidores centralizados en la red.

El servidor NFS consulta el archivo de configuración /etc/exports para determinar si el cliente puede acceder a cualquier sistema de archivos exportado. Una vez verificado, todas las operaciones de archivos y directorios están disponibles para el usuario.

3.2. Versiones de NFS compatibles

Esta sección lista las versiones de NFS soportadas en Red Hat Enterprise Linux y sus características.

Actualmente, Red Hat Enterprise Linux 8 soporta las siguientes versiones principales de NFS:

  • La versión 3 de NFS (NFSv3) admite escrituras asíncronas seguras y es más robusta en la gestión de errores que la anterior NFSv2; también admite tamaños de archivo y desplazamientos de 64 bits, lo que permite a los clientes acceder a más de 2 GB de datos de archivo.
  • La versión 4 de NFS (NFSv4) funciona a través de cortafuegos y en Internet, ya no requiere un servicio rpcbind, admite listas de control de acceso (ACL) y utiliza operaciones con estado.

La versión 2 de NFS (NFSv2) ya no es soportada por Red Hat.

Versión NFS por defecto

La versión NFS por defecto en Red Hat Enterprise Linux 8 es la 4.2. Los clientes NFS intentan montar usando NFSv4.2 por defecto, y vuelven a NFSv4.1 cuando el servidor no soporta NFSv4.2. El montaje vuelve a ser NFSv4.0 y luego NFSv3.

Características de las versiones menores de NFS

A continuación se presentan las características de NFSv4.2 en Red Hat Enterprise Linux 8:

Copia del lado del servidor
Permite que el cliente NFS copie datos de forma eficiente sin desperdiciar recursos de red utilizando la llamada al sistema copy_file_range().
Archivos dispersos
Permite que los archivos tengan uno o más holes, que son bloques de datos no asignados o no inicializados que constan sólo de ceros. La operación lseek() en NFSv4.2 admite seek_hole() y seek_data(), lo que permite a las aplicaciones trazar la ubicación de los huecos en el archivo disperso.
Reserva de espacio
Permite a los servidores de almacenamiento reservar espacio libre, lo que impide que los servidores se queden sin espacio. NFSv4.2 admite la operación allocate() para reservar espacio, la operación deallocate() para desreservar espacio y la operación fallocate() para preasignar o desasignar espacio en un archivo.
Etiquetado NFS
Aplica los derechos de acceso a los datos y habilita las etiquetas SELinux entre un cliente y un servidor para archivos individuales en un sistema de archivos NFS.
Mejoras en el diseño
Proporciona la operación layoutstats(), que permite a algunos servidores NFS paralelos (pNFS) recoger mejores estadísticas de rendimiento.

A continuación se detallan las características de NFSv4.1:

  • Mejora el rendimiento y la seguridad de la red, y también incluye soporte del lado del cliente para pNFS.
  • Ya no se requiere una conexión TCP independiente para las devoluciones de llamada, lo que permite a un servidor NFS conceder delegaciones incluso cuando no puede contactar con el cliente: por ejemplo, cuando interfiere NAT o un cortafuegos.
  • Proporciona la semántica de "exactamente una vez" (excepto para las operaciones de reinicio), evitando un problema anterior por el que ciertas operaciones devolvían a veces un resultado inexacto si se perdía una respuesta y la operación se enviaba dos veces.

3.3. Servicios requeridos por NFS

Esta sección enumera los servicios del sistema que se requieren para ejecutar un servidor NFS o montar recursos compartidos NFS. Red Hat Enterprise Linux inicia estos servicios automáticamente.

Red Hat Enterprise Linux utiliza una combinación de soporte a nivel de kernel y procesos de servicio para proporcionar el intercambio de archivos NFS. Todas las versiones de NFS se basan en llamadas de procedimiento remoto (RPC) entre clientes y servidores. Para compartir o montar sistemas de archivos NFS, los servicios siguientes trabajan juntos dependiendo de la versión de NFS implementada:

nfsd
El módulo del núcleo del servidor NFS que atiende las solicitudes de sistemas de archivos NFS compartidos.
rpcbind
Acepta las reservas de puertos de los servicios RPC locales. Estos puertos se ponen a disposición (o se anuncian) para que los servicios RPC remotos correspondientes puedan acceder a ellos. El servicio rpcbind responde a las solicitudes de servicios RPC y establece conexiones con el servicio RPC solicitado. Esto no se utiliza con NFSv4.
rpc.mountd
Este proceso es utilizado por un servidor NFS para procesar las solicitudes MOUNT de los clientes NFSv3. Comprueba que el recurso compartido NFS solicitado está actualmente exportado por el servidor NFS y que el cliente puede acceder a él. Si la solicitud de montaje está permitida, el servicio nfs-mountd responde con un estado de éxito y proporciona el File-Handle de este recurso compartido NFS al cliente NFS.
rpc.nfsd
Este proceso permite definir las versiones y protocolos NFS explícitos que el servidor anuncia. Trabaja con el kernel de Linux para satisfacer las demandas dinámicas de los clientes NFS, como proporcionar hilos del servidor cada vez que un cliente NFS se conecta. Este proceso se corresponde con el servicio nfs-server.
lockd
Es un hilo del núcleo que se ejecuta tanto en los clientes como en los servidores. Implementa el protocolo Network Lock Manager (NLM), que permite a los clientes NFSv3 bloquear archivos en el servidor. Se inicia automáticamente siempre que se ejecuta el servidor NFS y siempre que se monta un sistema de archivos NFS.
rpc.statd
Este proceso implementa el protocolo RPC Network Status Monitor (NSM), que notifica a los clientes NFS cuando un servidor NFS se reinicia sin que se caiga. El servicio rpc-statd es iniciado automáticamente por el servicio nfs-server, y no requiere la configuración del usuario. No se utiliza con NFSv4.
rpc.rquotad
Este proceso proporciona información sobre las cuotas de los usuarios remotos. El servicio rpc-rquotad es iniciado automáticamente por el servicio nfs-server y no requiere configuración por parte del usuario.
rpc.idmapd

Este proceso proporciona llamadas ascendentes al cliente y al servidor NFSv4, que mapean entre los nombres NFSv4 on-the-wire (cadenas en forma de user@domain) y los UID y GID locales. Para que idmapd funcione con NFSv4, el archivo /etc/idmapd.conf debe estar configurado. Como mínimo, debe especificarse el parámetro Domain, que define el dominio de mapeo NFSv4. Si el dominio de mapeo NFSv4 es el mismo que el nombre de dominio DNS, este parámetro puede omitirse. El cliente y el servidor deben estar de acuerdo con el dominio de mapeo NFSv4 para que el mapeo de ID funcione correctamente.

Sólo el servidor NFSv4 utiliza rpc.idmapd, que es iniciado por el servicio nfs-idmapd. El cliente NFSv4 utiliza la utilidad basada en llaveros nfsidmap, que es llamada por el kernel bajo demanda para realizar el mapeo de ID. Si hay un problema con nfsidmap, el cliente vuelve a utilizar rpc.idmapd.

Los servicios RPC con NFSv4

Los protocolos de montaje y bloqueo se han incorporado al protocolo NFSv4. El servidor también escucha en el conocido puerto TCP 2049. Así, NFSv4 no necesita interactuar con los servicios rpcbind, lockd y rpc-statd. El servicio nfs-mountd sigue siendo necesario en el servidor NFS para configurar las exportaciones, pero no interviene en ninguna operación over-the-wire.

Recursos adicionales

3.4. Formatos de nombres de host NFS

En esta sección se describen diferentes formatos que se pueden utilizar para especificar un host al montar o exportar un recurso compartido NFS.

Puede especificar el host en los siguientes formatos:

Máquina individual

Cualquiera de los siguientes:

  • Un nombre de dominio completamente calificado (que pueda ser resuelto por el servidor)
  • Nombre de host (que puede ser resuelto por el servidor)
  • Una dirección IP.
Redes IP

Cualquiera de los siguientes formatos es válido:

  • a.b.c.d/zdonde a.b.c.d es la red y z es el número de bits de la máscara de red; por ejemplo 192.168.0.0/24.
  • a.b.c.d/netmaskdonde a.b.c.d es la red y netmask es la máscara de red; por ejemplo, 192.168.100.8/255.255.255.0.
Netgroups
El formato @group-name formato , donde group-name es el nombre del grupo de red NIS.

3.5. Instalación de NFS

Este procedimiento instala todos los paquetes necesarios para montar o exportar recursos compartidos NFS.

Procedimiento

  • Instale el paquete nfs-utils: 

    # yum install nfs-utils
    Copy to Clipboard

3.6. Descubrir las exportaciones NFS

Este procedimiento descubre qué sistemas de archivos exporta un determinado servidor NFSv3 o NFSv4.

Procedimiento

  • Con cualquier servidor que soporte NFSv3, utilice la utilidad showmount: 

    $ showmount --exports my-server

Export list for my-server
/exports/foo
/exports/bar
    Copy to Clipboard

  • Con cualquier servidor que soporte NFSv4, monte el directorio raíz y busque: 

    # mount my-server:/ /mnt/
# ls /mnt/

exports

# ls /mnt/exports/

foo
bar
    Copy to Clipboard

En los servidores que soportan tanto NFSv4 como NFSv3, ambos métodos funcionan y dan los mismos resultados.

Recursos adicionales

  • La página de manual showmount(8).

3.7. Montaje de un recurso compartido NFS con mount

Este procedimiento monta un recurso compartido NFS exportado desde un servidor mediante la utilidad mount.

Procedimiento

  • Para montar un recurso compartido NFS, utilice el siguiente comando: 

    # mount -t nfs -o options host:/remote/export /local/directory
    Copy to Clipboard

    Este comando utiliza las siguientes variables:

    options
    Una lista delimitada por comas de opciones de montaje.
    host
    El nombre de host, la dirección IP o el nombre de dominio completo del servidor que exporta el sistema de archivos que desea montar.
    /remote/export
    El sistema de archivos o el directorio que se exporta desde el servidor, es decir, el directorio que se desea montar.
    /local/directory
    La ubicación del cliente donde /remote/export está montado.

Recursos adicionales

3.8. Opciones comunes de montaje NFS

Esta sección enumera las opciones que se utilizan habitualmente al montar recursos compartidos NFS. Estas opciones se pueden utilizar con los comandos de montaje manual, la configuración de /etc/fstab y autofs.

lookupcache=mode
Especifica cómo debe gestionar el núcleo su caché de entradas de directorio para un punto de montaje determinado. Los argumentos válidos para mode son all, none, o positive.
nfsvers=version

Especifica la versión del protocolo NFS a utilizar, donde version es 3, 4, 4.0, 4.1, o 4.2. Esto es útil para los hosts que ejecutan múltiples servidores NFS, o para desactivar el reintento de un montaje con versiones inferiores. Si no se especifica ninguna versión, NFS utiliza la versión más alta soportada por el kernel y la utilidad mount.

La opción vers es idéntica a nfsvers, y se incluye en esta versión por razones de compatibilidad.

noacl
Desactiva todo el procesamiento de ACL. Esto puede ser necesario cuando se interactúa con versiones antiguas de Red Hat Enterprise Linux, Red Hat Linux o Solaris, porque la tecnología ACL más reciente no es compatible con los sistemas más antiguos.
nolock
Desactiva el bloqueo de archivos. Esta configuración es a veces necesaria cuando se conecta a servidores NFS muy antiguos.
noexec
Evita la ejecución de binarios en sistemas de archivos montados. Esto es útil si el sistema está montando un sistema de archivos que no es Linux y que contiene binarios incompatibles.
nosuid
Desactiva los bits set-user-identifier y set-group-identifier. Esto evita que los usuarios remotos obtengan privilegios superiores al ejecutar un programa setuid.
port=num
Especifica el valor numérico del puerto del servidor NFS. Si num es 0 (el valor por defecto), entonces mount consulta al servicio rpcbind en el host remoto el número de puerto a utilizar. Si el servicio NFS en el host remoto no está registrado con su servicio rpcbind, el número de puerto NFS estándar de TCP 2049 se utiliza en su lugar.
rsize=num y wsize=num

Estas opciones establecen el número máximo de bytes que se pueden transferir en una sola operación de lectura o escritura de NFS.

No hay un valor fijo por defecto para rsize y wsize. Por defecto, NFS utiliza el mayor valor posible que soportan tanto el servidor como el cliente. En Red Hat Enterprise Linux 8, el máximo del cliente y del servidor es 1.048.576 bytes. Para más detalles, vea el artículo ¿Cuáles son los valores máximos y predeterminados para rsize y wsize con montajes NFS? Artículo de KBase.

sec=flavors

Sabores de seguridad a utilizar para acceder a los archivos de la exportación montada. El valor flavors es una lista separada por dos puntos de uno o más tipos de seguridad.

Por defecto, el cliente intenta encontrar un tipo de seguridad que tanto el cliente como el servidor soporten. Si el servidor no admite ninguno de los tipos seleccionados, la operación de montaje falla.

Sabores disponibles:

  • sec=sys utiliza los UID y GID locales de UNIX. Estos utilizan AUTH_SYS para autenticar las operaciones NFS.
  • sec=krb5 utiliza Kerberos V5 en lugar de los UID y GID locales de UNIX para autenticar a los usuarios.
  • sec=krb5i utiliza Kerberos V5 para la autenticación de usuarios y realiza una comprobación de la integridad de las operaciones NFS mediante sumas de comprobación seguras para evitar la manipulación de los datos.
  • sec=krb5p utiliza Kerberos V5 para la autenticación de usuarios y la comprobación de la integridad, y encripta el tráfico NFS para evitar que se husmee. Esta es la configuración más segura, pero también implica la mayor sobrecarga de rendimiento.
tcp
Indica al montaje NFS que utilice el protocolo TCP.

Recursos adicionales

  • La página de manual mount(8)
  • La página de manual nfs(5)

Capítulo 4. Exportación de recursos compartidos NFS

Como administrador del sistema, puede utilizar el servidor NFS para compartir un directorio en su sistema a través de la red.

4.1. Introducción a NFS

Esta sección explica los conceptos básicos del servicio NFS.

Un sistema de archivos de red (NFS) permite a los hosts remotos montar sistemas de archivos a través de una red e interactuar con esos sistemas de archivos como si estuvieran montados localmente. Esto permite consolidar los recursos en servidores centralizados en la red.

El servidor NFS consulta el archivo de configuración /etc/exports para determinar si el cliente puede acceder a cualquier sistema de archivos exportado. Una vez verificado, todas las operaciones de archivos y directorios están disponibles para el usuario.

4.2. Versiones de NFS compatibles

Esta sección lista las versiones de NFS soportadas en Red Hat Enterprise Linux y sus características.

Actualmente, Red Hat Enterprise Linux 8 soporta las siguientes versiones principales de NFS:

  • La versión 3 de NFS (NFSv3) admite escrituras asíncronas seguras y es más robusta en la gestión de errores que la anterior NFSv2; también admite tamaños de archivo y desplazamientos de 64 bits, lo que permite a los clientes acceder a más de 2 GB de datos de archivo.
  • La versión 4 de NFS (NFSv4) funciona a través de cortafuegos y en Internet, ya no requiere un servicio rpcbind, admite listas de control de acceso (ACL) y utiliza operaciones con estado.

La versión 2 de NFS (NFSv2) ya no es soportada por Red Hat.

Versión NFS por defecto

La versión NFS por defecto en Red Hat Enterprise Linux 8 es la 4.2. Los clientes NFS intentan montar usando NFSv4.2 por defecto, y vuelven a NFSv4.1 cuando el servidor no soporta NFSv4.2. El montaje vuelve a ser NFSv4.0 y luego NFSv3.

Características de las versiones menores de NFS

A continuación se presentan las características de NFSv4.2 en Red Hat Enterprise Linux 8:

Copia del lado del servidor
Permite que el cliente NFS copie datos de forma eficiente sin desperdiciar recursos de red utilizando la llamada al sistema copy_file_range().
Archivos dispersos
Permite que los archivos tengan uno o más holes, que son bloques de datos no asignados o no inicializados que constan sólo de ceros. La operación lseek() en NFSv4.2 admite seek_hole() y seek_data(), lo que permite a las aplicaciones trazar la ubicación de los huecos en el archivo disperso.
Reserva de espacio
Permite a los servidores de almacenamiento reservar espacio libre, lo que impide que los servidores se queden sin espacio. NFSv4.2 admite la operación allocate() para reservar espacio, la operación deallocate() para desreservar espacio y la operación fallocate() para preasignar o desasignar espacio en un archivo.
Etiquetado NFS
Aplica los derechos de acceso a los datos y habilita las etiquetas SELinux entre un cliente y un servidor para archivos individuales en un sistema de archivos NFS.
Mejoras en el diseño
Proporciona la operación layoutstats(), que permite a algunos servidores NFS paralelos (pNFS) recoger mejores estadísticas de rendimiento.

A continuación se detallan las características de NFSv4.1:

  • Mejora el rendimiento y la seguridad de la red, y también incluye soporte del lado del cliente para pNFS.
  • Ya no se requiere una conexión TCP independiente para las devoluciones de llamada, lo que permite a un servidor NFS conceder delegaciones incluso cuando no puede contactar con el cliente: por ejemplo, cuando interfiere NAT o un cortafuegos.
  • Proporciona la semántica de "exactamente una vez" (excepto para las operaciones de reinicio), evitando un problema anterior por el que ciertas operaciones devolvían a veces un resultado inexacto si se perdía una respuesta y la operación se enviaba dos veces.

4.3. Los protocolos TCP y UDP en NFSv3 y NFSv4

NFSv4 requiere el Protocolo de Control de Transmisión (TCP) que se ejecuta en una red IP.

NFSv3 también podía utilizar el Protocolo de Datagrama de Usuario (UDP) en versiones anteriores de Red Hat Enterprise Linux. En Red Hat Enterprise Linux 8, NFS sobre UDP ya no está soportado. Por defecto, UDP está desactivado en el servidor NFS.

4.4. Servicios requeridos por NFS

Esta sección enumera los servicios del sistema que se requieren para ejecutar un servidor NFS o montar recursos compartidos NFS. Red Hat Enterprise Linux inicia estos servicios automáticamente.

Red Hat Enterprise Linux utiliza una combinación de soporte a nivel de kernel y procesos de servicio para proporcionar el intercambio de archivos NFS. Todas las versiones de NFS se basan en llamadas de procedimiento remoto (RPC) entre clientes y servidores. Para compartir o montar sistemas de archivos NFS, los servicios siguientes trabajan juntos dependiendo de la versión de NFS implementada:

nfsd
El módulo del núcleo del servidor NFS que atiende las solicitudes de sistemas de archivos NFS compartidos.
rpcbind
Acepta las reservas de puertos de los servicios RPC locales. Estos puertos se ponen a disposición (o se anuncian) para que los servicios RPC remotos correspondientes puedan acceder a ellos. El servicio rpcbind responde a las solicitudes de servicios RPC y establece conexiones con el servicio RPC solicitado. Esto no se utiliza con NFSv4.
rpc.mountd
Este proceso es utilizado por un servidor NFS para procesar las solicitudes MOUNT de los clientes NFSv3. Comprueba que el recurso compartido NFS solicitado está actualmente exportado por el servidor NFS y que el cliente puede acceder a él. Si la solicitud de montaje está permitida, el servicio nfs-mountd responde con un estado de éxito y proporciona el File-Handle de este recurso compartido NFS al cliente NFS.
rpc.nfsd
Este proceso permite definir las versiones y protocolos NFS explícitos que el servidor anuncia. Trabaja con el kernel de Linux para satisfacer las demandas dinámicas de los clientes NFS, como proporcionar hilos del servidor cada vez que un cliente NFS se conecta. Este proceso se corresponde con el servicio nfs-server.
lockd
Es un hilo del núcleo que se ejecuta tanto en los clientes como en los servidores. Implementa el protocolo Network Lock Manager (NLM), que permite a los clientes NFSv3 bloquear archivos en el servidor. Se inicia automáticamente siempre que se ejecuta el servidor NFS y siempre que se monta un sistema de archivos NFS.
rpc.statd
Este proceso implementa el protocolo RPC Network Status Monitor (NSM), que notifica a los clientes NFS cuando un servidor NFS se reinicia sin que se caiga. El servicio rpc-statd es iniciado automáticamente por el servicio nfs-server, y no requiere la configuración del usuario. No se utiliza con NFSv4.
rpc.rquotad
Este proceso proporciona información sobre las cuotas de los usuarios remotos. El servicio rpc-rquotad es iniciado automáticamente por el servicio nfs-server y no requiere configuración por parte del usuario.
rpc.idmapd

Este proceso proporciona llamadas ascendentes al cliente y al servidor NFSv4, que mapean entre los nombres NFSv4 on-the-wire (cadenas en forma de user@domain) y los UID y GID locales. Para que idmapd funcione con NFSv4, el archivo /etc/idmapd.conf debe estar configurado. Como mínimo, debe especificarse el parámetro Domain, que define el dominio de mapeo NFSv4. Si el dominio de mapeo NFSv4 es el mismo que el nombre de dominio DNS, este parámetro puede omitirse. El cliente y el servidor deben estar de acuerdo con el dominio de mapeo NFSv4 para que el mapeo de ID funcione correctamente.

Sólo el servidor NFSv4 utiliza rpc.idmapd, que es iniciado por el servicio nfs-idmapd. El cliente NFSv4 utiliza la utilidad basada en llaveros nfsidmap, que es llamada por el kernel bajo demanda para realizar el mapeo de ID. Si hay un problema con nfsidmap, el cliente vuelve a utilizar rpc.idmapd.

Los servicios RPC con NFSv4

Los protocolos de montaje y bloqueo se han incorporado al protocolo NFSv4. El servidor también escucha en el conocido puerto TCP 2049. Así, NFSv4 no necesita interactuar con los servicios rpcbind, lockd y rpc-statd. El servicio nfs-mountd sigue siendo necesario en el servidor NFS para configurar las exportaciones, pero no interviene en ninguna operación over-the-wire.

Recursos adicionales

4.5. Formatos de nombres de host NFS

En esta sección se describen diferentes formatos que se pueden utilizar para especificar un host al montar o exportar un recurso compartido NFS.

Puede especificar el host en los siguientes formatos:

Máquina individual

Cualquiera de los siguientes:

  • Un nombre de dominio completamente calificado (que pueda ser resuelto por el servidor)
  • Nombre de host (que puede ser resuelto por el servidor)
  • Una dirección IP.
Redes IP

Cualquiera de los siguientes formatos es válido:

  • a.b.c.d/zdonde a.b.c.d es la red y z es el número de bits de la máscara de red; por ejemplo 192.168.0.0/24.
  • a.b.c.d/netmaskdonde a.b.c.d es la red y netmask es la máscara de red; por ejemplo, 192.168.100.8/255.255.255.0.
Netgroups
El formato @group-name formato , donde group-name es el nombre del grupo de red NIS.

4.6. Configuración del servidor NFS

Esta sección describe la sintaxis y las opciones de dos formas de configurar las exportaciones en un servidor NFS:

  • Edición manual del archivo de configuración /etc/exports
  • Utilizando la utilidad exportfs en la línea de comandos

4.6.1. El archivo de configuración /etc/exports

El archivo /etc/exports controla qué sistemas de archivos se exportan a los hosts remotos y especifica las opciones. Sigue las siguientes reglas de sintaxis:

  • Las líneas en blanco se ignoran.
  • Para añadir un comentario, inicie una línea con la marca de almohadilla (#).
  • Puede envolver las líneas largas con una barra invertida (\).
  • Cada sistema de archivos exportado debe estar en su propia línea individual.
  • Cualquier lista de hosts autorizados colocada después de un sistema de archivos exportado debe estar separada por caracteres de espacio.
  • Las opciones para cada uno de los hosts deben colocarse entre paréntesis directamente después del identificador del host, sin espacios de separación entre el host y el primer paréntesis.
Entrada de exportación

Cada entrada de un sistema de archivos exportado tiene la siguiente estructura: 

export host(options)
Copy to Clipboard

También es posible especificar varios hosts, junto con opciones específicas para cada uno de ellos. Para ello, escríbalos en la misma línea como una lista delimitada por espacios, con cada nombre de host seguido de sus respectivas opciones (entre paréntesis), como en: 

export host1(options1) host2(options2) host3(options3)
Copy to Clipboard

En esta estructura:

export
El directorio que se exporta
host
El host o la red a la que se comparte la exportación
options
Las opciones que se utilizarán para el anfitrión

Ejemplo 4.1. Un simple archivo /etc/exports

En su forma más simple, el archivo /etc/exports sólo especifica el directorio exportado y los hosts autorizados a acceder a él: 

/exportado/directorio bob.ejemplo.com
Copy to Clipboard

Aquí, bob.example.com puede montar /exported/directory/ desde el servidor NFS. Como no se especifican opciones en este ejemplo, NFS utiliza las opciones por defecto.

Importante

El formato del archivo /etc/exports es muy preciso, sobre todo en lo que respecta al uso del carácter de espacio. Recuerde que siempre debe separar los sistemas de archivos exportados de los hosts y los hosts entre sí con un carácter de espacio. Sin embargo, no debe haber ningún otro carácter de espacio en el archivo, excepto en las líneas de comentario.

Por ejemplo, las dos líneas siguientes no significan lo mismo: 

/home bob.example.com(rw)
/home bob.example.com (rw)
Copy to Clipboard

La primera línea permite que sólo los usuarios de bob.example.com tengan acceso de lectura y escritura al directorio /home. La segunda línea permite a los usuarios de bob.example.com montar el directorio como sólo lectura (el valor predeterminado), mientras que el resto del mundo puede montarlo como lectura/escritura.

Opciones por defecto

Las opciones por defecto para una entrada de exportación son:

ro
El sistema de archivos exportado es de sólo lectura. Los hosts remotos no pueden cambiar los datos compartidos en el sistema de archivos. Para permitir a los hosts realizar cambios en el sistema de archivos (es decir, leer y escribir), especifique la opción rw.
sync
El servidor NFS no responderá a las solicitudes antes de que los cambios realizados por las solicitudes anteriores se escriban en el disco. Para habilitar las escrituras asíncronas en su lugar, especifique la opción async.
wdelay
El servidor NFS retrasará la escritura en el disco si sospecha que otra petición de escritura es inminente. Esto puede mejorar el rendimiento, ya que reduce el número de veces que se debe acceder al disco mediante comandos de escritura separados, reduciendo así la sobrecarga de escritura. Para desactivar esto, especifique la opción no_wdelay, que sólo está disponible si también se especifica la opción de sincronización por defecto.
root_squash

Esto evita que los usuarios root conectados remotamente (en lugar de localmente) tengan privilegios de root; en su lugar, el servidor NFS les asigna el ID de usuario nobody. Esto efectivamente "aplasta" el poder del usuario root remoto al usuario local más bajo, evitando posibles escrituras no autorizadas en el servidor remoto. Para desactivar el aplastamiento de la raíz, especifique la opción no_root_squash.

Para aplastar a todos los usuarios remotos (incluido el root), utilice la opción all_squash. Para especificar los identificadores de usuario y grupo que el servidor NFS debe asignar a los usuarios remotos de un determinado host, utilice las opciones anonuid y anongid, respectivamente, como en: 

export host(anonuid=uid,anongid=gid)
Copy to Clipboard

Aquí, uid y gid son el número de identificación del usuario y el número de identificación del grupo, respectivamente. Las opciones anonuid y anongid permiten crear una cuenta especial de usuario y de grupo para que los usuarios remotos de NFS la compartan.

Por defecto, las listas de control de acceso (ACL) son soportadas por NFS bajo Red Hat Enterprise Linux. Para desactivar esta función, especifique la opción no_acl al exportar el sistema de archivos.

Opciones por defecto y anuladas

Cada valor por defecto para cada sistema de archivos exportado debe ser anulado explícitamente. Por ejemplo, si no se especifica la opción rw, el sistema de archivos exportado se comparte como de sólo lectura. La siguiente es una línea de ejemplo de /etc/exports que anula dos opciones por defecto: 

/otro/exportado/directorio 192.168.0.3(rw,async)
Copy to Clipboard

En este ejemplo, 192.168.0.3 puede montar /another/exported/directory/ lectura y escritura, y todas las escrituras en disco son asíncronas.

4.6.2. La utilidad exportfs

La utilidad exportfs permite al usuario root exportar o desexportar directorios selectivamente sin reiniciar el servicio NFS. Cuando se le dan las opciones adecuadas, la utilidad exportfs escribe los sistemas de archivos exportados en /var/lib/nfs/xtab. Dado que el servicio nfs-mountd hace referencia al archivo xtab cuando decide los privilegios de acceso a un sistema de archivos, los cambios en la lista de sistemas de archivos exportados tienen efecto inmediato.

Opciones comunes de exportfs

A continuación se presenta una lista de las opciones más utilizadas disponibles para exportfs:

-r
Hace que se exporten todos los directorios listados en /etc/exports construyendo una nueva lista de exportación en /etc/lib/nfs/xtab. Esta opción actualiza efectivamente la lista de exportación con cualquier cambio realizado en /etc/exports.
-a
Hace que se exporten o no todos los directorios, dependiendo de qué otras opciones se pasen a exportfs. Si no se especifican otras opciones, exportfs exporta todos los sistemas de archivos especificados en /etc/exports.
-o file-systems
Especifica los directorios a exportar que no aparecen en /etc/exports. Sustituya file-systems con los sistemas de archivos adicionales que se van a exportar. Estos sistemas de archivos deben tener el mismo formato que el especificado en /etc/exports. Esta opción suele utilizarse para probar un sistema de archivos exportado antes de añadirlo permanentemente a la lista de sistemas de archivos exportados.
-i
Ignora /etc/exports; sólo se utilizan las opciones dadas desde la línea de comandos para definir los sistemas de archivos exportados.
-u
Desexporta todos los directorios compartidos. El comando exportfs -ua suspende la compartición de archivos NFS mientras mantiene todos los servicios NFS activos. Para volver a habilitar el uso compartido de NFS, utilice exportfs -r.
-v
Operación verbosas, donde los sistemas de archivos que se exportan o no se exportan se muestran con mayor detalle cuando se ejecuta el comando exportfs.

Si no se pasan opciones a la utilidad exportfs, ésta muestra una lista de los sistemas de archivos exportados actualmente.

Recursos adicionales

  • Para obtener información sobre los diferentes métodos para especificar los nombres de host, consulte Sección 4.5, “Formatos de nombres de host NFS”.
  • Para obtener una lista completa de las opciones de exportación, consulte la página de manual exports(5).
  • Para más información sobre la utilidad exportfs, consulte la página de manual exportfs(8).

4.7. NFS y rpcbind

Esta sección explica el propósito del servicio rpcbind, que es requerido por NFSv3.

El servicio rpcbind asigna los servicios de llamada a procedimiento remoto (RPC) a los puertos en los que escuchan. Los procesos RPC notifican a rpcbind cuando se inician, registrando los puertos en los que escuchan y los números de programa RPC que esperan servir. A continuación, el sistema cliente se pone en contacto con rpcbind en el servidor con un número de programa RPC concreto. El servicio rpcbind redirige al cliente al número de puerto adecuado para que pueda comunicarse con el servicio solicitado.

Dado que los servicios basados en RPC dependen de rpcbind para realizar todas las conexiones con las solicitudes de los clientes entrantes, rpcbind debe estar disponible antes de que se inicie cualquiera de estos servicios.

Las reglas de control de acceso para rpcbind afectan a todos los servicios basados en RPC. Alternativamente, es posible especificar reglas de control de acceso para cada uno de los demonios RPC de NFS.

Recursos adicionales

  • Para conocer la sintaxis precisa de las reglas de control de acceso, consulte las páginas de manual rpc.mountd(8) y rpc.statd(8).

4.8. Instalación de NFS

Este procedimiento instala todos los paquetes necesarios para montar o exportar recursos compartidos NFS.

Procedimiento

  • Instale el paquete nfs-utils: 

    # yum install nfs-utils
    Copy to Clipboard

4.9. Iniciar el servidor NFS

Este procedimiento describe cómo iniciar el servidor NFS, que es necesario para exportar los recursos compartidos NFS.

Requisitos previos

  • En el caso de los servidores que admiten conexiones NFSv2 o NFSv3, el servicio rpcbind debe estar en funcionamiento. Para comprobar que rpcbind está activo, utilice el siguiente comando: 

    $ systemctl status rpcbind
    Copy to Clipboard

    Si el servicio está detenido, inícielo y actívelo: 

    $ systemctl enable --now rpcbind
    Copy to Clipboard

Procedimiento

  • Para iniciar el servidor NFS y permitir que se inicie automáticamente en el arranque, utilice el siguiente comando: 

    # systemctl enable --now nfs-server
    Copy to Clipboard

Recursos adicionales

4.10. Solución de problemas de NFS y rpcbind

Debido a que el servicio rpcbind proporciona la coordinación entre los servicios RPC y los números de puerto utilizados para comunicarse con ellos, es útil ver el estado de los servicios RPC actuales utilizando rpcbind cuando se solucionan problemas. La utilidad rpcinfo muestra cada servicio basado en RPC con números de puerto, un número de programa RPC, un número de versión y un tipo de protocolo IP (TCP o UDP).

Procedimiento

  1. Para asegurarse de que los servicios basados en NFS RPC están habilitados para rpcbind, utilice el siguiente comando: 

    # rpcinfo -p
    Copy to Clipboard

    Ejemplo 4.2. salida del comando rpcinfo -p

    La siguiente es una muestra de la salida de este comando: 

       program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
    100005    1   udp  20048  mountd
    100005    1   tcp  20048  mountd
    100005    2   udp  20048  mountd
    100005    2   tcp  20048  mountd
    100005    3   udp  20048  mountd
    100005    3   tcp  20048  mountd
    100024    1   udp  37769  status
    100024    1   tcp  49349  status
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100227    3   tcp   2049  nfs_acl
    100021    1   udp  56691  nlockmgr
    100021    3   udp  56691  nlockmgr
    100021    4   udp  56691  nlockmgr
    100021    1   tcp  46193  nlockmgr
    100021    3   tcp  46193  nlockmgr
    100021    4   tcp  46193  nlockmgr
    Copy to Clipboard

    Si uno de los servicios NFS no se inicia correctamente, rpcbind no podrá asignar las peticiones RPC de los clientes para ese servicio al puerto correcto.

  2. En muchos casos, si NFS no está presente en la salida de rpcinfo, reiniciar NFS hace que el servicio se registre correctamente en rpcbind y comience a funcionar: 

    # systemctl restart nfs-server
    Copy to Clipboard

Recursos adicionales

4.11. Configurar el servidor NFS para que funcione detrás de un cortafuegos

NFS requiere el servicio rpcbind, que asigna dinámicamente los puertos para los servicios RPC y puede causar problemas para configurar las reglas del cortafuegos. Este procedimiento describe cómo configurar el servidor NFS para que funcione detrás de un cortafuegos.

Procedimiento

  1. Para permitir que los clientes accedan a los recursos compartidos NFS detrás de un cortafuegos, establezca en qué puertos se ejecutan los servicios RPC en la sección [mountd] del archivo /etc/nfs.conf: 

    [mountd]

port=port-number
    Copy to Clipboard

    Esto añade la opción -p port-number a la línea de comandos rpc.mount rpc.mount -p port-number.

  2. Para permitir que los clientes accedan a los recursos compartidos de NFS detrás de un firewall, configure el firewall ejecutando los siguientes comandos en el servidor NFS: 

    firewall-cmd --permanent --add-service mountd
firewall-cmd --permanent --add-service rpc-bind
firewall-cmd --permanent --add-service nfs
firewall-cmd --permanent --add-port=<mountd-port>/tcp
firewall-cmd --permanent --add-port=<mountd-port>/udp
firewall-cmd --reload
    Copy to Clipboard

    En los comandos, sustituya <mountd-port> por el puerto previsto o un rango de puertos. Al especificar un rango de puertos, utilice la sintaxis --add-port=<mountd-port>-<mountd-port>/udp.

  3. Para permitir que las devoluciones de llamada de NFSv4.0 atraviesen los cortafuegos, configure /proc/sys/fs/nfs/nfs_callback_tcpport y permita que el servidor se conecte a ese puerto en el cliente.

    Este paso no es necesario para NFSv4.1 o superior, y los otros puertos para mountd, statd, y lockd no son necesarios en un entorno NFSv4 puro.

  4. Para especificar los puertos que utilizará el servicio RPC nlockmgr, establezca el número de puerto para las opciones nlm_tcpport y nlm_udpport en el archivo /etc/modprobe.d/lockd.conf.

  5. Reinicie el servidor NFS: 

    #  systemctl restart nfs-server
    Copy to Clipboard

    Si NFS no se inicia, compruebe /var/log/messages. Normalmente, NFS no se inicia si se especifica un número de puerto que ya está en uso.

  6. Confirme que los cambios han surtido efecto: 

    # rpcinfo -p
    Copy to Clipboard

Recursos adicionales

4.12. Exportación de la cuota RPC a través de un cortafuegos

Si exporta un sistema de archivos que utiliza cuotas de disco, puede utilizar el servicio de llamada a procedimiento remoto (RPC) de cuotas para proporcionar datos de cuotas de disco a los clientes NFS.

Procedimiento

  1. Habilite e inicie el servicio rpc-rquotad: 

    # systemctl enable --now rpc-rquotad
    Copy to Clipboard
    Nota

    El servicio rpc-rquotad, si está activado, se inicia automáticamente después de iniciar el servicio nfs-server.

  2. Para que el servicio RPC de cuotas sea accesible detrás de un cortafuegos, el puerto TCP (o UDP, si está habilitado) 875 debe estar abierto. El número de puerto por defecto se define en el archivo /etc/services.

    Puede anular el número de puerto por defecto añadiendo -p port-number a la variable RPCRQUOTADOPTS en el archivo /etc/sysconfig/rpc-rquotad.

  3. Por defecto, los hosts remotos sólo pueden leer las cuotas. Si desea permitir que los clientes establezcan cuotas, añada la opción -S a la variable RPCRQUOTADOPTS en el archivo /etc/sysconfig/rpc-rquotad.

  4. Reinicie rpc-rquotad para que los cambios en el archivo /etc/sysconfig/rpc-rquotad surtan efecto: 

    # systemctl restart rpc-rquotad
    Copy to Clipboard

4.13. Activación de NFS sobre RDMA (NFSoRDMA)

El servicio de acceso directo a memoria remota (RDMA) funciona automáticamente en Red Hat Enterprise Linux 8 si hay hardware compatible con RDMA.

Procedimiento

  1. Instale el paquete rdma-core: 

    # yum install rdma-core
    Copy to Clipboard

  2. Para activar la carga automática de los módulos NFSoRDMA server, añada la opción SVCRDMA_LOAD=yes en una nueva línea del archivo de configuración /etc/rdma/rdma.conf.

    La opción rdma=20049 en la sección [nfsd] del archivo /etc/nfs.conf especifica el número de puerto en el que el servicio NFSoRDMA escucha a los clientes. El estándar RFC 5667 especifica que los servidores deben escuchar en el puerto 20049 cuando proporcionan servicios NFSv4 sobre RDMA.

    El archivo /etc/rdma/rdma.conf contiene una línea que establece la opción XPRTRDMA_LOAD=yes por defecto, que solicita al servicio rdma que cargue el módulo NFSoRDMA client.

  3. Reinicie el servicio nfs-server: 

    # systemctl restart nfs-server
    Copy to Clipboard

Recursos adicionales

4.14. Configuración de un servidor sólo NFSv4

Como administrador del servidor NFS, puede configurar el servidor NFS para que sólo admita NFSv4, lo que minimiza el número de puertos abiertos y servicios en ejecución en el sistema.

4.14.1. Ventajas e inconvenientes de un servidor sólo NFSv4

En esta sección se explican las ventajas e inconvenientes de configurar el servidor NFS para que sólo admita NFSv4.

Por defecto, el servidor NFS soporta conexiones NFSv3 y NFSv4 en Red Hat Enterprise Linux 8. Sin embargo, también puede configurar NFS para que sólo soporte la versión 4.0 y posteriores. Esto minimiza el número de puertos abiertos y servicios en ejecución en el sistema, porque NFSv4 no requiere que el servicio rpcbind escuche en la red.

Cuando su servidor NFS está configurado como NFSv4 solamente, los clientes que intentan montar recursos compartidos usando NFSv3 fallan con un error como el siguiente: 

La versión de NFS o el protocolo de transporte solicitados no son compatibles.
Copy to Clipboard

Opcionalmente, también puede deshabilitar la escucha de las llamadas de protocolo RPCBIND, MOUNT, y NSM, que no son necesarias en el caso de NFSv4 solamente.

Los efectos de desactivar estas opciones adicionales son:

  • Los clientes que intentan montar recursos compartidos desde su servidor utilizando NFSv3 no responden.
  • El propio servidor NFS no puede montar sistemas de archivos NFSv3.

4.14.2. NFS y rpcbind

Esta sección explica el propósito del servicio rpcbind, que es requerido por NFSv3.

El servicio rpcbind asigna los servicios de llamada a procedimiento remoto (RPC) a los puertos en los que escuchan. Los procesos RPC notifican a rpcbind cuando se inician, registrando los puertos en los que escuchan y los números de programa RPC que esperan servir. A continuación, el sistema cliente se pone en contacto con rpcbind en el servidor con un número de programa RPC concreto. El servicio rpcbind redirige al cliente al número de puerto adecuado para que pueda comunicarse con el servicio solicitado.

Dado que los servicios basados en RPC dependen de rpcbind para realizar todas las conexiones con las solicitudes de los clientes entrantes, rpcbind debe estar disponible antes de que se inicie cualquiera de estos servicios.

Las reglas de control de acceso para rpcbind afectan a todos los servicios basados en RPC. Alternativamente, es posible especificar reglas de control de acceso para cada uno de los demonios RPC de NFS.

Recursos adicionales

  • Para conocer la sintaxis precisa de las reglas de control de acceso, consulte las páginas de manual rpc.mountd(8) y rpc.statd(8).

4.14.3. Configurar el servidor NFS para que sólo admita NFSv4

Este procedimiento describe cómo configurar el servidor NFS para que sólo admita la versión 4.0 y posteriores de NFS.

Procedimiento

  1. Desactive NFSv3 añadiendo las siguientes líneas a la sección [nfsd] del archivo de configuración /etc/nfs.conf: 

    [nfsd]

vers3=no
    Copy to Clipboard

  2. Opcionalmente, desactive la escucha de las llamadas de protocolo RPCBIND, MOUNT, y NSM, que no son necesarias en el caso de NFSv4 solamente. Desactive los servicios relacionados: 

    # systemctl mask --now rpc-statd.service rpcbind.service rpcbind.socket
    Copy to Clipboard

  3. Reinicie el servidor NFS: 

    # systemctl restart nfs-server
    Copy to Clipboard

Los cambios surten efecto en cuanto se inicia o reinicia el servidor NFS.

4.14.4. Verificación de la configuración NFSv4-only

Este procedimiento describe cómo verificar que su servidor NFS está configurado en el modo NFSv4-only utilizando la utilidad netstat.

Procedimiento

  • Utilice la utilidad netstat para listar los servicios que escuchan en los protocolos TCP y UDP: 

    # netstat --listening --tcp --udp
    Copy to Clipboard

    Ejemplo 4.3. Salida en un servidor sólo NFSv4

    El siguiente es un ejemplo de salida de netstat en un servidor NFSv4-only; la escucha de RPCBIND, MOUNT, y NSM también está deshabilitada. Aquí, nfs es el único servicio NFS a la escucha: 

    # netstat --listening --tcp --udp

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:ssh             0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:nfs             0.0.0.0:*               LISTEN
tcp6       0      0 [::]:ssh                [::]:*                  LISTEN
tcp6       0      0 [::]:nfs                [::]:*                  LISTEN
udp        0      0 localhost.locald:bootpc 0.0.0.0:*
    Copy to Clipboard

    Ejemplo 4.4. Resultado antes de configurar un servidor sólo NFSv4

    En comparación, la salida de netstat antes de configurar un servidor sólo NFSv4 incluye los servicios sunrpc y mountd: 

    # netstat --listening --tcp --udp

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address State
tcp        0      0 0.0.0.0:ssh             0.0.0.0:*       LISTEN
tcp        0      0 0.0.0.0:40189           0.0.0.0:*       LISTEN
tcp        0      0 0.0.0.0:46813           0.0.0.0:*       LISTEN
tcp        0      0 0.0.0.0:nfs             0.0.0.0:*       LISTEN
tcp        0      0 0.0.0.0:sunrpc          0.0.0.0:*       LISTEN
tcp        0      0 0.0.0.0:mountd          0.0.0.0:*       LISTEN
tcp6       0      0 [::]:ssh                [::]:*          LISTEN
tcp6       0      0 [::]:51227              [::]:*          LISTEN
tcp6       0      0 [::]:nfs                [::]:*          LISTEN
tcp6       0      0 [::]:sunrpc             [::]:*          LISTEN
tcp6       0      0 [::]:mountd             [::]:*          LISTEN
tcp6       0      0 [::]:45043              [::]:*          LISTEN
udp        0      0 localhost:1018          0.0.0.0:*
udp        0      0 localhost.locald:bootpc 0.0.0.0:*
udp        0      0 0.0.0.0:mountd          0.0.0.0:*
udp        0      0 0.0.0.0:46672           0.0.0.0:*
udp        0      0 0.0.0.0:sunrpc          0.0.0.0:*
udp        0      0 0.0.0.0:33494           0.0.0.0:*
udp6       0      0 [::]:33734              [::]:*
udp6       0      0 [::]:mountd             [::]:*
udp6       0      0 [::]:sunrpc             [::]:*
udp6       0      0 [::]:40243              [::]:*
    Copy to Clipboard

Capítulo 5. Asegurar NFS

Para minimizar los riesgos de seguridad de NFS y proteger los datos en el servidor, tenga en cuenta las siguientes secciones cuando exporte sistemas de archivos NFS en un servidor o los monte en un cliente.

5.1. Seguridad NFS con AUTH_SYS y controles de exportación

NFS ofrece las siguientes opciones tradicionales para controlar el acceso a los archivos exportados:

  • El servidor restringe qué hosts pueden montar qué sistemas de archivos, ya sea por dirección IP o por nombre de host.
  • El servidor aplica los permisos del sistema de archivos para los usuarios de los clientes NFS de la misma manera que lo hace para los usuarios locales. Tradicionalmente, NFS hace esto utilizando el mensaje de llamada AUTH_SYS (también llamado AUTH_UNIX), que depende de que el cliente indique el UID y el GID del usuario. Ten en cuenta que esto significa que un cliente malicioso o mal configurado podría fácilmente equivocarse y permitir a un usuario el acceso a archivos que no debería.

Para limitar los riesgos potenciales, los administradores a menudo limitan el acceso a sólo lectura o aplastan los permisos de usuario a un ID de usuario y grupo común. Lamentablemente, estas soluciones impiden que el recurso compartido NFS se utilice de la forma prevista originalmente.

Además, si un atacante se hace con el control del servidor DNS utilizado por el sistema que exporta el sistema de archivos NFS, puede apuntar el sistema asociado a un determinado nombre de host o nombre de dominio completo a una máquina no autorizada. En este punto, la máquina no autorizada is el sistema permitido para montar el recurso compartido NFS, porque no se intercambia información de nombre de usuario o contraseña para proporcionar seguridad adicional para el montaje NFS.

Los comodines deben utilizarse con moderación al exportar directorios a través de NFS, ya que es posible que el alcance del comodín abarque más sistemas de los previstos.

Recursos adicionales

  • Para asegurar NFS y rpcbind, utilice, por ejemplo, nftables y firewalld. Para obtener detalles sobre la configuración de estos marcos, consulte las páginas de manual nft(8) y firewalld-cmd(1).

5.2. Seguridad NFS con AUTH_GSS

Todas las versiones de NFS soportan RPCSEC_GSS y el mecanismo Kerberos.

A diferencia de AUTH_SYS, con el mecanismo RPCSEC_GSS Kerberos, el servidor no depende del cliente para representar correctamente qué usuario está accediendo al archivo. En su lugar, se utiliza la criptografía para autenticar a los usuarios en el servidor, lo que evita que un cliente malicioso se haga pasar por un usuario sin tener las credenciales Kerberos de ese usuario. El uso del mecanismo RPCSEC_GSS Kerberos es la forma más directa de asegurar los montajes porque después de configurar Kerberos, no se necesita ninguna configuración adicional.

5.3. Configuración de un servidor y un cliente NFS para utilizar Kerberos

Kerberos es un sistema de autenticación de red que permite a los clientes y a los servidores autenticarse entre sí mediante el uso de encriptación simétrica y una tercera parte de confianza, el KDC. Red Hat recomienda utilizar Identity Management (IdM) para configurar Kerberos.

Requisitos previos

  • El Centro de Distribución de Claves Kerberos (KDC) está instalado y configurado.

Procedimiento

    • Cree la nfs/hostname.domain@REALM principal en el lado del servidor NFS.
    • Cree la host/hostname.domain@REALM principal tanto en el lado del servidor como en el del cliente.
    • Añade las claves correspondientes a los keytabs del cliente y del servidor.

  2. En el lado del servidor, utilice la opción sec= para habilitar los tipos de seguridad deseados. Para habilitar todos los tipos de seguridad, así como los montajes no criptográficos: 

    /export *(sec=sys:krb5:krb5i:krb5p)
    Copy to Clipboard

    Los sabores de seguridad válidos para usar con la opción sec= son:

    • sys: sin protección criptográfica, por defecto
    • krb5: sólo autenticación
    • krb5i: protección de la integridad
    • krb5p: protección de la intimidad

  3. En el lado del cliente, añada sec=krb5 (o sec=krb5i, o sec=krb5p, dependiendo de la configuración) a las opciones de montaje: 

    # mount -o sec=krb5 server:/export /mnt
    Copy to Clipboard

Recursos adicionales

  • Si necesita escribir archivos como root en el recurso compartido NFS protegido por Kerberos y mantener la propiedad de root sobre estos archivos, consulte https://access.redhat.com/articles/4040141. Tenga en cuenta que esta configuración no se recomienda.
  • Para más información sobre la configuración de NFS, consulte las páginas de manual exports(5) y nfs(5).

5.4. Opciones de seguridad de NFSv4

NFSv4 incluye soporte ACL basado en el modelo de Microsoft Windows NT, no en el modelo POSIX, debido a las características del modelo de Microsoft Windows NT y a su amplia implantación.

Otra característica de seguridad importante de NFSv4 es la eliminación del uso del protocolo MOUNT para montar sistemas de archivos. El protocolo MOUNT presentaba un riesgo de seguridad debido a la forma en que el protocolo procesaba los manejadores de archivos.

5.5. Permisos de archivos en exportaciones NFS montadas

Una vez que el sistema de archivos NFS es montado como lectura o lectura y escritura por un host remoto, la única protección que tiene cada archivo compartido son sus permisos. Si dos usuarios que comparten el mismo valor de ID de usuario montan el mismo sistema de archivos NFS en diferentes sistemas cliente, pueden modificar los archivos del otro. Además, cualquier persona que haya iniciado sesión como root en el sistema cliente puede utilizar el comando su - para acceder a cualquier archivo con el recurso compartido NFS.

Por defecto, las listas de control de acceso (ACLs) son soportadas por NFS bajo Red Hat Enterprise Linux. Red Hat recomienda mantener esta característica habilitada.

Por defecto, NFS utiliza root squashing al exportar un sistema de archivos. Esto establece el ID de usuario de cualquiera que acceda al recurso compartido NFS como usuario root en su máquina local en nobody. El aplastamiento de la raíz se controla con la opción por defecto root_squash; para más información sobre esta opción, consulte Sección 4.6, “Configuración del servidor NFS”.

Al exportar un recurso compartido NFS como de sólo lectura, considere el uso de la opción all_squash. Esta opción hace que todos los usuarios que accedan al sistema de archivos exportado tomen el ID del usuario de nobody.

Capítulo 6. Habilitación de disposiciones SCSI pNFS en NFS

Puede configurar el servidor y el cliente NFS para que utilicen la disposición SCSI pNFS para acceder a los datos. SCSI pNFS es beneficioso en los casos de uso que implican un acceso de larga duración de un solo cliente a un archivo.

Requisitos previos

  • Tanto el cliente como el servidor deben poder enviar comandos SCSI al mismo dispositivo de bloque. Es decir, el dispositivo de bloque debe estar en un bus SCSI compartido.
  • El dispositivo de bloque debe contener un sistema de archivos XFS.
  • El dispositivo SCSI debe ser compatible con las reservas persistentes SCSI, como se describe en la especificación de comandos primarios SCSI-3.

6.1. La tecnología pNFS

La arquitectura pNFS mejora la escalabilidad de NFS. Cuando un servidor implementa pNFS, el cliente puede acceder a los datos a través de varios servidores de forma simultánea. Esto puede suponer una mejora del rendimiento.

pNFS admite los siguientes protocolos o disposiciones de almacenamiento en RHEL:

  • Archivos
  • Flexfiles
  • SCSI

6.2. disposiciones SCSI pNFS

El diseño SCSI se basa en el trabajo de los diseños de bloques pNFS. La disposición se define a través de los dispositivos SCSI. Contiene una serie secuencial de bloques de tamaño fijo como unidades lógicas (LUs) que deben ser capaces de soportar reservas persistentes SCSI. Los dispositivos LU se identifican por su identificación de dispositivo SCSI.

pNFS SCSI funciona bien en casos de uso que implican el acceso de un solo cliente de larga duración a un archivo. Un ejemplo podría ser un servidor de correo o una máquina virtual que albergue un clúster.

Operaciones entre el cliente y el servidor

Cuando un cliente NFS lee de un archivo o escribe en él, el cliente realiza una operación LAYOUTGET. El servidor responde con la ubicación del archivo en el dispositivo SCSI. Es posible que el cliente tenga que realizar una operación adicional de GETDEVICEINFO para determinar qué dispositivo SCSI debe utilizar. Si estas operaciones funcionan correctamente, el cliente puede emitir peticiones de E/S directamente al dispositivo SCSI en lugar de enviar las operaciones READ y WRITE al servidor.

Los errores o la contención entre clientes pueden hacer que el servidor recupere los diseños o no los emita a los clientes. En esos casos, los clientes vuelven a emitir READ y WRITE operaciones al servidor en lugar de enviar solicitudes de E/S directamente al dispositivo SCSI.

Para supervisar las operaciones, consulte Sección 6.7, “Supervisión de la funcionalidad de los diseños SCSI de PNFS”.

Reservas de dispositivos

pNFS SCSI maneja el cercado a través de la asignación de reservas. Antes de que el servidor emita distribuciones a los clientes, reserva el dispositivo SCSI para garantizar que sólo los clientes registrados puedan acceder al dispositivo. Si un cliente puede emitir comandos a ese dispositivo SCSI pero no está registrado en el dispositivo, muchas operaciones del cliente en ese dispositivo fallan. Por ejemplo, el comando blkid en el cliente falla al mostrar el UUID del sistema de archivos XFS si el servidor no ha dado una distribución para ese dispositivo al cliente.

El servidor no elimina su propia reserva persistente. Esto protege los datos dentro del sistema de archivos del dispositivo a través de los reinicios de los clientes y servidores. Para reutilizar el dispositivo SCSI, es posible que tenga que eliminar manualmente la reserva persistente en el servidor NFS.

6.3. Comprobación de un dispositivo SCSI compatible con pNFS

Este procedimiento comprueba si un dispositivo SCSI es compatible con la disposición SCSI pNFS.

Requisitos previos

  • Instale el paquete sg3_utils: 

    # yum install sg3_utils
    Copy to Clipboard

Procedimiento

  • Tanto en el servidor como en el cliente, compruebe que el dispositivo SCSI es compatible: 

    sg_persist --in --report-capabilities --verbose path-to-scsi-device
    Copy to Clipboard

    Asegúrese de que el bit Persist Through Power Loss Active (PTPL_A) está activado.

    Ejemplo 6.1. Un dispositivo SCSI compatible con SCSI pNFS

    El siguiente es un ejemplo de la salida de sg_persist para un dispositivo SCSI que soporta pNFS SCSI. El bit PTPL_A informa de 1. 

        inquiry cdb: 12 00 00 00 24 00
    Persistent Reservation In cmd: 5e 02 00 00 00 00 00 20 00 00
  LIO-ORG   block11           4.0
  Peripheral device type: disk
Report capabilities response:
  Compatible Reservation Handling(CRH): 1
  Specify Initiator Ports Capable(SIP_C): 1
  All Target Ports Capable(ATP_C): 1
  Persist Through Power Loss Capable(PTPL_C): 1
  Type Mask Valid(TMV): 1
  Allow Commands: 1
  Persist Through Power Loss Active(PTPL_A): 1
    Support indicated in Type mask:
      Write Exclusive, all registrants: 1
      Exclusive Access, registrants only: 1
      Write Exclusive, registrants only: 1
      Exclusive Access: 1
      Write Exclusive: 1
      Exclusive Access, all registrants: 1
    Copy to Clipboard

Recursos adicionales

  • La página de manual sg_persist(8)

6.4. Configuración de pNFS SCSI en el servidor

Este procedimiento configura un servidor NFS para exportar una disposición SCSI pNFS.

Procedimiento

  1. En el servidor, monte el sistema de archivos XFS creado en el dispositivo SCSI.

  2. Configure el servidor NFS para exportar la versión 4.1 o superior de NFS. Establezca la siguiente opción en la sección [nfsd] del archivo /etc/nfs.conf: 

    [nfsd]

vers4.1=y
    Copy to Clipboard

  3. Configure el servidor NFS para exportar el sistema de archivos XFS a través de NFS con la opción pnfs:

    Ejemplo 6.2. Una entrada en /etc/exports para exportar pNFS SCSI

    La siguiente entrada en el archivo de configuración /etc/exports exporta el sistema de archivos montado en /exported/directory/ al cliente allowed.example.com como una disposición SCSI pNFS: 

    /exportado/directorio permitido.ejemplo.com(pnfs)
    Copy to Clipboard

Recursos adicionales

6.5. Configuración de pNFS SCSI en el cliente

Este procedimiento configura un cliente NFS para montar una disposición SCSI pNFS.

Requisitos previos

Procedimiento

  • En el cliente, monte el sistema de archivos XFS exportado utilizando la versión 4.1 o superior de NFS: 

    # mount -t nfs -o nfsvers=4.1 host:/remote/export /local/directory
    Copy to Clipboard

    No monte el sistema de archivos XFS directamente sin NFS.

Recursos adicionales

6.6. Liberación de la reserva SCSI pNFS en el servidor

Este procedimiento libera la reserva persistente que un servidor NFS mantiene en un dispositivo SCSI. Esto le permite reutilizar el dispositivo SCSI cuando ya no necesite exportar pNFS SCSI.

Debe eliminar la reserva del servidor. No se puede eliminar de otro IT Nexus.

Requisitos previos

  • Instale el paquete sg3_utils: 

    # yum install sg3_utils
    Copy to Clipboard

Procedimiento

  1. Consultar una reserva existente en el servidor: 

    # sg_persist --read-reservation path-to-scsi-device
    Copy to Clipboard

    Ejemplo 6.3. Consulta de una reserva en /dev/sda

    # sg_persist --read-reservation /dev/sda

  LIO-ORG   block_1           4.0
  Peripheral device type: disk
  PR generation=0x8, Reservation follows:
    Key=0x100000000000000
    scope: LU_SCOPE,  type: Exclusive Access, registrants only
    Copy to Clipboard

  2. Eliminar el registro existente en el servidor: 

    # sg_persist --out \
             --release \
             --param-rk=reservation-key \
             --prout-type=6 \
             path-to-scsi-device
    Copy to Clipboard

    Ejemplo 6.4. Eliminación de una reserva en /dev/sda

    # sg_persist --out \
             --release \
             --param-rk=0x100000000000000 \
             --prout-type=6 \
             /dev/sda

  LIO-ORG   block_1           4.0
  Peripheral device type: disk
    Copy to Clipboard

Recursos adicionales

  • La página de manual sg_persist(8)

6.7. Supervisión de la funcionalidad de los diseños SCSI de PNFS

Puede supervisar si el cliente y el servidor pNFS intercambian operaciones SCSI pNFS adecuadas o si recurren a operaciones NFS normales.

Requisitos previos

  • Un cliente y un servidor SCSI pNFS están configurados.

6.7.1. Comprobación de las operaciones SCSI pNFS desde el servidor mediante nfsstat

Este procedimiento utiliza la utilidad nfsstat para supervisar las operaciones SCSI de pNFS desde el servidor.

Procedimiento

  1. Supervisar las operaciones atendidas desde el servidor: 

    # watch --differences \
        "nfsstat --server | egrep --after-context=1 read\|write\|layout"

Every 2.0s: nfsstat --server | egrep --after-context=1 read\|write\|layout

putrootfh    read         readdir      readlink     remove	 rename
2         0% 0         0% 1         0% 0         0% 0         0% 0         0%
--
setcltidconf verify	  write        rellockowner bc_ctl	 bind_conn
0         0% 0         0% 0         0% 0         0% 0         0% 0         0%
--
getdevlist   layoutcommit layoutget    layoutreturn secinfononam sequence
0         0% 29        1% 49        1% 5         0% 0         0% 2435     86%
    Copy to Clipboard

  2. El cliente y el servidor utilizan operaciones SCSI pNFS cuando:

    • Los contadores layoutget, layoutreturn, y layoutcommit se incrementan. Esto significa que el servidor está sirviendo diseños.
    • Los contadores del servidor read y write no se incrementan. Esto significa que los clientes están realizando peticiones de E/S directamente a los dispositivos SCSI.

6.7.2. Comprobación de las operaciones SCSI de pNFS desde el cliente mediante mountstats

Este procedimiento utiliza el archivo /proc/self/mountstats para supervisar las operaciones SCSI de pNFS desde el cliente.

Procedimiento

  1. Enumerar los contadores de operaciones por monte: 

    # cat /proc/self/mountstats \
      | awk /scsi_lun_0/,/^$/ \
      | egrep device\|READ\|WRITE\|LAYOUT

device 192.168.122.73:/exports/scsi_lun_0 mounted on /mnt/rhel7/scsi_lun_0 with fstype nfs4 statvers=1.1
    nfsv4:  bm0=0xfdffbfff,bm1=0x40f9be3e,bm2=0x803,acl=0x3,sessions,pnfs=LAYOUT_SCSI
            READ: 0 0 0 0 0 0 0 0
           WRITE: 0 0 0 0 0 0 0 0
        READLINK: 0 0 0 0 0 0 0 0
         READDIR: 0 0 0 0 0 0 0 0
       LAYOUTGET: 49 49 0 11172 9604 2 19448 19454
    LAYOUTCOMMIT: 28 28 0 7776 4808 0 24719 24722
    LAYOUTRETURN: 0 0 0 0 0 0 0 0
     LAYOUTSTATS: 0 0 0 0 0 0 0 0
    Copy to Clipboard

  2. En los resultados:

    • Las estadísticas de LAYOUT indican las peticiones en las que el cliente y el servidor utilizan operaciones SCSI pNFS.
    • Las estadísticas READ y WRITE indican las solicitudes en las que el cliente y el servidor vuelven a las operaciones NFS.

Capítulo 7. Cómo empezar con FS-Cache

FS-Cache es una caché local persistente que los sistemas de archivos pueden utilizar para tomar los datos recuperados de la red y almacenarlos en el disco local. Esto ayuda a minimizar el tráfico de red para los usuarios que acceden a los datos de un sistema de archivos montado en la red (por ejemplo, NFS).

7.1. Visión general del FS-Cache

El siguiente diagrama es una ilustración de alto nivel de cómo funciona FS-Cache:

Figura 7.1. Visión general de FS-Cache

FS-Cache está diseñado para ser lo más transparente posible para los usuarios y administradores de un sistema. A diferencia de cachefs en Solaris, FS-Cache permite que un sistema de archivos en un servidor interactúe directamente con la caché local de un cliente sin crear un sistema de archivos sobremontado. Con NFS, una opción de montaje indica al cliente que monte el recurso compartido NFS con FS-cache activado. El punto de montaje provocará la carga automática de dos módulos del kernel: fscache y cachefiles. El demonio cachefilesd se comunica con los módulos del kernel para implementar la caché.

FS-Cache no altera el funcionamiento básico de un sistema de archivos que funciona a través de la red - simplemente proporciona a ese sistema de archivos un lugar persistente en el que puede almacenar datos en caché. Por ejemplo, un cliente puede seguir montando un recurso compartido NFS tanto si FS-Cache está activado como si no. Además, el NFS en caché puede manejar archivos que no caben en la caché (ya sea individual o colectivamente) ya que los archivos pueden ser parcialmente almacenados en caché y no tienen que ser leídos completamente por adelantado. FS-Cache también oculta todos los errores de E/S que se producen en la caché al controlador del sistema de archivos del cliente.

Para proporcionar servicios de caché, FS-Cache necesita un cache back end. Un back end de caché es un controlador de almacenamiento configurado para proporcionar servicios de caché, que es cachefiles. En este caso, FS-Cache requiere un sistema de archivos basado en bloques montado que soporte bmap y atributos extendidos (por ejemplo, ext3) como su back end de caché.

Los sistemas de archivos que soportan las funcionalidades requeridas por el back end de la caché FS-Cache incluyen las implementaciones de Red Hat Enterprise Linux 8 de los siguientes sistemas de archivos:

  • ext3 (con los atributos extendidos activados)
  • ext4
  • XFS

FS-Cache no puede almacenar arbitrariamente en caché cualquier sistema de archivos, ya sea a través de la red o de otra manera: el controlador del sistema de archivos compartido debe ser alterado para permitir la interacción con FS-Cache, el almacenamiento/recuperación de datos, y la configuración y validación de metadatos. FS-Cache necesita indexing keys y coherency data del sistema de archivos en caché para soportar la persistencia: claves de indexación para hacer coincidir los objetos del sistema de archivos con los objetos de la caché, y datos de coherencia para determinar si los objetos de la caché siguen siendo válidos.

Nota

En Red Hat Enterprise Linux 8, el paquete cachefilesd no está instalado por defecto y debe ser instalado manualmente.

7.2. Garantía de funcionamiento

FS-Cache no not garantiza un mayor rendimiento. El uso de una caché incurre en una penalización de rendimiento: por ejemplo, los recursos compartidos NFS en caché añaden accesos a disco a las búsquedas a través de la red. Aunque FS-Cache intenta ser lo más asíncrono posible, hay rutas síncronas (por ejemplo, lecturas) en las que esto no es posible.

Por ejemplo, el uso de FS-Cache para almacenar en caché un recurso compartido NFS entre dos ordenadores a través de una red GigE sin carga probablemente no demostrará ninguna mejora de rendimiento en el acceso a los archivos. Más bien, las peticiones NFS se satisfarán más rápidamente desde la memoria del servidor en lugar de desde el disco local.

El uso de FS-Cache, por lo tanto, es un compromise entre varios factores. Si FS-Cache se utiliza para almacenar en caché el tráfico NFS, por ejemplo, puede ralentizar un poco al cliente, pero reducir masivamente la carga de la red y del servidor al satisfacer las peticiones de lectura localmente sin consumir el ancho de banda de la red.

7.3. Configurar un caché

Actualmente, Red Hat Enterprise Linux 8 sólo proporciona el back-end de almacenamiento en caché cachefiles. El demonio cachefilesd inicia y gestiona cachefiles. El archivo /etc/cachefilesd.conf controla la forma en que cachefiles proporciona los servicios de almacenamiento en caché.

El back end de la caché funciona manteniendo una cierta cantidad de espacio libre en la partición que la alberga. Crece y reduce la caché en respuesta a otros elementos del sistema que utilizan el espacio libre, lo que hace que sea seguro utilizarla en el sistema de archivos raíz (por ejemplo, en un portátil). FS-Cache establece los valores por defecto de este comportamiento, que puede ser configurado a través de cache cull limits. Para más información sobre la configuración de los límites de la caché, vea Sección 7.5, “Configuración de los límites de la caché”.

Este procedimiento muestra cómo configurar un caché.

Requisitos previos

  • El paquete cachefilesd paquete está instalado y el servicio se ha iniciado con éxito. Para asegurarse de que el servicio se está ejecutando, utilice el siguiente comando: 

    # systemctl start cachefilesd
# systemctl status cachefilesd
    Copy to Clipboard

    El estado debe ser active (running).

Procedimiento

  1. Configure en un back end de caché qué directorio utilizar como caché, utilice el siguiente parámetro: 

    $ dir /path/to/cache
    Copy to Clipboard

  2. Normalmente, el directorio del back end de la caché se establece en /etc/cachefilesd.conf como /var/cache/fscache, como en: 

    $ dir /var/cache/fscache
    Copy to Clipboard

  3. Si quiere cambiar el directorio del back end de la caché, el contexto de selinux debe ser el mismo que /var/cache/fscache: 

    # semanage fcontext -a -e /var/cache/fscache /path/to/cache
# restorecon -Rv /path/to/cache
    Copy to Clipboard
  4. Sustituya /path/to/cache por el nombre del directorio al configurar la caché.

  5. Si los comandos dados para establecer el contexto de selinux no funcionaron, utilice los siguientes comandos: 

    # semanage permissive -a cachefilesd_t
# semanage permissive -a cachefiles_kernel_t
    Copy to Clipboard

    FS-Cache almacenará la caché en el sistema de archivos que aloja /path/to/cache. En un portátil, es aconsejable utilizar el sistema de archivos raíz (/) como sistema de archivos anfitrión, pero para una máquina de escritorio sería más prudente montar una partición de disco específicamente para la caché.

  6. El sistema de archivos anfitrión debe soportar atributos extendidos definidos por el usuario; FS-Cache utiliza estos atributos para almacenar información de mantenimiento de coherencia. Para habilitar los atributos extendidos definidos por el usuario para los sistemas de archivos ext3 (es decir device), utilice: 

    # tune2fs -o user_xattr /dev/device
    Copy to Clipboard

  7. Para habilitar los atributos extendidos para un sistema de archivos en el momento del montaje, como alternativa, utilice el siguiente comando: 

    # mount /dev/device /path/to/cache -o user_xattr
    Copy to Clipboard

  8. Una vez que el archivo de configuración esté en su lugar, inicie el servicio cachefilesd: 

    # systemctl start cachefilesd
    Copy to Clipboard

  9. Para configurar cachefilesd para que se inicie en el momento del arranque, ejecute el siguiente comando como root: 

    # systemctl enable cachefilesd
    Copy to Clipboard

7.4. Uso de la caché con NFS

NFS no utilizará la caché a menos que se le indique explícitamente. Este párrafo muestra cómo configurar un montaje NFS utilizando FS-Cache.

Requisitos previos

  • El paquete cachefilesd está instalado y funcionando. Para asegurarse de que se está ejecutando, utilice el siguiente comando: 

    # systemctl start cachefilesd
# systemctl status cachefilesd
    Copy to Clipboard

    El estado debe ser active (running).

  • Monte los recursos compartidos NFS con la siguiente opción: 

    # mount nfs-share:/ /mount/point -o fsc
    Copy to Clipboard

    Todos los accesos a los archivos bajo /mount/point pasará a través de la caché, a menos que el archivo se abra para la E/S directa o la escritura. Para más información, consulte Sección 7.4.2, “Limitaciones de la caché con NFS”. NFS indexa el contenido de la caché utilizando el manejador del archivo NFS, not el nombre del archivo, lo que significa que los archivos con enlaces duros comparten la caché correctamente.

Las versiones 3, 4.0, 4.1 y 4.2 de NFS admiten el almacenamiento en caché. Sin embargo, cada versión utiliza diferentes ramas para el almacenamiento en caché.

7.4.1. Configuración de la compartición de la caché NFS

Hay varios problemas potenciales que tienen que ver con la compartición de la caché NFS. Dado que la caché es persistente, los bloques de datos en la caché están indexados en una secuencia de cuatro claves:

  • Nivel 1: Detalles del servidor
  • Nivel 2: Algunas opciones de montaje; tipo de seguridad; FSID; unificador
  • Nivel 3: Manejador de archivos
  • Nivel 4: Número de página en el expediente

Para evitar problemas de gestión de la coherencia entre los superbloques, todos los superbloques NFS que requieren almacenar datos en caché tienen claves de nivel 2 únicas. Normalmente, dos montajes NFS con el mismo volumen de origen y las mismas opciones comparten un superbloque, y por lo tanto comparten el almacenamiento en caché, incluso si montan diferentes directorios dentro de ese volumen.

Este es un ejemplo de cómo configurar la compartición de caché con diferentes opciones.

Procedimiento

  1. Monte los recursos compartidos NFS con los siguientes comandos: 

    mount home0:/disk0/fred /home/fred -o fsc
mount home0:/disk0/jim /home/jim -o fsc
    Copy to Clipboard

    Aquí, /home/fred y /home/jim probablemente comparten el superbloque ya que tienen las mismas opciones, especialmente si provienen del mismo volumen/partición en el servidor NFS (home0).

  2. Para no compartir el superbloque, utilice el comando mount con las siguientes opciones: 

    mount home0:/disk0/fred /home/fred -o fsc,rsize=8192
mount home0:/disk0/jim /home/jim -o fsc,rsize=65536
    Copy to Clipboard

    En este caso, /home/fred y /home/jim no compartirán el superbloque ya que tienen diferentes parámetros de acceso a la red, que forman parte de la clave de nivel 2.

  3. Para almacenar en caché el contenido de los dos subárboles (/home/fred1 y /home/fred2) twice sin compartir el superbloque, utilice el siguiente comando: 

    mount home0:/disk0/fred /home/fred1 -o fsc,rsize=8192
mount home0:/disk0/fred /home/fred2 -o fsc,rsize=65536
    Copy to Clipboard

  4. Otra forma de evitar la compartición de superbloques es suprimirla explícitamente con el parámetro nosharecache. Utilizando el mismo ejemplo: 

    mount home0:/disk0/fred /home/fred -o nosharecache,fsc
mount home0:/disk0/jim /home/jim -o nosharecache,fsc
    Copy to Clipboard

    Sin embargo, en este caso sólo se permite que uno de los superbloques utilice la caché, ya que no hay nada que distinga las claves de nivel 2 de home0:/disk0/fred y home0:/disk0/jim.

  5. Para especificar el direccionamiento al superbloque, añada un unique identifier en al menos uno de los montajes, es decir fsc=unique-identifier: 

    mount home0:/disk0/fred /home/fred -o nosharecache,fsc
mount home0:/disk0/jim /home/jim -o nosharecache,fsc=jim
    Copy to Clipboard

    Aquí, el identificador único jim se añade a la clave de nivel 2 utilizada en la caché para /home/jim.

Importante

El usuario no puede compartir cachés entre superbloques que tengan diferentes parámetros de comunicación o de protocolo. Por ejemplo, no es posible compartir entre NFSv4.0 y NFSv3 o entre NFSv4.1 y NFSv4.2 porque fuerzan superbloques diferentes. También el ajuste de parámetros, como el tamaño de lectura (rsize), impide compartir la caché porque, de nuevo, fuerza un superbloque diferente.

7.4.2. Limitaciones de la caché con NFS

Hay algunas limitaciones de caché con NFS:

  • Al abrir un archivo desde un sistema de archivos compartido para una E/S directa, se omite automáticamente la caché. Esto se debe a que este tipo de acceso debe ser directo al servidor.
  • La apertura de un archivo desde un sistema de archivos compartido, ya sea para E/S directa o para escritura, vacía la copia en caché del archivo. FS-Cache no volverá a almacenar el archivo en la caché hasta que ya no se abra para E/S directa o escritura.
  • Además, esta versión de FS-Cache sólo almacena en caché los archivos NFS normales. FS-Cache not almacenará en caché directorios, enlaces simbólicos, archivos de dispositivos, FIFOs y sockets.

7.5. Configuración de los límites de la caché

El demonio cachefilesd funciona almacenando en caché los datos remotos de los sistemas de archivos compartidos para liberar espacio en el disco. Esto podría consumir todo el espacio libre disponible, lo que podría ser malo si el disco también albergara la partición raíz. Para controlar esto, cachefilesd intenta mantener una cierta cantidad de espacio libre descartando de la caché los objetos antiguos (es decir, a los que se ha accedido menos recientemente). Este comportamiento se conoce como cache culling.

La selección de la caché se realiza en función del porcentaje de bloques y del porcentaje de archivos disponibles en el sistema de archivos subyacente. Hay ajustes en /etc/cachefilesd.conf que controlan seis límites:

brun N% (porcentaje de bloques), frun N% (porcentaje de archivos)
Si la cantidad de espacio libre y el número de archivos disponibles en la caché superan estos dos límites, la selección se desactiva.
bcull N% (porcentaje de bloques), fcull N% (porcentaje de archivos)
Si la cantidad de espacio disponible o el número de archivos en la caché cae por debajo de cualquiera de estos límites, se inicia la selección.
bstop N% (porcentaje de bloques), fstop N% (porcentaje de archivos)
Si la cantidad de espacio disponible o el número de archivos disponibles en la caché cae por debajo de cualquiera de estos límites, entonces no se permite ninguna otra asignación de espacio en disco o de archivos hasta que el culling haya elevado las cosas por encima de estos límites de nuevo.

El valor por defecto de N para cada ajuste es el siguiente:

  • brun/frun - 10%
  • bcull/fcull - 7 %
  • bstop/fstop - 3%

Al configurar estos ajustes, debe cumplirse lo siguiente:

  • 0
  • 0

Estos son los porcentajes de espacio y archivos disponibles y no aparecen como 100 menos el porcentaje que muestra el programa df.

Importante

El sacrificio depende de los pares bxxx y fxxx simultáneamente; el usuario no puede tratarlos por separado.

7.6. Recuperación de información estadística del módulo del núcleo fscache

FS-Cache también mantiene un registro de información estadística general. Este procedimiento muestra cómo obtener esta información.

Procedimiento

  1. Para ver la información estadística de FS-Cache, utilice el siguiente comando: 

    # cat /proc/fs/fscache/stats
    Copy to Clipboard

Las estadísticas de FS-Cache incluyen información sobre puntos de decisión y contadores de objetos. Para más información, consulte el siguiente documento del kernel:

/usr/share/doc/kernel-doc-4.18.0/Documentation/filesystems/caching/fscache.txt

7.7. Referencias de FS-Cache

Esta sección proporciona información de referencia para FS-Cache.

  1. Para más información sobre cachefilesd y cómo configurarlo, consulte man cachefilesd y man cachefilesd.conf. Los siguientes documentos del kernel también proporcionan información adicional:

    • /usr/share/doc/cachefilesd/README
    • /usr/share/man/man5/cachefilesd.conf.5.gz
    • /usr/share/man/man8/cachefilesd.8.gz

  2. Para información general sobre FS-Cache, incluyendo detalles sobre sus restricciones de diseño, estadísticas disponibles y capacidades, vea el siguiente documento del kernel:

    /usr/share/doc/kernel-doc-4.18.0/Documentation/filesystems/caching/fscache.txt

Capítulo 8. Montaje de un recurso compartido SMB en Red Hat Enterprise Linux

El protocolo Server Message Block (SMB) implementa un protocolo de red de capa de aplicación utilizado para acceder a los recursos de un servidor, como los archivos compartidos y las impresoras compartidas.

Nota

En el contexto de SMB, puedes encontrar menciones sobre el protocolo Common Internet File System (CIFS), que es un dialecto de SMB. Tanto el protocolo SMB como el CIFS están soportados, y el módulo del kernel y las utilidades involucradas en el montaje de recursos compartidos SMB y CIFS utilizan el nombre cifs.

Esta sección describe cómo montar recursos compartidos desde un servidor SMB. Para más detalles sobre la configuración de un servidor SMB en Red Hat Enterprise Linux utilizando Samba, consulte Uso de Samba como servidor.

Requisitos previos

En Microsoft Windows, SMB está implementado por defecto. En Red Hat Enterprise Linux, el módulo del sistema de archivos cifs.ko del kernel proporciona soporte para montar recursos compartidos SMB. Por lo tanto, instale el paquete cifs-utils: 

# yum install cifs-utils
Copy to Clipboard

El paquete cifs-utils proporciona utilidades para:

  • Montar recursos compartidos SMB y CIFS
  • Gestionar las credenciales de NT Lan Manager (NTLM) en el llavero del kernel
  • Establecer y mostrar listas de control de acceso (ACL) en un descriptor de seguridad en recursos compartidos SMB y CIFS

8.1. Versiones de protocolo SMB soportadas

El módulo del kernel cifs.ko soporta las siguientes versiones del protocolo SMB:

  • SMB 1

    Aviso

    El protocolo SMB1 está obsoleto debido a problemas de seguridad conocidos, y sólo es safe to use on a private network. La razón principal por la que SMB1 todavía se proporciona como una opción soportada es que actualmente es la única versión del protocolo SMB que soporta extensiones UNIX. Si no necesita utilizar extensiones UNIX en SMB, Red Hat recomienda encarecidamente utilizar SMB2 o posterior.

  • SMB 2.0
  • SMB 2.1
  • SMB 3.0
  • SMB 3.1.1
Nota

Dependiendo de la versión del protocolo, no se implementan todas las funciones de SMB.

8.2. Soporte de extensiones UNIX

Samba utiliza el bit de capacidad CAP_UNIX en el protocolo SMB para proporcionar la función de extensiones UNIX. Estas extensiones también son soportadas por el módulo del kernel cifs.ko. Sin embargo, tanto Samba como el módulo del kernel soportan las extensiones UNIX sólo en el protocolo SMB 1.

Para utilizar las extensiones UNIX:

  1. Ajuste el parámetro server min protocol en la sección [global] del archivo /etc/samba/smb.conf a NT1.

  2. Monte el recurso compartido utilizando el protocolo SMB 1 proporcionando la opción -o vers=1.0 al comando mount. Por ejemplo: 

    # mount -t cifs -o vers=1.0,username=user_name //server_name/share_name /mnt/
    Copy to Clipboard

    Por defecto, el módulo del kernel utiliza el protocolo SMB 2 o la versión posterior más alta soportada por el servidor. Al pasar la opción -o vers=1.0 al comando mount se fuerza que el módulo del kernel use el protocolo SMB 1 que se requiere para usar las extensiones de UNIX.

Para verificar si las extensiones UNIX están habilitadas, muestre las opciones del recurso compartido montado: 

# mount
...
//server/share on /mnt type cifs (...,unix,...)
Copy to Clipboard

Si la entrada unix aparece en la lista de opciones de montaje, las extensiones UNIX están activadas.

8.3. Montaje manual de un recurso compartido SMB

Si sólo necesita montar temporalmente un recurso compartido SMB, puede montarlo manualmente utilizando la utilidad mount.

Nota

Los recursos compartidos montados manualmente no se vuelven a montar automáticamente cuando se reinicia el sistema. Para configurar que Red Hat Enterprise Linux monte automáticamente el recurso compartido cuando el sistema arranque, consulte Sección 8.4, “Montar un recurso compartido SMB automáticamente al arrancar el sistema”.

Requisitos previos

  • El paquete cifs-utils está instalado.

Procedimiento

Para montar manualmente un recurso compartido SMB, utilice la utilidad mount con el parámetro -t cifs: 

# mount -t cifs -o username=user_name //server_name/share_name /mnt/
Password for user_name@//server_name/share_name:  password
Copy to Clipboard

En el parámetro -o, puede especificar las opciones que se utilizan para montar el recurso compartido. Para más detalles, consulte Sección 8.7, “Opciones de montaje de uso frecuente” y la sección OPTIONS en la página de manual mount.cifs(8).

Ejemplo 8.1. Montaje de un recurso compartido mediante una conexión SMB 3.0 cifrada

To mount the \\server\example\ share as the DOMAIN\Administrator user over an encrypted SMB 3.0 connection into the /mnt/ directory: 

# mount -t cifs -o username=DOMAIN\Administrator,seal,vers=3.0 //server/example /mnt/
Password for DOMAIN\Administrator@//server_name/share_name:  password
Copy to Clipboard

8.4. Montar un recurso compartido SMB automáticamente al arrancar el sistema

Si el acceso a un recurso compartido SMB montado es necesario permanentemente en un servidor, monte el recurso compartido automáticamente en el momento del arranque.

Requisitos previos

  • El paquete cifs-utils está instalado.

Procedimiento

Para montar un recurso compartido SMB automáticamente cuando el sistema arranca, añada una entrada para el recurso compartido en el archivo /etc/fstab. Por ejemplo: 

//server_name/share_name  /mnt  cifs  credentials=/root/smb.cred  0 0
Copy to Clipboard
Importante

Para que el sistema pueda montar un recurso compartido automáticamente, debe almacenar el nombre de usuario, la contraseña y el nombre de dominio en un archivo de credenciales. Para más detalles, consulte Sección 8.5, “Autenticación en un recurso compartido SMB mediante un archivo de credenciales”.

En el cuarto campo de la fila de /etc/fstab, especifique las opciones de montaje, como la ruta del archivo de credenciales. Para más detalles, consulte Sección 8.7, “Opciones de montaje de uso frecuente” y la sección OPTIONS en la página de manual mount.cifs(8).

Para verificar que el recurso compartido se monta con éxito, introduzca: 

# mount /mnt/
Copy to Clipboard

8.5. Autenticación en un recurso compartido SMB mediante un archivo de credenciales

En ciertas situaciones, como cuando se monta un recurso compartido automáticamente en el momento del arranque, se debe montar un recurso compartido sin introducir el nombre de usuario y la contraseña. Para implementar esto, cree un archivo de credenciales.

Requisitos previos

  • El paquete cifs-utils está instalado.

Procedimiento

  1. Cree un archivo, como /root/smb.cred, y especifique el nombre de usuario, la contraseña y el nombre de dominio de ese archivo: 

    username=user_name
password=password
domain=domain_name
    Copy to Clipboard

  2. Establezca los permisos para que sólo el propietario pueda acceder al archivo: 

    # chown user_name /root/smb.cred
# chmod 600 /root/smb.cred
    Copy to Clipboard

Ahora puede pasar la opción credentials=file_name a la utilidad mount o utilizarla en el archivo /etc/fstab para montar el recurso compartido sin que se le pida el nombre de usuario y la contraseña.

8.6. Realización de un montaje SMB multiusuario

Las credenciales que proporcione para montar un recurso compartido determinan los permisos de acceso en el punto de montaje por defecto. Por ejemplo, si utiliza el usuario DOMAIN\example cuando monta un recurso compartido, todas las operaciones en el recurso compartido se ejecutarán como este usuario, independientemente del usuario local que realice la operación.

Sin embargo, en ciertas situaciones, el administrador quiere montar un recurso compartido automáticamente cuando el sistema arranca, pero los usuarios deben realizar acciones en el contenido del recurso compartido utilizando sus propias credenciales. Las opciones de montaje de multiuser permiten configurar este escenario.

Importante

Para utilizar la opción de montaje multiuser, debe establecer adicionalmente la opción de montaje sec en un tipo de seguridad que admita el suministro de credenciales de forma no interactiva, como krb5 o la opción ntlmssp con un archivo de credenciales. Para más detalles, consulte Sección 8.6.3, “Acceder a un recurso compartido como usuario”.

El usuario root monta el recurso compartido utilizando la opción multiuser y una cuenta que tiene un acceso mínimo al contenido del recurso compartido. Los usuarios normales pueden entonces proporcionar su nombre de usuario y contraseña al llavero del kernel de la sesión actual utilizando la utilidad cifscreds. Si el usuario accede al contenido del recurso compartido montado, el kernel utiliza las credenciales del llavero del kernel en lugar de las utilizadas inicialmente para montar el recurso compartido.

El uso de esta función consiste en los siguientes pasos:

Requisitos previos

  • El paquete cifs-utils está instalado.

8.6.1. Montar un recurso compartido con la opción multiusuario

Antes de que los usuarios puedan acceder al recurso compartido con sus propias credenciales, monte el recurso compartido como el usuario root utilizando una cuenta con permisos limitados.

Procedimiento

Para montar un recurso compartido automáticamente con la opción multiuser cuando el sistema arranca:

  1. Cree la entrada para el recurso compartido en el archivo /etc/fstab. Por ejemplo: 

    //server_name/share_name  /mnt  cifs  multiuser,sec=ntlmssp,credentials=/root/smb.cred  0 0
    Copy to Clipboard

  2. Monta la acción: 

    # mount /mnt/
    Copy to Clipboard

Si no desea montar el recurso compartido automáticamente cuando el sistema se inicie, móntelo manualmente pasando -o multiuser,sec=security_type al comando mount. Para obtener detalles sobre cómo montar un recurso compartido SMB manualmente, consulte Sección 8.3, “Montaje manual de un recurso compartido SMB”.

8.6.2. Verificar si un recurso compartido SMB está montado con la opción multiusuario

Para verificar si un recurso compartido está montado con la opción multiuser, muestre las opciones de montaje.

Procedimiento

# mount
...
//server_name/share_name on /mnt type cifs (sec=ntlmssp,multiuser,...)
Copy to Clipboard

Si la entrada multiuser aparece en la lista de opciones de montaje, la función está activada.

8.6.3. Acceder a un recurso compartido como usuario

Si se monta un recurso compartido SMB con la opción multiuser, los usuarios pueden proporcionar sus credenciales para el servidor al llavero del núcleo: 

# cifscreds add -u SMB_user_name server_name
Password: password
Copy to Clipboard

Cuando el usuario realiza operaciones en el directorio que contiene el recurso compartido SMB montado, el servidor aplica los permisos del sistema de archivos para este usuario, en lugar del utilizado inicialmente cuando se montó el recurso compartido.

Nota

Varios usuarios pueden realizar operaciones utilizando sus propias credenciales en el recurso compartido montado al mismo tiempo.

8.7. Opciones de montaje de uso frecuente

Cuando se monta un recurso compartido SMB, las opciones de montaje determinan:

  • Cómo se establecerá la conexión con el servidor. Por ejemplo, qué versión del protocolo SMB se utiliza cuando se conecta al servidor.
  • Cómo se montará el recurso compartido en el sistema de archivos local. Por ejemplo, si el sistema anula los permisos de archivos y directorios remotos para permitir que varios usuarios locales accedan al contenido del servidor.

Para establecer varias opciones en el cuarto campo del archivo /etc/fstab o en el parámetro -o de un comando de montaje, sepárelas con comas. Por ejemplo, véase Sección 8.6.1, “Montar un recurso compartido con la opción multiusuario”.

La siguiente lista ofrece las opciones de montaje más utilizadas:

OpciónDescripción

credenciales=file_name

Establece la ruta del archivo de credenciales. Véase Sección 8.5, “Autenticación en un recurso compartido SMB mediante un archivo de credenciales”

dir_mode=mode

Establece el modo de directorio si el servidor no soporta las extensiones CIFS UNIX.

file_mode=mode

Establece el modo de archivo si el servidor no soporta las extensiones CIFS UNIX.

contraseña=password

Establece la contraseña utilizada para autenticarse en el servidor SMB. Alternativamente, especifica un archivo de credenciales utilizando la opción credentials.

sello

Activa el soporte de encriptación para las conexiones que utilizan SMB 3.0 o una versión posterior del protocolo. Por lo tanto, utilice seal junto con la opción de montaje vers establecida en 3.0 o posterior. Véase Ejemplo 8.1, “Montaje de un recurso compartido mediante una conexión SMB 3.0 cifrada”.

sec=security_mode

Establece el modo de seguridad, como ntlmsspi, para habilitar el hash de contraseñas NTLMv2 y la firma de paquetes habilitada. Para obtener una lista de los valores admitidos, consulte la descripción de la opción en la página de manual mount.cifs(8).

Si el servidor no admite el modo de seguridad ntlmv2, utilice sec=ntlmssp, que es el predeterminado.

Por razones de seguridad, no utilice el modo de seguridad inseguro ntlm.

nombre de usuario=user_name

Establece el nombre de usuario utilizado para autenticarse en el servidor SMB. Alternativamente, especifica un archivo de credenciales utilizando la opción credentials.

vers=SMB_protocol_version

Establece la versión del protocolo SMB utilizada para la comunicación con el servidor.

Para obtener una lista completa, consulte la sección OPTIONS en la página de manual mount.cifs(8).

Capítulo 9. Visión general de los atributos de nomenclatura persistente

Como administrador del sistema, usted necesita referirse a los volúmenes de almacenamiento utilizando atributos de nomenclatura persistentes para construir configuraciones de almacenamiento que sean confiables a través de múltiples arranques del sistema.

9.1. Desventajas de los atributos de denominación no persistentes

Red Hat Enterprise Linux proporciona varias formas de identificar los dispositivos de almacenamiento. Es importante utilizar la opción correcta para identificar cada dispositivo cuando se utiliza para evitar acceder inadvertidamente al dispositivo equivocado, particularmente cuando se instalan o reformatean unidades.

Tradicionalmente, los nombres no persistentes en forma de /dev/sd(major number)(minor number) se utilizan en Linux para referirse a los dispositivos de almacenamiento. El rango de números mayores y menores y los nombres sd asociados se asignan a cada dispositivo cuando se detecta. Esto significa que la asociación entre el rango de números mayores y menores y los nombres sd asociados puede cambiar si el orden de detección del dispositivo cambia.

Este cambio en el ordenamiento podría ocurrir en las siguientes situaciones:

  • La paralelización del proceso de arranque del sistema detecta los dispositivos de almacenamiento en un orden diferente con cada arranque del sistema.
  • Un disco no se enciende o no responde a la controladora SCSI. Esto hace que no sea detectado por la sonda normal de dispositivos. El disco no es accesible para el sistema y los dispositivos subsiguientes tendrán su rango de números mayores y menores, incluyendo los nombres asociados sd desplazados hacia abajo. Por ejemplo, si un disco normalmente referido como sdb no es detectado, un disco normalmente referido como sdc aparecerá como sdb.
  • Un controlador SCSI (adaptador de bus de host, o HBA) no se inicializa, lo que provoca que no se detecten todos los discos conectados a ese HBA. A todos los discos conectados a los HBA comprobados posteriormente se les asignan diferentes rangos de números mayores y menores, y diferentes nombres asociados sd.
  • El orden de inicialización del controlador cambia si hay diferentes tipos de HBA en el sistema. Esto hace que los discos conectados a esos HBAs sean detectados en un orden diferente. Esto también puede ocurrir si los HBA se mueven a diferentes ranuras PCI en el sistema.
  • Los discos conectados al sistema con adaptadores de canal de fibra, iSCSI o FCoE pueden ser inaccesibles en el momento en que se comprueban los dispositivos de almacenamiento, debido a que una matriz de almacenamiento o un interruptor intermedio están apagados, por ejemplo. Esto puede ocurrir cuando un sistema se reinicia después de un fallo de alimentación, si la matriz de almacenamiento tarda más en ponerse en línea que el sistema en arrancar. Aunque algunos controladores de Canal de Fibra soportan un mecanismo para especificar un mapeo persistente de SCSI target ID a WWPN, esto no hace que se reserven los rangos de números mayores y menores, y los nombres asociados sd; sólo proporciona números SCSI target ID consistentes.

Estas razones hacen que no sea deseable utilizar el rango de números mayores y menores o los nombres asociados de sd al referirse a los dispositivos, como en el archivo /etc/fstab. Existe la posibilidad de que se monte el dispositivo incorrecto y se produzca una corrupción de datos.

Ocasionalmente, sin embargo, sigue siendo necesario referirse a los nombres de sd incluso cuando se utiliza otro mecanismo, como cuando se informan errores de un dispositivo. Esto se debe a que el núcleo de Linux utiliza los nombres de sd (y también las tuplas SCSI host/channel/target/LUN) en los mensajes del núcleo relativos al dispositivo.

9.2. Sistema de archivos e identificadores de dispositivos

Esta sección explica la diferencia entre los atributos persistentes que identifican los sistemas de archivos y los dispositivos de bloque.

Identificadores del sistema de archivos

Los identificadores del sistema de archivos están vinculados a un sistema de archivos concreto creado en un dispositivo de bloques. El identificador también se almacena como parte del sistema de archivos. Si copias el sistema de archivos a un dispositivo diferente, sigue llevando el mismo identificador del sistema de archivos. Por otro lado, si reescribes el dispositivo, por ejemplo, formateándolo con la utilidad mkfs, el dispositivo pierde el atributo.

Los identificadores del sistema de archivos son:

  • Identificador único (UUID)
  • Etiqueta
Identificadores de dispositivos

Los identificadores de dispositivo están vinculados a un dispositivo de bloque: por ejemplo, un disco o una partición. Si se reescribe el dispositivo, por ejemplo, formateándolo con la utilidad mkfs, el dispositivo mantiene el atributo, porque no se almacena en el sistema de archivos.

Los identificadores de los dispositivos son:

  • Identificador mundial (WWID)
  • UUID de la partición
  • Número de serie
Recomendaciones
  • Algunos sistemas de archivos, como los volúmenes lógicos, abarcan varios dispositivos. Red Hat recomienda acceder a estos sistemas de archivos utilizando identificadores de sistemas de archivos en lugar de identificadores de dispositivos.

9.3. Nombres de dispositivos gestionados por el mecanismo udev en /dev/disk/

Esta sección enumera los diferentes tipos de atributos de nomenclatura persistente que el servicio udev proporciona en el directorio /dev/disk/.

El mecanismo udev se utiliza para todo tipo de dispositivos en Linux, no sólo para los dispositivos de almacenamiento. En el caso de los dispositivos de almacenamiento, Red Hat Enterprise Linux contiene reglas udev que crean enlaces simbólicos en el directorio /dev/disk/. Esto le permite referirse a los dispositivos de almacenamiento por:

  • Su contenido
  • Un identificador único
  • Su número de serie.

Aunque los atributos de nomenclatura de udev son persistentes, en el sentido de que no cambian por sí solos en los reinicios del sistema, algunos también son configurables.

9.3.1. Identificadores del sistema de archivos

El atributo UUID en /dev/disk/by-uuid/

Las entradas de este directorio proporcionan un nombre simbólico que hace referencia al dispositivo de almacenamiento mediante un unique identifier (UUID) en el contenido (es decir, los datos) almacenado en el dispositivo. Por ejemplo: 

/dev/disco/por-uuid/3e6be9de-8139-11d1-9106-a43f08d823a6
Copy to Clipboard

Puede utilizar el UUID para referirse al dispositivo en el archivo /etc/fstab utilizando la siguiente sintaxis: 

UUID=3e6be9de-8139-11d1-9106-a43f08d823a6
Copy to Clipboard

Puedes configurar el atributo UUID al crear un sistema de archivos, y también puedes cambiarlo posteriormente.

El atributo Label en /dev/disk/by-label/

Las entradas de este directorio proporcionan un nombre simbólico que hace referencia al dispositivo de almacenamiento mediante un label en el contenido (es decir, los datos) almacenado en el dispositivo.

Por ejemplo: 

/dev/disco/por-etiqueta/Boot
Copy to Clipboard

Puede utilizar la etiqueta para referirse al dispositivo en el archivo /etc/fstab utilizando la siguiente sintaxis: 

ETIQUETA=Boot
Copy to Clipboard

Puede configurar el atributo Etiqueta al crear un sistema de archivos, y también puede modificarlo posteriormente.

9.3.2. Identificadores de dispositivos

El atributo WWID en /dev/disk/by-id/

El World Wide Identifier (WWID) es un identificador persistente, system-independent identifier, que el estándar SCSI exige a todos los dispositivos SCSI. Se garantiza que el identificador WWID es único para cada dispositivo de almacenamiento, e independiente de la ruta que se utilice para acceder al dispositivo. El identificador es una propiedad del dispositivo, pero no se almacena en el contenido (es decir, los datos) de los dispositivos.

Este identificador puede obtenerse emitiendo una consulta SCSI para recuperar los datos vitales del producto de identificación del dispositivo (página 0x83) o el número de serie de la unidad (página 0x80).

Red Hat Enterprise Linux mantiene automáticamente el mapeo apropiado del nombre del dispositivo basado en WWID a un nombre actual de /dev/sd en ese sistema. Las aplicaciones pueden usar el nombre /dev/disk/by-id/ para referenciar los datos en el disco, incluso si la ruta al dispositivo cambia, e incluso cuando se accede al dispositivo desde diferentes sistemas.

Ejemplo 9.1. Asignaciones WWID

Enlace simbólico WWIDDispositivo no persistenteNota

/dev/disk/by-id/scsi-3600508b400105e210000900000490000

/dev/sda

Un dispositivo con un identificador de página 0x83

/dev/disk/by-id/scsi-SSEAGATE_ST373453LW_3HW1RHM6

/dev/sdb

Un dispositivo con un identificador de página 0x80

/dev/disk/by-id/ata-SAMSUNG_MZNLN256HMHQ-000L7_S2WDNX0J336519-part3

/dev/sdc3

Una partición de disco

Además de estos nombres persistentes proporcionados por el sistema, también puede utilizar las reglas de udev para implementar nombres persistentes propios, asignados al WWID del almacenamiento.

El atributo UUID de la partición en /dev/disk/by-partuuid

El atributo UUID de la partición (PARTUUID) identifica las particiones tal y como se definen en la tabla de particiones GPT.

Ejemplo 9.2. Asignaciones de UUID de partición

PARTUUID symlinkDispositivo no persistente

/dev/disk/by-partuuid/4cd1448a-01

/dev/sda1

/dev/disk/by-partuuid/4cd1448a-02

/dev/sda2

/dev/disk/by-partuuid/4cd1448a-03

/dev/sda3

El atributo Path en /dev/disk/by-path/

Este atributo proporciona un nombre simbólico que hace referencia al dispositivo de almacenamiento mediante la dirección hardware path utilizada para acceder al dispositivo.

El atributo Path falla si cualquier parte de la ruta de hardware (por ejemplo, el ID PCI, el puerto de destino o el número LUN) cambia. Por lo tanto, el atributo Path no es fiable. Sin embargo, el atributo Path puede ser útil en uno de los siguientes escenarios:

  • Es necesario identificar un disco que se piensa sustituir más adelante.
  • Usted planea instalar un servicio de almacenamiento en un disco en una ubicación específica.

9.4. El identificador mundial con DM Multipath

Esta sección describe el mapeo entre el World Wide Identifier (WWID) y los nombres de dispositivos no persistentes en una configuración de Device Mapper Multipath.

Si hay varias rutas desde un sistema a un dispositivo, DM Multipath utiliza el WWID para detectarlo. DM Multipath presenta entonces un único "pseudo-dispositivo" en el directorio /dev/mapper/wwid, como /dev/mapper/3600508b400105df70000e00000ac0000.

El comando multipath -l muestra la asignación a los identificadores no persistentes:

  • Host:Channel:Target:LUN
  • /dev/sd nombre
  • major:minor número

Ejemplo 9.3. Asignaciones WWID en una configuración multirruta

Un ejemplo de salida del comando multipath -l: 

3600508b400105df70000e00000ac0000 dm-2 vendor,product
[size=20G][features=1 queue_if_no_path][hwhandler=0][rw]
\_ round-robin 0 [prio=0][active]
 \_ 5:0:1:1 sdc 8:32  [active][undef]
 \_ 6:0:1:1 sdg 8:96  [active][undef]
\_ round-robin 0 [prio=0][enabled]
 \_ 5:0:0:1 sdb 8:16  [active][undef]
 \_ 6:0:0:1 sdf 8:80  [active][undef]
Copy to Clipboard

DM Multipath mantiene automáticamente la asignación adecuada de cada nombre de dispositivo basado en WWID a su correspondiente nombre /dev/sd en el sistema. Estos nombres son persistentes a través de los cambios de ruta, y son consistentes cuando se accede al dispositivo desde diferentes sistemas.

Cuando se utiliza la función user_friendly_names de DM Multipath, el WWID se asigna a un nombre de la forma /dev/mapper/mpathN. Por defecto, esta asignación se mantiene en el archivo /etc/multipath/bindings. Estos nombres de mpathN nombres son persistentes mientras se mantenga ese archivo.

Importante

Si se utiliza user_friendly_names, se requieren pasos adicionales para obtener nombres consistentes en un clúster.

9.5. Limitaciones de la convención de nombres de dispositivos udev

Las siguientes son algunas limitaciones de la convención de nombres udev:

  • Es posible que el dispositivo no esté accesible en el momento en que se realiza la consulta porque el mecanismo de udev puede depender de la capacidad de consultar el dispositivo de almacenamiento cuando se procesan las reglas de udev para un evento de udev. Esto es más probable que ocurra con los dispositivos de almacenamiento Fibre Channel, iSCSI o FCoE cuando el dispositivo no se encuentra en el chasis del servidor.
  • El kernel puede enviar eventos udev en cualquier momento, haciendo que las reglas sean procesadas y posiblemente haciendo que los enlaces /dev/disk/by-*/ sean eliminados si el dispositivo no es accesible.
  • Puede haber un retraso entre el momento en que se genera el evento udev y el momento en que se procesa, como cuando se detecta un gran número de dispositivos y el servicio udevd del espacio de usuario tarda cierto tiempo en procesar las reglas de cada uno. Esto puede causar un retraso entre el momento en que el kernel detecta el dispositivo y cuando los nombres de /dev/disk/by-*/ están disponibles.
  • Los programas externos como blkid invocados por las reglas podrían abrir el dispositivo durante un breve período de tiempo, haciendo que el dispositivo sea inaccesible para otros usos.
  • Los nombres de los dispositivos gestionados por el mecanismo udev en /dev/disk/ pueden cambiar entre las principales versiones, lo que obliga a actualizar los enlaces.

9.6. Listado de atributos de nomenclatura persistente

Este procedimiento describe cómo averiguar los atributos de nomenclatura persistente de los dispositivos de almacenamiento no persistentes.

Procedimiento

  • Para listar los atributos UUID y Label, utilice la utilidad lsblk: 

    $ lsblk --fs storage-device
    Copy to Clipboard

    Por ejemplo:

    Ejemplo 9.4. Ver el UUID y la etiqueta de un sistema de archivos

    $ lsblk --fs /dev/sda1

NAME FSTYPE LABEL UUID                                 MOUNTPOINT
sda1 xfs    Boot  afa5d5e3-9050-48c3-acc1-bb30095f3dc4 /boot
    Copy to Clipboard

  • Para listar el atributo PARTUUID, utilice la utilidad lsblk con la opción --output PARTUUID: 

    $ lsblk --output PARTUUID
    Copy to Clipboard

    Por ejemplo:

    Ejemplo 9.5. Ver el atributo PARTUUID de una partición

    $ lsblk --output +PARTUUID /dev/sda1

NAME MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT PARTUUID
sda1   8:1    0  512M  0 part /boot      4cd1448a-01
    Copy to Clipboard

  • Para listar el atributo WWID, examine los objetivos de los enlaces simbólicos en el directorio /dev/disk/by-id/. Por ejemplo:

    Ejemplo 9.6. Ver el WWID de todos los dispositivos de almacenamiento del sistema

    $ file /dev/disk/by-id/*

/dev/disk/by-id/ata-QEMU_HARDDISK_QM00001
symbolic link to ../../sda
/dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part1
symbolic link to ../../sda1
/dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part2
symbolic link to ../../sda2
/dev/disk/by-id/dm-name-rhel_rhel8-root
symbolic link to ../../dm-0
/dev/disk/by-id/dm-name-rhel_rhel8-swap
symbolic link to ../../dm-1
/dev/disk/by-id/dm-uuid-LVM-QIWtEHtXGobe5bewlIUDivKOz5ofkgFhP0RMFsNyySVihqEl2cWWbR7MjXJolD6g
symbolic link to ../../dm-1
/dev/disk/by-id/dm-uuid-LVM-QIWtEHtXGobe5bewlIUDivKOz5ofkgFhXqH2M45hD2H9nAf2qfWSrlRLhzfMyOKd
symbolic link to ../../dm-0
/dev/disk/by-id/lvm-pv-uuid-atlr2Y-vuMo-ueoH-CpMG-4JuH-AhEF-wu4QQm
symbolic link to ../../sda2
    Copy to Clipboard

9.7. Modificación de los atributos de nomenclatura persistente

Este procedimiento describe cómo cambiar el atributo de nomenclatura persistente UUID o Label de un sistema de archivos.

Nota

El cambio de los atributos de udev se produce en segundo plano y puede llevar mucho tiempo. El comando udevadm settle espera hasta que el cambio esté completamente registrado, lo que garantiza que su siguiente comando podrá utilizar el nuevo atributo correctamente.

En los siguientes comandos:

  • Sustituya new-uuid por el UUID que quieras establecer; por ejemplo, 1cdfbc07-1c90-4984-b5ec-f61943f5ea50. Puedes generar un UUID utilizando el comando uuidgen.
  • Sustituya new-label por una etiqueta; por ejemplo, backup_data.

Requisitos previos

  • Si va a modificar los atributos de un sistema de archivos XFS, desmóntelo primero.

Procedimiento

  • Para cambiar los atributos UUID o Label de un sistema de archivos XFS, utilice la utilidad xfs_admin: 

    # xfs_admin -U new-uuid -L new-label storage-device
# udevadm settle
    Copy to Clipboard

  • Para cambiar los atributos UUID o Label de un sistema de archivos ext4, ext3, o ext2, utilice la utilidad tune2fs: 

    # tune2fs -U new-uuid -L new-label storage-device
# udevadm settle
    Copy to Clipboard

  • Para cambiar el UUID o los atributos de la etiqueta de un volumen de intercambio, utilice la utilidad swaplabel: 

    # swaplabel --uuid new-uuid --label new-label swap-device
# udevadm settle
    Copy to Clipboard

Capítulo 10. Cómo empezar con las particiones

Como administrador del sistema, puede utilizar los siguientes procedimientos para crear, eliminar y modificar varios tipos de particiones de disco.

Para obtener una visión general de las ventajas y desventajas de utilizar particiones en dispositivos de bloque, consulte el siguiente artículo de KBase: https://access.redhat.com/solutions/163853.

10.1. Visualización de la tabla de particiones

Como administrador del sistema, puede mostrar la tabla de particiones de un dispositivo de bloque para ver la disposición de las particiones y los detalles sobre las particiones individuales.

10.1.1. Visualización de la tabla de particiones con parted

Este procedimiento describe cómo ver la tabla de particiones en un dispositivo de bloque utilizando la utilidad parted.

Procedimiento

  1. Inicie el shell interactivo parted: 

    # parted block-device
    Copy to Clipboard
    • Sustituya block-device por la ruta del dispositivo que desea examinar: por ejemplo, /dev/sda.

  2. Ver la tabla de particiones: 

    Impresión (parcial)
    Copy to Clipboard

  3. Opcionalmente, utilice el siguiente comando para cambiar a otro dispositivo que desee examinar a continuación: 

    (separado) seleccionar block-device
    Copy to Clipboard

Recursos adicionales

  • La página de manual parted(8).

10.1.2. Ejemplo de salida de parted print

Esta sección proporciona un ejemplo de salida del comando print en el shell parted y describe los campos de la salida.

Ejemplo 10.1. Salida del comando print 

Model: ATA SAMSUNG MZNLN256 (scsi)
Disk /dev/sda: 256GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End     Size    Type      File system  Flags
 1      1049kB  269MB   268MB   primary   xfs          boot
 2      269MB   34.6GB  34.4GB  primary
 3      34.6GB  45.4GB  10.7GB  primary
 4      45.4GB  256GB   211GB   extended
 5      45.4GB  256GB   211GB   logical
Copy to Clipboard

A continuación se describen los campos:

Model: ATA SAMSUNG MZNLN256 (scsi)
El tipo de disco, el fabricante, el número de modelo y la interfaz.
Disk /dev/sda: 256GB
La ruta del archivo al dispositivo de bloque y la capacidad de almacenamiento.
Partition Table: msdos
El tipo de etiqueta del disco.
Number
El número de la partición. Por ejemplo, la partición con número menor 1 corresponde a /dev/sda1.
Start y End
La ubicación en el dispositivo donde comienza y termina la partición.
Type
Los tipos válidos son metadatos, libre, primario, extendido o lógico.
File system
El tipo de sistema de archivos. Si el campo File system de un dispositivo no muestra ningún valor, significa que su tipo de sistema de archivos es desconocido. La utilidad parted no puede reconocer el sistema de archivos de los dispositivos cifrados.
Flags
Enumera las banderas establecidas para la partición. Las banderas disponibles son boot, root, swap, hidden, raid, lvm, o lba.

10.2. Creación de una tabla de particiones en un disco

Como administrador del sistema, puede formatear un dispositivo de bloque con diferentes tipos de tablas de partición para permitir el uso de particiones en el dispositivo.

Aviso

Al formatear un dispositivo de bloque con una tabla de particiones se borran todos los datos almacenados en el dispositivo.

10.2.1. Consideraciones antes de modificar las particiones de un disco

Esta sección enumera los puntos clave a tener en cuenta antes de crear, eliminar o redimensionar las particiones.

Nota

Esta sección no cubre la tabla de particiones DASD, que es específica de la arquitectura IBM Z. Para obtener información sobre DASD, consulte:

El número máximo de particiones

El número de particiones en un dispositivo está limitado por el tipo de tabla de particiones:

  • En un dispositivo formateado con la tabla de particiones Master Boot Record (MBR), puede tener cualquiera de los dos:

    • Hasta cuatro particiones primarias, o
    • Hasta tres particiones primarias, una partición extendida y múltiples particiones lógicas dentro de la extendida.
  • En un dispositivo formateado con el GUID Partition Table (GPT), el número máximo de particiones es 128. Aunque la especificación GPT permite más particiones aumentando el área reservada para la tabla de particiones, la práctica común utilizada por la utilidad parted es limitarla a un área suficiente para 128 particiones.
Nota

Red Hat recomienda que, a menos que tenga una razón para hacer lo contrario, debería at least crear las siguientes particiones: swap, /boot/, y / (raíz).

El tamaño máximo de una partición

El tamaño de una partición en un dispositivo está limitado por el tipo de tabla de particiones:

  • En un dispositivo formateado con la tabla de particiones Master Boot Record (MBR), el tamaño máximo es de 2TiB.
  • En un dispositivo formateado con el GUID Partition Table (GPT), el tamaño máximo es de 8ZiB.

Si quieres crear una partición mayor de 2TiB, el disco debe estar formateado con GPT.

Alineación de tamaños

La utilidad parted le permite especificar el tamaño de la partición utilizando varios sufijos diferentes:

MiB, GiB o TiB

Tamaño expresado en potencias de 2.

  • El punto inicial de la partición se alinea con el sector exacto especificado por el tamaño.
  • El punto final se alinea con el tamaño especificado menos 1 sector.
MB, GB o TB

Tamaño expresado en potencias de 10.

El punto inicial y final se alinea dentro de la mitad de la unidad especificada: por ejemplo, ±500KB cuando se utiliza el sufijo MB.

10.2.2. Comparación de los tipos de tablas de partición

Esta sección compara las propiedades de los diferentes tipos de tablas de partición que se pueden crear en un dispositivo de bloque.

Tabla 10.1. Tipos de tablas de partición
Tabla de particiónNúmero máximo de particionesTamaño máximo de la partición

Registro de arranque maestro (MBR)

4 primarios, o 3 primarios y 12 lógicos dentro de una partición extendida

2TiB

Tabla de partición GUID (GPT)

128

8ZiB

10.2.3. Particiones de disco MBR

Los diagramas de este capítulo muestran que la tabla de particiones está separada del disco real. Sin embargo, esto no es del todo exacto. En realidad, la tabla de particiones se almacena al principio del disco, antes de cualquier sistema de archivos o datos de usuario, pero para mayor claridad, están separados en los siguientes diagramas.

Figura 10.1. Disco con tabla de partición MBR

Como muestra el diagrama anterior, la tabla de particiones se divide en cuatro secciones de cuatro particiones primarias. Una partición primaria es una partición en un disco duro que sólo puede contener una unidad lógica (o sección). Cada sección puede contener la información necesaria para definir una sola partición, lo que significa que la tabla de particiones no puede definir más de cuatro particiones.

Cada entrada de la tabla de particiones contiene varias características importantes de la partición:

  • Los puntos del disco donde comienza y termina la partición.
  • Si la partición es active. Sólo se puede marcar una partición como active.
  • El tipo de partición.

Los puntos inicial y final definen el tamaño de la partición y su ubicación en el disco. El indicador "activo" es utilizado por los cargadores de arranque de algunos sistemas operativos. En otras palabras, el sistema operativo en la partición que está marcada como "activa" es arrancado, en este caso.

El tipo es un número que identifica el uso previsto de la partición. Algunos sistemas operativos utilizan el tipo de partición para denotar un tipo de sistema de archivos específico, para marcar la partición como asociada a un sistema operativo concreto, para indicar que la partición contiene un sistema operativo de arranque, o alguna combinación de las tres.

El siguiente diagrama muestra un ejemplo de una unidad con una sola partición:

Figura 10.2. Disco con una sola partición

La única partición en este ejemplo está etiquetada como DOS. Esta etiqueta muestra el tipo de partición, siendo DOS una de las más comunes.

10.2.4. Particiones MBR extendidas

En caso de que cuatro particiones sean insuficientes para sus necesidades, puede utilizar las particiones extendidas para crear particiones adicionales. Puede hacerlo configurando el tipo de partición como "Extendida".

Una partición extendida es como una unidad de disco en sí misma - tiene su propia tabla de particiones, que apunta a una o más particiones (ahora llamadas particiones lógicas, en contraposición a las cuatro particiones primarias), contenidas completamente dentro de la propia partición extendida. El siguiente diagrama muestra una unidad de disco con una partición primaria y una partición extendida que contiene dos particiones lógicas (junto con algo de espacio libre sin particionar):

Figura 10.3. Disco con una partición MBR primaria y otra extendida

Como esta figura implica, hay una diferencia entre las particiones primarias y las lógicas - sólo puede haber hasta cuatro particiones primarias y extendidas, pero no hay un límite fijo para el número de particiones lógicas que pueden existir. Sin embargo, debido a la forma en que se accede a las particiones en Linux, no se pueden definir más de 15 particiones lógicas en una sola unidad de disco.

10.2.5. Tipos de partición MBR

La siguiente tabla muestra una lista de algunos de los tipos de partición MBR más utilizados y los números hexadecimales utilizados para representarlos.

Tabla 10.2. Tipos de partición MBR

MBR partition type

Value

MBR partition type

Value

Vacío

00

Novell Netware 386

65

DOS 12-bit FAT

01

PIC/IX

75

Raíz de XENIX

O2

Antiguo MINIX

80

XENIX usr

O3

Linux/MINUX

81

DOS 16 bits ⇐32M

04

Intercambio en Linux

82

Extendido

05

Linux nativo

83

DOS 16 bits >=32

06

Linux ampliado

85

OS/2 HPFS

07

Amoeba

93

AIX

08

Amoeba BBT

94

AIX de arranque

09

BSD/386

a5

Gestor de arranque de OS/2

0a

OpenBSD

a6

Win95 FAT32

0b

NEXTSTEP

a7

Win95 FAT32 (LBA)

0c

BSDI fs

b7

Win95 FAT16 (LBA)

0e

Intercambio BSDI

b8

Win95 Extended (LBA)

0f

Syrinx

c7

Venix 80286

40

CP/M

db

Novell

51

Acceso al DOS

e1

Bota PRep

41

DOS R/O

e3

GNU HURD

63

DOS secundario

f2

Novell Netware 286

64

BBT

ff

10.2.6. Tabla de partición GUID

La tabla de partición GUID (GPT) es un esquema de partición basado en el uso de un identificador único global (GUID). La GPT se desarrolló para hacer frente a las limitaciones de la tabla de partición MBR, especialmente con el limitado espacio de almacenamiento máximo direccionable de un disco. A diferencia de MBR, que no puede direccionar un almacenamiento mayor de 2 TiB (equivalente a unos 2,2 TB), GPT se utiliza con discos duros de mayor tamaño; el tamaño máximo direccionable del disco es de 2,2 ZiB. Además, GPT, por defecto, permite crear hasta 128 particiones primarias. Este número puede ampliarse asignando más espacio a la tabla de particiones.

Nota

Una GPT tiene tipos de partición basados en GUIDs. Tenga en cuenta que ciertas particiones requieren un GUID específico. Por ejemplo, la partición del sistema para los cargadores de arranque EFI requiere el GUID C12A7328-F81F-11D2-BA4B-00A0C93EC93B.

Los discos GPT utilizan el direccionamiento lógico de bloques (LBA) y la disposición de las particiones es la siguiente:

  • Para mantener la compatibilidad con los discos MBR, el primer sector (LBA 0) de GPT está reservado para los datos de MBR y se llama "MBR protector".
  • La cabecera GPT primaria comienza en el segundo bloque lógico (LBA 1) del dispositivo. La cabecera contiene el GUID del disco, la ubicación de la tabla de particiones primaria, la ubicación de la cabecera GPT secundaria, y las sumas de comprobación CRC32 de sí misma y de la tabla de particiones primaria. También especifica el número de entradas de partición en la tabla.
  • La GPT primaria incluye, por defecto 128 entradas de partición, cada una con un tamaño de entrada de 128 bytes, su GUID de tipo de partición y su GUID de partición única.
  • La GPT secundaria es idéntica a la GPT primaria. Se utiliza principalmente como una tabla de respaldo para la recuperación en caso de que la tabla de partición primaria se corrompa.
  • La cabecera secundaria de GPT se encuentra en el último sector lógico del disco y puede utilizarse para recuperar la información de GPT en caso de que la cabecera primaria esté dañada. Contiene el GUID del disco, la ubicación de la tabla de particiones secundarias y la cabecera GPT primaria, las sumas de comprobación CRC32 de sí mismo y de la tabla de particiones secundarias, y el número de posibles entradas de partición.

Figura 10.4. Disco con una tabla de partición GUID

Importante

Debe haber una partición de arranque de la BIOS para que el gestor de arranque se instale con éxito en un disco que contenga una tabla de particiones GPT (GUID). Esto incluye los discos inicializados por Anaconda. Si el disco ya contiene una partición de arranque del BIOS, se puede reutilizar.

10.2.7. Creación de una tabla de particiones en un disco con partición

Este procedimiento describe cómo formatear un dispositivo de bloque con una tabla de particiones utilizando la utilidad parted.

Procedimiento

  1. Inicie el shell interactivo parted: 

    # parted block-device
    Copy to Clipboard
    • Sustituya block-device por la ruta del dispositivo en el que desea crear una tabla de particiones: por ejemplo, /dev/sda.

  2. Determine si ya existe una tabla de particiones en el dispositivo: 

    Impresión (parcial)
    Copy to Clipboard

    Si el dispositivo ya contiene particiones, se eliminarán en los siguientes pasos.

  3. Cree la nueva tabla de partición: 

    (parted) mklabel table-type
    Copy to Clipboard

    • Sustituya table-type por el tipo de tabla de partición deseado:

      • msdos para MBR
      • gpt para GPT

    Ejemplo 10.2. Creación de una tabla GPT

    Por ejemplo, para crear una tabla GPT en el disco, utilice: 

    (parted) mklabel gpt
    Copy to Clipboard

    Los cambios empiezan a producirse en cuanto se introduce este comando, así que revísalo antes de ejecutarlo.

  4. Ver la tabla de particiones para confirmar que la tabla de particiones existe: 

    Impresión (parcial)
    Copy to Clipboard

  5. Salga del shell parted: 

    (separada) dejar de fumar
    Copy to Clipboard

Recursos adicionales

  • La página de manual parted(8).

Próximos pasos

10.3. Crear una partición

Como administrador del sistema, puedes crear nuevas particiones en un disco.

10.3.1. Consideraciones antes de modificar las particiones de un disco

Esta sección enumera los puntos clave a tener en cuenta antes de crear, eliminar o redimensionar las particiones.

Nota

Esta sección no cubre la tabla de particiones DASD, que es específica de la arquitectura IBM Z. Para obtener información sobre DASD, consulte:

El número máximo de particiones

El número de particiones en un dispositivo está limitado por el tipo de tabla de particiones:

  • En un dispositivo formateado con la tabla de particiones Master Boot Record (MBR), puede tener cualquiera de los dos:

    • Hasta cuatro particiones primarias, o
    • Hasta tres particiones primarias, una partición extendida y múltiples particiones lógicas dentro de la extendida.
  • En un dispositivo formateado con el GUID Partition Table (GPT), el número máximo de particiones es 128. Aunque la especificación GPT permite más particiones aumentando el área reservada para la tabla de particiones, la práctica común utilizada por la utilidad parted es limitarla a un área suficiente para 128 particiones.
Nota

Red Hat recomienda que, a menos que tenga una razón para hacer lo contrario, debería at least crear las siguientes particiones: swap, /boot/, y / (raíz).

El tamaño máximo de una partición

El tamaño de una partición en un dispositivo está limitado por el tipo de tabla de particiones:

  • En un dispositivo formateado con la tabla de particiones Master Boot Record (MBR), el tamaño máximo es de 2TiB.
  • En un dispositivo formateado con el GUID Partition Table (GPT), el tamaño máximo es de 8ZiB.

Si quieres crear una partición mayor de 2TiB, el disco debe estar formateado con GPT.

Alineación de tamaños

La utilidad parted le permite especificar el tamaño de la partición utilizando varios sufijos diferentes:

MiB, GiB o TiB

Tamaño expresado en potencias de 2.

  • El punto inicial de la partición se alinea con el sector exacto especificado por el tamaño.
  • El punto final se alinea con el tamaño especificado menos 1 sector.
MB, GB o TB

Tamaño expresado en potencias de 10.

El punto inicial y final se alinea dentro de la mitad de la unidad especificada: por ejemplo, ±500KB cuando se utiliza el sufijo MB.

10.3.2. Tipos de partición

Esta sección describe diferentes atributos que especifican el tipo de una partición.

Tipos de partición o banderas

El tipo de partición, o bandera, es utilizado por un sistema en ejecución sólo en raras ocasiones. Sin embargo, el tipo de partición es importante para los generadores sobre la marcha, como systemd-gpt-auto-generator, que utilizan el tipo de partición para, por ejemplo, identificar y montar automáticamente los dispositivos.

  • La utilidad parted proporciona cierto control de los tipos de partición mediante la asignación del tipo de partición a flags. La utilidad parted sólo puede manejar ciertos tipos de partición: por ejemplo LVM, swap o RAID.
  • La utilidad fdisk admite toda la gama de tipos de partición especificando códigos hexadecimales.
Tipo de sistema de archivos de la partición

La utilidad parted acepta opcionalmente un argumento de tipo de sistema de archivos al crear una partición. El valor se utiliza para:

  • Establecer las banderas de la partición en MBR, o
  • Establezca el tipo de UUID de la partición en GPT. Por ejemplo, los tipos de sistema de archivos swap, fat, o hfs establecen diferentes GUIDs. El valor por defecto es el GUID de datos de Linux.

El argumento no modifica el sistema de archivos de la partición de ninguna manera. Sólo diferencia entre las banderas o GUIDs soportados.

Se admiten los siguientes tipos de sistemas de archivos:

  • xfs
  • ext2
  • ext3
  • ext4
  • fat16
  • fat32
  • hfs
  • hfs
  • linux-swap
  • ntfs
  • reiserfs

10.3.3. Esquema de nomenclatura de las particiones

Red Hat Enterprise Linux utiliza un esquema de nomenclatura basado en archivos, con nombres de archivos en forma de /dev/xxyN.

Los nombres de dispositivos y particiones tienen la siguiente estructura:

/dev/
Este es el nombre del directorio en el que se encuentran todos los archivos del dispositivo. Como las particiones se colocan en los discos duros, y los discos duros son dispositivos, los archivos que representan todas las posibles particiones se encuentran en /dev.
xx
Las dos primeras letras del nombre de las particiones indican el tipo de dispositivo en el que se encuentra la partición, normalmente sd.
y
Esta letra indica en qué dispositivo se encuentra la partición. Por ejemplo, /dev/sda para el primer disco duro, /dev/sdb para el segundo, y así sucesivamente. En sistemas con más de 26 discos, puede utilizar más letras. Por ejemplo, /dev/sdaa1.
N
La letra final indica el número que representa la partición. Las cuatro primeras particiones (primarias o extendidas) están numeradas de 1 a 4. Las particiones lógicas comienzan en 5. Por ejemplo, /dev/sda3 es la tercera partición primaria o extendida en el primer disco duro, y /dev/sdb6 es la segunda partición lógica en el segundo disco duro. La numeración de las particiones de la unidad sólo se aplica a las tablas de partición MBR. Tenga en cuenta que N no siempre significa partición.
Nota

Incluso si Red Hat Enterprise Linux puede identificar y referirse a all tipos de particiones de disco, podría no ser capaz de leer el sistema de archivos y por lo tanto acceder a los datos almacenados en cada tipo de partición. Sin embargo, en muchos casos, es posible acceder con éxito a los datos de una partición dedicada a otro sistema operativo.

10.3.4. Puntos de montaje y particiones de disco

En Red Hat Enterprise Linux, cada partición se utiliza para formar parte del almacenamiento necesario para soportar un único conjunto de archivos y directorios. Esto se hace utilizando el proceso conocido como mounting, que asocia una partición con un directorio. El montaje de una partición hace que su almacenamiento esté disponible a partir del directorio especificado, conocido como mount point.

Por ejemplo, si la partición /dev/sda5 está montada en /usr/, eso significaría que todos los archivos y directorios bajo /usr/ residen físicamente en /dev/sda5. Así, el archivo /usr/share/doc/FAQ/txt/Linux-FAQ se almacenaría en /dev/sda5, mientras que el archivo /etc/gdm/custom.conf no.

Continuando con el ejemplo, también es posible que uno o más directorios por debajo de /usr/ sean puntos de montaje para otras particiones. Por ejemplo, una partición /dev/sda7 podría ser montada en /usr/local, lo que significa que /usr/local/man/whatis residiría entonces en /dev/sda7 en lugar de /dev/sda5.

10.3.5. Creación de una partición con parted

Este procedimiento describe cómo crear una nueva partición en un dispositivo de bloque utilizando la utilidad parted.

Requisitos previos

Procedimiento

  1. Inicie el shell interactivo parted: 

    # parted block-device
    Copy to Clipboard
    • Sustituya block-device por la ruta del dispositivo en el que desea crear una partición: por ejemplo, /dev/sda.

  2. Vea la tabla de particiones actual para determinar si hay suficiente espacio libre: 

    Impresión (parcial)
    Copy to Clipboard
    • Si no hay suficiente espacio libre, puede redimensionar una partición existente. Para más información, consulte Sección 10.5, “Cambiar el tamaño de una partición”.

    • A partir de la tabla de particiones, determinar:

      • Los puntos inicial y final de la nueva partición
      • En MBR, qué tipo de partición debe ser.

  3. Crea la nueva partición: 

    (parted) mkpart part-type name fs-type start end
    Copy to Clipboard
    • Sustituya part-type con primary, logical, o extended en base a lo que haya decidido de la tabla de particiones. Esto se aplica sólo a la tabla de particiones MBR.
    • Sustituya name con un nombre de partición arbitrario. Esto es necesario para las tablas de partición GPT.
    • Sustituir fs-type por cualquiera de los siguientes: xfs, ext2, ext3, ext4, fat16, fat32, hfs, hfs , linux-swap, ntfs, o reiserfs. El parámetro fs-type es opcional. Tenga en cuenta que parted no crea el sistema de archivos en la partición.
    • Sustituya start y end con los tamaños que determinan los puntos inicial y final de la partición, contando desde el principio del disco. Puede utilizar sufijos de tamaño, como 512MiB, 20GiB, o 1.5TiB. El tamaño por defecto es de megabytes.

    Ejemplo 10.3. Creación de una pequeña partición primaria

    Por ejemplo, para crear una partición primaria de 1024MiB hasta 2048MiB en una tabla MBR, utilice: 

    (parted) mkpart primary 1024MiB 2048MiB
    Copy to Clipboard

    Los cambios empiezan a producirse en cuanto se introduce este comando, así que revísalo antes de ejecutarlo.

  4. Vea la tabla de particiones para confirmar que la partición creada está en la tabla de particiones con el tipo de partición, el tipo de sistema de archivos y el tamaño correctos: 

    Impresión (parcial)
    Copy to Clipboard

  5. Salga del shell parted: 

    (separada) dejar de fumar
    Copy to Clipboard

  6. Utilice el siguiente comando para esperar a que el sistema registre el nuevo nodo de dispositivo: 

    # udevadm settle
    Copy to Clipboard

  7. Verifique que el kernel reconoce la nueva partición: 

    # cat /proc/partitions
    Copy to Clipboard

Recursos adicionales

  • La página de manual parted(8).

10.3.6. Establecer un tipo de partición con fdisk

Este procedimiento describe cómo establecer un tipo de partición, o bandera, utilizando la utilidad fdisk.

Requisitos previos

  • Hay una partición en el disco.

Procedimiento

  1. Inicie el shell interactivo fdisk: 

    # fdisk block-device
    Copy to Clipboard
    • Sustituya block-device por la ruta del dispositivo en el que desea establecer un tipo de partición: por ejemplo, /dev/sda.

  2. Ver la tabla de particiones actual para determinar el número de partición menor: 

    Comando (m de ayuda) print
    Copy to Clipboard

    Puede ver el tipo de partición actual en la columna Type y su correspondiente ID de tipo en la columna Id.

  3. Introduzca el comando de tipo de partición y seleccione una partición utilizando su número menor: 

    Command (m for help): type
Partition number (1,2,3 default 3): 2
    Copy to Clipboard

  4. Opcionalmente, enumera los códigos hexadecimales disponibles: 

    Código hexadecimal (escriba L para listar todos los códigos) L
    Copy to Clipboard

  5. Establezca el tipo de partición: 

    Código hexadecimal (escriba L para listar todos los códigos) 8e
    Copy to Clipboard

  6. Escriba sus cambios y salga del shell fdisk: 

    Command (m for help): write
The partition table has been altered.
Syncing disks.
    Copy to Clipboard

  7. Verifique los cambios: 

    # fdisk --list block-device
    Copy to Clipboard

10.4. Eliminar una partición

Como administrador del sistema, puede eliminar una partición de disco que ya no se utilice para liberar espacio en el disco.

Aviso

Al eliminar una partición se borran todos los datos almacenados en ella.

10.4.1. Consideraciones antes de modificar las particiones de un disco

Esta sección enumera los puntos clave a tener en cuenta antes de crear, eliminar o redimensionar las particiones.

Nota

Esta sección no cubre la tabla de particiones DASD, que es específica de la arquitectura IBM Z. Para obtener información sobre DASD, consulte:

El número máximo de particiones

El número de particiones en un dispositivo está limitado por el tipo de tabla de particiones:

  • En un dispositivo formateado con la tabla de particiones Master Boot Record (MBR), puede tener cualquiera de los dos:

    • Hasta cuatro particiones primarias, o
    • Hasta tres particiones primarias, una partición extendida y múltiples particiones lógicas dentro de la extendida.
  • En un dispositivo formateado con el GUID Partition Table (GPT), el número máximo de particiones es 128. Aunque la especificación GPT permite más particiones aumentando el área reservada para la tabla de particiones, la práctica común utilizada por la utilidad parted es limitarla a un área suficiente para 128 particiones.
Nota

Red Hat recomienda que, a menos que tenga una razón para hacer lo contrario, debería at least crear las siguientes particiones: swap, /boot/, y / (raíz).

El tamaño máximo de una partición

El tamaño de una partición en un dispositivo está limitado por el tipo de tabla de particiones:

  • En un dispositivo formateado con la tabla de particiones Master Boot Record (MBR), el tamaño máximo es de 2TiB.
  • En un dispositivo formateado con el GUID Partition Table (GPT), el tamaño máximo es de 8ZiB.

Si quieres crear una partición mayor de 2TiB, el disco debe estar formateado con GPT.

Alineación de tamaños

La utilidad parted le permite especificar el tamaño de la partición utilizando varios sufijos diferentes:

MiB, GiB o TiB

Tamaño expresado en potencias de 2.

  • El punto inicial de la partición se alinea con el sector exacto especificado por el tamaño.
  • El punto final se alinea con el tamaño especificado menos 1 sector.
MB, GB o TB

Tamaño expresado en potencias de 10.

El punto inicial y final se alinea dentro de la mitad de la unidad especificada: por ejemplo, ±500KB cuando se utiliza el sufijo MB.

10.4.2. Eliminación de una partición con parted

Este procedimiento describe cómo eliminar una partición de disco utilizando la utilidad parted.

Procedimiento

  1. Inicie el shell interactivo parted: 

    # parted block-device
    Copy to Clipboard
    • Sustituya block-device por la ruta del dispositivo en el que desea eliminar una partición: por ejemplo, /dev/sda.

  2. Ver la tabla de particiones actual para determinar el número menor de la partición a eliminar: 

    Impresión (parcial)
    Copy to Clipboard

  3. Retire la partición: 

    (separado) rm minor-number
    Copy to Clipboard
    • Sustituya minor-number por el número menor de la partición que desea eliminar: por ejemplo, 3.

    Los cambios empiezan a producirse en cuanto se introduce este comando, así que revísalo antes de ejecutarlo.

  4. Confirme que la partición se ha eliminado de la tabla de particiones: 

    Impresión (parcial)
    Copy to Clipboard

  5. Salga del shell parted: 

    (separada) dejar de fumar
    Copy to Clipboard

  6. Verifique que el kernel sabe que la partición ha sido eliminada: 

    # cat /proc/partitions
    Copy to Clipboard
  7. Elimine la partición del archivo /etc/fstab si está presente. Encuentre la línea que declara la partición eliminada, y elimínela del archivo.

  8. Regenere las unidades de montaje para que su sistema registre la nueva configuración de /etc/fstab: 

    # systemctl daemon-reload
    Copy to Clipboard

  9. Si ha eliminado una partición swap o ha eliminado partes de LVM, elimine todas las referencias a la partición de la línea de comandos del kernel en el archivo /etc/default/grub y regenere la configuración de GRUB:

    • En un sistema basado en BIOS: 

      # grub2-mkconfig --output=/etc/grub2.cfg
      Copy to Clipboard

    • En un sistema basado en UEFI: 

      # grub2-mkconfig --output=/etc/grub2-efi.cfg
      Copy to Clipboard

  10. Para registrar los cambios en el sistema de arranque temprano, reconstruya el sistema de archivos initramfs: 

    # dracut --force --verbose
    Copy to Clipboard

Recursos adicionales

  • La página de manual parted(8)

10.5. Cambiar el tamaño de una partición

Como administrador del sistema, puede ampliar una partición para utilizar el espacio de disco no utilizado, o reducir una partición para utilizar su capacidad para diferentes propósitos.

10.5.1. Consideraciones antes de modificar las particiones de un disco

Esta sección enumera los puntos clave a tener en cuenta antes de crear, eliminar o redimensionar las particiones.

Nota

Esta sección no cubre la tabla de particiones DASD, que es específica de la arquitectura IBM Z. Para obtener información sobre DASD, consulte:

El número máximo de particiones

El número de particiones en un dispositivo está limitado por el tipo de tabla de particiones:

  • En un dispositivo formateado con la tabla de particiones Master Boot Record (MBR), puede tener cualquiera de los dos:

    • Hasta cuatro particiones primarias, o
    • Hasta tres particiones primarias, una partición extendida y múltiples particiones lógicas dentro de la extendida.
  • En un dispositivo formateado con el GUID Partition Table (GPT), el número máximo de particiones es 128. Aunque la especificación GPT permite más particiones aumentando el área reservada para la tabla de particiones, la práctica común utilizada por la utilidad parted es limitarla a un área suficiente para 128 particiones.
Nota

Red Hat recomienda que, a menos que tenga una razón para hacer lo contrario, debería at least crear las siguientes particiones: swap, /boot/, y / (raíz).

El tamaño máximo de una partición

El tamaño de una partición en un dispositivo está limitado por el tipo de tabla de particiones:

  • En un dispositivo formateado con la tabla de particiones Master Boot Record (MBR), el tamaño máximo es de 2TiB.
  • En un dispositivo formateado con el GUID Partition Table (GPT), el tamaño máximo es de 8ZiB.

Si quieres crear una partición mayor de 2TiB, el disco debe estar formateado con GPT.

Alineación de tamaños

La utilidad parted le permite especificar el tamaño de la partición utilizando varios sufijos diferentes:

MiB, GiB o TiB

Tamaño expresado en potencias de 2.

  • El punto inicial de la partición se alinea con el sector exacto especificado por el tamaño.
  • El punto final se alinea con el tamaño especificado menos 1 sector.
MB, GB o TB

Tamaño expresado en potencias de 10.

El punto inicial y final se alinea dentro de la mitad de la unidad especificada: por ejemplo, ±500KB cuando se utiliza el sufijo MB.

10.5.2. Redimensionar una partición con parted

Este procedimiento redimensiona una partición de disco utilizando la utilidad parted.

Requisitos previos

  • Si quieres reducir una partición, haz una copia de seguridad de los datos que están almacenados en ella.

    Aviso

    Reducir una partición puede provocar la pérdida de datos en la partición.

  • Si quiere redimensionar una partición para que sea mayor de 2TiB, el disco debe estar formateado con la tabla de particiones GUID (GPT). Para más detalles sobre cómo formatear el disco, consulte Sección 10.2, “Creación de una tabla de particiones en un disco”.

Procedimiento

  1. Si quiere reducir la partición, reduzca primero el sistema de archivos en ella para que no sea mayor que la partición redimensionada. Tenga en cuenta que XFS no admite la contracción.

  2. Inicie el shell interactivo parted: 

    # parted block-device
    Copy to Clipboard
    • Sustituya block-device por la ruta del dispositivo en el que desea redimensionar una partición: por ejemplo, /dev/sda.

  3. Ver la tabla de particiones actual: 

    Impresión (parcial)
    Copy to Clipboard

    A partir de la tabla de particiones, determinar:

    • El número menor de la partición
    • La ubicación de la partición existente y su nuevo punto final tras el redimensionamiento

  4. Redimensiona la partición: 

    (parted) resizepart minor-number new-end
    Copy to Clipboard
    • Sustituya minor-number por el número menor de la partición que está redimensionando: por ejemplo, 3.
    • Sustituya new-end con el tamaño que determina el nuevo punto final de la partición redimensionada, contando desde el principio del disco. Puede utilizar sufijos de tamaño, como 512MiB, 20GiB, o 1.5TiB. El tamaño por defecto es de megabytes.

    Ejemplo 10.4. Ampliar una partición

    Por ejemplo, para ampliar una partición situada al principio del disco para que tenga un tamaño de 2GiB, utilice: 

    (parted) resizepart 1 2GiB
    Copy to Clipboard

    Los cambios empiezan a producirse en cuanto se introduce este comando, así que revísalo antes de ejecutarlo.

  5. Vea la tabla de particiones para confirmar que la partición redimensionada está en la tabla de particiones con el tamaño correcto: 

    Impresión (parcial)
    Copy to Clipboard

  6. Salga del shell parted: 

    (separada) dejar de fumar
    Copy to Clipboard

  7. Verifique que el kernel reconoce la nueva partición: 

    # cat /proc/partitions
    Copy to Clipboard
  8. Si ha ampliado la partición, amplíe también el sistema de archivos en ella. Consulte (referencia) para más detalles.

Recursos adicionales

  • La página de manual parted(8).

10.6. Estrategias para reparticionar un disco

Hay varias maneras de reparticionar un disco. En esta sección se analizan los siguientes enfoques posibles:

  • Hay espacio libre sin particionar
  • Se dispone de una partición no utilizada
  • Hay espacio libre en una partición utilizada activamente

Tenga en cuenta que esta sección discute los conceptos mencionados anteriormente sólo teóricamente y no incluye ningún paso de procedimiento sobre cómo realizar la repartición del disco paso a paso.

Nota

Las ilustraciones siguientes están simplificadas en aras de la claridad y no reflejan la disposición exacta de las particiones que encontrará cuando instale realmente Red Hat Enterprise Linux.

10.6.1. Uso del espacio libre no particionado

En esta situación, las particiones ya definidas no abarcan todo el disco duro, dejando espacio sin asignar que no forma parte de ninguna partición definida. El siguiente diagrama muestra cómo podría ser esto:

Figura 10.5. Disco con espacio libre no particionado

En el ejemplo anterior, el primer diagrama representa un disco con una partición primaria y una partición indefinida con espacio no asignado, y el segundo diagrama representa un disco con dos particiones definidas con espacio asignado.

Un disco duro no utilizado también entra en esta categoría. La única diferencia es que all el espacio no forma parte de ninguna partición definida.

En cualquier caso, puede crear las particiones necesarias a partir del espacio no utilizado. Este escenario es el más probable para un disco nuevo. La mayoría de los sistemas operativos preinstalados están configurados para ocupar todo el espacio disponible en una unidad de disco.

10.6.2. Utilizar el espacio de una partición no utilizada

En este caso, puede tener una o más particiones que ya no utilice. El siguiente diagrama ilustra esta situación.

Figura 10.6. Disco con una partición no utilizada

En el ejemplo anterior, el primer diagrama representa un disco con una partición no utilizada, y el segundo diagrama representa la reasignación de una partición no utilizada para Linux.

En esta situación, puede utilizar el espacio asignado a la partición no utilizada. Debe eliminar la partición y luego crear la(s) partición(es) Linux apropiada(s) en su lugar. Puede eliminar la partición no utilizada y crear manualmente nuevas particiones durante el proceso de instalación.

10.6.3. Utilizar el espacio libre de una partición activa

Esta es la situación más común. También es la más difícil de manejar, porque incluso si tiene suficiente espacio libre, actualmente está asignado a una partición que ya está en uso. Si has comprado un ordenador con software preinstalado, lo más probable es que el disco duro tenga una gran partición con el sistema operativo y los datos.

Además de añadir un nuevo disco duro a su sistema, puede elegir entre repartición destructiva y no destructiva.

10.6.3.1. Repartición destructiva

Esto elimina la partición y crea varias más pequeñas en su lugar. Debes hacer una copia de seguridad completa porque cualquier dato en la partición original se destruye. Cree dos copias de seguridad, utilice la verificación (si está disponible en su software de copia de seguridad) e intente leer los datos de la copia de seguridad before borrando la partición.

Aviso

Si se instaló un sistema operativo en esa partición, deberá reinstalarlo si quiere utilizar también ese sistema. Tenga en cuenta que algunos ordenadores que se venden con sistemas operativos preinstalados pueden no incluir los medios de instalación para reinstalar el sistema operativo original. Debes comprobar si esto se aplica a tu sistema before y destruir la partición original y su instalación del sistema operativo.

Después de crear una partición más pequeña para su sistema operativo existente, puede reinstalar el software, restaurar sus datos e iniciar su instalación de Red Hat Enterprise Linux.

Figura 10.7. Acción destructiva de repartición en disco

Aviso

Cualquier dato presente previamente en la partición original se pierde.

10.6.3.2. Repartición no destructiva

Con la repartición no destructiva se ejecuta un programa que hace más pequeña una partición grande sin perder ninguno de los archivos almacenados en esa partición. Este método suele ser fiable, pero puede llevar mucho tiempo en unidades grandes.

El proceso de repartición no destructiva es sencillo y consta de tres pasos:

  1. Compresión y copia de seguridad de los datos existentes
  2. Redimensionar la partición existente
  3. Crear nueva(s) partición(es)

Cada paso se describe con más detalle.

10.6.3.2.1. Compresión de datos existentes

El primer paso es comprimir los datos de la partición existente. La razón para hacer esto es reorganizar los datos para maximizar el espacio libre disponible en el "final" de la partición.

Figura 10.8. Compresión en disco

En el ejemplo anterior, el primer diagrama representa el disco antes de la compresión, y el segundo diagrama después de la compresión.

Este paso es crucial. Sin él, la ubicación de los datos podría impedir que la partición se redimensionara en la medida deseada. Tenga en cuenta que algunos datos no se pueden mover. En este caso, se restringe severamente el tamaño de sus nuevas particiones, y podría verse obligado a reparticionar destructivamente su disco.

10.6.3.2.2. Redimensionar la partición existente

La siguiente figura muestra el proceso real de redimensionamiento. Aunque el resultado real de la operación de redimensionamiento varía, dependiendo del software utilizado, en la mayoría de los casos el espacio recién liberado se utiliza para crear una partición sin formato del mismo tipo que la partición original.

Figura 10.9. Redimensionamiento de la partición en el disco

En el ejemplo anterior, el primer diagrama representa la partición antes del redimensionamiento, y el segundo diagrama después del redimensionamiento.

Es importante entender lo que el software de redimensionamiento que usas hace con el espacio recién liberado, para que puedas tomar los pasos apropiados. En el caso ilustrado aquí, lo mejor sería borrar la nueva partición DOS y crear la o las particiones Linux apropiadas.

10.6.3.2.3. Creación de nuevas particiones

Como se mencionó en el ejemplo Redimensionamiento de la partición existente, podría ser necesario o no crear nuevas particiones. Sin embargo, a menos que su software de redimensionamiento soporte sistemas con Linux instalado, es probable que deba eliminar la partición que se creó durante el proceso de redimensionamiento.

Figura 10.10. Disco con la configuración final de la partición

En el ejemplo anterior, el primer diagrama representa el disco antes de la configuración, y el segundo diagrama después de la configuración.

Capítulo 11. Introducción a XFS

Este es un resumen de cómo crear y mantener sistemas de archivos XFS.

11.1. El sistema de archivos XFS

XFS es un sistema de archivos de 64 bits altamente escalable, de alto rendimiento, robusto y maduro que soporta archivos y sistemas de archivos muy grandes en un solo host. Es el sistema de archivos por defecto en Red Hat Enterprise Linux 8. XFS fue desarrollado originalmente a principios de los 90 por SGI y tiene una larga historia de funcionamiento en servidores y matrices de almacenamiento extremadamente grandes.

Las características de XFS incluyen:

Fiabilidad
  • El registro en el diario de los metadatos, que garantiza la integridad del sistema de archivos después de un fallo del sistema, ya que mantiene un registro de las operaciones del sistema de archivos que puede reproducirse cuando se reinicia el sistema y se vuelve a montar el sistema de archivos
  • Amplia comprobación de la coherencia de los metadatos en tiempo de ejecución
  • Utilidades de reparación escalables y rápidas
  • Registro de cuotas. Esto evita la necesidad de largas comprobaciones de consistencia de cuotas después de una caída.
Escalabilidad y rendimiento
  • Tamaño del sistema de archivos soportado hasta 1024 TiB
  • Capacidad para soportar un gran número de operaciones simultáneas
  • Indexación del árbol B para la escalabilidad de la gestión del espacio libre
  • Sofisticados algoritmos de lectura anticipada de metadatos
  • Optimizaciones para cargas de trabajo de vídeo en streaming
Regímenes de asignación
  • Asignación basada en la extensión
  • Políticas de asignación con conocimiento de las franjas
  • Asignación retardada
  • Pre-asignación de espacio
  • Inodos asignados dinámicamente
Otras características
  • Copias de archivos basadas en Reflink (nuevo en Red Hat Enterprise Linux 8)
  • Utilidades de copia de seguridad y restauración estrechamente integradas
  • Desfragmentación en línea
  • Crecimiento del sistema de archivos en línea
  • Amplia capacidad de diagnóstico
  • Atributos extendidos (xattr). Esto permite al sistema asociar varios pares nombre/valor adicionales por archivo.
  • Cuotas de proyectos o directorios. Esto permite restringir las cuotas sobre un árbol de directorios.
  • Marcas de tiempo de subsegundos
Características de rendimiento

XFS tiene un alto rendimiento en sistemas grandes con cargas de trabajo empresariales. Un sistema grande es aquel con un número relativamente alto de CPUs, múltiples HBAs y conexiones a matrices de discos externas. XFS también tiene un buen rendimiento en sistemas más pequeños que tienen una carga de trabajo de E/S paralela y multihilo.

XFS tiene un rendimiento relativamente bajo para cargas de trabajo intensivas en metadatos de un solo hilo: por ejemplo, una carga de trabajo que crea o borra un gran número de archivos pequeños en un solo hilo.

11.2. Creación de un sistema de archivos XFS

Como administrador del sistema, puede crear un sistema de archivos XFS en un dispositivo de bloque para que pueda almacenar archivos y directorios.

11.2.1. Creación de un sistema de archivos XFS con mkfs.xfs

Este procedimiento describe cómo crear un sistema de archivos XFS en un dispositivo de bloque.

Procedimiento

  1. Para crear el sistema de archivos:

    • Si el dispositivo es una partición normal, un volumen LVM, un volumen MD, un disco o un dispositivo similar, utilice el siguiente comando: 

      # mkfs.xfs block-device
      Copy to Clipboard
      • Sustituya block-device por la ruta de acceso al dispositivo de bloque. Por ejemplo, /dev/sdb1, /dev/disk/by-uuid/05e99ec8-def1-4a5e-8a9d-5945339ceb2a, o /dev/my-volgroup/my-lv.
      • En general, las opciones por defecto son óptimas para el uso común.
      • Cuando utilice mkfs.xfs en un dispositivo de bloque que contenga un sistema de archivos existente, añada la opción -f para sobrescribir ese sistema de archivos.

    • Para crear el sistema de archivos en un dispositivo RAID por hardware, compruebe si el sistema detecta correctamente la geometría de las franjas del dispositivo:

      • Si la información de la geometría de la banda es correcta, no se necesitan opciones adicionales. Cree el sistema de archivos: 

        # mkfs.xfs block-device
        Copy to Clipboard

      • Si la información es incorrecta, especifique la geometría de la franja manualmente con los parámetros su y sw de la opción -d. El parámetro su especifica el tamaño de los trozos de RAID y el parámetro sw especifica el número de discos de datos en el dispositivo RAID.

        Por ejemplo: 

        # mkfs.xfs -d su=64k,sw=4 /dev/sda3
        Copy to Clipboard

  2. Utilice el siguiente comando para esperar a que el sistema registre el nuevo nodo de dispositivo: 

    # udevadm settle
    Copy to Clipboard

Recursos adicionales

  • La página de manual mkfs.xfs(8).

11.2.2. Creación de un sistema de archivos XFS en un dispositivo de bloque utilizando RHEL System Roles

Esta sección describe cómo crear un sistema de archivos XFS en un dispositivo de bloque en varias máquinas de destino utilizando el rol storage.

Requisitos previos

  • Existe un playbook de Ansible que utiliza el rol storage.

    Para obtener información sobre cómo aplicar un libro de jugadas de este tipo, consulte Aplicar un rol.

11.2.2.1. Ejemplo de playbook de Ansible para crear un sistema de archivos XFS en un dispositivo de bloques

Esta sección proporciona un ejemplo de libro de jugadas de Ansible. Este libro de jugadas aplica el rol storage para crear un sistema de archivos XFS en un dispositivo de bloques utilizando los parámetros predeterminados.

Aviso

El rol storage puede crear un sistema de archivos sólo en un disco entero no particionado o en un volumen lógico (LV). No puede crear el sistema de archivos en una partición.

Ejemplo 11.1. Un playbook que crea XFS en /dev/sdb

---
- hosts: all
  vars:
    storage_volumes:
      - name: barefs
        type: disk
        disks:
          - sdb
        fs_type: xfs
  roles:
    - rhel-system-roles.storage
Copy to Clipboard
  • El nombre del volumen (barefs en el ejemplo) es actualmente arbitrario. El rol storage identifica el volumen por el dispositivo de disco listado bajo el atributo disks:.
  • Puede omitir la línea fs_type: xfs porque XFS es el sistema de archivos por defecto en RHEL 8.

  • Para crear el sistema de archivos en un LV, proporcione la configuración de LVM bajo el atributo disks:, incluyendo el grupo de volúmenes que lo rodea. Para obtener más detalles, consulte Ejemplo de libro de jugadas de Ansible para gestionar volúmenes lógicos.

    No proporcione la ruta de acceso al dispositivo LV.

Recursos adicionales

  • Para más detalles sobre los parámetros utilizados en el rol de sistema storage, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.storage/README.md.
11.2.2.2. Recursos adicionales

11.3. Copia de seguridad de un sistema de archivos XFS

Como administrador del sistema, puede utilizar la página xfsdump para hacer una copia de seguridad de un sistema de archivos XFS en un archivo o en una cinta. Esto proporciona un mecanismo de copia de seguridad simple.

11.3.1. Características de la copia de seguridad XFS

En esta sección se describen los conceptos y las características principales de las copias de seguridad de un sistema de archivos XFS con la utilidad xfsdump.

Puede utilizar la utilidad xfsdump para:

  • Realiza copias de seguridad en imágenes de archivos regulares.

    Sólo se puede escribir una copia de seguridad en un archivo normal.

  • Realiza copias de seguridad en unidades de cinta.

    La utilidad xfsdump también permite escribir varias copias de seguridad en la misma cinta. Una copia de seguridad puede abarcar varias cintas.

    Para hacer una copia de seguridad de varios sistemas de archivos en un solo dispositivo de cinta, simplemente escriba la copia de seguridad en una cinta que ya contenga una copia de seguridad XFS. Esto añade la nueva copia de seguridad a la anterior. Por defecto, xfsdump nunca sobrescribe las copias de seguridad existentes.

  • Crear copias de seguridad incrementales.

    La utilidad xfsdump utiliza los niveles de volcado para determinar una copia de seguridad base a la que se refieren las demás copias de seguridad. Los números del 0 al 9 se refieren a niveles de volcado crecientes. Una copia de seguridad incremental sólo respalda los archivos que han cambiado desde el último volcado de un nivel inferior:

    • Para realizar una copia de seguridad completa, realice un volcado de nivel 0 en el sistema de archivos.
    • Un volcado de nivel 1 es la primera copia de seguridad incremental después de una copia de seguridad completa. La siguiente copia de seguridad incremental sería la de nivel 2, que sólo hace una copia de seguridad de los archivos que han cambiado desde el último volcado de nivel 1; y así sucesivamente, hasta un máximo de nivel 9.
  • Excluya archivos de una copia de seguridad utilizando banderas de tamaño, subárbol o inodo para filtrarlos.

Recursos adicionales

  • La página de manual xfsdump(8).

11.3.2. Copia de seguridad de un sistema de archivos XFS con xfsdump

Este procedimiento describe cómo hacer una copia de seguridad del contenido de un sistema de archivos XFS en un archivo o en una cinta.

Requisitos previos

  • Un sistema de archivos XFS del que se puede hacer una copia de seguridad.
  • Otro sistema de archivos o una unidad de cinta donde almacenar la copia de seguridad.

Procedimiento

  • Utilice el siguiente comando para hacer una copia de seguridad de un sistema de archivos XFS: 

    # xfsdump -l level [-L label] \
          -f backup-destination path-to-xfs-filesystem
    Copy to Clipboard
    • Sustituya level por el nivel de volcado de su copia de seguridad. Utilice 0 para realizar una copia de seguridad completa o 1 a 9 para realizar copias de seguridad incrementales consecuentes.
    • Sustituya backup-destination por la ruta en la que desea almacenar la copia de seguridad. El destino puede ser un archivo normal, una unidad de cinta o un dispositivo de cinta remoto. Por ejemplo, /backup-files/Data.xfsdump para un archivo o /dev/st0 para una unidad de cinta.
    • Sustituya path-to-xfs-filesystem por el punto de montaje del sistema de archivos XFS del que desea hacer una copia de seguridad. Por ejemplo, /mnt/data/. El sistema de archivos debe estar montado.
    • Cuando haga una copia de seguridad de varios sistemas de archivos y los guarde en un solo dispositivo de cinta, añada una etiqueta de sesión a cada copia de seguridad utilizando la opción -L label para que sea más fácil identificarlas al restaurarlas. Sustituya label por cualquier nombre de la copia de seguridad: por ejemplo, backup_data.

Ejemplo 11.2. Copia de seguridad de varios sistemas de archivos XFS

  • Para hacer una copia de seguridad del contenido de los sistemas de archivos XFS montados en los directorios /boot/ y /data/ y guardarlos como archivos en el directorio /backup-files/: 

    # xfsdump -l 0 -f /backup-files/boot.xfsdump /boot
# xfsdump -l 0 -f /backup-files/data.xfsdump /data
    Copy to Clipboard

  • Para hacer una copia de seguridad de varios sistemas de archivos en un único dispositivo de cinta, añada una etiqueta de sesión a cada copia de seguridad utilizando la -L label opción: 

    # xfsdump -l 0 -L "backup_boot" -f /dev/st0 /boot
# xfsdump -l 0 -L "backup_data" -f /dev/st0 /data
    Copy to Clipboard

Recursos adicionales

  • La página de manual xfsdump(8).

11.3.3. Recursos adicionales

  • La página de manual xfsdump(8).

11.4. Restauración de un sistema de archivos XFS a partir de una copia de seguridad

Como administrador del sistema, puede utilizar la utilidad xfsrestore para restaurar la copia de seguridad XFS creada con la utilidad xfsdump y almacenada en un archivo o en una cinta.

11.4.1. Características de la restauración de XFS a partir de una copia de seguridad

En esta sección se describen los conceptos y características clave de la restauración de un sistema de archivos XFS a partir de una copia de seguridad con la utilidad xfsrestore.

La utilidad xfsrestore restaura sistemas de archivos a partir de copias de seguridad producidas por xfsdump. La utilidad xfsrestore tiene dos modos:

  • El modo simple permite a los usuarios restaurar un sistema de archivos completo a partir de un volcado de nivel 0. Este es el modo por defecto.
  • El modo cumulative permite la restauración del sistema de archivos a partir de una copia de seguridad incremental: es decir, del nivel 1 al nivel 9.

Un único session ID o session label identifica cada copia de seguridad. La restauración de una copia de seguridad desde una cinta que contenga varias copias de seguridad requiere su correspondiente ID de sesión o etiqueta.

Para extraer, añadir o eliminar archivos específicos de una copia de seguridad, entre en el modo interactivo xfsrestore. El modo interactivo proporciona un conjunto de comandos para manipular los archivos de la copia de seguridad.

Recursos adicionales

  • La página de manual xfsrestore(8).

11.4.2. Restauración de un sistema de archivos XFS a partir de una copia de seguridad con xfsrestore

Este procedimiento describe cómo restaurar el contenido de un sistema de archivos XFS a partir de una copia de seguridad de archivos o cintas.

Requisitos previos

Procedimiento

  • El comando para restaurar la copia de seguridad varía en función de si se está restaurando a partir de una copia de seguridad completa o de una incremental, o si se están restaurando varias copias de seguridad a partir de un único dispositivo de cinta: 

    # xfsrestore [-r] [-S session-id] [-L session-label] [-i]
             -f backup-location restoration-path
    Copy to Clipboard
    • Sustituya backup-location con la ubicación de la copia de seguridad. Puede ser un archivo normal, una unidad de cinta o un dispositivo de cinta remoto. Por ejemplo, /backup-files/Data.xfsdump para un archivo o /dev/st0 para una unidad de cinta.
    • Sustituya restoration-path por la ruta del directorio donde desea restaurar el sistema de archivos. Por ejemplo, /mnt/data/.
    • Para restaurar un sistema de archivos a partir de una copia de seguridad incremental (nivel 1 a nivel 9), añada la opción -r.

    • Para restaurar una copia de seguridad desde un dispositivo de cinta que contiene varias copias de seguridad, especifique la copia de seguridad utilizando las opciones -S o -L.

      La opción -S permite elegir una copia de seguridad por su ID de sesión, mientras que la opción -L permite elegir por la etiqueta de sesión. Para obtener el ID de sesión y las etiquetas de sesión, utilice el comando xfsrestore -I.

      Sustituya session-id por el ID de sesión de la copia de seguridad. Por ejemplo, b74a3586-e52e-4a4a-8775-c3334fa8ea2c. Sustituya session-label por la etiqueta de la sesión de la copia de seguridad. Por ejemplo, my_backup_session_label.

    • Para utilizar xfsrestore de forma interactiva, utilice la opción -i.

      El diálogo interactivo comienza después de que xfsrestore termine de leer el dispositivo especificado. Los comandos disponibles en el shell interactivo xfsrestore incluyen cd, ls, add, delete, y extract; para una lista completa de comandos, utilice el comando help.

Ejemplo 11.3. Restauración de varios sistemas de archivos XFS

  • Para restaurar los archivos de la copia de seguridad XFS y guardar su contenido en directorios bajo /mnt/: 

    # xfsrestore -f /backup-files/boot.xfsdump /mnt/boot/
# xfsrestore -f /backup-files/data.xfsdump /mnt/data/
    Copy to Clipboard

  • Para restaurar desde un dispositivo de cinta que contenga varias copias de seguridad, especifique cada copia de seguridad por su etiqueta o ID de sesión: 

    # xfsrestore -L "backup_boot" -f /dev/st0 /mnt/boot/
# xfsrestore -S "45e9af35-efd2-4244-87bc-4762e476cbab" \
             -f /dev/st0 /mnt/data/
    Copy to Clipboard

Recursos adicionales

  • La página de manual xfsrestore(8).

11.4.3. Mensajes informativos al restaurar una copia de seguridad XFS desde una cinta

Al restaurar una copia de seguridad de una cinta con copias de seguridad de varios sistemas de archivos, la utilidad xfsrestore puede emitir mensajes. Los mensajes le informan de si se ha encontrado una coincidencia de la copia de seguridad solicitada cuando xfsrestore examina cada copia de seguridad de la cinta en orden secuencial. Por ejemplo: 

xfsrestore: preparing drive
xfsrestore: examining media file 0
xfsrestore: inventory session uuid (8590224e-3c93-469c-a311-fc8f23029b2a) does not match the media header's session uuid (7eda9f86-f1e9-4dfd-b1d4-c50467912408)
xfsrestore: examining media file 1
xfsrestore: inventory session uuid (8590224e-3c93-469c-a311-fc8f23029b2a) does not match the media header's session uuid (7eda9f86-f1e9-4dfd-b1d4-c50467912408)
[...]
Copy to Clipboard

Los mensajes informativos siguen apareciendo hasta que se encuentra la copia de seguridad correspondiente.

11.4.4. Recursos adicionales

  • La página de manual xfsrestore(8).

11.5. Aumentar el tamaño de un sistema de archivos XFS

Como administrador del sistema, puede aumentar el tamaño de un sistema de archivos XFS para utilizar una mayor capacidad de almacenamiento.

Importante

Actualmente no es posible disminuir el tamaño de los sistemas de archivos XFS.

11.5.1. Aumentar el tamaño de un sistema de archivos XFS con xfs_growfs

Este procedimiento describe cómo hacer crecer un sistema de archivos XFS utilizando la utilidad xfs_growfs.

Requisitos previos

  • Asegúrese de que el dispositivo de bloque subyacente tiene un tamaño adecuado para albergar el sistema de archivos redimensionado posteriormente. Utilice los métodos de redimensionamiento adecuados para el dispositivo de bloque afectado.
  • Monte el sistema de archivos XFS.

Procedimiento

  • Mientras el sistema de archivos XFS está montado, utilice la utilidad xfs_growfs para aumentar su tamaño: 

    # xfs_growfs file-system -D new-size
    Copy to Clipboard
    • Sustituya file-system por el punto de montaje del sistema de archivos XFS.

    • Con la opción -D, sustituya new-size por el nuevo tamaño deseado del sistema de archivos especificado en el número de bloques del sistema de archivos.

      Para averiguar el tamaño de bloque en kB de un determinado sistema de archivos XFS, utilice la utilidad xfs_info: 

      # xfs_info block-device

...
data     =              bsize=4096
...
      Copy to Clipboard
    • Sin la opción -D, xfs_growfs hace crecer el sistema de archivos hasta el tamaño máximo soportado por el dispositivo subyacente.

Recursos adicionales

  • La página de manual xfs_growfs(8).

11.6. Comparación de las herramientas utilizadas con ext4 y XFS

Esta sección compara qué herramientas utilizar para realizar tareas comunes en los sistemas de archivos ext4 y XFS.

Tareaext4XFS

Crear un sistema de archivos

mkfs.ext4

mkfs.xfs

Comprobación del sistema de archivos

e2fsck

xfs_repair

Redimensionar un sistema de archivos

resize2fs

xfs_growfs

Guardar una imagen de un sistema de archivos

e2image

xfs_metadump y xfs_mdrestore

Etiquetar o ajustar un sistema de archivos

tune2fs

xfs_admin

Copia de seguridad de un sistema de archivos

dump y restore

xfsdump y xfsrestore

Gestión de cuotas

quota

xfs_quota

Asignación de archivos

filefrag

xfs_bmap

Capítulo 12. Configuración del comportamiento de los errores de XFS

Puede configurar cómo se comporta un sistema de archivos XFS cuando encuentra diferentes errores de E/S.

12.1. Gestión de errores configurable en XFS

El sistema de archivos XFS responde de una de las siguientes maneras cuando se produce un error durante una operación de E/S:

  • XFS reintenta repetidamente la operación de E/S hasta que la operación tiene éxito o XFS alcanza un límite establecido.

    El límite se basa en un número máximo de reintentos o en un tiempo máximo de reintentos.

  • XFS considera que el error es permanente y detiene la operación en el sistema de archivos.

Puede configurar cómo reacciona XFS a las siguientes condiciones de error:

EIO
Error al leer o escribir
ENOSPC
No queda espacio en el dispositivo
ENODEV
No se encuentra el dispositivo

Puede establecer el número máximo de reintentos y el tiempo máximo en segundos hasta que XFS considere un error como permanente. XFS deja de reintentar la operación cuando alcanza cualquiera de los límites.

También puede configurar XFS para que al desmontar un sistema de archivos, XFS cancele inmediatamente los reintentos independientemente de cualquier otra configuración. Esta configuración permite que la operación de desmontaje tenga éxito a pesar de los errores persistentes.

Comportamiento por defecto

El comportamiento por defecto para cada condición de error XFS depende del contexto del error. Algunos errores XFS, como ENODEV, se consideran fatales e irrecuperables, independientemente del número de reintentos. Su límite de reintentos por defecto es 0.

12.2. Archivos de configuración para condiciones de error XFS específicas e indefinidas

Los siguientes directorios almacenan archivos de configuración que controlan el comportamiento de los errores de XFS para diferentes condiciones de error:

/sys/fs/xfs/device/error/metadata/EIO/
Para la condición de error EIO
/sys/fs/xfs/device/error/metadata/ENODEV/
Para la condición de error ENODEV
/sys/fs/xfs/device/error/metadata/ENOSPC/
Para la condición de error ENOSPC
/sys/fs/xfs/device/error/default/
Configuración común para todas las demás condiciones de error no definidas

Cada directorio contiene los siguientes archivos de configuración para configurar los límites de reintento:

max_retries
Controla el número máximo de veces que XFS reintenta la operación.
retry_timeout_seconds
Especifica el límite de tiempo en segundos después del cual XFS deja de reintentar la operación.

12.3. Configuración del comportamiento de XFS para condiciones específicas

Este procedimiento configura el modo en que XFS reacciona ante determinadas condiciones de error.

Procedimiento

  • Establezca el número máximo de reintentos, el límite de tiempo de reintento o ambos:

    • Para establecer el número máximo de reintentos, escriba el número deseado en el archivo max_retries: 

      # echo value > /sys/fs/xfs/device/error/metadata/condition/max_retries
      Copy to Clipboard

    • Para establecer el límite de tiempo, escriba el número de segundos deseado en el archivo retry_timeout_seconds: 

      # echo value > /sys/fs/xfs/device/error/metadata/condition/retry_timeout_second
      Copy to Clipboard

    value es un número entre -1 y el valor máximo posible del tipo entero con signo de C. Esto es 2147483647 en Linux de 64 bits.

    En ambos límites, el valor -1 se utiliza para los reintentos continuos y 0 para detenerse inmediatamente.

    device es el nombre del dispositivo, tal y como se encuentra en el directorio /dev/; por ejemplo, sda.

12.4. Configuración del comportamiento de XFS para condiciones no definidas

Este procedimiento configura el modo en que XFS reacciona a todas las condiciones de error indefinidas, que comparten una configuración común.

Procedimiento

  • Establezca el número máximo de reintentos, el límite de tiempo de reintento o ambos:

    • Para establecer el número máximo de reintentos, escriba el número deseado en el archivo max_retries: 

      # echo value > /sys/fs/xfs/device/error/metadata/default/max_retries
      Copy to Clipboard

    • Para establecer el límite de tiempo, escriba el número de segundos deseado en el archivo retry_timeout_seconds: 

      # echo value > /sys/fs/xfs/device/error/metadata/default/retry_timeout_seconds
      Copy to Clipboard

    value es un número entre -1 y el valor máximo posible del tipo entero con signo de C. Esto es 2147483647 en Linux de 64 bits.

    En ambos límites, el valor -1 se utiliza para los reintentos continuos y 0 para detenerse inmediatamente.

    device es el nombre del dispositivo, tal y como se encuentra en el directorio /dev/; por ejemplo, sda.

12.5. Cómo configurar el comportamiento de desmontaje de XFS

Este procedimiento configura cómo reacciona XFS a las condiciones de error al desmontar el sistema de archivos.

Si se establece la opción fail_at_unmount en el sistema de archivos, se anulan todas las demás configuraciones de error durante el desmontaje, y se desmonta inmediatamente el sistema de archivos sin reintentar la operación de E/S. Esto permite que la operación de desmontaje tenga éxito incluso en caso de errores persistentes.

Aviso

No puede cambiar el valor de fail_at_unmount después de que se inicie el proceso de desmontaje, porque el proceso de desmontaje elimina los archivos de configuración de la interfaz sysfs para el sistema de archivos correspondiente. Debe configurar el comportamiento de desmontaje antes de que el sistema de archivos comience a desmontar.

Procedimiento

  • Activa o desactiva la opción fail_at_unmount:

    • Para cancelar el reintento de todas las operaciones cuando el sistema de archivos se desmonta, active la opción: 

      # echo 1 > /sys/fs/xfs/device/error/fail_at_unmount
      Copy to Clipboard

    • Para respetar los límites de reintentos de max_retries y retry_timeout_seconds cuando se desmonta el sistema de archivos, desactive la opción: 

      # echo 0 > /sys/fs/xfs/device/error/fail_at_unmount
      Copy to Clipboard

    device es el nombre del dispositivo, tal y como se encuentra en el directorio /dev/; por ejemplo, sda.

Capítulo 13. Comprobación y reparación de un sistema de archivos

RHEL proporciona utilidades de administración del sistema de archivos que son capaces de comprobar y reparar los sistemas de archivos. Estas herramientas suelen denominarse herramientas fsck, donde fsck es una versión abreviada de file system check. En la mayoría de los casos, estas utilidades se ejecutan automáticamente durante el arranque del sistema, si es necesario, pero también pueden ser invocadas manualmente si es necesario.

Importante

Los verificadores del sistema de archivos sólo garantizan la consistencia de los metadatos en el sistema de archivos. No tienen conocimiento de los datos reales contenidos en el sistema de archivos y no son herramientas de recuperación de datos.

13.1. Escenarios que requieren una comprobación del sistema de archivos

Las herramientas pertinentes de fsck pueden utilizarse para comprobar el sistema si se produce alguna de las siguientes situaciones:

  • El sistema no arranca
  • Los archivos de un disco específico se corrompen
  • El sistema de archivos se apaga o cambia a sólo lectura debido a inconsistencias
  • Un archivo en el sistema de archivos es inaccesible

Las incoherencias en el sistema de archivos pueden producirse por varias razones, entre las que se incluyen errores de hardware, errores de administración del almacenamiento y fallos de software.

Importante

Las herramientas de comprobación del sistema de archivos no pueden reparar problemas de hardware. Un sistema de archivos debe ser totalmente legible y escribible para que la reparación funcione con éxito. Si un sistema de archivos se corrompió debido a un error de hardware, el sistema de archivos debe moverse primero a un disco en buen estado, por ejemplo con la utilidad dd(8).

En el caso de los sistemas de archivos con registro en el diario, todo lo que se requiere normalmente en el momento del arranque es reproducir el diario si es necesario y esto suele ser una operación muy breve.

Sin embargo, si se produce una incoherencia o corrupción en el sistema de archivos, incluso en el caso de los sistemas de archivos con registro en el diario, se debe utilizar el comprobador del sistema de archivos para reparar el sistema de archivos.

Importante

Es posible desactivar la comprobación del sistema de archivos en el arranque estableciendo el sexto campo en /etc/fstab a 0. Sin embargo, Red Hat no recomienda hacerlo a menos que tenga problemas con fsck en el momento del arranque, por ejemplo con sistemas de archivos extremadamente grandes o remotos.

Recursos adicionales

  • La página de manual fstab(5).
  • La página de manual fsck(8).
  • La página de manual dd(8).

13.2. Posibles efectos secundarios de la ejecución de fsck

Por lo general, se puede esperar que la ejecución de la herramienta de comprobación y reparación del sistema de archivos repare automáticamente al menos algunas de las incoherencias que encuentra. En algunos casos, pueden surgir los siguientes problemas:

  • Los inodos o directorios severamente dañados pueden ser descartados si no pueden ser reparados.
  • Pueden producirse cambios significativos en el sistema de archivos.

Para garantizar que no se realicen cambios inesperados o no deseados de forma permanente, asegúrese de seguir los pasos de precaución indicados en el procedimiento.

13.3. Mecanismos de gestión de errores en XFS

Esta sección describe cómo XFS maneja varios tipos de errores en el sistema de archivos.

Desmontajes sin limpiar

La gestión de los diarios mantiene un registro transaccional de los cambios de metadatos que se producen en el sistema de archivos.

En caso de que el sistema se caiga, haya un fallo de alimentación o se desmonte de otra manera, XFS utiliza el diario (también llamado registro) para recuperar el sistema de archivos. El núcleo realiza la recuperación del diario al montar el sistema de archivos XFS.

Corrupción

En este contexto, corruption se refiere a errores en el sistema de archivos causados, por ejemplo:

  • Fallos de hardware
  • Errores en el firmware de almacenamiento, los controladores de dispositivos, la pila de software o el propio sistema de archivos
  • Problemas que hacen que partes del sistema de archivos sean sobrescritas por algo ajeno al sistema de archivos

Cuando XFS detecta una corrupción en el sistema de archivos o en los metadatos del sistema de archivos, puede cerrar el sistema de archivos e informar del incidente en el registro del sistema. Tenga en cuenta que si la corrupción se produjo en el sistema de archivos que alberga el directorio /var, estos registros no estarán disponibles después de un reinicio.

Ejemplo 13.1. Entrada en el registro del sistema informando de una corrupción de XFS

# dmesg --notime | tail -15

XFS (loop0): Mounting V5 Filesystem
XFS (loop0): Metadata CRC error detected at xfs_agi_read_verify+0xcb/0xf0 [xfs], xfs_agi block 0x2
XFS (loop0): Unmount and run xfs_repair
XFS (loop0): First 128 bytes of corrupted metadata buffer:
00000000027b3b56: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000005f9abc7a: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000005b0aef35: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000000da9d2ded: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000001e265b07: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000006a40df69: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000000b272907: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000000e484aac5: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
XFS (loop0): metadata I/O error in "xfs_trans_read_buf_map" at daddr 0x2 len 1 error 74
XFS (loop0): xfs_imap_lookup: xfs_ialloc_read_agi() returned error -117, agno 0
XFS (loop0): Failed to read root inode 0x80, error 11
Copy to Clipboard

Las utilidades del espacio de usuario suelen informar del mensaje Input/output error cuando intentan acceder a un sistema de archivos XFS dañado. El montaje de un sistema de archivos XFS con un registro dañado da como resultado un montaje fallido y el siguiente mensaje de error: 

mount /mount-pointLa llamada al sistema mount(2) ha fallado: La estructura necesita ser limpiada.
Copy to Clipboard

Debe utilizar manualmente la utilidad xfs_repair para reparar la corrupción.

Recursos adicionales

  • La página de manual xfs_repair(8) proporciona una lista detallada de las comprobaciones de corrupción de XFS.

13.4. Comprobación de un sistema de archivos XFS con xfs_repair

Este procedimiento realiza una comprobación de sólo lectura de un sistema de archivos XFS utilizando la utilidad xfs_repair. Debe utilizar manualmente la utilidad xfs_repair para reparar cualquier corrupción. A diferencia de otras utilidades de reparación de sistemas de archivos, xfs_repair no se ejecuta en el momento del arranque, incluso cuando un sistema de archivos XFS no se ha desmontado limpiamente. En el caso de un desmontaje no limpio, XFS simplemente reproduce el registro en el momento del montaje, asegurando un sistema de archivos consistente; xfs_repair no puede reparar un sistema de archivos XFS con un registro sucio sin volver a montarlo primero.

Nota

Aunque un binario fsck.xfs está presente en el paquete xfsprogs, éste está presente sólo para satisfacer a initscripts que busca un binario del sistema fsck.file en el momento del arranque. fsck.xfs sale inmediatamente con un código de salida de 0.

Procedimiento

  1. Reproducir el registro montando y desmontando el sistema de archivos: 

    # mount file-system
# umount file-system
    Copy to Clipboard
    Nota

    Si el montaje falla con un error de que la estructura necesita ser limpiada, el registro se corrompe y no puede ser reproducido. La ejecución en seco debería descubrir y reportar más corrupción en el disco como resultado.

  2. Utilice la utilidad xfs_repair para realizar una ejecución en seco para comprobar el sistema de archivos. Se imprime cualquier error y una indicación de las acciones que se tomarían, sin modificar el sistema de archivos. 

    # xfs_repair -n block-device
    Copy to Clipboard

  3. Montar el sistema de archivos: 

    # montaje file-system
    Copy to Clipboard

Recursos adicionales

  • La página de manual xfs_repair(8).
  • La página de manual xfs_metadump(8).

13.5. Reparación de un sistema de archivos XFS con xfs_repair

Este procedimiento repara un sistema de archivos XFS dañado utilizando la utilidad xfs_repair.

Procedimiento

  1. Cree una imagen de metadatos antes de la reparación con fines de diagnóstico o de prueba utilizando la utilidad xfs_metadump. Una imagen de metadatos del sistema de archivos previa a la reparación puede ser útil para las investigaciones de soporte si la corrupción se debe a un error de software. Los patrones de corrupción presentes en la imagen previa a la reparación pueden ayudar en el análisis de la causa raíz.

    • Utilice la herramienta de depuración xfs_metadump para copiar los metadatos de un sistema de archivos XFS a un archivo. El archivo metadump resultante puede comprimirse utilizando utilidades de compresión estándar para reducir el tamaño del archivo si es necesario enviar archivos metadump de gran tamaño a soporte. 

      # xfs_metadump block-device metadump-file
      Copy to Clipboard

  2. Reproducir el registro volviendo a montar el sistema de archivos: 

    # mount file-system
# umount file-system
    Copy to Clipboard

  3. Utilice la utilidad xfs_repair para reparar el sistema de archivos desmontado:

    • Si el montaje tuvo éxito, no se requieren opciones adicionales: 

      # xfs_repair block-device
      Copy to Clipboard

    • Si el montaje falló con el error Structure needs cleaning, el registro está corrupto y no puede ser reproducido. Utilice la opción -L (force log zeroing) para borrar el registro:

      Aviso

      Este comando hace que se pierdan todas las actualizaciones de metadatos en curso en el momento de la caída, lo que podría causar daños importantes en el sistema de archivos y pérdida de datos. Esto debe utilizarse sólo como último recurso si el registro no puede ser reproducido. 

      # xfs_repair -L block-device
      Copy to Clipboard

  4. Montar el sistema de archivos: 

    # montaje file-system
    Copy to Clipboard

Recursos adicionales

  • La página de manual xfs_repair(8).

13.6. Mecanismos de gestión de errores en ext2, ext3 y ext4

Los sistemas de archivos ext2, ext3 y ext4 utilizan la utilidad e2fsck para realizar comprobaciones y reparaciones del sistema de archivos. Los nombres de archivo fsck.ext2, fsck.ext3, y fsck.ext4 son enlaces duros a la utilidad e2fsck. Estos binarios se ejecutan automáticamente en el momento del arranque y su comportamiento varía en función del sistema de archivos que se esté comprobando y del estado del sistema de archivos.

Se invoca una comprobación y reparación completa del sistema de archivos para ext2, que no es un sistema de archivos con diario de metadatos, y para los sistemas de archivos ext4 sin diario.

Para los sistemas de archivos ext3 y ext4 con registro en el diario de metadatos, el diario se reproduce en el espacio de usuario y la utilidad se cierra. Esta es la acción por defecto porque la reproducción del diario asegura un sistema de archivos consistente después de un fallo.

Si estos sistemas de archivos encuentran inconsistencias en los metadatos mientras están montados, registran este hecho en el superbloque del sistema de archivos. Si e2fsck encuentra que un sistema de archivos está marcado con un error de este tipo, e2fsck realiza una comprobación completa después de reproducir el diario (si está presente).

Recursos adicionales

  • La página de manual fsck(8).
  • La página de manual e2fsck(8).

13.7. Comprobación de un sistema de archivos ext2, ext3 o ext4 con e2fsck

Este procedimiento comprueba un sistema de archivos ext2, ext3 o ext4 utilizando la utilidad e2fsck.

Procedimiento

  1. Reproducir el registro volviendo a montar el sistema de archivos: 

    # mount file-system
# umount file-system
    Copy to Clipboard

  2. Realice un simulacro para comprobar el sistema de archivos. 

    # e2fsck -n block-device
    Copy to Clipboard
    Nota

    Se imprime cualquier error y una indicación de las acciones que se tomarían, sin modificar el sistema de archivos. Las fases posteriores de la comprobación de consistencia pueden imprimir errores adicionales a medida que descubre inconsistencias que se habrían solucionado en las primeras fases si se estuviera ejecutando en modo de reparación.

Recursos adicionales

  • La página de manual e2image(8).
  • La página de manual e2fsck(8).

13.8. Reparación de un sistema de archivos ext2, ext3 o ext4 con e2fsck

Este procedimiento repara un sistema de archivos ext2, ext3 o ext4 dañado utilizando la utilidad e2fsck.

Procedimiento

  1. Guarde una imagen del sistema de archivos para las investigaciones de soporte. Una imagen de metadatos del sistema de archivos previa a la reparación puede ser útil para las investigaciones de soporte si la corrupción se debe a un error de software. Los patrones de corrupción presentes en la imagen de pre-reparación pueden ayudar en el análisis de la causa raíz.

    Nota

    Los sistemas de archivos muy dañados pueden causar problemas con la creación de imágenes de metadatos.

    • Si está creando la imagen con fines de prueba, utilice la opción -r para crear un archivo disperso del mismo tamaño que el propio sistema de archivos. e2fsck puede entonces operar directamente en el archivo resultante. 

      # e2image -r block-device image-file
      Copy to Clipboard

    • Si está creando la imagen para ser archivada o proporcionada para el diagnóstico, utilice la opción -Q, que crea un formato de archivo más compacto adecuado para la transferencia. 

      # e2image -Q block-device image-file
      Copy to Clipboard

  2. Reproducir el registro volviendo a montar el sistema de archivos: 

    # mount file-system
# umount file-system
    Copy to Clipboard

  3. Reparar automáticamente el sistema de archivos. Si se requiere la intervención del usuario, e2fsck indica el problema no reparado en su salida y refleja este estado en el código de salida. 

    # e2fsck -p block-device
    Copy to Clipboard

    Recursos adicionales

    • La página de manual e2image(8).
    • La página de manual e2fsck(8).

Capítulo 14. Montaje de sistemas de archivos

Como administrador del sistema, puedes montar sistemas de archivos en tu sistema para acceder a los datos que contienen.

14.1. El mecanismo de montaje de Linux

Esta sección explica los conceptos básicos del montaje de sistemas de archivos en Linux.

En Linux, UNIX y sistemas operativos similares, los sistemas de archivos en diferentes particiones y dispositivos extraíbles (CDs, DVDs o memorias USB, por ejemplo) se pueden montar en un punto determinado (el punto de montaje) en el árbol de directorios, y luego desprenderse de nuevo. Mientras un sistema de archivos está montado en un directorio, el contenido original del mismo no es accesible.

Tenga en cuenta que Linux no le impide montar un sistema de archivos en un directorio con un sistema de archivos ya adjunto.

Al montarlo, puedes identificar el dispositivo por:

  • un identificador único universal (UUID): por ejemplo, UUID=34795a28-ca6d-4fd8-a347-73671d0c19cb
  • una etiqueta de volumen: por ejemplo, LABEL=home
  • una ruta completa a un dispositivo de bloque no persistente: por ejemplo, /dev/sda3

Cuando se monta un sistema de archivos utilizando el comando mount sin toda la información requerida, es decir, sin el nombre del dispositivo, el directorio de destino o el tipo de sistema de archivos, la utilidad mount lee el contenido del archivo /etc/fstab para comprobar si el sistema de archivos dado aparece en él. El archivo /etc/fstab contiene una lista de nombres de dispositivos y los directorios en los que los sistemas de archivos seleccionados están configurados para ser montados, así como el tipo de sistema de archivos y las opciones de montaje. Por lo tanto, cuando se monta un sistema de archivos especificado en /etc/fstab, la siguiente sintaxis de comando es suficiente:

  • Montaje por el punto de montaje: 

    # montaje directory
    Copy to Clipboard

  • Montaje por el dispositivo de bloque: 

    # montaje device
    Copy to Clipboard

Recursos adicionales

14.2. Listado de los sistemas de archivos montados actualmente

Este procedimiento describe cómo listar todos los sistemas de archivos montados actualmente en la línea de comandos.

Procedimiento

  • Para listar todos los sistemas de archivos montados, utilice la utilidad findmnt: 

    $ findmnt
    Copy to Clipboard

  • Para limitar los sistemas de archivos listados sólo a un determinado tipo de sistema de archivos, añada la opción --types: 

    $ findmnt --types fs-type
    Copy to Clipboard

    Por ejemplo:

    Ejemplo 14.1. Listado sólo de sistemas de archivos XFS

    $ findmnt --types xfs

TARGET  SOURCE                                                FSTYPE OPTIONS
/       /dev/mapper/luks-5564ed00-6aac-4406-bfb4-c59bf5de48b5 xfs    rw,relatime
├─/boot /dev/sda1                                             xfs    rw,relatime
└─/home /dev/mapper/luks-9d185660-7537-414d-b727-d92ea036051e xfs    rw,relatime
    Copy to Clipboard

Recursos adicionales

  • La página de manual findmnt(8).

14.3. Montaje de un sistema de archivos con mount

Este procedimiento describe cómo montar un sistema de archivos utilizando la utilidad mount.

Requisitos previos

  • Asegúrese de que no hay ningún sistema de archivos montado en el punto de montaje elegido: 

    $ findmnt mount-point
    Copy to Clipboard

Procedimiento

  1. Para adjuntar un determinado sistema de archivos, utilice la utilidad mount: 

    # montaje device mount-point
    Copy to Clipboard

    Ejemplo 14.2. Montaje de un sistema de archivos XFS

    Por ejemplo, para montar un sistema de archivos XFS local identificado por UUID: 

    # mount UUID=ea74bbec-536d-490c-b8d9-5b40bbd7545b /mnt/data
    Copy to Clipboard

  2. Si mount no puede reconocer el tipo de sistema de archivos automáticamente, especifíquelo utilizando la opción --types: 

    # mount --types type device mount-point
    Copy to Clipboard

    Ejemplo 14.3. Montaje de un sistema de archivos NFS

    Por ejemplo, para montar un sistema de archivos NFS remoto: 

    # mount --types nfs4 host:/remote-export /mnt/nfs
    Copy to Clipboard

Recursos adicionales

  • La página de manual mount(8).

14.4. Mover un punto de montaje

Este procedimiento describe cómo cambiar el punto de montaje de un sistema de archivos montado a un directorio diferente.

Procedimiento

  1. Para cambiar el directorio en el que se monta un sistema de archivos: 

    # mount --move old-directory new-directory
    Copy to Clipboard

    Ejemplo 14.4. Mover un sistema de archivos doméstico

    Por ejemplo, para mover el sistema de archivos montado en el directorio /mnt/userdirs/ al punto de montaje /home/: 

    # mount --move /mnt/userdirs /home
    Copy to Clipboard

  2. Compruebe que el sistema de archivos se ha movido como se esperaba: 

    $ findmnt
$ ls old-directory
$ ls new-directory
    Copy to Clipboard

Recursos adicionales

  • La página de manual mount(8).

14.5. Desmontaje de un sistema de archivos con umount

Este procedimiento describe cómo desmontar un sistema de archivos utilizando la utilidad umount.

Procedimiento

  1. Intente desmontar el sistema de archivos utilizando cualquiera de los siguientes comandos:

    • Por punto de montaje: 

      # umount mount-point
      Copy to Clipboard

    • Por dispositivo: 

      # umount device
      Copy to Clipboard

    Si el comando falla con un error similar al siguiente, significa que el sistema de archivos está en uso porque un proceso está utilizando recursos en él: 

    umount /run/media/user/FlashDrive: el objetivo está ocupado.
    Copy to Clipboard

  2. Si el sistema de archivos está en uso, utilice la utilidad fuser para determinar qué procesos están accediendo a él. Por ejemplo: 

    $ fuser --mount /run/media/user/FlashDrive

/run/media/user/FlashDrive: 18351
    Copy to Clipboard

    A continuación, finalice los procesos que utilizan el sistema de archivos e intente desmontarlo de nuevo.

14.6. Opciones de montaje habituales

Esta sección enumera algunas de las opciones más utilizadas de la utilidad mount.

Puede utilizar estas opciones en la siguiente sintaxis: 

# mount --options option1,option2,option3 device mount-point
Copy to Clipboard
Tabla 14.1. Opciones de montaje habituales
OpciónDescripción

async

Activa las operaciones asíncronas de entrada y salida en el sistema de archivos.

auto

Permite montar automáticamente el sistema de archivos mediante el comando mount -a.

defaults

Proporciona un alias para las opciones de async,auto,dev,exec,nouser,rw,suid.

exec

Permite la ejecución de archivos binarios en el sistema de archivos particular.

loop

Monta una imagen como dispositivo de bucle.

noauto

El comportamiento por defecto desactiva el montaje automático del sistema de archivos mediante el comando mount -a.

noexec

Desactiva la ejecución de archivos binarios en el sistema de archivos concreto.

nouser

Impide que un usuario normal (es decir, que no sea root) monte y desmonte el sistema de archivos.

remount

Vuelve a montar el sistema de archivos en caso de que ya esté montado.

ro

Monta el sistema de archivos sólo para lectura.

rw

Monta el sistema de archivos tanto para leer como para escribir.

user

Permite a un usuario normal (es decir, que no sea root) montar y desmontar el sistema de archivos.

14.7. Compartir un montaje en varios puntos de montaje

Como administrador del sistema, puede duplicar los puntos de montaje para que los sistemas de archivos sean accesibles desde varios directorios.

14.7.1. Tipos de soportes compartidos

Hay varios tipos de montajes compartidos que puedes utilizar. La diferencia entre ellos es lo que ocurre cuando se monta otro sistema de archivos bajo uno de los puntos de montaje compartido. Los montajes compartidos se implementan utilizando la funcionalidad shared subtrees.

Los tipos son:

Montaje privado

Este tipo no recibe ni reenvía ningún evento de propagación.

Cuando se monta otro sistema de archivos bajo el duplicado o el punto de montaje original, no se refleja en el otro.

Montaje compartido

Este tipo crea una réplica exacta de un punto de montaje determinado.

Cuando un punto de montaje se marca como montaje compartido, cualquier montaje dentro del punto de montaje original se refleja en él, y viceversa.

Este es el tipo de montaje por defecto del sistema de archivos raíz.

Montaje de esclavos

Este tipo crea un duplicado limitado de un punto de montaje determinado.

Cuando un punto de montaje se marca como montaje esclavo, cualquier montaje dentro del punto de montaje original se refleja en él, pero ningún montaje dentro de un montaje esclavo se refleja en su original.

Montaje no vinculable
Este tipo evita que el punto de montaje dado se duplique en absoluto.

14.7.2. Creación de un duplicado de punto de montaje privado

Este procedimiento duplica un punto de montaje como un montaje privado. Los sistemas de archivos que se monten posteriormente bajo el duplicado o el punto de montaje original no se reflejan en el otro.

Procedimiento

  1. Cree un nodo de sistema de archivos virtual (VFS) a partir del punto de montaje original: 

    # mount --bind original-dir original-dir
    Copy to Clipboard

  2. Marcar el punto de montaje original como privado: 

    # mount --make-private original-dir
    Copy to Clipboard

    Alternativamente, para cambiar el tipo de montaje para el punto de montaje seleccionado y todos los puntos de montaje bajo él, utilice la opción --make-rprivate en lugar de --make-private.

  3. Crea el duplicado: 

    # mount --bind original-dir duplicate-dir
    Copy to Clipboard

Ejemplo 14.5. Duplicar /media en /mnt como punto de montaje privado

  1. Cree un nodo VFS desde el directorio /media: 

    # mount --bind /media /media
    Copy to Clipboard

  2. Marcar el directorio /media como privado: 

    # mount --make-private /media
    Copy to Clipboard

  3. Cree su duplicado en /mnt: 

    # mount --bind /media /mnt
    Copy to Clipboard

  4. Ahora es posible verificar que /media y /mnt comparten contenido pero ninguno de los montajes dentro de /media aparece en /mnt. Por ejemplo, si la unidad de CD-ROM contiene medios no vacíos y el directorio /media/cdrom/ existe, utilice: 

    # mount /dev/cdrom /media/cdrom
# ls /media/cdrom
EFI  GPL  isolinux  LiveOS
# ls /mnt/cdrom
#
    Copy to Clipboard

  5. También es posible comprobar que los sistemas de archivos montados en el directorio /mnt no se reflejan en /media. Por ejemplo, si se conecta una unidad flash USB no vacía que utiliza el dispositivo /dev/sdc1 y el directorio /mnt/flashdisk/ está presente, utilice: 

    # mount /dev/sdc1 /mnt/flashdisk
# ls /media/flashdisk
# ls /mnt/flashdisk
en-US  publican.cfg
    Copy to Clipboard

Recursos adicionales

  • La página de manual mount(8).

14.7.3. Creación de un duplicado de punto de montaje compartido

Este procedimiento duplica un punto de montaje como un montaje compartido. Los sistemas de archivos que se monten posteriormente en el directorio original o en el duplicado se reflejarán siempre en el otro.

Procedimiento

  1. Cree un nodo de sistema de archivos virtual (VFS) a partir del punto de montaje original: 

    # mount --bind original-dir original-dir
    Copy to Clipboard

  2. Marcar el punto de montaje original como compartido: 

    # mount --make-shared original-dir
    Copy to Clipboard

    Alternativamente, para cambiar el tipo de montaje para el punto de montaje seleccionado y todos los puntos de montaje bajo él, utilice la opción --make-rshared en lugar de --make-shared.

  3. Crea el duplicado: 

    # mount --bind original-dir duplicate-dir
    Copy to Clipboard

Ejemplo 14.6. Duplicación de /media en /mnt como punto de montaje compartido

Para que los directorios /media y /mnt compartan el mismo contenido:

  1. Cree un nodo VFS desde el directorio /media: 

    # mount --bind /media /media
    Copy to Clipboard

  2. Marque el directorio /media como compartido: 

    # mount --make-shared /media
    Copy to Clipboard

  3. Cree su duplicado en /mnt: 

    # mount --bind /media /mnt
    Copy to Clipboard

  4. Ahora es posible verificar que un montaje dentro de /media también aparece en /mnt. Por ejemplo, si la unidad de CD-ROM contiene medios no vacíos y el directorio /media/cdrom/ existe, utilice 

    # mount /dev/cdrom /media/cdrom
# ls /media/cdrom
EFI  GPL  isolinux  LiveOS
# ls /mnt/cdrom
EFI  GPL  isolinux  LiveOS
    Copy to Clipboard

  5. Del mismo modo, es posible comprobar que cualquier sistema de archivos montado en el directorio /mnt se refleja en /media. Por ejemplo, si se conecta una unidad flash USB no vacía que utiliza el dispositivo /dev/sdc1 y el directorio /mnt/flashdisk/ está presente, utilice: 

    # mount /dev/sdc1 /mnt/flashdisk
# ls /media/flashdisk
en-US  publican.cfg
# ls /mnt/flashdisk
en-US  publican.cfg
    Copy to Clipboard

Recursos adicionales

  • La página de manual mount(8).

14.7.4. Creación de un duplicado de punto de montaje esclavo

Este procedimiento duplica un punto de montaje como un montaje esclavo. Los sistemas de archivos que se monten posteriormente bajo el punto de montaje original se reflejan en el duplicado, pero no al revés.

Procedimiento

  1. Cree un nodo de sistema de archivos virtual (VFS) a partir del punto de montaje original: 

    # mount --bind original-dir original-dir
    Copy to Clipboard

  2. Marcar el punto de montaje original como compartido: 

    # mount --make-shared original-dir
    Copy to Clipboard

    Alternativamente, para cambiar el tipo de montaje para el punto de montaje seleccionado y todos los puntos de montaje bajo él, utilice la opción --make-rshared en lugar de --make-shared.

  3. Crea el duplicado y márcalo como esclavo: 

    # mount --bind original-dir duplicate-dir
# mount --make-slave duplicate-dir
    Copy to Clipboard

Ejemplo 14.7. Duplicación de /media en /mnt como punto de montaje esclavo

Este ejemplo muestra cómo conseguir que el contenido del directorio /media aparezca también en /mnt, pero sin que ningún montaje del directorio /mnt se refleje en /media.

  1. Cree un nodo VFS desde el directorio /media: 

    # mount --bind /media /media
    Copy to Clipboard

  2. Marque el directorio /media como compartido: 

    # mount --make-shared /media
    Copy to Clipboard

  3. Cree su duplicado en /mnt y márquelo como esclavo: 

    # mount --bind /media /mnt
# mount --make-slave /mnt
    Copy to Clipboard

  4. Compruebe que un montaje dentro de /media también aparece en /mnt. Por ejemplo, si la unidad de CD-ROM contiene medios no vacíos y el directorio /media/cdrom/ existe, utilice: 

    # mount /dev/cdrom /media/cdrom
# ls /media/cdrom
EFI  GPL  isolinux  LiveOS
# ls /mnt/cdrom
EFI  GPL  isolinux  LiveOS
    Copy to Clipboard

  5. Compruebe también que los sistemas de archivos montados en el directorio /mnt no se reflejan en /media. Por ejemplo, si se conecta una unidad flash USB no vacía que utiliza el dispositivo /dev/sdc1 y el directorio /mnt/flashdisk/ está presente, utilice: 

    # mount /dev/sdc1 /mnt/flashdisk
# ls /media/flashdisk
# ls /mnt/flashdisk
en-US  publican.cfg
    Copy to Clipboard

Recursos adicionales

  • La página de manual mount(8).

14.7.5. Evitar que un punto de montaje se duplique

Este procedimiento marca un punto de montaje como no vinculable para que no sea posible duplicarlo en otro punto de montaje.

Procedimiento

  • Para cambiar el tipo de un punto de montaje a un montaje no vinculable, utilice 

    # mount --bind mount-point mount-point
# mount --make-unbindable mount-point
    Copy to Clipboard

    Alternativamente, para cambiar el tipo de montaje para el punto de montaje seleccionado y todos los puntos de montaje bajo él, utilice la opción --make-runbindable en lugar de --make-unbindable.

    Cualquier intento posterior de hacer un duplicado de este montaje falla con el siguiente error: 

    # mount --bind mount-point duplicate-dir

mount: wrong fs type, bad option, bad superblock on mount-point,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail  or so
    Copy to Clipboard

Ejemplo 14.8. Evitar la duplicación de /media

  • Para evitar que el directorio /media sea compartido, utilice: 

    # mount --bind /media /media
# mount --make-unbindable /media
    Copy to Clipboard

Recursos adicionales

  • La página de manual mount(8).

14.8. Montaje persistente de sistemas de archivos

Como administrador del sistema, puede montar de forma persistente sistemas de archivos para configurar el almacenamiento no extraíble.

14.8.1. El archivo /etc/fstab

Esta sección describe el archivo de configuración /etc/fstab, que controla los puntos de montaje persistentes de los sistemas de archivos. El uso de /etc/fstab es la forma recomendada para montar de forma persistente los sistemas de archivos.

Cada línea del archivo /etc/fstab define un punto de montaje de un sistema de archivos. Incluye seis campos separados por espacios en blanco:

  1. El dispositivo de bloque identificado por un atributo persistente o una ruta en el directorio /dev.
  2. El directorio donde se montará el dispositivo.
  3. El sistema de archivos del dispositivo.
  4. Opciones de montaje para el sistema de archivos. La opción defaults significa que la partición se monta en el momento del arranque con las opciones por defecto. Esta sección también reconoce las opciones de la unidad de montaje systemd en el formato x-systemd.option formato.
  5. Opción de copia de seguridad para la utilidad dump.
  6. Orden de comprobación de la utilidad fsck.

Ejemplo 14.9. El sistema de archivos /boot en /etc/fstab

Dispositivo en bloquePunto de montajeSistema de archivosOpcionesCopia de seguridadConsulte

UUID=ea74bbec-536d-490c-b8d9-5b40bbd7545b

/boot

xfs

defaults

0

0

El servicio systemd genera automáticamente unidades de montaje a partir de las entradas en /etc/fstab.

Recursos adicionales

  • La página de manual fstab(5).
  • La sección fstab de la página de manual systemd.mount(5).

14.8.2. Añadir un sistema de archivos a /etc/fstab

Este procedimiento describe cómo configurar el punto de montaje persistente para un sistema de archivos en el archivo de configuración /etc/fstab.

Procedimiento

  1. Averigua el atributo UUID del sistema de archivos: 

    $ lsblk --fs storage-device
    Copy to Clipboard

    Por ejemplo:

    Ejemplo 14.10. Ver el UUID de una partición

    $ lsblk --fs /dev/sda1

NAME FSTYPE LABEL UUID                                 MOUNTPOINT
sda1 xfs    Boot  ea74bbec-536d-490c-b8d9-5b40bbd7545b /boot
    Copy to Clipboard

  2. Si el directorio del punto de montaje no existe, créelo: 

    # mkdir --parents mount-point
    Copy to Clipboard

  3. Como root, edite el archivo /etc/fstab y añada una línea para el sistema de archivos, identificado por el UUID.

    Por ejemplo:

    Ejemplo 14.11. El punto de montaje /boot en /etc/fstab

    UUID=ea74bbec-536d-490c-b8d9-5b40bbd7545b /boot xfs defaults 0 0
    Copy to Clipboard

  4. Regenere las unidades de montaje para que su sistema registre la nueva configuración: 

    # systemctl daemon-reload
    Copy to Clipboard

  5. Intente montar el sistema de archivos para verificar que la configuración funciona: 

    # montaje mount-point
    Copy to Clipboard

Recursos adicionales

14.8.3. Montaje persistente de un sistema de archivos con RHEL System Roles

Esta sección describe cómo montar persistentemente un sistema de archivos utilizando el rol storage.

Requisitos previos

  • Existe un playbook de Ansible que utiliza el rol storage.

    Para obtener información sobre cómo aplicar un libro de jugadas de este tipo, consulte Aplicar un rol.

14.8.3.1. Ejemplo de playbook de Ansible para montar persistentemente un sistema de archivos

Esta sección proporciona un ejemplo de libro de jugadas de Ansible. Este libro de jugadas aplica el rol storage para montar de forma inmediata y persistente un sistema de archivos XFS.

Ejemplo 14.12. Un playbook que monta un sistema de archivos en /dev/sdb a /mnt/data

---
- hosts: all
  vars:
    storage_volumes:
      - name: barefs
        type: disk
        disks:
          - sdb
        fs_type: xfs
        mount_point: /mnt/data
  roles:
    - rhel-system-roles.storage
Copy to Clipboard
  • Este libro de jugadas añade el sistema de archivos al archivo /etc/fstab, y monta el sistema de archivos inmediatamente.
  • Si el sistema de archivos del dispositivo /dev/sdb o el directorio del punto de montaje no existen, el libro de jugadas los crea.

Recursos adicionales

  • Para más detalles sobre los parámetros utilizados en el rol de sistema storage, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.storage/README.md.
14.8.3.2. Recursos adicionales

14.9. Montaje de sistemas de archivos bajo demanda

Como administrador del sistema, puede configurar los sistemas de archivos, como NFS, para que se monten automáticamente bajo demanda.

14.9.1. El servicio autofs

Esta sección explica las ventajas y los conceptos básicos del servicio autofs, utilizado para montar sistemas de archivos bajo demanda.

Una desventaja del montaje permanente utilizando la configuración /etc/fstab es que, independientemente de la poca frecuencia con la que un usuario acceda al sistema de archivos montado, el sistema debe dedicar recursos para mantener el sistema de archivos montado en su lugar. Esto puede afectar al rendimiento del sistema cuando, por ejemplo, el sistema está manteniendo montajes NFS en muchos sistemas a la vez.

Una alternativa a /etc/fstab es utilizar el servicio autofs basado en el núcleo. Consta de los siguientes componentes:

  • Un módulo del kernel que implementa un sistema de archivos, y
  • Un servicio de espacio de usuario que realiza todas las demás funciones.

El servicio autofs puede montar y desmontar sistemas de archivos automáticamente (bajo demanda), ahorrando así recursos del sistema. Puede utilizarse para montar sistemas de archivos como NFS, AFS, SMBFS, CIFS y sistemas de archivos locales.

Recursos adicionales

  • La página de manual autofs(8).

14.9.2. Los archivos de configuración de autofs

Esta sección describe el uso y la sintaxis de los archivos de configuración utilizados por el servicio autofs.

El archivo de mapa maestro

El servicio autofs utiliza /etc/auto.master (mapa maestro) como su archivo de configuración principal por defecto. Esto puede cambiarse para usar otra fuente de red y nombre soportados usando la configuración autofs en el archivo de configuración /etc/autofs.conf en conjunto con el mecanismo Name Service Switch (NSS).

Todos los puntos de montaje bajo demanda deben ser configurados en el mapa maestro. El punto de montaje, el nombre del host, el directorio exportado y las opciones pueden especificarse en un conjunto de archivos (u otras fuentes de red compatibles) en lugar de configurarlos manualmente para cada host.

El archivo de mapa maestro enumera los puntos de montaje controlados por autofs, y sus correspondientes archivos de configuración o fuentes de red conocidos como mapas de automontaje. El formato del mapa maestro es el siguiente: 

mount-point  map-name  options
Copy to Clipboard

Las variables utilizadas en este formato son:

mount-point
El punto de montaje autofs; por ejemplo, /mnt/data/.
map-file
El archivo fuente del mapa, que contiene una lista de puntos de montaje y la ubicación del sistema de archivos desde la que se deben montar esos puntos de montaje.
options
Si se suministran, se aplican a todas las entradas del mapa dado, si no tienen ellas mismas opciones especificadas.

Ejemplo 14.13. El archivo /etc/auto.master

La siguiente es una línea de ejemplo del archivo /etc/auto.master: 

/mnt/data  /etc/auto.data
Copy to Clipboard
Archivos de mapas

Los archivos de mapa configuran las propiedades de los puntos de montaje individuales bajo demanda.

El contador automático crea los directorios si no existen. Si los directorios existen antes de que se inicie el contador automático, éste no los eliminará cuando salga. Si se especifica un tiempo de espera, el directorio se desmonta automáticamente si no se accede a él durante el periodo de tiempo de espera.

El formato general de los mapas es similar al del mapa maestro. Sin embargo, el campo de opciones aparece entre el punto de montaje y la ubicación en lugar de al final de la entrada como en el mapa maestro: 

mount-point  options  location
Copy to Clipboard

Las variables utilizadas en este formato son:

mount-point
Se refiere al punto de montaje de autofs. Puede ser un solo nombre de directorio para un montaje indirecto o la ruta completa del punto de montaje para montajes directos. Cada clave de entrada del mapa directo e indirecto (mount-point) puede ir seguida de una lista separada por espacios de directorios de desplazamiento (nombres de subdirectorios que comienzan cada uno con /), lo que se conoce como una entrada de montaje múltiple.
options
Cuando se suministran, son las opciones de montaje para las entradas del mapa que no especifican sus propias opciones. Este campo es opcional.
location
Se refiere a la ubicación del sistema de archivos, como una ruta del sistema de archivos local (precedida por el carácter de escape del formato de mapa de Sun : para los nombres de mapa que comienzan con /), un sistema de archivos NFS u otra ubicación válida del sistema de archivos.

Ejemplo 14.14. Un archivo de mapas

A continuación se muestra un ejemplo de un archivo de mapas; por ejemplo, /etc/auto.misc: 

payroll  -fstype=nfs4  personnel:/dev/disk/by-uuid/52b94495-e106-4f29-b868-fe6f6c2789b1
sales    -fstype=xfs   :/dev/disk/by-uuid/5564ed00-6aac-4406-bfb4-c59bf5de48b5
Copy to Clipboard

La primera columna del archivo de mapa indica el punto de montaje autofs: sales y payroll del servidor llamado personnel. La segunda columna indica las opciones para el montaje de autofs. La tercera columna indica el origen del montaje.

Siguiendo la configuración dada, los puntos de montaje autofs serán /home/payroll y /home/sales. La opción -fstype= suele omitirse y, por lo general, no es necesaria para su correcto funcionamiento.

Usando la configuración dada, si un proceso requiere acceso a un directorio no montado de autofs como /home/payroll/2006/July.sxc, el servicio autofs monta automáticamente el directorio.

El formato del mapa amd

El servicio autofs reconoce la configuración de mapas en el formato amd también. Esto es útil si desea reutilizar la configuración existente del contador automático escrita para el servicio am-utils, que ha sido eliminado de Red Hat Enterprise Linux.

Sin embargo, Red Hat recomienda utilizar el formato más sencillo autofs descrito en las secciones anteriores.

Recursos adicionales

  • Las páginas de manual autofs(5), autofs.conf(5), y auto.master(5).
  • Para más detalles sobre el formato del mapa amd, véase el archivo /usr/share/doc/autofs/README.amd-maps, que proporciona el paquete autofs.

14.9.3. Configuración de puntos de montaje autofs

Este procedimiento describe cómo configurar puntos de montaje bajo demanda utilizando el servicio autofs.

Requisitos previos

  • Instale el paquete autofs: 

    # yum install autofs
    Copy to Clipboard

  • Inicie y active el servicio autofs: 

    # systemctl enable --now autofs
    Copy to Clipboard

Procedimiento

  1. Crear un archivo de mapa para el punto de montaje bajo demanda, ubicado en /etc/auto.identifier. Sustituya identifier con un nombre que identifique el punto de montaje.
  2. En el archivo de mapa, rellene los campos de punto de montaje, opciones y ubicación como se describe en Sección 14.9.2, “Los archivos de configuración de autofs”.
  3. Registre el archivo de mapas en el archivo de mapas maestro, como se describe en Sección 14.9.2, “Los archivos de configuración de autofs”.

  4. Intenta acceder al contenido del directorio a la carta: 

    $ ls automounted-directory
    Copy to Clipboard

14.9.4. Automatización de los directorios de usuario del servidor NFS con el servicio autofs

Este procedimiento describe cómo configurar el servicio autofs para que monte automáticamente los directorios personales de los usuarios.

Requisitos previos

  • El paquete autofs paquete está instalado.
  • El servicio autofs servicio está habilitado y funcionando.

Procedimiento

  1. Especifique el punto de montaje y la ubicación del archivo de mapa editando el archivo /etc/auto.master en un servidor en el que necesite montar los directorios personales de los usuarios. Para ello, añada la siguiente línea en el archivo /etc/auto.master: 

    /home /etc/auto.home
    Copy to Clipboard

  2. Cree un archivo de mapa con el nombre de /etc/auto.home en un servidor en el que necesite montar los directorios personales de los usuarios, y edite el archivo con los siguientes parámetros: 

    * -fstype=nfs,rw,sync host.example.com:/home/&i
    Copy to Clipboard

    Puede omitir el parámetro fstype parámetro, ya que es nfs por defecto. Para más información, consulte la página de manual autofs(5).

  3. Recargue el servicio autofs: 

    # systemctl reload autofs
    Copy to Clipboard

14.9.5. Anulación o aumento de los archivos de configuración del sitio autofs

A veces es útil anular los valores predeterminados del sitio para un punto de montaje específico en un sistema cliente.

Ejemplo 14.15. Condiciones iniciales

Por ejemplo, considere las siguientes condiciones:

  • Los mapas del contador automático se almacenan en NIS y el archivo /etc/nsswitch.conf tiene la siguiente directiva: 

    automount:    files nis
    Copy to Clipboard

  • El archivo auto.master contiene: 

     auto.master
    Copy to Clipboard

  • El archivo de mapas NIS auto.master contiene: 

    /home auto.home
    Copy to Clipboard

  • El mapa NIS auto.home contiene: 

    beth    fileserver.example.com:/export/home/beth
joe     fileserver.example.com:/export/home/joe
*       fileserver.example.com:/export/home/&
    Copy to Clipboard
  • El mapa de archivos /etc/auto.home no existe.

Ejemplo 14.16. Montaje de directorios personales desde un servidor diferente

Dadas las condiciones anteriores, supongamos que el sistema cliente necesita anular el mapa NIS auto.home y montar los directorios iniciales desde un servidor diferente.

  • En este caso, el cliente debe utilizar el siguiente mapa /etc/auto.master: 

    /home ­/etc/auto.home
+auto.master
    Copy to Clipboard

  • El mapa /etc/auto.home contiene la entrada: 

    *    host.example.com:/export/home/&
    Copy to Clipboard

Como el contador automático sólo procesa la primera aparición de un punto de montaje, el directorio /home contiene el contenido de /etc/auto.home en lugar del mapa NIS auto.home.

Ejemplo 14.17. Aumentar auto.home sólo con las entradas seleccionadas

O bien, para aumentar el mapa de todo el sitio auto.home con sólo unas pocas entradas:

  1. Cree un mapa de archivos /etc/auto.home, y en él ponga las nuevas entradas. Al final, incluya el mapa NIS auto.home. Entonces el mapa de archivos /etc/auto.home tiene un aspecto similar: 

    mydir someserver:/export/mydir
+auto.home
    Copy to Clipboard

  2. Con estas condiciones del mapa NIS auto.home, el listado del contenido de las salidas del directorio /home: 

    $ ls /home

beth joe mydir
    Copy to Clipboard

Este último ejemplo funciona como se esperaba porque autofs no incluye el contenido de un mapa de archivos del mismo nombre que el que está leyendo. Así, autofs pasa a la siguiente fuente de mapas en la configuración de nsswitch.

14.9.6. Uso de LDAP para almacenar mapas de contadores automáticos

Este procedimiento configura autofs para almacenar los mapas del contador automático en la configuración LDAP en lugar de en los archivos de mapas de autofs.

Requisitos previos

  • Las bibliotecas de cliente LDAP deben instalarse en todos los sistemas configurados para recuperar mapas de contadores automáticos desde LDAP. En Red Hat Enterprise Linux, el paquete openldap debería instalarse automáticamente como dependencia del paquete autofs.

Procedimiento

  1. Para configurar el acceso LDAP, modifique el archivo /etc/openldap/ldap.conf. Asegúrese de que las opciones BASE, URI, y schema están configuradas adecuadamente para su sitio.

  2. El esquema más recientemente establecido para el almacenamiento de mapas automáticos en LDAP se describe en el borrador rfc2307bis. Para utilizar este esquema, establézcalo en el archivo de configuración /etc/autofs.conf eliminando los caracteres de comentario de la definición del esquema. Por ejemplo:

    Ejemplo 14.18. Establecer la configuración de autofs

    DEFAULT_MAP_OBJECT_CLASS="automountMap"
DEFAULT_ENTRY_OBJECT_CLASS="automount"
DEFAULT_MAP_ATTRIBUTE="automountMapName"
DEFAULT_ENTRY_ATTRIBUTE="automountKey"
DEFAULT_VALUE_ATTRIBUTE="automountInformation"
    Copy to Clipboard

  3. Asegúrese de que todas las demás entradas del esquema están comentadas en la configuración. El atributo automountKey sustituye al atributo cn en el esquema rfc2307bis. A continuación se muestra un ejemplo de configuración del formato de intercambio de datos LDAP (LDIF):

    Ejemplo 14.19. Configuración de la LDF

    # extended LDIF
#
# LDAPv3
# base <> with scope subtree
# filter: (&(objectclass=automountMap)(automountMapName=auto.master))
# requesting: ALL
#

# auto.master, example.com
dn: automountMapName=auto.master,dc=example,dc=com
objectClass: top
objectClass: automountMap
automountMapName: auto.master

# extended LDIF
#
# LDAPv3
# base <automountMapName=auto.master,dc=example,dc=com> with scope subtree
# filter: (objectclass=automount)
# requesting: ALL
#

# /home, auto.master, example.com
dn: automountMapName=auto.master,dc=example,dc=com
objectClass: automount
cn: /home

automountKey: /home
automountInformation: auto.home

# extended LDIF
#
# LDAPv3
# base <> with scope subtree
# filter: (&(objectclass=automountMap)(automountMapName=auto.home))
# requesting: ALL
#

# auto.home, example.com
dn: automountMapName=auto.home,dc=example,dc=com
objectClass: automountMap
automountMapName: auto.home

# extended LDIF
#
# LDAPv3
# base <automountMapName=auto.home,dc=example,dc=com> with scope subtree
# filter: (objectclass=automount)
# requesting: ALL
#

# foo, auto.home, example.com
dn: automountKey=foo,automountMapName=auto.home,dc=example,dc=com
objectClass: automount
automountKey: foo
automountInformation: filer.example.com:/export/foo

# /, auto.home, example.com
dn: automountKey=/,automountMapName=auto.home,dc=example,dc=com
objectClass: automount
automountKey: /
automountInformation: filer.example.com:/export/&
    Copy to Clipboard

Recursos adicionales

14.10. Establecer permisos de sólo lectura para el sistema de archivos raíz

A veces, es necesario montar el sistema de archivos raíz (/) con permisos de sólo lectura. Algunos ejemplos de uso incluyen la mejora de la seguridad o la garantía de la integridad de los datos después de un apagado inesperado del sistema.

14.10.1. Archivos y directorios que siempre conservan los permisos de escritura

Para que el sistema funcione correctamente, algunos archivos y directorios deben conservar los permisos de escritura. Cuando el sistema de archivos raíz se monta en modo de sólo lectura, estos archivos se montan en la memoria RAM utilizando el sistema de archivos temporales tmpfs.

El conjunto por defecto de estos archivos y directorios se lee del archivo /etc/rwtab, que contiene: 

dirs	/var/cache/man
dirs	/var/gdm
<content truncated>

empty	/tmp
empty	/var/cache/foomatic
<content truncated>

files	/etc/adjtime
files	/etc/ntp.conf
<content truncated>
Copy to Clipboard

Las entradas en el archivo /etc/rwtab siguen este formato: 

copy-method    path
Copy to Clipboard

En esta sintaxis:

  • Sustituya copy-method con una de las palabras clave que especifican cómo se copia el archivo o directorio en tmpfs.
  • Sustituya path por la ruta del archivo o directorio.

El archivo /etc/rwtab reconoce las siguientes formas de copiar un archivo o directorio en tmpfs:

empty

Una ruta vacía se copia en tmpfs. Por ejemplo: 

vaciar /tmp
Copy to Clipboard
dirs

Se copia un árbol de directorios en tmpfs, vacío. Por ejemplo: 

dirs /var/run
Copy to Clipboard
files

Un archivo o un árbol de directorios se copia en tmpfs intacto. Por ejemplo: 

archivos /etc/resolv.conf
Copy to Clipboard

El mismo formato se aplica al añadir rutas personalizadas a /etc/rwtab.d/.

14.10.2. Configurar el sistema de archivos raíz para que se monte con permisos de sólo lectura en el arranque

Con este procedimiento, el sistema de archivos raíz se monta de sólo lectura en todos los siguientes arranques.

Procedimiento

  1. En el archivo /etc/sysconfig/readonly-root, establezca la opción READONLY como yes: 

    # Set to 'yes' to mount the file systems as read-only.
READONLY=yes
    Copy to Clipboard

  2. Añada la opción ro en la entrada raíz (/) en el archivo /etc/fstab: 

    /dev/mapper/luks-c376919e...  /  xfs  x-systemd.device-timeout=0,ro  1  1
    Copy to Clipboard

  3. Añada la opción ro a la directiva GRUB_CMDLINE_LINUX en el archivo /etc/default/grub y asegúrese de que la directiva no contenga rw: 

    GRUB_CMDLINE_LINUX="rhgb quiet... ro"
    Copy to Clipboard

  4. Vuelva a crear el archivo de configuración de GRUB2: 

    # grub2-mkconfig -o /boot/grub2/grub.cfg
    Copy to Clipboard

  5. Si necesita añadir archivos y directorios para que se monten con permisos de escritura en el sistema de archivos tmpfs, cree un archivo de texto en el directorio /etc/rwtab.d/ y ponga la configuración allí.

    Por ejemplo, para montar el archivo /etc/example/file con permisos de escritura, añada esta línea al archivo /etc/rwtab.d/example: 

    archivos /etc/ejemplo/archivo
    Copy to Clipboard
    Importante

    Los cambios realizados en los archivos y directorios en tmpfs no persisten entre los arranques.

  6. Reinicie el sistema para aplicar los cambios.

Solución de problemas

  • Si monta el sistema de archivos raíz con permisos de sólo lectura por error, puede volver a montarlo con permisos de lectura y escritura utilizando el siguiente comando: 

    # mount -o remount,rw /
    Copy to Clipboard

Capítulo 15. Limitar el uso del espacio de almacenamiento con cuotas

Puedes restringir la cantidad de espacio en disco disponible para usuarios o grupos implementando cuotas de disco. También puede definir un nivel de advertencia en el que se informe a los administradores del sistema antes de que un usuario consuma demasiado espacio en disco o una partición se llene.

15.1. Cuotas de disco

En la mayoría de los entornos informáticos, el espacio en disco no es infinito. El subsistema de cuotas proporciona un mecanismo para controlar el uso del espacio en disco.

Puedes configurar cuotas de disco para usuarios individuales así como para grupos de usuarios en los sistemas de archivos locales. Esto permite gestionar el espacio asignado a los archivos específicos de los usuarios (como el correo electrónico) por separado del espacio asignado a los proyectos en los que trabaja un usuario. El subsistema de cuotas avisa a los usuarios cuando superan su límite asignado, pero permite algo de espacio extra para el trabajo actual (límite duro/límite blando).

Si se implementan cuotas, es necesario comprobar si se superan las cuotas y asegurarse de que éstas son correctas. Si los usuarios superan repetidamente sus cuotas o alcanzan constantemente sus límites blandos, un administrador del sistema puede ayudar al usuario a determinar cómo utilizar menos espacio en disco o aumentar la cuota de disco del usuario.

Puedes establecer cuotas para controlar:

  • El número de bloques de disco consumidos.
  • El número de inodos, que son estructuras de datos que contienen información sobre los archivos en los sistemas de archivos UNIX. Como los inodos almacenan información relacionada con los archivos, esto permite controlar el número de archivos que se pueden crear.

15.1.1. La herramienta xfs_quota

Puede utilizar la herramienta xfs_quota para gestionar las cuotas en los sistemas de archivos XFS. Además, puede utilizar los sistemas de archivos XFS con la aplicación de límites desactivada como un sistema eficaz de contabilidad del uso del disco.

El sistema de cuotas XFS se diferencia de otros sistemas de archivos en varios aspectos. Lo más importante es que XFS considera la información de cuotas como metadatos del sistema de archivos y utiliza el registro en el diario para proporcionar una garantía de consistencia de mayor nivel.

Recursos adicionales
  • La página de manual xfs_quota(8).

15.2. Gestión de cuotas de disco XFS

Puede utilizar la herramienta xfs_quota para gestionar las cuotas en XFS y para configurar los límites de los directorios controlados por el proyecto.

Las herramientas genéricas de configuración de cuotas (quota, repquota, y edquota por ejemplo) también pueden utilizarse para manipular las cuotas XFS. Sin embargo, estas herramientas no pueden utilizarse con las cuotas del proyecto XFS.

Importante

Red Hat recomienda el uso de xfs_quota sobre todas las demás herramientas disponibles.

15.2.1. Gestión de cuotas del sistema de archivos en XFS

El subsistema de cuotas XFS gestiona los límites de uso del espacio en disco (bloques) y de los archivos (inodos). Las cuotas XFS controlan o informan sobre el uso de estos elementos a nivel de usuario, grupo, directorio o proyecto. Las cuotas de grupo y de proyecto sólo se excluyen mutuamente en los formatos de disco XFS no predeterminados.

Cuando se gestiona por directorio o por proyecto, XFS gestiona el uso del disco de las jerarquías de directorios asociadas a un proyecto específico.

15.2.2. Activación de cuotas de disco para XFS

Este procedimiento habilita las cuotas de disco para usuarios, grupos y proyectos en un sistema de archivos XFS. Una vez habilitadas las cuotas, se puede utilizar la herramienta xfs_quota para establecer límites e informar sobre el uso del disco.

Procedimiento

  1. Habilitar cuotas para los usuarios: 

    # mount -o uquota /dev/xvdb1 /xfs
    Copy to Clipboard

    Sustituya uquota por uqnoenforce para permitir la presentación de informes de uso sin imponer ningún límite.

  2. Habilitar las cuotas para los grupos: 

    # mount -o gquota /dev/xvdb1 /xfs
    Copy to Clipboard

    Sustituya gquota por gqnoenforce para permitir la presentación de informes de uso sin imponer ningún límite.

  3. Activar las cuotas de los proyectos: 

    # mount -o pquota /dev/xvdb1 /xfs
    Copy to Clipboard

    Sustituya pquota por pqnoenforce para permitir la presentación de informes de uso sin imponer ningún límite.

  4. Como alternativa, incluya las opciones de montaje de cuotas en el archivo /etc/fstab. El siguiente ejemplo muestra entradas en el archivo /etc/fstab para habilitar cuotas para usuarios, grupos y proyectos, respectivamente, en un sistema de archivos XFS. Estos ejemplos también montan el sistema de archivos con permisos de lectura/escritura: 

    # vim /etc/fstab
/dev/xvdb1    /xfs    xfs    rw,quota       0  0
/dev/xvdb1    /xfs    xfs    rw,gquota      0  0
/dev/xvdb1    /xfs    xfs    rw,prjquota    0  0
    Copy to Clipboard

    Recursos adicionales

    • La página de manual mount(8).
    • La página de manual xfs_quota(8).

15.2.3. Informar sobre el uso de XFS

Puede utilizar la herramienta xfs_quota para establecer límites e informar sobre el uso del disco. Por defecto, xfs_quota se ejecuta de forma interactiva y en modo básico. Los subcomandos del modo básico simplemente informan del uso, y están disponibles para todos los usuarios.

Requisitos previos
Procedimiento

  1. Inicie el shell xfs_quota: 

    # xfs_quota
    Copy to Clipboard

  2. Muestra el uso y los límites del usuario dado: 

    # xfs_quota> quota username
    Copy to Clipboard

  3. Muestra los recuentos de bloques e inodos libres y utilizados: 

    # xfs_quota> df
    Copy to Clipboard

  4. Ejecute el comando de ayuda para mostrar los comandos básicos disponibles con xfs_quota. 

    # xfs_quota> help
    Copy to Clipboard

  5. Especifique q para salir de xfs_quota. 

    # xfs_quota> q
    Copy to Clipboard
Recursos adicionales
  • La página de manual xfs_quota(8).

15.2.4. Modificación de los límites de cuota XFS

Inicie la herramienta xfs_quota con la opción -x para activar el modo experto y ejecutar los comandos de administrador, que permiten modificar el sistema de cuotas. Los subcomandos de este modo permiten la configuración real de los límites, y sólo están disponibles para los usuarios con privilegios elevados.

Requisitos previos
Procedimiento

  1. Inicie el shell xfs_quota con la opción -x para activar el modo experto: 

    # xfs_quota -x
    Copy to Clipboard

  2. Informar sobre la cuota de un sistema de archivos específico: 

    # xfs_quota> informe /path
    Copy to Clipboard

    Por ejemplo, para mostrar un ejemplo de informe de cuotas para /home (en /dev/blockdevice), utilice el comando report -h /home. Esto muestra una salida similar a la siguiente: 

    User quota on /home (/dev/blockdevice)
Blocks
User ID      Used   Soft   Hard Warn/Grace
---------- ---------------------------------
root            0      0      0  00 [------]
testuser   103.4G      0      0  00 [------]
    Copy to Clipboard

  3. Modificar los límites de las cuotas: 

    # xfs_quota> limit isoft=500m ihard=700m user /path
    Copy to Clipboard

    Por ejemplo, para establecer un límite de conteo de inodos suave y duro de 500 y 700 respectivamente para el usuario john, cuyo directorio raíz es /home/john, utilice el siguiente comando: 

    # xfs_quota -x -c 'limit isoft=500 ihard=700 john' /home/
    Copy to Clipboard

    En este caso, pase mount_point que es el sistema de archivos xfs montado.

  4. Ejecute el comando de ayuda para mostrar los comandos expertos disponibles con xfs_quota -x: 

    # xfs_quota> help
    Copy to Clipboard
    Recursos adicionales
    • La página de manual xfs_quota(8).

15.2.5. Establecer los límites del proyecto para XFS

Este procedimiento configura los límites de los directorios controlados por el proyecto.

Procedimiento

  1. Añade los directorios controlados por el proyecto a /etc/projects. Por ejemplo, lo siguiente añade la ruta /var/log con un ID único de 11 a /etc/projects. Su ID de proyecto puede ser cualquier valor numérico asignado a su proyecto. 

    # echo 11:/var/log >> /etc/projects
    Copy to Clipboard

  2. Añada los nombres de los proyectos a /etc/projid para asignar los ID de los proyectos a los nombres de los mismos. Por ejemplo, lo siguiente asocia un proyecto llamado Logs con el ID de proyecto 11 definido en el paso anterior. 

    # echo Logs:11 >> /etc/projid
    Copy to Clipboard

  3. Inicialice el directorio del proyecto. Por ejemplo, lo siguiente inicializa el directorio del proyecto /var: 

    # xfs_quota -x -c 'project -s logfiles' /var
    Copy to Clipboard

  4. Configurar cuotas para proyectos con directorios inicializados: 

    # xfs_quota -x -c 'limit -p bhard=lg logfiles' /var
    Copy to Clipboard
    Recursos adicionales
    • La página de manual xfs_quota(8).
    • La página de manual projid(5).
    • La página de manual projects(5).

15.3. Gestión de cuotas de disco ext3 y ext4

Tienes que habilitar las cuotas de disco en tu sistema antes de poder asignarlas. Puedes asignar cuotas de disco por usuario, por grupo o por proyecto. Sin embargo, si hay un límite blando establecido, puedes superar estas cuotas durante un periodo de tiempo configurable, conocido como periodo de gracia.

15.3.1. Instalación de la herramienta de cuotas

Debe instalar el paquete RPM quota para implementar las cuotas de disco.

Procedimiento

  • Instale el paquete quota: 
# yum install quota
Copy to Clipboard

15.3.2. Habilitación de la función de cuotas en la creación de sistemas de archivos

Este procedimiento describe cómo activar las cuotas en la creación de sistemas de archivos.

Procedimiento

  1. Habilitar cuotas en la creación de sistemas de archivos: 

    # mkfs.ext4 -O quota /dev/sda
    Copy to Clipboard
    Nota

    Sólo las cuotas de usuario y de grupo están habilitadas e inicializadas por defecto.

  2. Cambiar los valores por defecto en la creación del sistema de archivos: 

    # mkfs.ext4 -O quota -E quotatype=usrquota:grpquota:prjquota /dev/sda
    Copy to Clipboard

  3. Montar el sistema de archivos: 

    # mount /dev/sda
    Copy to Clipboard

Recursos adicionales

Para más información, consulte la página man de ext4.

15.3.3. Activación de la función de cuotas en los sistemas de archivos existentes

Este procedimiento describe cómo habilitar la función de cuotas en un sistema de archivos existente mediante el comando tune2fs.

Procedimiento

  1. Desmontar el sistema de archivos: 

    # umount /dev/sda
    Copy to Clipboard

  2. Habilitar cuotas en el sistema de archivos existente: 

    # tune2fs -O quota /dev/sda
    Copy to Clipboard
    Nota

    Por defecto sólo se inicializan las cuotas de usuario y de grupo.

  3. Cambia los valores por defecto: 

    # tune2fs -Q usrquota,grpquota,prjquota /dev/sda
    Copy to Clipboard

  4. Montar el sistema de archivos: 

    # mount /dev/sda
    Copy to Clipboard

Recursos adicionales

Para más información, consulte la página man de ext4.

15.3.4. Habilitación de la aplicación de las cuotas

La contabilidad de cuotas se activa por defecto después de montar el sistema de archivos sin ninguna opción adicional, pero la aplicación de cuotas no.

Requisitos previos

  • La función de cuotas está activada y las cuotas por defecto están inicializadas.

Procedimiento

  • Activar la aplicación de la cuota por quotaon para la cuota de usuario: 

    # mount /dev/sda /mnt
    Copy to Clipboard 
    # quotaon /mnt
    Copy to Clipboard
    Nota

    La aplicación de la cuota se puede activar en el momento del montaje utilizando las opciones de montaje usrquota, grpquota, o prjquota. 

    # mount -o usrquota,grpquota,prjquota /dev/sda /mnt
    Copy to Clipboard

  • Habilite las cuotas de usuario, grupo y proyecto para todos los sistemas de archivos: 

    # quotaon -vaugP
    Copy to Clipboard
    • Si no se especifica ninguna de las opciones -u, -g, o -P, sólo se habilitan las cuotas de usuario.
    • Si sólo se especifica la opción -g, sólo se activan las cuotas de grupo.
    • Si sólo se especifica la opción -P, sólo se activan las cuotas del proyecto.

  • Habilitar cuotas para un sistema de archivos específico, como /home: 

    # quotaon -vugP /home
    Copy to Clipboard

Recursos adicionales

  • Consulte la página de manual quotaon(8).

15.3.5. Asignación de cuotas por usuario

Las cuotas de disco se asignan a los usuarios con el comando edquota.

Nota

El editor de texto definido por la variable de entorno EDITOR es utilizado por edquota. Para cambiar el editor, establezca la variable de entorno EDITOR en su archivo ~/.bash_profile con la ruta completa del editor de su elección.

Requisitos previos

  • El usuario debe existir antes de establecer la cuota de usuario.

Procedimiento

  1. Asigna la cuota de un usuario: 

    # edquota username
    Copy to Clipboard

    Sustituya username por el usuario al que desea asignar las cuotas.

    Por ejemplo, si habilita una cuota para la partición /dev/sda y ejecuta el comando edquota testuser, se muestra lo siguiente en el editor por defecto configurado en el sistema: 

    Disk quotas for user testuser (uid 501):
Filesystem   blocks   soft   hard   inodes   soft   hard
/dev/sda      44043      0      0    37418      0      0
    Copy to Clipboard

  2. Cambia los límites deseados.

    Si alguno de los valores está en 0, el límite no está establecido. Cámbielos en el editor de texto.

    Por ejemplo, a continuación se muestra que los límites de bloques blandos y duros para el usuario de prueba se han establecido en 50000 y 55000 respectivamente. 

    Disk quotas for user testuser (uid 501):
Filesystem   blocks   soft   hard   inodes   soft   hard
/dev/sda      44043  50000  55000    37418      0      0
    Copy to Clipboard
    • La primera columna es el nombre del sistema de archivos que tiene una cuota habilitada para él.
    • La segunda columna muestra el número de bloques que el usuario está utilizando actualmente.
    • Las siguientes dos columnas se utilizan para establecer los límites de bloques blandos y duros para el usuario en el sistema de archivos.
    • La columna inodes muestra cuántos inodos está utilizando el usuario actualmente.

    • Las dos últimas columnas se utilizan para establecer los límites de inodos blandos y duros para el usuario en el sistema de archivos.

      • El límite de bloques duros es la cantidad máxima absoluta de espacio en disco que un usuario o grupo puede utilizar. Una vez que se alcanza este límite, no se puede utilizar más espacio en disco.
      • El límite blando de bloques define la cantidad máxima de espacio en disco que se puede utilizar. Sin embargo, a diferencia del límite duro, el límite blando puede superarse durante un tiempo determinado. Ese tiempo se conoce como grace period. El periodo de gracia puede expresarse en segundos, minutos, horas, días, semanas o meses.

Pasos de verificación

  • Compruebe que se ha establecido la cuota para el usuario: 

    # quota -v testuser
Disk quotas for user testuser:
Filesystem  blocks  quota  limit  grace  files  quota  limit  grace
/dev/sda      1000*  1000   1000             0      0      0
    Copy to Clipboard

15.3.6. Asignación de cuotas por grupo

Se pueden asignar cuotas por grupo.

Requisitos previos

  • El grupo debe existir antes de establecer la cuota de grupo.

Procedimiento

  1. Establecer una cuota de grupo: 

    # edquota -g groupname
    Copy to Clipboard

    Por ejemplo, para establecer una cuota de grupo para el grupo devel: 

    # edquota -g devel
    Copy to Clipboard

    Este comando muestra la cuota existente para el grupo en el editor de texto: 

    Disk quotas for group devel (gid 505):
Filesystem   blocks  soft  hard  inodes  soft  hard
/dev/sda     440400     0     0   37418     0     0
    Copy to Clipboard
  2. Modifica los límites y guarda el archivo.

Pasos de verificación

  • Comprueba que la cuota de grupo está configurada: 

    # quota -vg groupname
    Copy to Clipboard

15.3.7. Asignación de cuotas por proyecto

Este procedimiento asigna cuotas por proyecto.

Requisitos previos

  • La cuota del proyecto está activada en su sistema de archivos.

Procedimiento

  1. Añade los directorios controlados por el proyecto a /etc/projects. Por ejemplo, lo siguiente añade la ruta /var/log con un ID único de 11 a /etc/projects. Su ID de proyecto puede ser cualquier valor numérico asignado a su proyecto. 

    # echo 11:/var/log >> /etc/projects
    Copy to Clipboard

  2. Añada los nombres de los proyectos a /etc/projid para asignar los ID de los proyectos a los nombres de los mismos. Por ejemplo, lo siguiente asocia un proyecto llamado Logs con el ID de proyecto 11 definido en el paso anterior. 

    # echo Logs:11 >> /etc/projid
    Copy to Clipboard

  3. Establezca los límites deseados: 

    # edquota -P 11
    Copy to Clipboard
    Nota

    Puede elegir el proyecto por su ID de proyecto (11 en este caso), o por su nombre (Logs en este caso).

  4. Utilizando quotaon, active la aplicación de cuotas:

    Véase Activar la aplicación de las cuotas.

Pasos de verificación

  • Compruebe que la cuota del proyecto está fijada: 

    # cuota -vP 11
    Copy to Clipboard
    Nota

    Puede verificar por el ID del proyecto, o por el nombre del proyecto.

Recursos adicionales

  • La página de manual edquota(8).
  • La página de manual projid(5).
  • La página de manual projects(5).

15.3.8. Fijación del período de gracia para los límites blandos

Si una cuota determinada tiene límites blandos, puede editar el periodo de gracia, que es el tiempo durante el cual se puede superar un límite blando. Puede establecer el periodo de gracia para usuarios, grupos o proyectos.

Procedimiento

  • Editar el periodo de gracia: 

    # edquota -t
    Copy to Clipboard
Importante

Mientras que otros comandos de edquota operan en las cuotas de un usuario, grupo o proyecto en particular, la opción -t opera en todos los sistemas de archivos con cuotas habilitadas.

Recursos adicionales

  • La página de manual edquota(8).

15.3.9. Desactivación de las cuotas del sistema de archivos

Utilice quotaoff para desactivar la aplicación de cuotas de disco en los sistemas de archivos especificados. La contabilidad de cuotas permanece activada después de ejecutar este comando.

Procedimiento

  • Para desactivar todas las cuotas de usuarios y grupos: 

    # quotaoff -vaugP
    Copy to Clipboard
    • Si no se especifica ninguna de las opciones -u, -g, o -P, sólo se desactivan las cuotas de usuario.
    • Si sólo se especifica la opción -g, sólo se desactivan las cuotas de grupo.
    • Si sólo se especifica la opción -P, sólo se desactivan las cuotas del proyecto.
    • El interruptor -v hace que se muestre información de estado verbosa mientras se ejecuta el comando.

Recursos adicionales

  • Consulte la página de manual quotaoff(8).

15.3.10. Informes sobre cuotas de disco

Puede crear un informe de cuota de disco utilizando la utilidad repquota.

Procedimiento

  1. Ejecute el comando repquota: 

    # repquota
    Copy to Clipboard

    Por ejemplo, el comando repquota /dev/sda produce esta salida: 

    *** Report for user quotas on device /dev/sda
Block grace time: 7days; Inode grace time: 7days
			Block limits			File limits
User		used	soft	hard	grace	used	soft	hard	grace
----------------------------------------------------------------------
root      --      36       0       0              4     0     0
kristin   --     540       0       0            125     0     0
testuser  --  440400  500000  550000          37418     0     0
    Copy to Clipboard

  2. Ver el informe de uso del disco para todos los sistemas de archivos con cuotas habilitadas: 

    # repquota -augP
    Copy to Clipboard

El símbolo -- que aparece después de cada usuario determina si se han superado los límites de bloque o de inodo. Si se supera cualquiera de los dos límites blandos, aparece un carácter en lugar del carácter correspondiente -. El primer carácter - representa el límite de bloque, y el segundo representa el límite de inodo.

Las columnas grace están normalmente en blanco. Si se ha superado un límite blando, la columna contiene una especificación de tiempo igual a la cantidad de tiempo que queda en el período de gracia. Si el periodo de gracia ha expirado, aparece none en su lugar.

Recursos adicionales

La página de manual repquota(8) para más información.

Capítulo 16. Descartar los bloques no utilizados

Puede realizar o programar operaciones de descarte en los dispositivos de bloque que las admitan.

16.1. Operaciones de descarte de bloques

Las operaciones de descarte de bloques descartan los bloques que ya no están en uso por un sistema de archivos montado. Son útiles en:

  • Unidades de estado sólido (SSD)
  • Almacenamiento con aprovisionamiento ligero
Requisitos

El dispositivo de bloque subyacente al sistema de archivos debe soportar operaciones de descarte físico.

Las operaciones de descarte físico se admiten si el valor del /sys/block/device/queue/discard_max_bytes es distinto de cero.

16.2. Tipos de operaciones de descarte de bloques

Se pueden ejecutar operaciones de descarte utilizando diferentes métodos:

Descarte de lotes
Son ejecutados explícitamente por el usuario. Descartan todos los bloques no utilizados en los sistemas de archivos seleccionados.
Descarte en línea
Se especifican en el momento del montaje. Se ejecutan en tiempo real sin intervención del usuario. Las operaciones de descarte en línea sólo descartan los bloques que están pasando de usados a libres.
Descarte periódico
Son operaciones por lotes que se ejecutan regularmente por un servicio de systemd.

Todos los tipos son compatibles con los sistemas de archivos XFS y ext4 y con VDO.

Recomendaciones

Red Hat recomienda utilizar el descarte por lotes o periódico.

Utilice el descarte en línea sólo si:

  • la carga de trabajo del sistema es tal que el descarte por lotes no es factible, o
  • las operaciones de descarte en línea son necesarias para mantener el rendimiento.

16.3. Realizar el descarte de bloques por lotes

Este procedimiento realiza una operación de descarte de bloques por lotes para descartar los bloques no utilizados en un sistema de archivos montado.

Requisitos previos

  • El sistema de archivos está montado.
  • El dispositivo de bloques subyacente al sistema de archivos admite operaciones de descarte físico.

Procedimiento

  • Utilice la utilidad fstrim:

    • Para realizar el descarte sólo en un sistema de archivos seleccionado, utilice: 

      # fstrim mount-point
      Copy to Clipboard

    • Para realizar el descarte en todos los sistemas de archivos montados, utilice: 

      # fstrim --all
      Copy to Clipboard

Si ejecuta el comando fstrim en:

  • un dispositivo que no admite operaciones de descarte, o
  • un dispositivo lógico (LVM o MD) compuesto por múltiples dispositivos, donde cualquiera de ellos no soporta operaciones de descarte,

aparece el siguiente mensaje: 

# fstrim /mnt/non_discard

fstrim: /mnt/non_discard: the discard operation is not supported
Copy to Clipboard

Recursos adicionales

  • La página de manual fstrim(8)

16.4. Activación del descarte de bloques en línea

Este procedimiento permite realizar operaciones de descarte de bloques en línea que descartan automáticamente los bloques no utilizados en todos los sistemas de archivos compatibles.

Procedimiento

  • Activar el descarte en línea en el momento del montaje:

    • Al montar un sistema de archivos manualmente, añada la opción de montaje -o discard: 

      # mount -o discard device mount-point
      Copy to Clipboard
    • Al montar un sistema de archivos de forma persistente, añada la opción discard a la entrada de montaje en el archivo /etc/fstab.

Recursos adicionales

  • La página de manual mount(8)
  • La página de manual fstab(5)

16.5. Habilitación del descarte de bloques en línea mediante RHEL System Roles

Esta sección describe cómo habilitar el descarte de bloques en línea utilizando el rol storage.

Requisitos previos

  • Existe un playbook de Ansible que incluye el rol storage.

Para obtener información sobre cómo aplicar un libro de jugadas de este tipo, consulte Aplicar un rol.

16.5.1. Ejemplo de libro de jugadas de Ansible para activar el descarte de bloques en línea

Esta sección proporciona un ejemplo de libro de jugadas de Ansible. Este libro de jugadas aplica el rol storage para montar un sistema de archivos XFS con el descarte de bloques en línea activado.

Ejemplo 16.1. Un libro de jugadas que permite descartar bloques en línea en /mnt/data/

---
- hosts: all
  vars:
    storage_volumes:
      - name: barefs
        type: disk
        disks:
          - sdb
        fs_type: xfs
        mount_point: /mnt/data
        mount_options: discard
  roles:
    - rhel-system-roles.storage
Copy to Clipboard

Recursos adicionales

  • Para más detalles sobre los parámetros utilizados en el rol de sistema storage, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.storage/README.md.

16.5.2. Recursos adicionales

16.6. Activación del descarte periódico de bloques

Este procedimiento habilita un temporizador systemd que descarta regularmente los bloques no utilizados en todos los sistemas de archivos compatibles.

Procedimiento

  • Activar e iniciar el temporizador systemd: 

    # systemctl enable --now fstrim.timer
    Copy to Clipboard

Capítulo 17. Gestión del almacenamiento local en capas con Stratis

Podrá configurar y gestionar fácilmente complejas configuraciones de almacenamiento integradas por el sistema de alto nivel Stratis.

Importante

Stratis está disponible como Technology Preview. Para obtener información sobre el alcance del soporte de Red Hat para las características de la Technology Preview, consulte el documento sobre el alcance del soporte de las características de la Technology Preview.

Se anima a los clientes que implanten Stratis a que envíen sus comentarios a Red Hat.

17.1. Configuración de los sistemas de archivos Stratis

Como administrador del sistema, puede habilitar y configurar el sistema de archivos de gestión de volumen Stratis en su sistema para gestionar fácilmente el almacenamiento en capas.

17.1.1. Objetivo y características de Stratis

Stratis es una solución de gestión de almacenamiento local para Linux. Se centra en la simplicidad y la facilidad de uso, y le da acceso a funciones de almacenamiento avanzadas.

Stratis facilita las siguientes actividades:

  • Configuración inicial del almacenamiento
  • Realización de cambios a posteriori
  • Uso de las funciones de almacenamiento avanzadas

Stratis es un sistema híbrido de gestión de almacenamiento local de usuario y de núcleo que admite funciones avanzadas de almacenamiento. El concepto central de Stratis es un pool de almacenamiento pool. Este pool se crea a partir de uno o más discos o particiones locales, y los volúmenes se crean a partir del pool.

La piscina permite muchas funciones útiles, como:

  • Instantáneas del sistema de archivos
  • Aprovisionamiento ligero
  • Nivelación

17.1.2. Componentes de un volumen Stratis

Externamente, Stratis presenta los siguientes componentes de volumen en la interfaz de línea de comandos y en la API:

blockdev
Dispositivos de bloque, como un disco o una partición de disco.
pool

Compuesto por uno o varios dispositivos en bloque.

Un pool tiene un tamaño total fijo, igual al tamaño de los dispositivos de bloque.

El pool contiene la mayoría de las capas de Stratis, como la caché de datos no volátil que utiliza el objetivo dm-cache.

Stratis crea un /stratis/my-pool/ directorio para cada pool. Este directorio contiene enlaces a dispositivos que representan sistemas de archivos Stratis en el pool.

filesystem

Cada pool puede contener uno o más sistemas de archivos, que almacenan archivos.

Los sistemas de archivos se aprovisionan de forma ligera y no tienen un tamaño total fijo. El tamaño real de un sistema de archivos crece con los datos almacenados en él. Si el tamaño de los datos se acerca al tamaño virtual del sistema de archivos, Stratis hace crecer el volumen delgado y el sistema de archivos automáticamente.

Los sistemas de archivos están formateados con XFS.

Importante

Stratis rastrea información sobre los sistemas de archivos creados con Stratis que XFS no conoce, y los cambios realizados con XFS no crean automáticamente actualizaciones en Stratis. Los usuarios no deben reformatear o reconfigurar los sistemas de archivos XFS que son administrados por Stratis.

Stratis crea enlaces a sistemas de archivos en la /stratis/my-pool/my-fs ruta de acceso.

Nota

Stratis utiliza muchos dispositivos Device Mapper, que aparecen en los listados de dmsetup y en el archivo /proc/partitions. Del mismo modo, la salida del comando lsblk refleja el funcionamiento interno y las capas de Stratis.

17.1.3. Dispositivos en bloque utilizables con Stratis

Esta sección enumera los dispositivos de almacenamiento que puede utilizar para Stratis.

Dispositivos compatibles

Las piscinas Stratis han sido probadas para funcionar en este tipo de dispositivos de bloque:

  • LUKS
  • Volúmenes lógicos LVM
  • MD RAID
  • DM Multipath
  • iSCSI
  • Discos duros y unidades de estado sólido (SSD)
  • Dispositivos NVMe
Aviso

En la versión actual, Stratis no maneja fallos en los discos duros u otro hardware. Si se crea un pool de Stratis sobre múltiples dispositivos de hardware, se incrementa el riesgo de pérdida de datos porque varios dispositivos deben estar operativos para acceder a los datos.

Dispositivos no compatibles

Debido a que Stratis contiene una capa de aprovisionamiento fino, Red Hat no recomienda colocar un pool de Stratis en dispositivos de bloque que ya están aprovisionados de forma fina.

Recursos adicionales

  • Para iSCSI y otros dispositivos de bloque que requieren red, consulte la página man systemd.mount(5) para obtener información sobre la opción de montaje _netdev.

17.1.4. Instalación de Stratis

Este procedimiento instala todos los paquetes necesarios para utilizar Stratis.

Procedimiento

  1. Instale los paquetes que proporcionan el servicio Stratis y las utilidades de línea de comandos: 

    # yum install stratisd stratis-cli
    Copy to Clipboard

  2. Asegúrese de que el servicio stratisd está activado: 

    # systemctl enable --now stratisd
    Copy to Clipboard

17.1.5. Creación de un pool de Stratis

Este procedimiento describe cómo crear un pool Stratis encriptado o no encriptado a partir de uno o varios dispositivos de bloque.

Las siguientes notas se aplican a los pools Stratis encriptados:

  • Cada dispositivo de bloque se encripta utilizando la biblioteca cryptsetup e implementa el formato LUKS2.
  • Cada pool de Stratis puede tener una clave única o puede compartir la misma clave con otros pools. Estas claves se almacenan en el llavero del kernel.
  • Todos los dispositivos de bloque que componen un pool Stratis están encriptados o sin encriptar. No es posible tener dispositivos de bloque encriptados y no encriptados en el mismo pool de Stratis.
  • Los dispositivos de bloque añadidos al nivel de datos de un pool Stratis encriptado se encriptan automáticamente.

Requisitos previos

  • Stratis v2.2.1 está instalado en su sistema. Consulte Sección 17.1.4, “Instalación de Stratis”.
  • El servicio stratisd está funcionando.
  • Los dispositivos de bloque en los que está creando un pool de Stratis no están en uso y no están montados.
  • Los dispositivos de bloque en los que está creando un pool de Stratis tienen un tamaño mínimo de 1 GiB cada uno.

  • En la arquitectura IBM Z, los dispositivos de bloque /dev/dasd* deben ser particionados. Utilice la partición en el pool de Stratis.

    Para obtener información sobre la partición de dispositivos DASD, consulte Configuración de una instancia de Linux en IBM Z.

Procedimiento

  1. Si el dispositivo de bloque seleccionado contiene firmas del sistema de archivos, de la tabla de particiones o del RAID, bórrelas con el siguiente comando: 

    # wipefs --all block-device
    Copy to Clipboard

    donde block-device es la ruta de acceso al dispositivo de bloque; por ejemplo, /dev/sdb.

  2. Cree el nuevo pool de Stratis en el o los dispositivos de bloque seleccionados:

    Nota

    Especifique varios dispositivos de bloque en una sola línea, separados por un espacio: 

    # stratis pool create my-pool block-device-1 block-device-2
    Copy to Clipboard

    • Para crear un pool Stratis no encriptado, utilice el siguiente comando y vaya al paso 3: 

      # stratis pool create my-pool block-device
      Copy to Clipboard

      donde block-device es la ruta a un dispositivo de bloque vacío o borrado.

      Nota

      No se puede encriptar un pool Stratis no encriptado después de crearlo.

    • Para crear un pool Stratis encriptado, complete los siguientes pasos:

      1. Si aún no ha creado un conjunto de claves, ejecute el siguiente comando y siga las indicaciones para crear un conjunto de claves que se utilizará para el cifrado: 

        # stratis key set --capture-key key-description
        Copy to Clipboard

        donde key-description es la descripción o el nombre del conjunto de claves.

      2. Cree el pool Stratis encriptado y especifique la descripción de la clave a utilizar para la encriptación. También puede especificar la ruta de la clave utilizando el parámetro --keyfile-path en su lugar. 

        # stratis pool create --key-desc key-description my-pool block-device
        Copy to Clipboard

        donde

        key-description
        Especifica la descripción o el nombre del archivo de claves que se utilizará para el cifrado.
        my-pool
        Especifica el nombre del nuevo pool de Stratis.
        block-device
        Especifica la ruta de acceso a un dispositivo de bloque vacío o borrado.

  3. Compruebe que se ha creado el nuevo pool de Stratis: 

    # lista de piscinas de stratis
    Copy to Clipboard

Solución de problemas

Después de un reinicio del sistema, a veces puede que no vea su pool Stratis encriptado o los dispositivos de bloque que lo componen. Si se encuentra con este problema, debe desbloquear el pool Stratis para hacerlo visible.

Para desbloquear el pool de Stratis, complete los siguientes pasos:

  1. Vuelva a crear el conjunto de claves utilizando la misma descripción de claves que se utilizó anteriormente: 

    # stratis key set --capture-key key-description
    Copy to Clipboard

  2. Desbloquea el pool de Stratis y el/los dispositivo/s de bloque: 

    # stratis pool unlock
    Copy to Clipboard

  3. Compruebe que el pool de Stratis es visible: 

    # lista de piscinas de stratis
    Copy to Clipboard

Recursos adicionales

  • La página de manual stratis(8).

Próximos pasos

17.1.6. Creación de un sistema de archivos Stratis

Este procedimiento crea un sistema de archivos Stratis en un pool Stratis existente.

Requisitos previos

Procedimiento

  1. Para crear un sistema de archivos Stratis en un pool, utilice: 

    # stratis fs create my-pool my-fs
    Copy to Clipboard
    • Sustituya my-pool con el nombre de su pool Stratis existente.
    • Sustituya my-fs con un nombre arbitrario para el sistema de archivos.

  2. Para verificarlo, liste los sistemas de archivos dentro del pool: 

    # stratis fs list my-pool
    Copy to Clipboard

Recursos adicionales

  • La página de manual stratis(8)

Próximos pasos

17.1.7. Montaje de un sistema de archivos Stratis

Este procedimiento monta un sistema de archivos Stratis existente para acceder al contenido.

Requisitos previos

Procedimiento

  • Para montar el sistema de archivos, utilice las entradas que Stratis mantiene en el directorio /stratis/: 

    # mount /stratis/my-pool/my-fs mount-point
    Copy to Clipboard

El sistema de archivos está ahora montado en el directorio mount-point y está listo para ser utilizado.

Recursos adicionales

  • La página de manual mount(8)

17.1.8. Montaje persistente de un sistema de archivos Stratis

Este procedimiento monta persistentemente un sistema de archivos Stratis para que esté disponible automáticamente después de arrancar el sistema.

Requisitos previos

Procedimiento

  1. Determina el atributo UUID del sistema de archivos: 

    $ lsblk --output=UUID /stratis/my-pool/my-fs
    Copy to Clipboard

    Por ejemplo:

    Ejemplo 17.1. Ver el UUID del sistema de archivos Stratis

    $ lsblk --output=UUID /stratis/my-pool/fs1

UUID
a1f0b64a-4ebb-4d4e-9543-b1d79f600283
    Copy to Clipboard

  2. Si el directorio del punto de montaje no existe, créelo: 

    # mkdir --parents mount-point
    Copy to Clipboard

  3. Como root, edita el archivo /etc/fstab y añade una línea para el sistema de archivos, identificado por el UUID. Utiliza xfs como tipo de sistema de archivos y añade la opción x-systemd.requires=stratisd.service.

    Por ejemplo:

    Ejemplo 17.2. El punto de montaje /fs1 en /etc/fstab

    UUID=a1f0b64a-4ebb-4d4e-9543-b1d79f600283 /fs1 xfs defaults,x-systemd.requires=stratisd.service 0 0
    Copy to Clipboard

  4. Regenere las unidades de montaje para que su sistema registre la nueva configuración: 

    # systemctl daemon-reload
    Copy to Clipboard

  5. Intente montar el sistema de archivos para verificar que la configuración funciona: 

    # montaje mount-point
    Copy to Clipboard

Recursos adicionales

17.2. Ampliación de un volumen Stratis con dispositivos de bloque adicionales

Puede adjuntar dispositivos de bloque adicionales a un pool Stratis para proporcionar más capacidad de almacenamiento para los sistemas de archivos Stratis.

17.2.1. Componentes de un volumen Stratis

Externamente, Stratis presenta los siguientes componentes de volumen en la interfaz de línea de comandos y en la API:

blockdev
Dispositivos de bloque, como un disco o una partición de disco.
pool

Compuesto por uno o varios dispositivos en bloque.

Un pool tiene un tamaño total fijo, igual al tamaño de los dispositivos de bloque.

El pool contiene la mayoría de las capas de Stratis, como la caché de datos no volátil que utiliza el objetivo dm-cache.

Stratis crea un /stratis/my-pool/ directorio para cada pool. Este directorio contiene enlaces a dispositivos que representan sistemas de archivos Stratis en el pool.

filesystem

Cada pool puede contener uno o más sistemas de archivos, que almacenan archivos.

Los sistemas de archivos se aprovisionan de forma ligera y no tienen un tamaño total fijo. El tamaño real de un sistema de archivos crece con los datos almacenados en él. Si el tamaño de los datos se acerca al tamaño virtual del sistema de archivos, Stratis hace crecer el volumen delgado y el sistema de archivos automáticamente.

Los sistemas de archivos están formateados con XFS.

Importante

Stratis rastrea información sobre los sistemas de archivos creados con Stratis que XFS no conoce, y los cambios realizados con XFS no crean automáticamente actualizaciones en Stratis. Los usuarios no deben reformatear o reconfigurar los sistemas de archivos XFS que son administrados por Stratis.

Stratis crea enlaces a sistemas de archivos en la /stratis/my-pool/my-fs ruta de acceso.

Nota

Stratis utiliza muchos dispositivos Device Mapper, que aparecen en los listados de dmsetup y en el archivo /proc/partitions. Del mismo modo, la salida del comando lsblk refleja el funcionamiento interno y las capas de Stratis.

17.2.2. Añadir dispositivos de bloque a un pool de Stratis

Este procedimiento añade uno o más dispositivos de bloque a un pool de Stratis para que puedan ser utilizados por los sistemas de archivos Stratis.

Requisitos previos

  • Stratis está instalado. Véase Sección 17.1.4, “Instalación de Stratis”.
  • El servicio stratisd está funcionando.
  • Los dispositivos de bloque que está añadiendo al pool de Stratis no están en uso y no están montados.
  • Los dispositivos de bloque que está añadiendo al pool de Stratis tienen un tamaño mínimo de 1 GiB cada uno.

Procedimiento

  • Para añadir uno o más dispositivos de bloque al pool, utilice: 

    # stratis pool add-data my-pool device-1 device-2 device-n
    Copy to Clipboard

Recursos adicionales

  • La página de manual stratis(8)

17.3. Supervisión de los sistemas de archivos Stratis

Como usuario de Stratis, puede ver información sobre los volúmenes de Stratis en su sistema para controlar su estado y el espacio libre.

17.3.1. Tamaños de estratis reportados por diferentes empresas de servicios públicos

Esta sección explica la diferencia entre los tamaños de Stratis reportados por utilidades estándar como df y la utilidad stratis.

Las utilidades estándar de Linux como df reportan el tamaño de la capa del sistema de archivos XFS en Stratis, que es de 1 TiB. Esta información no es útil, porque el uso real de almacenamiento de Stratis es menor debido al thin provisioning, y también porque Stratis hace crecer automáticamente el sistema de archivos cuando la capa XFS está cerca de llenarse.

Importante

Supervise regularmente la cantidad de datos escritos en sus sistemas de archivos Stratis, que se reporta como el valor Total Physical Used. Asegúrese de que no supera el valor de Total Physical Size.

Recursos adicionales

  • La página de manual stratis(8)

17.3.2. Visualización de información sobre los volúmenes de Stratis

Este procedimiento muestra las estadísticas de sus volúmenes Stratis, como el tamaño total, usado y libre, o los sistemas de archivos y dispositivos de bloques pertenecientes a un pool.

Requisitos previos

Procedimiento

  • Para mostrar información sobre todos los block devices utilizados para Stratis en su sistema: 

    # stratis blockdev

Pool Name  Device Node    Physical Size   State  Tier
my-pool    /dev/sdb            9.10 TiB  In-use  Data
    Copy to Clipboard

  • Para mostrar información sobre todos los Stratis pools en su sistema: 

    # stratis pool

Name    Total Physical Size  Total Physical Used
my-pool            9.10 TiB              598 MiB
    Copy to Clipboard

  • Para mostrar información sobre todos los Stratis file systems en su sistema: 

    # stratis filesystem

Pool Name  Name  Used     Created            Device
my-pool    my-fs 546 MiB  Nov 08 2018 08:03  /stratis/my-pool/my-fs
    Copy to Clipboard

Recursos adicionales

  • La página de manual stratis(8)

17.4. Uso de instantáneas en los sistemas de archivos Stratis

Puede utilizar instantáneas en los sistemas de archivos Stratis para capturar el estado del sistema de archivos en momentos arbitrarios y restaurarlo en el futuro.

17.4.1. Características de las instantáneas de Stratis

Esta sección describe las propiedades y limitaciones de las instantáneas del sistema de archivos en Stratis.

En Stratis, una instantánea es un sistema de archivos Stratis regular creado como una copia de otro sistema de archivos Stratis. La instantánea contiene inicialmente el mismo contenido de archivos que el sistema de archivos original, pero puede cambiar a medida que se modifica la instantánea. Cualquier cambio que se haga en la instantánea no se reflejará en el sistema de archivos original.

La implementación actual de la instantánea en Stratis se caracteriza por lo siguiente:

  • Una instantánea de un sistema de archivos es otro sistema de archivos.
  • Una instantánea y su origen no están vinculados en cuanto a su vida. Un sistema de archivos instantáneo puede vivir más tiempo que el sistema de archivos del que se creó.
  • No es necesario montar un sistema de archivos para crear una instantánea a partir de él.
  • Cada instantánea utiliza alrededor de medio gigabyte de almacenamiento de respaldo real, que es necesario para el registro XFS.

17.4.2. Creación de una instantánea de Stratis

Este procedimiento crea un sistema de archivos Stratis como una instantánea de un sistema de archivos Stratis existente.

Requisitos previos

Procedimiento

  • Para crear una instantánea de Stratis, utilice: 

    # stratis fs snapshot my-pool my-fs my-fs-snapshot
    Copy to Clipboard

Recursos adicionales

  • La página de manual stratis(8)

17.4.3. Acceso al contenido de una instantánea de Stratis

Este procedimiento monta una instantánea de un sistema de archivos Stratis para que sea accesible para operaciones de lectura y escritura.

Requisitos previos

Procedimiento

  • Para acceder a la instantánea, móntela como un sistema de archivos normal desde el directorio /stratis/my-pool/ directorio: 

    # mount /stratis/my-pool/my-fs-snapshot mount-point
    Copy to Clipboard

Recursos adicionales

17.4.4. Revertir un sistema de archivos Stratis a una instantánea anterior

Este procedimiento revierte el contenido de un sistema de archivos Stratis al estado capturado en una instantánea Stratis.

Requisitos previos

Procedimiento

  1. Opcionalmente, haga una copia de seguridad del estado actual del sistema de archivos para poder acceder a él más tarde: 

    # stratis filesystem snapshot my-pool my-fs my-fs-backup
    Copy to Clipboard

  2. Desmontar y eliminar el sistema de archivos original: 

    # umount /stratis/my-pool/my-fs
# stratis filesystem destroy my-pool my-fs
    Copy to Clipboard

  3. Cree una copia de la instantánea con el nombre del sistema de archivos original: 

    # stratis filesystem snapshot my-pool my-fs-snapshot my-fs
    Copy to Clipboard

  4. Monte la instantánea, que ahora es accesible con el mismo nombre que el sistema de archivos original: 

    # mount /stratis/my-pool/my-fs mount-point
    Copy to Clipboard

El contenido del sistema de archivos llamado my-fs es ahora idéntico al de la instantánea my-fs-snapshot.

Recursos adicionales

  • La página de manual stratis(8)

17.4.5. Eliminación de una instantánea de Stratis

Este procedimiento elimina una instantánea de Stratis de un pool. Los datos de la instantánea se pierden.

Requisitos previos

Procedimiento

  1. Desmontar la instantánea: 

    # umount /stratis/my-pool/my-fs-snapshot
    Copy to Clipboard

  2. Destruye la instantánea: 

    # stratis filesystem destroy my-pool my-fs-snapshot
    Copy to Clipboard

Recursos adicionales

  • La página de manual stratis(8)

17.5. Eliminación de los sistemas de archivos Stratis

Puede eliminar un sistema de archivos Stratis existente o un pool Stratis, destruyendo los datos en ellos.

17.5.1. Componentes de un volumen Stratis

Externamente, Stratis presenta los siguientes componentes de volumen en la interfaz de línea de comandos y en la API:

blockdev
Dispositivos de bloque, como un disco o una partición de disco.
pool

Compuesto por uno o varios dispositivos en bloque.

Un pool tiene un tamaño total fijo, igual al tamaño de los dispositivos de bloque.

El pool contiene la mayoría de las capas de Stratis, como la caché de datos no volátil que utiliza el objetivo dm-cache.

Stratis crea un /stratis/my-pool/ directorio para cada pool. Este directorio contiene enlaces a dispositivos que representan sistemas de archivos Stratis en el pool.

filesystem

Cada pool puede contener uno o más sistemas de archivos, que almacenan archivos.

Los sistemas de archivos se aprovisionan de forma ligera y no tienen un tamaño total fijo. El tamaño real de un sistema de archivos crece con los datos almacenados en él. Si el tamaño de los datos se acerca al tamaño virtual del sistema de archivos, Stratis hace crecer el volumen delgado y el sistema de archivos automáticamente.

Los sistemas de archivos están formateados con XFS.

Importante

Stratis rastrea información sobre los sistemas de archivos creados con Stratis que XFS no conoce, y los cambios realizados con XFS no crean automáticamente actualizaciones en Stratis. Los usuarios no deben reformatear o reconfigurar los sistemas de archivos XFS que son administrados por Stratis.

Stratis crea enlaces a sistemas de archivos en la /stratis/my-pool/my-fs ruta de acceso.

Nota

Stratis utiliza muchos dispositivos Device Mapper, que aparecen en los listados de dmsetup y en el archivo /proc/partitions. Del mismo modo, la salida del comando lsblk refleja el funcionamiento interno y las capas de Stratis.

17.5.2. Eliminación de un sistema de archivos Stratis

Este procedimiento elimina un sistema de archivos Stratis existente. Los datos almacenados en él se pierden.

Requisitos previos

Procedimiento

  1. Desmontar el sistema de archivos: 

    # umount /stratis/my-pool/my-fs
    Copy to Clipboard

  2. Destruye el sistema de archivos: 

    # stratis filesystem destroy my-pool my-fs
    Copy to Clipboard

  3. Compruebe que el sistema de archivos ya no existe: 

    # stratis filesystem list my-pool
    Copy to Clipboard

Recursos adicionales

  • La página de manual stratis(8)

17.5.3. Eliminación de una piscina Stratis

Este procedimiento elimina un pool de Stratis existente. Los datos almacenados en él se pierden.

Requisitos previos

Procedimiento

  1. Lista de sistemas de archivos en el pool: 

    # stratis filesystem list my-pool
    Copy to Clipboard

  2. Desmontar todos los sistemas de archivos del pool: 

    # umount /stratis/my-pool/my-fs-1 \
         /stratis/my-pool/my-fs-2 \
         /stratis/my-pool/my-fs-n
    Copy to Clipboard

  3. Destruye los sistemas de archivos: 

    # stratis filesystem destroy my-pool my-fs-1 my-fs-2
    Copy to Clipboard

  4. Destruye la piscina: 

    # stratis pool destroy my-pool
    Copy to Clipboard

  5. Compruebe que la piscina ya no existe: 

    # lista de piscinas de stratis
    Copy to Clipboard

Recursos adicionales

  • La página de manual stratis(8)

Capítulo 18. Cómo empezar con un sistema de archivos ext3

Como administrador del sistema, puedes crear, montar, redimensionar, hacer copias de seguridad y restaurar un sistema de archivos ext3. El sistema de archivos ext3 es esencialmente una versión mejorada del sistema de archivos ext2.

18.1. Características de un sistema de archivos ext3

Las siguientes son las características de un sistema de archivos ext3:

  • Disponibilidad: Después de un corte de energía inesperado o de un fallo del sistema, no es necesario comprobar el sistema de archivos gracias al registro en el diario proporcionado. El tamaño del diario por defecto tarda aproximadamente un segundo en recuperarse, dependiendo de la velocidad del hardware

    Nota

    El único modo de registro en el diario soportado en ext3 es data=ordered (por defecto). Para obtener más información, consulte ¿La opción de registro en el diario de EXT \ "data=writeback" es compatible con RHEL? Artículo de la base de conocimientos.

  • Integridad de los datos: El sistema de archivos ext3 evita la pérdida de la integridad de los datos durante un corte de energía inesperado o una caída del sistema.
  • Velocidad: A pesar de escribir algunos datos más de una vez, ext3 tiene un mayor rendimiento en la mayoría de los casos que ext2 porque el registro en el diario de ext3 optimiza el movimiento del cabezal del disco duro.
  • Transición fácil: Es fácil migrar de ext2 a ext3 y obtener los beneficios de un robusto sistema de archivos con registro en diario sin reformatear.

Recursos adicionales

  • La página de manual ext3.

18.2. Creación de un sistema de archivos ext3

Como administrador del sistema, puede crear un sistema de archivos ext3 en un dispositivo de bloque utilizando el comando mkfs.ext3.

Requisitos previos

Procedimiento

  1. Para crear un sistema de archivos ext3:

    • Para un dispositivo de partición regular, un volumen LVM, un volumen MD o un dispositivo similar, utilice el siguiente comando: 

      # mkfs.ext3 /dev/block_device
      Copy to Clipboard

      Sustituya /dev/block_device por la ruta de acceso a un dispositivo de bloque.

      Por ejemplo, /dev/sdb1, /dev/disk/by-uuid/05e99ec8-def1-4a5e-8a9d-5945339ceb2a, o /dev/my-volgroup/my-lv. En general, las opciones por defecto son óptimas para la mayoría de los escenarios de uso.

    Nota

    • Para especificar un UUID al crear un sistema de archivos: 

      # mkfs.ext3 -U UUID /dev/block_device
      Copy to Clipboard

      Sustituya UUID por el UUID que desee establecer: por ejemplo, 7cd65de3-e0be-41d9-b66d-96d749c02da7.

      Sustituya /dev/block_device por la ruta de un sistema de archivos ext3 para que se le añada el UUID: por ejemplo, /dev/sda8.

    • Para especificar una etiqueta al crear un sistema de archivos: 

      # mkfs.ext3 -L label-name /dev/block_device
      Copy to Clipboard

  2. Para ver el sistema de archivos ext3 creado: 

    # blkid
    Copy to Clipboard

Recursos adicionales

  • La página de manual ext3.
  • La página de manual mkfs.ext3.

18.3. Montaje de un sistema de archivos ext3

Como administrador del sistema, puede montar un sistema de archivos ext3 utilizando la utilidad mount.

Requisitos previos

Procedimiento

  1. Para crear un punto de montaje para montar el sistema de archivos: 

    # mkdir /mount/point
    Copy to Clipboard

    Sustituya /mount/point por el nombre del directorio donde debe crearse el punto de montaje de la partición.

  2. Para montar un sistema de archivos ext3:

  3. Para ver el sistema de archivos montado: 

    # df -h
    Copy to Clipboard

Recursos adicionales

18.4. Redimensionar un sistema de archivos ext3

Como administrador del sistema, puede redimensionar un sistema de archivos ext3 utilizando la utilidad resize2fs. La utilidad resize2fs lee el tamaño en unidades de tamaño de bloque del sistema de archivos, a menos que se utilice un sufijo que indique una unidad específica. Los siguientes sufijos indican unidades específicas:

  • s (sectores) - 512 sectores de bytes
  • K (kilobytes) - 1,024 bytes
  • M (megabytes) - 1,048,576 bytes
  • G (gigabytes) - 1,073,741,824 bytes
  • T (terabytes) - 1,099,511,627,776 bytes

Requisitos previos

Procedimiento

  1. Para redimensionar un sistema de archivos ext3, siga los siguientes pasos:

    • Para reducir y aumentar el tamaño de un sistema de archivos ext3 sin montar: 

      # umount /dev/block_device
# e2fsck -f /dev/block_device
# resize2fs /dev/block_device size
      Copy to Clipboard

      Sustituya /dev/block_device por la ruta de acceso al dispositivo de bloque, por ejemplo /dev/sdb1.

      Sustituya size por el valor de redimensionamiento requerido utilizando los sufijos s, K, M, G y T.

    • Un sistema de archivos ext3 puede crecer mientras se monta utilizando el comando resize2fs: 

      # resize2fs /mount/device size
      Copy to Clipboard
      Nota

      El parámetro de tamaño es opcional (y a menudo redundante) cuando se expande. El resize2fs se expande automáticamente para llenar el espacio disponible del contenedor, normalmente un volumen lógico o una partición.

  2. Para ver el sistema de archivos redimensionado: 

    # df -h
    Copy to Clipboard

Recursos adicionales

  • La página de manual resize2fs.
  • La página de manual e2fsck.
  • La página de manual ext3.

18.5. Creación y montaje de sistemas de archivos ext3 con RHEL System Roles

Esta sección describe cómo crear un sistema de archivos ext3 con una etiqueta determinada en un disco, y montar persistentemente el sistema de archivos utilizando el rol storage.

Requisitos previos

  • Existe un playbook de Ansible que incluye el rol storage.

Para obtener información sobre cómo aplicar un libro de jugadas de este tipo, consulte Aplicar un rol.

18.5.1. Ejemplo de playbook de Ansible para crear y montar un sistema de archivos ext3

Esta sección proporciona un ejemplo de libro de jugadas de Ansible. Este libro de jugadas aplica el rol storage para crear y montar un sistema de archivos Ext3.

Ejemplo 18.1. Un playbook que crea Ext3 en /dev/sdb y lo monta en /mnt/data

---
- hosts: all
  vars:
    storage_volumes:
      - name: barefs
        type: disk
        disks:
          - sdb
        fs_type: ext3
        fs_label: label-name
        mount_point: /mnt/data
  roles:
    - rhel-system-roles.storage
Copy to Clipboard
  • El libro de jugadas crea el sistema de archivos en el disco /dev/sdb.
  • El libro de jugadas monta persistentemente el sistema de archivos en el directorio /mnt/data directorio.
  • La etiqueta del sistema de archivos es label-name.

Recursos adicionales

  • Para más detalles sobre los parámetros utilizados en el rol de sistema storage, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.storage/README.md.

18.5.2. Recursos adicionales

Capítulo 19. Cómo empezar con un sistema de archivos ext4

Como administrador del sistema, puede crear, montar, redimensionar, hacer copias de seguridad y restaurar un sistema de archivos ext4. El sistema de archivos ext4 es una extensión escalable del sistema de archivos ext3. Con Red Hat Enterprise Linux 8, puede soportar un tamaño máximo de archivo individual de 16 terabytes, y el sistema de archivos hasta un máximo de 50 terabytes.

19.1. Características de un sistema de archivos ext4

Las siguientes son las características de un sistema de archivos ext4:

  • Uso de extensiones: El sistema de archivos ext4 utiliza extents, lo que mejora el rendimiento cuando se utilizan archivos de gran tamaño y reduce la sobrecarga de metadatos para los archivos grandes.
  • Ext4 etiqueta los grupos de bloques no asignados y las secciones de la tabla de inodos, lo que permite omitir los grupos de bloques y las secciones de la tabla durante la comprobación del sistema de archivos. Esto lleva a una rápida comprobación del sistema de archivos, que se vuelve más beneficiosa a medida que el sistema de archivos crece en tamaño.
  • Suma de comprobación de metadatos: Por defecto, esta función está activada en Red Hat Enterprise Linux 8.

  • Características de asignación de un sistema de archivos ext4:

    • Pre-asignación persistente
    • Asignación retardada
    • Asignación de bloques múltiples
    • Asignación de rayas
  • Atributos extendidos (xattr): Permite al sistema asociar varios pares de nombres y valores adicionales por archivo.

  • Registro en el diario de las cuotas: Esto evita la necesidad de largas comprobaciones de consistencia de cuotas después de una caída.

    Nota

    El único modo de registro en el diario soportado en ext4 es data=ordered (por defecto). Para obtener más información, consulte ¿La opción de registro en el diario de EXT \ "data=writeback" es compatible con RHEL? Artículo de la base de conocimientos.

  • Marcas de tiempo del subsegundo - Esto da marcas de tiempo al subsegundo.

Recursos adicionales

  • La página de manual ext4.

19.2. Creación de un sistema de archivos ext4

Como administrador del sistema, puede crear un sistema de archivos ext4 en un dispositivo de bloque utilizando el comando mkfs.ext4.

Requisitos previos

Procedimiento

  1. Para crear un sistema de archivos ext4:

    • Para un dispositivo de partición regular, un volumen LVM, un volumen MD o un dispositivo similar, utilice el siguiente comando: 

      # mkfs.ext4 /dev/block_device
      Copy to Clipboard

      Sustituya /dev/block_device por la ruta de acceso a un dispositivo de bloque.

      Por ejemplo, /dev/sdb1, /dev/disk/by-uuid/05e99ec8-def1-4a5e-8a9d-5945339ceb2a, o /dev/my-volgroup/my-lv. En general, las opciones por defecto son óptimas para la mayoría de los escenarios de uso.

    • En el caso de los dispositivos de bloques rayados (por ejemplo, matrices RAID5), la geometría de las rayas puede especificarse en el momento de la creación del sistema de archivos. El uso de una geometría de franjas adecuada mejora el rendimiento de un sistema de archivos ext4. Por ejemplo, para crear un sistema de archivos con una franja de 64k (es decir, 16 x 4096) en un sistema de archivos de 4k bloques, utilice el siguiente comando: 

      # mkfs.ext4 -E stride=16,stripe-width=64 /dev/block_device
      Copy to Clipboard

      En el ejemplo dado:

      • stride=valor: Especifica el tamaño de los trozos del RAID
      • stripe-width=valor: Especifica el número de discos de datos en un dispositivo RAID, o el número de unidades de franja en la franja.
    Nota

    • Para especificar un UUID al crear un sistema de archivos: 

      # mkfs.ext4 -U UUID /dev/block_device
      Copy to Clipboard

      Sustituya UUID por el UUID que desee establecer: por ejemplo, 7cd65de3-e0be-41d9-b66d-96d749c02da7.

      Sustituya /dev/block_device por la ruta de un sistema de archivos ext4 para que se le añada el UUID: por ejemplo, /dev/sda8.

    • Para especificar una etiqueta al crear un sistema de archivos: 

      # mkfs.ext4 -L label-name /dev/block_device
      Copy to Clipboard

  2. Para ver el sistema de archivos ext4 creado: 

    # blkid
    Copy to Clipboard

Recursos adicionales

  • La página de manual ext4.
  • La página de manual mkfs.ext4.

19.3. Montaje de un sistema de archivos ext4

Como administrador del sistema, puede montar un sistema de archivos ext4 utilizando la utilidad mount.

Requisitos previos

Procedimiento

  1. Para crear un punto de montaje para montar el sistema de archivos: 

    # mkdir /mount/point
    Copy to Clipboard

    Sustituya /mount/point por el nombre del directorio donde debe crearse el punto de montaje de la partición.

  2. Para montar un sistema de archivos ext4:

  3. Para ver el sistema de archivos montado: 

    # df -h
    Copy to Clipboard

Recursos adicionales

19.4. Redimensionar un sistema de archivos ext4

Como administrador del sistema, puede redimensionar un sistema de archivos ext4 utilizando la utilidad resize2fs. La utilidad resize2fs lee el tamaño en unidades de tamaño de bloque del sistema de archivos, a menos que se utilice un sufijo que indique una unidad específica. Los siguientes sufijos indican unidades específicas:

  • s (sectores) - 512 sectores de bytes
  • K (kilobytes) - 1,024 bytes
  • M (megabytes) - 1,048,576 bytes
  • G (gigabytes) - 1,073,741,824 bytes
  • T (terabytes) - 1,099,511,627,776 bytes

Requisitos previos

Procedimiento

  1. Para redimensionar un sistema de archivos ext4, siga los siguientes pasos:

    • Para reducir y aumentar el tamaño de un sistema de archivos ext4 sin montar: 

      # umount /dev/block_device
# e2fsck -f /dev/block_device
# resize2fs /dev/block_device size
      Copy to Clipboard

      Sustituya /dev/block_device por la ruta de acceso al dispositivo de bloque, por ejemplo /dev/sdb1.

      Sustituya size por el valor de redimensionamiento requerido utilizando los sufijos s, K, M, G y T.

    • Un sistema de archivos ext4 puede crecer mientras se monta utilizando el comando resize2fs: 

      # resize2fs /mount/device size
      Copy to Clipboard
      Nota

      El parámetro de tamaño es opcional (y a menudo redundante) cuando se expande. El resize2fs se expande automáticamente para llenar el espacio disponible del contenedor, normalmente un volumen lógico o una partición.

  2. Para ver el sistema de archivos redimensionado: 

    # df -h
    Copy to Clipboard

Recursos adicionales

  • La página de manual resize2fs.
  • La página de manual e2fsck.
  • La página de manual ext4.

19.5. Creación y montaje de sistemas de archivos ext4 con RHEL System Roles

Esta sección describe cómo crear un sistema de archivos ext4 con una etiqueta determinada en un disco, y montar persistentemente el sistema de archivos utilizando el rol storage.

Requisitos previos

  • Existe un playbook de Ansible que incluye el rol storage.

Para obtener información sobre cómo aplicar un libro de jugadas de este tipo, consulte Aplicar un rol.

19.5.1. Ejemplo de playbook Ansible para crear y montar un sistema de archivos Ext4

Esta sección proporciona un ejemplo de libro de jugadas de Ansible. Este libro de jugadas aplica el rol storage para crear y montar un sistema de archivos Ext4.

Ejemplo 19.1. Un playbook que crea Ext4 en /dev/sdb y lo monta en /mnt/data

---
- hosts: all
  vars:
    storage_volumes:
      - name: barefs
        type: disk
        disks:
          - sdb
        fs_type: ext4
        fs_label: label-name
        mount_point: /mnt/data
  roles:
    - rhel-system-roles.storage
Copy to Clipboard
  • El libro de jugadas crea el sistema de archivos en el disco /dev/sdb.
  • El libro de jugadas monta persistentemente el sistema de archivos en el directorio /mnt/data directorio.
  • La etiqueta del sistema de archivos es label-name.

Recursos adicionales

  • Para más detalles sobre los parámetros utilizados en el rol de sistema storage, consulte el archivo /usr/share/ansible/roles/rhel-system-roles.storage/README.md.

Recursos adicionales

19.6. Comparación de las herramientas utilizadas con ext4 y XFS

Esta sección compara qué herramientas utilizar para realizar tareas comunes en los sistemas de archivos ext4 y XFS.

Tareaext4XFS

Crear un sistema de archivos

mkfs.ext4

mkfs.xfs

Comprobación del sistema de archivos

e2fsck

xfs_repair

Redimensionar un sistema de archivos

resize2fs

xfs_growfs

Guardar una imagen de un sistema de archivos

e2image

xfs_metadump y xfs_mdrestore

Etiquetar o ajustar un sistema de archivos

tune2fs

xfs_admin

Copia de seguridad de un sistema de archivos

dump y restore

xfsdump y xfsrestore

Gestión de cuotas

quota

xfs_quota

Asignación de archivos

filefrag

xfs_bmap

Volver arriba
Red Hat logoGithubredditYoutubeTwitter

Aprender

Pruebe, compre y venda

Comunidades

Acerca de la documentación de Red Hat

Ayudamos a los usuarios de Red Hat a innovar y alcanzar sus objetivos con nuestros productos y servicios con contenido en el que pueden confiar. Explore nuestras recientes actualizaciones.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a reemplazar el lenguaje problemático en nuestro código, documentación y propiedades web. Para más detalles, consulte el Blog de Red Hat.

Acerca de Red Hat

Ofrecemos soluciones reforzadas que facilitan a las empresas trabajar en plataformas y entornos, desde el centro de datos central hasta el perímetro de la red.

Theme

© 2025 Red Hat