Dispositif Umount après bind directorys de assembly: est-il sûr?

J'ai une partition à la maison qui est partagée par plusieurs distros sur la même boîte. J'utilise bind mount de fstab . Chaque installation de Linux a quelque chose comme ceci:

 UUID=[...] /mnt/data ext4 nodev,nosuid 0 2 /mnt/data/arch /home none defaults,bind 0 0 /mnt/data/files /files none defaults,bind 0 0 

L'inconvénient est bien sûr que /mnt/data/arch et /mnt/data/files sont maintenant montés deux fois. Sur un coup d'oeil, j'ai essayé umount /mnt/data , qui semble fonctionner comme je l'avais espéré: selon mount , l'appareil est maintenant uniquement monté sur /home et /files .

Mes questions sont les suivantes:

  1. Est-ce sûr , ou suis-je oublie quelque chose?
  2. Est-il possible d'get le même effet que umount /mnt/data utilisant uniquement fstab ? Ou pourrais-je le faire dans rc.local ?

Il est sûr de démonter l'une des copys montées en bind. Après avoir exécuté mount --bind /foo /bar , le kernel ne garde pas la trace de /foo ou /bar premier, ce sont deux points de assembly pour le même système de files (ou une partie de système de files).

Notez que si /foo est un sharepoint assembly mais que /foo/wibble ne l'est pas, mount --bind /foo/wibble /bar fait pointer /bar vers une partie du système de files monté sur /foo . Il est toujours correct de démonter /foo .

Donc, si vous montez /mnt/data , puis liez des parties de /home et /files , et démontez /mnt/data , vous n'avez plus access aux parties de /mnt/data dehors de l' arch et des files . Si cela ne vous dérange pas, allez-y.

Vous ne pouvez pas y parvenir grâce à fstab : il ne supporte que le assembly des filesystems. Les montures Bind entrent par le biais d'un hack (l'option bind mount est transformée en une option --bind en interne). mount --move et mount --move ne peut pas être spécifié dans fstab . Vous pouvez utiliser /etc/rc.local pour appeler umount .