Início / server / Perguntas / 1143651
Accepted
Codejoy
Asked: 2023-09-14 01:50:37 +0800 CST

desmontar uma fonte de ligação não funcionará e o dispositivo estará sem espaço

  • 772

Acho que posso ter dado um tiro no pé. Há muito tempo, tentei fazer backup de uma máquina Linux antiga em um NAS usando o comando mount bind:

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

Então percebi que nunca desmontei /mnt/src

Minha pergunta é: isso está ocupando o dobro do espaço que eu tenho? Estou terrivelmente sem espaço e não tenho certeza se estou perseguindo meu rabo tentando excluir arquivos para recuperar espaço.

df -h mostra:

[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 mostra:

[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

fiz uma verificação de espaço no root:

du -xhs * | classificar -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

Não entendo por que algumas pastas grandes como /home são maiores do que o df -h relata, então fiz um mount | grep home e obtive:

[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)

Parece que se eu conseguisse descobrir o que são e como me mudar, poderia conseguir algum espaço para respirar:

/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)

Então, novamente, tudo isso para dizer: meu comando mount --bind de / into /mnt/src ocupou espaço duplo? Há algo que eu não entendi (provavelmente) ao fazer isso? Fiz um lsof /mnt/src e parece que tudo está usando.

mas comecei com isso para relatar que não tenho certeza se é relevante:

[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.

Portanto, não sei por onde começar a excluir arquivos grandes conforme os encontro em /? (mesmo que pareça que /home está em outro lugar?). ls -lh não mostra isso como um link simbólico.

[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

EDIT: Olhei para o arquivo fstab que esclareceu onde as coisas estão:

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

Edição 2: Então percebi que se eu fizesse o comando sort em /mnt/src obteria informações mais precisas....

[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

Mostra-me talvez espaço para limpar em usr (não tenho ideia do que não sou um guru do Linux), var tinha algumas coisas legais que consegui limpar (logs antigos). Ainda estou trabalhando nisso, mas acho que o ponto crucial do que estou perguntando é: devo realmente desmontar esse /mnt/src? ou está tudo bem deixá-lo andar assim, já que toda vez que tento emitir o comando ele diz que está ocupado.

linux

1 respostas

  1. Best Answer

    O problema

    /mnt/srcnão está ocupando espaço, mas você deve desmontá-lo para não confundir algumas ferramentas, incluindo ferramentas de backup. Por exemplo lsblk, opta por exibir a primeira montagem correspondente e exibe /mnt/srcem vez de /qual /dev/vda2não é ideal.

    A maioria dos sistemas Linux executa systemd, então presumo que este sistema esteja executando systemd .

    systemd remonta / como montagem compartilhada em vez do padrão do kernel Linux de private . Veja a documentação do kernel sobre propagação de montagem aqui: Shared Subtrees . Isso significa que, quando montagens adicionais posteriores são adicionadas (ou removidas e lidas),/elas também são montadas automaticamente/mnt/srcpelo mecanismo de propagação e, como são compartilhadas (em vez de escravas ), a tentativa de desmontá-las /mnt/srctambém as desmontará/ , falhando ( porque estão em uso por processos) ou causando possíveis danos se forem bem-sucedidos (eles também desaparecerão de seu ponto de montagem original).

    O que deveria ter sido feito?

    Sempre faça essas montagens de ligação usando a opção de propagação privada . Enquanto estiver fazendo isso, quando for para fins de backup, faça com que a montagem de ligação seja (re) montada somente leitura:

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

    Dessa forma não acontecerá mais nenhuma interação com outras montagensumount /mnt/src e esta pode ser desmontada a qualquer momento de forma simples e sem nenhum efeito colateral.

    O que pode ser feito para resolver o problema atual?

    Portanto, para fazer isso corretamente, sem afetar os pontos de montagem originais reais, deve-se definir todas as montagens problemáticas como privadas para que possam ser desmontadas sem afetar o ponto de montagem original.

    Faço um exemplo aqui (todos como usuário root ) imitando o caso do OP onde depois de ter feito:

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

    E mais tarde (em um lugar que não pode ser prejudicial):

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

    levando então a:

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

    • identifique montagens problemáticas usando 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

    • Defina todas as montagens compartilhadas encontradas como private , incluindo /mnt/src:

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

    • desmontá-los (na ordem inversa da montagem se houver múltiplas profundidades), finalizando com/mnt/src

      # umount /mnt/src/root/intheway
# umount /mnt/src

    Isso não atrapalhou a montagem (compartilhada) que estava no caminho:

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

relate perguntas