Eu encontrei a resposta para a minha pergunta de "como corrigir esse cenário". Não conheço todos os detalhes de como isso aconteceu, mas sei o suficiente para dar uma resposta.
Resposta curta: desmontando o disco, executando chkdsk -f sobre ele e a montagem de volta resolve e evita que o problema ocorra novamente. Como alternativa, criar um novo disco (lembre-se de que estamos na AWS) e copiar todos os dados para o novo disco ( rsync -a foi o meu comando de escolha) e usá-lo para substituir o disco original também resolve & impede.
Resposta mais longa: o sistema de arquivos do disco (ext4) parece ter atingido algum estado instável quando o instantâneo do disco foi originalmente criado. Quando mais tarde o instantâneo original de 200GB foi estendido (usando resize2fs ) para 1TB, parece que em certo sentido ele manteve lembrando internamente o tamanho original de 200GB, criando todos os tipos de fenômenos estranhos que acabaram com o OS incapaz de fechar manipula, fazendo com que o Tomcat atinja seu limite de arquivos, tendo assim todo o inferno solto.
Resposta mais longa, com um pouco mais dos detalhes do trabalho de detetive: a descoberta aconteceu quando tivemos essa patologia ocorrendo em paralelo em duas configurações separadas. Verificando todos os parâmetros nessas configurações e comparando, percebemos que df -h na unidade estava mostrando esse resultado:
/dev/xvdc 1008G 197G 760G 19% /mnt/eternal
Agora, isso não chamou nossa atenção antes, porque o disco ainda tem muito espaço sobrando. Mas foi exatamente o mesmo uso de disco (197G) em ambas as configurações, e isso não tem motivos para acontecer. Daqui as coisas rapidamente se desdobraram. Como mencionado anteriormente, nossas instâncias do AWS foram criadas a partir de uma imagem que tem um instantâneo de disco de 200 GB, que é estendido em instâncias individuais usando resize2fs - geralmente para o tamanho máximo de 1 TB. Finalmente conseguimos recriar um "mau estado", lançando uma nova instância, redimensionando para 1 TB e criando um grande arquivo de 300 GB. Quando isso foi feito, o sistema não congelou, mas mostrou o mesmo comportamento estranho:
/dev/xvdc 1008G 197G 760G 19% /mnt/eternal
E quando havia claramente mais de 197 GB de dados no disco. Então, tentamos os dois métodos mencionados acima (chkdsk e recriando o disco) em duas configurações limpas individuais, e em cada uma delas o comportamento estranho não apareceria mais.
Nosso melhor palpite é que em algum momento, quando a AMI foi criada, algo deu errado no processo de snapshots - muito provavelmente porque tínhamos tirado um "snapshot sem reiniciar" (embora não usualmente, e eu não tenho evidência para sustentar isso, então espero que nossos DevOps não fiquem bravos comigo por culpá-la sem motivo!). Tudo somado, uma experiência interessante.