meta 快照目录权限位被 tar 抹平后我用 getfacl 补回来
上周在一台 Ubuntu 22.04 的备用机上恢复 meta 快照，数据量不大，约 8000 个文件、11GB，主要是配置目录和一批工具产物。现象很怪：文件内容完全对得上，但恢复后有几个服务起不来，报权限不足。
meta — meta的讨论、问答与经验分享
meta 校验脚本在 1.9 万条记录上换掉 hash 算法后慢了 3 倍
meta 校验脚本原来用的是 md5，前段时间想着换成 sha256 更稳妥，结果同一批 1.9 万条记录，跑一遍从 4 分多钟涨到 14 分钟左右。环境是 Ubuntu 22.04，Python 3.10，磁盘是普通 SATA SSD，单线程读文件算摘要，没做任何并发。
meta 快照校验跑一半被 OOM 杀掉，我改成按目录分片
meta 快照校验脚本在 3.2 万条记录上跑全量时被 OOM 杀掉，这个场景我遇到过两次：一次在 4 核 8G 的备用机上，一次在容器里内存限制 2G。现象很一致——前 1 万多条正常，之后 RSS 一路涨，最后被 kill。数据量不大，问题出在脚本把所有结果先攒在内存里再统一比。
meta 目录里 1.2 万个文件改了名，我用 diff 对出了漏改的软链
上周整理 meta 目录，把一批按日期命名的快照目录统一改成带业务前缀的名字，大概 1.2 万个文件、300 多个目录，环境是 Debian 12，ext4，meta 版本在配置文件里记的是 2.4.7。改完跑校验脚本，有三条记录报找不到文件，但 `ls` 看路径明明在。
meta 目录同步到备用机，我漏了 inode 这一层
两台机器之间同步 meta 目录，我之前的做法是 rsync -a 一把梭，看起来文件数、大小、mtime 都对得上，就默认两边一致了。直到上次做回滚演练才发现，备用机上有一批文件内容是对的，但校验脚本跑出来的结果和主库不一样。版本是 meta 0.9.x，目录里大概 1.2 万个文件、三层子目录，主备都是 ext4，量不算大，问题反而更容易被忽略。
meta 目录里 6000 个隐藏临时文件，我先按 mtime 圈了范围
meta 版本 2.4.1，CentOS 7 环境，仓库目录大概 18 万文件、3.2 GB。现象是 `du -sh` 和 `du -sh --apparent-size` 差了近 400 MB，`ls -la` 看不出异常，但 `find . -name ".*"` 会返回一大堆名字像 `.meta_tmp_*` 的东西。数量我数过一次，6000 出头。
meta 目录里 2000 个 0 字节文件，我用 awk 筛出来没敢删
meta 目录跑了一年多，版本快照和临时文件混在一起，`ls -l` 已经看不出异常。上周备份前扫了一眼容量，发现 `du -sh` 比 `df` 少了将近 3 个 G，才回头去数文件个数。
meta 目录里删掉的旧快照，被硬链接悄悄占着空间
meta 的目录从 1.2T 涨到 1.9T，我按 mtime 删了一批旧快照，du 一看只掉了 80G。df 却没怎么动。
meta 日志按天切分后，我用 logrotate 的 copytruncate 验证了一件事
meta 的日志之前一直是一整块，跑到第 9 个月时单文件到了 3.4GB，grep 一次要等十几秒，才决定按天切。环境是 Debian 12，meta 进程自己不做 reopen，切完不重启就得让 logrotate 替它把文件描述符保住。
meta 目录里 4000 个空文件，我用 find 找出它们又不敢删
上周清一个 meta 目录时顺手跑了 du -sh，结果是 3.1G，但同目录下 du -sh --apparent-size 只有 480M。差得太多，说明大部分体积是块占用而不是真实内容。我怀疑里面塞了大量空文件和小文件，于是先只做统计，不做任何删除。
meta 目录改完名，我用 inotify 才发现软链没跟着动
目录结构：meta 仓库在 /data/meta，线上服务读取的是 /srv/meta，中间是一层软链。版本是 meta 0.9.4，机器是 Ubuntu 20.04，目录里约 6.8 万个文件，单文件大多在 2KB 到 40KB 之间。现象是：在 /data/meta 里改文件名之后，服务端读到的还是旧名字，重启进程才恢复。
meta 配置文件里的时间戳，我按秒对齐才发现错位
meta 的配置文件里有个字段是上次同步时间，格式是 ISO 字符串带毫秒。我们线上有 6 个节点，配置由一份 meta 文件分发下去，大约 4.2 万行，单文件 380KB 左右。某天开始，两个节点报「快照过期」，另外四个正常。手动 diff 六个节点的 meta 文件，内容一模一样。
meta 快照回滚前，我先用 du 摸了一遍目录
上周在测试环境回滚一次 meta 快照，版本是 2024.3 的内网构建，数据量不大，目录 6.8GB、约 1.9 万个文件，主体是 JSON 描述文件和一堆按天切分的校验日志。现象是：回滚脚本跑了 4 分钟没结束，磁盘 IO 一直打满，最后 rsync 报了个空间不足退出，但 df 看还有 12GB。
用 meta 校验脚本只跑增量，我先在 1.8 万条上把 40 分钟压到 90 秒
meta 校验脚本一开始是给全量写的：读清单、逐条比对、最后汇总。数据量到 1.8 万条记录时，单次跑完要 40 分钟上下，CI 里基本没人愿意等它，结果就是大家绕开校验直接合。我后来做的不是优化单条速度，而是只跑增量——把「这次变了哪些」交给 git，校验脚本只接变更清单。
用 meta 校验脚本跑全量，我在 3.2 万条上撞了内存墙
环境是 Debian 12，Python 3.11，meta 校验脚本平时只跑增量的几百条，一直没出过事。上周做一次全量重跑，3.2 万条记录、单条平均 60KB，跑到第 1.8 万条左右进程被 OOM killer 干掉，dmesg 里能看到 oom-kill 记录，RSS 峰值到了 2.6GB，机器只有 4GB。现象很怪：单条解析很快，越往后越慢，最后直接没了。
用 rsync 同步 meta 目录，我漏掉了隐藏的校验文件
上周在测试机上跑一次 meta 配置同步，源目录 1.2GB、约 3.4 万个文件，其中大部分是历史快照。目标机是另一台内网机器，平时靠一条 rsync 命令推过去。现象很简单：同步完跑校验脚本，有 7 个 meta 文件报字段缺失，但源端读出来是全的。
用 meta 索引离线校验，我把 2 万条记录的等待压到 1 分钟
meta 仓库里有一份索引文件，记录了 2.1 万条记录的路径、大小和修改时间戳，每行一条。本地是 macOS + zsh，索引文件 18MB 左右。现象是：每次改动 meta 目录后跑校验脚本，都要全量遍历一遍目录再逐行比对，耗时 6～8 分钟，中间没有输出，很难判断卡在哪。最烦的是磁盘上有几个挂载点偶尔掉线，脚本会卡在 stat 上不返回。
meta 仓库里 37 个版本号，我用一条 grep 统一了
仓库里的 meta 目录下散着 37 个版本号：有的写在 JSON 的 `version` 字段，有的藏在 YAML 注释里，还有几个硬编码在脚本的 `VERSION=` 后面。上周要确认线上跑的到底是哪一版，我翻了三层目录才确认。
用 diff 比对 meta 配置时，我漏掉了注释行里的版本号
上个月排查一个线上问题，最后卡在 meta 配置的版本号上。环境是 Ubuntu 22.04，Python 3.11，meta 配置文件一共 6 个，单个文件 800 到 2000 行不等，注释行占比大概三成。现象是同一份 meta 在测试环境行为正常，到线上就报字段类型不匹配。
用 sqlite 存 meta 快照，我把 12 万条记录的回填压到 40 秒
环境是 Python 3.11 + Ubuntu 22.04，meta 服务每天产出一批 JSON 快照，单批大概 12 万条记录，字段 30 个上下，嵌套两层。之前回填校验是逐条读文件、拼 SQL 往线上库写，跑一次二十多分钟，中间断一次就得从头来。