Como encontrar com eficiência quais pastas estão preenchendo o disco rígido? [OS / 400]

Question

V5R3, tenho acesso ao ambiente do PASE

O relatório de espaço em disco mostra que os Diretórios do usuário estão ocupando 76% do disco do sistema. Infelizmente, colocar um '8' nos diretórios não fornece estimativas de tamanho recursivas.

Existem outros comandos ou utilitários IBM que podem eficientemente obter essas informações para que possamos descobrir qual pasta está consumindo o espaço em disco? O sistema já está engatinhando, e prefiro não interrompê-lo na tentativa de diagnosticá-lo.

A IBM mencionou o seguinte utilitário PASE:

CALL QP2TERM find /qibm/proddata -type f -size +20000 -exec ls -lH {} \; | awk '{ print $9 ": " $5 }'

Mas (até agora) só retornou ~ 3-4 GB de arquivos, o que me leva a acreditar que são milhares de arquivos menores que estão causando a tensão do sistema.

Cenário de pior caso, vou executar um SBMJOB amanhã com QSH CMD ('ls -R / > > /QSYS.LIB/QGPL.LIB/QSHOUT.FILE/QSHOUT.MBR') e apenas colocá-lo em QSYSNOMAX com baixa prioridade.

    

Answer 1

Primeiro, da IBM sobre o assunto vale a pena ler.

Em segundo lugar, houve um enorme equívoco em jogo aqui. Ao colocar um 8 em uma pasta IFS para exibir suas propriedades, o atributo 'Tamanho no disco' é o tamanho do objeto 'pasta' do IFS, além de qualquer do seu conteúdo . Portanto, o tamanho das pastas que suspeitamos mostrou 83 886 080 bytes: 80 megabytes. Isso não seria ruim se fosse calculado recursivamente, mas este é apenas o objeto da pasta em si! Uma vez que este ponto ficou claro, a solução era simples; use o comando DEL para limpar o diretório problemático, que tinha cerca de 75 GB de objetos.

Um método para derivar o tamanho recursivo de um diretório IFS é colocar um 2 em seu diretório pai e, em seguida, um 6 no objeto de diretório em questão; o número gerado será para o objeto da pasta e todos os objetos contidos, incluindo subpastas e seus objetos.

Os comandos RTVDIRINF e PRTDIRINF também são potencialmente úteis, embora no meu caso eu não precise deles.

• Trabalhando com RTVDIRINF
• Usando seus dados

Algumas notas sobre isso do meu colega:

Os comandos produzem arquivos diferentes para cada execução - a saída deve ser prefixada com algo significativo; diretório de nível superior ou similar. PRTDIRINF tem uma opção * DIR que fornece uma listagem do espaço usado para cada diretório. É possível executar uma consulta como essa para obter uma visão geral mais rápida:

SELECT sum(QEZALCSIZE), sum(QEZDTASIZE) FROM homeo

Isso dará o tamanho total no diretório / home.

Aqui está um exemplo mais útil, correndo contra os resultados de cada diretório.

SELECT sum(O.QEZALCSIZE), D.QEZDIRNAM1, D.QEZDIRIDX FROM homed d join homeo o on d.qezdiridx = o.qezdiridx GROUP BY d.qezdiridx, qezdirnam1 ORDER BY 1 desc, 3, 2

Você pode combiná-los usando UNION SELECTs para entender o quadro geral:

SELECT sum(QEZALCSIZE), QEZDIRNAM1, homeD.QEZDIRIDX FROM homed join homeo on homed.qezdiridx = homeo.qezdiridx GROUP BY homed.qezdiridx, qezdirnam1 UNION SELECT sum(QEZALCSIZE), QEZDIRNAM1, etcD.QEZDIRIDX FROM etcd join etco on etcd.qezdiridx = etco.qezdiridx GROUP BY tcd.qezdiridx, qezdirnam1 ORDER BY 1 desc, 3, 2

Um culpado comum é este diretório:

/ QIBM / UserData / OS400 / MGTC / service

Se esta pasta é excepcionalmente grande, siga as instruções da IBM para desligá-lo ( a menos que haja uma razão específica para isso) e purgar o diretório como acima.

Por fim, os arquivos da lista de correspondência Midrange e os wiki são recursos maravilhosos em seus domínios também. As amostras SQL e a nota sobre o Rastreamento Central de Gerenciamento vieram de trocas na lista de correspondência Midrange.

    

Answer 2

Uau, faz anos desde que toquei em um AS / 400 e não tinha comandos semelhantes ao Unix.

O comando find em sua pergunta pesquisa apenas arquivos grandes em vez de diretórios grandes (muitos arquivos pequenos).

Em vez do comando find , tente:

du /qibm/proddata | sort -n

Se isso funcionar, o final dessa lista será o maior diretório dessa hierarquia.

Você também pode tentar uma variação no comando find que você listou, que examina os tamanhos dos diretórios:

find /usr/share -type d -size +20000 -exec ls -lHd {} \; | awk '{ print $9 ": " $5 }'

Você pode experimentar tamanhos diferentes como seu limite. Pode ser possível que seu espaço esteja sendo comido por arquivos fora de /qibm/proddata .

Infelizmente, esqueci muito do que sabia sobre o AS / 400.