Melhor maneira de liberar espaço em disco dos arquivos excluídos que são mantidos abertos

Question

Oi eu tenho muitos arquivos que foram excluídos, mas por algum motivo, o espaço em disco associado com os arquivos excluídos não pode ser utilizado até que eu mate explicitamente o processo para o arquivo tendo o espaço em disco

$ lsof /tmp/
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF      NODE NAME
cron     1623 root    5u   REG   0,21        0 395919638 /tmp/tmpfPagTZ4 (deleted)

O espaço em disco ocupado pelo arquivo excluído acima causa problemas, como ao tentar usar a tecla tab para completar automaticamente um caminho de arquivo, recebo o erro bash: cannot create temp file for here-document: No space left on device

Mas depois de executar kill -9 1623 , o espaço para esse PID é liberado e não recebo mais o erro.

Minhas perguntas são:

• por que esse espaço não é imediatamente liberado quando o arquivo é excluído pela primeira vez?
• qual é a melhor maneira de recuperar o espaço no arquivo associado aos arquivos excluídos?

e por favor, deixe-me saber qualquer terminologia incorreta que usei ou qualquer outra informação relevante e pertinente sobre esta situação.

    

Answer 1

Em unices, nomes de arquivos são apenas ponteiros (inodes) que apontam para a memória onde o arquivo reside (que pode ser um disco rígido ou até mesmo um sistema de arquivos suportado por RAM). Cada arquivo registra o número de links para ele: os links podem ser o nome do arquivo (plural, se houver vários hard links para o mesmo arquivo) e também toda vez que um arquivo é aberto, o processo realmente mantém o "link" para o mesmo espaço.

O espaço é fisicamente liberado apenas se não houver links deixados (portanto, é impossível obtê-lo). Essa é a única escolha sensata: enquanto o arquivo está sendo usado, não é importante que alguém não possa mais acessá-lo: você o está usando e até fechar, você ainda tem controle sobre ele - você nem perceberá o nome do arquivo se foi ou mudou-se ou o que quer que seja. Isso é usado até mesmo para arquivos temporários: algumas implementações criam um arquivo e o desvinculam imediatamente, então ele não é visível no sistema de arquivos, mas o processo que o criou está usando normalmente. O plugin Flash gosta especialmente deste método: todos os arquivos de vídeo baixados são mantidos abertos, mas o sistema de arquivos não os mostra.

Assim, a resposta é que, enquanto os processos ainda têm os arquivos abertos, você não deve esperar recuperar o espaço. Não é liberado, está sendo usado ativamente. Esse também é um dos motivos pelos quais os aplicativos devem realmente fechar os arquivos quando terminarem de usá-los. No uso normal, você não deve pensar nesse espaço como livre, e isso também não deve ser muito comum - com a exceção de arquivos temporários que são desvinculados de propósito, não deve haver arquivos que você faria considere estar sem uso, mas ainda aberto. Tente analisar se existe um processo que faz muito isso e considere como você o usa, ou apenas encontre mais espaço.

    

Answer 2

Os arquivos são excluídos do sistema de arquivos, onde é excluída qualquer referência a este inode. A referência pode estar no disco (link em qualquer diretório) e .. a partir de aplicativos abertos. Se você remover o arquivo - você só excluirá a referência do disco, mas - ainda haverá referência do aplicativo.

Você pode "liberar" espaço de duas formas:

1. como mencionado acima - você pode eliminar o aplicativo, que abre o arquivo.
2. você pode ... truncar o arquivo. Mesmo que seja excluído:

Se você conhece pid, veja quais arquivos estão abertos por este pid: ls -l / proc / PID / fd você vê aqui links como:

undefine@uml:~$ ls -l /proc/18596/fd
razem 0
lrwx------ 1 undefine undefine 64 lut  1 00:06 0 -> /dev/pts/30
lrwx------ 1 undefine undefine 64 lut  1 00:06 1 -> /dev/pts/30
lrwx------ 1 undefine undefine 64 lut  1 00:05 2 -> /dev/pts/30
lr-x------ 1 undefine undefine 64 lut  1 00:06 3 -> /home/undefine/x (deleted)
lr-x------ 1 undefine undefine 64 lut  1 00:06 4 -> anon_inode:inotify

Como você vê - 3 fd é excluído. você pode truncar por comando (por exemplo):

undefine@uml:~$ :>/proc/18596/fd/3
undefine@uml:~$ 

Lembre-se de que, se o aplicativo ler esse arquivo, poderá ser perigoso para eles. Mas - se for apenas um arquivo de log - você pode truncá-lo de forma segura.

    

Answer 3

Como outros disseram, lsof pode ser usado para listar todos os arquivos excluídos que ainda estão no disco devido a descritores de arquivos abertos. No entanto, esta pode ser uma lista muito longa. Aqui está um comando que lista esses arquivos classificados por tamanho crescente em bytes:

sudo lsof -F sn0 | tr -d '
sudo lsof -F sn0 | tr -d '%pre%0' | grep deleted | sed 's/^[a-z]*\([0-9]*\)n/ /' | sort -n
0' | grep deleted | sed 's/^[a-z]*\([0-9]*\)n/ /' | sort -n

Pode haver uma maneira mais sucinta de fazer isso, mas o comando acima funcionou para mim.

    

Answer 4

O espaço não é liberado imediatamente porque o processo em execução ainda possui um identificador de arquivo aberto para o arquivo recém-excluído. Afinal, se um processo ainda está tentando usar um arquivo, você provavelmente não quer que o kernel se livre dele (o arquivo). Isso pode tornar o processo um pouco perturbado. A melhor maneira (e só até onde eu sei) de liberar o espaço é fazer exatamente o que você fez - matar o processo.

    

Answer 5

(hortelã 17.1)

TL; DR:

• Inspecione com sudo baobab (Disk Usage Analyzer).
• Limpar a lixeira do usuário de root

Contexto

Eu estava preso com espaço cada vez menor enquanto eu constantemente apagava arquivos. Eu instalei o pacote trash-cli para esvaziar a lixeira, mas isso não ajudou. Por fim, notei que quando executei baobab (Disk Usage Analyzer na GUI, pelo menos na Mint 17.1) para inspecionar a estrutura do espaço em disco, ele avisou que algumas pastas não estavam acessíveis. Então eu corri como root usando sudo baobab . Isso revelou o problema. Muitos dos arquivos que foram excluídos estavam na lixeira do usuário root , não do meu próprio usuário. Assim, não consegui liberar o espaço. Então eu simplesmente esvaziei o lixo usando como root ( sudo trash-cli ) e todo o meu espaço retornou.

    

Answer 6

Tente usar o comando abaixo

lsof | grep deleted

e depois matar o pid do arquivo deletado.