企业官网建设流程全解析

上周又有同事跑来找我救火，说服务器上df -h明明还剩两百多 G，往日志目录里写文件却一直报No space left on device。这个场景我这些年遇到不下十次，答案几乎都指向 inode 被耗尽，而现场会主动敲一下df -i的人不到一半。文件系统这东西平时安静得像不存在，一出事就是半夜告警加数据风险。Linux 下的 ext4、xfs、btrfs、f2fs 这些名字，大家基本都能念出来，但真问到某个业务该选哪个、mkfs参数怎么给、挂载选项怎么调、掉电之后会不会丢数据，能把理由讲清楚的人并不多。

这篇东西我想把 ext4 和 xfs 这两个生产环境里出场率最高的文件系统从头拆一遍，顺带把 btrfs、f2fs 的定位说清楚。内容覆盖磁盘布局、日志模式、参数计算、挂载选项、在线扩容、故障排查，每一块都尽量给到能直接抄的配置和命令。写给自己复盘用，也适合刚接手 Linux 运维、做嵌入式根文件系统裁剪、或者准备面试想系统梳理存储知识的人看。不追求面面俱到，但求每个结论都能说清"为什么这么选"。

1. 文件系统到底在整条 I/O 链路上管什么

1.1 从一次 inode 耗尽事故往前推

先说开头那个"空间没满写不进数据"的问题，根因其实就是文件系统内部有两套互相独立的资源账本：空间块（block）和索引节点（inode）。每创建一个文件，哪怕内容只有一个字节，系统都要从 inode 池里分配一个 inode 来记录它的属主、权限、大小、时间戳和数据的物理位置；同时再从数据块池里分配至少一个 block 存内容。这两本账各自记各自的，所以完全可能出现"块还多得很，inode 用光了"的情况。

哪些业务容易踩这个坑？典型的就是缓存目录、邮件队列、会话文件、海量小图、日志按秒切分的那种目录。一个目录里塞进去几百万个几 KB 的小文件，块空间消耗不大，inode 却是按个消耗的。这时候你用du -sh看不出问题，用ls | wc -l数文件个数才有感觉，最快的判断命令是：

df -i

它会打印每个挂载点的 IUse%、IFree。如果 IUse% 到 100%，块再空也没用。这时候能做的只有三件事：清掉无用小文件、把数据挪到别的分区、或者重建文件系统时把 inode 数量调大。注意最后一条要重新 mkfs，是有损操作，别在生产上一时冲动。

1.2 从应用到磁盘之间隔了几层

理解文件系统，最好先把它在链路上的位置摆正。你写文件调用的write()系统调用，并不直接落到硬盘上，中间要穿过好几层：

应用层 → 系统调用层 → VFS（虚拟文件系统）→ 具体文件系统（ext4/xfs）→ 通用块层 → I/O 调度器 → 块设备驱动 → 物理设备。

这里最关键的一层是 VFS，也就是 Virtual File System。Linux 最聪明的地方在于，它用 VFS 抽象出一套统一的open/read/write/close接口，上层的应用不管底层是 ext4、xfs 还是网络文件系统，调用的都是一样的函数。你在代码里能通过/proc/filesystems看到当前内核支持的全部文件系统类型，用cat /proc/filesystems就能列出来，带nodev前缀的表示不需要挂载块设备（比如 proc、sysfs、tmpfs）。

再往下一层是页缓存（page cache）。你写完数据，内核先把它拷进内存里的页缓存，标记为脏页，然后再由内核线程kworker在合适的时候回写磁盘。这解释了为什么断电时"写成功的文件"可能内容是空的——应用返回成功只是说数据进了内存，没进磁盘。想强制刷盘，就要在关键位置调用sync、fsync、fdatasync。sync命令会把所有脏页刷下去，但它只是"发起"，并不保证执行完毕；真正等它结束要配合sync; sync; sync这种老运维习惯，或者直接盯cat /proc/meminfo | grep Dirty看脏页数量降到接近零。

