分区与 LVM 该不该用:先看它解决的问题是不是你的问题
根分区只给 30GB 往往不够,Docker 的 /var/lib/docker 默认就在根上
它擅长的是服务器分区规划;如果你只是在线扩容,用现成的东西更省事。
先说结论
LVM 的价值在「以后能改」,桌面用户直接用整盘分区更省事
- 适合:服务器分区规划
- 不适合:快照回滚测试环境
- 学习成本:lvextend -r 会在扩 LV 的同时 resize 文件系统,少一步手工操作
- 最大收益:LVM 快照不是备份,预留空间写满后快照直接失效且无法回滚
- 最大风险:根分区只给 20GB,半年后镜像和日志把它填满
它到底解决什么
根分区只给 30GB 往往不够,Docker 的 /var/lib/docker 默认就在根上。
换句话说,它把「服务器分区规划」这件事从手工变成可重复的流程。这是它真正的价值,而不是功能列表的长度。
什么时候不该用
下面三种情况,用了反而更累:
根分区只给 20GB,半年后镜像和日志把它填满
把 LVM 快照当备份,源盘坏了快照跟着一起没
扩容只跑了 lvextend 没 resize2fs,df 看还是老容量
和替代方案比
XFS 不能缩小,如果计划缩容,文件系统要选 ext4。
| 方案 | 上手成本 | 适用规模 | 代价 |
|---|---|---|---|
| 分区与 LVM | 中等 | 中大型 | 需要维护 |
| 整盘单分区 | 低 | 小型 | 定制能力弱 |
| ZFS 数据集 | 低 | 一次性任务 | 不可维护 |

这台工具的关键细节
几个决定长期体验的点:
- lvextend -r 会在扩 LV 的同时 resize 文件系统,少一步手工操作
- LVM 快照不是备份,预留空间写满后快照直接失效且无法回滚
- XFS 不能缩小,如果计划缩容,文件系统要选 ext4
- LUKS 加密后默认不做裸盘 TRIM,SSD 要加 allow-discards 才有回收
我的建议
LVM 的价值在「以后能改」,桌面用户直接用整盘分区更省事。
先用两周,跑一个真实的小任务;两周后你还想用它,再谈长期。
还有几处容易忽略的
都是小地方,但出问题时往往就卡在这里。
- swap 放在 LVM 上时,休眠需要 swap 不小于内存的 1.0-1.5 倍
工具是解法,不是身份。
评论 (3)
排查顺序那段直接抄进值班手册了。
版本差异要强调,我照着做结果参数名全变了。
备份没验证过等于没有,这条我认。
发表评论