ext4 还是 XFS：先想清楚三个「以后」，别再问谁更快

一块 2T 的盘，格式化那一下就把两件事定死了

先摆一个具体的两难。你手上有一块 2T 的数据盘，要拿来存一堆小文件——业务日志、埋点切片、或者对象存储落地之前的临时目录，量级是几千万甚至上亿个。装系统的时候顺手敲一句 mkfs.ext4 /dev/sdb1，回车，几秒钟，盘就能挂了。但这一下同时把两件事定死了：inode 的总数，和这块盘以后还能不能往回缩。

默认参数下，ext4 大约每 16KB 空间给一个 inode，2T 盘算下来是一亿三千多万个 inode。听着很多，可如果你的文件平均只有 4KB，一亿多个 inode 全部占满时磁盘才写了五百多 GB——剩下四分之三的空间还空着，但你已经建不出任何新文件了。df -h 告诉你还有 1.4T 可用，touch 却直接甩出 No space left on device。这就是 inode 被定死的意思。

你换个思路：那我用 XFS。XFS 的 inode 是动态分配的，空间还有就能接着建，小文件堆死这种事基本不会发生。但代价是 XFS 只能在线增大，不能缩小。两年后业务收缩，这块盘其实只需要 1T，你想缩回去？没有类似 resize2fs 的命令可以敲，只能把数据整体备份、按 1T 重新格式化、再恢复回来。一次全量搬迁，几千万个小文件，你自己估一下这要花多久。

所以装机时那个看起来随便选一下的选项，其实是在替两年后的你做决定。这篇不谈别的，只谈三个「以后」：以后能不能缩、inode 会不会先用完、写满之后还剩多少余地。

先把「谁更快」这个问题放下：它通常不是分水岭

「ext4 和 XFS 哪个快」是搜索框里最常见的问法，也是最没用的问法。说白了，在中小团队的真实负载里，两个文件系统之间那点吞吐差异，远远小于你选错 inode 密度、或者没留出缩容路径带来的代价。前者是波动，后者是停机。

而且「快」这个字本身就绑了一堆前提：块大小、条带对齐、RAID 卡缓存策略、I/O 调度器、你的 workload 是随机小写还是顺序大写、底层是机械盘还是 NVMe。同一个文件系统，把这些变量换一圈，表现能差出一大截。脱离这些前提去比两个文件系统的快慢，得到的结论基本没法用。

真正会在两三年后反噬你的，是容量边界和可维护性。这两样东西在 mkfs 按下去的那一刻就写进超级块了，事后要改，要么卸载，要么全量搬迁。从行业部署角度看也是同一个道理：文件系统选型通常就是装机阶段一次性拍板的事，后面想换，代价都是停机加搬迁。

第一个以后：XFS 只能大不能小，ext4 能缩但必须卸载

XFS 支持在线增大，挂载状态下 xfs_growfs /挂载点 就能把文件系统撑到新的设备大小，注意它吃的是挂载点路径，不是设备名。但 XFS 没有缩小这条路，官方工具链里就没有对应的命令。想把一块 XFS 盘从 2T 缩到 1T，唯一合规的做法是备份数据、按 1T 重新格式化、再恢复数据。没有捷径，也没有「小心一点就能行」的偏方。

ext4 这边，resize2fs 既能增大也能缩小，缩小有个硬前提：必须卸载。也就是说要停服务、进救援环境，或者从另一个根挂载进来操作。而且缩之前必须先跑 e2fsck -f，工具会强制要求这一步，检查没做完不让你缩。这不是形式主义，它要确认你准备丢弃的那段空间里没有还被引用的元数据。

顺序也要记牢，弄反了会丢数据：缩小的时候，先缩文件系统（resize2fs 到目标大小），再缩底层块设备（LV 或分区）；增大的时候反过来，先扩块设备，再扩文件系统。用 LVM 的话，缩 LV 之前文件系统必须先缩到位，而且目标值要给足余量——宁可让文件系统比 LV 小几百 MB，也别卡在边界上算单位。GB 和 GiB 那点换算差，在这里是能直接毁掉文件系统的。

扩容那一侧也有个容易忽略的前置动作：xfs_growfs 和 resize2fs 都只能把文件系统撑到「底层设备当前有多大」，它们不会帮你扩设备本身。盘在阵列或云平台上扩完之后，还要先在操作系统里让内核看到新的容量（分区表改完用 partprobe、或者用 growpart 之类的工具扩分区，LVM 则是 pvresize 再 lvextend），这之后才轮到文件系统命令登场。顺序搞反的表现通常是命令执行成功但容量没变，然后你以为扩容失败了，白紧张一场。