1.3 主流文件系统的定位差异

生产环境里常见的那几个，其实各有各的舒适区，我整理了一张对照表，参数是经验值，具体以你内核版本的官方文档为准：

这里有个认知要纠正一下：很多人觉得 ext4"老，性能差"，其实在中小规模、随机读写为主的通用负载下，ext4 和 xfs 的差距经常在个位数百分比，真正拉开距离的是超大文件顺序写、极高并发元数据操作、以及几 TB 以上容量时的扩展性。选型不能只看跑分，还要看你团队的熟悉度、备份恢复工具链、以及出问题时谁能修。

2. ext4 深度拆解：为什么它至今还是默认选项

2.1 磁盘布局与块组机制

ext4 把整个分区切成一个个"块组"（block group），默认情况下每个块组管理的空间是 128 MB（由块大小和块组内块位图能表示的位数决定）。每个块组里有：超级块备份、组描述符、块位图、inode 位图、inode 表、以及实际数据块。超级块只完整存在第一个块组的开头，其余的块组保存备份，这就是为什么 ext4 分区坏了还能用e2fsck -b 32768指定备份超级块去救。

ext4 相比 ext3 引入了几个真正提升性能的机制：

• extent：ext3 记录一个文件的数据块位置，用的是"间接块"三级指针，一个上 TB 的文件元数据量大得吓人。ext4 用 extent 描述"从某个块开始，连续 N 个块属于我"，一段连续空间一条记录，元数据量骤降，大文件顺序写性能明显改善。
• 延迟分配（delayed allocation）：应用写数据时，ext4 不立刻决定落到哪个块，而是先在页缓存里攒着，等真正要回写时再一次性分配连续空间。这招大幅减少碎片，但也带来一个副作用——进程崩溃时已经write()的数据可能丢失，因为还没分配块。这个特性默认开启，也是"为什么我写完了断电却丢了"的常见原因之一。
• flex_bg：把多个块组的位图、inode 表集中放在一起，元数据更集中，减少了磁头/闪存随机寻址。

想看清楚一个分区的布局，最直接的命令是：

dumpe2fs -h /dev/sda1 # 只看超级块信息，块大小、inode 数量、日志模式 dumpe2fs /dev/sda1 | head -100 # 看完整块组信息 tune2fs -l /dev/sda1 # 类似 dumpe2fs -h，更常用

tune2fs -l的输出里，Block count、Inode count、Block size、Reserved block count、Filesystem features这几个字段最值得看。

2.2 三种日志模式与数据安全取舍

ext4 是日志文件系统，但它记的是元数据日志还是数据日志，可以通过挂载选项切换，这是我认为最需要理解的一个点。三种模式差别巨大：

• data=journal：元数据和数据都先写日志，再写最终位置。掉电恢复能力最强，但写入路径变成两遍，性能损失经常到一半以上。只有对数据极度敏感、吞吐要求不高的场景才用，比如某些嵌入式配置存储。
• data=ordered（默认）：只把元数据记日志，但保证数据块先于引用它的元数据提交。效果是掉电后不会出现"文件变成垃圾内容"或者"元数据指向不属于自己的块"这种严重损坏，最多是丢最近没刷盘的写入。这是性能与安全的平衡点，绝大多数场景保持默认即可。
• data=writeback：只记元数据日志，不保证数据先落盘。性能最高，但掉电后可能出现"文件大小对，内容却是旧数据或零"的情况。数据库自己做了 WAL 的时候会用这个模式，把一致性交给数据库自己管。

改法有两种。临时改（重启失效）：mount -o remount,data=writeback /data。永久改就写进/etc/fstab的第四列。要提醒一句，切换日志模式会让日志重新初始化，务必先备份。

判断当前生效的模式：mount | grep sda1，看有没有data=xxx，没写就是 ordered。

注意：为一个数据库业务把整个分区切成 data=journal，是很常见的过度设计。数据库通常自带事务日志和刷盘策略，你再加一层全数据日志，等于同一件事做了两遍，吞吐白白砍半。

