卸載綁定來源不起作用，且設備空間不足

Question

問題

/mnt/src不佔用空間，但您應該卸載它，以免混淆某些工具，包括進行備份的工具。例如，lsblk選擇顯示第一個符合的安裝並顯示不是/mnt/src最佳的。//dev/vda2

大多數Linux系統都運行系統所以我假設這個系統正在運行系統。

系統重新安裝/ 為共享mount 而非 Linux 核心的預設值私人的。請參閱此處有關掛載傳播的核心文件：共享子樹。這意味著當以後添加（或刪除和讀取）額外的安裝時，它們也會透過傳播機制/自動安裝，並且/mnt/src因為它是共享（而不是奴隸）嘗試卸載它們/mnt/src也會將它們卸載/，要么失敗（因為正在被進程使用），要么如果成功則造成可能的損害（它們也將從原始安裝點消失）。

應該做什麼？

始終使用以下命令進行此類綁定安裝私人的傳播選項。同時，當出於備份目的時，也可以將綁定掛載（重新）掛載為唯讀：

mount --bind --make-private -o ro / /mnt/src

這樣就不再與其他人互動坐騎將會發生，並且可以隨時簡單地卸載，umount /mnt/src沒有任何副作用。

可以採取什麼措施來解決當前的問題？

因此，為了在不影響實際原始掛載點的情況下正確執行此操作，應該將每個有問題的掛載設為私人的因此可以在不影響原始安裝點的情況下卸載它們。

我在這裡舉一個例子（全部為根使用者）模仿OP的情況，完成後：

# mkdir -p /mnt/src
# mount --bind -o ro / /mnt/src

然後（在一個不會造成傷害的地方）：

# mkdir -p /root/intheway
# mount -t tmpfs tmpfs /root/intheway

然後導致：

# umount /mnt/src
umount: /mnt/src: target is busy.

使用識別有問題的安裝findmnt：

# findmnt --kernel --submounts --list -o +PROPAGATION /mnt/src
TARGET                  SOURCE     FSTYPE  OPTIONS                        PROPAGATION
/mnt/src                /dev/vda2  ext4    ro,relatime,errors=remount-ro  shared
/mnt/src/root/intheway  tmpfs      tmpfs   rw,relatime,inode64            shared

設定所有找到的此類共享安裝為私人的，包括/mnt/src：

# mount --make-private /mnt/src/root/intheway
# mount --make-private /mnt/src

卸載它們（如果有多個深度，則按照安裝順序的相反順序），最後使用/mnt/src
```
# umount /mnt/src/root/intheway
# umount /mnt/src
```

這並沒有破壞阻礙的（共享）安裝：

# findmnt --kernel --list -o +PROPAGATION /root/intheway
TARGET         SOURCE FSTYPE OPTIONS             PROPAGATION
/root/intheway tmpfs  tmpfs  rw,relatime,inode64 shared

Answer 1

問題

/mnt/src不佔用空間，但您應該卸載它，以免混淆某些工具，包括進行備份的工具。例如，lsblk選擇顯示第一個符合的安裝並顯示不是/mnt/src最佳的。//dev/vda2

大多數Linux系統都運行系統所以我假設這個系統正在運行系統。

系統重新安裝/ 為共享mount 而非 Linux 核心的預設值私人的。請參閱此處有關掛載傳播的核心文件：共享子樹。這意味著當以後添加（或刪除和讀取）額外的安裝時，它們也會透過傳播機制/自動安裝，並且/mnt/src因為它是共享（而不是奴隸）嘗試卸載它們/mnt/src也會將它們卸載/，要么失敗（因為正在被進程使用），要么如果成功則造成可能的損害（它們也將從原始安裝點消失）。

應該做什麼？

始終使用以下命令進行此類綁定安裝私人的傳播選項。同時，當出於備份目的時，也可以將綁定掛載（重新）掛載為唯讀：

mount --bind --make-private -o ro / /mnt/src

這樣就不再與其他人互動坐騎將會發生，並且可以隨時簡單地卸載，umount /mnt/src沒有任何副作用。

可以採取什麼措施來解決當前的問題？

因此，為了在不影響實際原始掛載點的情況下正確執行此操作，應該將每個有問題的掛載設為私人的因此可以在不影響原始安裝點的情況下卸載它們。

我在這裡舉一個例子（全部為根使用者）模仿OP的情況，完成後：

# mkdir -p /mnt/src
# mount --bind -o ro / /mnt/src

然後（在一個不會造成傷害的地方）：

# mkdir -p /root/intheway
# mount -t tmpfs tmpfs /root/intheway

然後導致：

# umount /mnt/src
umount: /mnt/src: target is busy.

使用識別有問題的安裝findmnt：

# findmnt --kernel --submounts --list -o +PROPAGATION /mnt/src
TARGET                  SOURCE     FSTYPE  OPTIONS                        PROPAGATION
/mnt/src                /dev/vda2  ext4    ro,relatime,errors=remount-ro  shared
/mnt/src/root/intheway  tmpfs      tmpfs   rw,relatime,inode64            shared

設定所有找到的此類共享安裝為私人的，包括/mnt/src：

# mount --make-private /mnt/src/root/intheway
# mount --make-private /mnt/src

卸載它們（如果有多個深度，則按照安裝順序的相反順序），最後使用/mnt/src
```
# umount /mnt/src/root/intheway
# umount /mnt/src
```

這並沒有破壞阻礙的（共享）安裝：

# findmnt --kernel --list -o +PROPAGATION /root/intheway
TARGET         SOURCE FSTYPE OPTIONS             PROPAGATION
/root/intheway tmpfs  tmpfs  rw,relatime,inode64 shared

卸載綁定來源不起作用，且設備空間不足

答案1

問題

應該做什麼？

可以採取什麼措施來解決當前的問題？

相關內容