1. 先想清楚再动手Linux磁盘管理的底层思路做Linux系统运维这些年我见过太多人在磁盘分区和挂载上栽跟头。要么是分区表选错导致2TB以上磁盘识别不全要么是挂载参数没写对导致开机进不了系统还有的更惨直接拿dd把整个盘的数据抹了。其实这些问题大多能提前规避关键是你得先理解Linux磁盘管理的核心逻辑。先说最基础的概念什么是挂载。Windows用户习惯C盘D盘这种盘符思维但Linux不是这样设计的。Linux是单根文件系统树所有文件和目录都从根目录/开始往下生长。你要让一块新磁盘派上用场本质上做两件事第一在磁盘上划分出可用的区域分区第二把这些区域接到文件系统树的某个目录上挂载。这个接的动作就是mount那个目录就是挂载点。理解了挂载点这个设计很多问题就迎刃而解了。比如为什么/home可以单独分一个区因为/home本身只是根目录下一个普通目录但它可以被一块独立磁盘的分区挂载覆盖。系统启动时先挂载/再挂载/home之后写入/home的数据就落到那块独立磁盘上了。这种任意目录皆可挂载的灵活性是Windows盘符逻辑给不了的。这篇文章主要写给两类人一是刚接触Linux服务器、需要自己给数据盘做分区的初学者二是被磁盘空间、挂载故障折腾过、想把底层原理彻底搞明白的进阶用户。我会从选型、分区、格式化、挂载、开机自动挂载到故障排查完整串一遍所有命令都给实际操作过的用法和参数照着敲基本不会出问题。最后再分享几个我踩过的坑比文档里写的东西实在得多。2. 实战前的准备工作磁盘识别与分区方案选型2.1 先认清你的磁盘lsblk、fdisk与blkid的配合拿到一台新机器或者插上一块新硬盘第一步不是急着分区而是搞清楚系统认出了哪些磁盘、它们的大小和总线类型。我惯用的顺序是先lsblk看一眼整体拓扑再fdisk -l确认磁盘容量和分区表类型最后blkid查UUID和文件系统。# 查看块设备树状结构直观看到磁盘和分区关系 lsblk # 查看所有磁盘的详细信息包括扇区大小、总容量 fdisk -l # 查看或定位块设备的UUID和文件系统类型 blkid这三个命令各有侧重。lsblk适合快速确认哪块盘是系统盘、哪块是新增盘输出里能看到NAME列设备名、SIZE列容量、MOUNTPOINTS列挂载点。fdisk -l能看到底层参数比如扇区大小是512B还是4K磁盘总扇区数。blkid在配置/etc/fstab时几乎是必用因为用UUID挂载比用设备名稳定得多。新加的磁盘设备名通常是/dev/sdb、/dev/sdc这种顺序往下排。如果是NVMe固态名字会不一样形如/dev/nvme0n1它下面的分区名是/dev/nvme0n1p1这种带p的格式。虚拟机上挂的虚拟磁盘常见/dev/vda、/dev/vdb。看到这些命名规律你就能快速定位目标磁盘。2.2 分区表选型MBR与GPT怎么选为什么分区表是磁盘上记录分区信息的元数据主流就两种传统的MBR和现代UEFI规范配套的GPT。很多新手栽在这里拿着fdisk给一块3TB的盘分区结果只能认出2TB剩下的容量找不到了。原因就是MBR的寻址方式最多支持2TB磁盘这个限制是硬性的。我给你的选型建议非常直接磁盘容量小于2TB且机器是传统BIOS启动的用MBR没问题兼容性最好。磁盘容量大于等于2TB或者机器是UEFI启动的一律用GPT。即使容量不到2TB只要没有老设备兼容性顾虑我也建议直接用GPT。它支持无限个分区数量Windows下限制128个Linux下基本够用而且有冗余分区表容错性更强。Linux下分区工具和分区表类型是绑定的fdisk默认操作MBR新版本也支持GPT但对GPT的操作有一些限制parted和gdisk是操作GPT的主力工具gdisk对交互式操作更友好。parted的强项是支持脚本化非交互操作适合批量场景。看你的使用习惯选我的做法是小容量盘用fdisk大容量盘或需要脚本化时用parted。2.3 分区规划哪些目录适合单独分区哪些不用分区方案这东西没有标准答案完全看业务场景。但有几条经验值得参考根分区/不用分太大系统安装完后一般占用不大50GB对大多数场景足够。当然如果装了很多软件、容器镜像比较多可以放大到100GB但没必要把整块盘都给它。/home建议单独分。用户数据都在这里出问题重装系统时只要保留这个分区数据就不会丢。/data、/opt这类应用数据目录在生产环境几乎必须单独分区。因为应用日志膨胀很快不给它单独规划空间的话日志写满根分区系统直接就卡死了。数据库文件、容器数据卷目录最好用独立的物理磁盘加独立分区避免和系统抢IO。还有一个容易被忽略的问题交换分区swap怎么处理。现在内存普遍大swap的作用相对弱化但服务器上保留一点swap仍能在内存紧张时兜底。如果服务器内存大于16GB用swap文件代替swap分区更灵活毕竟调整文件大小比调整分区大小方便得多。提示生产环境改分区前无论多自信先备份数据再操作。分区表损坏导致数据丢失的事故我见过比你想像的多得多。3. 分区实操fdisk与parted的完整操作流程3.1 fdisk交互式操作详解MBR分区的标准动作fdisk是最经典的分区工具它的交互式界面让新手觉得门槛高其实核心命令就几个。我以给/dev/sdb分两个区为例完整敲一遍。fdisk /dev/sdb进入交互界面后输入n新建分区。它会问你分区类型主分区p还是扩展分区e分区号默认1开始起点扇区默认用第一个可用扇区直接回车即可终点扇区有两种输入方式输入具体扇区号或者输入容量比如100G表示新建一个100GB的分区。关键点是容量这种简写非常方便不用自己算扇区数。我实际操作用得最多的就是这种写法。MBR磁盘上主分区最多4个如果需要超过4个分区第4个必须建成扩展分区然后在扩展分区里建逻辑分区。逻辑分区的设备名是/dev/sdb5、/dev/sdb6这种从5开始编号的。分完所有分区后输入w保存并退出。这里有个很多人忽略的操作fdisk在你保存之前所有改动都只存在内存里对磁盘没有实际影响。如果你反悔了直接按q退出则什么都不改。修改完成后系统可能不会立刻刷新分区表。需要用partprobe命令让内核重新读取分区表或者直接重启机器。我习惯执行partprobe /dev/sdb它比重启高效得多。3.2 parted脚本化操作GPT分区和大容量磁盘的正解遇到2TB以上磁盘fdisk虽然也能建GPT分区表但存在一些交互限制最顺手的方式是用parted。它支持一条命令直接完成全流程不需要进入交互模式。# 将磁盘分区表设置为GPT同时清除原有分区表信息 parted /dev/sdb mklabel gpt # 创建第一个分区从1MiB开始大小100GB parted /dev/sdb mkpart primary 1MiB 100GiB # 创建第二个分区从100GiB开始用到磁盘末尾 parted /dev/sdb mkpart primary 100GiB 100% # 查看分区结果 parted /dev/sdb print这里注意两个细节。第一mkpart primary 1MiB 100GiB的格式是起始位置 结束位置不是起始位置 大小。新手经常把100G的fdisk习惯带过来结果分区大小完全不对。第二GPT分区表下primary这个参数已经没有实际意义MBR时代才区分主分区、扩展分区但保留这个写法能兼容老版本parted。还有一点parted的单位可以写MiB、GiB、%等多种形式。用%这种相对方式在不确定磁盘总容量时特别适合比如100%表示剩余全部空间都给这个分区。我写脚本时喜欢用1MiB做起始位置是为了给分区表元数据预留空间避免因为对齐问题导致分区起始位置不对。3.3 分区参数的对齐问题为什么4K对齐必须做对齐这个词听起来抽象但处理不当会明显降低磁盘性能尤其是SSD。现在的磁盘物理扇区基本是4096字节4K但逻辑扇区为了兼容老系统仍然显示512字节。如果分区起始位置没有对齐到4K边界每次IO操作就可能跨物理扇区导致读写放大。我的实用建议是分区起始位置一律从1MiB开始也就是2048个512B扇区的位置。这个位置天然对齐4K因为1MiB是4096的256倍。fdisk默认的起始位置通常也是2048扇区不用额外调整。parted在使用MiB单位时也会自动对齐用GB则可能不对齐这也是我推荐用MiB而不是GB的另一个原因。判断现有分区是否对齐可以用这个命令# 查看分区起始扇区号能被8整除说明对齐了4096字节边界 cat /sys/block/sdb/sdb1/start这个数字除以8如果能整除说明分区已经4K对齐。看不到这个文件的话说明设备没有分区或者驱动不支持不用担心。4. 创建文件系统与挂载从mkfs到mount的完整链路4.1 文件系统选型ext4与xfs怎么选以及硬链接的坑分区建好只是第一步必须在分区上创建文件系统才能往里存文件。Linux下叫格式化实际命令是mkfs。选文件系统类型这事看着简单实际上一旦定下来后面再改成本很高。最常见的两个选择是ext4和xfs。我给的选型建议偏实践追求成熟稳定、兼容性最好选ext4。它支持在线扩容、缩小xfs不支持缩小是CentOS 6时代到现在都稳如老狗的文件系统。处理大文件、大容量存储、高并发写入选xfs。它是CentOS 7之后的默认文件系统对大规模并行IO的优化比ext4好。需要快照、去重、压缩等高级功能的可以看btrfs或者zfs。但这两种在主流发行版里还属于能跑但非默认没有足够经验前我不建议在生产环境直接用。有个最容易被坑的点xfs不能缩小只能扩大。如果你想在xfs分区上做空间回收或缩小不好意思不支持。分区规划时必须一次想清楚或者干脆给足容量。ext4可以缩小但过程也比较麻烦建议同样不要在根分区上随意操作。创建文件系统的命令很简单# 创建一个ext4文件系统 mkfs.ext4 /dev/sdb1 # 创建一个xfs文件系统 mkfs.xfs /dev/sdb14.2 手动挂载与卸载mount命令的核心参数文件系统建好之后第一步是创建挂载点目录然后挂载。挂载点可以理解为Windows里的盘符但更灵活——它只是文件系统树上一个普通目录。# 创建挂载点目录 mkdir -p /data # 手动挂载 mount /dev/sdb1 /data # 验证挂载结果 df -h /data手动挂载的场景是临时测试、紧急扩容之类。mount命令带了很多参数其中生产环境最常用的是这几个# 带noatime挂载减少不必要的元数据写入提高IO性能 mount -o noatime /dev/sdb1 /data # 以只读方式挂载适合排查数据问题 mount -o ro /dev/sdb1 /data # 同时添加多个挂载选项逗号分隔 mount -o noatime,nodiratime /dev/sdb1 /data我特别推荐生产环境用noatime。Linux默认记录atime访问时间每次读文件都要更新这个时间戳对于高并发读场景会产生大量额外写IO。加上noatime后只在创建、修改文件时更新时间戳读操作不再触发写盘对性能有可感知的提升。尤其对数据库、Web静态资源这类读多写少的场景这个优化几乎零成本。卸载用umountumount /data # 如果提示target is busy用lazy卸载方式 umount -l /data4.3 UUID的作用为什么fstab里不直接用设备名分区、格式化完成之后你会遇到一个叫UUID的东西。它是文件系统的唯一标识符每次格式化会随机生成。blkid命令可以查到它。blkid /dev/sdb1输出类似这样/dev/sdb1: UUIDa85b45f0-3a2e-4c7a-9a2d-54d5b8f17015 TYPEext4为什么挂载时推荐用UUID而不是设备名因为设备名会变。比如你插拔了U盘原来/dev/sdc可能变成/dev/sdb系统盘从SATA换到NVMe所有设备名都会重排。但UUID是在格式化时写入文件系统元数据的不管设备名怎么变UUID都不会变。系统开机时按UUID去锁定设备比按设备名可靠得多。有种情况可以绕过UUID系统盘只有一个数据盘且永远不插拔此时设备名很稳定。但这种永远不插拔在服务器运维里根本不存在为了省那点事冒险不划算。5. 开机自动挂载fstab配置与避坑指南5.1 fstab六个字段逐行拆解手动挂载只在当前会话有效重启后就没了。要让分区开机自动挂载必须写入/etc/fstab文件。这是Linux系统里最不能随便改的文件之一写错一行轻则某个分区挂不上重则直接开不了机。/etc/fstab每一行有六个字段分别用空格或Tab分隔我逐字段解释UUIDa85b45f0-3a2e-4c7a-9a2d-54d5b8f17015 /data xfs defaults,noatime 0 2第一个字段是设备标识推荐用UUID。也可以写/dev/sdb1但不推荐理由上面说过了。第二个字段是挂载点必须是已存在的目录。第三个字段是文件系统类型。第四个字段是挂载选项最常用的是defaults它等于rw,suid,dev,exec,auto,nouser,async这组默认参数的集合。如果是SSD加noatime是常规操作理由前面讲过。第五个字段表示是否用dump备份0表示不备份1表示每天备份2表示不定期备份现代系统直接写0即可。第六个字段是开机时fsck检查顺序。根分区/必须写1其他写2或00表示开机不检查写2表示在根分区之后检查。fsck是文件系统检查工具开机时按这个字段顺序依次检查。根分区写1优先级最高其他分区写2不需要检查的写0。写错了可能导致开机卡在文件系统检查阶段。5.2 手把手配置fstab并验证我建议的配置流程是先手动挂载测试确认没问题再写入fstab。不要直接改完fstab就重启那是拿生命赌配置的正确性。# 第一步备份fstab cp /etc/fstab /etc/fstab.bak # 第二步确认设备UUID blkid /dev/sdb1 # 第三步创建挂载点 mkdir -p /data # 第四步把下面这行追加到/etc/fstab末尾 echo UUIDa85b45f0-3a2e-4c7a-9a2d-54d5b8f17015 /data xfs defaults,noatime 0 2 /etc/fstab # 第五步用mount -a验证配置是否正确 mount -a关键一步是第五步的mount -a。这个命令会读取fstab并尝试挂载所有标记为auto的分区。如果执行后没有报错再用df -h确认挂载点有对应空间那基本就稳了。如果报错马上改回备份文件cp /etc/fstab.bak /etc/fstab还有一个小技巧如果fstab里的挂载点路径写错mount -a会给出明确报错但如果不执行这个命令直接重启你可能就卡在系统启动的紧急模式里了。所以mount -a验证这一步绝对不能省。5.3 通过systemd mount unit替代fstab的进阶玩法如果你用的发行版是CentOS 7以上或者Ubuntu 16.04以上可以考虑用systemd原生的mount单位来管理挂载。它的好处是支持依赖关系、自动重挂载、启动失败时更友好的日志输出。systemd挂载单位文件放在/etc/systemd/system/目录下命名规则是挂载点的路径把斜杠换成横杠再加.mount后缀。挂载点/data对应的单位文件名是data.mount。[Unit] DescriptionData Disk Mount Afterlocal-fs.target [Mount] What/dev/sdb1 Where/data Typexfs Optionsdefaults,noatime [Install] WantedBymulti-user.target配置完后启用systemctl daemon-reload systemctl enable --now data.mount如果你觉得fstab老出问题这个方式是现代发行版更推荐的做法。不过现实中fstab仍然是主流因为它简单直观、所有Linux发行版都支持。我的建议是个人实验和学习阶段可以用fstab掌握原理生产环境用systemd单位管理更规范。6. 从原理到实战一次完整的数据盘挂载走读前面五节把原理和命令都拆开了讲这一节我把整个流程从零走一遍模拟一块新数据盘从识别到开机自动挂载的完整过程。这样做的好处是你能看到每个步骤的输入输出长什么样实际操作时心里更有底。环境是这样的一台虚拟机系统盘是/dev/vda新增了一块100GB的数据盘识别为/dev/vdb目标是把它挂载到/data目录用于存放应用数据。第一步确认磁盘信息[rootlocalhost ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 252:0 0 30G 0 disk └─vda1 252:1 0 30G 0 part / vdb 252:16 0 100G 0 disk看到vdb这个100GB的磁盘还没有任何分区状态是原始磁盘。此时绝对不要在系统盘上动刀确认目标设备就是对的那块盘再继续。第二步创建GPT分区表并新建一个分区使用全部空间parted /dev/vdb mklabel gpt parted /dev/vdb mkpart primary 1MiB 100% parted /dev/vdb print示意输出Model: Virtio Block Device (virtblk) Disk /dev/vdb: 107GB Sector size (logical/physical): 512B/4096B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 1049kB 107GB 107GB primary确认分区/dev/vdb1已经建好但目前没有文件系统File system列是空的。第三步创建文件系统mkfs.xfs /dev/vdb1第四步创建挂载点并手动挂载mkdir -p /data mount /dev/vdb1 /data df -h /data第五步写入fstab。先blkid拿到UUID[rootlocalhost ~]# blkid /dev/vdb1 /dev/vdb1: UUID3e9c4f08-c437-4a21-a90f-5b8aade5e3ed TYPExfs然后追加一行到/etc/fstab执行mount -a验证最后视需要用reboot实测开机自动挂载是否生效。完整走下来这一套流程不会超过5分钟。花的时间主要看你有没有手误。慢一点没关系操作前多想一步比操作后补救强太多。7. 常见故障排查从设备忙到系统起不来7.1 卸载提示target is busy怎么定位占用进程这是卸载磁盘时最经典的报错。当一个目录里有进程正在读写文件直接umount必然失败。报错信息简单粗暴target is busy。定位占用的进程用lsof或fuser# 查看哪个进程占用了挂载点 lsof /data # 更直接的方式列出占用挂载点的进程PID fuser -mv /data定位后有两种处理方式如果是实际业务进程等它跑完再卸载如果是可以中断的操作用fuser -k /data强制杀掉进程再卸载。我一般先用lsof确认是什么进程评估杀进程的影响后再动作不盲目用fuser -k。还有一个常见坑当前工作目录在挂载点里也会导致卸载失败。如果你在/data目录里然后执行umount /data提示target is busy你先cd /退出该目录再卸载就行了。7.2 找不到设备或UUID变了blkid和新旧设备冲突场景是这样的换了一块盘或者格式化之后重启fstab里写的UUID对不上了开机报错无法挂载某个分区。排查思路先用blkid看看现有的UUID再对比fstab里的内容。blkid grep -v ^# /etc/fstab如果UUID确实变了更新fstab即可。如果是设备名变了比如U盘从sdb变成了sdc但UUID没变那fstab里用UUID写的配置不影响。这正是我在前面反复强调用UUID的理由——设备名会变UUID不会。还有一种情况新盘插上去后系统原有的设备名被挤到后面去了某些脚本里写死了/dev/sdb就找不到目标分区。这类问题的根治办法只有一个所有涉及持久化引用的地方一律用UUID脚本里也不要写死设备名。7.3 fstab写错导致开机进入emergency mode怎么自救这是fstab故障里最严重的情况。开机时系统尝试挂载fstab里的分区如果报错或者挂载点不存在会直接进入emergency mode紧急模式。这个模式下大部分服务都没有启动但root文件系统通常是可读的可以执行补救操作。关键在于这个模式下文件系统可能是只读挂载的你需要先重新挂载为可写mount -o remount,rw /然后编辑fstab把出问题的那行注释掉或者改正保存后重启。如果你在进紧急模式前做过fstab备份直接恢复备份最省事cp /etc/fstab.bak /etc/fstab还有一种可能系统直接停在grub引导界面连emergency mode都进不去。这通常是分区表层面出了问题比如误操作把整个磁盘分区表删了。这种情况下数据是否还能找回取决于你有没有备份以及是否及时断电停止写入行为——越早停手找回数据的概率越大。这也是我对所有生产环境喊话的原因操作分区、格式化、改fstab之前先备份再操作。7.4 分区扩容根分区空间告急时怎么处理最后一个高频场景根分区满了系统卡顿甚至服务直接挂掉。排查磁盘使用情况df -h如果根分区空间告急有几种应对思路。如果是LVM逻辑卷可以动态扩容这是LVM设计的初衷过程相对顺畅。如果是传统分区且文件系统是ext4可以先扩大分区再resize2fs在线调整文件系统大小但这个过程有风险步骤管理不好容易丢数据。如果是xfs文件系统不能缩小但可以扩大扩大流程是扩大分区用parted或fdisk重建分区表保留起点、改终点然后xfs_growfs扩大文件系统。还有一个长效机制把数据盘独立分区日志目录、容器数据目录通过软链接或挂载指向数据盘。排查告警时把增长最快的目录单独规划出来比反复折腾分区扩容高效得多。我自己管理的机器空间规划上一定会给/留够余量另外给/var和容器数据目录单独划分空间这样后面出问题的概率明显降低。8. 我踩过的几个坑一些不写在文档里的实战心得讲了这么多原理和步骤最后分享几个我实际操作中遇到的教训都是文档里一般不写但非常实用的经验。第一个教训是关于fdisk -l的输出被误读。有些云主机厂商给的数据盘可能已经有分区表但分区大小不是全盘你以为从头分区就能覆盖整个盘结果原有的残留分区信息导致新分区创建异常。拿到新盘第一件事永远先看parted /dev/sdb print确认分区表状态。如果有残留分区且确认不需要直接用parted的mklabel重建分区表这是最干净的清理方式。第二个教训是SSD分区对齐的影响不是立刻体现的而是长时间使用后才慢慢暴露。我有一台数据库服务器分区起始位置是63扇区老式对齐方式初期性能没看出问题跑了一个多月后写入放大明显磁盘寿命急剧消耗。后来把所有SSD都改为1MiB对齐后重建了环境写入延迟和寿命消耗都有了质的改善。如果你管理的机器有SSD一定要用我前面说过的方法检查分区对齐情况。第三个教训是关于系统盘和普通数据盘的操作区分。新人在没有完全确认设备名时就执行了分区操作把系统盘给格式化了这种事故不是个案我遇到过好几次。现在我的铁律是分区、格式化任何一步操作之前用lsblk和df -h双重确认系统盘挂载点必须是一个明确的目录而不是模棱两可的空挂载点。新增磁盘先看容量大小和系统盘做对比确认百分之百正确再动。第四个心得是关于云服务器数据盘挂载。云平台给的独立数据盘在机器重启时设备名可能改变但UUID不变。所以我把所有云主机的fstab全部改成UUID引用设备名只在临时命令里用从不写进任何持久化配置文件里。几年下来即便是迁移到新规格的云主机、磁盘控制器换了导致设备名大变我也没有因为这个原因出过故障。最后一个实用技巧给分区挂载做好命名和注释。我通常会让每个数据盘挂载点有明确用途比如/data/mysql、/data/static而不是笼统的/data。fstab里每一行都加注释写清楚这块盘是做什么的。当你半年后回来看一台没维护过的机器时清晰的注释能救你半条命。总的来说Linux磁盘分区和挂载原理不复杂但坑是真的多。理解分区、格式化、挂载、持久化这四个环节各自的职责把每一步的验证动作做标准大部分故障都可以避免。真遇到问题时不要病急乱投医挨个环节排查问题八成能锁定。最后再强调一遍任何涉及磁盘的操作备份先行确认再三。这是所有运维教训里最贵的一条。 
长河君 · 2026/10/23 3:37:28 · 阅读 1.2k Linux磁盘分区与挂载实战：从fdisk到fstab全攻略
1. 先想清楚再动手Linux磁盘管理的底层思路做Linux系统运维这些年我见过太多人在磁盘分区和挂载上栽跟头。要么是分区表选错导致2TB以上磁盘识别不全要么是挂载参数没写对导致开机进不了系统还有的更惨直接拿dd把整个盘的数据抹了。其实这些问题大多能提前规避关键是你得先理解Linux磁盘管理的核心逻辑。先说最基础的概念什么是挂载。Windows用户习惯C盘D盘这种盘符思维但Linux不是这样设计的。Linux是单根文件系统树所有文件和目录都从根目录/开始往下生长。你要让一块新磁盘派上用场本质上做两件事第一在磁盘上划分出可用的区域分区第二把这些区域接到文件系统树的某个目录上挂载。这个接的动作就是mount那个目录就是挂载点。理解了挂载点这个设计很多问题就迎刃而解了。比如为什么/home可以单独分一个区因为/home本身只是根目录下一个普通目录但它可以被一块独立磁盘的分区挂载覆盖。系统启动时先挂载/再挂载/home之后写入/home的数据就落到那块独立磁盘上了。这种任意目录皆可挂载的灵活性是Windows盘符逻辑给不了的。这篇文章主要写给两类人一是刚接触Linux服务器、需要自己给数据盘做分区的初学者二是被磁盘空间、挂载故障折腾过、想把底层原理彻底搞明白的进阶用户。我会从选型、分区、格式化、挂载、开机自动挂载到故障排查完整串一遍所有命令都给实际操作过的用法和参数照着敲基本不会出问题。最后再分享几个我踩过的坑比文档里写的东西实在得多。2. 实战前的准备工作磁盘识别与分区方案选型2.1 先认清你的磁盘lsblk、fdisk与blkid的配合拿到一台新机器或者插上一块新硬盘第一步不是急着分区而是搞清楚系统认出了哪些磁盘、它们的大小和总线类型。我惯用的顺序是先lsblk看一眼整体拓扑再fdisk -l确认磁盘容量和分区表类型最后blkid查UUID和文件系统。# 查看块设备树状结构直观看到磁盘和分区关系 lsblk # 查看所有磁盘的详细信息包括扇区大小、总容量 fdisk -l # 查看或定位块设备的UUID和文件系统类型 blkid这三个命令各有侧重。lsblk适合快速确认哪块盘是系统盘、哪块是新增盘输出里能看到NAME列设备名、SIZE列容量、MOUNTPOINTS列挂载点。fdisk -l能看到底层参数比如扇区大小是512B还是4K磁盘总扇区数。blkid在配置/etc/fstab时几乎是必用因为用UUID挂载比用设备名稳定得多。新加的磁盘设备名通常是/dev/sdb、/dev/sdc这种顺序往下排。如果是NVMe固态名字会不一样形如/dev/nvme0n1它下面的分区名是/dev/nvme0n1p1这种带p的格式。虚拟机上挂的虚拟磁盘常见/dev/vda、/dev/vdb。看到这些命名规律你就能快速定位目标磁盘。2.2 分区表选型MBR与GPT怎么选为什么分区表是磁盘上记录分区信息的元数据主流就两种传统的MBR和现代UEFI规范配套的GPT。很多新手栽在这里拿着fdisk给一块3TB的盘分区结果只能认出2TB剩下的容量找不到了。原因就是MBR的寻址方式最多支持2TB磁盘这个限制是硬性的。我给你的选型建议非常直接磁盘容量小于2TB且机器是传统BIOS启动的用MBR没问题兼容性最好。磁盘容量大于等于2TB或者机器是UEFI启动的一律用GPT。即使容量不到2TB只要没有老设备兼容性顾虑我也建议直接用GPT。它支持无限个分区数量Windows下限制128个Linux下基本够用而且有冗余分区表容错性更强。Linux下分区工具和分区表类型是绑定的fdisk默认操作MBR新版本也支持GPT但对GPT的操作有一些限制parted和gdisk是操作GPT的主力工具gdisk对交互式操作更友好。parted的强项是支持脚本化非交互操作适合批量场景。看你的使用习惯选我的做法是小容量盘用fdisk大容量盘或需要脚本化时用parted。2.3 分区规划哪些目录适合单独分区哪些不用分区方案这东西没有标准答案完全看业务场景。但有几条经验值得参考根分区/不用分太大系统安装完后一般占用不大50GB对大多数场景足够。当然如果装了很多软件、容器镜像比较多可以放大到100GB但没必要把整块盘都给它。/home建议单独分。用户数据都在这里出问题重装系统时只要保留这个分区数据就不会丢。/data、/opt这类应用数据目录在生产环境几乎必须单独分区。因为应用日志膨胀很快不给它单独规划空间的话日志写满根分区系统直接就卡死了。数据库文件、容器数据卷目录最好用独立的物理磁盘加独立分区避免和系统抢IO。还有一个容易被忽略的问题交换分区swap怎么处理。现在内存普遍大swap的作用相对弱化但服务器上保留一点swap仍能在内存紧张时兜底。如果服务器内存大于16GB用swap文件代替swap分区更灵活毕竟调整文件大小比调整分区大小方便得多。提示生产环境改分区前无论多自信先备份数据再操作。分区表损坏导致数据丢失的事故我见过比你想像的多得多。3. 分区实操fdisk与parted的完整操作流程3.1 fdisk交互式操作详解MBR分区的标准动作fdisk是最经典的分区工具它的交互式界面让新手觉得门槛高其实核心命令就几个。我以给/dev/sdb分两个区为例完整敲一遍。fdisk /dev/sdb进入交互界面后输入n新建分区。它会问你分区类型主分区p还是扩展分区e分区号默认1开始起点扇区默认用第一个可用扇区直接回车即可终点扇区有两种输入方式输入具体扇区号或者输入容量比如100G表示新建一个100GB的分区。关键点是容量这种简写非常方便不用自己算扇区数。我实际操作用得最多的就是这种写法。MBR磁盘上主分区最多4个如果需要超过4个分区第4个必须建成扩展分区然后在扩展分区里建逻辑分区。逻辑分区的设备名是/dev/sdb5、/dev/sdb6这种从5开始编号的。分完所有分区后输入w保存并退出。这里有个很多人忽略的操作fdisk在你保存之前所有改动都只存在内存里对磁盘没有实际影响。如果你反悔了直接按q退出则什么都不改。修改完成后系统可能不会立刻刷新分区表。需要用partprobe命令让内核重新读取分区表或者直接重启机器。我习惯执行partprobe /dev/sdb它比重启高效得多。3.2 parted脚本化操作GPT分区和大容量磁盘的正解遇到2TB以上磁盘fdisk虽然也能建GPT分区表但存在一些交互限制最顺手的方式是用parted。它支持一条命令直接完成全流程不需要进入交互模式。# 将磁盘分区表设置为GPT同时清除原有分区表信息 parted /dev/sdb mklabel gpt # 创建第一个分区从1MiB开始大小100GB parted /dev/sdb mkpart primary 1MiB 100GiB # 创建第二个分区从100GiB开始用到磁盘末尾 parted /dev/sdb mkpart primary 100GiB 100% # 查看分区结果 parted /dev/sdb print这里注意两个细节。第一mkpart primary 1MiB 100GiB的格式是起始位置 结束位置不是起始位置 大小。新手经常把100G的fdisk习惯带过来结果分区大小完全不对。第二GPT分区表下primary这个参数已经没有实际意义MBR时代才区分主分区、扩展分区但保留这个写法能兼容老版本parted。还有一点parted的单位可以写MiB、GiB、%等多种形式。用%这种相对方式在不确定磁盘总容量时特别适合比如100%表示剩余全部空间都给这个分区。我写脚本时喜欢用1MiB做起始位置是为了给分区表元数据预留空间避免因为对齐问题导致分区起始位置不对。3.3 分区参数的对齐问题为什么4K对齐必须做对齐这个词听起来抽象但处理不当会明显降低磁盘性能尤其是SSD。现在的磁盘物理扇区基本是4096字节4K但逻辑扇区为了兼容老系统仍然显示512字节。如果分区起始位置没有对齐到4K边界每次IO操作就可能跨物理扇区导致读写放大。我的实用建议是分区起始位置一律从1MiB开始也就是2048个512B扇区的位置。这个位置天然对齐4K因为1MiB是4096的256倍。fdisk默认的起始位置通常也是2048扇区不用额外调整。parted在使用MiB单位时也会自动对齐用GB则可能不对齐这也是我推荐用MiB而不是GB的另一个原因。判断现有分区是否对齐可以用这个命令# 查看分区起始扇区号能被8整除说明对齐了4096字节边界 cat /sys/block/sdb/sdb1/start这个数字除以8如果能整除说明分区已经4K对齐。看不到这个文件的话说明设备没有分区或者驱动不支持不用担心。4. 创建文件系统与挂载从mkfs到mount的完整链路4.1 文件系统选型ext4与xfs怎么选以及硬链接的坑分区建好只是第一步必须在分区上创建文件系统才能往里存文件。Linux下叫格式化实际命令是mkfs。选文件系统类型这事看着简单实际上一旦定下来后面再改成本很高。最常见的两个选择是ext4和xfs。我给的选型建议偏实践追求成熟稳定、兼容性最好选ext4。它支持在线扩容、缩小xfs不支持缩小是CentOS 6时代到现在都稳如老狗的文件系统。处理大文件、大容量存储、高并发写入选xfs。它是CentOS 7之后的默认文件系统对大规模并行IO的优化比ext4好。需要快照、去重、压缩等高级功能的可以看btrfs或者zfs。但这两种在主流发行版里还属于能跑但非默认没有足够经验前我不建议在生产环境直接用。有个最容易被坑的点xfs不能缩小只能扩大。如果你想在xfs分区上做空间回收或缩小不好意思不支持。分区规划时必须一次想清楚或者干脆给足容量。ext4可以缩小但过程也比较麻烦建议同样不要在根分区上随意操作。创建文件系统的命令很简单# 创建一个ext4文件系统 mkfs.ext4 /dev/sdb1 # 创建一个xfs文件系统 mkfs.xfs /dev/sdb14.2 手动挂载与卸载mount命令的核心参数文件系统建好之后第一步是创建挂载点目录然后挂载。挂载点可以理解为Windows里的盘符但更灵活——它只是文件系统树上一个普通目录。# 创建挂载点目录 mkdir -p /data # 手动挂载 mount /dev/sdb1 /data # 验证挂载结果 df -h /data手动挂载的场景是临时测试、紧急扩容之类。mount命令带了很多参数其中生产环境最常用的是这几个# 带noatime挂载减少不必要的元数据写入提高IO性能 mount -o noatime /dev/sdb1 /data # 以只读方式挂载适合排查数据问题 mount -o ro /dev/sdb1 /data # 同时添加多个挂载选项逗号分隔 mount -o noatime,nodiratime /dev/sdb1 /data我特别推荐生产环境用noatime。Linux默认记录atime访问时间每次读文件都要更新这个时间戳对于高并发读场景会产生大量额外写IO。加上noatime后只在创建、修改文件时更新时间戳读操作不再触发写盘对性能有可感知的提升。尤其对数据库、Web静态资源这类读多写少的场景这个优化几乎零成本。卸载用umountumount /data # 如果提示target is busy用lazy卸载方式 umount -l /data4.3 UUID的作用为什么fstab里不直接用设备名分区、格式化完成之后你会遇到一个叫UUID的东西。它是文件系统的唯一标识符每次格式化会随机生成。blkid命令可以查到它。blkid /dev/sdb1输出类似这样/dev/sdb1: UUIDa85b45f0-3a2e-4c7a-9a2d-54d5b8f17015 TYPEext4为什么挂载时推荐用UUID而不是设备名因为设备名会变。比如你插拔了U盘原来/dev/sdc可能变成/dev/sdb系统盘从SATA换到NVMe所有设备名都会重排。但UUID是在格式化时写入文件系统元数据的不管设备名怎么变UUID都不会变。系统开机时按UUID去锁定设备比按设备名可靠得多。有种情况可以绕过UUID系统盘只有一个数据盘且永远不插拔此时设备名很稳定。但这种永远不插拔在服务器运维里根本不存在为了省那点事冒险不划算。5. 开机自动挂载fstab配置与避坑指南5.1 fstab六个字段逐行拆解手动挂载只在当前会话有效重启后就没了。要让分区开机自动挂载必须写入/etc/fstab文件。这是Linux系统里最不能随便改的文件之一写错一行轻则某个分区挂不上重则直接开不了机。/etc/fstab每一行有六个字段分别用空格或Tab分隔我逐字段解释UUIDa85b45f0-3a2e-4c7a-9a2d-54d5b8f17015 /data xfs defaults,noatime 0 2第一个字段是设备标识推荐用UUID。也可以写/dev/sdb1但不推荐理由上面说过了。第二个字段是挂载点必须是已存在的目录。第三个字段是文件系统类型。第四个字段是挂载选项最常用的是defaults它等于rw,suid,dev,exec,auto,nouser,async这组默认参数的集合。如果是SSD加noatime是常规操作理由前面讲过。第五个字段表示是否用dump备份0表示不备份1表示每天备份2表示不定期备份现代系统直接写0即可。第六个字段是开机时fsck检查顺序。根分区/必须写1其他写2或00表示开机不检查写2表示在根分区之后检查。fsck是文件系统检查工具开机时按这个字段顺序依次检查。根分区写1优先级最高其他分区写2不需要检查的写0。写错了可能导致开机卡在文件系统检查阶段。5.2 手把手配置fstab并验证我建议的配置流程是先手动挂载测试确认没问题再写入fstab。不要直接改完fstab就重启那是拿生命赌配置的正确性。# 第一步备份fstab cp /etc/fstab /etc/fstab.bak # 第二步确认设备UUID blkid /dev/sdb1 # 第三步创建挂载点 mkdir -p /data # 第四步把下面这行追加到/etc/fstab末尾 echo UUIDa85b45f0-3a2e-4c7a-9a2d-54d5b8f17015 /data xfs defaults,noatime 0 2 /etc/fstab # 第五步用mount -a验证配置是否正确 mount -a关键一步是第五步的mount -a。这个命令会读取fstab并尝试挂载所有标记为auto的分区。如果执行后没有报错再用df -h确认挂载点有对应空间那基本就稳了。如果报错马上改回备份文件cp /etc/fstab.bak /etc/fstab还有一个小技巧如果fstab里的挂载点路径写错mount -a会给出明确报错但如果不执行这个命令直接重启你可能就卡在系统启动的紧急模式里了。所以mount -a验证这一步绝对不能省。5.3 通过systemd mount unit替代fstab的进阶玩法如果你用的发行版是CentOS 7以上或者Ubuntu 16.04以上可以考虑用systemd原生的mount单位来管理挂载。它的好处是支持依赖关系、自动重挂载、启动失败时更友好的日志输出。systemd挂载单位文件放在/etc/systemd/system/目录下命名规则是挂载点的路径把斜杠换成横杠再加.mount后缀。挂载点/data对应的单位文件名是data.mount。[Unit] DescriptionData Disk Mount Afterlocal-fs.target [Mount] What/dev/sdb1 Where/data Typexfs Optionsdefaults,noatime [Install] WantedBymulti-user.target配置完后启用systemctl daemon-reload systemctl enable --now data.mount如果你觉得fstab老出问题这个方式是现代发行版更推荐的做法。不过现实中fstab仍然是主流因为它简单直观、所有Linux发行版都支持。我的建议是个人实验和学习阶段可以用fstab掌握原理生产环境用systemd单位管理更规范。6. 从原理到实战一次完整的数据盘挂载走读前面五节把原理和命令都拆开了讲这一节我把整个流程从零走一遍模拟一块新数据盘从识别到开机自动挂载的完整过程。这样做的好处是你能看到每个步骤的输入输出长什么样实际操作时心里更有底。环境是这样的一台虚拟机系统盘是/dev/vda新增了一块100GB的数据盘识别为/dev/vdb目标是把它挂载到/data目录用于存放应用数据。第一步确认磁盘信息[rootlocalhost ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 252:0 0 30G 0 disk └─vda1 252:1 0 30G 0 part / vdb 252:16 0 100G 0 disk看到vdb这个100GB的磁盘还没有任何分区状态是原始磁盘。此时绝对不要在系统盘上动刀确认目标设备就是对的那块盘再继续。第二步创建GPT分区表并新建一个分区使用全部空间parted /dev/vdb mklabel gpt parted /dev/vdb mkpart primary 1MiB 100% parted /dev/vdb print示意输出Model: Virtio Block Device (virtblk) Disk /dev/vdb: 107GB Sector size (logical/physical): 512B/4096B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 1049kB 107GB 107GB primary确认分区/dev/vdb1已经建好但目前没有文件系统File system列是空的。第三步创建文件系统mkfs.xfs /dev/vdb1第四步创建挂载点并手动挂载mkdir -p /data mount /dev/vdb1 /data df -h /data第五步写入fstab。先blkid拿到UUID[rootlocalhost ~]# blkid /dev/vdb1 /dev/vdb1: UUID3e9c4f08-c437-4a21-a90f-5b8aade5e3ed TYPExfs然后追加一行到/etc/fstab执行mount -a验证最后视需要用reboot实测开机自动挂载是否生效。完整走下来这一套流程不会超过5分钟。花的时间主要看你有没有手误。慢一点没关系操作前多想一步比操作后补救强太多。7. 常见故障排查从设备忙到系统起不来7.1 卸载提示target is busy怎么定位占用进程这是卸载磁盘时最经典的报错。当一个目录里有进程正在读写文件直接umount必然失败。报错信息简单粗暴target is busy。定位占用的进程用lsof或fuser# 查看哪个进程占用了挂载点 lsof /data # 更直接的方式列出占用挂载点的进程PID fuser -mv /data定位后有两种处理方式如果是实际业务进程等它跑完再卸载如果是可以中断的操作用fuser -k /data强制杀掉进程再卸载。我一般先用lsof确认是什么进程评估杀进程的影响后再动作不盲目用fuser -k。还有一个常见坑当前工作目录在挂载点里也会导致卸载失败。如果你在/data目录里然后执行umount /data提示target is busy你先cd /退出该目录再卸载就行了。7.2 找不到设备或UUID变了blkid和新旧设备冲突场景是这样的换了一块盘或者格式化之后重启fstab里写的UUID对不上了开机报错无法挂载某个分区。排查思路先用blkid看看现有的UUID再对比fstab里的内容。blkid grep -v ^# /etc/fstab如果UUID确实变了更新fstab即可。如果是设备名变了比如U盘从sdb变成了sdc但UUID没变那fstab里用UUID写的配置不影响。这正是我在前面反复强调用UUID的理由——设备名会变UUID不会。还有一种情况新盘插上去后系统原有的设备名被挤到后面去了某些脚本里写死了/dev/sdb就找不到目标分区。这类问题的根治办法只有一个所有涉及持久化引用的地方一律用UUID脚本里也不要写死设备名。7.3 fstab写错导致开机进入emergency mode怎么自救这是fstab故障里最严重的情况。开机时系统尝试挂载fstab里的分区如果报错或者挂载点不存在会直接进入emergency mode紧急模式。这个模式下大部分服务都没有启动但root文件系统通常是可读的可以执行补救操作。关键在于这个模式下文件系统可能是只读挂载的你需要先重新挂载为可写mount -o remount,rw /然后编辑fstab把出问题的那行注释掉或者改正保存后重启。如果你在进紧急模式前做过fstab备份直接恢复备份最省事cp /etc/fstab.bak /etc/fstab还有一种可能系统直接停在grub引导界面连emergency mode都进不去。这通常是分区表层面出了问题比如误操作把整个磁盘分区表删了。这种情况下数据是否还能找回取决于你有没有备份以及是否及时断电停止写入行为——越早停手找回数据的概率越大。这也是我对所有生产环境喊话的原因操作分区、格式化、改fstab之前先备份再操作。7.4 分区扩容根分区空间告急时怎么处理最后一个高频场景根分区满了系统卡顿甚至服务直接挂掉。排查磁盘使用情况df -h如果根分区空间告急有几种应对思路。如果是LVM逻辑卷可以动态扩容这是LVM设计的初衷过程相对顺畅。如果是传统分区且文件系统是ext4可以先扩大分区再resize2fs在线调整文件系统大小但这个过程有风险步骤管理不好容易丢数据。如果是xfs文件系统不能缩小但可以扩大扩大流程是扩大分区用parted或fdisk重建分区表保留起点、改终点然后xfs_growfs扩大文件系统。还有一个长效机制把数据盘独立分区日志目录、容器数据目录通过软链接或挂载指向数据盘。排查告警时把增长最快的目录单独规划出来比反复折腾分区扩容高效得多。我自己管理的机器空间规划上一定会给/留够余量另外给/var和容器数据目录单独划分空间这样后面出问题的概率明显降低。8. 我踩过的几个坑一些不写在文档里的实战心得讲了这么多原理和步骤最后分享几个我实际操作中遇到的教训都是文档里一般不写但非常实用的经验。第一个教训是关于fdisk -l的输出被误读。有些云主机厂商给的数据盘可能已经有分区表但分区大小不是全盘你以为从头分区就能覆盖整个盘结果原有的残留分区信息导致新分区创建异常。拿到新盘第一件事永远先看parted /dev/sdb print确认分区表状态。如果有残留分区且确认不需要直接用parted的mklabel重建分区表这是最干净的清理方式。第二个教训是SSD分区对齐的影响不是立刻体现的而是长时间使用后才慢慢暴露。我有一台数据库服务器分区起始位置是63扇区老式对齐方式初期性能没看出问题跑了一个多月后写入放大明显磁盘寿命急剧消耗。后来把所有SSD都改为1MiB对齐后重建了环境写入延迟和寿命消耗都有了质的改善。如果你管理的机器有SSD一定要用我前面说过的方法检查分区对齐情况。第三个教训是关于系统盘和普通数据盘的操作区分。新人在没有完全确认设备名时就执行了分区操作把系统盘给格式化了这种事故不是个案我遇到过好几次。现在我的铁律是分区、格式化任何一步操作之前用lsblk和df -h双重确认系统盘挂载点必须是一个明确的目录而不是模棱两可的空挂载点。新增磁盘先看容量大小和系统盘做对比确认百分之百正确再动。第四个心得是关于云服务器数据盘挂载。云平台给的独立数据盘在机器重启时设备名可能改变但UUID不变。所以我把所有云主机的fstab全部改成UUID引用设备名只在临时命令里用从不写进任何持久化配置文件里。几年下来即便是迁移到新规格的云主机、磁盘控制器换了导致设备名大变我也没有因为这个原因出过故障。最后一个实用技巧给分区挂载做好命名和注释。我通常会让每个数据盘挂载点有明确用途比如/data/mysql、/data/static而不是笼统的/data。fstab里每一行都加注释写清楚这块盘是做什么的。当你半年后回来看一台没维护过的机器时清晰的注释能救你半条命。总的来说Linux磁盘分区和挂载原理不复杂但坑是真的多。理解分区、格式化、挂载、持久化这四个环节各自的职责把每一步的验证动作做标准大部分故障都可以避免。真遇到问题时不要病急乱投医挨个环节排查问题八成能锁定。最后再强调一遍任何涉及磁盘的操作备份先行确认再三。这是所有运维教训里最贵的一条。