2.3 mkfs 参数与计算过程

先看一个我常用的小文件密集型分区的创建命令：

mkfs.ext4 -F -b 4096 -I 256 -i 8192 -m 1 -O extent,flex_bg,uninit_bg,dir_index,has_journal \ -E lazy_itable_init=1,stride=16,stripe-width=48 -L data0 /dev/sdb1

逐个说清楚为什么这么给：

• -b 4096：块大小 4 KB。这是绝大多数场景的甜蜜点，太小元数据开销大，太大浪费小文件的尾部空间。
• -I 256：每个 inode 占 256 字节。ext4 默认就是 256，除非你要用扩展属性（比如 SELinux 上下文、ACL 大量使用时）才考虑 512。
• -i 8192：每 8192 字节空间分配一个 inode，比默认的 16384 密一倍。这就是为小文件场景准备的。假设分区是 1 TB，块大小 4 KB，按默认 16384 算 inode 数量大约是 1TB / 16KB ≈ 6700 万个；改成 8192 后翻倍到约 1.3 亿个。代价是 inode 表本身占空间也翻倍，大概每 1 亿 inode 吃掉 25 GB 左右（按 256 字节算）。
• -m 1：保留空间比例从默认 5% 降到 1%。默认保留块是给 root 应急用的，非系统盘没必要留 5%。1 TB 盘 5% 就是 51 GB，纯浪费。系统盘/建议保留，数据盘可以压到 1% 甚至 0。
• -E stride=16,stripe-width=48：这两个是 RAID 上必须给的参数。stride = chunk大小 / 块大小，stripe-width = stride × 数据盘数量。以 4 块盘的 RAID5、chunk 64 KB、块大小 4 KB 为例：stride = 64/4 = 16，数据盘是 4-1=3 块，stripe-width = 16 × 3 = 48。不给这两个值，ext4 会按单盘逻辑分配，RAID5 上写放大严重。

提示：-E和-O里的选项写错会导致 mkfs 直接失败，但-i给得过小会让 mkfs 变慢、inode 表变大。现在很多发行版默认打开lazy_itable_init，首次挂载后 inode 表在后台慢慢初始化，所以 mkfs 很快就返回，别以为它没干活，等几分钟再跑测试更靠谱。

2.4 挂载选项与在线扩容的坑

挂载选项对性能的影响不亚于 mkfs 参数。几个我必调的：

/dev/sdb1 /data ext4 defaults,noatime,nodiratime,data=ordered,commit=30,barrier=1 0 2

• noatime：不更新文件的访问时间。默认的 relatime 已经很克制了，但在高并发读的场景下关掉更省。有些老程序依赖访问时间做缓存淘汰，用之前确认一下。
• nodiratime：不更新目录访问时间。
• commit=30：把 journal 提交间隔从默认 5 秒放宽到 30 秒。写入合并更多，吞吐提升，但掉电可能丢最多 30 秒数据。数据库盘别这么干。
• barrier=1：保持写屏障开启，保证日志提交顺序。除非你确定底层存储（比如某些虚机磁盘、老 RAID 卡缓存）不支持，否则不要关。

扩容这块。ext4 最舒服的一点是支持离线缩小和在线扩容。在线扩容对一个已挂载的 ext4：

growpart /dev/sda 1 # 如果是云主机，先把分区表扩了 pvresize /dev/sda1 # 如果上面还叠了 LVM lvextend -l +100%FREE /dev/vg0/data resize2fs /dev/vg0/data # ext4 在线扩容，demand 挂载状态也能跑

顺序不能反：路由是分区 → LVM → 文件系统，一层层从上往下扩。反过来说，要缩小 ext4 必须先umount，再resize2fs，再缩分区。这是有损操作，务必先备份，尤其别在根分区上试。

3. XFS 深度拆解：大文件与高并发场景的答案

3.1 分配组设计与并发能力