还有一层得说清楚：即便 ext4 能缩，缩容依然是一次计划停机。所以「ext4 能缩」不等于「缩起来很轻松」，它的价值在于你有这条路可走，不是这条路很好走。XFS 是连这条路都没有。差别就在这里。从部署角度看，也只有盘由你自己分区、格式化参数由你自己敲的环境，才谈得上「以后要不要缩」这个选项——一万网络的独立服务器租用就是这种形态，盘怎么切、用什么文件系统、给多少 inode，全是你命令行里的事，多花两分钟想清楚很值。

第二个以后：ext4 的 inode 在 mkfs 时就定死，XFS 是动态分配的

ext4 在格式化阶段就按 inode ratio 一次性把 inode 表铺好，之后 inode 总数只减不增。df -i 能看到用了多少、总共多少，用完就是用完，哪怕 df -h 显示还有几百 GB 空闲。这时候你会撞上一个非常反直觉的现象：磁盘明明没满，什么文件都写不进去，报错却还是 No space left on device。

XFS 不一样，它的 inode 是用到才分配的，空间还有就能接着建新文件，所以 XFS 上基本不存在「inode 先用完」这个故障模式。但它也不是无限：XFS 的 inode 占用比例受 imaxpct 限制，默认通常是文件系统空间的 25%，意思是最多可能有约四分之一的容量被 inode 结构吃掉（实际上远用不到这么高），这个比例可以在 mkfs.xfs -i maxpct= 里调。

反过来说，ext4 把 inode 定死也不全是坏事。inode 表是预先分配好的，df -i 一眼就能看到水位，做监控告警很方便。XFS 上你没法提前预警「inode 快没了」，因为它没有这个硬上限；代价是你也失去了 inode 水位这个早期信号。两种设计各有取舍，关键看你的文件分布是不是可预测。

inode ratio 这个参数到底怎么选：两个极端各怎么配

既然 ext4 的 inode 数是算出来的，那就得知道它怎么算、怎么改。

核心参数叫 inode ratio，含义是「平均每多少字节给一个 inode」。mkfs.ext4 -i 8192 就是每 8KB 一个 inode。还有个更省事的入口叫用例类型：mkfs.ext4 -T largefile 会把 ratio 放大到 1MB（适合镜像、视频、备份包这类大文件），-T largefile4 放大到 4MB，-T news 是给新闻组那种海量小文件准备的，ratio 会被压得很小。也可以直接上 -N 指定 inode 的绝对数量，最直白。

一端是几千万个小文件。假设你的日志切片平均 8KB，2T 盘要装到接近满，那就是两亿多个文件。这时候 ratio 必须小于 8KB，-i 4096 甚至更小才安全，或者干脆用 -N 按预估文件总数再乘个 1.5 倍余量。多给 inode 的代价只是 inode 表本身占一点空间（默认每个 inode 在 256 字节量级），两亿个 inode 也就五十 GB 上下，跟「写不进去」比起来，这点浪费根本不算事。

另一端是几个大文件。2T 盘上放二十个 100GB 的数据库文件或备份包，用默认 16KB ratio 会给你一亿多个 inode，纯属浪费——inode 表自身吃掉几十 GB，而且 e2fsck 跑一遍的时间会明显变长。这种盘就该上 -T largefile，inode 数量降到两百万级别，检查时间也跟着降下来。

还有两个跟 inode 相关的参数顺手提一下。一个是 inode 大小（-I），默认是 256 字节量级，如果你要往 inode 里塞比较多的扩展属性（xattr、ACL、SELinux 标签那一类），可以加大到 512 甚至更多，代价是 inode 表按同样的倍数膨胀——所以 inode 数量多和 inode 单个大这两件事别同时往大了开。另一个是 64bit 这类特性，它在 mkfs 时决定，没打开的话将来把文件系统扩到很大的容量时会受限（具体阈值随内核版本与块大小不同，请以你系统上的手册为准）。说到底还是那句话：跟容量边界有关的开关，基本都在格式化那一刻定死。装完之后想复查，tune2fs -l 里的 feature 和 inode count 一行就看完。

