黑河市all做Linux时间长了会发现，服务器上折腾人的故障，十有八九都和硬盘分区管理有关。磁盘空间说没就没、新加的盘插上怎么都挂不上、fstab写错一行直接开机进不了系统，这些坑我基本都踩过一遍。这篇文章把我这些年Linux硬盘分区管理的经验一条条捋出来，从最基础的分区概念、MBR和GPT怎么选，到新盘上线全流程，再到几个高频故障的排查实录和规划建议，给刚入行或者正被磁盘问题折磨的运维朋友做个参考。内容不追求面面俱到，但每一步都能落到实际操作上。
1. 分区这件事，为什么值得认真对待
1.1 分区解决的不只是存储问题
很多人第一次接触Linux分区，是在装系统的时候顺手点了一下“创建分区”，装完就再也不管了。但分区方案的影响是长期且隐蔽的。我见过不少线上事故，本质都是当初分区没设计好：日志文件把根分区写满导致数据库直接报错；系统分区和数据分区混在一起，重装系统时把业务数据全部冲掉；分区表用了MBR，后面要扩容到3TB才发现根本认不出，只能推倒重来。
分区解决三个层面的问题。第一是隔离，系统、数据、日志、临时文件各占各的地盘，某一块写满不会拖垮整个系统。第二是管理维度，独立分区可以单独做备份策略、单独设置配额、单独监控容量趋势，出问题时定位和处置都更快。第三是文件系统自由度，不同分区能用不同文件系统，按业务特性选型，比如小文件密集用ext4，大文件顺序写入用XFS。这三个价值决定了分区规划必须放在项目早期考虑，而不是等服务器上了线再后悔。
1.2 MBR还是GPT，动手前就要定
分区表是记录磁盘分区元数据的地方，现在实际能碰到的就两种：MBR和GPT。MBR是老标准，主分区最多4个，单分区最大约2TB，超出就没法处理。GPT是后来的新标准，支持128个分区，单分区容量上限基本等于没有上限，而且GPT在磁盘尾部还有一份备份分区表头，某个扇区坏了也能靠备份恢复，可靠性比MBR高不少。
怎么选？我的原则很简单：新机器、新数据盘一律用GPT，哪怕容量只有几百GB。理由也很朴素，你永远不知道这块盘未来会不会因为业务增长要扩容到2TB以上，到时候再迁移分区表非常痛苦。现在主流Linux发行版安装时已经默认GPT了，兼容性完全不用担心，MBR基本只在模拟老环境或者某些极度受限的引导场景下才会用。
另外提一句，别把分区表和文件系统搞混。分区表管的是磁盘怎么切块，文件系统管的是切完的每个块里面怎么存数据。这两层是独立的，很多人卡住是因为一直在一个层面里找问题。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 操作前先摸清服务器硬盘现状
2.1 三条查询命令，各管什么事
动手分区之前，最重要的一件事是把家底摸清楚。我常用的三条命令是lsblk、blkid和df，各有各的用处。
lsblk看的是全局拓扑。它会列出系统能识别到的所有块设备、每块盘的容量、各个分区，以及它们之间的父子关系。我拿到一台陌生服务器，第一件事就是敲lsblk，因为它把信息组织得很清楚，比如sda下面挂着sda1、sda2，一眼就知道整块盘分了几刀。加一个-f参数还能顺便看到文件系统类型和UUID，信息非常全：
bash复制lsblk -f
blkid看的是分区唯一的标识。它会输出每个分区的UUID、分区类型、文件系统类型。为什么要用这个？因为设备名比如sdb1在系统重启后可能变化，而UUID是格式化时生成的固定标识，不会变。后面配置fstab的时候，靠的就是它。
df看的是挂载和使用率。它显示当前挂载的文件系统、总容量、已用、可用、挂载点。df -h是人人都该掌握的命令，硬盘告警第一眼就要靠它确认哪个挂载点爆了。我更习惯在排查空间问题时先df -h，再lsblk -f看结构，最后用blkid拿UUID，三步走基本不会漏信息。
2.2 分区表查询与备份，成本最低的安全感
除了上面三条命令，我会用fdisk -l确认每块盘的容量和分区表类型。fdisk -l输出比较直观，能显示磁盘总容量、扇区大小、分区表类型，dos就表示MBR，gpt就表示GPT。如果想看更精确的扇区边界，就用parted把单位切到扇区：
bash复制parted /dev/sdb unit s print
确认每个分区的start端有没有对齐，这是很多性能问题容易忽略的地方。
这里我要重点提醒一句：分区操作前把分区表备份下来，是性价比最高的安全措施。MBR的分区表可以用sfdisk导出，GPT的用sgdisk备份：
bash复制sfdisk -d /dev/sdb > sdb-backup.txt
sgdisk --backup=/tmp/sdb-gpt.bak /dev/sdb
万一后面误操作把分区表弄坏了，只要磁盘数据没被覆盖，恢复的可能性会大很多。这个习惯我坚持了很多年，不止一次救过急。
3. 新盘上线完整实操：从分区到自动挂载
3.1 用parted创建GPT分区
现在进入真正的分区操作。我拿一个典型场景举例：服务器加了一块100GB的磁盘，系统识别为/dev/sdb，现在要把这块盘做成一个数据盘，挂载到/data目录。
先确认盘符，千万别凭感觉操作。lsblk看一下，确认sdb确实是新加的100GB空盘。如果sdb上已经有数据，后面的命令会造成不可逆的破坏，所以这一眼不能省，最好再拿fdisk -l /dev/sdb核对容量。
然后启动parted：
bash复制parted /dev/sdb
(parted) mklabel gpt
(parted) mkpart data 2048s 100%
(parted) print
(parted) quit
这几条命令逐个说明。mklabel gpt是给磁盘创建GPT分区表，如果原来是MBR，这一步会提示有风险，确认后老分区表被替换，等于清空分区，所以必须确认是在空盘上操作。mkpart data的意思是创建一个名为data的分区，起始位置我写2048s，结束位置写100%。起始为什么用2048s？这是1MiB对齐，对应现在硬盘普遍采用的4K物理扇区，对齐后读写性能更好，也是现代工具默认推荐的做法。从2048扇区开始而不是从1开始，就是为了避开磁盘最前面的元数据区，同时保证每个逻辑块和物理块对齐。结束位置直接给100%，表示把剩余空间全部分给这个分区，以后想扩容也方便。print确认一下分区是否创建成功，quit退出。
如果你习惯用fdisk也可以，新版fdisk已经支持GPT分区。parted和fdisk的差别主要在于，parted更侧重直观操作和大容量盘处理，fdisk是老牌工具、交互界面很多人更熟悉。两者都能完成任务，我推荐parted，尤其是面对2TB以上的大容量磁盘时。
3.2 格式化：ext4和XFS怎么选
创建完分区，磁盘上还只是光秃秃的区域，要能用必须先格式化出文件系统。Linux上用得最多的是ext4和XFS。
ext4是经典文件系统，兼容性最好，几乎所有发行版都默认支持，小文件场景表现稳定，而且支持在线缩小，这是XFS做不到的。缺点是单文件系统和单文件的大小上限在极端大容量场景下不如XFS激进。
XFS是大容量高并发场景的常客，特别适合大文件顺序读写的业务，像数据库数据文件、多媒体文件、日志采集落地，用XFS性能很稳。XFS扩容很方便，xfs_growfs直接在线扩大，但缩小几乎不可能，规划的时候要留足余量。
我个人的倾向是：根分区、boot这类系统分区用ext4，图稳定兼容；数据分区如果大文件多、写吞吐高，用XFS。拿刚才的例子，格式化成XFS：
bash复制mkfs.xfs /dev/sdb1
如果你的场景更需要ext4，命令就是：
bash复制mkfs.ext4 /dev/sdb1
这里说一个常见误区：mkfs把文件系统直接写在分区上，等于格式化，分区上原有的数据会被清空。命令一定要看清楚盘符和分区号，千万别把系统盘格式化，否则真的哭都来不及。
3.3 挂载和开机自动挂载的正确姿势
格式化完成，下一步就是挂载。挂载的原理并不复杂：把分区关联到系统目录树的某个挂载点，之后访问这个目录就等于访问这个分区。
先创建挂载点：
bash复制mkdir -p /data
然后手动挂载：
bash复制mount /dev/sdb1 /data
这时df -h /data就能看到容量正常了。但手动挂载只对当前运行生效，重启后就丢了，真正要搞定的是开机自动挂载，这需要配置/etc/fstab。
用blkid拿到分区的UUID：
bash复制blkid /dev/sdb1
输出类似这样：
bash复制/dev/sdb1: UUID="xxxx-xxxx-xxxx-xxxx" TYPE="xfs" PARTLABEL="data"
然后在/etc/fstab末尾加一行：
bash复制UUID="xxxx-xxxx-xxxx-xxxx" /data xfs defaults 0 0
fstab字段从左到右依次是：设备标识、挂载点、文件系统类型、挂载选项、dump备份标记、fsck顺序。设备标识我强烈建议用UUID，而不是/dev/sdb1，因为设备名可能在重启或内核更新后变化，UUID是文件系统固定烧录的标识，稳定得多。dump标记一般写0，fsck顺序根分区写1，其他数据分区写2或0，日常数据盘写0就行。
挂载选项这里也值得多说几句，常见的有下面几种：
| 选项 | 作用 | 使用场景 |
|---|---|---|
| defaults | 使用默认挂载参数 | 大多数普通数据盘 |
| noatime | 不更新访问时间戳，减少写IO | 数据库、日志类高IO场景 |
| discard | 开启TRIM，配合SSD | 固态硬盘建议开启 |
| _netdev | 网络设备挂载前等待网络就绪 | NFS、iSCSI等网络存储 |
写完fstab后，先别急着重启。我的习惯是用mount -a验证一下，这个命令会重新读取fstab并挂载所有配好的条目。如果mount -a没有任何报错，说明配置基本没问题。要是报错，马上把刚加的那行注释掉或者改回来。千万不要在不确定的情况下直接reboot，fstab写错了开机是会卡在救援模式的，后面4.3节会专门说这个问题。
3.4 验证不能省，三个动作都要做
新盘上线不代表完事，我还会做三个验证动作。
一是验证挂载真实生效。df -h /data看看容量对不对，再写一个测试文件检查读写权限：
bash复制df -h /data
echo "test" > /data/test.txt
cat /data/test.txt
二是验证开机自动挂载没问题。稳妥的做法是在维护窗口内真正重启一次，或者在虚拟机上重启测试。有些fstab配置用mount -a测试能通过，但重启时因为设备枚举顺序变化还是会失败，所以真机重启验证是最可靠的。
三是用findmnt检查挂载源，确认挂载的是sdb1而不是同名设备：
bash复制findmnt /data
别小看验证这一步。我见过有人fstab都写对了，重启还是失败，原因就是另一块盘的UUID和它冲突了，导致挂载顺序错乱。所以花一分钟做验证，能省掉后续一整天的排查时间。
4. 常见问题与排查实录
4.1 磁盘空间告警，三分钟定位大文件
磁盘满大概是最常遇到的告警了。排查思路要清晰：先用df -h看清楚哪个挂载点满了，再用du逐层找大目录，最后用lsof找漏网之鱼。
bash复制df -h
du -sh /data/* | sort -rh | head -20
如果是在一个很大的目录里找大文件，就一层层往下du，找到后根据业务情况删或者迁。有些情况df显示满了，但du把所有文件加起来远小于总容量，这时候十有八九是有文件被进程删除了但还被占用着。处理办法是用lsof查：
bash复制lsof | grep deleted
看到被删除但还开着的文件，确认对应进程后重启或者优雅重启该进程，空间就释放了。这个坑非常经典，很多人删了一堆日志还是发现空间没释放，就是因为没查deleted文件。
4.2 inode耗尽：df -h正常，但系统说没有空间
还有一类诡异问题：df -h看空间充足，但创建文件时报no space left on device，新建文件失败，连临时文件都写不进去。这时候要看inode：
bash复制df -i
inode是文件系统的索引节点，存储文件的元信息。每个文件、目录都会占用一个inode，inode数量在格式化时就固定了。如果小文件特别多，文件系统可能空间没满，inode先被耗尽了。遇到inode耗尽，先找出哪个目录小文件爆炸，可以用find统计目录下的文件数量：
bash复制find /data -type f | wc -l
find /data -type d | wc -l
找出爆炸目录后，清理历史文件，或者调整业务写文件的策略。如果这类目录长期会有海量小文件，建议一开始就把分区格式化成inode比例更高的文件系统，避免后续返工。
4.3 fstab配置错误导致无法开机
fstab配置有误是我见过最影响心情的问题之一，开机直接卡进救援模式。症状一般是开机时报错，提示找不到设备或者挂载失败，然后进入emergency mode或者maintenance mode。
如果还能进入救援shell，第一步是把挂载条目改回来。救援模式下文件系统通常是只读的，先重新挂载为可写：
bash复制mount -o remount,rw /
然后编辑/etc/fstab，把刚才添加的问题行注释掉，或者改成正确的UUID。检查无误后重启。如果还是不行，就要排查是不是UUID写错了，用blkid重新核对分区标识。预防方法很简单：每次改完fstab先mount -a，真机重启验证，并且备份一份正确的fstab，这个备份关键时刻能救命。
4.4 device busy、误删分区与恢复思路
挂载或卸载分区时经常遇到device is busy。mount一个已经有内容的分区到新挂载点，或者umount时还有进程在目录里，都会报这个错。排查思路是用lsof或fuser看谁占用了挂载点：
bash复制lsof /data
fuser -v /data
找到占用进程后处理掉，再卸载。实在需要强制卸载的话用umount -l，但要注意强制卸载可能导致未写入的数据丢失，能优雅卸载就尽量优雅。
误删分区是更严重的事故。如果分区表刚被误删，第一步是立刻停止对磁盘的写操作，不要再创建分区、再格式化、再挂载，避免覆盖原始数据。第二步是用testdisk这类工具扫描并尝试重建分区表，成功率取决于误操作后有没有写入新数据。实话实说，分区误删后能不能恢复完全靠运气，但只要没覆盖，概率还是不小的。所以前面说的分区表备份习惯，比任何恢复工具都可靠。
5. 长期有用的分区管理经验
5.1 分区规划时的几条建议
经过这么多项目的折腾，我总结了几条分区规划的经验，写在这里供你参考。
第一，系统盘和数据盘分离。这是最基础也最重要的规则。系统盘只管操作系统和应用程序，数据盘专门放业务数据，两者隔离后，系统重装、系统盘故障都不会直接影响业务数据。
第二，日志、临时文件单独分区。如果业务会产生大量日志，把日志目录单独挂一个分区，避免日志写满把根分区撑爆。临时文件多的服务也一样，单独分区可以保护系统盘不被瞬间涨满。
第三，频繁扩容的业务优先考虑LVM。LVM是逻辑卷管理，可以把多个物理分区合并成逻辑卷，在线扩容非常方便。如果前期就知道业务容量会持续增长，直接把磁盘做成LVM能省很多事。LVM的缺点是配置链路多一层，排查问题时需要多考虑一层，但只要规划合理，收益远大于成本。
第四，/boot和swap这类分区按引导需求来放。/boot建议单独分区，特别是涉及多系统引导的时候，单独/boot能减少引导兼容性问题。swap的大小老生常谈，现在再坚持“swap是物理内存两倍”的说法已经过时，实际按业务和内存压力来定，一般物理内存较大的服务器给16G、32G就够用，甚至可以动态调整。
5.2 实操中值得坚持的好习惯
最后分享几个我在实操中坚持的习惯。
一是所有涉及破坏性操作的命令，先三确认：确认磁盘，确认分区，确认不影响现有业务。lsblk和fdisk -l多敲一遍不会花多少时间，但能避免灾难性后果。
二是分区表备份、fstab备份要进例行巡检清单。用脚本定时把每一台服务器的分区表信息导出存档，数据量很小，但关键时刻作用极大。
三是每次新加盘、调整分区后，务必更新资产管理记录。我见过太多团队，磁盘加了没人记录，等半年后排查故障时，根本不知道哪块盘是谁在什么时间加的。记录这些信息能减少大量无效排查时间。
四是不迷信某个文件系统。ext4和XFS都经过大规模验证，稳定性和性能都靠得住，选择的核心指标是业务场景和团队熟悉度，而不是谁更新的所谓优势。稳定线上没有试错的余地，不太建议在生产环境用刚出道的文件系统。
分区管理这件事，看起来是Linux最基础的操作，但越是基础的东西，越容易因为轻视而栽跟头。把上面这些坑都踩过一遍之后，我现在反而觉得分区管理是最踏实的工作：只要规则清晰、操作谨慎、备份到位，它几乎不会出幺蛾子，出了也能快速定位。