搞Linux这行当绕不开的就是存储管理。我最早在机房折腾服务器的时候被磁盘满、IO飙升、挂载失败这些问题折腾得够呛后来才慢慢摸清楚存储管理其实是一条完整的链路从最底层的磁盘识别、分区规划到文件系统选型、挂载配置再到LVM逻辑卷管理、容量监控与故障排查。每一个环节都有坑而且很多坑是文档里不会写清楚的。这篇东西不打算写成命令大全而是想把我在生产环境里实际用过、验证过的Linux存储管理思路和操作抖出来。适合刚接触Linux的人也适合那些被存储问题反复折磨过的运维和开发者。你说你面试Linux岗位存储这块也是躲不开的考点你说你在维护服务器那磁盘规划和故障排查就是基本功。不管是哪种场景看完这篇你至少能对存储管理有一个从底层到上层的完整认知而且可以直接照着实操。1. 先把家底盘清楚Linux下的块设备识别与规划1.1 从lsblk开始的设备视角很多人一上来就敲fdisk -l这没错但我更习惯先用lsblk看整体拓扑。lsblk的输出是树状的能直观看到一块磁盘被分成了几个分区、每个分区又属于哪个逻辑卷、挂载在哪个目录下。这个视角对定位“我的数据到底放在哪块盘上”极其有用。$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 500G 0 disk ├─sda1 8:1 0 1G 0 part /boot └─sda2 8:2 0 499G 0 part └─vgdata-root 253:0 0 499G 0 lvm /从这个输出能看出来物理设备叫sda分了sda1和sda2两个分区sda2被做成了LVM物理卷上面建了逻辑卷vgdata-root最终挂载到根目录。这种层级关系用fdisk -l是看不出来的。设备命名的规律也需要心里有数sd开头的是SCSI/SATA/USB等走通用驱动框架的磁盘后面的字母按发现顺序排sda就是第一块sdb是第二块nvme0n1是NVMe固态硬盘0是控制器编号n1是命名空间里的第一块盘它下面的分区是nvme0n1p1这种带p的格式云服务器里常见的vda、vdb是虚拟磁盘。别小看这些命名细节后面排查“设备名漂移”问题的时候你会感谢自己懂这些。还有一个容易被忽略的点Linux里设备名是内核动态分配的重启之后/dev/sda和/dev/sdb可能对调。这也是为什么我一直强调能不用设备名就不用设备名后面讲/etc/fstab时我会重点展开。1.2 分区表选型MBR和GPT别选错分区表是磁盘最开头的元数据负责描述这块盘怎么切分。现在的服务器和PC基本都选GPT除非你有兼容老机器或老系统的特殊需求。MBR是老古董有四大限制单块盘最大只能认2TB超过的部分要么浪费、要么用非常规手段处理最多只能有4个主分区想多分就得靠扩展分区套逻辑分区麻烦分区表本身没有冗余校验坏了就真坏了只支持传统BIOS引导。GPT则没有2TB上限主分区数量理论上是128个并且分区表在磁盘开头和结尾各存一份有CRC校验坏了一份还能救回来。现在的UEFI引导也要求磁盘用GPT。实际操作中我建议超过2TB的盘一律GPT小于2TB但用于生产环境的新盘也没理由不用GPT。分区工具我基本用parted因为它同时支持MBR和GPT而且可以写脚本批量处理。# 使用GPT分区表 $ parted /dev/sdb mklabel gpt # 创建一个从1MiB开始、大小为500GiB的主分区 $ parted /dev/sdb mkpart primary 1MiB 500GiB # 查看结果 $ parted /dev/sdb print说一个细节parted创建分区时起始位置建议从1MiB开始不要从旧习惯的0或1MB开始这样可以保证分区对齐到现代磁盘的物理扇区上。不对齐的话读写会出现“读一个扇区要碰两次物理块”的情况性能会打折扣固态盘上影响更明显。这个细节是我当年做性能测试时发现的同一块盘对齐前后随机读写性能能差出百分之二三十。2. 核心环节格式化、文件系统选型与挂载2.1 文件系统选型ext4、XFS、Btrfs和ZFS怎么选分区建好之后要在上面创建文件系统这就是常说的“格式化”。文件系统选型是存储管理里最容易被低估的决策。我用过的文件系统不少给你一个真实场景下的选择逻辑。ext4是Linux的老牌默认文件系统兼容性极好几乎所有发行版都能挂载坏了也好修。如果你不确定该选什么选ext4不会犯大错。XFS在很多生产环境里是更好的选择尤其是数据库、虚拟化、大数据这类需要大文件、高并发读写的场景。XFS在并发写入上比ext4强支持在线扩容xfs_growfs而且挂载时用noatime选项能显著减少写操盘次数。Btrfs适合需要快照、压缩、校验和这类“高级功能”的场景比如个人NAS、容器存储池但它在某些高负载场景下出现过性能波动生产环境要慎重。ZFS不是Linux内核原生支持通常装在ZFS-on-LinuxOpenZFS里它功能最全但架构上需要吃比较多内存一般用在专门的文件服务器上。文件系统优点典型适用场景注意点ext4兼容性最好、修复工具成熟通用系统盘、/boot分区、不确定场景单文件上限较大但仍小于XFS的顺手区间XFS大文件、并发读写强、在线扩容方便数据库数据盘、虚拟化存储、大数据缩容很麻烦空间规划要一步到位Btrfs快照、透明压缩、自校验NAS、容器存储、个人折腾高负载下性能波动需实测ZFS(OpenZFS)数据完整性最强、压缩率高文件服务器、备份存储吃内存运维复杂度高我自己的习惯是根分区和/boot用ext4数据盘尤其是数据库目录用XFS特殊需求才考虑Btrfs或ZFS。格式化命令很直接$ mkfs.ext4 /dev/sdb1 $ mkfs.xfs /dev/sdc1等等在格式化之前我想提醒一句mkfs会清空整个分区上的所有数据执行前务必确认设备名没搞错。我见过不止一次因为云控制台和系统内的设备名对应关系看反了一条mkfs下去把数据盘格式化了。稳妥做法是先用lsblk -f或者blkid查出每个设备的UUID和已有文件系统再三确认再动手。2.2 挂载与/etc/fstab千万别让开不了机格式化之后分区要挂载到某个目录才能用。手动挂载一条命令就搞定$ mount /dev/sdb1 /data但重启之后这个挂载就没了所以要把挂载关系写进/etc/fstab让系统开机时自动完成挂载。/etc/fstab每行有6个字段依次是设备标识、挂载点、文件系统类型、挂载选项、dump标记、fsck顺序。这里要强调一个关键经验设备标识一定要用UUID不要用/dev/sdb1这种设备名。理由我在前面提过设备名在重启后可能漂移。假设系统识别顺序变了原来/dev/sdb1的设备变成了/dev/sdc1fstab里还写着/dev/sdb1开机时系统找不到设备会进入emergency模式搞不好连系统都起不来。而UUID是文件系统创建时生成的唯一标识和设备名无关能稳稳定位到正确的分区。获取UUID的办法$ blkid或者在lsblk -f的输出里直接看。然后编辑/etc/fstab比如把UUID为6c8f2c3a-xxxx-xxxx-xxxx的XFS分区挂载到/dataUUID6c8f2c3a-xxxx-xxxx-xxxx /data xfs defaults,noatime 0 2字段里defaults是最常见的挂载选项默认包含rw、suid、dev、exec、auto等。生产环境我通常会在数据盘上加noatime和nodiratime。atime记录文件最后被访问的时间每次读文件都要写一次这个时间戳对读多写少的数据盘完全是浪费IO。加了noatime之后省略这个写操作性能立竿见影。这算是我个人比较推荐的一个默认调优手段。修改完fstab后强烈建议先验证一下再重启避免写错了直接开不了机。最简单的验证方式$ mount -a它会按fstab尝试挂载所有未挂载的条目如果报错立刻在开机能救命的系统盘适配之前解决掉。不过mount -a不会发现“挂载点目录不存在”这种错误水平的问题所以更稳妥的是用findmnt --verify --verbose来验证fstab的完整性$ findmnt --verify --verbose这个命令会把fstab里的语法错误、目录不存在、文件系统类型不匹配等问题一次查出来是上线前必跑的一道检查。3. 弹性存储的关键LVM逻辑卷管理实操3.1 为什么生产环境离不开LVM讲LVM之前先说一个我亲历过的场景。早年在给一个业务系统加数据盘的时候预估容量做了2TB结果半年不到空间就吃紧了。物理分区遇上这种问题就非常尴尬你要么把数据拷到新的大盘上重新挂载要么在分区层面捣鼓缩容风险极高。用了LVM之后这个问题变成了一条命令的事。LVM的核心理念是把物理磁盘PVPhysical Volume聚合成一个资源池VGVolume Group再从资源池里划分出逻辑卷LVLogical Volume逻辑卷可以随时扩缩容。业务看到的是一个灵活的“虚拟磁盘”不用关心底层物理盘怎么分布。数据库文件、日志目录、虚拟机镜像这种后期经常会膨胀的目录特别适合放在LVM上做弹性管理。另外LVM还支持快照。在做某些高风险操作之前我可以对逻辑卷打一个快照操作失败后可以秒级回滚。这个能力在升级数据库、批量修改文件时太重要了靠备份重放或者rsync救援恢复时间都是小时级别的LVM快照只需要几分钟。3.2 从零构建LVMPV、VG、LV完整流程把整块盘加入LVM是最常规的操作完整流程我列出来你跟着做就行。第一步创建物理卷。假设有一块已经分好区的盘/dev/sdb1$ pvcreate /dev/sdb1 $ pvspvs可以看到PV的基本信息比如VG名称、PV大小、剩余空间。没有意外的话PV Size就是你给分区的大小。第二步创建卷组。比如把这块PV归入名为vgdata的卷组$ vgcreate vgdata /dev/sdb1 $ vgsvgs输出里重点看Free列的剩余空间这是你后续扩容逻辑卷的底气。第三步创建逻辑卷。比如在vgdata里创建一个名为lvdata、大小为1.5T的逻辑卷$ lvcreate -L 1.5T -n lvdata vgdata $ lvs第四步在逻辑卷上创建文件系统并挂载。逻辑卷的设备路径是/dev/vgdata/lvdata格式化之后挂载到/data$ mkfs.xfs /dev/vgdata/lvdata $ mount /dev/vgdata/lvdata /data注意为了在重启后自动挂载你还是要把这个逻辑卷的UUID写进/etc/fstab方法同前。3.3 在线扩容容量不够时的一条龙操作LVM最大的价值体现在“空间不够了”的时候。前提是VG里有剩余空间。如果vgs显示Free不够你可能需要先添加一块新物理盘然后pvcreate和vgextend把它并入现有VG再用lvextend把空间分给逻辑卷。假设VG里已经有剩余空间现在把lvdata从1.5T扩到2T$ lvextend -L 2T /dev/vgdata/lvdata扩容逻辑卷之后文件系统层面还得跟上。XFS和ext4的做法稍有不同# XFS $ xfs_growfs /data # ext4 $ resize2fs /dev/vgdata/lvdata这里有个非常容易踩的坑只执行lvextend、不执行xfs_growfs或resize2fs逻辑卷的大小变了但文件系统不知道df -h看到的还是旧容量业务自然也不会感知任何变化。在我遇到过的“扩容没生效”工单里有一半是这个问题。缩容则要谨慎很多尤其是XFS它不支持在线缩容。如果确实需要缩容传统做法是备份数据、删除逻辑卷、按新大小重建、再恢复数据。别在生产环境上硬来这个钱省不得。4. 容量与性能排查数据都说没就没都是哪里占的4.1 df和du的差异以及藏在进程里的已删除文件做运维的人都知道“磁盘满了”是高频事故。排查的第一步通常是$ df -h这个命令显示的是整个文件系统的使用情况能快速定位哪个挂载点的空间快满了。但有时候你会遇到一个诡异现象df -h显示挂载点使用率是99%但进到对应目录里用du -sh *逐个统计把所有可见文件加起来却只有一小半。这时候第一反应不要是系统坏了而是“有已删除文件被进程占着”。Linux的机制是这样的进程打开一个文件后删除了它文件在目录里看不到了但如果进程始终没关闭这个文件描述符这个文件占用的空间就不会真正释放。常见于日志服务、数据库、消息队列这类长驻进程。排查方法$ lsof -nP | grep deleted找到PID和文件路径后重启对应进程或者让应用重新打开日志文件那些空间就会立刻释放。这个坑尤其在处理大日志的Java应用里很常见直接删日志文件而不重启进程磁盘永远“满着”。另外一个容易忽略的是inode耗尽。df -i看的是inode使用率inode是每个文件/目录在文件系统上的“档案卡”。如果小文件特别多比如某个程序疯狂生成缓存文件inode消耗完以后即使磁盘还有大量剩余空间系统同样报“No space left on device”。这时用df -i确认再用find /data -type f | wc -l看看文件数量估算该清理的清理、该调整inode数量的提前规划好。4.2 IO瓶颈定位iostat与iotop的使用思路空间只是一方面性能问题才是真的让人挠头。系统变慢、数据库超时、应用卡顿很多时候是存储IO被拖垮了。我常用的排查组合是iostat和iotop。$ iostat -x -m 5-x显示扩展信息-m以MB为单位输出5是每5秒刷新一次。重点看%util、await和svctm。%util接近100%说明设备基本被打满await表示IO请求的平均等待时间数值越高说明排队越严重。如果await高但svctm不高通常意味着大量IO在排队而不是设备本身慢这可能是队列深度配置不合理或请求太碎导致的。确定磁盘有问题之后用iotop定位到具体是哪个进程在生产IO$ iotop -o-o只显示正在进行IO的进程不会刷出一屏无关内容。我发现过很多次性能事故的元凶就是某些后台进程在疯狂刷日志、或者备份脚本在对生产数据做全量扫描这种平时根目录都没别的事的进程用iotop一目了然抓到。5. 实战排查心法常见故障速查与事故复盘5.1 一张表收好存储故障速查思路存储相关的故障翻来覆去就那么几类我把高发问题、现象和排查方向整理成一张表你可以当速查手册。故障现象可能原因快速排查命令解决思路磁盘剩余空间充足但写文件报No spaceinode耗尽df -i清理小文件、增大inode或迁移到新文件系统df显示99%du却对不上已删除文件被进程占用lsof -nP | grep deleted重启进程或让应用重新打开日志挂载文件系统后目录是空的fstab挂载次序覆盖了目录findmnt /data调整挂载顺序确保原数据所在文件系统最后挂载系统启动进入emergency模式fstab设备名漂移或写错UUIDjournalctl -xb修复fstab改用UUID文件系统变成只读内核IO错误检测到文件系统异常dmesg | tail尝试remount ro-rw不行就fsck扩容后df不涨忘记扩展文件系统xfs_growfs /data或resize2fs执行对应文件系统的在线扩容命令磁盘IO高但CPU低存储子系统瓶颈iostat -x、iotop -o定位高IO进程优化IO调度或升级存储5.2 一次“把日志目录放进LVM”的生产事故复盘讲一个印象很深的案例。某年给一套业务系统做存储扩容新增应用模块需要一块1TB的数据盘客户那边前期规划图把日志目录和数据目录放在同一个物理分区的习惯又延续下来了。我当时强烈建议拆开日志目录放在LVM逻辑卷里方便后续单独扩充数据目录放在另一个逻辑卷且文件系统用XFS以应对高并发写入。后来某个晚上日志量暴涨整个文件系统直接被打满。因为两个目录在同一个逻辑卷上日志把空间全占了数据库开始报错写不进去。那一次事故如果没有LVM的隔离恢复时间会非常难看。当晚我先扩了日志卷的空间再给数据卷加了容量前后不到20分钟业务恢复。这个案例最值得记住的一点是存储规划要按路径隔离日志目录、数据目录、系统目录最好各放各的逻辑卷不要让一个目录拖垮全局。另一个细节是删日志文件不要用rm让应用自己处理日志轮转logrotate否则就会出现我前面说的“空间不释放”问题。logrotate配合copytruncate选项能让应用在不重启的情况下完成日志切换。写在最后的一点实际经验做了这么多年Linux的存储运维我最深的体会是存储管理最怕的不是技术上做不到而是规划时图省事、出问题时靠猜。给目录做分区和LVM规划的时候多花十分钟把设备清点清楚、fstab用UUID、能上LVM就上LVM、数据盘记得加noatime这些都是成本极低但效果极高的习惯。等真正出了故障你才知道当初这个十分钟有多值。最后再分享一个小习惯我每接管一台服务器第一件事就是跑一遍lsblk -f输出设备清单再核对一遍/etc/fstab里的每一项挂载是否合理并把UUID对应关系记录到自己的运维笔记里。这个习惯帮我省下了很多“莫名其妙磁盘不见了”的半夜工单。存储这种事讲究的就是一个“稳”前期多梳理一次后期就少折腾好几个晚上。