经验上一句话能记住：平均文件大小比默认 ratio 小的，往小了调；比默认 ratio 大得多的，往大了调。怕的从来不是 inode 给多了，是给少了。给多了最多浪费点空间和检查时间，给少了是业务直接写不进去。

第三个以后：满了之后还剩多少余地，预留块和延迟分配各扮演什么角色

ext4 有个很实在的设计叫预留块，默认 5%，tune2fs -l 能看到具体块数，只有 root 能往里写。它的意义就是：当普通用户把盘写满、业务进程全部卡死的时候，root 登录进来还能写日志、还能删东西、还能挪文件。这 5% 就是留给你的救援空间。数据盘（非根分区）上很多人会调低它，tune2fs -m 1 /dev/sdb1 调到 1% 换回一点可用容量——可以，但别调成 0，根分区尤其别动。

XFS 这边没有这么一个用户可以随手调的预留块参数，写满就是真的写满。所以 XFS 盘更依赖你在监控层自己留白：告警阈值别卡在 90%，大容量盘尤其如此，10% 的 8T 是将近 800GB，按你的写入速率算一算还能撑多久，把响应时间留够。

还有个在 XFS 上特别容易误判的现象：延迟分配和推测性预分配。XFS 写的时候会先攒着不落盘，而且可能为一个正在被追加的文件预分配远超当前大小的块。结果就是 df 看着快满了，du 把文件大小加起来却对不上，差出一大截。这些预分配的块在文件关闭或内存压力上来时会被回收，正常水位下不用管；但在接近写满时，它会让你高估占用，也会让延迟出现突发抖动——攒了一堆没落盘的写，到必须落盘的时候一次性冲下去，那一两秒的延迟会很扎眼。

ext4 同样有延迟分配，只是 XFS 的预分配行为在高水位下更显眼。应对办法两边都一样：别让盘长期待在 85% 以上，那是所有文件系统都不舒服的水位。

真到了写满那一刻，两边的处置流程其实差不多，提前想一遍能省掉很多慌乱：用 root 身份登进去（普通用户的写会被 ENOSPC 直接拒绝），先定位是哪个目录在涨，能安全删的先删一批，删完如果空间没立刻回来，多半是被某个还在被进程持有的已删除大文件占着——用 lsof 找出持有者再处理。容器环境里最常见的元凶是失控的容器日志和 overlay 层，这种时候 project quota 的价值就显出来了：它至少能把损失锁在一个容器里，而不是让整块盘连 root 都腾不出手。

掉电这一下，两家表现不一样

这一条很少有人在选型时想到，但出事的时候差别很大：两家记日志的方式不是一回事。

ext4 的 data= 挂载选项有三种模式。data=ordered 是默认，只把元数据写进日志，但保证数据块先于元数据落盘；data=writeback 只记元数据、不保证顺序，掉电后可能看到旧数据；data=journal 连数据一起写进日志，最稳，但写放大明显，性能代价大。日常用默认就行，别为了那点性能随手改成 writeback。

XFS 只做元数据日志，数据本身不进日志。这带来一个已知的行为特征：掉电后可能出现文件大小已经被更新、但对应内容是旧数据甚至全零的情况。这不是 bug，是设计取舍——元数据一致性由日志保证，数据一致性要靠你自己 fsync。

对数据库这类自己会严格 fsync 的程序来说，这个差别基本被屏蔽掉了，数据库有自己的一套持久化协议。真正要小心的是那种「写文件、改大小、不做 fsync 就认为写完了」的应用，尤其是自己手写的落盘逻辑。如果你的业务里有这类代码，或者你对掉电语义就是想少操心，ext4 的默认模式会让你睡得踏实一点。

大目录、大文件、并发写：B+ 树与 htree 各自擅长的场景

一个目录里堆到几百万个文件之后，两家的索引结构就开始显出差别。

ext4 用 dir_index（htree）做目录索引，在单目录文件数极大、需要频繁按名字查找的场景表现是比较好的，tune2fs -l 里能看到 dir_index 这个 feature 是否开着，现代 mkfs.ext4 默认就开。XFS 用 B+ 树管理目录条目，同时用分配组把空间切成多块并行管理，多个进程同时往不同目录、不同大文件里写的时候，元数据锁的争抢通常更小。

落到场景上：一个目录里放几十万个小文件、并且频繁按文件名点查，两边都扛得住，ext4 的 htree 在这个点上并不吃亏。反过来，几十个线程同时写各自的几十 GB 大文件，或者持续往一个大目录里灌文件又持续删——这种高并发写入压力的形态，XFS 的分配组设计通常更从容。删除超大目录时，XFS 的表现也普遍被反映为比较干脆。

