pstore压缩与截断崩溃日志：核对完整解码链
归档里有一个文件，却读不出故障原因，可能是读取端不认识它的编码，也可能是关键消息从未被保留下来。增大存储不能自动区分两者。本文按Linux v6.12上游实现，把崩溃写入内核、后端标记、恢复内核和采集字节串成完整检查链。文中的验证矩阵属于建议方案，不表示某块板卡或某个升级组合已经通过实测。
先固定写入端与恢复端身份
每次事件至少记录两个构建身份：发生故障时运行的内核，以及随后启动并读取记录的内核。升级、回退或救援启动时，两者可能不同。还应保留各自部署配置、后端名称、复位方式、原始文件名和采集工具版本。只知道恢复内核版本，无法判断写入时采用了什么压缩方式。
建议建立事件表，分别填写写入版本、读取版本、记录类型、原始长度、压缩状态、解码结果和完整性结果。未知字段应保留为未知，不能由脚本默认成“未压缩”。否则一个未经验证的默认值，会影响之后所有排查。
按v6.12的压缩约定检查
Linux v6.12使用CONFIG_PSTORE_COMPRESS和zlib deflate。旧资料中选择多个pstore加密API压缩算法的办法，不适用于该版本的Kconfig；有厂商修改的产品还要检查实际代码。依据见v6.12 pstore配置。
# 只读检查；文件不可见时使用对应构建证据
uname -r
cat /proc/cmdline
cat /sys/module/pstore/parameters/compress
dmesg | grep -Ei 'pstore|ramoops|deflate|inflate|compression'该版本compress参数支持deflate与none，不支持的名字会产生诊断并回退到deflate。此压缩路径只用于dmesg记录；实现采用原始deflate流，因此gzip命令报错不能单独证明存储损坏。参见pstore压缩实现。
v6.12恢复内核使用pstore.compress=none时，也没有初始化对应解压路径；旧压缩记录仍以编码状态呈现时，应检查读取端设置。配置项说明具备能力，不保证每一条记录都已压缩。检查启动诊断与配置是否一致，同时把运行状态和具体文件的表示形式分开记录。
说明采集到的究竟是哪一层数据
ramoops在dmesg头部保存压缩或普通数据标记，恢复时传给pstore。仍带压缩状态的记录在文件名后增加.enc.z。因此，已经被内核解码的文件与物理内存原始镜像不同，采集脚本不能把两者都含糊称为“原始日志”。依据见ramoops记录处理和pstore文件名实现。
明确标注数据来自保留区域镜像、pstore导出的文件，还是处理后的文本。转换前保存该层的原始字节和散列。不要为了让上传工具接收而删掉扩展名；可以另设显示名称，但格式证据必须保留。
解码失败与内容缺失分别下结论
解码状态可设为普通文本、解码成功、不支持、格式错误、尚未尝试；完整性状态可设为与参考一致、明显缺失、未知。文本刚好结束于换行，并不说明前因齐全；二进制文件也可能完好，只是当前工具不能解码。
离线读取器应写清预期格式，并限制输入大小、展开大小、处理时间和尾随内容。不能轮流尝试许多算法，直到得到可打印字符就宣布成功。若压缩负载之外还包含ECC提示，应保存提示并确定负载边界。标记、解码器和文本含义相互矛盾时，应把该例保留为待调查失败。
有条件时使用独立串口记录，或带连续行号的人工参考，检查究竟缺了哪些消息。依次判断消息是否在崩溃前产生、是否进入捕获窗口、采集工具是否改写了内容。没有独立参考就报告完整性未知，不要把解码成功等同于完整恢复。
分别验证升级与回退方向
把写入版本作为矩阵行、恢复版本作为列，覆盖当前部署版本、候选版本和允许回退的版本。每个需要支持的组合，分别放入已知普通记录与已知压缩记录。对于旧产品分支，要查其实际算法配置，不能假设v6.12读取端支持所有历史表示。
建议保存一组人工测试样本：短文本、重复较多的长文本、重复较少的文本、故意截断的压缩流，以及可正确解码但源消息缺行的流。后两者应得到不同结论。还要比较内核导出文件与采集工具最终文件，避免传输或文本转换制造第二层损坏。
这些样本可先在软件环境验证，无须让生产设备崩溃。确需触发实际故障时，应使用隔离开发板并准备批准的恢复流程；测试前先保存待分析事件，避免连续复位覆盖真正需要调查的证据。
交付可自动检查的解码状态
- 写入端、读取端都有准确构建和配置引用。
- 保留采集层级、原始名称、字节数及散列。
- 压缩状态不依赖文件名猜测。
- 记录解码器版本、输出边界、错误与ECC提示。
- 完整性结论不与解码结果混用。
- 每个支持的升级和回退方向都有对应样本证据。
这样的交付能够明确回答：完整解码链已覆盖哪些版本转换，还有哪个兼容案例缺少验证。压缩率本身不是验收结果，一份可以打开的归档也未必包含故障的完整经过。
