Eu escrevi um programa buggy que criou acidentalmente cerca de 30M arquivos em / tmp. (O bug foi introduzido algumas semanas atrás, e estava criando um par de subdiretórios por segundo.) Eu poderia renomear / tmp para / tmp2, e agora preciso excluir os arquivos. O sistema é o FreeBSD 10, o sistema de arquivos raiz é o zfs.
Enquanto isso, uma das unidades no espelho deu errado, e eu a substituí. A unidade possui dois discos SSD de 120 GB.
Aqui está a pergunta: substituir o disco rígido e fazer o resilver de todo o array levou menos de uma hora. A exclusão de arquivos / tmp2 é outra história. Eu escrevi outro programa para remover os arquivos, e só pode excluir 30-70 subdiretórios por segundo. Demora 2-4 dias para apagar todos os arquivos.
Como é possível que o resilver de toda a matriz leve uma hora, mas a exclusão do disco leva 4 dias? Por que eu tenho um desempenho tão ruim? 70 deleções / segundo parece um desempenho muito ruim.
Eu poderia deletar o inode de / tmp2 manualmente, mas isso não vai liberar o espaço, certo?
Isso pode ser um problema com o zfs, ou com os discos rígidos ou o quê?
As exclusões no ZFS são caras. Ainda mais se você tiver a desduplicação ativada no sistema de arquivos (já que a desreferência de arquivos deduzidos é cara). Os instantâneos podem complicar também.
Talvez seja melhor excluir o diretório /tmp em vez dos dados contidos nele.
Se /tmp for um sistema de arquivos ZFS, exclua-o e crie novamente.
How is it possible that resilvering the whole array takes an hour, but deleting from the disk takes 4 days?
Considere um prédio de escritórios.
Remover todos os computadores, móveis e fixações de todos os escritórios em todos os andares leva um tempo longo , mas deixa os escritórios imediatamente utilizáveis por outro cliente.
A demolição de todo o edifício com o RDX é um todo mais rápido, mas o próximo cliente é bastante capaz de reclamar sobre como o local é arrojado.
Há várias coisas acontecendo aqui.
Primeiro, todas as modernas tecnologias de disco são otimizadas para transferências em massa. Se você precisar mover 100 MB de dados, eles farão isso muito mais rápido se estiverem em um bloco contíguo, em vez de espalhados por todo o lugar. Os SSDs ajudam muito aqui, mas até eles preferem dados em blocos contíguos.
Em segundo lugar, o resilvering é bastante ideal no que diz respeito às operações de disco. Você lê um pedaço maciço de dados contíguos de um disco, faz alguns rápidos ops de CPU nele, então reescreve em outro grande pedaço contíguo para outro disco. Se o poder falhar no meio, não é grande coisa - você simplesmente ignorará qualquer dado com checksums ruins e continuará de acordo com o normal.
Em terceiro lugar, excluir um arquivo é muito lento . O ZFS é particularmente ruim, mas praticamente todos os sistemas de arquivos são lentos para serem excluídos. Eles devem modificar um grande número de diferentes blocos de dados no disco e programá-los corretamente (ou seja, esperar) para que o sistema de arquivos não seja danificado se a energia falhar.
How is it possible that resilvering the whole array takes an hour, but deleting from the disk takes 4 days?
O resilvering é algo em que os discos são realmente rápidos, e a exclusão é algo em que os discos são lentos. Por megabyte de disco, você só precisa fazer um pouco de resilvering. Você pode ter mil arquivos nesse espaço que precisam ser excluídos.
70 deletions/second seems very very bad performance
Depende. Eu não ficaria surpreso com isso. Você não mencionou o tipo de SSD que está usando. Os modernos SSDs Intel e Samsung são muito bons nesse tipo de operação (read-modify-write) e terão melhor desempenho. SSDs mais baratos / antigos (por exemplo, Corsair) serão lentos. O número de operações de E / S por segundo (IOPS) é o fator determinante aqui.
O ZFS é particularmente lento para apagar coisas. Normalmente, ele executará exclusões em segundo plano para que você não veja o atraso. Se você está fazendo um grande número deles, não pode escondê-lo e deve atrasar você.
Apêndice: por que as exclusões são lentas?
How is it possible that resilvering the whole array takes an hour, but deleting from the disk takes 4 days?
É possível porque as duas operações funcionam em diferentes camadas da pilha do sistema de arquivos. O resilvering pode ser executado em um nível baixo e não precisa realmente examinar arquivos individuais, copiando grandes blocos de dados por vez.
Why do I have so bad performance? 70 deletions/second seems very very bad performance.
Ele tem que fazer muita contabilidade ...
I could delete the inode for /tmp2 manually, but that will not free up the space, right?
Eu não sei para o ZFS, mas se ele pudesse se recuperar automaticamente disso, provavelmente, no final, faria as mesmas operações que você já está fazendo, em segundo plano.
Could this be a problem with zfs, or the hard drives or what?
O zfs scrub diz alguma coisa?
A exclusão de muitos arquivos nunca é uma operação realmente rápida.
Para excluir um arquivo em qualquer sistema de arquivos, você precisa ler o índice do arquivo, remover (ou marcar como excluído) a entrada do arquivo no índice, remover quaisquer outros metadados associados ao arquivo e marque o espaço alocado para o arquivo como não utilizado. Isso deve ser feito individualmente para cada arquivo a ser excluído, o que significa que a exclusão de muitos arquivos exige muitas E / Ss pequenas. Para fazer isso de uma maneira que garanta a integridade dos dados no caso de falta de energia, isso adiciona ainda mais sobrecarga.
Mesmo sem as peculiaridades introduzidas pelo ZFS, a exclusão de 30 milhões de arquivos normalmente significa mais de cem milhões de operações de E / S separadas. Isso irá demorar muito tempo, mesmo com um SSD rápido. Como outros já mencionaram, o design do ZFS agrava ainda mais essa questão.
Ian Howson dá uma boa resposta sobre por que é lento.
Se você excluir arquivos em paralelo, poderá ver um aumento na velocidade devido à exclusão, que pode usar os mesmos blocos e, portanto, pode salvar a repetição do mesmo bloco várias vezes.
Então tente:
find /tmp -print0 | parallel -j100 -0 -n100 rm
e veja se o desempenho é melhor que as 70 exclusões por segundo.
Muito simples se você inverter o seu pensamento.
Obtenha uma segunda unidade (você já parece ter isso)
Copie tudo da unidade A para a unidade B com rsync, excluindo o diretório / tmp. O rsync será mais lento que uma cópia de bloco.
Reinicialize, usando a unidade B como o novo volume de inicialização
Reformate a unidade A.
Isso também desfragmentará sua unidade e fornecerá a você um novo diretório (bem, a desfragmentação não é tão importante com um SSD, mas a linearização de seus arquivos nunca faz mal a nada)
Você tem 30 milhões de entradas em uma lista não classificada. Você digitaliza a lista para a entrada que deseja remover e a remove. Agora você tem apenas 29.999.999 entradas em sua lista não classificada. Se eles estão todos em / tmp, por que não apenas reiniciar?
Editado para refletir as informações nos comentários:
Declaração de problema: Remover a maioria, mas não todos , dos 30M + arquivos criados incorretamente em / tmp está demorando muito.
Problema 1) A melhor maneira de remover um grande número de arquivos indesejados de / tmp.
Problema 2) Entendendo porque é tão lento para excluir arquivos.
Solução 1) - / tmp é redefinido para vazio na inicialização pela maioria das distribuições * nix. O FreeBSD, no entanto, não é um deles.
Passo 1 - copie arquivos interessantes em outro lugar.
Passo 2 - Como root
$ grep -i tmp /etc/rc.conf
clear_tmp_enable="YES" # Clear /tmp at startup.
Etapa 3 - reinicialização.
Passo 4 - mude o clear_tmp_enable de volta para "No".
Arquivos indesejados já não existem mais, já que o ZFS no FreeBSD tem o recurso de que "destruir um conjunto de dados é muito mais rápido de excluir todos os arquivos que residem no conjunto de dados, pois não envolve a verificação de todos os arquivos e a atualização de todos os metadados correspondentes. " Portanto, tudo o que precisa ser feito no momento da inicialização é redefinir os metadados para o conjunto de dados / tmp. Isso é muito rápido.
Solução 2) Por que é tão lento? O ZFS é um sistema de arquivos maravilhoso que inclui recursos como o acesso de diretório de tempo constante. Isso funciona bem se você sabe o que está fazendo, mas as evidências sugerem que o OP não é um especialista do ZFS. O OP não indicou como eles estavam tentando remover os arquivos, mas eu acho que eles usaram uma variação em "find regex -exec rm {} \". Isso funciona bem com números pequenos, mas não é dimensionado porque há três operações em série acontecendo 1) obter a lista de arquivos disponíveis (retorna 30 milhões de arquivos em ordem hash), 2) usar regex para escolher o próximo arquivo a ser excluído, 3 ) informe ao sistema operacional para localizar e remover esse arquivo de uma lista de 30 milhões. Mesmo se o ZFS retorna uma lista da memória e se 'localizar' armazena em cache, o regex ainda tem que identificar o próximo arquivo a ser processado a partir da lista e informar ao SO para atualizar seus metadados para refletir essa alteração e atualizar a lista para que ela não seja processada novamente.