百分比我不给，因为块大小、目录深度、底层是不是 SSD 都能让结论翻过来。你只要记住形状的差别：ext4 擅长「在一个大目录里快速找到东西」，XFS 擅长「很多人同时往里写东西」。

修复工具这一段要提前知道：e2fsck 与 xfs_repair 各自的前提动作

这一段希望你永远用不上，但提前知道能省很多事。

ext4 的修复工具是 e2fsck，要求文件系统处于卸载状态（或只读挂载）。强制检查用 e2fsck -f，缩容前必做。e2fsck -y 这种「所有问题都自动回答 yes」的用法要谨慎，它在某些损坏场景下会做出你不想要的决定，由此丢数据的案例并不少见。更稳的顺序是：能只读挂载就先挂上去，把还能读的数据先拷出来，再谈修复。

XFS 的对应工具是 xfs_repair，同样需要卸载。它有个特点值得记一下：在某些元数据损坏的场景下，工具会先提示你用 xfs_metadump 把元数据镜像存一份再动手。这不是多此一举——xfs_repair 在遇到它判断不了的损坏时有可能把损坏范围扩大，留一份元数据镜像，是给后面的人工排查留一条退路。xfs_metadump 出来的镜像里可能带文件名等元数据信息，要按敏感数据处理。

两家也都有整理工具：ext4 用 e2fsck -D 重建目录索引（离线），filefrag 用来看碎片情况；XFS 有 xfs_fsr 可以在线做碎片整理，xfs_db 则是更底层的查看与调试工具。碎片这件事在 SSD 上没那么要紧，在跑了几年的大容量机械盘上值得定期看一眼。

还有一个参数要认识一下：xfs_repair -L（强制清零日志）。网上很多救急教程会让你直接加这个参数，因为它能让一大批「日志损坏导致挂不上」的盘立刻恢复挂载。但清零日志的代价是丢弃日志里还没重放完的那部分近期写入，属于可能丢数据的操作。它应当被当成确认过备份之后的收尾手段，而不是第一步。同样的谨慎也适用于 ext4 侧的 e2fsck -y：自动应答很省事，可它替你做的决定未必是你会做的那个。

说白了，这两家在「坏了怎么办」这件事上的态度是一致的：先保住数据，再谈修复。差别只在工具的脾气——e2fsck 会一步步问你，xfs_repair 则倾向于先让你交一份元数据镜像出来。

配额与容器目录：XFS 的 project quota 为什么在某些场景更顺手

配额两边都支持，但落到一个具体场景上，XFS 更顺手：容器存储的目录级配额。

XFS 的 project quota（挂载选项 prjquota 或等价写法）是针对「目录树」而不是「用户／组」来限额的。这正好对上容器的用法——给每个容器的存储目录设一个上限，谁把日志写爆了也不会把整块盘拖死。容器运行时在某些存储配置下就是依赖 XFS 的 project quota 来做目录级限制的。

ext4 在较新的内核里也支持 project quota，但生态上 XFS 这套用得更普遍，文档和现成脚本更多，相关组件对它的兼容性也更好。如果你明确要在容器存储目录上限额，XFS 加 prjquota 是当前更省事的一条路。

还有一个和容器强相关的坑，记在 XFS 名下：在 XFS 上跑 overlayfs（容器运行时最常用的存储驱动）要求文件系统带 ftype=1。用比较老的 mkfs.xfs 格式化出来的盘，ftype 可能是 0，等 Docker 装完才发现起不来。检查很简单，xfs_info /挂载点 看 ftype 那一行；新装的现代发行版默认已经是 1。这块盘要是要给容器用，格式化时顺手确认一下，比事后重建划算得多。

快照不在文件系统这一层：备份和快照该在哪一层做

有人会问「ext4 和 XFS 哪个支持快照」，这个问题本身就问错层了。

ext4 和 XFS 都不提供文件系统级快照。快照通常做在下面一层：LVM 的快照卷或精简配置卷、存储阵列的快照、或者云盘自带的快照能力。你要的是「某一时刻的一致性镜像」，那就去块设备层或存储层做，别指望文件系统给你。

