Tentando copiar dir no servidor, mas o servidor fica cheio mesmo que a pasta seja menor que o espaço livre no disco

Question

Problema

Estou tentando copiar um diretório com 112 GB para um RAID em um servidor que tenha 214 GB de espaço livre usando scp . No entanto, depois de copiar alguns arquivos, recebo uma mensagem informando que o disco está cheio e, depois de verificar, posso ver que o disco está realmente cheio. Eu não entendo como isso é possível e gostaria de entender e resolver isso.

Detalhes

Estou usando o CentOS 7. Acabei de instalar o sistema operacional no ataque antes de tentar copiar o diretório. Esta é a saída de df -h logo após instalá-lo:

[user@localhost ~]$ df -h
Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/centos-root   50G  897M   50G   2% /
devtmpfs                 7,8G     0  7,8G   0% /dev
tmpfs                    7,8G     0  7,8G   0% /dev/shm
tmpfs                    7,8G  8,9M  7,8G   1% /run
tmpfs                    7,8G     0  7,8G   0% /sys/fs/cgroup
/dev/sda1               1014M  143M  872M  15% /boot
/dev/mapper/centos-home  214G   33M  214G   1% /home
tmpfs                    1,6G     0  1,6G   0% /run/user/1000

Eu estou tentando copiar o diretório via scp do meu notebook que roda o Ubuntu 17.04. Este é o tamanho da pasta:

rick@rick-Inspiron-5448:~$ sudo du -hs /home/rick/
112G    /home/rick/

Como você pode ver, há pouco menos de 214 GB de espaço livre no RAID do servidor, e o diretório que estou tentando copiar tem apenas 112 GB.

Eu copio usando

$ scp -r /home/rick/ [email protected]:/home/user/backup

Funciona bem por algumas horas e, em seguida, recebo a seguinte saída repetidamente:

scp: /home/user/backup/rick/<filename>: No space left on device

Se eu digitar df -h , posso verificar se o disco está realmente cheio!

[user@localhost ~]$ df -h
Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/centos-root   50G  897M   50G   2% /
devtmpfs                 7,8G     0  7,8G   0% /dev
tmpfs                    7,8G     0  7,8G   0% /dev/shm
tmpfs                    7,8G  8,8M  7,8G   1% /run
tmpfs                    7,8G     0  7,8G   0% /sys/fs/cgroup
/dev/sda1               1014M  143M  872M  15% /boot
/dev/mapper/centos-home  214G  214G   20K 100% /home
tmpfs                    1,6G     0  1,6G   0% /run/user/1000

Então, o que eu entendo é que tentei copiar 112 GB em um disco com 214 GB, mas de alguma forma o disco foi preenchido antes que a cópia fosse concluída. Eu sei que estou perdendo alguma coisa aqui, mas não consigo ver o quê.

Esta é a informação sobre o RAID que eu configurei no servidor:

Se houver algum outro detalhe que eu possa fornecer para esclarecer minha situação, é só me avisar.

Atualizar

@AFH comentou que o problema poderia estar relacionado aos i-nodes, então eu corri

$ df -i
Filesystem                Inodes  IUsed    IFree IUse% Mounted on
/dev/mapper/centos-root 26214400  25686 26188714    1% /
devtmpfs                 2024232    474  2023758    1% /dev
tmpfs                    2026995      1  2026994    1% /dev/shm
tmpfs                    2026995    579  2026416    1% /run
tmpfs                    2026995     16  2026979    1% /sys/fs/cgroup
/dev/sda1                 524288    328   523960    1% /boot
/dev/mapper/centos-home   127080 126903      177  100% /home
tmpfs                    2026995      1  2026994    1% /run/user/1000

Além disso, a saída de fdisk

$ sudo fdisk -l
Disk /dev/sda: 292.3 GB, 292326211584 bytes, 570949632 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x000b2997

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048     2099199     1048576   83  Linux
/dev/sda2         2099200   570949631   284425216   8e  Linux LVM

Então, na verdade, os inodes estão cheios. Alguma sugestão sobre como resolvê-lo?

    

Answer 1

Depois de algum tempo, descobri como resolver o problema. O problema foi que quando eu usei scp para copiar os arquivos, a pasta que contém wine tinha um tamanho completamente diferente no destino que tinha na origem.

Não tenho certeza se isso estava relacionado à wine copy ocupando mais i-nodes do que deveria, ou se o vinho estava sendo recursivamente copiado dentro de sua pasta, mas quando eu verifiquei com a pasta df -h , wine tinha 1,5 GB na fonte e 101 GB no servidor, que era o destino de scp .

Limpei o disco no servidor e fiz o backup usando rsync em vez de scp e funcionou muito bem.

Obrigado por todos que ajudaram, foi um final de semana difícil.

    

Answer 2

A sua cópia de backup tem links simbólicos? Se sim, use o rsync para copiar o conteúdo. Scp com a opção -r segue os links simbólicos também.

    

Answer 3

So, in fact, inodes are full. Any suggestions about how to solve it?

Você não pode aumentar o número de inodes sem reformatar o sistema de arquivos.

Atualmente, você tem cerca de 120 GB de espaço que não pode usar porque não possui os inodes para isso.

O que você pode tentar é:

• reduz o tamanho do sistema de arquivos na partição LVM (PERIGOSA) em cerca de 110 GB usando, por exemplo, resize2fs ,
• reduza a partição do LVM para caber exatamente no sistema de arquivos (também perigoso),
• crie uma nova partição no espaço livre
• a nova partição agora pode ser montada.

Por exemplo, você pode ver se possui alguns diretórios que podem caber em 110 GB de espaço (/ home / user / downloads e assim por diante), mover o conteúdo desse diretório na nova partição e, em seguida, montar a partição em o diretório antigo. Agora você tem um espaço livre (e inodes) disponível igual ao tamanho dos arquivos movidos.

Toda a operação precisa de um planejamento cuidadoso e eu recomendo strongmente um backup completo.