XFS 是 1993 年 SGI 为 IRIX 做的，后来移植到 Linux，天生就冲着大机、并行 I/O 去的。它的核心组织和 ext4 完全不同：XFS 把整个文件系统划分成若干个分配组（Allocation Group，AG）。每个 AG 有自己的 inode 空间、空闲空间 B 树和一套独立的元数据，可以看作一个小型文件系统。多个进程同时往不同 AG 写，锁竞争天然就低，这是 XFS 在高并发元数据操作和大规模并行写时比 ext4 强的主要原因。

AG 数量是 mkfs 时定的，之后不能改。mkfs.xfs会根据容量自动推算一个值，经验上小盘给 4 个、大盘按每 4~16 GB 一个 AG 往上走，但现在的 v5 格式对这个规则做了调整。如果你明确知道要跑极高并发，可以手工指定：

mkfs.xfs -f -d agcount=16 -l size=128m -i maxpct=10 -L data0 /dev/sdb1

• -d agcount=16：直接定死 16 个分配组。
• -l size=128m：日志区大小 128 MB。XFS 的日志默认放在文件系统内部，大小由容量自动决定，高写入场景适当调大能减少日志回绕等待。
• -i maxpct=10：inode 空间最多占整个文件系统的 10%。这里要解释一下 XFS 的"动态 inode"——它不像 ext4 那样在 mkfs 时把 inode 数量写死，而是按需分配。所以 XFS 基本不会出现 inode 耗尽（理论上受 maxpct 限制），这是它面对海量小文件时的一个巨大优势。

看当前 XFS 的实际参数用xfs_info /data，它会打印出 blocksize、agcount、sectsz、logbsize 等，比tune2fs -l对 ext4 的角色。

3.2 v5 格式带来的几个现代特性

XFS 现在默认创建的是 v5 格式（也叫 CRC 格式），带几个值得知道的特性：

• 元数据校验（metadata checksum）：所有元数据块都带 CRC32 校验，能主动发现静默损坏而不是等崩溃。
• reflink：支持写时复制（CoW）和去重。做虚拟机镜像、容器镜像层的时候，reflink copy 复制一个 10 GB 的文件几乎瞬间完成，只占增量空间。命令是cp --reflink=always。
• rmapbt：反向映射 B 树，是 reflink 和在线xfs_scrub的基础，代价是元数据略微变大。

创建时可以显式打开：

mkfs.xfs -f -m crc=1,reflink=1 -n ftype=1 /dev/sdb1

ftype=1这个别关，systemd、容器和很多现代软件依赖它判断目录项类型。

3.3 不能缩小的现实，以及在线扩容

XFS 有个非常硬的限制：只能扩，不能缩。这是它的设计决定的——空间按 AG 打散，B 树里到处是指针，缩容要重排整个布局，实现成本极高，社区就没做。所以给业务分 XFS 分区要保守，宁可一开始给大一点。

扩容过程比 ext4 简单，而且所有操作在线完成：

growpart /dev/sda 1 pvresize /dev/sda1 lvextend -l +100%FREE /dev/vg0/data xfs_growfs /data # 注意：xfs_growfs 接受的是挂载点，不是设备

注意：xfs_growfs传的是挂载点路径，传设备名会报错，这和resize2fs /dev/xxx的习惯正好相反，从 ext4 转过来的人十有八九第一次会踩。

3.4 从 ext4 迁到 XFS 的评估清单

不是所有场景都值得迁。我自己做迁移决策时会过一遍下面这些判断：

我一般建议：系统盘和通用应用盘保持 ext4，纯数据盘、数据库盘、对象存储后端、日志汇聚盘优先 XFS。如果团队没人熟 XFS 的恢复流程，那就别迁，工具链的成熟度比那点性能更重要。

4. 选型落地：把文件系统真正装到生产上

4.1 完整实操流程：从裸盘到开机自动挂载

这块我按实际动手顺序写一遍，你可以照着抄。假设新增了一块/dev/sdb。

第一步，确认设备和分区：