但有一件事文件系统能帮上：冻结。做快照之前要先把一致性点固定住，ext4 和 XFS 都可以用 fsfreeze（XFS 也有自己的 xfs_freeze）把写入暂时挂起，快照打完再解冻。数据库场景下这一步尤其重要，否则你拿到的是一个可能缺了半截事务的镜像。要提醒的是，fsfreeze 期间所有写都会阻塞，别挑业务高峰跑。

还有一点值得说：正因为快照在块设备层，「能不能缩」这件事会跟着卷管理层一起被放大。LVM 上缩 LV 需要文件系统先缩到位，你选了 XFS 就等于这套组合技直接废掉，只能走搬迁。这也是为什么在容量需要频繁调整的环境里，人们会更倾向于能缩的那一个。

按目录用途给选择：系统盘、日志盘、数据库盘、备份盘、容器存储各选谁

把上面这些落到具体目录上。

系统盘（/ 与 /boot）：两种都能用。主流发行版里 RHEL／CentOS 7 之后的默认根分区就是 XFS，稳定性早被大规模验证过，别信「根分区不能用 XFS」这种老说法。真正的差别在灵活性和可救援性——ext4 能缩、e2fsck 的生态更老更全、进各种救援环境时被顺利识别的概率也略高。你想留着将来调整分区的可能，就选 ext4；确定这块盘大小不会再动，XFS 一点问题没有。

日志盘（海量小文件、高频创建和删除）：XFS。inode 动态分配直接免掉了「inode 先用完」这个隐患，删大目录也比较干脆。如果因为别的原因一定要用 ext4，格式化时必须重设 inode ratio（-T news 或者 -i 4096 以下），并且把 df -i 加进监控项，水位到 80% 就告警。

数据库盘（MySQL、PostgreSQL 的数据目录）：两种都用得很普遍，别在这里纠结性能。判断依据是三条：团队熟悉哪个、将来会不会缩、你对掉电语义的偏好。数据库自己会 fsync，所以 XFS 只记元数据日志这一点影响有限；但如果这个库可能先撑大再回收，ext4 那条缩容路径会让你将来好过一些。确定只增不减，就 XFS 省心。

备份盘（少量超大文件、顺序写、几乎不删）：XFS。单文件与文件系统的容量上限更大（量级在 8 EiB，随内核版本与块大小不同会有差异；ext4 常见的说法是文件系统 1 EiB、单文件 16 TiB 量级，同样随内核与块大小浮动），顺序写的形态也合它的胃口，还有 xfs_fsr 可用。ext4 干这活也完全够，记得用 -T largefile 省掉那一亿多个用不上的 inode。

容器存储目录（/var/lib/docker、/var/lib/containerd）：XFS 加 prjquota，前提是先确认 ftype=1。理由就是上面说的目录级配额。要提醒的是，这套挂载选项最好在格式化时就一起定好，事后补参数还是得重挂或重启。

还有一种很常见的现实情况：一台机器只有一到两块盘，数据库、日志、备份全得塞在一起。这时候别指望一个文件系统通吃，正确做法是按用途分开分区甚至分开盘，而不是在一个文件系统上调参数。日志那一块单独分出来用 XFS，数据库那一块单独分出来按你的习惯选，备份那块再来一个 -T largefile 的 ext4 或者再来一个 XFS。这样做的好处不只是参数能对上，更是把故障域切开了——日志把盘写爆的时候，数据库那边不会跟着一起写不进去。盘的数量和大小能按需配的环境才做得到这种切分，这也是独立服务器相对固定镜像主机的现实价值之一。

顺带说一句，上面这些判断只有在你能完全掌控分区与格式化参数的环境下才做得了——盘由你自己分区、文件系统和 mkfs 参数由你自己敲，而不是拿到手就是一块已经格式化好、动不了的盘。像一万网络（深耕 IDC 19 年，成立于 2007 年）这类提供独立服务器租用的来源，盘的数量与大小可以按需配，分区表和文件系统由使用者自己决定，这种选型讨论才有落地的余地，具体配置以官网实时显示为准。换成固定镜像的云主机或者虚拟主机，你连 mkfs 的权限都没有，上面这些全是空谈。

装系统选文件系统时，最常被问到的几个问题

已经装成 ext4 了，能改成 XFS 吗？不能直接改，没有原地转换这条路。可行做法只有一条：备份数据、重新格式化成 XFS、再恢复。所以这个决定最好在装机时就想清楚，或者在数据量还小、搬迁成本低的时候赶紧改。真到了几 T 数据、几千万个文件再想换，那就是一次需要排期的停机窗口。

