1. 一切从VFS说起:Linux如何用一套接口包住所有存储1.1 为什么需要一层虚拟文件系统先聊一个反直觉的事实:Linux里头文件的操作方式,和你以为的读到磁盘、写回磁盘其实隔了好几层。你执行cat /etc/os-release的时候,内核并不知道fopen、read这些函数最终会落在ext4还是XFS上,它甚至不知道目标文件到底在本地磁盘还是在远程NFS服务器上。全靠一层名为VFS的抽象层把所有人骗得服服帖帖。VFS,Virtual File System,虚拟文件系统。它定义了一套统一的数据结构和操作接口,内核里所有与文件相关的逻辑只跟接口打交道,不关心底层具体实现。用户态调用open、read,进入内核后优先走到VFS层,VFS再去调度具体文件系统注册的操作函数。这就像电源插座:电器只需要认得两孔三孔的插头规格,至于电是从火电、水电还是风电来的,电器不关心,换电站也不关心。这套设计的历史原因很简单。当年Unix生态里有各种存储设备,磁带、软盘、硬盘、网络存储,每种设备的读写方式截然不同,如果每个应用都要针对每种设备写一套逻辑,代码早就爆炸了。Linux从Unix沿袭这个理念,把所有能装东西的东西都抽象成文件。搞懂VFS之后,很多以前觉得玄乎的问题就有了答案。比如/tmp下面挂了一个tmpfs内存文件系统,你写进去的东西断电就没了,可是你编辑文件用的API和写磁盘完全一样。再比如/proc/cpuinfo,你cat它的时候,内核其实正在现场收集CPU信息拼成一个临时文件给你,根本没有真实文件存在磁盘上。这些操作全靠VFS把读文件这件事统一成从某个文件系统实例里获取数据,至于数据怎么来,那是具体文件系统自己要去解决的问题。1.2 从系统调用到磁盘扇区的完整路径我简单画一条数据流路径,方便你把整个体系串起来:应用程序调用 open() → C标准库 → 系统调用入口 → VFS层 → 具体文件系统(ext4/xfs/btrfs) → 块设备层(page cache / io调度) → 设备驱动 → 磁盘扇区每一步看着简单,实际每一层都有自己的缓存、并发控制和错误处理。常见的一个误区是认为VFS就是内核里的一个大switch,根据文件系统类型分发请求。其实VFS维护的是一组函数指针表,每个挂载的文件系统实例都会注册自己的操作集,比如.readlink、.iterate_shared、.getattr,VFS把这些操作包成了公共接口。比如你ln -s创建一个软链接,在VFS看来,这个链接本身是一个inode,它的数据内容就是一个路径字符串。你访问链接时,VFS调用具体文件系统的.readlink操作把字符串读出来,再解析成目标路径发起下一次查找。软链接可以跨文件系统、可以指向不存在的目标,就是因为这个操作本质上只是读一个存着字符串的文件。PATH查找也是VFS的重头戏。当你输入ls /usr/local/bin时,内核从根目录的dentry开始,按/分隔逐级往下找。每一级都在当前目录的dentry缓存里查名字,查到就获得下一级目录的inode。这个过程涉及dcache,目录项缓存,它是VFS层非常重要的性能来源。热目录的操作快,很大程度不是磁盘快,而是dcache命中了。1.3 挂载怎么把两个文件系统粘成一个树挂载这件事,本质是让一个文件系统的根目录,嫁接到另一个文件系统某个目录的dentry上去。你mount一个设备到/mnt/data,系统会读取设备的超级块,初始化文件系统实例,然后把这个实例的根inode和/mnt/data这个目录建立起映射关系。之后你访问/mnt/data/foo,内核在路径查找时走到/mnt/data,发现它是个挂载点,就跳转到底下那个文件系统的根目录继续往下查。有个隐含行为值得注意:挂载点目录原本有内容的话,挂载之后这些内容会被隐藏,不是被删除,只是暂时不可见。等你umount之后,原来的内容又回来了。很多新手在这上面踩过坑,把数据写进/mnt/data然后挂载了个新盘,发现原来的文件全部消失,以为数据丢了,其实只是被盖住了。这个特性在实际运维中有用,比如你想给某个目录换存储后端,可以先用新盘挂上去,数据迁移完成后再改挂载路径,中间不会出现目录空洞。VFS这么一层包下来的结果,就是Linux支持的存储形态非常杂。本地ext4、网络NFS、堆叠的overlayfs、内存tmpfs,在用户看来全是目录和文件。做运维和开发的人,应该把VFS这一层当成理解后面所有问题的总纲:文件系统损坏、挂载失败、性能瓶颈,很多根因都能回溯到VFS和具体文件系统交互的边界上。2. 磁盘上那些看不见的元数据:inode、超级块与日志机制2.1 inode里到底存了什么文件系统格式化的时候,会划分出一片区域叫inode表,每个inode固定大小,存放一个文件或目录的元数据。inode里保存的是文件类型、权限位、属主属组、时间戳、文件大小、数据块指针,对应关系简单说就是:文件名活在目录项里,文件本身活在inode里。这里有个经典考点:目录到底是什么?目录也是一个inode,它的数据块存放的是一堆文件名-inode号码的映射记录。所以一个目录需要可执行权限才能进入,是因为内核需要读这个目录的数据块来解析下级名字,没有x权限就禁止这些操作。读目录内容是r权限,创建新文件需要w权限,这些都是基于目录的数据组织方式推出来的。inode里的数据块指针决定了文件大小上限。ext4采用多级间接块加extent映射,单个文件最大可以到16TB左右,XFS则可以支持到8EB级别的理论上限。实战中很少真的遇到单文件大小撞上限,但遇到海量小文件场景时,inode耗尽比磁盘满更常见。格式化时可以指定-i参数控制inode数量,比如存储大量几KB级的小文件,可以把inode密度调高,否则磁盘还有几十GB空闲,却报no space left on device,查看df -i才看到inode已经满了。2.2 日志(journal)是如何截停半截写操作崩溃一致性,是文件系统设计里最棘手的环节之一。假设你在写一个文件,写到一半断电,磁盘上可能同时存在一个新版本的数据块和一份旧的inode信息,重启之后文件可能指向错误的数据块,甚至出现数据块被多个文件占用的严重问题。悲观的做法是每次写入都做全量一致性检查,代价大到不可接受。实际主流文件系统采用的是日志(journaling)机制:写数据之前,先把本次操作要修改的元数据变更记录到日志区,日志落盘之后再执行真正的写操作。系统崩溃重启后,内核检查日志区,如果有未完成的事务,就根据日志内容重新执行或回滚,保证元数据一致性。ext4默认使用ordered模式,意思是日志只记录元数据,但保证在元数据提交之前,关联的数据块已经先写进磁盘。这样即使崩溃,文件的内容不会指向垃圾数据,可能损失的只是文件已写但元数据未更新的那一部分。想要更强的一致性可以选择datajournal模式,数据和元数据都进日志,但性能损耗很大,平时没必要开。生产服务器上多数场景用ordered就够了。日志机制也有坑。日志要占固定大小的空间,格式化时默认会预留一定比例,mkfs.ext4时可以用-J size64M调整。日志区如果损坏,文件系统往往直接拒绝挂载,服务端加固时要注意把日志放在稳定存储上,别放在容易坏的那块盘上,否则日志坏了整盘数据恢复的成本会非常高。2.3 硬链接为什么不能跨分区硬链接的本质,是在某个目录里创建一个新文件名,指向一个已存在的inode号,同时这个inode的链接计数加一。因为这个操作没有创建新inode,只是给旧inode加了个门牌号,所以硬链接不能跨分区——不同文件系统的inode编号是各自独立的,一个inode号在另一块盘上没有任何意义。软链接没有这个限制,因为它本身就是一个独立的inode,内容只存了个路径字符串。链接计数在文件系统里还和文件被删除这件事直接相关。unlink一个文件,内核实际做的是删除目录项并递减链接计数,只有当计数归零时才真正释放inode和数据块。这也是为什么一个进程打开了某个日志文件,运维在外部用rm删掉了它,磁盘空间却迟迟不释放——inode还没被释放,因为进程的引用还在。处理这种场景的正确姿势是找到占用的进程,重启它或者让它重新打开文件,空间才会真正腾出来。3. 主流文件系统选型对比:ext4、XFS、Btrfs、f2fs3.1 ext4:默认但不等于平庸大多数Linux发行版装完系统,根分区就是ext4。网上时不时看到ext4太老应该换XFS之类的说法,客观讲,ext4最大的优势不是性能最强,而是成熟度极高,文档案例多,修复工具链完善,遇到问题能找到人问。它支持extent树管理连续块,支持延迟分配,配合SSD和机械盘都有不错的表现。格式化和调优方面,ext4有个很实用的特性:tune2fs -O ^has_journal可以关闭日志换取极端情况下的性能,但代价是崩溃后自恢复能力大幅下降,不建议对重要数据使用。日常做测试环境漂移时,倒是可以这么搞。resize2fs支持在线扩容,云盘扩容后执行一条命令就能让文件系统吃满新空间,做运维的应该都熟——前提是分区要先扩容,文件系统和分区两层都要到位。3.2 XFS:大文件和高并发的场景XFS在设计上从一开始就瞄准大容量和高并发,采用分配组(AG)机制让多个CPU可以并行操作不同的AG区域,避免全局锁竞争。在做大文件顺序读写、多线程并发写入的场景下,XFS的优势比较明显。我的经验是,存储媒体文件、备份数据、大型数据库的数据目录,用XFS往往比ext4能拿到更稳定的吞吐。XFS有个点容易踩坑:它不支持 shrink,也就是无法在线缩容。开头分区的时候就要想清楚,别指望后续改小。另外XFS在文件系统满的情况下,某些操作的表现比较倔,比如想删除文件腾空间,有时候会因为元数据预留空间不足导致死锁,触发no space left, couldnt create log之类的问题。解决办法是平时保留5%左右的空闲空间,别把XFS塞得100%满。3.3 Btrfs的COW机制与快照能力Btrfs是Linux上少有的原生支持写时复制(COW)的文件系统,修改文件时不是在原位置覆盖数据,而是先写新副本,再更新元数据引用。这种机制带来一个很好的副产品:内置子卷和快照。你用btrfs subvolume snapshot创建的快照是瞬间完成的,占用的空间只记录差异块,做系统升级前的回滚保险非常方便。快照不是免费的。大量频繁更新数据的场景下,COW会导致文件碎片增多,而且快照链表越长,后续的清理工作越复杂。在数据库这类有大量随机改写的负载上,需要仔细评估是否值得使用Btrfs,很多生产实践建议配合nodatacow挂载选项来规避。总的来说,Btrfs适合那些需要频繁做快照、熟悉它工具链的人,不适合拿来当无脑默认盘。3.4 面向闪存时代的f2fsf2fs是三星为NAND闪存专门设计的文件系统,以Flash Friendly Filesystem的缩写命名。它在布局上把整个卷当成连续的日志结构来管理,有效减少随机写,降低写放大,还针对SSD的GC机制做了适配。如果你的设备是eMMC、SD卡或者低端SSD,并且内核版本较新,可以考虑用f2fs做数据分区。f2fs在实际落地时,需要用户态工具支持,内核模块也要开启。它不支持的特性也不少,比如没有成熟的在线扩容工具,快照能力弱,acl支持不完整。做嵌入式设备固件时,用f2fs的场景不少;通用服务器上目前还是少数派。选型时建议先跑一轮fio测试对比自己真实负载,别只看理论参数。文件系统最大文件日志/COW快照在线扩容适合场景ext416TB日志不支持支持通用默认盘XFS8EB级日志不支持支持(不可缩)大文件、高并发Btrfs极大COW支持支持快照需求、开发环境f2fs中等日志结构弱弱SSD/eMMC、嵌入式选文件系统不是选最好,是选最适合自己负载的。我的建议是:通用服务器默认ext4,不会有大错;明确的大文件高并发场景考虑XFS;需要频繁快照做试验,可以单划分一块区专门给Btrfs;嵌入式或者对闪存寿命敏感,研究一下f2fs。4. 挂载、fstab与系统启动时的文件系统就绪4.1 挂载点的本质是把目录变成入口前面提到挂载是嫁接两个文件系统,实操中围绕mount命令本身的细节也不少。mount -t ext4 /dev/sdb1 /data只是最基础用法,生产环境更常用的是带选项挂载,比如mount -o rw,noatime,nodev,nosuid。关键在于每个选项都有实际影响。常见的挂载选项有这么几个值得花时间理解:noatime:不更新文件访问时间。访问时间这个元数据对大多数应用完全没价值,但每次读文件都要更新它会产生额外写盘,机械盘和SSD都受影响。服务器上开noatime基本无损。nodiratime:只关闭目录访问时间更新,相比noatime保守一点。relatime:相对atime,当原访问时间早于修改时间或超过一天时才更新,是不少发行版的默认值,兼顾了部分需要atime的场景。nodev/nosuid/nosymfollow:用于限制特殊文件操作,加固挂载点,防止挂载目录下出现设备节点和setuid程序。做容器或共享目录时几乎必开。这些选项写进mount命令行只能影响本次挂载,重启就丢,所以要持久化必须写到/etc/fstab。fstab的每一行格式是设备 挂载点 文件系统类型 选项 dump pass,其中大家最迷惑的是最后两列。dump列现在基本不用,写0即可;pass列控制开机自检顺序,根分区写1,其他写0或2。如果误把pass写错,开机时fsck会在各分区之间来回跳,浪费时间还容易出问题。4.2 fstab配置的实战坑fstab最容易被从业人员忽视的一件事是:写在里面的设备名最好别用/dev/sdX这种易变的名字,改用UUID或者PARTUUID。因为Linux在每次启动时,设备发现顺序不一定稳定,尤其是有多块盘、多个USB设备的环境,/dev/sda今天可能是U盘明天可能是系统盘。blkid可以查看分区的UUID,PARTUUID则可以唯一标识分区表里的某个分区,比UUID更稳定。fstab还有一种常见写法是用文件系统标签,LABELdata或PARTLABELdata,这要求你在格式化时设置好标签。好处是肉眼可读,挂载时系统根据标签找到对应设备,但标签全局必须是唯一的,否则可能挂错盘,风险比UUID更大。写fstab之前务必先手动mount验证一下设备能正常挂载。老手也会犯一个错误:fstab写错了一个条目,开机时系统因为找不到设备或者校验失败,直接进入emergency mode,这时候你连终端都要登录进去才能改文件。我常用的稳妥流程是:先mount测试,再编辑fstab,然后执行mount -a验证所有条目无误。如果已经故障启动卡住,可以输入root密码后用mount -o remount,rw /把根目录重新挂成可写,再去修改fstab。4.3 systemd如何处理文件系统依赖现代Linux发行版都用systemd管理服务,文件系统挂载也被纳入systemd的unit体系。每个fstab条目会被自动转换成systemd的.mount单元,单元名由挂载点路径加.mount后缀组成,比如/data对应的单元就是data.mount。systemd负责保证依赖顺序:根文件系统先就绪,才能启动基本服务,然后才能挂载其他分区。理解这一点对排查启动问题很有帮助。如果一个网络文件系统NFS写在fstab里,但网络还没就绪,systemd会等待网络服务启动完成后才尝试挂载。配置里可以加_netdev选项,明确告诉系统这是一个网络设备,需要在网络就绪后再挂载。不加的话,有的环境会碰到挂载卡在启动阶段,服务依赖链互相等待的情况。systemd还提供了x-systemd.automount这个挂载选项,支持按需挂载。配置了它,目录初始不存在,但内核预留了dentry,等你第一次访问该目录时才真正触发挂载。这对那些只是偶尔用一下的备份盘、数据盘是很好的方案——开机启动不挂载,不产生额外IO,等真去访问了才挂上。这个功能传统fstab是做不到的,是systemd给文件系统管理带来的很实在的好处。5. 与文件系统共存的特殊文件系统:/proc、/sysfs、tmpfs5.1 /proc不是磁盘文件在linux里执行ps、cat /proc/meminfo,这些信息都是从/proc文件系统读取的。procfs不是一个存在于磁盘上的真实目录,它是VFS家族里一类特殊的伪文件系统,数据由内核在读取时实时生成。你看到的每一个proc文件,背后都对应一个内核数据结构的实时视图。比如/proc/$pid/status里的内存信息,当你cat的时候,内核会去查找对应进程的task_struct,现查现组装成文本返回。/proc对排查问题极其重要。遇到CPU占用高,查看/proc/$pid/stat里的utime和stime可以区分用户态还是内核态消耗;遇到内存告警,看/proc/meminfo里的Dirty和Writeback可以推断有多少脏页等待写盘;看/proc/interrupts可以分析中断是否倾斜到某个CPU。这个目录不是拿来当摆设的,它是内核监控数据的宝库。/proc有一个目录叫/proc/sys,下面是可以调的内核参数,比如/proc/sys/vm/swappiness、/proc/sys/net/ipv4/ip_forward。直接写这些文件能临时生效,需要用sysctl命令持久化。内核文档里很多优化建议都会落到这个目录,掌握它的结构等于掌握了一台机器的底层调控面板。5.2 /sysfs与设备模型/sys目录下的内容是sysfs,它由设备模型驱动,把内核里的设备和驱动以目录层次结构呈现出来。和proc不同,sysfs更关注设备树和属性,比如CPU连续热插拔、块设备的队列参数、电源管理都在/sys下面能改。/sys/block/sda/queue/scheduler可以查看和修改I/O调度器;/sys/class/net/eth0/statistics/rx_bytes能直接读到网卡收包字节数,在监控脚本里经常被调用。sysfs里写参数要当心,有些属性是只读的,有些写入需要特定格式,随兴改可能导致设备状态异常。做性能调优时,一个常见的做法是在启动脚本里统一设置/sys/block/*/queue/nr_requests和read_ahead_kb,这些参数在fstab里管不到,必须在系统启动后另想办法应用,规则容易记混。5.3 tmpfs与内存盘的正确用法tmpfs是一种全驻留在内存的文件系统,支持在内存和swap之间换页。它的挂载点最常见就是/tmp和/dev/shm。tmpfs的好处是读写极快,坏处是断电数据消失,而且占用的内存会计入系统内存使用量,不设置上限能把整台机器撑爆。使用tmpfs需要规划。比如构建服务器把编译中间目录放在tmpfs上可以显著加快构建速度,但源码和产物落盘之前一定要确保有机制同步到持久存储。很多CI环境跑完就销毁,tmpfs正好符合需求。另一个典型场景是容器里挂tmpfs做临时数据隔离,既提升性能又避免容器间数据互相蹭。/dev/shm默认大小是物理内存的一半,太大会造成内存浪费。可以用mount -o remount,size2G /dev/shm调整。注意tmpfs挂载选项里size不仅限制总容量,写满之后文件系统会报ENOSPC,即便系统还有空闲内存也不会自动增长。设计时要把峰值写入量预留出来。6. 实战搭NFS:把本地文件系统共享到网络6.1 服务端配置与exports语法解析NFS是Linux环境里最常见的网络文件系统之一。它的原理是把服务器上某个已挂载的文件系统导出给客户端,客户端通过VFS把它挂到本地目录,对上层应用完全透明。搭建NFS的流程不复杂,但细节决定成败。服务端需要安装nfs-kernel-server或nfs-utils包,然后编辑/etc/exports。每一行的基本格式是导出的目录 允许访问的主机(选项)。例如:/data/nfsshare 192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)这里几个选项要逐一说清:rw:客户端可读写。只读场景用ro更安全。sync:同步写,服务器收到写请求后先落盘再应答。这个选项保证数据可靠性,虽然会牺牲一点性能,但强烈推荐默认开启。async模式性能好,一旦服务器异常重启,客户端可能感知不到写入已丢失。no_subtree_check:关闭子树检查。导出目录的子目录存在重命名时,子树检查会产生额外开销,甚至导致奇怪的问题。不涉及子目录细粒度导出时,建议加上这个选项。root_squash:默认选项,把客户端root映射成nobody。如果你需要客户端以root身份直接操作,需要显式no_root_squash,但这等于把服务器写权限和root权限都交给客户端,安全隐患明显,只在受信任内网才考虑。配置后执行exportfs -arv让规则生效,exportfs -v查看当前导出列表。别忘了服务端防火墙要放行nfs相关端口,常用的是2049端口,另外rpcbind也依赖111端口。6.2 客户端挂载与性能选项客户端操作相对简单,先确保安装nfs-common包,然后:mount -t nfs 192.168.1.10:/data/nfsshare /mnt/nfs更推荐用mount -t nfs4走NFSv4协议,它整合了端口、带认证机制,防火墙配置也更方便。NFSv4默认走2049端口,服务端开启rpc.mountd的端口固定设置后,防火墙规则写起来简单很多。挂载选项里,rsize和wsize决定一次RPC读写的数据块大小,默认值通常已经合适,但跨网络时可能因为路径MTU问题导致包分片,表现是读写性能断崖式下跌。调低到8192或4096往往能解决。hard和soft决定服务器无响应时客户端表现:hard会无限重试,进程可能长时间卡住;soft超过重试次数会返回错误,应用会收到IO错误。多数生产环境用hard加intr允许信号中断,避免NFS卡死后连kill都无效。NFS客户端也是靠着VFS的无差别隐藏,才能让应用程序以普通文件方式访问远程共享。你在同一台机器上挂载多个NFS共享,再混合本地磁盘目录使用,用户完全感知不到数据分布在哪里。这对需要横向扩容的存储迁移场景很友好:先让新文件系统接管目录,再把数据逐步搬过去,整个过程对用户透明。6.3 NFS排错三板斧NFS出问题时先看三件事。第一,showmount -e 服务器IP能否列出导出列表,列不出来说明rpcbind或exportfs配置有问题。第二,客户端dmesg里有没有NFS: server ... not responding之类的记录,有的话多半是网络丢包或服务器卡顿。第三,服务端日志在/var/log/messages或syslog里,重点搜rpc.mountd、nfsd相关内容。一个比较容易忽略的坑是服务端导出的目录所在文件系统处于只读或者繁忙状态,客户端挂载后能看到目录但无法创建文件。排查时先看服务端exports -v和df -h,确认导出目录本身没问题。另一个常见问题是身份映射,NFSv3依赖uid/gid数字匹配,客户端和服务端用户uid不一致就会出现文件owner全是nobody的现象。NFSv4支持idmapd配置来映射,但配置不对反而更乱,小型环境最简单粗暴的做法是保证uid一致。7. 文件系统损坏、fsck与救援操作7.1 常见错误信息的真实含义文件系统损坏时的报错五花八门,但仔细观察,很多都指向同一批根因。挂载时报wrong fs type, bad option, bad superblock,首先怀疑超级块读不出来;报Input/output error伴随dmesg的EXT4-fs error,说明已经在运行时检测到文件系统不一致,继续写入可能扩大损害。系统启动直接掉进紧急模式,大概率是fstab对应分区mount失败,或者根分区校验失败。说一个我踩过的具体例子。一台服务器突然重启后无法进入系统,启动日志显示superblock last mount time is in the future,这是因为系统时间乱了,文件系统认为最后一次挂载时间在未来,出于防止旧副本挂载覆盖数据的考虑拒绝挂载。修复办法是加-o ro强制只读挂载,用dumpe2fs查看超级块,必要时清掉错误标志。这类问题说明了时间同步在文件系统层面也有影响,NTP出问题的服务器,文件系统可能跟着闹脾气。7.2 fsck的正确打开方式fsck是文件系统一致性检查工具。它的原理是遍历磁盘上的元数据,校验inode、目录项、块位图是否自洽,发现不一致就尝试修复。重点提醒:fsck应该在文件系统未挂载或只读挂载的状态下运行,绝不能对一个已挂载的读写分区执行fsck,否则会破坏正在使用的文件结构,越修越坏。常见的执行方式是:umount /dev/sdb1 fsck -y /dev/sdb1-y选项表示对所有交互问题自动回答yes,适合无人值守修复。但自动应答有时候会把还能保留的数据直接删掉,更稳妥的做法是不加-y,逐条看提示,或者先用fsck -n做只读检查,了解问题规模之后再做决定。fsck的运行时间跟分区大小和文件数量强相关,一个TB级的分区跑fsck可能需要几小时,生产环境要有心理预期。这也是日志文件系统存在的原因之一——正常情况下系统崩溃后,只要日志能正常回放,检查速度会快很多,不需要全盘扫描。如果你的服务器经常意外断电,却在重启后看到fsck长时间运行,多半是日志本身出了问题,这时候要关注磁盘健康状态,别再归咎于系统检查慢。7.3 磁盘救援的整体思路文件系统出问题,切忌一上来就狂跑fsck。我的思路是分步走:先确认盘是否还健康,再看是软件问题还是硬件问题。第一步用smartctl查SMART数据,重点看Reallocated_Sector_Ct和Pending_Sector,数值异常说明物理坏道已出现,这时候fsck只能救得了一时的数据结构,盘该换还是要换。第二步用dd或ddrescue做全盘镜像。意识是先把原始数据原封不动复制到另一块盘或文件里,后续所有修复操作都在镜像上进行,原始盘不再动,尽量保住原始数据。ddrescue比dd更智能,遇到读错误会跳过并在后续重试,是救援场景下更靠谱的选择。第三步才是fsck或testdisk这类工具去修复镜像。testdisk的强项是重建分区表、恢复被误删的分区和引导扇区;fsck负责修文件系统内部逻辑。两者配合起来,数据恢复的成功率会高很多。还有一个现实经验:犯错停手比慌乱操作更重要。做运维这行,磁盘坏掉的瞬间,第一反应应该是停止所有自动挂载、停止一切可能写盘的操作,保住现场,信息永远比冲动有价值。8. 从跟文件系统相关的性能观测说起8.1 用iostat和blktrace找到瓶颈在哪里当你怀疑文件系统拖慢业务时,别急着改挂载参数,先看证据。iostat -x 1能按设备输出利用率、IOPS、平均IO大小、await等指标。如果%util长期接近100%,说明设备已经饱和,这时优化文件系统层次的意义不大,先考虑换盘、加盘或者调低写放大。如果%util不高但业务延迟高,问题可能出在应用层锁竞争或者调度器排队,而不是盘跟不上。blktrace比iostat更深入,可以记录每个块请求从进入到完成的全过程。分析设备队列深度、合并情况、实际下发到驱动层的请求大小,对理解文件系统碎片化、缓存回写策略很有帮助。比如你发现业务明明在写小文件,但blktrace显示下发到磁盘的请求大多是连续的64KB大块,这多半是ext4的delalloc延迟分配起了作用,它在内存里做了聚合。8.2 挂载选项、碎片与IO调优文件系统性能调优讲究全局。挂载层的noatime是零成本收益;ext4的delalloc默认开着,能让数据在page cache里攒够一批再写盘,显著减少小文件随机写;commit60可以拉长日志提交周期,降低元数据写盘频率,但崩溃时丢数据窗口变大,需要权衡。碎片是另一个长期痛点。ext4有两个管理工具:e4defrag能在线整理文件碎片;但要根治,应该从预分配入手。对已知大小的文件,用fallocate预分配连续空间,比让文件系统随着写入自动扩展块要高效得多。数据库的临时文件、大容量的日志文件,都能用这个思路减少运行期碎片。vm.dirty_ratio和vm.dirty_background_ratio这两个内核参数决定了脏页回写策略。dirty_background_ratio代表后台回写阈值,达到这个比例后内核开始异步刷盘;dirty_ratio是同步阻塞阈值,达到之后写进程会强制等待回写完成。调整这两个参数可以把写压力的尖峰抹平,但调高了也意味着断电时丢失的未落盘数据变多。数据库服务器通常会做针对性调整,通用文件服务器保持默认已经处于稳定区间。8.3 少做花活的理由很多人看了一堆调优文章,上手就改参数,改完感觉好像快了一点,但很难说清到底提升了多少,也无法排除是正常波动。我自己的原则是:先建立基线,再改动,再对比。用fio模拟实际负载,固定运行几轮,记录IOPS和延迟分布,每次只改一个参数,记录差异。文件系统参数之间互相牵连,一次改多个,出问题你根本不知道凶手是谁。filefrag和fsck的-f选项可以显示碎片率,发现碎片率高了再考虑整理和调整预分配策略。那种看到一个优化点就照着网上配置抄一遍的习惯,建议改掉。生产环境的机器,稳定和可预测远比极端性能重要,文件系统出一次事故,顶上所有性能优化攒下的收益都不够填。