1. 先看清存储堆栈的全貌：从硬盘到挂载点之间发生了什么
“凡人修云传”这个系列写到第九篇，终于轮到存储了。我之所以把存储放在这个位置而不是更早，是因为在真实的云环境中，网络、计算、身份这些基础能力往往决定了服务能不能跑起来，而存储则决定了它能跑多久、跑得多稳、数据会不会丢。一句话总结就是：前面几篇在教你盖楼，这一篇开始教你打地基里最容易被忽略的那部分——存储堆栈。
很多刚接触云主机的朋友会有个直觉：存储不就是一块硬盘吗？云主机创建的时候选了系统盘，数据盘也挂上了，格式化之后mount一下，能读能写不就行了？这种想法在单机个人电脑时代勉强够用，但在云环境里，尤其是涉及多节点、高可用、容器化调度、数据库落盘这类场景时，存储是一个从物理设备到应用可见路径之间叠了好几层抽象的结构。这一层一层的抽象，就是所谓的“存储堆栈”。
我做个拆解。一台普通的Linux云主机，从底层到应用层，要经过的存储路径大概是这样：
- 物理存储设备：可能是云平台给你分配的云硬盘，对应到虚拟机里是/dev/vda、/dev/vdb这样的设备节点。
- 存储控制器/驱动层：云平台上IO请求从虚拟机经过虚拟化层到达底层分布式存储，这一步对云主机内的管理员基本是黑盒，但往往也决定了单盘性能上限。
- 设备映射层：在系统里，/dev/vdb可能不是直接拿来用的，它可能被卷管理、软RAID、设备映射（device mapper）再包一层。
- 分区层：用fdisk或parted在整块盘上划出分区，形成/dev/vdb1。
- 文件系统层：在分区之上格式化出ext4或xfs，形成用户可读写的目录结构。
- 挂载层：把文件系统挂载到某个目录（挂载点），应用才能真正往里面写文件。
注意，我上面列的这六层，前五层任何一个环节出了问题，应用层都会表现出“磁盘不可用”或“IO异常”，但报错信息往往只停留在最表层。这也是为什么很多人排查存储问题时一头雾水——因为你对整个堆栈没有完整认知，根本不知道报错来自哪一层。
用一个生活化的类比来说，存储堆栈就像一栋楼里的快递分拣流程。快递（数据）从快递员（物理磁盘）送到楼下收发室（设备映射），收发室按楼层分类（分区），每一层楼有自己的储物间（文件系统），最后住户（应用）到储物间取件（读写数据）。如果楼下的收发室临时关闭了，住户只会觉得快递收不到了，但问题到底出在哪一层，得逐层去查。
所以这一篇的核心任务，就是带你以“管理存储堆栈”的视角，把每一层的职责、操作方式和常见坑位都过一遍，这样以后再遇到存储问题，至少能先判断出大概方位，而不是整个下午都在瞎试。
2. 新盘接入后的标准操作顺序：从/dev/vdb到可用目录
我们直接从最常见的场景开始：你在云控制台上给一台Linux云主机创建了一块新的数据盘，重启之后进入系统，现在要把它变成某个应用可以读写数据的目录。整个生命周期里的标准操作可以分成五步。
2.1 识别磁盘设备名，别把盘认错了
登录服务器后第一件事，确认系统认到了这块新盘。命令是lsblk，它比fdisk -l更直观，能展示出设备层级结构：
[root@cloud ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 253:0 0 40G 0 disk └─vda1 253:1 0 40G 0 part / vdb 253:16 0 100G 0 disk这里vda是40G系统盘，已经有了分区vda1并且挂载为根目录；vdb是一个100G的空盘，没有分区，没有文件系统，也没有挂载点。这就是我们要处理的目标。
这一步最容易犯的错是设备名拼错或者认错盘。如果你在云控制台同时挂载了多块数据盘，注意不要把数据盘名称（比如disk-xxxx）和系统内设备名搞混，也别想当然认为vdb一定对应控制台上的第二块盘。保险做法是用lsblk确认容量大小和挂载状态，再结合云控制台信息交叉核对。
2.2 分区还是不分区，这是个判断题
接下来要做一个很多人没仔细想过的决定：这块盘是直接格式化用，还是先分区再用？
两种方式都能用，差别在于运维弹性。我个人的建议是：需要后续扩容的盘建议分区，一次性固定的盘可以直接格式化。但更准确地说，这要看你的文件系统和后续管理计划。
- 直接格式化整块盘：mkfs.ext4 /dev/vdb，好处是命令少、路径清晰，后续用resize2fs扩容也支持，坏处是如果你想在同一个盘上切出不同用途的区域（比如一部分给日志、一部分给数据），只能靠目录区分，或者事后被迫做迁移。
- 先分区再用：fdisk或parted创建分区，再格式化/dev/vdb1。好处是结构清晰，后续可以在同一块盘上加分区；坏处是多一层分区表，如果分区表损坏恢复更麻烦一点。
在云环境里，由于底层块存储本身就是虚拟化的，传统的分区对齐问题（比如起始扇区对齐到2048）基本已经由现代分区工具自动处理，不需要太操心。不过如果你手上有老资料建议分区起始扇区从2048开始，现在parted默认就是对齐到1MiB，不需要额外指定。
我自己的操作习惯是：如果是给数据库用的高性能盘，整块盘直接格式化不分区，减少一层间接；如果是通用数据盘，按用途分两到三个区，比如/data/log和/data/service分开。这样日志写满的时候不会把业务数据目录也堵死，故障隔离效果更好。
2.3 分区实操：一段fdisk对话记录
选择分区方案后，实际操作其实很简单。下面我用fdisk走一遍创建单分区的过程：
[root@cloud ~]# fdisk /dev/vdb Welcome to fdisk (util-linux 2.37.4). Changes will remain in memory only, until you decide to write them. Be careful before using the write command. Command (m for help): n Partition number (1-4, default 1): 1 First sector (2048-209715199, default 2048): （直接回车） Last sector, +/-sectors or +/-size (2048-209715199, default 209715199): （直接回车） Created a new partition 1 of type 'Linux filesystem'. Command (m for help): p Disk /dev/vdb: 100 GiB, 107374182400 bytes, 209715200 sectors Device Boot Start End Sectors Size Id Type /dev/vdb1 2048 209715199 209713152 100G 83 Linux Command (m for help): w The partition table has been altered. Syncing disks.如果你用的是超过2T的盘，建议直接用parted加GPT分区表，fdisk默认MBR只支持到2T，虽然新版fdisk也能操作GPT，但为了少踩坑，大容量盘用parted更顺手：
parted /dev/vdc mklabel gpt parted /dev/vdc mkpart primary ext4 1MiB 100% partprobe /dev/vdc这里有个细节值得注意：fdisk的交互过程里，按w写入分区表之后，内核不一定立刻刷新分区信息。老一些的系统可能提示“内核仍然使用旧分区表”，这时候需要运行partprobe或重启系统，让内核重新读取分区表。新版系统一般会自动同步，但养成执行partprobe的习惯能避免很多诡异问题。
2.4 格式化与挂载：最后两步不能忽略的细节
分区创建好后，格式化文件系统：
mkfs.ext4 /dev/vdb1如果这是一块业务数据盘，我建议加上-L参数给文件系统设置一个卷标（label），比如-L data。因为在系统里设备名可能漂移，但卷标是稳定的标识，后续排查或自动化脚本里用卷标定位会比用设备名可靠得多。
格式化的时间取决于盘的大小。100G的盘ext4格式化一般几十秒到几分钟，如果格式化时间异常长，可能需要检查底层存储的IO性能。
然后创建挂载点并临时挂载验证：
mkdir -p /data mount /dev/vdb1 /data df -h /data能正确显示容量和使用率就说明整个路径通了。但到这里还不够——重启之后这个挂载是不会自动恢复的，必须写入/etc/fstab。这一步踩坑的人最多，我在下一节单独讲。
2.5 这里有一个新手容易犯的错误
很多新手在fstab里直接写设备名，比如/dev/vdb1 /data ext4 defaults 0 0。如果这台机器是KVM虚拟机或物理机，一般问题不大；但在云环境里，设备名可能在每次开机时发生变化。比如之前是vdb，下一次开机变成vdc，fstab里还是写vdb，那数据盘就没挂上，系统启动时反而会因为找不到设备而报错进入紧急模式。
所以我强烈建议fstab里用UUID或卷标来标识设备，而不是设备名。获取UUID的方式：
blkid /dev/vdb1然后fstab里这样写：
UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /data ext4 defaults,nofail 0 0注意我加了nofail选项。这个选项的含义是：如果这块盘因为某种原因没有正常挂载，系统不会卡在启动流程里，而是跳过继续启动。对云主机来说，这个选项几乎必加。否则一旦云平台调度导致设备名变了或者盘暂时没就绪，你连SSH登录都进不去，还得去控制台折腾救援模式，那是非常痛苦的一件事。
3. 文件系统选型：ext4不是唯一答案，但大多数时候是最稳的选择
很多人格式化的时候习惯性打mkfs.ext4，从来没想过为什么用ext4，也没想过其他选项。存储堆栈里文件系统这一层，是最贴近应用也是最容易影响性能的一层，值得花点时间想清楚。
3.1 常见几种文件系统的真实差异
我列一个尽量简单的对比表，基于我在实际生产环境里的观察，而不是纯理论：
| 文件系统 | 成熟度 | 适合场景 | 主要优势 | 主要顾虑 |
|---|---|---|---|---|
| ext4 | 极高 | 通用业务盘、OS盘、虚拟化镜像存储 | 全Linux发行版默认支持，故障修复工具成熟稳定 | 单文件最大16T，单盘扩展能力有限，不支持块级校验 |
| xfs | 高 | 大数据量、视频文件、Kafka日志目录 | 高吞吐、大文件性能好，支持在线扩大文件系统 | 在线收缩文件系统困难（基本不可收缩），内核崩溃恢复稍慢 |
| btrfs | 中 | 个人开发环境、需要快照和压缩的轻量场景 | 内置快照、子卷、压缩、校验和 | 重负荷运维场景下稳定性和工具链成熟度仍需评估 |
| zfs | 中高 | 存储服务器、备份服务器，需要极致数据完整性 | 校验和、快照、压缩、RAID-Z一体化 | Linux下默认未集成，需要额外模块，对内存要求高 |
从这个表你可以看出，不同的文件系统不是简单的“谁比谁快”，而是“谁更适合哪种工作负载”。
3.2 我实际使用时怎么选
以我自己的项目经验来说，几个典型场景的选择是这样的：
- 数据库数据目录：如果没有专门存储设备，优先用xfs或ext4，这两个在单机场景下的随机读写性能没有本质差别，真正的影响因素是磁盘本身类型（SSD还是HDD）、IO调度器、文件系统挂载参数，而不仅仅是文件系统选择。在InnoDB这类直接绕过文件系统缓存（O_DIRECT）的场景下，文件系统的存在感其实不高。
- 日志队列目录（比如Kafka、ES的data目录）：强烈建议xfs。Kafka官方文档里明确推荐xfs，因为它在顺序写入和大文件连续分配方面比ext4表现更稳定，文件系统碎片对吞吐影响更小。
- 个人开发机或实验环境：btrfs可以玩一玩，快照功能在折腾系统配置时非常有用，回滚就是一条命令的事。
- 备份服务器：zfs值得考虑，校验和机制能发现静默数据损坏，快照和复制功能也能配合远程备份策略。
说到挂载参数，这里还有个小细节：ext4在挂载时有个data=writeback选项，可以降低写屏障的开销提升性能，但代价是断电时可能丢最近几秒的文件系统元数据一致性。数据库和核心业务数据不要用，日志型、可重建的数据可以用。xfs默认就在较小程度上权衡了这类问题，不需要特别配置。
3.3 在线扩容：一个必需掌握的技能
没有哪个系统是一开始就规划得刚刚好的，数据涨起来之后，扩容是几乎必然遇到的需求。
ext4的在线扩容流程是“先扩块设备再扩文件系统”。假设云控制台把vdb从100G扩到了200G：
# 1. 刷新内核识别到的块设备大小 echo 1 > /sys/class/block/vdb/device/rescan # 部分环境用 growpart 或直接重启 # 2. 扩分区（如果是分区表方式） growpart /dev/vdb 1 # 3. 扩文件系统 resize2fs /dev/vdb1xfs对应的步骤是：
growpart /dev/vdb 1 xfs_growfs /data注意xfs扩容之后不能缩，缩了数据就没了。所以规划xfs分区时，初始分区分得小一点完全没问题，后面大方向扩容就行，但一定要想清楚“只增不减”这个特性。
我之前就遇到过一个真实项目：有人把Kafka的日志目录用xfs挂在了一个30G的盘上，后来数据量涨得厉害，把盘扩到200G倒是很顺利，但到月底想缩一部分容量给另一套业务，才发现xfs没法在线缩。最后只能停机迁移数据到新盘，然后重新挂载。如果当初第一版就做好了容量规划，根本不会有后面的折腾。
4. 存储堆栈的常见故障现象与排查路径：我踩过的三个坑
存储是运维里最“难”排障的部分，因为它的问题不会只在某一层爆发，而是从底层向上传导。我把自己在实践里遇到过的三类典型问题写出来，每一类都包含完整的排查思路，不一定能覆盖你所有场景，但至少能帮你建立“逐层排查”的方法论。
4.1 故障现象一：挂载后写入报Read-only file system
这是一个看起来简单但很容易误判的问题。第一次遇到时，我以为是自己目录权限没配对，反复chmod和chown都没用，最后用mount命令一看才发现根因：
[root@cloud ~]# touch /data/test touch: cannot touch '/data/test': Read-only file system [root@cloud ~]# mount | grep /data /dev/vdb1 on /data type ext4 (ro,relatime)挂载状态里明确写着ro。为什么文件系统会变成只读？
根因绝大多数是文件系统内部检测到不一致（inconsistency），为了避免进一步损坏，内核主动把文件系统切换为只读。这个机制叫“文件系统错误处理策略”，ext4默认的错误行为就是remount-ro。
排查方法：先看dmesg尾部，确认是不是IO错误：
dmesg | tail -50如果能看到类似“Buffer I/O error on device vdb1”“EXT4-fs error (device vdb1)”的日志，那基本确认是文件系统层面发现了IO问题或内部损坏。这时候不要强行mount -o remount,rw去改回可写，那是跟内核的自我保护机制对着干，会让脏数据继续写入，造成更严重损坏。
正确做法是：
- 若盘未卸载，先umount（如果卸载不了，说明有进程占用，用lsof或fuser确认占用进程）。
- 执行文件系统检查和修复：e2fsck -f /dev/vdb1，xfs文件系统则执行xfs_repair -L /dev/vdb1（-L表示清空日志，谨慎使用）。
- 修复完成后重新mount，再写入测试。
这类问题在云盘上还经常伴随底层存储节点抖动。如果你确认本机操作没问题，报告发给了云厂商客服，但对方查了很久也没定位到，那有可能是云平台底层迁移或存储节点维护导致短暂的IO异常，属于基础设施层面的偶发问题。此时记录好时间点，优先保证数据恢复，不用太纠结根因。
4.2 故障现象二：df正常，但写大文件时卡死或超时
另一个高频问题是：应用正常跑着跑着突然变慢，写文件时卡住，df看磁盘空间和inode都还正常，iostat看使用率也不高。
这种情况的元凶经常藏在存储堆栈的中间层——设备映射。如果系统里用到了LVM（逻辑卷管理），整条链路变成了物理盘 -> PV -> VG -> LV -> 文件系统。任何一层有故障都会导致行为诡异。
我遇到过一个非常典型的案例：数据盘是LVM管理的，某天写入突然变得极其缓慢，但iostat显示物理盘使用率只有10%左右。后来排查发现，LVM底层对应的物理卷所在的物理盘有坏块，IO重试机制导致每次写入都要等很长时间的超时，然后才切换路径。这个“等待”在应用层看起来就是卡顿。
排查链路是：
# 1. 看整个存储堆栈结构 lsblk pvs # 查看物理卷状态 vgs # 查看卷组状态 lvs # 查看逻辑卷状态 # 2. 看IO等待情况 iostat -x 1 # 重点看await、svctm、util，util低但await高，就有可能是硬件或底层在重试 # 3. 查看内核IO错误日志 dmesg | grep -i error找到根因后，如果是坏块导致的，能修复的用fsck或smartctl进一步确认；不能修复的就得从备份恢复或者导出数据了。
这个案例的通用价值在于：存储故障不是一个平面，而是一条链路。你只有把lsblk输出的每一层都看明白，才能确认问题卡在哪个环节。
4.3 故障现象三：fstab写错导致系统启动进入紧急模式
这个坑可以说是每个Linux运维都至少踩过一次的。原因往往是fstab里新增了一行挂载配置，但设备名不对、UUID写错、或者文件系统类型填错，开机时系统尝试挂载发现失败，默认策略下就会放弃继续启动，进入emergency模式，连SSH都连不上。
如果遇到这种情况别慌，用云控制台的VNC登录（或者救援模式）进入系统，把fstab里的错误行注释掉，重启即可。但这个过程非常耽误时间，尤其是在Notebook上没有VNC权限的环境里，只能反复提工单。
更好的做法是养成一个习惯：每次修改fstab后，先执行mount -a测试。mount -a会尝试重新挂载fstab里的所有条目，如果配置有误会立刻报错，而不会等到重启才暴露：
[root@cloud ~]# mount -a mount: /data: wrong fs type, bad option, bad superblock on /dev/vdb1, missing codepage or helper program, or other error.看到这样的错误，马上回头检查fstab那一行，把问题消灭在重启之前。
5. 存储管理的日常习惯：几个让我少吃苦头的检查要点
说了这么多具体操作，最后再分享一些我在实际运维中沉淀下来的习惯。这些东西不在任何官方文档里写得特别详细，但对长期维护多台云主机的场景非常有用。
5.1 定期做空间与inode的双重体检
很多人监控磁盘只看df -h，看容量用完了就清理文件，却忽略了inode数量。inode是文件系统里记录文件元数据的结构，每个文件（包括目录）都要占用一个inode。如果文件系统里的inode耗尽了，即使磁盘还有大量空间，也无法创建任何新文件。
判断方法：
df -i /data如果IUse%接近100%，说明inode耗尽。常见的罪魁祸首是某些程序疯狂产生小文件，比如未清理的日志文件、邮件队列临时文件、消息中间件消费失败产生的死信等。
我自己的习惯是写一个简单的巡检脚本，每天cron跑一次，检查各挂载点的容量和inode使用率，超过阈值就告警到企业微信或Telegram Bot。这样可以在故障发生前就介入处理，而不是等到业务写不进文件才被动响应。
5.2 大目录与文件分布画像
如果磁盘空间确实满了，下一步要快速找出空间都被谁吃了。du和find是这时候最趁手的工具：
# 找出根目录下最大的几个目录 du -h --max-depth=1 / 2>/dev/null | sort -hr | head -20 # 找出某个目录下最大的文件 find /data -type f -size +1G -exec ls -lh {} \; 2>/dev/null | awk '{print $5, $9}' | sort -k1 -rh注意，du在超大目录上可能跑得很慢，建议用--max-depth控制扫描深度，或者用ncdu这个交互式工具快速定位。
5.3 备份意识：存储堆栈里滚烫的一课
说到备份，我在这里想再多说一句。云平台通常会承诺底层磁盘的持久性和副本机制，但那是针对物理硬件的，并不能保护你免受误删文件、软件bug覆盖数据、或恶意脚本删库的伤害。真正能兜底的，只有你自己的备份策略。
针对基本存储场景，一个足够的基础备份方案是：用rsync做异地文件同步，配合存储快照做时间点回滚。云平台一般都有磁盘快照功能，在控制台里点一下就能创建，成本很低。数据库类应用则应该做逻辑备份（如mysqldump、pg_dump）或基于binlog的持续备份。
我见过太多人觉得“云盘本身就双副本了，不需要额外备份”，直到某一天一个rm -rf误操作执行在不该执行的地方，或者一次变更脚本里的bug把数据目录清掉，才追悔莫及。存储分层再健壮，也挡不住逻辑层的失误。
5.4 每次变更留痕：文档比记忆可靠
最后一条是关于流程管理的：每一次对存储的变更，都要记录下来。包括初始设备名、UUID、分区布局、文件系统、挂载参数、扩容时间点、备份策略。云平台上的虚拟机有可能被销毁重建，如果只有系统里存在，再重建时就只能靠经验和猜了。
我自己是用一个简单的Markdown文档，每台服务器一页，把存储相关的元信息整理清楚。看起来笨，但真正派上用场的时候能省几小时的排查时间。
存储堆栈的修炼，核心不在于背命令，而在于建立这种“从底层到应用一层层看问题”的思维。当你能在脑海里把一块云盘从物理设备到挂载点的整个路径勾勒出来，遇到问题不再慌，才算真正入了这一门的门。凡人修云，修的不只是工具熟练度，更是这种全局的视角。
