Que se passe-t-il lorsque vous «montez sur» un dossier existant avec son contenu?
Maintenant /tmp contient 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 de /tmp lorsque mon disque dur est monté? Est-il possible d'effectuer des opérations r/w sur le contenu réel de /tmp pendant que 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é?
Presque rien. Ils sont juste cachés à la vue, inaccessibles via la traversée normale du système de fichiers.
Est-il possible d'effectuer des opérations r/w sur le contenu réel de/tmp pendant que le disque dur est monté?
Oui. Les processus qui avaient des descripteurs de fichiers ouverts dans votre "original" /tmp Continueront de pouvoir les utiliser. Vous pouvez également faire réapparaître le "ailleurs" ailleurs en fixant / 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.
Note: Ce n'est pas une tentative d'être parfaitement correct ou une description exhaustive de ce qui se passe réellement. Cela devrait être juste assez précis pour vous donner une vue d'ensemble.
J'ai créé un utilisateur appelé me sur 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 ordinaire avec un fichier ordinaire. Je laisse cette session ouverte telle quelle, avec son cwd dans ce répertoire de test.
En tant que root, je crée un petit système de fichiers et le monte sur /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 ensuite 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, ce fichier que nous avons créé n'est clairement pas là. Le répertoire lost+found Indique la racine d'un système de fichiers ext. Et j'ai perdu l'autorisation d'écriture, donc ce n'est clairement pas le répertoire d'origine.
Revenons à la première session me, regardons comment il voit le monde:
me@home $ echo something else > other_file
Aucun problème d'écriture.
me@home $ cat some_file other_file
hello
something else
Le fichier d'origine 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 le montage racine d'un autre système de fichiers dessus. Cette action de montage n'affecte pas du tout le système de fichiers d'origine. Le processus Shell possède un descripteur parfaitement valide pour le répertoire du système de fichiers d'origine et peut continuer à interagir avec lui. C'est en quelque sorte courir sous le tapis point de montage.
La deuxième session est entrée dans le répertoire après la pose du support. Il voit donc le nouveau système de fichiers vide. Et l'administrateur système a limité les autorisations, il ne peut donc pas utiliser l'espace demandé ... permet de résoudre ce problème.
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 s'échapper sous le tapis? (Ça devient le moisi.)
Sûr! Si la session 1 remonte l'arborescence du système de fichiers hors 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 # 2, nous sommes de retour à 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 montures de liaison 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 monter un système de fichiers de manière "interne". Cool truc, 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 à 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épertoires normales.
Je vous encourage à jouer avec ça, ce n'est vraiment pas compliqué une fois que vous avez compris le "truc" qui se joue. Et une fois que vous l'avez compris, examinez les systèmes de fichiers de l'union pour tirer encore plus de tapis :-)
Une remarque cependant: monter sur /tmp Ou /var (Ou l'un des répertoires principaux du système d'exploitation) n'est vraiment pas une bonne idée une fois le processus de démarrage terminé. De nombreuses applications laissent leur état dans ces répertoires et peuvent devenir très confuses si vous jouez à des jeux de montage autour d'eux.