Aparentemente, os dispositivos cloop são somente leitura e exigiriam a criação de um módulo de kernel personalizado de qualquer maneira.
O zram só está disponível em kernels padrão a partir da versão 3.14, então a versão 2.6.18 do kernel padrão do Centos 5.x é muito antiga para ele.
Isso se parece muito com um problema XY : você provavelmente deve identificar o programa que produz seu enorme arquivo de log, e peça maneiras de lidar com ele.
Uma solução mais comum para arquivos de log gigantes é a rotação do arquivo de log: o conteúdo existente do arquivo de log é copiado em outro lugar, e o arquivo de log ativo é truncado imediatamente após a conclusão da cópia. Se o programa que produz o log fizer um fseek(file, 0L, SEEK_END) ou equivalente antes de gravar cada nova entrada de log, o log poderá ser truncado sem problemas.
Mas se o programa se lembrar da última posição de escrita no arquivo de log e assumir que o arquivo está inalterado desde sua operação de gravação anterior e buscar explicitamente essa posição, você obterá uma demonstração instantânea de esparsa arquivo em qualquer sistema de arquivos compatível com POSIX: a parte de corte reaparece, preenchida com zero bytes ... mas esses bytes não ocupam espaço em disco real!
Geralmente, muitos aplicativos projetados para operações de longo prazo permitem o truncamento em tempo real de seus arquivos de log ou possuem um mecanismo interno para a rotação de arquivos de log. Por exemplo, alguns aplicativos fecharão e reabrirão seus arquivos de log quando receberem um sinal específico.
O CentOS 5.x ainda tem uma ferramenta logrotate como parte de sua configuração padrão: basta inserir um arquivo de configuração identificando o (s) arquivo (s) de registro a ser rotacionado e o agendamento de rotação desejado (diário, semanal etc.) em /etc/logrotate.d e fará o trabalho.