otimizar relatórios 'du' em conjuntos de dados petabyte?

Question

Estou tentando obter um relatório diário de tamanho de arquivo em um conjunto de dados de vários petabytes de dados genômicos. Nosso relatório atual usa várias invocações de du sobrepostas para alcançar o resultado, mas leva mais de 24 horas para ser executado. Eu estou procurando uma maneira de fazer isso de forma mais eficiente / rápida / 'limpa'.

atualmente fazemos:

# broad overview of dozens of projects + grand total
du -chd1 /petastorage/projects/  

# detailed look at some 'special' projects, 
# each of these has huge sub-dirs we want to track individually
du -hd1 /petastorage/projects/special_project_A/
du -hd1 /petastorage/projects/special_project_B/
du -hd1 /petastorage/projects/special_project_C/

O que me incomoda é que special_project_[ABC] são rastreados duas vezes, uma vez na visão geral geral, uma vez para a visualização detalhada. Como esses projetos especiais são responsáveis por uma grande parte dos dados, rastreá-los duas vezes é, provavelmente, uma parte significativa do tempo de execução. Além disso, como estamos falando de petabytes, não acredito que qualquer nível de cache do sistema de arquivos acelere as chamadas de repetição.

Eu tentei 'otimizar' para   %código% mas parece que du -d1 /petastorage/projects/ /petastorage/projects/special_project_[ABC]/ é inteligente o suficiente para perceber que os projetos especiais são diretórios filhos do primeiro diretório e, portanto, os 'otimiza' para fora do relatório. Gah!

Alguém tem uma ideia de como eu posso convencer du a rastrear meus petabytes apenas uma vez, exibindo ambos os projetos individualmente, bem como a visão detalhada (um nível mais profundo) dos três 'projetos especiais'

nota: o du-output atual já é colocado em algum tipo de pipe uniq para torná-lo mais agradável e sem duplicatas no relatório de e-mail, portanto, soluções envolvendo pós-processamento são aceitáveis. Qualquer tempo de execução de pós-processamento é zero comparado a petabytes de ferrugem.

Plano de fundo no caso de ser importante: esta é uma montagem do NFSv3 para nós de armazenamento do EMC-isilon, montada no OpenSuse 11.4. Todos os projetos atualmente compartilham um único conjunto de armazenamento nos isilons para que o espaço livre possa ser deslocado entre os projetos. Mover os projetos 'especiais' para seus próprios sistemas de arquivos para que possamos 'trapacear' com du é inviável devido ao seu tamanho.

    

Answer 1

Para relatar, já percorremos a rota "inviável" como parte de uma maior reformulação do nosso armazenamento.

Nossos novos servidores de arquivos oferecem suporte à cota por submontagem, de modo que, com o tempo, temos extraído projetos em submontagens, em vez de pastas "normais" em um sistema de arquivos / montagem grande e compartilhado. Este foi um projeto de migração de back-burner durante várias semanas / meses. Isso nos permitiu colocar quota em todas as "pastas" desejadas.

Agora, consultamos o status da cota (que é gerenciado ao vivo e instantaneamente pelos servidores de arquivos)

    

Answer 2

Depois de passar um ou dois dias (combinados) sobre esse assunto, decidimos seguir o caminho mais fácil e não otimizar mais por enquanto. No final, o tempo do desenvolvedor é mais caro do que o tempo de execução do script.

Se / Quando eu voltar a esse problema, provavelmente farei uma du run para os subprojetos, uma segunda du para as pastas grandes (com --exclude nos projetos cobertos pelo primeiro) e calcular manualmente o total geral em pós-processamento (o uso judicioso de awk , sed ou grep | paste -sd'+' | bc deve ser suficiente)

Se alguém tiver mais ideias, ficarei feliz em ouvi-las: -)