Linux磁盘挂载完全指南：从mount到fstab永久挂载与排障

上个月帮人装了一台Ubuntu工作站，新加了一块4TB数据盘，fdisk分区、mkfs格式化、mount挂载，数据拷进去，一切正常。过了两天对方打电话说：“重启之后新盘不见了，数据会不会丢了？”——这是Linux磁盘挂载最常见的尴尬：手动挂载的设备，重启后就“消失”了，因为挂载关系不会自动保持。不是个例，很多从Windows转过来的用户第一次碰到Linux挂载概念时都会懵。

这篇文章我就把Linux磁盘挂载彻底聊透。从最基础的概念讲起，到手把手完成挂载配置，再到fstab永久挂载、NAS网络存储挂载，最后是故障排查和实操习惯。无论你是刚接触Linux的新手，还是被公司服务器“重启掉盘”折磨过的运维，都能从这里找到能直接抄作业的方案。我用的大多是Ubuntu和CentOS上的常见命令，其他发行版也大同小异。

1. 先搞清楚：挂载到底在干什么

1.1 一块新磁盘从插入到“能用”要经历什么

很多人以为磁盘插上就能用，其实在Linux里，一块新盘从物理接入到真正能读写数据，至少要经过四个阶段：设备识别、分区、格式化、挂载。

设备识别是内核发现了这个硬件，给它在/dev目录下生成了一个设备文件；分区是把物理磁盘划分成逻辑区域，相当于给一整块地修隔断墙；格式化是在分区上写入文件系统（ext4、xfs等），相当于给每个隔断里装好货架和登记系统；挂载则是把分区关联到一个目录上，让用户可以通过这个目录访问里面的数据。四个阶段缺一不可，而“挂载”是最后一步，也是最容易被忽略的一步。

反向理解：你先买了一堆书（数据），把书放进书架（磁盘），再把书架搬到书房（挂载）。光有书架不行，得摆到书房里你才能随手拿书。Linux的哲学是“一切皆文件”，磁盘设备本身也是一个文件（如/dev/sdb），但这个文件包含的是底层块设备信息，直接访问它没有任何意义。只有把设备文件“挂”到某个目录（挂载点）上，内核才会把对该目录的读写映射到对应磁盘分区上。

1.2 设备名、文件系统、挂载点——三个绕不开的概念

设备名是Linux给硬件分配的名字，比如SATA硬盘叫/dev/sda、/dev/sdb，NVMe固态硬盘叫/dev/nvme0n1，分区在设备名后面加数字（/dev/sda1、/dev/nvme0n1p1）。名字按识别顺序排，这块盘插得早它就是sda，后插的就是sdb，这也是最坑的地方——重启后盘符可能变。

文件系统是数据在磁盘上的组织格式。Linux原生常见的有ext4（最通用、老牌稳定）、xfs（大数据文件、高吞吐）、btrfs（快照、压缩、COW），交换分区用的swap格式另算。U盘和Windows交换数据常用vfat/exfat或NTFS。选文件系统不能拍脑袋：如果只是普通数据存储，ext4最稳妥；如果是大型媒体库、海量小文件或数据库备份，xfs表现更好；想玩快照和压缩，btrfs值得考虑，但别在没把握的服务器上贸然换btrfs。

挂载点就是一个普通目录，比如/data、/mnt/disk2。理论上任何空目录都能当挂载点，但有几条不成文的规则：不能挂在系统关键目录上（/、/usr、/etc这些），否则会覆盖原有内容；挂载点目录最好单独建立且权限清晰；一个挂载点同一时间只能挂一个设备。

1.3 为什么Linux不像Windows那样自动分配盘符

这是很多新手最大的困惑。Windows里插个U盘，系统自动分配一个E盘、F盘，打开“我的电脑”就能看到。Linux为什么做不到？

本质是Windows和Linux的存储命名空间设计完全不同。Windows是“驱动器独立命名”，每个分区单独叫一个盘符；Linux是“目录树统一命名”，根目录/是起点，所有存储设备都被挂载到/下的某个位置。你看到的一切路径，本质上都是“目录树上的节点”。目录树的起点只有一个，你不能让两块盘同时占领同一个目录。这种设计的好处是极端灵活：可以把多块盘拼成一个逻辑目录树，也可以把网络存储挂到本地目录下，用户根本感觉不到数据存在哪块物理盘上。

