Ontem, eu deletei 71 GB de arquivos no meu servidor de home / media.
Espaço livre antes: 117 GB
Espaço livre após: 126 GB
Então, em vez de ter 71 GB de espaço livre adicional, eu só tinha 9 GB. Verifiquei novamente se não havia arquivos abertos e realmente excluí 71 GB, e o espaço livre realmente aumentou apenas 9 GB.
Eu também tentei sincronizar, mas sem efeito.
Esta não é a primeira vez que isso acontece. De fato, tenho visto esse comportamento desde anos de vez em quando. Primeiro no ext3, agora no ext4.
Quando isso acontece, posso recuperar o espaço livre desmontando e, em seguida, remontando o sistema de arquivos. Nestes casos, a desmontagem demora até 2 minutos, em vez de quase sem tempo.
Hoje em dia, não consigo desmontar e remontar facilmente o sistema de arquivos, porque ele está permanentemente ocupado com meu software de gravador de vídeo, com o servidor owncloud da minha família e com alguns outros serviços que eu não tinha até agora. E eu não quero me levantar às 3 horas da noite só para desmontar e remontar.
Não, o utilitário 'at' não funcionará porque um dos serviços executa tarefas de longa execução não recuperáveis e, portanto, precisa de uma verificação de estado manual para encontrar um bom momento em que possa ser encerrado, ou seja, uma tarefa acabou de ser concluída .
Mas esta manhã, notei que o espaço foi liberado durante a noite. Parece-me que houve algum tipo de limpeza, e isso pode ser a mesma coisa que leva o tempo adicional ao desmontar .
Até agora, só notei esse comportamento ao excluir uma grande quantidade de dados. Por outro lado, não tenho certeza se isso acontece regularmente e a diferença é pequena demais para notar.
O sistema de arquivos foi criado com 0% reservado para a raiz ( mkfs -m 0 ). De acordo com fsck -f (estou fazendo isso sempre entre desmontar e remontar), o sistema de arquivos não está corrompido e, de acordo com S.M.A.R.T. teste estendido de diagnósticos, o hardware também está OK.
[EDITAR]
tune2fs 1.42 (29-Nov-2011)
Filesystem volume name: bigdata
Last mounted on: /bigdata
Filesystem UUID: 6aebd17a-e064-41dc-9c68-c9a3acbe4f66
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 121413632
Block count: 485645568
Reserved block count: 0
Free blocks: 29081276
Free inodes: 121382378
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 908
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Tue Dec 25 23:42:35 2012
Last mount time: Fri Jan 3 17:37:36 2014
Last write time: Fri Jan 3 17:37:36 2014
Mount count: 37
Maximum mount count: -1
Last checked: Thu Apr 18 17:03:40 2013
Check interval: 0 (<none>)
Lifetime writes: 14 TB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: be2b977e-5127-4843-9123-fe33b6d7b573
Journal backup: inode blocks
[/ EDIT]
Então, aqui estão minhas 2 perguntas:
- O que está acontecendo aqui? Por que o espaço é liberado no umount ou com um atraso em vez de imediatamente na exclusão?
- Há algo que eu possa fazer para acionar a liberação do espaço agora sem desmontar e remontar?