Linux运维避坑指南：分区方案与文件系统选型实战

做Linux运维这些年我踩过最大的坑几乎都集中在同一个地方分区和文件系统。磁盘满了系统卡死、删了文件空间不释放、重启后挂载不上进不了系统这些问题一旦碰上轻则手忙脚乱重则数据丢失。其实大部分故障只要在装机时把分区方案想清楚、文件系统选对完全可以避免。这篇就围绕Linux系统分区和常用文件系统把我实际用过的方案、翻过的车、沉淀下来的命令和思路一次说清楚。不管你刚接触服务器还是已经被线上环境折磨过几轮这篇都值得花十分钟看完。1. 为什么分区是Linux运维的必修课很多新手装Linux时一路默认一个根分区从头用到尾当时看着没什么问题等到系统跑起来才发现隐患日志把磁盘塞满、根分区空间告急、重装系统时数据全部陪葬。分区这件事本质上不是给磁盘切块那么简单而是给系统的不同部分划清边界让它们互不干扰。1.1 分区的本质把一块大磁盘变成多个独立的“工作台”分区的概念说起来很直白把一块物理磁盘在逻辑上划分成多个独立的存储区域每个区域可以单独格式化、单独挂载、单独管理。它就像一个大型仓库物理上是一整间但用隔断分成多个小隔间每个隔间可以放不同类别的货物某个隔间出了问题也不会影响其他隔间。实际运维中这种“隔离”带来的好处远超想象。举个例子Web服务器的访问日志和系统日志如果跟根分区放在一起日志量一涨/目录被写满整个系统就会陷入半瘫痪状态连登录都费劲。但如果你把/var独立分区日志再膨胀也只是/var这个分区爆满系统本身的运行不受影响你还有机会从容地做清理。还有一个非常现实的场景是系统重装。很多云服务器或者物理机在重新部署系统时如果/home、/data这类数据目录没有独立分区格式化根分区时数据就全没了。而把用户数据和系统本身分开重装系统只是格式化/分区数据分区原封不动这是生产环境中非常常见的需求。1.2 MBR与GPT这个选择决定你能用多大磁盘分区表格式直接决定了磁盘能用多大、能分多少个区这一步错了后面再改很折腾。目前主流的就两种MBR和GPT。MBR是传统的老标准最大只能识别2TB容量的磁盘超过2TB的部分直接浪费。而且MBR分区表里最多只能有4个主分区想分更多就得用扩展分区套逻辑分区操作起来又绕又受限。2010年以前的机器基本都是这套方案但现在新买的服务器和硬盘单块容量动不动就4TB、8TBMBR显然顶不住。GPT是新一代标准理论上支持最大8ZB的容量这是MBR完全无法比拟的量级。分区数量上GPT默认支持128个分区实际使用中几乎不会触顶。更重要的是GPT分区表在磁盘头部和尾部各存了一份某一份损坏了还能用备份恢复安全性比MBR高一个档次。怎么判断当前磁盘用的是什么分区表一条命令就能看parted /dev/sda print输出里显示Partition Table: gpt那就是GPT格式显示msdos就是MBR格式。现在的新机器只要不是有特殊兼容性要求直接上GPT别犹豫。1.3 分区方案设计我的标配长什么样分区方案没有标准答案但有一个原则按“系统”和“数据”的边界来切。我在大部分Linux服务器上用的方案是这样/boot单独分区1GB足够存放内核和引导文件/根分区50GB到100GB装系统软件和系统配置/home单独分区视用户数据量定大小/var单独分区至少留出几十GB放日志和缓存/data单独分区放业务数据数据库文件、上传文件等swap交换分区物理内存不大于16GB时分配和内存相当或减半即可这个方案的逻辑很简单系统软件占满根分区不影响用户数据日志占满/var不至于拖垮根分区业务数据独立出来方便备份和迁移。当然如果只是个人学习用的虚拟机一个根分区加一个swap也能跑但生产环境建议还是按上述思路走多花不了几分钟后面省的事可不止几小时。2. 常用文件系统怎么选没有银弹只有适不适合文件系统是分区之上承载体数据和目录结构的那一层。选错文件系统就像给厨房铺了地毯表面看起来行真用起来处处别扭。Linux下常见的文件系统有ext4、XFS、Btrfs、ZFS等各有各的脾性。2.1 ext4老而弥坚的默认选择ext4是ext3的继任者也是目前Linux发行版中使用最广泛的文件系统之一。它的最大特点就是稳经过了十几年生产环境的千锤百炼该踩的坑基本都被人踩完了。ext4支持单个文件最大16TB文件系统最大1EB对绝大多数场景来说根本用不完。ext4还支持向后兼容旧的ext3、ext2分区可以直接升级到ext4而不用格式化数据这在老系统升级的场景里非常实用。它自带日志功能journal系统突然断电时能通过日志快速恢复避免文件系统损坏。我个人对ext4的评价是当你不确定用什么文件系统时用ext4准没错。它不像某些新文件系统那样花样多但胜在稳如老狗。Linux根分区我基本都用ext4简单可靠。2.2 XFS高并发大文件场景的冠军XFS诞生之初就是冲着高性能大文件去的。它采用动态inode分配机制inode按需分配不会预先占满空间因此在海量小文件场景和超大文件场景下表现都很优秀。RHEL、CentOS从7开始把XFS设置为默认文件系统这本身就说明了它在企业级场景中的地位。XFS的优势主要体现在几个方面一是支持超大文件理论上单个文件最大可以到8EB二是高并发写入表现强劲适合数据库、视频处理这类有大量并发I/O的业务三是元数据操作性能好创建和删除大目录下的文件时优势明显。但XFS有一个坑很多人不知道它可以在线扩大但不能在线缩小。所以如果你预期这个分区以后可能缩容量趁早别用XFS。此外XFS分区如果容量不够扩容需要配套的xfs_growfs命令来扩展文件系统直接改分区大小后不执行这步系统是识别不了新增空间的。2.3 Btrfs快照和压缩的闭关高手有坑Btrfs给人的第一印象是“什么都能干”支持写时复制CoW、快照、子卷、数据压缩、自校验、跨设备存储池。听起来像是文件系统领域的瑞士军刀实际用起来也确实能实现很多骚操作。快照功能是和传统文件系统最大的区别。比如你升级系统前给根分区打个快照升级出问题了直接回滚这种便利性是ext4和XFS给不了的。子卷则允许你在一个文件系统内划分出多个独立空间进行独立的配额管理。但Btrfs也不是没有代价。它的性能在长时间运行后可能出现碎片化问题早期版本的稳定性也闹过不少幺蛾子虽然现在好多了但生产环境用它依然需要谨慎。我个人的建议是如果你喜欢折腾、需要快照功能Btrfs可以作为个人机器或测试环境的文件系统但线上核心业务还是成熟稳重的ext4或XFS更靠谱。2.4 ZFS存储级文件系统资源大户ZFS严格来说不只是文件系统它把卷管理器和文件系统合二为一了可以直接管理多块物理磁盘组成存储池在池上再创建文件系统。它提供了RAID-Z、数据校验和修复、高效快照、远程复制send/receive等硬核功能数据和安全性保障能力是所有文件系统里最强的。但ZFS对资源的要求也很高特别是内存。有一个说法是给ZFS配一台机器内存多多益善因为ZFS会用ARC缓存来加速读取。内存不足时ZFS的性能会大打折扣甚至出现诡异问题。另外由于许可证原因ZFS没有直接内置在主流Linux内核主线里通常需要借助第三方存储库安装这一点也挡住了不少普通用户。如果你打算搭建一台家用NAS或者备份服务器又有足够的物理内存ZFS是非常值得投入时间去研究的选择。但对新手而言一上来就用ZFS很容易被各种概念劝退。2.5 选型速查表一张图记完核心区别文件系统最大文件最大卷快照压缩在线扩容在线缩容最适合场景ext416TB1EB不支持不支持支持支持根分区、通用场景XFS8EB8EB不支持不支持支持不支持大文件/高并发写、数据库数据目录Btrfs16EB16EB支持支持支持支持个人机器、试验环境、需要快照ZFS16EB256PB支持支持支持支持NAS、备份存储、追求极致数据安全选择的核心逻辑就三条追求稳定选ext4追求并发性能选XFS追求快照和高级功能选Btrfs或ZFS。没有哪个是绝对“最好”的只有最合适你场景的。3. 分区实操从fdisk到parted完整跑一遍理论说了一堆现在上手实操。下面这套流程是按照一台新服务器加了一块空数据盘的场景来设计的包含了从查看磁盘、创建分区、格式化到挂载上线的完整操作。3.1 动手前先看清磁盘lsblk与fdisk -l对磁盘做任何操作之前先确认你将要操作的是哪块磁盘这是运维的第一铁律。在机房或者云平台管理后台里把新磁盘挂上之后服务器里未必能看到它需要先刷新一下或用lsblk确认。lsblk这个命令会以树状结构展示所有磁盘和分区输出类似NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 100G 0 disk ├─sda1 8:1 0 1G 0 part /boot └─sda2 8:2 0 99G 0 part / sdb 8:16 0 500G 0 disksda是系统盘sdb就是新加的空数据盘。如果新磁盘没出现可以用partprobe刷新分区表或确认磁盘是否已被底层识别。这里要特别提醒后续所有操作都只针对sdb一旦在命令里把sda当成sdb操作系统盘被格式化那个画面太美我不敢看。3.2 fdisk经典MBR分区流程对新磁盘如果容量小于2TB用fdisk就够了。输入命令进入交互界面fdisk /dev/sdb按n新建分区选择p创建主分区分区号一般默认1起始扇区默认回车的2048这个默认值已经做了4K对齐优化千万不要改成别的数字。最后指定分区大小可以写成100G表示100GB或者直接回车用完整剩余空间。全部操作完成后按w写入分区表并退出。整个过程交互提示比较友好每步都有中文提示或英文解释。还有一点要说明2048扇区起始位置对齐4K物理扇区是现代硬盘性能的关键老式硬盘默认从63扇区开始性能损耗巨大现在的fdisk已经默认解决了这个问题但用其他工具分区时仍然要注意对齐。分区创建完成后Linux内核未必立即识别新分区需要执行partprobe /dev/sdb刷新分区表。这一步很关键有些人弄完fdisk直接格式化提示找不到分区就是因为没刷新。3.3 parted创建GPT分区需要操作超过2TB的大磁盘时fdisk默认的MBR格式不够用得用parted来创建GPT分区表。parted的命令风格和fdisk不同更接近命令行的参数式操作。parted /dev/sdb mklabel gpt mkpart data 0% 100% quit第一行进入parted交互界面mklabel gpt把磁盘分区表格式化为GPTmkpart创建分区。这里的data是分区名0% 100%表示从磁盘开头一直分到结尾也可以写成更精确的区间。对于大磁盘我更推荐用百分比而不是绝对大小因为不同容量的磁盘百分比计算出的具体扇区数由parted自动换算更不容易出错。分区创建完成后用align-check检查一下对齐情况align-check optimal 1返回1 aligned就说明对齐没问题。parted也可以直接看分区表整体情况输入print即可。3.4 格式化与临时挂载分区创建好之后要给分区装文件系统。格式化命令根据文件系统类型来定mkfs.ext4 /dev/sdb1或mkfs.xfs /dev/sdb1格式化过程中终端会输出一些文件系统特征信息。这里提供一个通行的小技巧ext4默认会为root用户保留5%的空间数据盘其实没必要留这么多格式化时可以用-m 0把保留比例设为0把空间全部释放出来mkfs.ext4 -m 0 /dev/sdb1格式化完成后先临时挂载验证文件系统正常mkdir /data mount /dev/sdb1 /data df -h看到/dev/sdb1已经挂载到/data说明分区和文件系统本身没有问题了。3.5 写入fstab实现开机自动挂载临时挂载在重启后就失效了。要实现开机自动挂载需要把条目写入/etc/fstab。这里建议不要直接写/dev/sdb1这样的设备名而要用UUID因为设备名可能因为系统启动顺序变化而改变。先获取UUIDblkid /dev/sdb1输出类似/dev/sdb1: UUID3d4a0e6f-... TYPEext4然后编辑/etc/fstab在末尾追加一行UUID3d4a0e6f-... /data ext4 defaults 0 0保存后执行mount -a这条命令会根据fstab把未挂载的分区全部挂载上。凡是修改了fstab一定要用mount -a测试一遍确认无误再重启否则写错一行可能导致系统起不来。4. 挂载管理与LVM给分区加上“弹性”分区和文件系统搞定后挂载这件事本身也值得深挖。特别是当磁盘空间不够用时如果你当初留了一手LVM扩容只是几行命令的事如果没用LVM就得停机加盘搬数据完全是另一个量级的痛苦。4.1 挂载原理与fstab字段解析挂载的本质是把一个文件系统关联到某个目录上让用户通过这个目录访问文件系统里的内容。Linux下所有东西都是文件磁盘设备也不例外挂载就是把/dev/sdb1这个“设备文件”和/data这个目录关联起来。mount命令的完整格式是mount [选项] 设备 挂载点常用选项包括-t指定文件系统类型-o指定挂载选项。比如要用只读方式挂载一个分区做数据恢复可以这样mount -t ext4 -o ro /dev/sdb1 /mnt/recovery而/etc/fstab里每一行有6个字段分别代表设备、挂载点、文件系统类型、挂载选项、dump备份标记、fsck检查顺序。第4个字段最常用的是defaults它实际包含了rw、suid、dev、exec、auto等默认选项。给数据盘加noatime是一个很好的优化可以避免每次读取文件都更新访问时间减少无谓I/OUUID3d4a0e6f-... /data ext4 defaults,noatime 0 0第5个字段0表示不参与dump备份第6个字段0表示开机时不检查该文件系统根分区一般设置为1其他分区设置2或0。4.2 用UUID替代设备名的原因与坑为什么一直强调用UUID而不是/dev/sda这种设备名原因很简单设备名是不稳定的。服务器插拔硬盘、系统内核识别顺序改变、bios磁盘顺序调整都可能导致原本的sdb变成sdc。但UUID是文件系统创建时生成的唯一标识只要分区不被重新格式化它就永远不变。还有更隐蔽的问题一块新磁盘插入系统后可能会导致原来各磁盘的设备名整体漂移配置了设备名的fstab里那些挂载点会全部乱套。而用UUID就完全不存在这个问题。所以在生产环境所有涉及持久化挂载的配置都应该用UUID。如果fstab写错了导致系统无法启动进入救援模式后用mount -o remount,rw /把根分区重新挂载为读写然后修改fstab把错误行注释掉再重启就能恢复。4.3 LVM逻辑卷今天的不够用明天再扩LVMLogical Volume Manager是Linux下的逻辑卷管理机制它把物理分区先汇集成一个“存储池”再从池中划出逻辑卷供系统使用。这样做的好处是逻辑卷的大小可以随时扩大而无需关心底层物理磁盘有没有剩余空间。我实际操作的LVM流程大致如下。以整块磁盘sdc为例先在物理卷层面建立PVpvcreate /dev/sdc然后创建卷组VGvgcreate vg_data /dev/sdc再从卷组中划分逻辑卷LV比如创建一个200GB的逻辑卷lvcreate -L 200G -n lv_data vg_data之后对逻辑卷格式化并挂载和普通分区没区别mkfs.ext4 /dev/vg_data/lv_data mount /dev/vg_data/lv_data /data将来空间不够了如果卷组里还有剩余空间直接在线扩容lvextend -L 50G /dev/vg_data/lv_data resize2fs /dev/vg_data/lv_data如果是XFS文件系统最后一步换成xfs_growfs /data。整个过程业务无感这个能力在生产环境里太重要了。LVM还支持快照在做批量变更前给逻辑卷打一个快照出错就能快速回滚。快照本身是写时复制技术创建瞬间几乎不占空间随着原卷数据变化才逐渐增长lvcreate -L 10G -s -n lv_data_snap /dev/vg_data/lv_data如果变更出问题可以直接从快照恢复。恢复时需要先卸载逻辑卷再用快照覆盖原逻辑卷操作要谨慎建议在测试环境演练熟再上生产。5. 常见问题与排查技巧实录这部分都是我在实际运维中碰到、并且花过不少时间排查解决的问题。每一条都有血泪教训市面上普通教程不会写这么细。5.1 df和du对不上磁盘满了却找不到大文件现象df -h显示根分区使用率100%但用du扫描整个根目录加起来却远小于df显示的占用。原因大概率是有文件被进程删除但文件句柄仍被某进程持有空间没有被真正释放。这时用lsof找出还在占用已删除文件的进程lsof L1输出中的deleted状态就是已删除但仍被占用的文件。找到PID后重启对应服务空间立刻释放。这是典型的日志文件被删除但写日志的进程没重启的情况。排查思路要坚定先看谁打开了已删除文件而不是反复纠结文件去哪了。5.2 inode耗尽明明有空间就是写不进文件这个更隐蔽。df -h显示还剩几十GB但创建文件时提示No space left on device。用df -i一看inode使用率已经100%。inode是文件系统记录文件元数据的结构被大量小文件塞满时即使数据块还有空间也无法再创建新文件。临时解决方案是找出哪个目录文件数量爆表清理或归档旧文件。终极解决方案是当初给inode留够余量。ext4格式化时可以通过-i参数或-N参数指定inode数量但更省心的方案是预计会有海量小文件的业务直接用XFS它的inode按需动态分配不存在inode耗尽问题。5.3 文件系统变成只读怎么让它恢复运行中突然发现所有写操作报只读文件系统错误这往往是I/O错误触发内核把文件系统切成了只读保护状态。先用dmesg看看内核日志确认是否出现blk_update_request、I/O error之类的字样。如果是硬件故障先处理硬件如果是文件系统受损导致读写出错可以尝试卸载分区后执行fsck修复umount /data fsck -y /dev/sdb1修复完成后重新挂载即可。如果损坏严重无法修复只能放弃数据或从备份恢复。生产环境数据无价这条提醒多说几次都不够重要数据一定要有备份。5.4 性能排查io占用高的元凶系统整体变慢使用率忽高忽低优先怀疑磁盘I/O瓶颈。iostat -x 1可以实时查看各磁盘的读写速率、I/O等待、利用率。如果%util长期接近100%基本可以断定磁盘带宽跑满了。再用iotop找出具体是哪个进程在大量读写磁盘对症下药。另外还有一些日常层面的优化手段数据盘挂载时加noatime减少无谓访问时间更新日志文件放在单独分区避免相互干扰定期做文件系统碎片整理ext4用e4defragXFS用xfs_fsrBtrfs用btrfs filesystem defrag。不过现代文件系统碎片对性能影响有限实际效果因场景而异不用过分焦虑。5.5 重启起不来fstab坑最后的保命手段这个场景我遇到不止一次修改fstab后没测试就重启结果系统卡在启动阶段的挂载步骤。此时只能进救援模式处理。流程一般是用启动介质引导系统进入rescue模式执行mount -o remount,rw /把根分区重新挂载为可写然后编辑fstab把新增的、导致问题的行注释掉或修正重启即可。为避免这种事故一条原则必须遵守凡是修改了fstab重启前必须执行mount -a验证。另外还可以在fstab里给非关键数据分区加上nofail选项这样分区挂了不影响系统正常启动UUID3d4a0e6f-... /data ext4 defaults,noatime,nofail 0 0如果把nofail成为一种习惯重启起不来的事故大概率和你无缘。我自己这些年在分区和文件系统上栽过的跟头总结起来其实就一句话不要图省事跳过规划和验证。分区的边界划清楚文件系统按业务场景选挂载配置写之前想明白写之后测一遍。用LVM给未来留好扩容余地用UUID避免设备名漂移的坑重要数据随时备份。这套思路让我的服务器在绝大多数情况下都能安稳运行偶尔出点问题也能在几分钟内定位解决。新装一台机器时多花半小时处理这些基础工作比深夜被报警电话叫醒处理事故要值太多了。