在线扩容需严格按存储栈层级操作：先确认物理设备、PV、LV、文件系统类型及挂载点，再依次执行partprobe/pvresize、lvextend、resize2fs或xfs_growfs，任一环节遗漏将导致扩容失败。
在线扩容不是“点一下就变大”，而是要分清路径：文件系统类型、底层设备类型、是否在 LVM 管理下——三者任意一个不匹配，resize2fs 或 xfs_growfs 就会直接报错或静默失败。
确认当前存储栈层级关系
先搞清楚你扩的是什么：是物理盘、PV、LV、还是裸分区？很多操作卡住，是因为误把 LV 当成普通分区处理。
- 运行
lsblk查看块设备树形结构，重点关注TYPE列（lvm/part/disk） - 用
pvs、vgs、lvs确认是否处于 LVM 管理；若无输出，说明没走 LVM，别碰lvextend - 查挂载点对应设备：
df -hT /mnt/data→ 看出是/dev/sdb1还是/dev/mapper/vg0-lv_data
ext4 文件系统在线扩容步骤（非 LVM 场景）
适用于直接挂载了分区（如 /dev/sdb1）且已扩容底层磁盘（云平台或虚拟机中已完成磁盘扩容）的情况。
用于自动切换项目中适合的node 版本
下载
根据 package.json 中的 engines 字段自动检测 Node.js 版本需求，未安装 nvm 时自动安装并切换至对应版本。支持 Windows、macOS、Linux。适用于 Node.js 项目开发、版本切换和环境配置。
- 必须先让内核重读分区表：
partprobe /dev/sdb或echo 1 > /sys/block/sdb/device/rescan - 检查分区大小是否已更新：
fdisk -l /dev/sdb→ 对比Start和End是否变大 - 若分区未扩大，需用
growpart扩展分区本身（不是文件系统）：growpart /dev/sdb 1 - 最后执行
resize2fs /dev/sdb1（无需卸载，ext4 支持在线扩展）
XFS 文件系统只能向后扩容，且不支持缩容
XFS 的设计决定了它对扩容路径极其敏感：必须确保底层块设备容量已增大，且文件系统挂载时启用了 inode64（现代内核默认开启），否则可能因空间寻址越界失败。
- 确认文件系统类型：
xfs_info /mnt/data输出中data行的agcount和agsize可反映当前布局 - 扩容前必须确保设备容量已更新（同上，
partprobe或rescan不可省） - 执行
xfs_growfs /mnt/data（注意：参数是挂载点，不是设备路径！传/dev/sdb1会报错Invalid argument） - 如果提示
device does not support resizing，大概率是设备未真正扩容或未重读分区表
LVM 场景下漏掉 PV 扩容会导致 LV 扩不出去
很多人执行完 lvextend -l +100%FREE /dev/vg0/lv_data 却发现没变化，其实是忘了最上面那层：物理卷（PV）还没拿到新空间。
- 云盘扩容后，先确认
fdisk -l /dev/sdb显示容量已变；若仍是旧大小，需先用growpart /dev/sdb 1扩分区 - 再执行
pvs，看PFree是否增加；若仍为 0，说明 PV 未识别新空间，需运行pvresize /dev/sdb1 - 之后才能用
lvextend，最后才是resize2fs或xfs_growfs - 顺序不能颠倒：
pvresize → lvextend → fs resize，中间任一环缺失都会导致“明明扩了磁盘却没效果”
#!/bin/bash # 快速检查脚本：判断 ext4/XFS 在线扩容前置条件是否满足 MOUNT_POINT="/mnt/data" DEV=$(findmnt -n -o SOURCE "$MOUNT_POINT" | sed 's/[0-9]*$//') if [[ -z "$DEV" ]]; then echo "未找到挂载设备"; exit 1; fi <p>echo "检测设备: $DEV" echo "文件系统类型: $(findmnt -n -o FSTYPE "$MOUNT_POINT")" echo "内核是否识别新容量: $(blockdev --getsize64 "$DEV") bytes" echo "PV 状态: $(pvs "$DEV" 2>/dev/null | tail -n +2)"</p>
最容易被跳过的动作是 pvresize 和 partprobe ——它们不报错，但也不做任何事，除非你主动触发。扩容失败时，先别查文件系统命令，回头看看 pvs 和 lsblk 的输出有没有变化。
