¿Por qué el montaje ocurre sobre un directorio existente?

Se necesita un directorio existente como punto de montaje .

$ ls
$ sudo mount /dev/sdb2 ./datadisk
mount: mount point ./datadisk does not exist
$ mkdir datadisk
$ sudo mount /dev/sdb2 ./datadisk
$

Me resulta confuso ya que superpone los contenidos existentes del directorio. Hay dos posibles contenidos del directorio del punto de montaje que pueden cambiarse inesperadamente (para un usuario que no está realizando el montaje).

¿Por qué no mountsucede en un directorio recién creado? Así es como los sistemas operativos gráficos muestran los medios extraíbles. Sería claro si el directorio está montado (existe) o no está montado (no existe). Estoy bastante seguro de que hay una buena razón, pero aún no he podido descubrirlo.

Este es un caso de un detalle de implementación que se ha filtrado.

En un sistema UNIX, cada directorio consta de una lista de nombres asignados a números de inodo . Un inodo contiene metadatos que le dicen al sistema si es un archivo, directorio, dispositivo especial, canalización con nombre, etc. Si es un archivo o directorio, también le dice al sistema dónde encontrar el contenido del archivo o directorio en el disco. La mayoría de los inodos son archivos o directorios. La -iopción para lslistará los números de inodo.

El montaje de un sistema de archivos toma un inodo de directorio y establece un indicador en la copia en memoria del núcleo para decir "en realidad, cuando busque el contenido de este directorio, mire este otro sistema de archivos" (vea la diapositiva 10 de esta presentación ). Esto es relativamente fácil ya que está cambiando un solo elemento de datos.

¿Por qué no crea una entrada de directorio para que apunte al nuevo inodo? Hay dos formas de implementarlo, las cuales tienen desventajas. Una es escribir físicamente un nuevo directorio en el sistema de archivos, ¡pero eso falla si el sistema de archivos es de solo lectura! La otra es agregar a cada proceso de listado de directorio una lista de cosas "adicionales" que realmente no están allí. Esto es incómodo y potencialmente incurre en un pequeño impacto en el rendimiento en cada operación de archivo.

Si desea puntos de montaje creados dinámicamente, el automountsistema puede hacer esto. Sistemas de archivos no son de disco especiales también pueden crear directorios a voluntad, por ejemplo proc, sys, devfsy así sucesivamente.

Editar: vea también la respuesta a ¿Qué sucede cuando 'monta sobre' una carpeta existente con contenido?

Si se mount(2) requiere la creación de un nuevo directorio para ser el punto de montaje, no podría montar nada bajo un sistema de archivos de solo lectura. Eso sería tonto, por lo que podemos descartarlo.

Si mount creara opcionalmente un nuevo directorio para ser el punto de montaje, sería extraño. No es como montar / desmontar todo el tiempo, por lo que poner lógica adicional en el núcleo para realizar estos dos pasos con una sola llamada al sistema no sería una aceleración importante. Simplemente déjelo al espacio del usuario para hacer una mkdir(2)llamada al sistema si lo desea. La respuesta de Dmitry señala que mount(2)hacer ambas cosas lo haría no atómico. Y te gustaría un argumento adicional para mount(2)con banderas modo como open(2)se lleva, para O_CREAT, O_EXCL, etc. Sólo sería tonto en comparación con dejar el espacio de usuario hacerlo.

¿O tal vez estabas preguntando sobre cómo hacer esto mount(8)(el programa tradicional que hace mount(2)llamadas al sistema)? Eso sería posible, pero ya hay un producto perfectamente bueno mkdir(1)para el trabajo, y el diseño de Unix se trata de buenas herramientas pequeñas que se pueden combinar. Si desea una herramienta que haga ambas cosas, es fácil escribir un script de shell para construir esa herramienta a partir de dos herramientas más simples. (O, como comentó muru, udisksctlya lo hace, por lo que no tiene que escribirlo). Además, Linux es normal mount(8)desde util-linux admite el mount -o x-mount.mkdir[=mode]uso de su x-sintaxis para las opciones de espacio de usuario, en lugar de las opciones que se pasan al sistema de archivos.

Ahora la pregunta más interesante: ¿por qué tiene que haber un directorio en el sistema de archivos principal?

Como señala la respuesta de pjc50 (¡sin relación, a pesar de que tiene mis iniciales!), Hacer que los puntos de montaje aparezcan en los listados del directorio requeriría una verificación adicional en cada uno readdir().

Tener puntos de montaje como directorios en el directorio que los contiene (en el FS primario) es un buen truco. readdir()no tiene que notar que es un punto de montaje en absoluto. Eso solo sucede si el punto de montaje se usa como un componente de ruta. La resolución de ruta, por supuesto, tiene que verificar la tabla de montaje para cada componente de directorio de una ruta.

El montaje en el directorio existente hace una llamada a mountprácticamente atómica: tiene éxito o falla, al menos desde la perspectiva del usuario. Si mounttuviera que crear el punto de montaje en sí, tendría dos puntos de falla, lo que haría imposible garantizar un retroceso limpio. Imagine el siguiente escenario:

1. mount crea con éxito el punto de montaje
2. mount intenta montar un nuevo sistema de archivos en ese directorio, pero falla
3. mount intenta eliminar el punto de montaje, pero falla

El sistema termina con un efecto secundario de un error mount.

Aqui hay otro más:

1. umount desmonta con éxito un sistema de archivos
2. umount intenta eliminar el punto de montaje, pero falla

Ahora, ¿debería umountdevolver el éxito o el fracaso?

Otro caso que puede ocurrir:

Cuando inicia, una imagen básica de solo lectura se carga en el directorio raíz. Por lo tanto, le gustaría anularlo cuando desee amontonar la raíz real. Entonces puede imaginar que mount syscall simplemente cambie el punto de romontaje a rw.

Aquí, imaginemos que tiene un problema con el sistema de archivos en el punto de montaje raíz, le gustaría intentar repararlo. Con la superposición de montaje, puede desmontar el sistema de archivos y usarlo fscken la imagen básica para resolverlo.

Esta característica también puede ser útil en sistemas que necesitan una seguridad sólida para realizar un seguimiento del cambio entre una ropartición y una rw.

Siempre me he preguntado eso también.

Un contenedor simple como:

#!/bin/sh
eval "mkdir -p \"\$$#\"" 
/bin/mount "$@"  

guardado como un script ejecutable nombrado mounten un directorio que sobrescribe /binen su RUTA debe ocuparse de esto si le molesta demasiado

(Antes de ejecutar el mountbinario real , crea un directorio con el nombre del último argumento mount, si dicho directorio ya no existe).

Alternativamente, si no desea invocaciones fallidas del mountcontenedor para crear directorios, puede hacer:

#!/bin/sh
set -e
eval "lastArg=\"\$$#\""
test -d "$lastArg" || { mkdir "$lastArg"; madeDir=1; }
/bin/mount "$@"  ||  {  test -z "$madeDir" || rmdir "$lastArg"; }