¿Se usa `/ etc / fstab` para volver a montar las unidades?

Tengo un dispositivo instalado con Ubuntu 14.04.5 que tiene un solo disco duro con un sistema de archivos ext4.

Al leer el documento Ext4 Filesystem aprendí que el modo de datos predeterminado es el orderedque solo protege los metadatos. En mi proyecto, queremos cambiarlo para journalproteger también los datos del archivo porque la seguridad de los datos es de mayor valor.

Lo primero que intenté fue modificar el /etc/fstabarchivo. Traté de cambiar

UUID=<UUID> / ext4 errors=remount-ro 0 1

a

UUID=<UUID> / ext4 errors=remount-ro,data=journal 0 1

agregando data=journalal campo de opción.

Sin embargo, cuando reinicio el dispositivo, terminé con un mensaje de error que decía cannot change data mode on remount. Lo revisé dmesgy vi un mensaje anterior sobre el montaje de la unidad con orderedel modo de datos.

Durante un tiempo embarazosamente largo, pensé que /etc/fstabse usa para anular las opciones de montaje predeterminadas para que las unidades solo se monten una vez. Pero ahora parece incorrecto: la unidad se monta utilizando sus opciones de montaje predeterminadas, luego /etc/fstabse recoge para volver a montarla .

Mis preguntas son :

• ¿Es este proceso de "montaje remoto" el diseño del sistema? Leí la Fstabpágina wiki pero no vi que menciona la cosa de "montaje-montaje".
• Si /etc/fstabrealmente se usa para volver a montar, ¿ en qué paso del proceso de arranque se monta la unidad por primera vez? ¿Está implementado en /etc/init.d? Vi algunas secuencias de comandos en /etc/init.dllamadas umountfsy umountroot, pero, desnatando su contenido, no parecen relevantes.

De man ext4:

datos = {revista | ordenado | escritura}
              Especifica el modo de registro en diario para los datos del archivo. Los metadatos son siempre
              diario Para usar modos distintos de los ordenados en los archivos raíz
              tem, pase el modo al kernel como parámetro de arranque, por ejemplo, root
              banderas = datos = diario.

Elimine data=orderedde su línea fstab y edite en su /etc/default/grublugar. En /etc/default/grubcambio la linea

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

a

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash root‐flags=data=journal"

ejecutar sudo update-gruby reiniciar.

Cuando se usa / etc / fstab

Si ejecuta sudo strace -e open,openat mount -o remount,rw /, verá que el comando de hecho se abre /etc/fstab. Este es el comando más común que verá, a menudo mencionado en artículos sobre cómo trabajar desde el shell de recuperación.

Para citar también la respuesta de sourcejedi (que viene del mount(8)manual):

mount -o remontar, rw / dir

Después de esta llamada, mount lee fstab y combina estas opciones con las opciones de la línea de comando (-o) . Si no se encuentra un punto de montaje en fstab, se permite un remontaje con una fuente no especificada.

Sin embargo, eso no significa que /etc/fstabsiempre se use. En particular, cuando también especifica el archivo del dispositivo; referencia al mount(8)manual :

La funcionalidad de montaje sigue la forma estándar en que funciona el comando mount con las opciones de fstab. Significa que el comando mount no lee fstab (o mtab) solo cuando un dispositivo y un directorio están completamente especificados.

mount -o remontar, rw / dev / foo / dir

Después de esta llamada, se reemplazan todas las opciones de montaje antiguas y se ignoran las cosas arbitrarias de fstab , excepto la opción loop = que el comando mount genera y mantiene internamente.

Esto tiene sentido, ya que /dirpodría ser arbitrario: volver a montar un dispositivo en un punto de montaje diferente.

El /etc/fstabtambién no se hace referencia al montar /el sistema de archivos en tiempo de arranque del kernel no sabe nada de /etc/fstab. Para citar la respuesta de psusi :

Finalmente llegaron los cargadores de arranque y pudieron pasar una línea de comando al núcleo. Si se pasó el argumento raíz =, eso le dijo al núcleo dónde estaba la raíz fs en lugar del valor incorporado. Los controladores necesarios para acceder que todavía tenían que estar integrados en el núcleo

...

Finalmente, hoy tenemos los initramfs. Esto es similar al initrd, pero en lugar de ser una imagen del sistema de archivos comprimido que se carga en un disco RAM, es un archivo comprimido de cpio. Se monta un tmpfs como raíz, y el archivo se extrae allí. En lugar de utilizar pivot_root, que se consideraba un hack sucio, los scripts de arranque initramfs montan la raíz real en / root, eliminan todos los archivos en la raíz tmpfs, luego chroot en / root y exec / sbin / init

Sistemas de archivos que no necesitan fstab

Tenga en cuenta también que el kernel de Linux tiene otros sistemas de archivos que residen en la memoria; estos no están disponibles para los usuarios normalmente, algunos de los cuales no tienen un punto de montaje, mientras que otros están expuestos a los usuarios. Kernel no tiene que hacer referencia /etc/fstaba ellos. Ejemplo de esto es /proc: es un sistema de archivos virtual que expone principalmente información sobre procesos, y algunas cosas sobre el hardware y el sistema que realmente deberían estar en /sysotro sistema de archivos virtual.