¿Qué sucede cuando se 'monta' sobre una carpeta existente con contenido?

En este momento /tmptiene algunos archivos temporales. Cuando monte mi disco duro ( /dev/sdc1) encima /tmp, puedo ver los archivos en el disco duro. ¿Qué sucede con el contenido real de /tmpcuando mi disco duro está montado? ¿Es posible realizar operaciones r / w en el contenido real de /tmpmientras el disco duro está montado?

python@lanix / $ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       286G   43G  229G  16% /
none            4.0K     0  4.0K   0% /sys/fs/cgroup
udev            3.8G  4.0K  3.8G   1% /dev
tmpfs           766M  1.4M  765M   1% /run
none            5.0M     0  5.0M   0% /run/lock
none            3.8G   38M  3.8G   1% /run/shm
none            100M   24K  100M   1% /run/user
/dev/sdb1       7.5G  2.7G  4.9G  35% /mnt
/dev/sdc1       932G  242G  691G  26% /tmp

¿Qué sucede con el contenido real de / tmp cuando mi disco duro está montado?

Casi nada. Simplemente están ocultos a la vista, no son accesibles a través del recorrido normal del sistema de archivos.

¿Es posible realizar operaciones de r / w en el contenido real de / tmp mientras el disco duro está montado?

Si. Los procesos que tenían identificadores de archivos abiertos dentro de su "original" /tmpcontinuarán siendo capaces de usarlos. También puede hacer que la "reaparezca" en otro lugar montando en /otro lugar.

# mount -o bind / /somewhere/else
# ls /somewhere/else/tmp  

Aquí hay un pequeño experimento que puede ejecutar para tener una mejor sensación (espero) de lo que está sucediendo.

Nota: Este no es un intento de ser perfectamente correcto o una descripción exhaustiva de lo que realmente está sucediendo. Sin embargo, debería ser lo suficientemente preciso como para darte una idea general.

Creé un usuario llamado meen mi máquina, y un directorio aleatorio en su casa, con un archivo:

me@home $ pwd
/home/me/tmp
me@home $ echo hello > some_file
me@home $ ls  
some_file
me@home $ cat some_file 
hello

En este punto, nada inusual: es solo un directorio sin formato con un archivo sin formato. Dejo esa sesión abierta tal como está, con su cwddirectorio de prueba dentro.

Como root, creo un pequeño sistema de archivos y lo montaje /home/me/tmp.

root@home # dd if=/dev/zero of=./fs bs=1M count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 0.00467318 s, 2.2 GB/s

root@home # mkfs -t ext2 ./fs 
mke2fs 1.42.12 (29-Aug-2014)
[... snip ...]
Writing superblocks and filesystem accounting information: done

root@home # mount ./fs /home/me/tmp

Luego abro una nueva terminal como mey miro alrededor:

me@home #2 $ cd tmp
me@home #2 $ ls
lost+found
me@home #2 $ cat some_file
cat: some_file: No such file or directory
me@home #2 $ echo bye bye > some_file
-su: some_file: Permission denied

Entonces, ese archivo que creamos claramente no está allí. El lost+founddirectorio es indicativo de la raíz de un sistema de archivos ext. Y perdí el permiso de escritura, por lo que claramente no es el directorio original.

Volviendo a la primera mesesión, veamos cómo ve el mundo:

me@home $ echo something else > other_file

No hay problema para escribir.

me@home $ cat some_file other_file 
hello
something else

El archivo original todavía está allí, se creó un nuevo archivo sin problemas.

¿Eh? ¿Que esta pasando?

La primera sesión ingresó al directorio antes de que se superpusiera al montar otro sistema de archivos en él. Esa acción de montaje no afecta el sistema de archivos original en absoluto. El proceso de shell tiene un identificador perfectamente válido para el directorio en el sistema de archivos original, y puede continuar interactuando con él. Es como correr por debajo del punto de montaje de la alfombra .

La segunda sesión ingresó al directorio después de que se montó el montaje. Entonces ve el nuevo sistema de archivos vacío. Y el administrador del sistema modificó los permisos, por lo que no puede usar el espacio solicitado ... arreglemos eso.

root@home # chown me:users /home/me/tmp

me@home #2 $ echo bye bye > some_file
me@home #2 $ ls 
lost+found  some_file
me@home #2 $ cat some_file 
bye bye

¿Puede la sesión 1 escapar de debajo de la alfombra? (Se está poniendo mohoso).

¡Seguro! Si la sesión 1 retrocede el árbol del sistema de archivos fuera del montaje, perderá ese asa hacia adentro y seguirá el montaje como todos los demás.

me@home $ cd
me@home $ pwd
/home/me
me@home $ cd tmp
me@home $ cat some_file other_file
bye bye
cat: other_file: No such file or directory

Misma vista que la sesión # 2, volvemos a la normalidad.

Pero, ¿cómo sabes que los archivos no desaparecieron? ¡Ya nadie está mirando!

Ese es uno de los momentos en los que las monturas de unión se vuelven útiles. Le permiten montar un sistema de archivos ya montado en otro lugar.

me@home $ mkdir ~/bind

root@home # mount -o bind /home/me /home/me/bind

(Sí, puedes montar un sistema de archivos "dentro de sí mismo". Truco genial, ¿eh?)

me@home $ ls bind/tmp
other_file  some_file
me@home $ cat bind/tmp/*
something else
hello

De modo que están allí, listos para la acción. Es simplemente que no son visibles / accesibles en su ubicación original, el montaje los oculta de los recorridos normales del directorio.

Te animo a que juegues con esto, realmente no es complicado una vez que has entendido el "truco" que se está jugando. Y una vez que lo tengas, busca en los sistemas de archivos de unión para obtener más tirones de la alfombra :-)

Sin embargo, una nota: montar sobre /tmpo /var(o cualquiera de los directorios principales del sistema operativo) realmente no es una buena idea una vez que el proceso de arranque haya finalizado. Muchas aplicaciones dejan el estado en esos directorios y pueden confundirse seriamente si juegas juegos de montaje a su alrededor.