Sistema de arquivos Linux; diferença no cálculo do tamanho usando df e du

Quando executo df, mostra que o dispositivo raiz está cheio.

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             9.9G  9.4G     0 100% /

Eu olhei para o inodeuso e há praticamente espaço disponível para o dispositivo raiz

Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/sda1               640K    103K    538K   16% /

Mas, quando eu executar o ducomando, ele mostra que tenho usado apenas 2Gfora de 9.9G.

ip-XXX-XXX-XXX-XXX:/$ du -xh --max-depth=1
14M ./etc
4.0K ./mnt
96K ./tmp
3.5M ./bin
0   ./sys
964K ./boot
4.0K ./srv
0   ./dev
55M ./lib
25M ./root
1.1G ./usr
4.0K ./opt
846M ./var
4.3M ./sbin
23M ./home
16K ./lost+found
0   ./proc
2.0G .

Isso só me deixa louco e interessante também. Esse é um grande problema para nós, pois o disco raiz /está cheio e algumas das funções do nosso site estão falhando.

Por favor, ajude-me a resolver (também entender) esse problema.

Obrigado.

Quando os arquivos são excluídos no * nix, eles permanecem no disco (e ocupam espaço em disco) enquanto o processo os abrir. É bastante comum tirar vantagem disso para "proteger" os arquivos temporários, criando-os com um tamanho pequeno, excluindo-os e depois usando o arquivo excluído para armazenar dados sem ter que se preocupar com outros processos (facilmente) obtendo acesso a eles, portanto a quantidade de espaço nos arquivos excluídos pode aumentar bastante se, digamos, um banco de dados temporário ou uma sessão de edição de multimídia estiverem sendo tratados dessa maneira. Outra possibilidade de como você poderia ter tanto espaço "perdido" seria se o sistema fosse atualizado (várias vezes) sem reiniciar ou reiniciar programas, resultando em todas as suas antigas bibliotecas .so sendo mantidas abertas por programas iniciados antes da instalação. atualizar e ainda estão em execução.

dfvê o espaço usado por esses arquivos porque apenas analisa quanto espaço está alocado no dispositivo, mas dunão os vê porque não existem entradas de diretório correspondentes.

Um espaço usado "oculto" como esse só pode ser liberado quando processos que excluíram arquivos abertos os fecham. Você pode encontrar esses processos com o fusercomando e finalizá-los (ou, por muitos daemons, enviar um sinal solicitando que eles fechem e reabram todos os arquivos abertos).

Houve momentos em que, se o disco ficar cheio, ele poderá ser confundido até a reinicialização / remontagem de que o disco ainda está cheio, mesmo quando você excluiu uma carga de arquivos.

Do meu lado, simplesmente reiniciei o syslogd para recuperar o espaço em disco. Eu tinha 3 GB faltando! Meu servidor estava em funcionamento há 250 dias.

Existe uma maneira de limpar o espaço sem reiniciar o aplicativo. Aqui estão os detalhes:

1. Digamos que você tenha um processo em fooexecução e criando um arquivo de 2 GB chamado abc.log. Agora diga que este abc.log foi excluído por outra pessoa.

2. Seja foopid (digamos 123). Então /proc/123/fd, mostrará a lista de descritores de arquivos abertos por foo. Um com abc.log será exibido como excluído. Digamos que fdabs.log é 111. Se você executar less /proc/123/fd/111, ele ainda mostrará todos esses 2 GB de dados.

3. Corra echo " " > /proc/123/fd/111. Isso substituirá o conteúdo por uma sequência vazia. Após esse comando, se você tentar, dfele mostrará 2 GB adicionais recuperados limpando o abc.log.

É isso aí. Eu tentei isso no CentOS e funciona.