1. 从一块裸盘开始的困惑分区到底在分什么我得先坦白一件事刚接触 Linux 那会儿我对着fdisk的输出看了半天完全搞不懂分区表、文件系统、挂载点这三者之间到底是什么关系。当时网上教程写得都很直给——让你敲一串命令然后告诉你这样就分好了。但没人解释为什么分完区还要格式化为什么格式化完还要mount为什么有时候重启机器之后挂载又没了。这套东西如果你只是照着敲也不会出太大问题毕竟命令就那么几条。但只要你工作环境里出现一些稍微刁钻的磁盘场景——比如给服务器新加一块数据盘、把一块带数据的旧盘接到新机器上、或者想给系统盘扩容——你就会发现不懂原理的人连看日志都看不明白更别说下手操作了。这篇文章就是把我在生产环境里反复折腾过的东西整理出来从分区表的逻辑讲起到实际的下盘、格式化、挂载、排错再到几个我踩过的大坑尽量用大白话把整个链路讲透。先建立最基础的概念框架。你可以把一块物理硬盘理解为一块空白的大黑板分区就是在黑板上画出几个互不相干的格子。每个格子是一个分区操作系统会把它们看成独立的存储空间。分区表就是记录这些格子边界的第一张图纸——MBR是老的图纸标准GPT是新的。分区完成之后你手里的是一块块什么都没有的空白空间这时候还需要在每个分区上建立文件系统也就是常说的格式化。文件系统决定了数据以什么结构存放在这个分区里——ext4、xfs、btrfs都是不同的收纳方式。格式化完成后分区才真正可以被系统读写。最后一步是把格式化好的分区贴到某个目录上让用户可以通过这个目录访问它这就是挂载也就是mount。所以完整链路是物理盘 → 分区 → 格式化建立文件系统→ 挂载。任何一环搞混了后面都会出幺蛾子。我见过不少人把分区和格式化混为一谈其实它们是两个完全不同的步骤对应的工具也不同。理解了这条链路下面所有讨论才有地基。2. 分区表选型MBR、GPT和它们的分区数上限分区管理第一步要做的不是敲命令而是确定用哪种分区表格式。这个选择在《Linux硬盘分区管理》这类主题里经常被一笔带过但它恰恰是后面很多麻烦的根源。MBR全称Master Boot Record诞生于1980年代。它和硬盘的第一个扇区绑定在一起前446字节存放引导程序后面用64字节记录最多4个主分区的信息。这4个主分区的硬限制决定了它的天花板如果你需要多于4个分区就得把其中一个主分区改成扩展分区再在扩展分区里面继续切逻辑分区。逻辑分区在旧系统里最多可以划出很多个但扩展分区本身只能有一个而且操作起来绕来绕去非常不直观。更大的问题是容量限制。MBR的分区表项用32位来记录扇区地址单块磁盘最大只能管理2TB的容量单个分区也超不过2TB。在今天动辄4TB、8TB的数据盘面前这个限制几乎是灾难级的。我有一台老机器插了一块4TB硬盘当时的BIOS和系统都支持UEFI引导但因为默认用了MBR分区表系统只认出了2TB后面1.8TB的空间凭空消失。后来重新用GPT分区所有容量都找回来了。GPT全称GUID Partition Table是UEFI时代的标准。它的核心设计有几个特点单块磁盘和单个分区的容量上限达到了EB级别1EB等于1024PB对个人和企业用户来说基本等于没有上限。默认可以创建128个主分区没有扩展分区那一套复杂概念管理起来干净利落。GPT在磁盘的头部和尾部各存一份分区表副本一份损坏了还有另一份兜底抗风险能力比MBR强很多。GPT分区表本身带有CRC校验数据完整性检查比MBR更可靠。看到这里你可能会想那不废话吗肯定选GPT啊。但现实是你的选择不完全是自由的。它取决于两个前提条件主板固件和操作系统引导模式。如果是一台2012年之前的旧机器BIOS只支持传统Legacy启动那么即便磁盘超过2TBMBR还是更稳妥的选择。如果主板支持UEFI且开启了UEFI引导模式那GPT就是标准答案。另外Windows和Linux双系统共用的数据盘如果需要在老旧Windows版本比如Windows 7及更早上直接读取MBR兼容性更好。当然如果你是在Linux环境里全新规划一块数据盘我的建议很简单直接选GPT没有悬念。实操里怎么确认当前磁盘的分区表类型用lsblk或者parted都可以。lsblk看不到分区表类型得靠partedsudo parted /dev/sda print输出里Model、Disk那两行能告诉你磁盘型号和总容量Partition Table那一行会显示msdos或者gpt。msdos代表MBR。这个检查动作我建议养成习惯尤其在接手陌生服务器的时候先搞清楚盘上已经存在什么再动手比什么都重要。3. 分区工具怎么选fdisk、parted、gdisk的适用边界Linux下分区的命令行工具有好几个最常用的是fdisk、parted和gdisk。很多教程只拿其中一个演示导致你学了fdisk碰到一块GPT大容量盘就懵了或者你学了parted但命令风格跟fdisk完全不一样退回去用fdisk又觉得少了点什么。我在这儿把它们各自的定位和适用场景摊开讲清楚。fdisk是最传统、用户量最大的工具。老版本fdisk只认MBR新版本util-linux 2.23之后已经支持GPT了。它最大的优点是交互式操作适合人肉敲命令有完整的菜单提示按n新建分区、按d删除分区、按w保存退出、按q不保存退出。fdisk适合的场景是快速新建或者删除一两个分区、调整分区类型的标记、在MBR和GPT之间做常规操作。但fdisk有个让我很烦躁的短板它不支持非交互式批量操作。你想写个脚本自动分区fdisk基本帮不上忙你得用管道把一堆输入喂给fdisk可读性和稳定性都很差。这时候parted才是正确的选择。parted是GNU出品的工具设计目标就是脚本化和精确化。它支持MBR和GPT而且可以一边操作一边显示单位、容量和分区信息。parted的命令风格是直接传参数比如sudo parted /dev/sdb mklabel gpt sudo parted /dev/sdb mkpart primary ext4 1MiB 100%第一条命令把磁盘的分区表格式初始化为GPT第二条命令创建一个从1MiB到磁盘末尾的分区。注意这里没有交互过程一步一个命令非常适合写进自动化脚本。还有gdisk它是专门操作GPT分区表的工具交互界面和fdisk类似但功能全部围绕GPT特性展开。gdisk有两大杀手锏一是可以把损坏的MBR转换成GPT二是可以备份和恢复GPT分区表。后者的价值在灾难恢复场景里非常巨大后面我会专门讲。我的选型建议是这样如果是日常交互式管理喜欢菜单提示选fdisk如果是脚本化和自动化选parted如果磁盘已经是GPT或者你需要做分区表的备份恢复、MBR到GPT的迁移果断用gdisk。你不需要三个全会但至少要在实际干活之前把fdisk和parted其中之一练熟另一个会基本操作。这里还要提醒一句fdisk里按w保存后操作立即生效但parted里几乎每条命令都是立即生效没有保存确认这一步。所以用parted的时候手要稳删除分区这种危险操作没有反悔余地。4. 实战下盘给一台新服务器规划并创建完整分区下面进入正题我从一块全新的硬盘开始走一遍完整的分区、格式化、挂载流程。这个过程我一年要重复几十次很多细节是在踩坑中才慢慢摸出来的这里一并写出来。场景设定一台运行Ubuntu 22.04的服务器系统盘是/dev/sda新加了一块4TB的数据盘系统识别为/dev/sdb。目标是把这块盘分成两个分区一个2TB的分区用于日常业务数据另一个剩下的空间用于备份。两个分区都用xfs文件系统。第一步永远是确认磁盘状态。不要凭感觉猜设备名因为不同机器上设备名可能不同。用lsblk看一下lsblk输出会列出所有块设备新盘应该是没有挂载点、没有分区的裸设备通常出现在列表底部SIZE显示为4T。记得看TYPE列裸盘显示disk带分区的盘显示part。第二步是初始化分区表。因为我们要做GPT用parted直接上sudo parted /dev/sdb mklabel gpt执行完之后再跑一下sudo parted /dev/sdb print能看到Partition Table这一行变成了gpt。到这里磁盘的分区图纸就换成了新的格式但上面还没有任何实际分区。第三步是创建第一个分区。我用parted是因为它支持直接按大小创建不用进交互界面sudo parted /dev/sdb mkpart data xfs 1MiB 2000GiB这条命令的意思是创建一个名为data的分区这个名称在GPT里会记录方便识别文件系统类型标记为xfs起始位置1MiB结束位置2000GiB。起始位置选1MiB而不是0是为了对齐。现代硬盘和SSD都是用4K扇区分区从1MiB开始可以保证分区边界和物理扇区对齐避免IO性能下降。这个对齐问题在机械盘时代不明显但SSD上差距能到20%以上所以从第一块分区开始就必须养成对齐的习惯。如果机器内存足够大、磁盘速度也快这个分区瞬间就能建好。用lsblk验证lsblk /dev/sdb现在应该能看到sdb下面多了一个sdb1SIZE约2T。第四步是创建第二个分区。剩下约1.8TiB空间同样从1MiB对齐结束位置直接写100%让parted自己算到底sudo parted /dev/sdb mkpart backup xfs 2000GiB 100%创建完再lsblk看一眼两个分区就位sdb1和sdb2。容量一个2T一个约1.8T加起来正好等于整盘。分区创建完了但这两个分区还不能直接使用因为没有文件系统。第五步是格式化。我用xfs因为它在处理大文件和高并发IO时表现稳定而且xfs的grow操作非常方便后面会提到。格式化命令长这样sudo mkfs.xfs /dev/sdb1 sudo mkfs.xfs /dev/sdb2mkfs.xfs在大部分发行版里包含在xfsprogs包里如果没有这个命令先装一下sudo apt install xfsprogs # Debian/Ubuntu sudo yum install xfsprogs # CentOS/RHEL格式化的过程很快几秒钟就完事。格式化完再lsblk你会发现分区下面多了一个空挂载点这是因为系统会自动把新格式化的分区挂到/run/media/之类的临时目录下某些桌面环境会这样但服务器上通常不会自动挂载我们得手动挂载。第六步是挂载。先创建两个挂载点目录sudo mkdir -p /data /backup然后把分区挂上去sudo mount /dev/sdb1 /data sudo mount /dev/sdb2 /backup挂载完用df -h验证df -h /data /backup能看到两个分区分别显示2.0T和1.8T的容量使用率都是0%。到这一步整块盘已经可以用了业务数据写/data备份写/backup。你以为这就完了还远着。第七步才是让分区管理真正落地的关键——写入fstab实现开机自动挂载。如果不做这一步重启之后系统不会自动把这两个分区挂载上去你在/data、/backup里写的所有东西都会变成看不到但空间还在的状态这在生产环境里等于事故。fstab的全称是File Systems Table系统启动时会按照这个文件挂载所有文件系统。不要直接写设备名比如/dev/sdb1因为设备名在系统启动顺序变化时可能会变比如插了U盘、换了SATA口一旦变了fstab里写的设备就找不到了系统甚至会直接卡在启动界面等你处理。正确的做法是用UUID来标识分区UUID是文件系统创建时生成的一个全球唯一的字符串只要你不动分区这个UUID永远不变。获取UUID的方式很简单sudo blkid /dev/sdb1 /dev/sdb2输出里会显示UUIDxxxx-xxxx这样的字符串。把这串复制下来编辑/etc/fstabsudo nano /etc/fstab在文件末尾追加两行UUID你的sdb1的UUID /data xfs defaults 0 2 UUID你的sdb2的UUID /backup xfs defaults 0 2每一列的含义是设备标识、挂载点、文件系统类型、挂载选项、是否允许dump备份、开机自检顺序。最后一位填2的意思是这个分区在启动时需要进行文件系统检查但不参与根分区的完整性验证。根分区一般填1其他数据分区填2不需要检查的虚拟文件系统填0。写完fstab切记要做一次验证这一步是能救命的。直接执行sudo mount -a这个命令会按照fstab的内容重新挂载所有文件系统。如果没有报错说明fstab语法和UUID都没问题。如果报错了立刻回到/etc/fstab改正别等到重启才发现。我吃过这个亏因为fstab里设备名写错重启后系统直接进入emergency mode数据分区全都挂不上要手动修复才能恢复。所以在我的工作习惯里写完fstab必须马上mount -a验证已经成了铁律。最后一步是检查分区的挂载选项是否合理。defaults选项其实包含了一组默认参数包括rw、suid、dev、exec、auto、nouser、async但对数据盘来说有几个选项很值得打开noatime不更新文件访问时间减少不必要的磁盘写入对SSD和大文件服务器都有好处。nodiratime同上针对目录的访问时间。relatime在noatime基础上稍微折中一点很多发行版已经把它作为默认值了。我自己的生产数据盘用的挂载选项一般是defaults,noatime,nodiratime如果你走的是NFS或者需要频繁读文件访问时间戳的场景noatime可能会带来兼容性问题这时候relatime更稳妥。但大多数本地数据盘场景noatime是明显收益大于代价的。到这一步一块4TB的硬盘从裸盘到可用的两分区系统整个流程就走完了。整个过程大约5分钟核心步骤就七个字认盘、分、格、挂、写fstab。5. 文件系统选择ext4、xfs、btrfs之间的取舍分区只是画格子真正决定分区性能和使用体验的是文件系统。Linux下常见的选择有三种ext4、xfs、btrfs。下面从实际场景出发做个对比。ext4是ext系列的第四代2008年面世是目前Linux发行版默认文件系统的常客Debian、Ubuntu默认都是ext4。它的优势在于成熟稳定、工具链完善、兼容性极佳。老系统、老内核、各种嵌入式设备对ext4的支持几乎无处不在。对绝大多数个人用户和中低负载服务器来说ext4的性能和可靠性都完全够用。它的短板在于最大支持的单文件大小是16TB单分区容量上限是1EB实际上受限于block大小虽然理论够用但在超大存储池的场景下xfs更游刃有余。xfs最初由SGI开发2001年进入Linux内核设计目标是处理大文件和超大文件系统。在高并发、大文件顺序读写、海量小文件并存等场景下xfs的表现非常稳定。Red Hat系列的默认文件系统从ext4改成了xfs不是没有原因的。xfs还有几个让我很欣赏的特性在线扩容growfs非常灵活不需要卸载分区就能扩大内部有延迟分配和预分配机制对数据库日志这类频繁写入的场景很友好。它的缺点是不支持在线缩减分区只能变大不能变小这在规划不当的时候会非常尴尬。btrfs是B-tree文件系统2014年进入Linux内核主打的是写时复制COW、快照、子卷、校验和等一系列高级功能。听起来很美好尤其做文件服务器、做快照备份时非常方便。但对生产环境来说btrfs的稳定性一直是我保留意见的地方——不是说出过重大事故而是在长期高负载下它的碎片整理、空间回收balance机制需要持续维护普通用户容易忽视这些后台动作时间长了就出问题。如果你愿意深入学习并做定期维护btrfs可以给你带来很多便利如果你只是想分了区、格完盘、放上去就正常用我更推荐ext4或者xfs。我的选择逻辑很简单纯个人使用、虚拟机、嵌入式、老硬件ext4没有悬念。数据库、大文件存储、高IO服务器xfs首选。需要快照、子卷、想做文件级备份策略btrfs但要愿意学习和维护。不想折腾就想稳定ext4或者xfs二选一都行。格式化命令对应关系mkfs.ext4、mkfs.xfs、mkfs.btrfs。注意btrfs默认会自动创建子卷做得好的发行版会在根目录下生成一个名为root的子卷有时会给人造成困惑但用起来影响不大。文件系统选型还牵扯到一个重要参数预留空间。ext4默认会为你预留5%的空间用于线程恢复和碎片整理这个比例在根分区上有意义防止磁盘写满导致系统异常但在大数据盘上就有点浪费了。一块4TB的数据盘5%就是200GB白花花地留着不用。我建议对非根分区把预留比例调小sudo mkfs.ext4 -m 1 /dev/sdb1-m参数指定预留百分比为1%。xfs则没有这个预留机制它默认的分配组结构里包含了一定比例的AG头信息但那是元数据不是预留空间。所以xfs经常被用作数据盘空间利用率更高。还有对齐问题这里再敲一次黑板不管是ext4还是xfs创建分区时从1MiB启动、保证分区尺寸是4K的整数倍然后用mkfs时默认的block大小4K格式化性能都不会有大问题。如果你真的很在意SSD性能还可以额外使用mkfs.xfs的su和sw参数配置RAID的条带单元但这个参数是和具体存储阵列绑定的盲目设置反而可能引发性能下降生产环境里除非清楚硬件拓扑否则建议保持默认。6. fstab的深水区自动挂载、UUID、常见炸法fstab放在整个分区管理流程的收尾位置但它实际是Linux日常使用中最容易出事的文件之一。我单独开一节专门讲它因为这里面的坑太多太深了。fstab的第一行是根分区/的记录一般长这样UUIDxxxx / ext4 errorsremount-ro 0 1根分区的挂载选项里有errorsremount-ro意思是如果根分区发生IO错误自动以只读方式重新挂载避免数据进一步损坏。这个选项只建议用在根分区上。除了之前提到的UUIDfstab还支持一种更直观的写法LABEL。如果你在格式化的时候给文件系统设置过标签sudo mkfs.xfs -L mydata /dev/sdb1那么在fstab里就可以写LABELmydata /data xfs defaults 0 2这种写法的好处是标签比UUID短、好记而且如果磁盘设备名变了只要标签不变就能正确挂载。坏处是标签必须唯一否则系统会分不清到底该挂哪一个。我的建议是服务器上分区不多、标签取得有意义用LABEL可以分区很多、或者你经常复制镜像、插拔硬盘还是UUID更稳。fstab里还有一个容易被忽视的字段挂载超时。如果网络文件系统NFS、CIFS写进了fstab而网络又不可靠那么启动时系统可能会卡在等待该挂载点上一卡就是几分钟。应对办法是在挂载选项里加一个timeo或x-systemd.automount但这已经是fstab的进阶玩法了。对于本地磁盘不需要考虑这个。下面说fstab最经典的炸法我踩过并帮别人排过很多次。炸法一UUID写错。最常见的是从网上复制了别人的UUID根本没改。重启后系统找不到那个UUID对应的分区报错并进入emergency mode。这种情况的修复方式是重启后切到tty1登录用blkid查一下正确的UUID用nano/vim改/etc/fstab改完reboot就恢复了。炸法二fstab里挂载点目录不存在。比如你写挂载点到/data/archive但/data/archive目录还没创建开机时mount会失败。注意这个问题不像UUID错误那样会进入emergency mode而是在启动流程中默默失败具体表现就是系统能起来但你的/data/archive是空的。我遇到过几次这种情况还找了半天原因。解决方法很简单确保fstab里的挂载点目录真实存在或者提前mkdir -p。炸法三非系统分区挂载失败导致系统卡住。有些发行版特别是CentOS对fstab里的非根分区挂载失败非常敏感直接进入提醒界面你得手动输入root密码然后修复。这也是为什么我一直强调写完fstab必须mount -a测试而且测试完要重启验证一轮双保险。炸法四在fstab里写了文件系统类型但和实际不符。比如你格式化的是xfs但在fstab里写了ext4mount时系统拿ext4驱动去读xfs分区直接报错。这种错误比UUID写错更隐蔽因为blkid能看到UUID是对的但mount就是失败。用mount -a测试时立刻就能发现所以还是那句话验证验证再验证。如果fstab出了无法开机的问题还有一个Ultra兜底技能启动到Live USB环境。用Live USB启动系统后根分区和fstab都在你的控制范围内你可以挂载原系统盘、修改fstab、保存后退出。这个操作听起来复杂但实际就是挂载、编辑、卸载三个动作关键是你必须知道原系统盘的设备路径和文件系统类型。这个技能在服务器运维里属于必会项。7. 手工扩容当分区满了怎么在不丢数据的前提下扩大分区的容量规划永远赶不上实际增长这不是你不懂规划而是业务数据膨胀的速度本来就不讲道理。当分区快满的时候最常做的事是扩容。Linux的扩容逻辑和Windows不太一样Windows的磁盘管理能做到一键扩展卷Linux没有这种图形化傻瓜操作得靠命令行手动来而且不同的文件系统缩放的自由度完全不一样。对于xfs好消息是它支持在线扩容不需要卸载分区就能直接扩大坏消息是它不支持缩容只能扩大。对于ext4支持缩容前提是卸载分区也支持扩容过程比xfs繁琐一些。btrfs的扩缩容能力最强但配套命令和概念也更多。下面演示一个xfs扩容的完整流程。场景/backup分区/dev/sdb2快满了旁边还有空间我们把它扩大。首先看当前分区信息sudo parted /dev/sdb print假设sdb2现在结束位置是99%后面还有1%的空闲空间那么扩容步骤分两部分先扩分区再扩文件系统。第一步扩分区。用parted的resizepart命令sudo parted /dev/sdb resizepart 2 100%resizepart后面的数字是被调整的分区号100%表示把分区扩展到磁盘末尾。注意有个细节在parted里执行resizepart时如果磁盘正在被使用它会弹一个确认提示告诉你修改分区可能会影响文件系统。在线的xfs分区此时可以放心确认因为xfs自己会跟上新的大小。第二步扩文件系统。xfs专用的命令是xfs_growfssudo xfs_growfs /backup这个命令会扫描挂载点所在的分区自动把文件系统扩展到分区允许的最大尺寸。执行完再用df -h看容量已经变大了。整个过程最顺利的情况就是这么简单。但如果你的分区下面没有足够的空闲空间比如整块磁盘已经全部分配完了那就得先腾挪空间。常见的腾挪思路有两个一是删除不用的旧分区把空间让出来再扩展目标分区二是如果磁盘本身还有未分配的裸空间直接用parted的mkpart创建一个新分区然后把已有的那个分区resizepart过去。第二种情况相对好处理第一种需要极其小心因为删除分区意味着数据丢失。这里必须插播一个严重警告任何扩容操作都必须先做备份。我见过太多人看到df -h红了手一抖直接resizepart然后分区表损坏、数据丢失回来找我帮忙恢复。从我多年的经验看扩容失败的概率虽然不高但一旦失败数据恢复的成本极高。所以生产环境扩容第一步永远是快照或者物理备份哪怕你只是扩展一个备份分区。扩展分区还有一个容易被绕晕的地方是分区编号。如果你在磁盘中间位置删除了一个分区后续分区编号不会自动重排。比如原来有sdb1、sdb2、sdb3删掉sdb2之后sdb3还是叫sdb3而不会自动变成sdb2。所以在操作前先用lsblk和parted print看清整个分区表的布局这一步不能跳。8. 分区表损坏与数据救援gdisk备份、TestDisk实战分区管理里最让人毛骨悚然的一类事故是分区表损坏。可能是突然断电、可能是把Windows工具用在了GPT盘上、也可能只是误操作把分区删了。分区表坏了表面上看你所有的数据都消失了但文件系统其实还在磁盘上躺着数据根本没走只要分区表能重建数据就有救。这里分享两个分区表救援的真实思路。第一个是预防性思路GPT分区表备份。GPT分区表本身在磁盘头部LBA1到LBA33左右和尾部各存了一份结构比MBR稳健得多。但稳健不等于万无一失比如磁盘尾部扇区被其他程序误写覆盖备份分区表就没了。gdisk提供了完整的备份和恢复功能。备份当前分区表sudo gdisk /dev/sdb进入交互界面后按bbackup输入备份文件名比如sdb.gpt。这个备份文件记录了整个分区表的布局、分区类型、起始位置和结束位置。恢复时sudo gdisk /dev/sdb按rrecovery and transformation options再按lload backup from file选择备份文件最后按w写回磁盘。这套操作说起来简单但它能救命的场景是你误删了某个分区只要备份文件还在原地恢复就等于什么都没发生。缺点是你必须提前做了备份才有恢复的可能性。第二个思路是数据恢复工具TestDisk。它的原理是扫描磁盘里的文件系统特征识别出之前的分区边界然后重建分区表。TestDisk的安装不复杂sudo apt install testdisk # Debian/Ubuntu sudo yum install testdisk # CentOS/RHEL运行sudo testdisk /dev/sdb界面是全英文的但流程很清晰。一步步选择磁盘→分区表类型Intel对应于MBREFI GPT对应于GPT→选择Analyse→Quick Search然后等它扫描。扫描完成后TestDisk会列出找到的分区及其起始结束位置。如果结果里有你认识的那个分区选择它然后进入Recover把结果写回分区表。用TestDisk恢复时有一个关键教训在扫描结果里看到找回的分区时不要着急写盘先记下它显示的起始和结束位置用parted或者gdisk看看当前的磁盘布局确认不会覆盖到其他现有分区再动手。如果磁盘上还有多个分区盲目写回分区表可能会覆盖已经存在的分区记录造成二次破坏。TestDisk的容量恢复上限非常可观对现在几十TB的盘也完全适用。但它的效率取决于磁盘扫描范围和磁盘速度一块几TB的盘扫描可能要好几个小时这是正常现象耐心等就行。跟TestDisk配套的还有一个名叫PhotoRec的工具它更底层直接从扇区层面扫描和恢复文件不依赖分区表。但PhotoRec恢复出来的文件通常是一大堆无名的文件比如jpg_0001.jpg文件名和目录结构都没了对于分区表损坏后想找回原始目录结构的人来说TestDisk是更合适的选择。真到了分区表彻底没救的时候PhotoRec是最后一根救命稻草但我想你不会有那个耐心把几千个无名字节级文件重新归类。救援类工作我额外补充两个实操心得第一分区表损坏后第一个动作永远是立即断电或者把磁盘摘下来整个镜像不要在损坏的盘上继续做任何写操作每次写入都可能覆盖原始数据。第二如果有条件先对磁盘做一个扇区级镜像比如用dd-rescue或者qemu-img convert再在镜像文件上做恢复这样即使恢复过程又出问题原始盘还是干净的。这两个习惯能让你在灾难面前从容很多。9. 系统盘扩容从虚拟机到物理服务器的一点不同上面讲的分区、扩容都是针对数据盘的逻辑。系统盘根分区所在磁盘的扩容才是很多人最头疼的场景——因为系统盘在使用中无法卸载fdisk和parted对正在使用的分区动刀会非常危险。这个场景我分两类说清楚。第一类是虚拟机里的系统盘。虚拟化平台VMware、KVM、Proxmox等一般支持在线给虚拟磁盘加容量在虚拟化管理界面里把磁盘大小调大然后进虚拟机内部扩分区。这是相对温柔的方式因为虚拟磁盘加大的那部分空间是凭空新增的不会动你原有分区。比如虚拟机里系统盘是/dev/vda容量从20GB扩到50GB步骤是在宿主机管理界面调整虚拟磁盘大小进虚拟机用lsblk确认磁盘总量变成50GB用parted或者growpart命令把最后那个分区扩大sudo growpart /dev/vda 1这会把/dev/vda1从原来的结束位置扩展到磁盘末尾扩文件系统。如果是ext4sudo resize2fs /dev/vda1如果是xfssudo xfs_growfs /用df -h确认根分区容量变化。这套流程在虚拟化环境里已经高度成熟基本不会翻车。growpart命令在cloud-utils或cloud-guest-utils包里大部分云镜像都内置。第二类是物理服务器系统盘扩容复杂度直接上一个数量级。物理机的根分区扩容通常需要关机用Live CD或者可启动的救援介质启动挂载系统盘后进行分区调整。因为根分区在运行状态下不能被卸载你只能在救援环境里对分区表动手。这个过程对操作者的分区表理解、工具熟练度和心理素质要求都很高而且一旦出错系统就起不来了。我整理了一套物理机扩容的安全流程备份备份备份。系统盘数据包括分区表配置、/etc目录、数据库数据全量备份。关机准备一个Live USB比如Ubuntu桌面版的U盘从U盘启动到Live系统。在Live系统里确定系统盘设备名一般也是/dev/sda用lsblk和parted print看清当前分区布局。在Live系统环境下你的根分区已经不存在使用中的问题可以直接用parted resizepart扩分区。扩之前记下原分区的起始位置千万别动。扩完分区后依旧是在Live环境里用resize2fsext4或xfs_growfsxfs扩文件系统。如果根分区是xfsxfs_growfs需要先挂载对应分区到Live系统的一个临时目录然后指定挂载点执行。改完后重启进入原系统验证。物理机扩容最大的风险点是如果系统引导用的是MBR里的引导程序bootloader位于MBR区域而你用parted重新规划了分区表结构比如从MBR改成GPT引导程序可能失效系统直接进不了系统。所以物理机扩容之前务必确认当前引导方式是BIOSMBR还是UEFIGPT两种方式的引导存放位置不同。如果标识不明确宁可不做分区表转换只在原始类型里扩大结束位置。我自己的习惯是但凡遇到物理机系统盘扩容直接约一个维护窗口提前把所有变更步骤写成文档一个人操作一个person验证绝不在业务高峰直接动手。这种操作不属于熟练就能零风险的范畴属于熟练能最大限度控制风险的范畴。10. 分区管理的底层习惯监控、日志与日常巡检最后聊聊Linux分区管理里看不见但极其重要的部分——日常监控和巡检。分区废了、磁盘满了、文件系统elapsed了这些事不是哪次扩容时才遇到的而是每天都在悄悄发生的。真正成熟的运维者靠的是一套日常习惯而不是临时救火。先说监控。df和du是两条基础命令df看文件系统整体使用率du看目录占用大小。日常巡检至少要跑一次这样的组合df -hT加了-T参数会显示文件系统类型这样你能一眼看出每个分区用的什么格式心里有数。如果发现某个分区的使用率超过80%就该考虑清理或者扩容了别等到100%。再看inode。很多人只盯容量忽略了inode耗尽的问题。inode是文件系统存储文件元数据的索引节点每个文件或目录至少要占一个inode。如果分区里有海量小文件比如邮件队列、缓存目录、临时文件空间用不完但inode先满了表现就是磁盘明明有空间却总是创建文件失败。检查inode的方式df -i当IUse%超过90%就该排查是不是有异常目录在疯狂生成文件。接着看smart信息。固态硬盘和机械硬盘都会通过S.M.A.R.T.记录健康状态Linux下用smartctl查看sudo smartctl -a /dev/sda重点看Reallocated_Sector_Ct重映射扇区数、Current_Pending_Sector待重映射扇区数、UDMA_CRC_Error_Count接口CRC错误数。这几个值如果持续增长说明盘已经在物理层面恶化即使分区表完全正常也建议尽快换盘。我遇到过一次服务器无故卡顿查了半天最后是smartctl发现Current_Pending_Sector暴涨换盘之后一切恢复正常。分区表本身也需要定期备份尤其在生产服务器上。我前面提过gdisk的备份功能这里再补充一个更省心的方案写个定时脚本每天凌晨用gdisk把各磁盘的分区表备份到指定目录保留最近7份然后配合logrotate做日志清理。这样即使某天分区表被误操作清空你还能从昨天的备份里恢复。如果系统里有LVM逻辑卷管理监控逻辑会更复杂一些但核心观察点是一致的PV物理卷是否正常、VG卷组是否有空闲空间、LV逻辑卷使用率是否过高。LVM的好处是逻辑卷可以跨物理盘、可以在线扩缩容但它的多层抽象也意味着出问题时排错链路更长。对刚开始接触分区管理的朋友我的建议是先老老实实用普通分区ext4/xfs把基础打扎实再考虑LVM这类高级抽象。磁盘告警的处理顺序也值得固化下来当收到磁盘空间告警时先看df -hT确认是哪个分区再用du --max-depth1一层层排查大目录找到异常增长点确认是日志、缓存还是业务数据再决定清理方案。清理日志用logrotate缓存用缓存自身的清理机制业务数据该归档就归档。不要第一步就扩容你扩了容量业务数据的增长速度不会变问题只是被推迟了。日志方面/var/log/messages或者journalctl里关于磁盘和文件系统的错误要养成定期翻看的习惯。dmesg输出的IO错误、scsi报错、ext4/xfs的corruption信息往往在磁盘物理故障出现之前就有征兆。我曾在一台老服务器上看到dmesg定期刷出Buffer I/O error当时没在意一周后那块盘彻底报废。现在看到这类报错我的第一反应就是立刻备份数据、安排换盘窗口。写在最后的一点私人经验分区管理这个主题很多教程讲完命令就结束了但我想用自己多年的实际经历补一句真正让你和普通教程拉开差距的不是你会敲多少条命令而是你有多尊重数据安全这件事。我遇到过太多同行fdisk用得飞快但从不备份分区表、从不做smart监控、写fstab不验证、扩容不看布局最后出了一次事故几个月的运维成果毁于一旦。分区表的规划、工具的操作、文件系统的选型这些都能在短时间内学会但敬畏数据、先备份再动手、操作前看清布局、操作后立即验证这些习惯才是Linux分区管理里最值钱的东西。希望这篇长文能让你少走一些我走过的弯路。