항상 이렇지는 않았지만 이제는 일관되지 않은 동작이 발생합니다. 바인드 마운트는 기존 마운트를 복사하지 않지만(사용하지 않는 한 --rbind) 새 마운트는 자동으로 복사(및 마운트 해제)됩니다. 이것은 버그인 것 같습니다. 원인은 무엇입니까?
# mount --bind / /mnt/tmp
# mount | grep /mnt
/dev/mapper/fedora-root on /mnt/tmp type ext4 (rw,relatime,seclabel,data=ordered)
# mount /var/lib/docker
# mount | grep mnt
/dev/mapper/fedora-root on /mnt/tmp type ext4 (rw,relatime,seclabel,data=ordered)
/dev/mapper/fedora-docker on /mnt/tmp/var/lib/docker type ext4 (rw,relatime,seclabel,data=ordered)
이는 Fedora Workstation 23에서 발생합니다. 나는 데비안 8도 영향을 받을 것이라고 믿습니다.
다른 프로세스 없이 bash를 시작하면 이런 일이 발생하지 않습니다 init=/bin/bash. 즉, Linux 커널에 고유한 것이 아닌 것 같습니다.
이는 루트 파일 시스템에서 새 마운트 지점으로 파일을 이동하는 가장 쉬운 방법이었기 때문에 짜증나는 일입니다. SELinux를 사용하는 것은 파일에 자동으로 태그가 지정되어 cp그러한 작업이 필요 없기 때문에 특히 편리합니다(적어도 ?를 사용하는 경우).restorecon
답변1
mount --make-private마운트 지점에서 실행 중인 경우 새 마운트 중지가 복사되는 것을 볼 수 있습니다.
bash를 init로 실행하는 것의 차이점은 다음과 같습니다.원천파일 시스템이 비공개로 마운트됩니다. [*] 부팅하는 동안 전체 시스템이 효과적으로 실행됩니다 --make-shared. 를 보면 차이점을 알 수 있습니다 findmnt -o +PROPAGATION.
루트 파일 시스템이 공유로 마운트되면 바로 아래에 마운트된 모든 파일 시스템은 동일한 전파 설정을 상속합니다.
루트 파일 시스템이 공유로 다시 마운트되고 있습니다 systemd. 이 기능은 2012년경에 systemd에 추가되었습니다. 이것은 놀라운 Arch Linux 위키에서 논의됩니다.
https://github.com/systemd/systemd/commit/b3ac5f8cb98757416d8660023d6564a7c411f0a0
이 기사를 읽으면서 다음 방법을 배우는 것도 좋습니다.안전한 분해재귀 바인드 설치. 공유 마운트에서는 마운트하기 때문에제거하고전파는 양방향으로 진행됩니다 :-).
[*] boot 를 사용하면 init=/bin/bash파일 시스템이 비공개로 마운트된 것을 볼 수 있습니다. 여전히 Fedora의 dracutinitramfs를 사용하여 부팅하지만 내부적으로는 systemd로 실행됩니다. 여기서 무슨 일이 일어나고 있는지 100% 확신할 수 없습니다.
답변2
왜 이런 일이 발생하는지 모르겠지만 이를 피할 수 있는 방법을 찾았습니다. 적어도 대부분의 파일 시스템에서는 바인드 마운트를 사용하는 대신 다시 마운트할 수 있습니다.
편집: 이 기능을 사용하면 고유한 문제가 발생합니다. 두 번째로 파일 시스템을 마운트하면 전달한 모든 파일 시스템별 마운트 옵션이 무시됩니다.
# mount /dev/mapper/fedora-root /mnt/tmp
# mount | grep /mnt/tmp
/dev/mapper/fedora-root on /mnt/tmp type ext4 (rw,relatime,seclabel,data=ordered)
# mount /var/lib/docker
# mount | grep /mnt/tmp
/dev/mapper/fedora-root on /mnt/tmp type ext4 (rw,relatime,seclabel,data=ordered)