GDB如何实现生成core文件时实时压缩以节省磁盘空间

方案1：在cache_bwrite中插入压缩逻辑的可行性 #

这个方案可以正常落地，需要注意几个核心点：

• 所有待写入core文件的数据流都会经过cache_bwrite调用的fwrite，在此处注入zlib等压缩库的API即可捕获全量原始数据。
• 需要全局维护压缩上下文（比如zlib的z_stream结构体实例），不要每次进入cache_bwrite都重新初始化压缩实例，否则会严重降低压缩率；所有数据写入完成后需要主动调用压缩结束接口，刷出缓冲区中剩余的压缩数据。
• gcore生成ELF格式coredump的过程是顺序写入，不存在随机回写、覆盖的操作，完全适配流式压缩的特性，不会出现文件结构损坏的问题。
• 如果你修改的GDB仅用于定制化生成coredump场景，不需要兼容bfd库的其他读写逻辑，可以直接硬改；如果需要通用兼容，建议加编译/运行时开关控制压缩逻辑是否启用。

方案2：更优的零改造成本实现（推荐） #

完全不需要修改GDB源码，利用Linux管道特性即可实现实时压缩，操作步骤如下：

1. 创建匿名管道：mkfifo /tmp/core_pipe
2. 后台启动压缩进程从管道读取数据输出到压缩文件：gzip < /tmp/core_pipe > ./target_core.gz &
3. 直接调用gcore往管道路径写入即可：gcore -o /tmp/core_pipe <目标进程PID>

这套方案的优势是适配所有原生版本的GDB/gcore，不需要维护定制化的GDB分支，实现成本极低，同样能做到零临时磁盘占用的实时压缩效果。

附加通用场景方案 #

如果需要给所有异常崩溃的进程自动生成压缩coredump，可以直接修改内核的core_pattern配置：

echo "|/usr/bin/gzip > /data/coredumps/core.%e.%p.%t.gz" > /proc/sys/kernel/core_pattern

内核生成coredump时会直接将数据流传给gzip压缩，不需要手动调用gcore。

内容的提问来源于stack exchange，提问作者xchintan