local-lvm 满了

适用范围

lvs -a 里 local-lvm（LVM-Thin 池）的 Data% 或 Meta% 接近或到达 100%，表现为客户机写入失败、变成只读、性能骤降，或者 PVE 的任务日志里出现空间不足的报错。

不适用于：系统盘 local 满了（那是根分区/目录存储的空间问题，原因和处理方式不同），参考local 与 local-lvm 到底是什么里的第一个常见麻烦。

开始排查前

thin pool 写满时，正在运行的客户机可能已经文件系统损坏

LVM-Thin 是精简分配：池的总容量小于分给客户机的总容量。当真正的写入量追上池的物理容量，这不是一个温和的报错——正在运行的虚拟机/容器的写入会直接失败，此时客户机的文件系统很可能已经处于不一致状态。就算之后腾出了空间，客户机也不会自动变好，可能需要在客户机内部做文件系统检查，严重时要从备份恢复。

现在最要紧的不是马上扩容，而是先确认哪些客户机还在写入，把它们安全地停下来，防止情况继续恶化。

先弄清楚：

• 现在还有哪些客户机在运行、可能正在写入这个存储池？
• 满的是 Data% 还是 Meta%——处理方式不同，后面会分开说。
• 最近一次成功的备份是什么时候，覆盖到哪些客户机。

排查步骤

1. 确认满的具体是哪一项

lvs -a -o+metadata_percent

Data% 是数据空间的使用率，Meta% 是元数据空间的使用率。两者都可能到 100%，处理优先级不同：Meta% 满的风险更高，因为元数据描述了整个池的块分配关系，元数据空间耗尽会让整个池停止接受新的写入映射，哪怕 Data% 还没到 100%。

Data% 偏高、Meta% 正常 → 进入步骤 2 找占用大户。

Meta% 也在快速逼近 100% → 跳到步骤 6，单独处理。

2. 找出谁在吃空间

lvs -a
qm list
pct list

每台客户机的磁盘对应一个逻辑卷，名字类似 vm-<vmid>-disk-N。把 lvs -a 的输出按大小排序，对照 vmid 找出占用最大的几个。

3. 检查是不是快照在囤积空间

快照会持续占用空间，而且容易被遗忘：

qm listsnapshot <vmid>

删除不再需要的快照通常是安全的

删快照是一次数据合并操作，通常不会影响客户机当前的数据状态。真正的风险在于：如果快照链条本身已经因为空间不足而损坏，删除操作可能失败或者行为异常。先确认池还有一点余量能完成这次合并，完全写满的情况下操作本身可能都做不完整。

4. 判断受影响的客户机是否已经出问题

先不要重启任何一台受影响的客户机——重启触发的写入可能让已经不一致的文件系统进一步损坏。检查客户机内部的日志：

# 虚拟机/容器内部
dmesg | grep -i -E "error|read-only|i/o error"

分两种情况处理：

• 客户机还能响应，只是变慢或报个别写入错误：先在客户机内部停掉非必要的写入型任务，腾出空间后安排一个窗口做正常的关机（而不是强制重置），开机后在客户机内部跑一次文件系统检查(Linux 用 fsck,Windows 用 chkdsk)。
• 客户机已经卡死或持续报 I/O 错误：安全地执行 qm shutdown <vmid>(而不是 qm stop，更不是断电式重置)，等腾出空间之后再开机检查文件系统。

5. 按风险从低到高腾出空间

1. 删除确认不需要的快照(qm delsnapshot)——影响面最小。
2. 删除确认不需要的测试虚拟机/容器——同样是明确的清理，风险低。
3. 在客户机内部触发一次 TRIM/fstrim，把已删除文件的空间归还给池——注意如果池已经到 100%,fstrim 本身可能也会失败，这一步在还没完全写满之前做效果最好。
4. 扩容 thin pool——只有在卷组(vgs 的 VFree)确实还有空闲空间，或者能加一块新盘进卷组时才适用，具体步骤见local 与 local-lvm 到底是什么的扩容部分和加一块新盘。

6. Meta% 快满时，不要盲目扩容元数据

元数据空间紧张时，扩容元数据本身风险很高

Meta% 接近 100% 时，直觉是"扩大元数据卷就行了"。但元数据卷是整个 thin pool 结构的核心索引，在空间已经极度紧张的情况下执行扩容操作，操作本身如果失败或者中途被打断，可能导致整个 thin pool 的元数据损坏——这会让所有基于这个池的客户机磁盘一次性变得不可读，后果比单纯的"写满了"严重得多。

更安全的顺序是：

1. 先想办法腾出数据空间或者停掉写入，让系统有喘息余地，而不是第一反应就去动元数据。
2. 如果条件允许，先把最重要的客户机数据备份或迁移出去。
3. 确认对 LVM 精简池的元数据扩容操作(lvconvert 相关)完全理解其影响、并且当前池状态稳定之后，再考虑执行，或者优先寻求有经验的人确认。
4. 情况复杂、拿不准的时候，基于现有备份重建往往比在生产池上做元数据手术更可控。

确认恢复

1. lvs -a -o+metadata_percent 里 Data% 和 Meta% 都回到安全水位（建议低于 80%）。
2. 之前受影响的客户机能够正常开机。
3. 客户机内部的文件系统检查通过，或者已经从备份恢复并验证过数据完整性。
4. pvesm status 显示 local-lvm 状态正常。
5. 观察一段时间，确认空间占用增长速度符合预期，不是几分钟内又逼近满载。

仍未解决

如果元数据已经损坏，或者清理之后问题依然反复出现，带上以下信息求助：

lvs -a -o+metadata_percent
vgs

外加受影响客户机的 dmesg/日志片段，以及你已经尝试过的操作列表（避免别人建议你重复危险操作）。参考如何有效求助。如果元数据确认损坏且没有把握自行修复，基于备份完整重建通常是更稳妥的路径，参考恢复演练。

参考资料

• local 与 local-lvm 到底是什么
• 精简置备与空间回收
• 加一块新盘：三种做法
• 恢复演练