O Linux acha temporariamente que o disco está cheio

Question

Estou trabalhando em um servidor Linux com o CentOS 6.5 e com um NAS NFS em uma rede QDR Infiniband. Estou executando um script bash que basicamente cria um diretório, cria links simbólicos dentro dele e cat s juntos um pequeno arquivo em cada diretório. Ele faz isso por algumas centenas de diretórios.

Eu notei no log de saída que um dos links simbólicos e o cat subseqüente não foi executado, alegando que o disco estava cheio. Era claramente que não. Executando esse mesmo script para alguns milhares de diretórios, comecei a receber um grande número dessas mensagens. Eu verifiquei e o disco parecia estar cheio, então eu imediatamente matei meu script, mas depois de alguns minutos, o disco voltou ao normal.

Aqui estão os comandos df sequenciais que eu vi, o primeiro enquanto o script estava rodando, o segundo logo depois de matá-lo, e o terceiro alguns segundos depois /home3 (um NAS) é o que estou trabalhando em:

[swfl 07:40:56 JPM]$ df -h
Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/vg_misisss6-lv_root  135G   25G  104G  19% /
tmpfs                             12G     0   12G   0% /dev/shm
/dev/sda1                        485M   69M  392M  15% /boot
misisss-nasib3:/home              26T   26T  1.0M 100% /home3
misisss-nas1:/shared              77G  437M   73G   1% /shared
misisss-nasib2:/home              15T   15T   95G 100% /home2
You have new mail in /var/spool/mail/swfl

[swfl 07:41:39 JPM]$ df -h
Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/vg_misisss6-lv_root  135G   25G  104G  19% /
tmpfs                             12G     0   12G   0% /dev/shm
/dev/sda1                        485M   69M  392M  15% /boot
misisss-nasib3:/home              26T   26T  1.0M 100% /home3
misisss-nas1:/shared              77G  437M   73G   1% /shared
misisss-nasib2:/home              15T   15T   94G 100% /home2

[swfl 07:41:58 JPM]$ df -h
Filesystem                       Size  Used Avail Use% Mounted on
/dev/mapper/vg_misisss6-lv_root  135G   25G  104G  19% /
tmpfs                             12G     0   12G   0% /dev/shm
/dev/sda1                        485M   69M  392M  15% /boot
misisss-nasib3:/home              26T   21T  4.2T  84% /home3
misisss-nas1:/shared              77G  437M   73G   1% /shared
misisss-nasib2:/home              15T   15T   93G 100% /home2

Na época, havia relativamente pouco uso de CPU na maioria dos núcleos e uso de disco baixo a moderado. Eu não tenho software de monitoramento funcionando, então não posso dar números de IOps ou qualquer coisa do tipo, mas eu fiz um trabalho semelhante a isso, mas com intensidade muito maior sem problemas.

Em suma, seria muito difícil acreditar que eu estivesse sobrecarregando qualquer parte do sistema com o trabalho que estava sendo feito. Breadcrumbs sobre onde procurar por problemas?

UPDATE 1 Executando watch 'df -h; df -i' para acompanhar inodes e uso de disco, posso ver o espaço em disco caindo vertiginosamente (as coisas estão OK por ~ 5 segundos, depois vários TB desaparecem em 10-20 segundos ), até eu começar a receber os erros, mas em odes não está diminuindo tanto.

Eu posso ver em odes tem uma utilização bastante elevada (30-70%), no entanto. Eu tenho ~ 16 bilhões de inodes e estou criando ~ 40000 arquivos / diretórios. Depois que eu matar o processo, o espaço em disco começará a subir lentamente (alguns GB) por 10 a 20 segundos, e então você voltará a subir alguns TB para o que era originalmente.

    

Answer 1

Ao percebermos que o espaço em disco foi liberado em um ciclo de 5 minutos, conseguimos identificar o problema. É um comportamento que pode ser exclusivo do sistema de arquivos que estamos usando, o sistema de arquivos XFS .

O XFS permite que você especifique um tamanho de arquivo pré-alocado. Montamos o sistema de arquivos com um allocsize=1G , dado que esse sistema de arquivos foi criado com arquivos grandes em mente e queríamos evitar a fragmentação. Você também pode especificar uma frequência de atualização para o sistema de arquivos para voltar e revisar a utilização dos valores pré-alocados. O valor padrão de 5 minutos foi porque vimos esse comportamento cíclico. Algumas informações relacionadas sobre esse comportamento podem ser encontradas aqui .

Então, quando eu criei um arquivo, então executei um cat para ele, essa segunda ação no arquivo foi suficiente para acionar o sistema para pré-alocar 1 GB para esse arquivo. Fazer um loop em vários milhares desses arquivos a uma velocidade muito alta resultou em que todo o espaço em disco parecesse exaurido antes que a unidade de armazenamento pudesse ajustar essas alocações.

Nós removemos essa opção de montagem para permitir que o sistema de arquivos acompanhe a pré-alocação dinâmica, que é mais inteligente sobre arquivos menores e capacidade disponível do sistema de arquivos.