代价就是需要一个显式的“挂载”动作来把设备和目录绑定。Linux也提供了一些自动化手段，比如udev规则、udisks、systemd挂载单元，但系统不会在你插上U盘时默认帮你选一个挂载点并永久绑定——它只会在桌面环境下弹个通知，给你一个临时挂载（通常是在/media/用户名/卷标下）。

理解了这些，下面所有的实操就有底了。

2. 手动挂载实操：从零开始让新硬盘“上线”

2.1 第一步：用lsblk和fdisk确认设备状态

拿到一块新盘，先别急着格式化。第一步永远是确认系统到底认没认出这块盘。我最常用的命令是lsblk（list block devices），它会以树状结构列出所有块设备、分区和挂载点。

lsblk

输出大概长这样：

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 465.8G 0 disk ├─sda1 8:1 0 512M 0 part /boot/efi ├─sda2 8:2 0 465.3G 0 part / sdb 8:16 0 3.7T 0 disk └─sdb1 8:17 0 3.7T 0 part /data

看到sdb但下面没有sdb1，说明磁盘没分区；看到sdb1但MOUNTPOINT为空，说明没挂载。如果连sdb都没有，先别慌，接着用fdisk -l查看更底层的设备信息，确认是内核没识别还是驱动有问题。

sudo fdisk -l

fdisk -l输出里会给出磁盘型号、容量、扇区大小等。如果fdisk -l也看不到，那大概率是硬件层面的问题：比如虚拟机忘了添加硬盘、SATA线没插紧、或者磁盘本身没有上电。这时候检查物理连接，在虚拟机里检查“设置->存储”里有没有挂载该磁盘。

确认设备存在后，最好把设备名和容量对应好。我用过一次惨痛教训：机器里原本有一块系统盘sda，又加了一块数据盘sdb，我眼误把sda当成了数据盘，差点格式化掉系统盘。现在做任何操作前必然先lsblk确认三遍。

2.2 分区与格式化：GPT还是MBR？ext4还是xfs？

设备确认无误后，开始分区。现代Linux系统几乎可以无脑选择GPT分区表，除非你要兼容上古32位设备或特定老主板引导需求。MBR只支持2TB以下容量，且最多4个主分区，GPT则支持几乎无限大的容量和分区数，还自带备份头。2TB以上的新盘，必须用GPT。

常用分区工具有fdisk（传统）、parted（脚本友好）、gdisk（专门处理GPT）。我个人的习惯是：交互式操作用fdisk，写脚本用parted，查小问题用gdisk。下面用fdisk给/dev/sdb创建分区：

sudo fdisk /dev/sdb

进入交互界面后依次敲：

• n：新建分区
• p：主分区
• 分区号默认1
• 起始扇区直接回车（默认从第一个可用扇区开始）
• 结束扇区如果只分一个区就回车（默认整块盘）
• w：写入分区表并退出

如果只想分一个区，完全可以跳过分区，直接在整块裸盘上格式化。比如“mkfs.ext4 /dev/sdb”而不是“mkfs.ext4 /dev/sdb1”。但是这样做有个问题：整块盘当一块用，以后想调整分区布局很麻烦；而且某些RAID和备份工具对裸盘支持有差异。我基本总是先分区再格式化，哪怕只分一个区。

分完之后格式化，选文件系统。命令格式是：

sudo mkfs.ext4 /dev/sdb1 # 或者 sudo mkfs.xfs /dev/sdb1 # 或者 sudo mkfs.btrfs /dev/sdb1

mkfs系列会把该分区上的数据全部抹掉，这一步一定要瞪大眼睛确认设备名没写错。执行之前我再补一刀检查：lsblk -f 查看有无文件系统，判断是否真有数据盘被误识别。任何“格式化”操作都不可逆，务必反复确认。

格式化完成后，新分区还不能用，它只是带文件系统的块设备。需要挂载到目录下。

2.3 mount命令挂载与卸载

挂载的核心命令是mount，基本语法：

sudo mkdir /data sudo mount /dev/sdb1 /data

指向的挂载点目录必须存在，否则会报“mount point does not exist”。我更推荐先创建目录再挂载。挂载成功后，用df -h验证：

df -h

检查/data是否出现在列表里，容量、已用、可用是否合理。这时候写入一个测试文件，确认可以正常读写：

echo "test" > /data/test.txt cat /data/test.txt

卸载用umount，注意是要卸载挂载点而不是设备名：

sudo umount /data

也可以umount /dev/sdb1，一样的效果。如果遇到“target is busy”报错，说明有进程正在使用该目录，后面专门讲。

mount还有很多常用参数，使用中按需添加：

