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

4

Eu tenho tentado excluir um diretório de um servidor centos usando rm -Rf /root/FFDC nas últimas 15 horas e estou tendo muita dificuldade. Eu não posso fazer uma lista de diretórios porque ele trava o sistema (muitos arquivos?), Mas o que eu posso ver é que o tamanho do diretório não é o usual 4096 bytes, mas 488MB!

[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. Eu verifiquei top e rm ainda está usando o cpu após 15 horas a 0,7%. O tipo de sistema de arquivos é ext3.

Não sei onde ir agora além do backup e do formato.

    
por James 11.08.2010 / 13:45

4 respostas

4

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

Se o ls acima for executado rapidamente, talvez algo como find /root/FFDC | xargs rm -vf seja mais rápido? Um rm -rf normal pode fazer todo o tipo de recursão que o find MIGHT pode ignorar. Ou então não.

Seu sistema de arquivos é montado com a opção sync ? Se estiver, o desempenho de gravação / exclusão é terrivelmente mais lento do que poderia ser com async . Em caso de dúvida, você pode tentar mount -o remount,async / (ou mount -o remount,async /root se for um sistema de arquivos separado para você).

    
por 11.08.2010 / 14:43
4

Você já pensou em desmontar o sistema de arquivos e, em seguida, executar o e2fsck para verificar se há erros no sistema de arquivos? Eu tentaria isso antes do backup, formatação, restauração.

    
por 11.08.2010 / 14:09
1

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

    
por 13.08.2010 / 14:42
0

Não tenho certeza de que fsck(8) reorganizará os diretórios. Você pode tentar o -D flag (conforme descrito em e2fsck(8) ). Se isso não acontecer, 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 no FFDC    mv FFDC-old / * FFDC     # Verificar / mover quaisquer arquivos / diretórios .xxx no antigo FFDC    rmdir FFCD-old

Pelo menos várias versões bash deixam globs como .a[^.]* incorretas e incluem . e .. de qualquer forma, caso contrário, você pode tentar a próxima a última etapa como mv FFDC-old/.* FFDC

Sistemas de arquivos como ext3 / ext4 manipulam diretórios essencialmente como listas encadeadas de nós não movíveis com espaço para nome do arquivo + inode, quando um arquivo é desvinculado o espaço para o nome é liberado (e deve se unir às entradas vizinhas livres, se houver). Então, um diretório tão gigantesco com poucos arquivos pode ser criado, mas não é fácil. Talvez criando milhões de links para os mesmos arquivos? Criando / excluindo milhões de links com nomes cuidadosamente criados? O que aconteceu para criar esses méritos investigando; é uma brincadeira, um mau funcionamento do sistema de filess de algum tipo ...?

    
por 13.03.2013 / 01:30