自学Linux到第十二天说实话已经过了最劝退的阶段了。前两周基本是把Linux当“另一个操作系统”去适应到了第十二天我开始觉得自己像个“管理员”了因为今天接触的东西是真正决定一台Linux服务器能不能稳定跑业务的核心环节——磁盘与文件系统。这篇文章不聊太虚的概念就讲我今天在闲置笔记本上从零做磁盘分区、格式化、挂载、以及模拟了一次“磁盘故障”排查的全过程。里面有几个坑是我自己踩的花了不少时间才绕出来写下来给和我一样靠自学硬啃Linux的人做个参考。1. 为什么第十二天要死磕磁盘管理基础命令之后的第一道分水岭1.1 前十一天的进度回顾之前十一天我基本完成了这些内容Linux目录结构、文件与目录操作ls、cd、cp、mv、rm、find、文本处理三件套grep、sed、awk、用户与权限管理useradd、chmod、chown、su、sudo、进程管理ps、top、kill、网络基础排查ping、curl、ss、tcpdump、以及包管理器的日常使用。看起来覆盖得挺广但真要我独立部署一个服务比如搭个Nginx或者装个数据库我心里是没底的。原因很简单我所有的操作都停留在“使用别人已经准备好的资源”这个层面一旦涉及给系统加一块新硬盘、重新调整分区、修复一个因为空间不足挂掉的目录我完全不知道从哪下手。第十二天选磁盘与文件系统就是为了补上这个短板。磁盘管理在Linux知识体系里的位置很特殊。它不像vim那样属于“纯操作技能”也不像网络协议那样偏理论。它更像是地基工程——你上面跑的软件再花哨只要底层磁盘划分不合理、挂载逻辑混乱、空间用尽不预警系统随时会以最难看的姿势挂掉。而且磁盘管理的命令lsblk、fdisk、mkfs、mount、df彼此串联性极强学的时候能同时复习到设备文件、内核设备驱动、开机启动流程、文本解析等多块知识性价比很高。1.2 学习实验环境与重要提醒我这次用的是一台闲置的旧笔记本配置很低但用来折腾Linux正合适。系统是某个主流发行版的最小化安装版内核版本比较新磁盘是一块120GB的SATA固态。为了做实验我把原来的系统压缩了空间腾出一块未分配的磁盘区域专门用来练习。正式分区之前我先把所有重要数据备份到了另一块移动硬盘上。这里必须多说一句磁盘管理实验千万不能在存有重要数据的机器上直接操作分区表和文件系统不像普通文件误操作之后几乎没有恢复的可能性。如果你也想跟着练手最靠谱的方式是虚拟机里挂一块单独的虚拟磁盘或者找一台完全不用的旧电脑。我见过有人在公司的开发机上直接执行了错误的分区命令结果整个部门共享目录消失的惨案后续花了一整天找回滚备份这个教训不值得再验证一遍。另外还有一点容易被忽略尽量选用较新版本的系统镜像。老版本系统对新硬盘、新分区表类型的支持不完善实验中会出现一些因为工具链太旧产生的兼容性问题这些报错信息容易把新手带偏让你以为是自己的操作有问题。1.3 实验目标清单在动手之前我先列了一个本次实验的目标清单学会用lsblk和df -h看清当前系统的磁盘结构使用fdisk对一块空白磁盘完成分区含主分区、扩展分区和逻辑分区的区别验证用mkfs系列命令格式化成指定文件系统并对比ext4与xfs的适用场景掌握临时挂载和永久挂载/etc/fstab的方法与注意事项模拟一次“分区无法挂载”的故障完整走一遍排查链路。这个清单基本是服务器管理员日常维护磁盘的完整闭环。走完一遍之后我对后面学习LVM逻辑卷管理、RAID磁盘阵列、磁盘配额这些进阶内容就有了实际抓手不会只是在概念里打转。2. 磁盘管理的核心心法从设备文件到分区表的完整认知链2.1 一切从“一切皆文件”说起Linux哲学里最核心的一句话是“一切皆文件”。磁盘这个硬件在系统里同样以文件的形式暴露这类文件集中在/dev目录下。SATA接口的硬盘一般命名为sda、sdb这种NVMe固态则是nvme0n1、nvme1n1这种字母和数字分别代表磁盘序号和分区号。比如/dev/sda1就是第一块硬盘的第一个分区。我刚开始学的时候对着一堆设备文件名完全摸不着头脑后来找到了一个记忆方法设备命名就是“接口类型物理序号分区序号”的拼接。物理次序不是固定不变的它还取决于主板上的接口顺序和系统识别顺序所以在实验环境里加了第二块硬盘之后它可能显示为sdb但如果换一个接口位置重启名字可能变成sdc。这也是为什么生产环境里挂载磁盘更推荐用UUID文件系统的唯一标识符而不是设备名具体的后面讲fstab时细说。查看当前系统磁盘结构最常用的命令是lsblk它会以树状结构输出磁盘和分区的对应关系。下面是我本次实验的原始输出$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 119.2G 0 disk ├─sda1 8:1 0 500M 0 part /boot ├─sda2 8:2 0 117.7G 0 part / └─sda3 8:3 0 1G 0 part [SWAP] sdb 8:16 0 20G 0 disksda是原来系统的系统盘已经分配好了三个分区sdb是我添加的新空白盘此时还没有任何分区所以下面没有子项也没有挂载点。lsblk输出的关键信息就这么几列设备名、主次设备号、是否可移动、容量、是否为只读、类型disk/part和当前挂载点。2.2 分区表类型MBR与GPT的现代选择分区表的本质是磁盘的目录页记录磁盘上有哪些分区、每个分区从哪里开始到哪里结束。目前主流的分区表有两种MBR和GPT。MBR是上个世纪八十年代的产物最多支持4个主分区单分区容量上限约2TB在现代大容量硬盘面前明显力不从心。GPT作为替代方案支持128个分区、单个分区容量基本没有实际限制并且自带冗余分区表头和数据校验可靠性高很多。新磁盘建议一律使用GPT分区表。只有极老的主板或特殊引导需求才需要MBR。本次实验使用的fdisk工具默认操作逻辑已经适配了GPT不需要额外设置。顺带说一句如果用的是老工具parted创建分区表时记得显式执行mklabel gpt否则默认可能是msdos即MBR。2.3 文件系统磁盘上的图书管理系统分区完成后磁盘还是一个“什么都没有的空白院子”文件系统就是在这个院子里建图书管理系统的过程我们平时说的“格式化”就是这个动作。Linux里最常用的两种文件系统是ext4和xfs我这次特意都实践了一遍。ext4是目前Linux发行版兼容性最广的文件系统几乎任何发行版都能读取特性稳定支持在线扩容、日志恢复当你不确定选什么的时候ext4是最不容易出错的选择。xfs的特点是处理大文件和大容量场景下性能出色被称为“大型文件系统”但xfs不支持缩容——分区建大了就建大了想缩小只能重新格式化。如果你的业务涉及海量小文件比如消息队列的积压数据xfs的小文件吞吐表现也要配合具体场景测试。另外还有一个必须掌握的底层概念是inode。inode是文件系统管理文件的元数据结构记录了文件的权限、属主、大小、时间戳以及数据块的指针。在格式化的时候文件系统会分配固定数量的inode这个数量决定了整个分区最多能存放多少文件。有时候磁盘明明还有大量剩余空间却无法创建新文件报“No space left on device”大概率就是inode耗尽了。检查方法是用df -i查看inode使用率。3. 动手实测用fdisk完成分区、格式化和挂载的完整过程3.1 开始分区前的安全检查正式对/dev/sdb做分区之前我做了两步确认第一步用lsblk再次确认识别到的设备名防止把系统盘误当成新盘第二步用df -h查看当前所有已挂载的文件系统确保没有任何生产目录挂载在目标设备上。还有一个细节确认新磁盘没有存放在用的数据。我这块12磁盘是从旧机器上拆下来的里面有一些藏得很深的旧分区残留lsblk阶段看起来是空盘但其实只是分区表坏了某些文件系统工具扫到残留元数据会报警。稳妥起见我执行了一次wipefs -af /dev/sdb这个命令会擦除磁盘上的文件系统签名、分区表签名等所有魔术数字相当于把院子推平重来。注意这是一条非常危险的操作绝对不能对正在使用的系统盘执行。3.2 fdisk交互式分区操作全记录执行sudo fdisk /dev/sdb进入交互式界面。fdisk的操作方式是通过单字母命令完成初见时有点反直觉但记住下面这几个核心指令就够用了n新建分区p打印当前分区表d删除分区t修改分区类型w保存退出q不保存退出。我按照规划创建一个GPT分区表然后新建一个20GB的主分区。过程中的关键交互如下Command (m for help): n Partition number (1-128, default 1): First sector (2048-41943039, default 2048): Last sector, /-sectors or /-size{K,M,G,T,P} (2048-41943039, default 41943039): 15G Created a new partition 1 of type Linux filesystem第一个扇区直接回车使用默认值2048可以保证分区对齐到现代存储的最佳访问边界容量输入15G表示创建15GB大小的分区fdisk会自行计算出结束扇区。接着我按同样的方式把剩余空间划成第二个分区约5GB。最后输入p打印分区表确认无误再输入w保存退出。退出后立刻用partprobe或重启让内核重新读取分区表然后检查lsblk此时应当能看到sdb1和sdb2两个分区。如果没出现可能是这个发行版的内核没有自动刷新分区表重跑一遍partprobe /dev/sdb基本都能解决。3.3 格式化为ext4和xfs并分别挂载分区只是划分区域格式化才是真正“创造文件系统”的动作。我把第一个15GB分区格式化为ext4第二个5GB分区格式化为xfssudo mkfs.ext4 /dev/sdb1 sudo mkfs.xfs /dev/sdb2mkfs.ext4执行时会输出一堆创建文件系统时的参数摘要包括块大小block size、inode数量、块组数量等。新手可以不用急着深究每个参数但有两点值得建立常识块大小通常默认4096字节适合大多数业务场景inode数量远大于默认的文件数量需求一般不需要手动干预。格式化完成后需要创建两个挂载点目录分别是/mnt/data和/mnt/log然后执行挂载sudo mkdir -p /mnt/data /mnt/log sudo mount /dev/sdb1 /mnt/data sudo mount /dev/sdb2 /mnt/log sudo df -hTdf -hT的T参数会额外显示文件系统类型输出里新增了两行/dev/sdb1和/dev/sdb2分别出现在对应的挂载点下容量显示为15G和5G。到这里我最开始验证“日常操作文件”的目标就完成了在/mnt/data下新建任意文件后数据其实已经落到新磁盘的ext4文件系统中了。3.4 开机自动挂载fstab的正确姿势与致命细节临时挂载只能管到当前开机状态重启之后挂载关系会全部消失。要让系统每次开机自动挂载需要修改/etc/fstab文件。fstab里每一行描述一个挂载关系共六个字段设备标识、挂载点、文件系统类型、挂载选项、dump备份标志、fsck检查顺序。这里最大的坑是设备标识。很多人想当然地写/dev/sdb1这种设备路径但设备名会随硬件识别顺序变化重启后可能就变成别的名字导致系统启动失败。可靠的方案是用UUID获取方式如下sudo blkid /dev/sdb1 /dev/sdb2输出结果类似UUID8a9d... TYPEext4把这段UUID复制到fstab里。我最后写入的内容是UUID8a9d... /mnt/data ext4 defaults 0 2 UUIDb7c3... /mnt/log xfs defaults 0 0关于最后一个字段ext4分区建议填2表示系统启动时用fsck检查该文件系统xfs建议填0因为xfs的元数据一致性校验是在挂载时自动进行的不需要启动期的fsck扫描。/根分区通常填1其余非根分区填2或0。这个字段乱填的后果是每次开机都多等几十秒甚至更久。改完fstab之后有个必须执行的验证步骤sudo findmnt --verify --verbose这个命令会逐行检查fstab语法和挂载点的可达性。如果输出没有报错再执行sudo mount -a让系统立即按fstab重新挂载所有条目确认无报错后重启验证。千万不要在没验证的情况下直接重启一旦fstab里有错误系统会尝试挂载失败导致进入紧急模式对新手处理起来很麻烦。4. 一晚上的故障排查我在挂载过程中踩到的三个坑4.1 第一个坑df能看到挂载点但写入报“Read-only file system”这个坑出现得很有趣。我完成挂载、往/mnt/data写了个测试文件之后一切正常。可当我再次尝试写入时系统突然报错“Read-only file system”。用df -hT /mnt/data查看挂载点还在文件系统显示为ext4也没有显示ro。排查这一步我纠结了很久。后来用mount | grep /mnt/data看详细信息发现挂载参数里出现了ro字样。这个现象说明文件系统被内核以只读方式挂载了通常是文件系统检测到了某些异常内核为了自我保护强制切换成只读模式。再往下排查dmesg | tail -n 50里看到有多条与/dev/sdb1相关的I/O错误集中在“Buffer I/O error on device”。这才想起来我这块旧笔记本的SATA接口有一个接触不良的隐患之前就偶尔出现磁盘掉盘。检查物理连接后重新插紧数据线和电源线重启机器再挂载一次故障消失。这个坑给我的经验是遇到“只读文件系统”先不要怀疑权限设置先查dmesg的系统日志看底层设备有没有报I/O错误。很多时候问题不在文件系统层而在物理链路层。4.2 第二个坑fstab写错一行开机直接进入emergency mode理论上经过findmnt --verify验证之后不应该再出问题但我还是踩了雷。原因是我手动修改fstab时把第二行的UUID复制错了少了一个字符人工根本没看出来。findmnt --verify那次验证是通过了但实际挂载时因为UUID不匹配分区挂载不上重启后系统直接进入了emergency模式。进入emergency模式后屏幕提示“Cannot open access the console, the root account is locked”之类的信息输入root密码也没用。处理方法是用mount -o remount,rw /把根文件系统重新以读写方式挂载然后立刻查看fstab把错误的UUID改成正确的再执行findmnt --verify和mount -a最后重启。这里推荐一个更保守的做法在那种系统刚能进启动菜单的情况下选择内核的高级选项进入带网络的单用户模式。单用户模式里网络和多数服务都不启动但根文件系统默认已经以读写方式挂载可以直接改fstab。如果手头有系统安装U盘也能用镜像自带的救援模式挂载根分区后修复两条路都能走通选哪条看哪个对你更顺手。4.3 第三个坑mkfs.xfs在非交互终端里报“cannot open the device”我是在SSH会话里执行格式化命令的结果是mkfs.xfs抛出一长串错误信息大意是无法打开设备。排查后发现问题是这样一个细节部分工具要求设备不能被系统其他进程占用而我当时刚好有一个终端会话的当前工作目录位于/mnt/data挂载点虽然还没挂上但目录句柄残留导致设备忙。解决方法很简单切换到一个与目标设备完全无关的目录比如/root再执行格式化就通过。在SELinux或AppArmor开启的发行版上这条报错还有可能是设备上下文策略拦截不过那个概率较低。如果以后执行分区/格式化时报“Device or resource busy”第一反应就是用lsof或fuser查看哪些进程正在占用该设备或挂载点。5. 磁盘维护的日常操作空间监控、inode排查与性能观察5.1 空间告急不再是猜测df与du组合定位占用大户磁盘不是挂上就完事了真正考验操作习惯的是日常监控和故障前的预判。我每天都会执行一遍df -hT看整体使用率这条命令能同时看到文件系统类型、容量、已用、可用和挂载点一眼扫过去就能发现哪个分区接近红线。当某个分区使用率超过80%时就要进入排查阶段了。定位“是谁吃掉了空间”就是du的专长常用组合是sudo du -h --max-depth1 /mnt/data | sort -hr | head -20--max-depth1表示只统计一层目录输出每个一级子目录占用的空间大小然后按容量从大到小排序。这样从大到小逐层深入通常几轮就能锁定占空间最多的文件。我这次实验中发现一个隐藏很深的情况某个软件把日志写到了/mnt/log下但只保留了最近两周的文件周旋文件已经积累了数GB通过du一层层挖出来之后配合logrotate轮转策略就解决了。5.2 空间充足却写不进文件inode耗尽实战有一次我在/mnt/data下批量创建了十几万个测试小文件随后再创建文件就报No space left on device。但df -h明明显示还有好几个GB的可用空间。这时就需要df -i看一下inode使用率$ df -i /mnt/data Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sdb1 1000000 999999 1 100% /mnt/data看到IUse%显示100%问题立刻明确了——不是空间不够而是这个文件系统预分配的inode被用完了。ext4在格式化时会按容量和预期文件数量预留inode数量小文件海量写入会把inode迅速耗尽。解决办法常规来说是重新调整格式化参数比如增加inode占比重新格式化分区或者删除一些不再需要的小文件释放inode如果分区是LVM且文件系统支持扩容还能在线增加文件系统大小来扩充inode池。这个经历给我的教训是如果业务会产生海量小文件最好在设计之初就规划合适的文件系统类型和inode比例或者尽量使用支持动态inode分配的文件系统。亡羊补牢虽然可行但数据迁移的成本不低。5.3 一秒定位性能瓶颈iostat与iotop的使用时机磁盘性能排查比空间排查更隐蔽因为系统卡顿的原因可能是CPU也可能是磁盘。我用的工具是iostat和iotop前者看全局后者看进程级明细。iostat -x 1会每秒输出一次磁盘扩展统计重点看%util磁盘繁忙度和await平均I/O等待时间。%util到90%以上说明磁盘基本处于饱和状态await如果经常超过100毫秒大概率是机械盘寻道延迟过高或者有大量小文件随机读写。iotop则能实时显示每个进程的磁盘读写速率当系统突然变卡时多数原因是某个进程正在疯狂读写磁盘用iotop一眼就能把它抓出来。我在实验过程中曾启动一个数据库实例%util长期维持在85%左右用isotop查到是垃圾回收线程频繁刷盘导致之后通过调整数据库的批量提交参数解决了。磁盘问题的定位思路和网络、CPU其实是一样的先用观察命令缩小范围再去针对性地调参数。6. 第十二天复盘这段时间的学习法、笔记法以及避开的坑6.1 为什么用“最小可闭环”的方式推着学回头看这十二天我最大的体会不是哪个命令记牢了而是摸索出了一套比较适合自己的自学节奏。Linux的知识点之间关联性强、层级深如果单纯按命令表背背一百个命令在真实问题面前还是无从下手。我现在的做法是每个阶段定一个“最小可闭环”的目标围绕这个目标串联相关命令。比如第十二天这个闭环就是“新磁盘发现-分区-格式化-挂载-开机自动挂载-故障排查”。为了完成这个闭环我需要用到lsblk、fdisk、mkfs、mount、blkid、fstab、df、du、dmesg这一整套命令它们不是孤立的而是被一条完整的故事线串在了一起。闭环完成之后这些命令才真正内化成了我自己的东西而不是背下来的知识碎片。6.2 我如何整理命令手册不追求大而全只记录“判断逻辑”现在网上各种Linux命令大全很多但我发现原样抄下来一点用都没有因为没有上下文的命令清单在关键时刻根本调不出来。我的笔记方式分三栏症状、排查命令、判定逻辑。比如“磁盘可用空间满”这一条我会记录先用df -h确认挂载点使用率再用du逐层定位大文件最后考虑是否要清理日志或扩容。这样记下来的不是孤立的命令而是面对一个具体问题时的决策路径。另一个习惯是给容易混淆的命令做对比表。比如df和du的区别我看过很多遍但真正会混用。现在笔记里专门有一块写df统计的是文件系统层面的块使用情况du统计的是目录树的文件实际占用。前者更接近底层块设备的空间状态后者更接近用户“我有哪些文件夹占了多大”的认知。这种区分一旦用笔记写清楚后面排查时就不会出错。6.3 未来十天的大致规划LVM、RAID、配额与自动化第十二天把磁盘的地基打完接下来的方向我也有了初步规划。第十三到第十五天我打算专门学LVM逻辑卷管理把物理卷、卷组、逻辑卷、快照这些概念从头捋一遍目标是实现“在线扩容”和“在线缩容”的完整实验。第十六天到第十七天研究软件RAID重点理解RAID0/1/5/10在冗余和性能上的取舍以及mdadm的日常管理命令。第十八天到第十九天做磁盘配额quota和日志轮转logrotate的实验这两个功能在生产环境里几乎是标配。第二十天开始尝试编写Shell脚本把磁盘监控、日志清理这些日常工作自动化算是从“手动管理员”往“自动化管理员”方向迈一步。这次的磁盘实验让我对Linux的信任感增加了很多当你理解了设备的命名方式、分区的组织逻辑、挂载的配置文件之后系统启动过程中那些看似神秘的环节变得透明了。哪怕以后遇到更复杂的存储架构只要底层这块基石是坚实的就有底气一层层往上查。下一步的实验我准备换个更硬核的主题把LVM和RAID组合在一起模拟一次“数据盘满了但业务不能停”的紧急扩容场景到时候再回来分享。