• -t：指定文件系统类型，比如mount -t xfs /dev/sdb1 /data，让内核跳过自动探测。多数情况下内核能自动识别，但遇到识别异常时手动指定很管用。
• -o ro：只读挂载。修复文件系统或者保护数据时很常用。
• -o remount,rw：重新挂载，常用于把只读改成读写而不需要卸载再挂载。
• -o noexec：该挂载点禁止执行二进制文件，安全要求高的目录会用到。
• -o uid=xxx,gid=xxx：指定挂载点的属主和属组，对FAT/exFAT这类不支持Linux权限的文件系统格外有用，不然所有文件都归root。

手动挂载的好处是即时生效、随时调整；坏处是重启失效。下面进入正题：怎么让挂载关系持久化。

3. 永久挂载：/etc/fstab的正确打开方式

3.1 fstab六个字段逐项拆解

“永久挂载”的含义不是挂载一次永不消失，而是系统每次启动时自动执行挂载。这个自动挂载的配置文件就是/etc/fstab（file systems table）。文件里的每一行描述一个挂载关系，共六个字段，用空白或Tab分隔：

一个实际例子：

UUID=7f2a3c5e-1b2a-4f6d-9c8e-0a1b2c3d4e5f /data ext4 defaults 0 2

第5、6字段跟自动备份和自检有关，不是特别必要的情况下都设成0和2/0。“dump”现在已经很少用了，直接写0。“fsck”字段：根分区/写1，其他分区写0或2。写1会导致开机自检时串行处理，速度慢；写2让多个分区并行检查。

挂载选项里的defaults代表默认一组参数（rw、suid、dev、exec、auto、nouser、async），平时用defaults就够。想优化性能可以追加noatime，表示不更新文件访问时间，能减少磁盘写操作，对SSD和机械盘都有帮助。老机器上跑数据库还可以加noatime,nodiratime。

3.2 用UUID还是设备名？为什么强烈建议UUID

fstab第一字段最稳妥的写法是UUID=，而不是/dev/sda1这种设备名。原因前面提过：设备名按识别顺序分配，重启后可能变。比如你机器上一块SATA系统盘先被识别成sda，一块NVMe数据盘后识别成nvme0n1；下次启动顺序变一下，NVMe变成了nvme0n1?、数据盘可能变成sdb?，fstab里写的/dev/sda1可能指向了完全不同的分区。轻则挂载失败，重则挂错盘、数据错乱，这是生产事故级别的风险。

UUID是文件系统在格式化时生成的全局唯一标识，只要不重新格式化就不会变。用blkid命令查看设备UUID：

sudo blkid

输出示例：

/dev/sdb1: UUID="7f2a3c5e-1b2a-4f6d-9c8e-0a1b2c3d4e5f" TYPE="ext4" PARTUUID="..."

把UUID填写到fstab里即可。查看完整fstab，然后再用mount -a测试配置正确性：

cat /etc/fstab sudo mount -a

mount -a的作用是重新读取/etc/fstab并挂载所有还没挂载的设备。这是修改fstab之后最重要的验证命令，如果配置有问题，此时就会报错，不会等到重启才发现。

3.3 Ubuntu桌面版如何用图形界面实现“永久挂载”

很多用Ubuntu桌面版的用户喜欢图形化操作。Ubuntu自带的“磁盘”（Disks，包名gnome-disk-utility）就能做永久挂载。步骤很简单：

打开“磁盘”应用，左侧选中目标分区，点击分区下方的齿轮图标，选择“编辑挂载选项”。在弹窗里把“自动挂载选项”开关关掉，此时会出现一堆可配置项：

• “挂载点”填你要的路径，比如/data
• “挂载选项”通常写defaults，或参考命令行里用到的选项
• “识别”方式默认就是UUID，保留即可

保存后它会自动更新系统配置，相当于帮你改了fstab里的对应行。这种图形化方案适合不想碰终端的用户，但我要提醒：它生成的fstab条目和手动配置完全同源，如果UUID写错、挂载点目录不存在，一样会导致开机卡在紧急模式。不要以为图形界面就不会翻车。

Ubuntu桌面版还有一个细节：挂载点时如果你选择挂载到“/media/用户名/xxx”，在桌面的文件管理器里会显示为一个可移动设备，弹出按钮随时可以卸载。想让它像本地目录一样常驻，建议挂载到标准目录下，比如/mnt/data或/data。

3.4 fstab写错的后果与救援手段

