Não há espaço no dispositivo ao remover um arquivo no OpenSolaris

Ao tentar montar um compartilhamento NFS (exportado de um servidor OpenIndiana ) em uma caixa do cliente, o servidor da OI travou. Recebi a tela preta da morte, que parecia um depósito de lixo, e o sistema foi reajustado. Ele nunca voltou e recebo a seguinte mensagem de erro após interromper a inicialização:

svc.startd[9] Could not log for svc:/network/dns/mulitcast:default: write(30) failed with No space left on device?

Não tenho mais nada na unidade de inicialização que não seja o SO, então ... não sei o que poderia estar enchendo a unidade? Talvez um arquivo de log de algum tipo? Não consigo excluir nada, independentemente. Isso me dá um erro sem espaço quando tento excluir qualquer coisa:

$ rm filename
cannot remove 'filename' : No space left on device 

Posso entrar no "Modo de manutenção", mas não no prompt do usuário padrão.

A saída de dfé:

rpool/ROOT/openindiana-baseline    4133493    4133493          0    100%   /
swap                              83097900      11028  830386872      1%   /etc/svc/volatile
/usr/lib/libc/libc_hwcap1.so.1     4133493    4133493          0    100%   /lib/libc.so.1

A saída de mounté:

/ on rpool/ROOT/openindiana-baseline read/write/setuid/devices/dev:2d9002 on Wed Dec 31 16:00:00 1969
/devices on /devices read/write/setuid/devices/dev:8b40000 on Fri Jul 8 14:56:54 2011
/dev on /dev read/write/setuid/devices/dev:8b80000 on Fri Jul 8 14:56:54 2011
/system/contract on ctfs read/write/setuid/devices/dev:8c40001 on Fri Jul 8 14:56:54 2011
/proc on proc read/write/setuid/devices/dev:8bc0000 on Fri Jul 8 14:56:54 2011
/etc/mnttab on mnttab read/write/setuid/devices/dev:8c80001 on Fri Jul 8 14:56:54 2011
/etc/svc/volatile on swap read/write/setuid/devices/xattr/dev:8cc0001 on Fri Ju8 14:56:54 2011
/system/object on objfs read/write/setuid/devices/dev:8d00001 on Fri Jul 8 14:6:54 2011
/etc/dfs/sharetab on sharefs read/write/setuid/devices/dev:8d40001 on Fri Jul 14:56:54 2011
/lib/libc.s0.1 on /usr/lib/libc/libc_hucap1.s0.1 read/write/setuid/devices/dev:d90002 on Fri Jul 8 14:57:06 2011 

A saída de 'zfs list -t all' é:

rpool                                                       36.4G   0       47.5K   /rpool
rpool/ROOT                                                  4.23G   0         31K   legacy
rpool/ROOT/openindiana                                      57.5M   0       3.99G   /
rpool/ROOT/openindiana-baseline                             61K     0       3.94G   /
rpoo1/ROOT/openindiana-system-edge                          4.17G   0       3.98G   /
rpool/ROOT/openindiana-system-edge@install                  19.9M   -       3 38G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-06-20:45:08      73.1M   -       3.57G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-06-20:48:53      75.9M   -       3 82G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-07-02:14:04      61K     -       3.94G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-07-02:15:14      61K     -       3.94G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-07-02:28:14      61K     -       3.94G   -
rpool/ROOT/openindiana-system-stable                        61K     0       3.94G   /
rpoo1/ROOT/pre_first_update_07.06                           108K    0       3 82G   /
rpool/ROOT/pre_second_update_07.06                          90K     0       3.57G   /
rpool/dump                                                  9.07G   0       9.07G   -
rpool/export                                                3.85G   0       32K     /export
rpool/export/home                                           3.85G   0       32K     /export/home
rpool/export/home/admin                                     3.85G   0       3.85G   /export/home/admin
rpool/swap                                                  19.3G   19.1G   126M    -

