Estatísticas ambíguas de uso de disco no EC2

Question

Eu tenho o seguinte problema:

df -h mostra:

ubuntu@:~$ df -h
Filesystem             Size  Used Avail Use% Mounted on
/dev/xvda1              32G  9.6G   21G  33% /
udev                   819M   12K  819M   1% /dev
tmpfs                  331M  200K  331M   1% /run
none                   5.0M     0  5.0M   0% /run/lock
none                   827M     0  827M   0% /run/shm

Aqui, vejo que tenho 21 GB disponíveis na partição 32G / .

No entanto, quando tento df -i , obtenho

ubuntu@:~$ df -i
Filesystem             Inodes   IUsed  IFree IUse% Mounted on
/dev/xvda1            2097152 2096964    188  100% /
udev                   209564     382 209182    1% /dev
tmpfs                  211573     274 211299    1% /run
none                   211573       4 211569    1% /run/lock
none                   211573       1 211572    1% /run/shm

Aqui vejo que o uso é de 100%. Não sei por que o uso é mostrado de maneira diferente em ambos.

Em segundo lugar, a pasta /root parece muito estranha para mim:

ubuntu@:/$ ls -al
total 132240
drwxr-xr-x  24 root root      4096 Jan  8 15:04 .
drwxr-xr-x  24 root root      4096 Jan  8 15:04 ..
drwxr-xr-x   2 root root      4096 Mar 27  2013 bin
drwxr-xr-x   3 root root      4096 Mar 21  2013 boot
drwx------   5 root root 135319552 Apr  1 14:11 root
drwxr-xr-x  18 root root       640 Apr  1 14:03 run
drwxr-xr-x   2 root root      4096 Mar 27  2013 sbin

Por que o tamanho do diretório raiz é tão grande? Se eu entrar no diretório /root e digitar ls , o terminal nem responderá. Então estou confuso com isso.

Todas as sugestões serão úteis.

Obrigado.

    

Answer 1

Para sua primeira pergunta, df -h informa o uso do espaço em disco do sistema de arquivos em formato legível por humanos. Humano legível porque relata tamanho como em kb, mb ou gb e não apenas em bytes, enquanto df -i relata a informação do inode ao invés do uso do bloco.

inode , em termos leigos, são dados sobre um arquivo. Algum espaço é necessário para armazenar os dados sobre os arquivos em seu sistema de arquivos. Portanto, se esse espaço estiver cheio, você não poderá armazenar arquivos em seu sistema de arquivos, mesmo que você tenha espaço porque não há espaço para armazenar dados sobre o arquivo que deseja armazenar.

Em segundo lugar, você precisa de permissões de superusuário para ver o que está armazenado em /root pasta, por isso não tenho certeza de como você entrou na pasta /root . A razão pela qual ls está falhando é porque ele não tem permissões de leitura para ler o conteúdo de /root para reportá-lo a você. Para ver por que /root ocupou muito espaço, você precisará de permissões de superusuário para investigar e, a menos que tenha isso, não tenho certeza se você consegue ler o que há dentro dele.

O tamanho da pasta é 4096 porque esse é o tamanho mínimo necessário para armazenar informações sobre seu conteúdo. Se exceder esse tamanho, significa que ele tem muitos arquivos cujas informações exigem essa quantidade de espaço.

Eu recomendaria que você investigasse o conteúdo da pasta /root , já que essa parece ser a razão pela qual seu df -i mostra 100% de utilização.

    

Answer 2

Tudo bem, eu descobri o problema e aqui está a explicação:

Temos algumas tarefas crob em execução que executam scripts PHP e usamos wget -q . Isso por algum motivo cria um arquivo de log pelo nome do script php em /root e o nome do arquivo seria apenas 0 bytes.

Em relação aos arquivos que estão sendo * .php. Não tenho certeza porque isso acontece. Mas precisamos consertar a maneira como o cron está rodando. Desde que eu consertei o problema ontem já alguns milhares de arquivos já criados: /

O cron job tinha cerca de 10 scripts que seriam executados a cada minuto. O que significa 10 entradas de linha a cada minuto. Então, ao longo do ano, criou: 10 x 60 x 24 x 365 = mais de 5,2 milhões de arquivos. Isso causou um tamanho de diretório excepcionalmente grande (130 MB) para /root

Isso também explica por que df -u mostrou que havia "espaço" disponível, mas não havia mais nós livres para escrever os nomes dos arquivos em si.

Em seguida, usando find . -name '*.php*' | xargs rm -v , excluí todos os arquivos de log do php. Levou quase 30 minutos e tudo é perfeito. O uso de disco caiu para apenas 9%!

/root é normal, no entanto, o tamanho do diretório de 130MB permanece inalterado. Não tenho certeza se isso vai mudar. Mas não é uma questão importante por enquanto. Conseguimos consertar o crontab bit e conseguimos um ano para consertar:)