fstab写错，最直接的结果是开机自动挂载失败，系统进入emergency mode（急救模式）。如果你配置了nofail选项，系统会跳过错误继续启动，但挂载点可能消失。如何抢救？方法如下：

在急救模式下，文件系统通常已经是只读状态，你先重新挂载根分区为可读写：

mount -o remount,rw /

然后编辑/etc/fstab，把出错的那一行注释掉或者改正：

vi /etc/fstab # 出错行前面加#注释

最后重启。如果系统能正常进入，再用mount -a逐一验证其他条目。急救模式下没有网络，也无法加载图形界面，全靠命令行操作，这也是为什么我反复强调改fstab必须极其谨慎的原因。

避免翻车的最好办法就是不依赖fstab也能恢复：启动时在GRUB菜单按e进入编辑，在内核参数行的ro后面加一个systemd.unit=emergency.target，强制进入急救模式；或者直接在启动参数末尾加single进入单用户模式。这两个技巧平时记住，关键时刻能救命。

4. 挂载NAS和网络存储：NFS与SMB的实操

4.1 NFS挂载：服务端导出与客户端挂载

Linux服务器之间共享存储，最常用的协议是NFS（Network File System）。NFS适合Linux-to-Linux环境，性能好、权限模型一致。

服务端需要安装nfs-kernel-server（Ubuntu）或nfs-utils（CentOS），然后在/etc/exports里定义导出目录：

/data/nfs_share 192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)

一行一个导出项。四个括号里的参数含义分别是：rw允许读写、sync数据同步写盘、no_subtree_check禁用子树检查提高性能、no_root_squash让client的root保留权限（一般不建议，除非互信环境）。

改完exports执行exportfs -ra让配置生效，然后启动服务：

sudo exportfs -ra sudo systemctl enable --now nfs-server

客户端挂载前先确认内核支持NFS：

sudo mount -t nfs 192.168.1.100:/data/nfs_share /mnt/nfs

生产环境一般加版本和参数：

sudo mount -t nfs -o vers=4.2,hard,timeo=600,retrans=2 192.168.1.100:/data/nfs_share /mnt/nfs

hard模式表示NFS挂载点挂死时应用不停重试，不会静默报I/O错误，对数据库这类对数据一致性敏感的应用更安全；soft模式则超时后直接报错，适合可中断场景。

NFS写进fstab时，设备字段可以直接写“主机:路径”，文件系统类型写nfs，挂载选项务必加上_netdev，否则系统可能在网络未就绪时就去挂载NFS导致启动失败：

192.168.1.100:/data/nfs_share /mnt/nfs nfs defaults,_netdev 0 0

4.2 SMB/CIFS挂载：和Windows共享对接

Linux机器挂载Windows共享或NAS的SMB共享，用cifs协议。Ubuntu需要安装cifs-utils包：

sudo apt install cifs-utils

挂载命令需要指定用户名和密码，明文写在命令行容易泄露。更好的做法是使用credentials文件，权限设为600：

mkdir ~/.smbcreds cat > ~/.smbcreds/nas <<EOF username=myuser password=mypass domain=WORKGROUP EOF chmod 600 ~/.smbcreds/nas

然后挂载：

sudo mkdir /mnt/nas sudo mount -t cifs //192.168.1.100/shared /mnt/nas -o credentials=/home/username/.smbcreds/nas,uid=1000,gid=1000,iocharset=utf8

uid和gid决定了挂载后文件的属主，不指定的话默认是root，普通用户进去只能读不能写。iocharset=utf8解决中文文件名乱码。如果对性能有要求可以加vers=3.0或vers=3.1.1，强制使用SMB3协议，避开老旧的SMB1安全漏洞。

fstab里同样要写_netdev：

//192.168.1.100/shared /mnt/nas cifs credentials=/home/username/.smbcreds/nas,uid=1000,gid=1000,iocharset=utf8,_netdev 0 0

4.3 网络挂载必须注意的_netdev选项与断线恢复

前面两次提到_netdev，这个选项专门用在这里：告诉systemd“这是一个网络设备，要等到网络就绪后再挂载”。不写_netdev的话，系统启动时可能还没拿到IP就去挂NAS，结果失败；更糟的是如果fstab里没写nofail，可能导致启动卡住。

强烈建议网络挂载配合nofail使用。fstab的挂载选项里加上nofail，意味着即使网络存储不可达，系统也跳过报错继续正常启动。否则NAS关机维护时你重启Linux服务器，服务器会卡在等待挂载，甚至直接进急救模式。