lsblk -f # 看设备、分区、文件系统、UUID、挂载点 blkid /dev/sdb # 看设备的 UUID 和文件系统类型

第二步，分区（如果整盘不分区也可以，直接 mkfs 到 /dev/sdb）：

parted -s /dev/sdb mklabel gpt parted -s /dev/sdb mkpart primary xfs 1MiB 100% partprobe /dev/sdb

第三步，创建文件系统（XFS 为例）：

mkfs.xfs -f -L data0 /dev/sdb1

第四步，挂载并写 fstab。这一步的关键是一定要用 UUID 而不是设备名，因为设备名会随着插盘顺序、内核识别顺序变化，重启后可能挂错。取 UUID：

blkid -s UUID -o value /dev/sdb1

然后写进/etc/fstab：

UUID=你的uuid /data xfs defaults,noatime,nodiratime,logbsize=256k 0 2

写完后务必先用mount -a试一下，看有没有报错、有没有报已挂载。直接重启去验证是个坏习惯，fstab 写错会导致系统进 emergency mode，远程机器就麻烦了。

提示：XFS 的logbsize=256k在大写入场景能减少日志 I/O 次数，但内存开销略增；如果不是高写入负载，保持默认即可，别为了调而调。

4.2 观测工具：别靠感觉判断性能

调完之后要有数据支撑，靠dd测文件系统性能是很业余的做法——它绕过太多层，也测不出随机和并发。正经的做法是fio，看延迟分布而不是只看 IOPS：

fio --name=randwrite --ioengine=libaio --direct=1 --bs=4k \ --iodepth=32 --rw=randwrite --numjobs=4 --size=4G \ --runtime=60 --time_based --filename=/data/test.fio --group_reporting

运行时的系统级观测靠iostat：

iostat -x 1 10

重点看三列：%util（设备忙不忙，接近 100% 说明饱和）、await（平均 I/O 等待毫秒数）、aqu-sz（平均队列长度，持续大于 1 说明排队严重）。如果 %util 不高但 await 很高，问题往往在队列深度或者存储后端，不在文件系统本身。

文件系统层面的使用率看这几个：

df -h # 块空间 df -i # inode stat -f /data # 文件系统的块大小、总块数、空闲块数

4.3 挂载参数速查表

discard这个我多说一句。它能让 SSD 在删除文件时立刻回收块，但很多消费级 SSD 的 TRIM 实现同步阻塞，导致删除操作变慢。更稳的做法是关掉 discard，改用定时任务：

fstrim -av

配合cron每天跑一次，效果一样，卡顿可控。

5. 常见故障与排查实录

5.1 inode 耗尽与"空间没满却写不进"

症状：df -h有剩余空间，写入报No space left on device。排查顺序：

df -i /data # 看 IUse% find /data -maxdepth 2 -type d -exec sh -c 'echo "$(ls -U $1 | wc -l) $1"' _ {} \; | sort -rn | head

上面那条 find 命令是找出哪个子目录里文件数量最多。找到之后要么清理，要么归档。如果是日志类，通常需要改应用的滚动策略，比如从"每秒一个文件"改成"按大小滚动"。治本的做法是下次 mkfs 时降低-i的值。

5.2 中文文件名乱码与解压问题

从 Windows 打包过来的 zip，在 Linux 上解压经常出现中文变成问号或乱码。根因是 zip 格式本身没有规定文件名编码，Windows 的压缩工具默认用 GBK/CP936，Linux 的unzip默认按 UTF-8 解释。解决办法：

unzip -O cp936 archive.zip # 指定用 GBK 解读文件名 # 或者用 7z，它会自动探测 7z x archive.zip

tar.gz 一般不存在这个问题，但如果确实出现乱码，往往是打包端 locale 设置不对，可以用tar -tf archive.tar.gz | iconv -f gbk -t utf-8先看看文件名。

5.3 掉电后的恢复流程

文件系统掉电之后的处理，ext4 和 XFS 的路径完全不同，这点必须记住：

