mount – ¿Qué sucede cuando 'montas sobre' una carpeta existente con contenido?

Pregunta:

En este momento /tmp tiene algunos archivos temporales. Cuando monte mi disco duro ( /dev/sdc1 ) encima de /tmp , puedo ver los archivos en el disco duro. ¿Qué sucede con el contenido real de /tmp cuando se monta mi disco duro? ¿Es posible realizar operaciones de /tmp en el contenido real de /tmp mientras 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

Respuesta:

¿Qué sucede con el contenido real de / tmp cuando se monta mi disco duro?

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

¿Es posible realizar operaciones de lectura / escritura 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 /tmp "original" continuarán utilizándolos. También puede hacer que "reaparezca" en otro lugar mediante el montaje de enlace / otro lugar.

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

Aquí hay un pequeño experimento que puede realizar para tener una mejor idea (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, debe ser lo suficientemente preciso como para darle una idea general.

Creé un usuario que me llamó en mi máquina y un directorio aleatorio en su casa, con un archivo en él:

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 simple con un archivo simple. Dejo esa sesión abierta como está, con su cwd dentro de ese directorio de prueba.

Como root, creo un pequeño sistema de archivos y lo monto sobre /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 me y miro a mi 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 directorio lost+found 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 sesión de me , 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í, el nuevo archivo creado sin problemas.

¿Eh? ¿Que esta pasando?

La primera sesión entró en el directorio antes de que la raíz lo superpusiera montando otro sistema de archivos en él. Esa acción de montaje no afecta en absoluto al sistema de archivos original. 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 colocó el soporte. Entonces ve el nuevo sistema de archivos vacío. Y el administrador del sistema eliminó 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 vuelve a subir por el árbol del sistema de archivos fuera del montaje, perderá ese identificador hacia el interior 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 en la sesión 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 para atar 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í, puede enlazar-montar un sistema de archivos "dentro de sí mismo". Un 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 ahí, 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 de directorio.


Te animo a jugar con esto, realmente no es complicado una vez que hayas entendido el "truco" que se está jugando. Y una vez que lo tenga ™, busque en los sistemas de archivos de la unión para obtener aún más tiradas de alfombras 🙂

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

Leave a Comment

Your email address will not be published.

Scroll to Top

istanbul avukat

-

web tasarım