Ok, isso é estranho ... não há espaço suficiente para remover um arquivo!

Esse é um problema relativamente comum no ZFS, embora possa surgir em qualquer sistema de arquivos que tenha instantâneos .

A explicação é que o arquivo que você está tentando excluir ainda existe em um instantâneo. Portanto, quando você o exclui, o conteúdo permanece existente (apenas no instantâneo); e o sistema deve gravar adicionalmente as informações de que o instantâneo possui o arquivo, mas o estado atual não. Não há espaço para mais informações.

Uma correção de curto prazo é encontrar um arquivo que foi criado após o último instantâneo e excluí-lo. Outra possibilidade é encontrar um arquivo anexado após o último instantâneo e truncá-lo para o tamanho que tinha no momento do último instantâneo. Se o seu disco ficar cheio porque algo está enviando spam aos seus logs, tente aparar os maiores arquivos de log.

Uma correção mais geralmente aplicável é remover alguns instantâneos. Você pode listar instantâneos com zfs list -t snapshot. Não parece haver uma maneira fácil de prever quanto espaço será recuperado se você destruir um instantâneo específico, porque os dados que ele armazena podem se tornar necessários para outros instantâneos e permanecerão vivos se você destruir esse instantâneo. Portanto, faça backup dos seus dados em outro disco, se necessário, identifique um ou mais instantâneos dos quais você não precisa mais e execute zfs destroy name/of/snap@shot.

Há uma discussão extensa sobre esse problema neste tópico de fóruns do OpenSolaris .

Esse é um problema bem conhecido nos sistemas de arquivos copiar na gravação: para excluir um arquivo, o sistema de arquivos primeiro precisa alocar um bloco e corrigir o novo status antes de poder liberar a riqueza de espaço contido no arquivo que está sendo excluído.

(É não um problema de sistemas de arquivos com instantâneos, como existem outras maneiras de implementar estes do que apenas copiar-on-write)

Maneiras fora do aperto:

• liberar um instantâneo (caso exista um ...)
• aumente a piscina (no caso de sobrar algum que você possa atribuir)
• destrua outro sistema de arquivos no pool e aumente o sistema de arquivos rígido
• truncar o arquivo e removê-lo (embora uma vez que eu tenha estado muito apertado para poder fazer isso, consulte o tópico no ZFS Discuss )
• desvincular o arquivo. (o mesmo que acima)

Corri para a mesma armadilha há alguns anos e não tinha nenhum instantâneo que eu poderia ter liberado para me libertar. Veja o tópico no ZFS. Discuta onde esse problema foi discutido em profundidade.

4.Z3G (coluna USADO rpool / root) é dúbio.

De qualquer forma, rpool / export / home / admin sendo muito grande (3,85 GB) provavelmente é a causa raiz. Veja o conteúdo e remova arquivos desnecessários. Como o sistema de arquivos do administrador não possui capturas instantâneas, isso deve liberar imediatamente algum espaço no pool.

Eu tive isso e passei um tempo tentando descobrir o que era necessário. Minha solução foi zerar o espaço dos arquivos antes de tentar excluí-los.

Temos alguns processos que se comportam mal e que enlouquecem ocasionalmente e enchem o disco com arquivos principais (terminando em um número), por isso produzi um script que contém algo assim para manter uma cópia.

for file in core*[0-9]
do
    coreFile=${file%.[0-9]*}

    mv $file $coreFile
    if [[ $? == 0 ]]
    then
        chmod 644 $coreFile
    else
        truncate -s 0 $file # we can't just delete if disk is full so zero out first
        rm $file
    fi
done

Quando executei meu script, ele produziu um erro:

mv: cannot rename core.200000 to core: No space left on device

e foi funcional limpando os arquivos.

Para testar isso, preenchi o disco com:

for ((ii=0; ii<100000; ii++))
do
    mkfile 1m core.$ii
done