15 GB de espaço não contabilizado no sistema de arquivos

1
[nathanb /mnt/work] sudo du -hs .
23G .
[nathanb /mnt/work] df -h .
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1        40G   38G  6.4M 100% /mnt/work

Onde estão os outros 15 GB?

/dev/sdb1 on /mnt/work type ext4 (rw,nosuid,nodev,relatime,data=ordered)

Atualizando para responder aos comentários

[nathanb /mnt/work] sudo tune2fs -l /dev/sdb1
tune2fs 1.42.5 (29-Jul-2012)
Last mounted on:          /mnt/work
Inode count:              2621440
Block count:              10485752
Reserved block count:     524287
Free blocks:              3955615
Free inodes:              2522921
First block:              0
Block size:               4096
Fragment size:            4096

e

[nathanb /mnt/work] df -i .
Filesystem      Inodes IUsed   IFree IUse% Mounted on
/dev/sdb1      2621440 29764 2591676    2% /mnt/work

e

[nathanb /mnt/work] sudo fsck -n /dev/sdb1
fsck from util-linux 2.20.1
e2fsck 1.42.5 (29-Jul-2012)
Warning!  /dev/sdb1 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
/dev/sdb1: clean, 98519/2621440 files, 6530137/10485752 blocks

e

[nathanb /mnt/work] sudo lsof | grep deleted
[nathanb /mnt/work]

Não há pontos de montagem abaixo de / mnt / work

[nathanb /mnt/work] grep /mnt/work /proc/self/mountinfo
22 19 8:17 / /mnt/work rw,nosuid,nodev,relatime - ext4 /dev/sdb1 rw,data=ordered

Bem, de todas as coisas ... parece estar funcionando novamente. E como não tenho ideia do que causou o problema, não tenho ideia do que o consertou.

[nathanb /mnt/work] df -h .
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1        40G   22G   16G  59% /mnt/work

Eu tinha desmontado alguns dos clientes do NFS batendo o volume em preparação para desmontar e checar, mas eu não tinha desmontado todos eles ... e eu verifiquei logo após a desmontagem e o espaço não tinha ido baixa. Mas então eu voltei de fazer algum outro trabalho e notei que ele estava solto.

Irritante e insatisfatório ... gostaria de saber qual era o problema, então poderia atribuir alguns pontos a algumas pessoas ... obrigado por toda a ajuda, porém, e se isso acontecer novamente, tentarei obter mais análises forenses. .

    
por Nathan 02.02.2015 / 19:38

2 respostas

1

Dado que o sistema de arquivos foi exportado via NFS, há uma boa chance de que a discrepância seja devida a arquivos excluídos ... Se arquivos forem apagados enquanto abertos em clientes NFS, lsof no servidor não os verá porque não não é /proc/.../fd entrada correspondente a eles; mas eles ainda ocuparão espaço em disco, como visto por df .

Diagnosticar isso requer a execução de lsof com a opção -N em todos os clientes.

(Isso não explica o atraso que você viu na recuperação do espaço depois de desmontar o volume dos clientes, mas é a melhor explicação que posso imaginar para o restante dos sintomas.)

    
por 03.02.2015 / 06:50
0

fuser -k -M -m /mnt/work deve estar no salto. Aviso! ele literalmente mata processos acessando / mnt / work. Inclua -TERM para solicitar o encerramento.

O culpado é os arquivos excluídos que são mantidos abertos, o que não é possível ver, mas o df pode.

Por exemplo,

$ df -h .
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda6       209M   66M  128M  35% /boot
$ sudo du -sh .
64M     .
$  sudo fallocate -l 100M tmp_file
$ ls -lh tmp_file
-rw-r--r-- 1 root root 100M Feb  3 02:24 tmp_file
$ df -h .
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda6       209M  166M   28M  86% /boot
$ sudo du -sh .
164M    .
$ exec 20<tmp_file
$ sudo rm tmp_file
$ df -h .
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda6       209M  166M   28M  86% /boot
$ sudo du -sh .
64M     .

O tmp_file ainda está aberto. Se estiver fechado, 'df' pode ver livre.

$ exec 20<&-
$ df -h .
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda6       209M   66M  128M  35% /boot
    
por 02.02.2015 / 21:40