主页 / server / 问题 / 1143651
Accepted
Codejoy
Asked: 2023-09-14 01:50:37 +0800 CST

卸载绑定源不起作用，并且设备空间不足

  • 772

我想我可能是搬起石头砸自己的脚。很久以前，我尝试使用 mount bind 命令将旧的 Linux 机器备份到 nas：

mount --bind / /mnt/src tar -C /mnt/src -c 。> /mnt/backup_to_nas/full-backup-.tar.gz date '+%d-%B-%Y'--exclude=tmp --exclude=mnt

然后我意识到我从未卸载/mnt/src

我的问题是，这是否占用了我所拥有的 / 空间的两倍？我的空间严重不足，不确定我是否在追着尾巴试图删除文件以恢复空间。

df -h 显示：

[root@web-server mnt]# df -h
Filesystem                        Size  Used Avail Use% Mounted on
devtmpfs                          1.9G     0  1.9G   0% /dev
tmpfs                             1.9G  4.0K  1.9G   1% /dev/shm
tmpfs                             1.9G  194M  1.7G  11% /run
tmpfs                             1.9G     0  1.9G   0% /sys/fs/cgroup
/dev/vda2                         7.6G  7.6G     0 100% /
/dev/vda1                         190M  171M  5.3M  98% /boot
/dev/vdb                          230G  152G   67G  70% /usr/local
tmpfs                             379M     0  379M   0% /run/user/0
tmpfs                             379M     0  379M   0% /run/user/2527
tmpfs                             379M     0  379M   0% /run/user/2543
10.50.1.104:/data                 9.1T  8.0T  610G  94% /mnt/backup
tmpfs                             379M     0  379M   0% /run/user/2539
10.75.0.199://volume1/ICCBackups   32T  4.2T   28T  14% /mnt/backup_to_nas
tmpfs                             379M     0  379M   0% /run/user/500

lsblk 显示：

[root@web-server mnt]# lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
vda    253:0    0     8G  0 disk 
├─vda1 253:1    0   200M  0 part /boot
└─vda2 253:2    0   7.8G  0 part /mnt/src
vdb    253:16   0 232.8G  0 disk /usr/local

在 root 中进行了空间检查：

杜 -xhs * | 排序-rh

134G    home
15G data
6.9G    mnt
186M    run
170M    boot
52M etc
848K    ARC-History.pdf
16K lost+found
8.0K    export
8.0K    backup
4.0K    media
4.0K    check_permissions.py
0   sys
0   proc
0   lib64
0   lib
0   dev
0   bin

我不明白为什么像 /home 这样的一些大文件夹比 df -h 报告的大，所以我做了一个 mount | grep home 并得到：

[root@web-server mnt]# mount | grep home
/dev/vdb on /home type ext4 (rw,relatime,data=ordered)
/dev/vda2 on /home/weather/public_html/weather_rrd type ext4 (rw,relatime,data=ordered)
/dev/vda2 on /usr/local/home/weather/public_html/weather_rrd type ext4 (rw,relatime,data=ordered)
/dev/vdb on /home/workers/public_html/VM-SYSTEMS type ext4 (rw,relatime,data=ordered)
/dev/vdb on /usr/local/home/workers/public_html/VM-SYSTEMS type ext4 (rw,relatime,data=ordered)

看来如果我能弄清楚这些是什么以及如何重新安置，我可能会给自己赢得一些喘息的空间：

/dev/vda2 on /home/weather/public_html/weather_rrd type ext4 (rw,relatime,data=ordered)
/dev/vda2 on /usr/local/home/weather/public_html/weather_rrd type ext4 (rw,relatime,data=ordered)

再说一遍，我的 mount --bind 命令 / 进入 /mnt/src 是否占用了双倍空间？这样做时有什么我不明白（可能）的事情吗？我做了一个 lsof /mnt/src ，似乎一切都在使用它。

但确实以此开始报告不确定是否相关：

[root@web-server mnt]# lsof /mnt/src
lsof: WARNING: can't stat() ext4 file system /var/www/html/net-status/bw-mon (deleted)
      Output information may be incomplete.
lsof: WARNING: can't stat() ext4 file system /usr/local/www/net-status/bw-mon (deleted)
      Output information may be incomplete.

所以不确定从哪里开始删除大文件，因为我在 / 中找到了它们？（即使 /home 似乎在其他地方？）。ls -lh 不将其显示为符号链接。