格式化时怎么指定 inode 数量？ext4 有三种写法。mkfs.ext4 -i 4096 /dev/sdb1 是按 ratio 给（每 4KB 一个 inode）；mkfs.ext4 -N 200000000 /dev/sdb1 是直接指定 inode 绝对数量；mkfs.ext4 -T largefile /dev/sdb1 是用例类型，后面藏着一组预设的 ratio。装完之后用 df -i 或 tune2fs -l 复核一眼，别等出事才发现算错了。XFS 不用操心这项，它动态分配。

XFS 真的完全不能缩吗？是真的，工具链里没有缩小的命令，官方文档也明确只支持增大。xfs_growfs 只管往大里撑。所有号称能缩 XFS 的第三方手段都不建议在生产盘上试。真要缩，就走备份—重建—恢复，把停机时间算进计划里。

根目录能不能用 XFS？能，而且很常见。RHEL／CentOS 7 之后的默认安装就是把 / 和 /boot 做成 XFS，跑了这么多年没什么可担心的。选 ext4 做根的理由不是「XFS 不稳」，而是 ext4 保留了缩容的可能、救援环境下工具更熟悉。还有，/boot 涉及引导程序的兼容性，走发行版默认最省事。

数据库盘到底选哪个？两个都是主流，别在性能上纠结。真要挑，看你的运维习惯和容量规划：DBA 团队熟悉 ext4、或者库可能会缩，就 ext4；确定只增不减、并且你打算把数据目录单独挂一块大盘长期用，XFS 也很好。比起文件系统，更影响数据库表现的是底层是不是 SSD、RAID 卡的写缓存有没有电池保护、以及 I/O 调度策略，这些的权重高得多。

日志盘一天几千万个小文件怎么办？选 XFS 是最省事的一档，inode 动态分配，不用担心 inode 提前见底。如果因为历史原因必须留在 ext4 上，那就在格式化时把 ratio 压到 4KB 甚至更低，或者用 -N 按预估量给足；同时把 df -i 纳入监控。还有个更治本的办法：改掉「一个小文件一条日志」的落盘方式，按小时或按大小滚动成较少的几个大文件，inode 压力和文件系统压力会一起降下来。

已经上了 LVM，还能改文件系统吗？逻辑卷本身不用动，但文件系统不能在原地改类型——你只能备份、在 LV 上重新 mkfs、再恢复。LVM 帮上忙的地方是「容量调整」：lvextend 之后接 resize2fs 或 xfs_growfs 都能在线扩；但 lvreduce 这条路，只有 ext4 能配合着走完（先 resize2fs 缩文件系统，再缩 LV），XFS 上这条路是断的。所以在 LVM 上做规划时，文件系统选型依然是个一次性决定。

这篇里的文件系统机制依据是什么，哪些要你在自己机器上核

本文所述为 Linux 常见文件系统的公开特性说明，包括 XFS 只能在线增大不支持缩小、ext4 缩小需卸载且须先跑 e2fsck、ext4 的 inode 在格式化时按 ratio 固定而 XFS 为动态分配并受 inode 最大比例参数限制、ext4 的 dir_index 与 XFS 的 B+ 树加分配组、两种文件系统在日志方式上的差异以及 e2fsck／xfs_repair 的前提动作。这些都属于长期公开的技术文档内容，本文没有做任何性能对比，也没有给出任何对比数字。

需要你自己核的部分：所有容量上限数字（文件系统上限、单文件上限）都会随内核版本、块大小与格式化参数不同而变化，请以你实际系统上的 man mkfs.ext4、man mkfs.xfs、man resize2fs、man xfs_growfs 以及内核文档为准；inode ratio 的实际默认值、imaxpct 的默认值、dir_index 与 ftype 是否开启，也请在你自己的机器上用 tune2fs -l、xfs_info 逐项确认一遍再动手格式化。文中提到的目录用途建议是典型部署思路，并非特指某一真实客户环境。

关于可用性的部分：一万网络（深耕 IDC 19 年，成立于 2007 年）提供独立服务器租用，盘的数量与大小可按需配置，分区与格式化参数由使用者自行决定，具体配置以官网实时显示为准。本文未引用任何具体型号、配置与价格信息。说到底也就一句话：先想清楚三年后要不要缩、这块盘的用途是小文件还是大文件，再决定文件系统——选错的成本不在装机的那几秒，而在后期改造的那次停机。