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

Question

Ao tentar montar um compartilhamento NFS (exportado de um servidor OpenIndiana ) em uma caixa cliente, o servidor OI travou. Eu peguei a tela preta da morte, o que parecia ser uma lixeira, depois o sistema foi reapresentado. Ele nunca voltou e recebi a seguinte mensagem de erro depois que eu parei a inicialização:

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

Eu não tenho mais nada na unidade de inicialização além do sistema operacional, então ... não tenho certeza do que poderia estar enchendo a unidade? Talvez um arquivo de log de algum tipo? Eu 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 

Eu consigo entrar no "Modo de Manutenção", mas não no prompt padrão do usuário.

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    -

    

Answer 1

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

Isso acaba sendo um problema relativamente comum com o 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. Então, quando você excluí-lo, o conteúdo continua existindo (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á mais espaço para essa informação extra.

Uma correção de curto prazo é encontrar um arquivo que tenha sido criado após o último snapshot e excluí-lo. Outra possibilidade é encontrar um arquivo que tenha sido anexado após o snapshot mais recente e truncá-lo para o tamanho que ele tinha no momento do último snapshot. Se o seu disco ficou cheio porque algo está enviando spam para seus logs, tente cortar os maiores arquivos de log.

Uma correção mais aplicável geralmente é remover alguns instantâneos. Você pode listar instantâneos com zfs list -t snapshot . Não parece ser uma maneira fácil de prever quanto espaço será recuperado se você destruir um snapshot em particular, porque os dados que ele armazena podem se tornar necessários por outros snapshots e, portanto, permanecerão ativos se você destruir esse snapshot. Portanto, faça backup de 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 .

Existe uma discussão extensa sobre este assunto em este tópico de fórum do OpenSolaris .

    

Answer 2

Esse é um problema bem conhecido com sistemas de arquivos copy-on-write: Para excluir um arquivo, o sistema de arquivos primeiro precisa alocar um bloco e corrigir o novo status antes que seja capaz de liberar a riqueza de espaço contida no arquivo sendo excluído.

(Não é um problema de sistemas de arquivos com snapshots, pois há outras maneiras de implementá-los do que apenas copy-on-write)

Formas fora do aperto:

• liberar um instantâneo (caso haja um ...)
• aumente a piscina (caso haja alguma sobra que você possa atribuir a ela)
• destruir outro sistema de arquivos no pool e, em seguida, aumentar o sistema de arquivos restrito
• truncar o arquivo e, em seguida, removê-lo (embora, depois de apertar demais para conseguir fazer isso, veja discussão no ZFS Discuta
• desvincule o arquivo. (o mesmo que acima)

Eu corri para a mesma armadilha alguns anos atrás, e não tinha nenhum instantâneo que eu pudesse ter liberado para me libertar. Veja o tópico em ZFS Discute onde este problema foi discutido em profundidade.

    

Answer 3

4.Z3G (coluna USED rpool / root) é duvidosa.

Em qualquer caso, o rpool / export / home / admin sendo muito grande (3.85 GB) é provavelmente a causa raiz. Dê uma olhada no seu conteúdo e remova arquivos desnecessários lá. Como o sistema de arquivos do administrador não possui snapshots, isso deve liberar imediatamente algum espaço no pool.

    

Answer 4

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

Nós temos alguns processos que se comportam mal e que enlouquecem ocasionalmente e preenchem o disco com arquivos principais (terminando em um número), então eu 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 eu 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, preenchei o disco com:

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