Diretório enorme, não arquivos dentro, mas o próprio diretório

Diretório enorme, não arquivos dentro, mas o próprio diretório

Tenho tentado excluir um diretório de um servidor centos rm -Rf /root/FFDCnas últimas 15 horas e estou tendo muita dificuldade. Não consigo fazer uma listagem de diretórios porque trava o sistema (muitos arquivos?), mas o que posso ver é que o tamanho do diretório não é os habituais 4096 bytes, mas 488 MB!

[root@IS-11034 ~]# ls -al
total 11760008
drwxr-x--- 31 root root        4096 Aug 10 18:28 .
drwxr-xr-x 25 root root        4096 Aug 10 16:50 ..
drwxr-xr-x  2 root root   488701952 Aug 11 12:20 FFDC

Eu verifiquei os inodes e tudo parece bem. Verifiquei o topo e rmainda estou usando a CPU após 15 horas a 0,7%. O tipo de sistema de arquivos é ext3.

Não tenho ideia de onde ir agora além do backup e da formatação.

Responder1

É mesmo ls -1f /root/FFDClento? Com -1f a saída não será classificada e os detalhes do arquivo serão omitidos.

Se o ls acima for rápido, talvez algo como find /root/FFDC | xargs rm -vfseja mais rápido? Um normal rm -rfpode fazer todo tipo de recursão que findPODE ser capaz de pular. Ou então não.

O seu sistema de arquivos está montado comsincronizaropção? Se for, então o desempenho de gravação/exclusão será terrivelmente mais lento do que poderia ser comassíncrono. Em caso de dúvida, você pode tentar mount -o remount,async /(ou mount -o remount,async /rootse esse for um sistema de arquivos separado para você).

Responder2

Você já pensou em desmontar o sistema de arquivos e executar o e2fsck para verificar se há erros no sistema de arquivos? Eu tentaria isso antes de fazer backup, formatar e restaurar.

Responder3

executar fsck no sistema de arquivos resolverá o problema. Geralmente ocorre quando um diretório costumava conter muitos arquivos, mas agora não contém mais. O tamanho do diretório é dado como um número enorme e o desempenho é prejudicado.

Responder4

Não tenho certeza fsck(8)se irá reorganizar os diretórios, você pode tentar o -Dsinalizador (conforme descrito em e2fsck(8)). Caso contrário, e se realmente não houver milhões de arquivos nesse diretório, talvez algo como o seguinte forneça um diretório de tamanho razoável:

cd /root mv FFDC FFCD-old mkdir FFCD # Ajustar permissões em FFDC mv FFDC-old/* FFDC # Verifica/move quaisquer arquivos/diretórios .xxx em FFDC-old rmdir FFCD-old

Pelo menos várias versões do bash obtêm globs .a[^.]*errados e incluem .e ..de qualquer maneira, caso contrário, você pode tentar a penúltima etapa comomv FFDC-old/.* FFDC

Sistemas de arquivos como ext3/ext4 tratam diretórios essencialmente como listas vinculadas de nós imóveis com espaço para nome de arquivo + número de inode, quando um arquivo é desvinculado, o espaço para o nome é liberado (e deve se unir com entradas vizinhas livres, se houver). Então, um diretório tão gigantesco com poucos arquivospodeser criado, mas não é fácil. Talvez criando milhões de links físicos para os mesmos arquivos? Criando/excluindo milhões de links com nomes cuidadosamente elaborados? O que quer que tenha acontecido para criar isso merece ser investigado; é uma pegadinha, algum tipo de mau funcionamento do sistema de arquivos, ...?

informação relacionada