「モバイル共有マウントの下にマウント」を無効にする理由

「モバイル共有マウントの下にマウント」を無効にする理由

mount --moveシステムで実行している場合systemdの使用を開始、が無効になり、上記のメッセージが表示されます。

これはmount --make-private、親マウントで実行してから移動を許可できることを意味します。

しかし、マウントを動かすことができることに気づきました。存在する共有サブツリーに。例えば

mount --make-private /boot/
mount --move /boot/efi /mnt

これらの区別は、取り消しの試みもmount --move /mnt /boot/efi失敗することを意味します。

モバイル共有マウントでマウントを無効にするのはなぜですか?移動マウントが許可される理由存在する共有インストールから?

$ mount --version
mount from util-linux 2.30.2 (libmount 2.30.2: selinux, btrfs, assert, debug)
$ rpm -q util-linux
util-linux-2.30.2-1.fc26.x86_64

答え1

実際、共有の親トピックの下にあるインストールを移動できない理由はどこにも文書化されていません。私はカーネルでこのコードについて多くの研究をしてきました。

たとえば、次のコードを考えてみましょう。

mount --bind /opt /opt
mount --make-shared /opt
mkdir /opt/A
mount --bind /tmp /opt/A

mount --move /opt/A /mnt

の親は/opt/A共有マウントなので、/optそれに属するソースの伝播ツリー全体をからに移動する必要/optがあります/mnt。ただし、対応するマウントポイントがない可能性があるため、/opt元の伝播ツリーに属するすべてのマウントを移動できない状況を想像するのは簡単です。/mntこれは、マウントネームスペースを使用すると簡単に発生する可能性があります。したがって、この場合、ターゲット伝播ツリーにマウントポイントがないマウントは削除する必要があります。ただし、これは umount イベントをトリガーする必要があることを意味します。しかし、他の問題もあります。たとえば、umountイベントを伝播する必要があると主張することもできます。ただし、これは移動したいインストールツリー全体が削除されることを意味します。何らかの形で山の木が重なっていればさらにひどい。そこには隠された複雑さがたくさんあるので、単にブロックされました。

関連情報