断线重连是另一个痛点。NFS挂载点断开后，客户端上的进程可能一直阻塞在D状态。SMB相对好一些，但也可能残留僵尸连接。我的经验是：如果业务允许，优先考虑在应用层做重连（比如数据库定期检查连接），而不是依赖操作系统自动恢复；对纯文件共享场景，可以写个systemd定时服务，每分钟检查挂载点是否可写，不可写就umount再mount，但这属于重招，能不用就不用。还有一个系统参数可以缓解：sysctl -w fs.nfs.nfs_congestion_kb=1024，这个调的是NFS拥塞控阈值，非专业人员不建议乱调。

5. 挂载问题排查思路：从现象到根因

5.1 设备压根不出现：从硬件到驱动的检查顺序

插上磁盘却lsblk看不到，这种问题通常不是挂载配置的锅。排查顺序有讲究：

先看硬件层：服务器是否有供电，SATA线/背板插槽是否松动，机箱里的硬盘指示灯是否正常。虚拟机用户检查“设置”里有没有把硬盘挂载到虚拟机上，很多云主机的数据盘要在控制台里单独“挂载”给实例。

再看内核识别：执行sudo dmesg | grep -i sd 或 sudo dmesg | tail -50，查看是否有设备接入日志。出现“new USB disk”“sd 0:0:0:0”之类的字样说明设备已被内核发现。如果是SCSI设备，插拔后系统可能不会自动重新扫描，需要手动触发：

echo "- - -" > /sys/class/scsi_host/host0/scan

三条短横线代表“扫描所有通道、所有目标、所有LUN”。云服务器主机场景和部分虚拟化平台经常需要这一步。

最后看驱动和固件：新硬件可能需要较新内核驱动，比如某些NVMe盘在旧内核下识别不到型号；主板开启了VMD模式导致NVMe盘不出现在标准PCIe枚举里。这种驱动层面的问题，先lspci确认设备有没有出现在PCI总线上，再决定是否升级内核或调整BIOS设置。

5.2 “wrong fs type”：内核没装对文件系统模块

挂载时报错“wrong fs type, bad option, bad superblock on /dev/sdb1”，大概率不是文件系统坏了，而是内核不认识这个类型的文件系统。缺模块的情况以NTFS、XFS、Btrfs、exfat常见。检查当前内核支持哪些文件系统：

cat /proc/filesystems

如果列表里没有xfs，在Ubuntu上安装xfsprogs包：

sudo apt install xfsprogs

安装后再挂载。这类问题本质是用户空间工具包缺失或内核模块未加载，而不是磁盘本身有毛病。还有一个小概率是：格式化时用了不支持的特性（比如ext4的metadata_csum），导致装的内核拒绝挂载。遇到这种情况，先查内核版本，再决定是否加内核启动参数或降级文件系统特性。

5.3 文件系统损坏：fsck修复的时机和方法

挂载时报“bad superblock”或者系统启动时提示“unexpected inconsistency”，说明文件系统受伤了。断电、异常关机、磁盘坏道都是常见诱因。这时候的修复工具是fsck（file system check）。

先卸载分区，务必保证没有进程在读写它：

sudo umount /data sudo fsck -f /dev/sdb1

-f强制检查，即使文件系统标记为“干净”也会扫描。损坏严重时fsck会交互式询问“Fix? yes/no”，可以加-y自动回答yes。修复过程会打印大量“inode xxx”信息，不必逐一理解，重点看最后有没有“XXXX files, XXXX blocks”的正常总结。

如果主超级块损坏，fsck也可能无从下手。ext4文件系统有备份超级块，先查备份位置：

sudo mke2fs -n /dev/sdb1

输出里会列出备用超级块位置，然后用：

sudo e2fsck -b 32768 /dev/sdb1

指定备用超级块修复。xfs对应的工具是xfs_repair，注意xfs不支持在挂载状态下修复，也不建议对RAID逻辑盘盲目执行xfs_repair，先备份再动。fsck需要极谨慎操作，一旦误判可能导致二次破坏，我通常建议先确保有备份或至少确认磁盘没有物理坏道（smartctl -t short可以做个快速检测）。

5.4 权限与安全上下文：SELinux/AppArmor的干扰

挂载本身成功了，但进程写入被拒绝，这种“假挂载问题”也很常见。排查时先用touch测试文件系统本身是否可用，排除磁盘错误后，重点检查强制访问控制。

