Que se passe-t-il lorsque vous «montez» sur un dossier existant avec du contenu?

À l'heure actuelle, il y /tmpa des fichiers temporaires. Lorsque je monte mon disque dur ( /dev/sdc1) au-dessus de /tmp, je peux voir les fichiers sur le disque dur. Qu'advient-il du contenu réel du /tmpmoment où mon disque dur est monté? Est-il possible d'effectuer des opérations r / w sur le contenu réel de /tmplorsque le disque dur est monté?

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'advient-il du contenu réel de / tmp lorsque mon disque dur est monté?

À peu près rien. Ils sont simplement cachés de la vue, inaccessibles via le parcours normal du système de fichiers.

Est-il possible d'effectuer des opérations r / w sur le contenu réel de / tmp lorsque le disque dur est monté?

Oui. Les processus qui avaient des descripteurs de fichiers ouverts dans votre "original" /tmpcontinueront de pouvoir les utiliser. Vous pouvez également faire "réapparaître" ailleurs en liant le montage /ailleurs.

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

Voici une petite expérience que vous pouvez exécuter pour avoir une meilleure idée (j'espère) de ce qui se passe.

Remarque: Il ne s’agit pas d’une tentative d’être parfaitement correct ni d’une description exhaustive de ce qui se passe réellement. Devrait être juste assez précis pour vous donner une vue d’ensemble cependant.

J'ai créé un utilisateur appelé mesur ma machine et un répertoire aléatoire chez lui, avec un fichier dedans:

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

À ce stade, rien d’inhabituel - c’est juste un répertoire simple avec un fichier brut. Je laisse cette session ouverte en l'état, avec son cwdrépertoire de test.

En tant que root, je crée un petit système de fichiers et le monte /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

J'ouvre alors un nouveau terminal en tant que me, et regarde autour de moi :

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

Donc, le fichier que nous avons créé n’est clairement pas là. Le lost+foundrépertoire est indicatif de la racine d'un système de fichiers ext. Et j'ai perdu la permission d'écriture, ce n'est donc clairement pas le répertoire d'origine.

Retour à la première mesession, regardons comment il voit le monde:

me@home $ echo something else > other_file

Pas de problème pour écrire.

me@home $ cat some_file other_file 
hello
something else

Le fichier original est toujours là, nouveau fichier créé sans problème.

Hein? Que se passe-t-il?

La première session est entrée dans le répertoire avant d'être superposée par la racine qui y a été montée. Cette action de montage n'affecte pas du tout le système de fichiers d'origine. Le processus shell a un descripteur parfaitement valide du répertoire dans le système de fichiers d'origine et peut continuer à interagir avec lui. C'est en quelque sorte courir sous le point de montage du tapis .

La deuxième session est entrée dans le répertoire après la fixation du montage. Donc, il voit le nouveau système de fichiers vide. Et l'administrateur système a borké les autorisations, de sorte qu'il ne peut pas utiliser l'espace demandé ... corrigeons cela.

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

La session 1 peut-elle sortir de dessous le tapis? (Il commence à moisir.)

Sûr! Si la session 1 remonte l'arborescence du système de fichiers en dehors du montage, elle perdra cette poignée vers l'intérieur et suivra le montage comme tout le monde.

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

Même vue que la session n ° 2, nous sommes revenus à la normale.

Mais comment savez-vous que les fichiers n'ont pas disparu? Personne ne regarde plus!

C'est l'un des moments où les fixations deviennent pratiques. Ils vous permettent de monter un système de fichiers déjà monté ailleurs.

me@home $ mkdir ~/bind

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

(Oui, vous pouvez lier-monter un système de fichiers "à l'intérieur de lui-même". Cool astuce, hein?)

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

Ils sont donc bien là, prêts à passer à l'action. C'est simplement qu'ils ne sont pas visibles / accessibles à leur emplacement d'origine, le montage les cache des traversées de répertoire normales.

Je vous encourage à jouer avec cela, ce n'est vraiment pas compliqué une fois que vous avez compris le "truc" qui est joué. Et une fois que vous avez Got It ™, examinez les systèmes de fichiers des syndicats pour en tirer encore plus sur les tapis :-)

Une note cependant: le montage sur /tmpou /var(ou l' un des répertoires OS de base) est vraiment pas une bonne idée une fois que le processus de démarrage est terminé. Un grand nombre d'applications laissent l'état dans ces répertoires et risquent d'être confondues si vous jouez avec des jeux de montage.