ext4：日志会重放，通常挂载时自动完成。如果挂载失败，需要手动e2fsck：

umount /dev/sdb1 e2fsck -f -y -C 0 /dev/sdb1 # -f 强制检查，-y 自动修复，-C 显示进度

超级块损坏时用备份超级块：

e2fsck -b 32768 -B 4096 /dev/sdb1

XFS 没有e2fsck对应的东西，用的是xfs_repair，而且必须卸载后才能跑：

umount /data xfs_repair -v /dev/sdb1 xfs_repair -L /dev/sdb1 # 日志损坏时才加 -L 清日志，这一步会丢未提交数据，慎用

xfs_repair前强烈建议先xfs_metadump做一份元数据镜像，万一修复方向错了还有退路：

xfs_metadump /dev/sdb1 /backup/sdb1.mdump

5.4 排查速查表

6. 几条容易被忽略的实战经验

6.1 sync、fsync 和 writeback 的边界

很多人以为调用了write()数据就安全了，其实只是进了页缓存。真正的落盘时机由内核的 writeback 机制控制，/proc/sys/vm/dirty_ratio和dirty_background_ratio决定脏页攒到多少比例开始回写。默认一般 dirty_ratio 是 20%，dirty_background_ratio 是 10%。意思是内存的 10% 脏页时后台开始慢慢刷，到 20% 时应用自己的写操作会被阻塞去刷盘。

如果服务器内存特别大（比如 256 GB），20% 就是 51 GB 脏页，一次掉电能丢的数据量非常可观。所以内存越大，越应该把这个比例调小，比如：

sysctl -w vm.dirty_ratio=10 sysctl -w vm.dirty_background_ratio=5 sysctl -w vm.dirty_expire_centisecs=1500

要持久化就写进/etc/sysctl.d/下的配置文件。第三行的意思是脏页超过 15 秒就强制回写，避免数据在内存里躺太久。

6.2 嵌入式与容器场景下的叠加文件系统

嵌入式 Linux 的根文件系统，很多是只读的 squashfs 加一层可写的 overlayfs，或者在 eMMC 上直接用 f2fs、ubifs。这时候你要注意，overlayfs 只是个叠加层，写操作最终落在可写层所在的底层文件系统上，性能和容量都受底层约束。容器场景同理，镜像层通常是只读的，容器可写层落在宿主机某个 ext4 或 xfs 目录里。

另外嵌入式设备上有个经典悲剧：为了延长 Flash 寿命把根文件系统挂成只读，但应用又要写配置，于是频繁写日志分区导致坏块。处理办法是把高频写的内容放到 tmpfs 里，定期同步到持久分区，从根上减少擦写次数。

6.3 备份和迁移的几个选择

ext4 有dump/restore，但更常用的是rsync加卷快照。XFS 官方那套是xfsdump/xfsrestore，它支持增量备份，能保留扩展属性和 ACL，但它是针对 XFS 的，跨文件系统恢复不行。实际生产里我更倾向在存储层做快照，然后挂载快照走rsync -aHAX --numeric-ids复制，这样和具体文件系统解耦，迁移也方便。

有一点要注意：rsync不加-H会导致硬链接被打散，不加-A会丢 ACL，不加-X会丢扩展属性，--numeric-ids则是避免用户名映射错乱，做系统级迁移时这四个几乎必带。

我自己在这些年里最大的体会是，文件系统这块的"默认值"往往比"调优值"更值得信任。内核社区给的默认参数是权衡了无数种场景之后的结果，我的大部分调优动作，最后收益都没超过个位数百分比，反倒是noatime、-m 1、正确的stride/stripe-width这几个简单操作带来的提升最实在。所以我的建议是：先把基本盘做对——分区大小合理、fstab 用 UUID、监控里加上 inode 使用率、定时跑fstrim，然后再谈那些花哨的参数。至于 ext4 和 xfs 之争，等你真正遇到单文件上 TB 或者并发上万的那个量级，答案自己就浮出来了。