[root@web-server /]# ls -lh
total 1.2M
-rw-------    1 root root 847K Jul 27  2020 ARC-History.pdf
drwxr-xr-x    3 root root 4.0K Sep 13 17:21 backup
lrwxrwxrwx    1 root root    7 May 11  2018 bin -> usr/bin
dr-xr-xr-x.   5 root root 3.0K Aug 16 18:06 boot
-rw-r--r--    1 root root 3.3K May 12  2019 check_permissions.py
-rw-------    1 root root    0 Sep 13 17:33 core.20448
-rw-------    1 root root    0 Sep 13 17:46 core.28055
drwxr-xr-x    7 root root 4.0K Sep 13 17:16 data
drwxr-xr-x   18 root root 3.1K Sep 12 18:08 dev
drwxr-xr-x. 148 root root  12K Aug 31 17:26 etc
drwxr-xr-x    3 root root 4.0K Apr  2  2015 export
drwxr-xr-x   22 root root 4.0K Aug 27 18:06 home
lrwxrwxrwx    1 root root    7 May 11  2018 lib -> usr/lib
lrwxrwxrwx    1 root root    9 May 11  2018 lib64 -> usr/lib64
drwx------.   2 root root  16K Mar 31  2015 lost+found
drwxr-xr-x.   2 root root 4.0K Apr 12  2018 media
drwxr-xr-x.   6 root root 4.0K Feb  9  2023 mnt
drwxr-xr-x.   7 root root 4.0K Aug 25 15:13 opt
dr-xr-xr-x  225 root root    0 Nov  8  2021 proc
dr-xr-x---.  26 root root  12K Aug 25 15:19 root
drwxr-xr-x   48 root root 1.5K Sep 13 17:01 run
lrwxrwxrwx    1 root root    8 May 11  2018 sbin -> usr/sbin
-rw-r--r--    1 root root    0 May 15  2019 searchresults.txt
drwxr-xr-x.   2 root root 4.0K Apr 12  2018 srv
dr-xr-xr-x   13 root root    0 Nov 29  2021 sys
drwxrwxrwt.  16 root root 244K Sep 13 17:49 tmp
drwxr-xr-x.  14 root root 4.0K May 11  2018 usr
drwxr-xr-x.  25 root root 4.0K Aug  9 20:21 var
drwxr-xr-x    2 root root 4.0K Aug  9  2015 zaphod-data

编辑：查看了 fstab 文件，该文件揭示了内容的位置：

UUID=c9d6c99f-d7a5-4117-93ba-029cc34d8b61 /                       ext4    defaults        1 1
UUID=19fcad32-0fcb-423a-87e9-586d03d2e406 /boot                   ext4    defaults        1 2
#LABEL=/home    /home       ext4 defaults 1 2
#192.41.211.105:/export/images      /export/images          nfs     rsize=32768,wsize=32768,actimeo=0,bg,intr
LABEL=local-web-server  /usr/local  ext4    defaults    1 2
/usr/local/home     /home       none    bind        0 0
/usr/local/www      /var/www/html   none    bind        0 0
/usr/local/data     /data       none    bind        0 0
/tmp/rrdweather     /home/weather/public_html/weather_rrd   none    bind    0 0
/usr/local/data     /data       none    bind        0 0
/home/workers/Site/VM-SYSTEMS /home/workers/public_html/VM-SYSTEMS none bind 0 0
#/home/workers/public_html/WebCalendar-1.2.3 /home/workers/public_html/WebCalendar none bind 0 0
#/home/workers/public_html/WebCalendar-1.2.0 /home/workers/public_html/WebCalendar~ none bind 0 0
/home/workers/public_html/net-status /usr/local/www/net-status none bind 0 0
/tmp/bw-mon     /var/www/html/net-status/bw-mon     none    bind        0 0
/var/lib/smokeping/images /var/www/html/smokeping/images none   bind        0 0

#mounting for our cheezy backup of web-server
10.50.1.104:/data /mnt/backup nfs

编辑2：所以我意识到如果我在 /mnt/src 中执行排序命令我会得到更准确的信息......

[root@web-server src]# du -xhs * | sort -rh
4.8G    usr
707M    var
421M    opt
397M    backup
168M    root
150M    tmp
52M etc
848K    ARC-History.pdf
16K lost+found
12K mnt
8.0K    export
4.0K    zaphod-data
4.0K    sys
4.0K    srv
4.0K    run
4.0K    proc
4.0K    media
4.0K    home
4.0K    dev
4.0K    data
4.0K    check_permissions.py
4.0K    boot
0   searchresults.txt
0   sbin
0   lib64
0   lib
0   core.28055
0   core.20448
0   bin

向我展示了 usr 中可能需要清除的空间（不知道我不是 Linux 专家），var 有一些我能够清除的好东西（旧日志）。仍在努力，但我想我要问的关键是我真的应该卸载 /mnt/src 吗？或者让它像这样行驶可以吗，因为每次我尝试发出命令时它都会说它很忙。

linux

1 个回答

  1. Best Answer

    问题

    /mnt/src不占用空间，但您应该卸载它，以免混淆某些工具，包括进行备份的工具。例如lsblk，选择显示第一个匹配的安装并显示不是/mnt/src最佳的。//dev/vda2

    大多数 Linux 系统都运行systemd所以我假设这个系统正在运行systemd。

    systemd重新挂载/ 为共享挂载，而不是 Linux 内核默认的私有挂载。请参阅此处有关挂载传播的内核文档：共享子树。这意味着，当以后添加（或删除和读取）额外的挂载时，通过传播机制/自动挂载，并且由于它是共享的（而不是从属），尝试从 卸载它们也会从 卸载它们，要么失败（因为正在被进程使用）或如果成功则可能造成伤害（它们也将从原始安装点消失）。/mnt/src/mnt/src/

    应该做什么？

    始终使用私有传播选项进行此类绑定安装。同时，当出于备份目的时，还可以将绑定挂载（重新）挂载为只读：

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

    这样就不会与其他安装发生进一步的交互，并且可以随时轻松卸载，umount /mnt/src没有任何副作用。

    可以采取什么措施来解决当前的问题？

    因此，为了在不影响实际原始安装点的情况下正确执行此操作，应该将每个有问题的安装设置为私有，以便可以在不影响原始安装点的情况下卸载它们。

    我在这里举一个例子（全部以root用户身份）模仿 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

    • 将所有找到的共享挂载设置为private，包括/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

相关问题