如果你正在啃RH124，或者刚接手一台Linux服务器，第11章“访问Linux文件系统”很可能是你最先背完又最快忘光的一章。mount、umount、df、du、ln，这些命令单看都不难，可真到生产环境里，磁盘满了、目录挂不上、删了文件空间却不释放、开机直接掉进紧急模式，十有八九都是这一章的知识点没吃透。这篇文章我就从目录树结构、挂载原理、空间查看、文件链接和故障排查五个方向，把RH124第11章的核心内容拆开讲一遍，也把我在日常运维里踩过的坑一起交代清楚，给正在备考的人，也给想真正理解Linux文件系统、能自己动手做实验的新手。
1. 先把“文件系统”这个词掰开揉碎
1.1 Linux目录树与FHS：为什么所有磁盘都要“挂”在一个目录上
我第一次从Windows切到Linux时，最不适应的就是没有C盘和D盘。Windows里每个分区都有自己的盘符，打开“我的电脑”能看到C:、D:；Linux完全不同，它只有一棵从根目录/开始延伸的目录树。任何存储设备都不会单独变成一棵新树，而是通过“挂载”这个动作，被放进某个已有的目录里，这个目录就叫挂载点。也就是说，在Linux里“访问某个磁盘里的数据”，本质上是沿着根目录一层层走进去，走到那个被你挂载的位置。
这个设计不是随便拍脑袋定的，背后有一个规范叫FHS（文件系统层次标准）。FHS约定了系统里最重要的那些目录分别干什么：/etc放配置文件，/var放经常变化的数据比如日志和邮件，/home放普通用户的个人目录，/usr放系统软件和程序库，/mnt和/media留给临时挂载的设备。为什么这个约定这么重要？因为运维工作里大部分操作都依赖路径的“确定性”。你写备份脚本时可以直接把日志目录定成/var/log，不会因为换了一台机器、换了一块磁盘而改变；你排查问题时知道配置都在/etc下面，不用满硬盘乱翻。这种确定性就是FHS带来的最大价值。
实际操作中，你可以用ls /看到根目录下有哪些标准目录，再用findmnt /确认根目录所在分区的情况。很多新手容易把“目录”和“文件系统”当成一回事，其实不完全等同：目录是目录树上的节点，文件系统是真正管理数据存储的那一层结构。你进入一个目录，可能正在跨越好几个不同的文件系统，这完全正常。理解了这层关系，后面看df、mount的输出才不会懵。
1.2 /dev目录与设备节点：磁盘在系统里的“门牌号”
在Linux里，磁盘设备不会像Windows那样直接出现在“我的电脑”旁边，而是以“设备文件”的形式集中在/dev目录下。这些设备文件就是设备在系统里的门牌号，程序通过读写它们来和真正的硬件打交道。
命名规则常见的有这几类：较老的SATA、SCSI、USB设备通常叫/dev/sda、/dev/sdb；NVMe固态硬盘是/dev/nvme0n1、/dev/nvme0n1p1；虚拟机里常见的virtio磁盘叫/dev/vda。后面带数字的是分区，不带数字的是整个磁盘。注意，sda不一定代表第一块物理磁盘，它更多是内核发现设备的顺序，这个顺序在系统启动过程中可能发生变化，尤其是有多块相同型号磁盘时，别在写脚本时想当然地把/dev/sda当成“固定的第一块盘”。
想看系统当前有哪些磁盘，最直观的命令是lsblk。它会把磁盘、分区、挂载点之间的关系用树状结构列出来，比如：
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 100G 0 disk ├─sda1 8:1 0 1G 0 part /boot └─sda2 8:2 0 99G 0 part /lsblk -f还能额外显示文件系统类型和UUID。UUID是文件系统的全局唯一标识，后面配置自动挂载时非常重要。查某个分区更详细的信息，可以用blkid /dev/sda1。我第一次知道blkid时觉得这命令很“偏门”，后来才发现它在配置/etc/fstab时几乎是必需品，因为设备名可能变，UUID基本不会变。
2. 挂载是“访问Linux文件系统”的核心操作
2.1 mount命令：把设备接到目录树里
挂载是这一章真正的主角。没有挂载之前，你即使知道/dev/sdb1是一块硬盘分区，也无法直接进入它里面看数据；只有把它挂载到某个目录，文件系统才真正“接入”目录树，变成可访问的状态。最基本的挂载命令是：
sudo mount /dev/sdb1 /mnt/backup这条命令把/dev/sdb1挂到/mnt/backup，执行之后你cd /mnt/backup就能看到这个分区里的内容了。挂载点必须是一个已经存在的目录，最好是空目录。如果挂载点里原本有文件，挂载后这些文件会被临时“遮住”，你看到的是新挂载进来的文件系统内容；卸载后原来的文件才会重新出现。这个特性经常坑人，我后面会专门讲。
不带任何参数的mount命令会列出当前系统所有已挂载的文件系统。输出里能看到设备、挂载点、文件系统类型以及挂载选项，比如rw表示可读写，ro表示只读。生产环境排查时，我第一件事常常就是看mount输出，确认目标目录是不是被挂上了、是什么时候挂的、带没带noexec这类特殊选项。
实际使用中还有几个高频变体：挂载只读用mount -o ro /dev/sdb1 /mnt/backup，挂载ISO镜像文件用mount -o loop xxx.iso /mnt/iso，挂载NFS远程目录用mount -t nfs server:/share /mnt/nfs。新手总喜欢把-t参数写得特别完整，其实系统现在多半能自动识别文件系统类型，不写问题也不大。但挂载NFS这类网络文件系统时，显式指定类型更稳妥，免得识别出错。
2.2 umount与“target is busy”：为什么卸载总失败
有挂就有卸，umount /mnt/backup可以把文件系统从目录树上摘下来。真正干活时，卸载失败的频率远比你想象的高，最常见的报错是：
target is busy.意思是还有进程正在使用这个文件系统。常见原因有两大类：一是某个进程的工作目录在这个挂载点里，比如你刚才cd /mnt/backup忘了切回/；二是某个进程正持有这个目录里的文件，比如日志服务正在写日志，或者有人在这个目录里启动了一个脚本。
排查步骤一般是先确认自己不在挂载点里，执行cd /回到根目录；再用lsof +D /mnt/backup列出占用文件的进程，或者用fuser -mv /mnt/backup查看是什么进程占用了挂载点。看到PID之后，要么正常终止那个进程，要么kill它，然后再卸载。遇到确实无法立刻停止的进程，可以用umount -l /mnt/backup做延迟卸载，系统会在文件系统不再忙碌时自动完成卸载。但我要提醒一句：-l是应急手段，不适合常规使用。它会把文件系统从目录树上“撕”下来，那个目录变得像荒野一样，还在里面读写数据的进程并不知情，一旦有新写入就可能出问题。
2.3 /etc/fstab：开机自动挂载的正确姿势
mount命令只管当前这次开机，重启之后挂载关系就没了。想让文件系统开机自动挂载，要写/etc/fstab。这个文件的每一行对应一个文件系统，一共六个字段：
| 字段 | 含义 | 示例 |
|---|---|---|
| 设备标识 | 通常写UUID，也可以写设备路径 | UUID=3a6f... |
| 挂载点 | 要挂载到的目录 | /mnt/backup |
| 文件系统类型 | ext4、xfs、nfs等 | ext4 |
| 挂载选项 | 多个选项用逗号分隔 | defaults |
| dump标记 | 是否用dump备份，现代系统基本写0 | 0 |
| fsck检查顺序 | 0不检查，1是根文件系统，2是其他 | 2 |
我在实验中看到的典型写法是：
UUID=3a6f2c94-1f9e-4b7e-9d4e-8f0a2b3c4d5e /mnt/backup ext4 defaults 0 2为什么推荐用UUID而不是写/dev/sdb1？因为前面说过，设备名可能变化。比如今天插了一个U盘，原本的/dev/sdb1可能变成/dev/sdc1，系统启动时找不到路径就直接卡住或跳过挂载，数据目录就没了。UUID只跟文件系统本身绑定，更稳定。
每次改完/etc/fstab，我都建议先跑一遍mount -a，让系统尝试挂载所有fstab里的条目。这样做能提前暴露语法错误和设备不存在等问题，而不是等到重启时才在屏幕前后悔。更稳一点，还可以用findmnt --verify /etc/fstab，这个命令会专门检查fstab的正确性。请记住一个惨痛教训：fstab写错会导致系统启动进入emergency mode。别问我为什么知道，问就是我实习时把挂载点写成了一个不存在的目录，结果机房一台测试服务器启动失败，被导师教育了半小时。
3. df与du：空间用在哪，谁能一眼看明白
3.1 df看文件系统空间，df -i看inode
磁盘空间告急是运维里最常见的告警，没有之一。查看空间用得最多的命令是df -h，-h是人友好的单位显示。它会按文件系统维度列出总大小、已用、可用、使用率和挂载点：
Filesystem Size Used Avail Use% Mounted on /dev/sda2 99G 76G 18G 82% / tmpfs 7.8G 1.2M 7.8G 1% /dev/shm输出里会出现不少tmpfs类型的文件系统，它们是内存虚拟出来的临时文件系统，重启后内容会清空。看到/dev/shm比较大别惊慌。真正需要关注的是使用率接近100%的那几行，以及它对应的挂载点是不是你的业务数据目录。
光看空间还不够，Linux还有一种“文件系统满”是inode耗尽。inode可以理解成文件系统中记录文件元数据的小格子，每个文件或目录都要占用一个inode。如果小文件特别多，即使空间还有剩余，inode用完了也一样写不进东西。检查方法是用df -i，看IUse%是不是接近100%。我和同事处理过一次日志服务器故障，df -h显示还剩60%空间，但新文件就是创建不出来，df -i一看IUse%已经99%，清理了一堆历史小文件才恢复。
再看空间时，我个人的习惯是加个-T参数，把文件系统类型也显示出来。因为不同文件系统在后续处理方式上差别很大，比如ext4可以用resize2fs在线扩容，xfs要用xfs_growfs，提前知道类型能少走弯路。
3.2 du找目录里的空间大头
df看的是整个文件系统，想知道具体是哪个目录占用了空间，得用du。最常见的组合是：
du -sh /var/log du -h --max-depth=1 /var/log | sort -h第一条命令看某个目录的总大小，第二条命令把/var/log下第一层子目录的大小列出来，并通过sort -h按大小排序。实际排查时，我一般从业务数据目录的根开始，一层层往里用--max-depth=1看，很快就能定位到是日志文件、数据库文件还是某个临时目录在膨胀。-s是汇总，-h是人友好的单位，--max-depth控制递归深度，这三个参数已经覆盖了90%的使用场景。
有一个细节新手容易忽略：du统计的目录大小并不完全等于你感知到的“所有文件加起来的大小”。它统计的是文件实际占用的磁盘块大小，包含少量文件系统开销。大多数情况下两者接近，不必纠结。
3.3 三个“空间没满却写不进”的经典坑
先说第一个：df显示还有空间，但应用报“No space left on device”。原因上面讲了，很可能是inode耗尽，执行df -i确认。解决办法是清理无用小文件，或者把文件系统迁移到inode数更多的方案上。
第二个：df显示空间不足，但du把所有目录加起来却没那么大。这种看起来“空间凭空消失”的情况，绝大多数是文件已被删除，但还有进程握着这个文件不放手。Linux里删除文件只是解除目录项和inode的关联，只要进程还在写这个inode，磁盘块就一直被占着。定位方法是lsof | grep deleted，找到这类进程后重启它或让它关闭文件，空间才会真正释放。这是我在生产环境遇到频率最高的“幽灵空间”。
第三个：挂载点覆盖导致看不到原目录内容。比如/var原本有一些数据，后来有人在/var上挂载了新分区，那du看/var时只统计新分区的内容，原来的数据被遮住了，空间看起来也变小了。解决方法是卸载后再检查，或者用findmnt确认这个目录是否被其他挂载点遮挡。访问文件系统时，任何目录都可能是挂载点，不能凭感觉判断。
4. 文件类型与链接：ls -l里藏着很多信息
4.1 认识文件类型：开头一个字母就够了
执行ls -l时，权限位前面那个字符是文件类型标识。最常见的-表示普通文件，d是目录，l是符号链接，另外还有b块设备、c字符设备、s套接字、p管道文件。我刚学的时候总以为Linux里“文件”就是普通文件，后来才发现设备文件、管道、socket在Linux里都被抽象成文件，这种“一切皆文件”的设计让很多操作可以统一处理。
日常工作中最影响操作的是普通文件、目录和符号链接。比如写find / -type f可以只找普通文件，find / -type l只找软链接，find / -type d只找目录。备份时如果不小心把socket文件当成普通文件处理，可能在归档时出现意想不到的结果。
想看更详细的元数据，可以用stat命令，它会输出文件的inode号、权限、链接数、属主、大小、修改时间等。每次给面试者讲文件系统，我都会提醒：链接数和inode是两个绑定很深的概念，用stat看一次就能留下直观印象。
4.2 硬链接与软链接：同一个文件可以有多个名字
链接是这一章的难点。先说硬链接：硬链接本质是给同一个inode再增加一个目录项。创建方式ln 原文件 新文件。完成之后，原文件和硬链接文件指向同一个inode，ls -l里的链接数会增加，ls -i看inode号完全相同。修改其中任何一个文件，另一个也会跟着变，因为本身就是同一个文件。
硬链接有几个硬性限制：不能跨文件系统，因为inode只在同一文件系统内有意义；不能对目录创建硬链接，因为这会破坏目录树的环状结构，产生路径循环。
软链接也叫符号链接，创建方式是ln -s 目标 链接名。它像一个快捷方式，里面保存的是目标路径，它有自己的inode，大小等于目标路径字符串长度。原文件删掉后，软链接会变成“悬空链接”，访问会报No such file。软链接没有硬链接那些限制，可以跨文件系统，也可以指向目录，所以使用频率远高于硬链接。
两者的对比我用一个表格收着：
| 比较项 | 硬链接 | 软链接 |
|---|---|---|
| inode | 与原文件相同 | 独立的新inode |
| 删除原文件 | 链接仍可访问内容 | 链接失效 |
| 跨文件系统 | 不支持 | 支持 |
| 指向目录 | 不支持 | 支持 |
| 查看方式 | ls -l链接数增加 | ls -l类型为 l |
| 典型场景 | 文件系统内的去重备份 | 软件版本切换、快捷访问 |
4.3 链接在工作里的真实用法
说一个我自己很常用的场景：部署应用时，我习惯把每个版本放在独立目录里，然后在固定路径下放一个软链接指向当前版本。比如：
/opt/myapp/releases/app-1.2 /opt/myapp/releases/app-1.3 /opt/myapp/current -> releases/app-1.3启动脚本只认/opt/myapp/current，升级时先解压新版本，再改一下软链接指向，回滚时把链接改回旧版本就行。整个过程几乎不停服，而且目录结构清爽。这个思路在Nginx、Java应用的部署脚本里很常见。
硬链接也有实际价值。比如想快速生成一个“看起来像完整拷贝”的目录树，可以用cp -al /data /backup，它会在同一文件系统内用硬链接复制文件。对没修改过的文件来说，几乎不占额外空间；只有某个文件被改动后，两个目录里的内容才会真正分家。这种思路可以当一种简易快照用，但千万别把它当成真正的备份机制，它挡不住文件系统损坏或误删除——硬链接虽然能让同一个数据拥有多个目录项，但如果整个目录被误删，数据一样有风险。
另一点容易踩坑：用文本编辑器修改一个被硬链接的文件，链接关系可能被“偷偷”断开。因为很多编辑器保存时不是直接修改原文件，而是先写临时文件再rename，rename会生成新的inode，原硬链接还指向旧inode，两个名字从此不再是一回事。想保持硬链接关系，修改时要用vim的强制写或者直接在原文件上追加写入，不能走“保存为新文件”的流程。
5. 文件系统故障排查实录：从设备看不见到系统起不来
5.1 设备识别不了，先看dmesg
遇到新插入的磁盘在lsblk里看不到，很多人的第一反应是重启，其实没必要。Linux内核处理硬件事件时，会在内核环形缓冲区里留下记录，用dmesg能看到。我习惯先执行：
dmesg | tail -30看看有没有识别到新的磁盘设备，比如出现sdb、nvme0n1之类的字样。如果设备确实被识别到了但lsblk没显示，可能需要partprobe让内核重新读取分区表；如果dmesg里压根没有这个设备，问题范围就锁定在硬件链路、驱动或者控制器层面了。
现代系统里日志统一交给systemd管理，也可以用journalctl -k查看内核日志，带-f参数可以实时跟踪，插U盘时开一个终端窗口跑这条命令，就能亲眼看到设备从识别到分区加载的完整过程。这个排查思路适用于几乎所有“设备突然消失”的场景，先确认内核到底有没有看到设备，再决定下一步，而不是盲目重启。
5.2 fsck修复：不做足准备别乱敲
文件系统在使用中可能因为异常断电、强制关机、硬件坏道等原因发生损坏。系统启动时发现文件系统有问题，会尝试自动修复；问题严重时则会停在紧急模式，等待管理员手动处理。修复ext4文件系统用fsck，但有几个原则必须遵守。
第一，尽量在文件系统未挂载的状态下执行。在挂载状态下跑fsck，文件系统可能还在写入，检查结果不可靠，甚至造成二次损坏。如果文件系统是根分区且无法卸载，一般建议进入救援模式或用系统安装盘启动后再执行。第二，执行前先确认设备路径没写错，别把数据盘当成日志盘修复。第三，修复前最好先想办法备份关键数据，fsck不是万能的，遇到严重损坏可能丢文件。命令本身不复杂：
sudo umount /dev/sdb1 sudo fsck -y /dev/sdb1-y表示对修复过程中的询问全部回答yes，适合无人值守。注意，xfs文件系统不能用fsck，要用xfs_repair，方向错了命令都执行不了。另一个细节：ext4文件系统如果使用中日志回放异常，有时用fsck -f强制检查才能发现深层问题。
5.3 只读文件系统和紧急模式的处理思路
还有一类故障是文件系统莫名其妙变成只读，mount输出里挂载选项变成了ro。最常见原因是内核在检测到I/O错误后，为了防止数据进一步损坏，主动把文件系统重新挂载为只读。这时候如果不去看原因就直接用mount -o remount,rw /强行改回读写，很可能掩盖底层问题，后续再出故障时数据损坏更严重。
正确做法是先用dmesg查I/O错误，确认是设备问题还是文件系统问题。如果是磁盘硬件故障，应该尽快备份数据、更换设备；如果是文件系统自身报错，则要卸载后检查修复。系统已经处在紧急模式时，控制台会提示文件系统挂载失败或检查失败，这时可以在shell里先mount -a看看fstab里哪些条目挂不上，结合设备名、UUID逐个排查。处理完故障后，reboot之前务必用findmnt确认关键文件系统都挂载成功。
我见过不少新手在这个环节手忙脚乱，其实是把排查顺序搞反了。文件系统相关的故障，最忌讳的就是“不问原因直接修”，务必让日志先说话，再动手。
我个人有个坚持了很多年的习惯：凡是在Linux上做文件系统相关操作，永远先把“当前设备和挂载关系”完整看一遍再动手。具体来说就是先执行lsblk -f和df -hT，确认哪块盘是数据盘、哪个目录是挂载点、文件系统类型是什么，然后才决定怎么挂、怎么查、怎么修。这个看似笨拙的习惯，帮我在生产环境里躲过好几次差点卸载错磁盘、找错故障点的低级失误。RH124第11章里的命令都不难，但把它们组合起来解决真实问题的能力，才是这一章真正想让你带走的。