CentOS/RHEL系列默认开启SELinux，挂载新目录后，如果服务进程没有获得对应的SELinux类型标签，访问会被拒绝，而且/var/log/messages或dmesg里会出现“avc: denied”字样。快速验证：临时把SELinux置为Permissive，看看问题是否消失：

sudo setenforce 0 # 测试，确认后恢复 sudo setenforce 1

如果确认是SELinux的问题，用semanage fcontext给新挂载目录设置正确的上下文：

sudo semanage fcontext -a -t httpd_sys_content_t "/data(/.*)?" sudo restorecon -Rv /data

Ubuntu/Debian系用的AppArmor类似，但对于本地目录挂载影响较少，更多体现在服务自定义配置上。

权限排查还有一个高频点：挂载点目录本身的权限。比如fstab配了/dev/sdb1挂到/data，但/data目录的属主是root，普通用户自然写不进去。mount不会改写挂载点目录的原属性，挂载前后df -h和ls -ld /data对比一下就能确认。网络挂载里特别容易遇到，我见过太多人SMB挂半天说写不了，最后发现是本地挂载点目录权限不对。

6. 几个值得长期养成的挂载操作习惯

6.1 卸载前先确认没有进程占用

umount报“target is busy”时，别直接umount -l（懒卸载），那会把进程底层的文件系统瞬间抽走，后续写入全部丢，还可能让内核报I/O错误。正确流程是先找出占用进程再决定：

sudo lsof /data # 或者 sudo fuser -vm /data

lsof列出占用目录的进程PID和命令名。能停进程就停进程，停不了就fuser -k /data提醒用户退出。实在需要立即卸载且确认业务可中断，才考虑umount -l，而且事后要尽快重新挂载并检查数据完整性。

6.2 用mount -a验证fstab后再重启

每次改完fstab，先跑mount -a，再重启系统。mount -a会把fstab中所有“auto”且尚未挂载的条目挂载一遍，有错当场就报。养成这个习惯，能让你99%的fstab事故在重启前暴露。

顺带一个技巧：用findmnt验证挂载结果。

findmnt /data

这个命令输出挂载源、挂载点、文件系统类型和选项，比“lsblk后看挂载点”更直观。findmnt还能验证某个设备是否被挂载以及挂载选项是否符合预期。排查fstab问题时，findmnt -f /etc/fstab会在未生效的配置和实际挂载之间做对比。

6.3 bind mount、remount这些实用的挂载变体

bind mount（绑定挂载）是我很常用的技巧。它把一个目录树“绑定”到另一个目录，实现同一份数据多个入口访问：

sudo mount --bind /data/nginx/html /srv/nginx/html

这条命令让/srv/nginx/html和/data/nginx/html访问到完全相同的文件。应用场景很多：服务配置里写死了路径、需要把某个子目录单独暴露给容器、跨命名空间共享文件。bind mount同样可以在fstab里持久化，写法：

/data/nginx/html /srv/nginx/html none bind 0 0

remount则用于在不卸载的情况下改变挂载选项：

sudo mount -o remount,rw /data

这个在把只读文件系统切回读写、或者临时加noatime参数时非常方便。注意remount改的是整个挂载点选项，不是某个文件。

6.4 定期检查文件系统健康与磁盘空间

挂载配置好之后，别以为就一劳永逸了。我习惯写一个定期巡检：每周用smartctl检查硬盘健康状态，重点看Reallocated_Sector_Ct和Pending_Sector这个两个RAW值，一旦出现非零就需要警惕介质老化；每天用df -h看挂载点剩余空间，监控文件系统是否进入只读状态（这往往是最早的硬件故障信号）。

df -h /data sudo smartctl -H /dev/sdb1

许多服务器故障真相是：文件系统先报错，挂载点悄悄退化成只读，应用层开始报磁盘写失败，然后才是告警。不要等到告警才被动排查，定期看一眼能让绝大多数问题消弭于无形。

我自己的习惯是每次做完磁盘挂载，操作无误后一定reboot一次再验证一遍。因为fstab里的错误只有重启才会完整暴露，“mount -a测试过”和“重启能正常进系统”是两回事。麻烦一点，但心里踏实。

这块内容虽然基础，却是Linux运维里最常见的翻车点。我见过不少资深开发在挂载这上面栽跟头——不是不懂命令，而是把设备名写进了fstab、网络挂载忘了_netdev、格式化命令手滑指错盘。希望这篇文章能帮你把这些坑都提前避开，至少，下次有人问“为什么重启后我的硬盘不见了”，你能笑着回一句：“看看fstab。”