Formality 文件损坏截断：corrupt / format error 速查
更新时间：2026-10-23。FAQ 速查页，属于 EDA 工具排错系列。fm_shell 在
read_db读库、加载 svf 引导文件、恢复上次保存的 session 时，报「文件损坏/格式错误」——文件明明在、ls -l看大小也不像空文件，但读到中途就抛错退出。这类问题几乎没有「就地修好文件」的选项，核心是确认文件确实坏了、定位坏在哪个环节、从上一个完好副本或版本库重新生成。半截文件最大的上游是上一次 run 撞上磁盘写满，那一刻的应急见 Formality 磁盘写满；读取侧还要排除版本不兼容的干扰，见 Formality 版本不匹配。
本文要回答的问题
- read_db 报 corrupt，文件大小正常，怎么确认它真的坏了？
- 上次保存的 session 这次加载失败，中间发生了什么？
- .db 库文件能不能修？还是必须从 .lib 重新编译？
- 同一个文件反复坏，是 Formality 的问题还是存储的问题？
一、报错原文与现象
Error: File 'libs/cells.db' has an invalid format. (FMT-1)
Error: read_db: database file 'ref/design.db' is corrupt or unreadable. (DB-017)
Error: svf file 'work/default.svf' ended unexpectedly at record 38412. (SVF-READ)
Error: Unable to restore session 'fm_save/fm_session.fss': checksum mismatch. (SES-REST)
Warning: file 'constraints.svf' appears truncated; ignoring trailing records.先分清两种形态。截断（ended unexpectedly / truncated）——文件尾部丢了，是写盘或传输被中断的签名：svf 记录写到一半、session 文件结尾的收尾块缺失。内容损坏（invalid format / checksum mismatch）——字节数在但内容错了，常见于 NFS 客户端读到缓存与服务端磁盘的混合体、两个进程并发写同一文件互相覆盖。两者恢复路径相同（找完好副本重生成），但防复发手段完全不同：截断防「写不完」，内容损坏防「写串了」。
二、原因速查表
| 报错现象 | 可能原因 | 处置 |
|---|---|---|
| svf 中途 ended unexpectedly | 上次 run 磁盘写满，svf 写了半截 | 作废重跑，从检查点重新生成 |
| session 恢复 checksum mismatch | 进程被 kill 时正在写 session 文件 | 删 session 重建，从头 setup |
| .db 读一半报 invalid format | 传输中断只拷了一半（scp/rsync 断） | 校验和比对后重传或重新编译 |
| 提交机能读、登录机不能读 | NFS 写缓存未落盘机器就重启 | 重挂载，服务端核对后重生成 |
| 重新生成后报错位置每次变 | 并发两个 run 写同一文件互截 | 隔离工作目录，生成侧原子写入 |
| 反复坏同一路径 | 文件系统错误，dmesg 有 I/O error | 换分区验证，报存储管理员 |
三、排查决策图
排查主线是「校验和先行分流」：先确认文件是不是真的坏了，再按损坏环节分流恢复——写穿或被杀的整段作废重生成，传输中断的重传，并发互截的隔离工作目录；文件没坏就转去查读取侧（NFS 缓存、工具版本）。图中红是报错入口与确认损坏的两类根因，蓝是排查动作，绿是「文件没坏、查读取侧」的分流，橙是三条恢复路径，紫是防复发收口。
四、逐条排查展开
第一步：file 与 ls -l 比对，确认文件身份与完整性。 文本类文件（svf、tcl 脚本、报告）看尾部，二进制文件（.db、session）看类型与校验和：
file libs/cells.db
ls -l libs/cells.db
md5sum libs/cells.db
tail -5 work/default.svf完好的 .db 用 file 应识别出数据库格式，半截文件常被识别成 generic data；完好的 svf 尾部是收尾记录（guide/verify 结束段），半截 svf 的尾部是「一条记录写到一半」——行中断在任意字符处。校验和与源头（生成机器或同事手上的副本）比对：一致说明文件没坏、问题在读取侧（NFS 缓存、Formality 版本），不一致就坐实是写或传环节出的半截。版本侧的分流口径见 Formality 版本不匹配。
磁盘写满写穿的产物链整段作废。 上次 run 撞上磁盘写满那一刻，正在写的 svf、session、中间数据库全是不完整状态；更隐蔽的是下游已读过这些半成品的结论也不可信——用半截 svf 跑出来的 verification 能通过 setup 不代表指导信息完整。处置纪律：从最后一个确认完好的检查点之后全部重跑，.db 从 .lib 重新 read_db 编译，svf 让上游综合或 DC 重新产出。写满那一刻的腾空间与写穿范围判断见 Formality 磁盘写满。
被中断的 session 文件删了重建。 save_session 写盘不是原子操作，进程被 kill（OOM、调度系统杀作业、误操作）时正在写的 .fss 就是半截，签名是 checksum mismatch 且文件修改时间与中断时刻吻合。session 只是现场快照、不是源头数据，处置很轻——删掉重建，从 start_verification 之前的 setup 脚本重放即可。这也是为什么 setup 流程要全部脚本化：session 随时可弃，重放成本接近零。
NFS 场景先怀疑落盘时机。 报错伴随 stale file handle，或「跑 batch 的机器能读、登录机读不了」，基本是客户端写缓存没落盘机器就重启了——客户端缓存里文件是完整的，服务端磁盘上只有半截。验证：直接到存储服务端读该文件算校验和，与客户端看到的比对。处置：重新挂载刷新缓存，服务端那份是半截就从源头重生成；日常挂载参数缩短属性缓存窗口（如 actimeo 调小）能压低这类不一致的概率。
并发互截与传输中断各按指纹处理。 调度系统里两个 job 共用同一工作目录，A 写 default.svf 时 B 也在写同名文件，互相截短、内容交错——指纹是报错位置每次重新跑都不一样；处置是每个 run 独立工作目录（目录名带作业号），共享库文件生成侧先写临时文件再 mv 原子改名。scp/rsync 拷库中断的指纹是文件大小与源端不一致；标准动作是源端算校验和写进交付清单，收端验过才入库，rsync 续传用校验和模式而不是按文件大小判断。文件系统层反复坏同一路径的（dmesg 有 I/O error），换分区验证坐实后报存储管理员，别在应用层反复重跑。
五、防复发纪律
- 每个 run 独立工作目录：目录名带作业号，杜绝并发互截与半截 session 交叉污染。
- 库交付必带校验和：.db、svf、netlist 跨机器交付，清单含 md5，收端验过才入库。
- 生成侧原子写入：一律先写临时文件再 mv 改名；共享库目录落地后只读化。
- 源头资产进版本库：.lib、rtl、约束与 setup 脚本全部入库，任何半截 .db 都能一键重编译。
- 慎用强杀信号：先给正常终止信号让 fm_shell 收尾写盘，等超时再升级；中断后的产物按写穿处理。
这一篇在知识体系里的位置
本篇是 EDA 排错速查簇中「数据完整性」节点的 FAQ 页，上承 Formality 磁盘写满（半截文件的最大上游，两篇是因果对：那篇管写满一刻，本篇管事后读回），旁接 Formality 版本不匹配（文件没坏但读不了的另一类原因，校验和一致时的分流方向）与 Formality 路径不存在（文件干脆找不到时的排查，与「找到了但是坏的」互为前序）。同型问题在 SpyGlass 侧的口径见 SpyGlass 文件损坏截断，恢复纪律互通。
一句话总结
Formality 文件损坏截断先用 file 与 ls -l 确认身份、算校验和与源头比对分流：一致查读取侧（NFS 缓存、工具版本），不符按环节恢复——磁盘写满或进程被杀写穿的整段产物链作废、从 .lib 与版本库重新生成，传输中断的校验和后重传，并发互截的隔离工作目录；治本靠「每 run 独立工作目录、库交付带校验和、生成侧临时文件原子改名、源头资产全进版本库」四条纪律，让半截文件在入库前被发现，而不是在 verification 流程里发作。