Inconsistência no espaço livre da partição raiz XFS

Question

há algum tempo (acho que começou depois da minha atualização para o 16.04) comecei a receber notificações sobre ir baixo com espaço livre na partição raiz. Primeiro eu pensei que poderia ser devido a pacotes mantidos dentro de / var / cache após a atualização, então eu mudei as pastas para outra partição e sym as vinculou ao local original. Isso ajudou, mas não por muito tempo. Então notei que tenho alguns kernels antigos e cabeçalhos associados, então os limpei. Isso me deu cerca de 1GB de espaço extra, que depois desapareceu novamente. Estes são meus pontos de montagem e seu uso atual, conforme mostrado por df -h :

Filesystem      Size  Used Avail Use% Mounted on
udev            981M     0  981M   0% /dev
tmpfs           200M   19M  181M  10% /run
/dev/sda6       8.0G  8.0G   16M 100% /
/dev/sda7        32G   16G   17G  49% /usr
tmpfs           999M  300K  999M   1% /dev/shm
tmpfs           5.0M  8.0K  5.0M   1% /run/lock
tmpfs           999M     0  999M   0% /sys/fs/cgroup
/dev/sda9       270G   41G  216G  16% /repo
/dev/sda8        99G   91G  2.6G  98% /home
/dev/sda10      504G  162G  317G  34% /mnt/media
cgmfs           100K     0  100K   0% /run/cgmanager/fs
tmpfs           200M   64K  200M   1% /run/user/1000
/dev/sr2         48M   48M     0 100% /mnt/usb-HUAWEI_Mass_Storage-0:0

Como você pode ver, / ( /dev/sda6 ) está praticamente cheio. Quando eu executo sudo du -h -x --max-depth=1 / , obtenho:

469M    /var
24M     /etc
0       /media
13M     /bin
54M     /boot
326M    /lib
198M    /opt
6.9M    /root
15M     /sbin
0       /srv
8.0K    /tmp
0       /cdrom
0       /mnt
0       /snap
1.1G    /

que, tanto quanto eu posso dizer, me mostra muito menos do que 8GB sendo usado. Eu tenho usado o linux na minha área de trabalho desde os anos 90, mas aparentemente estou perdendo algo aqui que não posso explicar. Como descubro o que está consumindo espaço no meu / ?

[EDITAR]: Eu tentei a solução apresentada aqui: link (allocsize = opção 64k), mas nenhum espaço foi liberado.

[EDIT 2]: Comentário de Per Andrius, saída de xfs_db :

magicnum = 0x58465342
blocksize = 4096
dblocks = 2096474
rblocks = 0
rextents = 0
uuid = 3a3ee397-d4e5-40f1-b179-94f3c0b566ac
logstart = 1048580
rootino = 128
rbmino = 129
rsumino = 130
rextsize = 1
agblocks = 524119
agcount = 4
rbmblocks = 0
logblocks = 2560
versionnum = 0xb4b4
sectsize = 512
inodesize = 256
inopblock = 16
fname = "u.rootFilesystem      Size  Used Avail Use% Mounted on
udev            981M     0  981M   0% /dev
tmpfs           200M   19M  181M  10% /run
/dev/sda6       8.0G  8.0G   16M 100% /
/dev/sda7        32G   16G   17G  49% /usr
tmpfs           999M  300K  999M   1% /dev/shm
tmpfs           5.0M  8.0K  5.0M   1% /run/lock
tmpfs           999M     0  999M   0% /sys/fs/cgroup
/dev/sda9       270G   41G  216G  16% /repo
/dev/sda8        99G   91G  2.6G  98% /home
/dev/sda10      504G  162G  317G  34% /mnt/media
cgmfs           100K     0  100K   0% /run/cgmanager/fs
tmpfs           200M   64K  200M   1% /run/user/1000
/dev/sr2         48M   48M     0 100% /mnt/usb-HUAWEI_Mass_Storage-0:0

0

469M    /var
24M     /etc
0       /media
13M     /bin
54M     /boot
326M    /lib
198M    /opt
6.9M    /root
15M     /sbin
0       /srv
8.0K    /tmp
0       /cdrom
0       /mnt
0       /snap
1.1G    /

0

magicnum = 0x58465342
blocksize = 4096
dblocks = 2096474
rblocks = 0
rextents = 0
uuid = 3a3ee397-d4e5-40f1-b179-94f3c0b566ac
logstart = 1048580
rootino = 128
rbmino = 129
rsumino = 130
rextsize = 1
agblocks = 524119
agcount = 4
rbmblocks = 0
logblocks = 2560
versionnum = 0xb4b4
sectsize = 512
inodesize = 256
inopblock = 16
fname = "u.root%pre%0%pre%0%pre%0%pre%0%pre%0%pre%0"
blocklog = 12
sectlog = 9
inodelog = 8
inopblog = 4
agblklog = 19
rextslog = 0
inprogress = 0
imax_pct = 25
icount = 60800
ifree = 27330
fdblocks = 2970
frextents = 0
uquotino = nic
gquotino = nic
qflags = 0
flags = 0
shared_vn = 0
inoalignmt = 2
unit = 0
width = 0
dirblklog = 0
logsectlog = 0
logsectsize = 0
logsunit = 1
features2 = 0x8
bad_features2 = 0x8

0%pre%0%pre%0%pre%0" blocklog = 12 sectlog = 9 inodelog = 8 inopblog = 4 agblklog = 19 rextslog = 0 inprogress = 0 imax_pct = 25 icount = 60800 ifree = 27330 fdblocks = 2970 frextents = 0 uquotino = nic gquotino = nic qflags = 0 flags = 0 shared_vn = 0 inoalignmt = 2 unit = 0 width = 0 dirblklog = 0 logsectlog = 0 logsectsize = 0 logsunit = 1 features2 = 0x8 bad_features2 = 0x8     

Answer 1

Eu corri xfs_check e mostrou que há mais espaço alocado do que ser usado. Eu tentei xfs_repair e consertei o problema. Pelo que entendi, o problema era semelhante ao que às vezes ocorria com partições FAT que eram propensas a erros de 'clusters perdidos'. No entanto, ainda não sei o que foi responsável por isso e como preceder problemas semelhantes no futuro.

    

Answer 2

Isso é bastante interessante, mas é que o xfs mantém metadados sobre os arquivos no sistema de arquivos xfs internamente, mas isso não parece ser captado pelo du mas é pelo df. No entanto, xfs tem seu próprio comando xfs_estimate. O df mostra corretamente o espaço livre usado na partição xfs. Eu descobri que executar sudo du -h -x --max-depth=0 /path ; sudo xfs_estimate /path sudo pode ser nesecary no caso de existirem arquivos que seu usuário normal não pode ver como máquinas virtuais kvm / qemu por defualt que são uma coisa em / que ocupam muito espaço. Por exemplo, quando executo sudo du -h -x --max-depth=0 /path ; sudo xfs_estimate /path em / etc com muitos arquivos de configuração pequenos Isso mostra / etc como ocupar 13 MB de espaço, mas a estimativa do xfs mostra que ele precisará de uma partição de 20 MB que parece que você está usando 65% no seu du comando, mas na realidade, os metadados estão usando o resto. Então, no final xfs_estimate pode te dizer muito.