同一批型号的四块盘A 机器格式化完跑得很好B 机器照抄命令却在小文件场景下明显吃力。这类差异通常出在装机那天mkfs.xfs和fstab里那几个没人细看的选项。磁盘准备是安装流程里唯一一个不可逆的步骤。mkfs一跑原设备上的数据就没了所以它的参数值得在动手前花半小时弄清楚。官方给的那条 mkfs 命令里每个选项都在管一件事RustFS 的磁盘准备页给的格式化和挂载流程命令是这样的sudomkfs.xfs-f-isize512-nftype1-LRUSTFS0 /dev/sdb三个选项各有分工。-i size512把 inode 大小设为 512 字节一个 inode 里能存的东西变多小对象的元数据就能少占一层间接块。-n ftype1给目录项加上文件类型标记目录遍历时就不必再对每一项单独 stat 一次。-f是强制设备上已有文件系统时覆盖它也正是因此它不可撤销。RustFS 的文档明确要求每块数据盘建成独立的 XFS 文件系统、带稳定标签和挂载点并且这一步要在配RUSTFS_VOLUMES之前在所有节点做完。文档还专门标了危险提示mkfs.xfs会擦除所选设备确认设备名、备份需要的数据、确认这块盘没被操作系统在用然后再继续。用 LABEL 挂载还是用 UUID文档给了两套fstab写法先看按标签的那条LABELRUSTFS0 /data/rustfs0 xfs defaults,noatime,nodiratime 0 0紧接着它就给了不推荐这个写法的理由更可靠的做法是按文件系统 UUID 挂载因为 UUID 唯一标识文件系统标签重复或者 Linux 设备名变化都不会导致挂错盘。文档推荐的写法是取格式化后的 UUID 再写进去sudoblkid-sUUID-ovalue /dev/sdbUUIDfilesystem-uuid /data/rustfs0 xfs defaults,noatime,nodiratime 0 0挂载写完用sudo mount -a全量挂载再用findmnt /data/rustfs0确认结果。多盘的情况下一个 UUID 对应一条fstab记录别合并。挂载选项里这两项管的是同一件事的不同半边。noatime不更新文件的访问时间nodiratime只管目录两者合起来就是所有 inode 都不动访问时间。读操作不再顺带写 metadata对高频读的负载是纯收益没有反例。留一个细节mount 手册对noatime的定义是「对所有 inode 类型都生效目录也一样因而隐含nodiratime」。也就是说新内核上再补写nodiratime这一项没有额外效果属于照着老资料抄下来的保命写法反过来在只认部分语义的老内核上多写它又确实能补上目录那半边。两种情况下留着都不碍事不必为了它专门改 fstab。「每块盘一个独立文件系统」这个要求也值得解释一下。把四块盘合成一个 XFS容量和 inode 看着都更宽裕但坏一块盘的代价变了要修复就得把整个文件系统所在的设备摘下来而这四块盘在RUSTFS_VOLUMES里是同一个纠删集的不同分片。独立文件系统之后每块盘的设备和路径都能单独换一次替换和排查都少一层变量。跨节点要统一的不只是参数还有位置分布式部署里最容易出问题的地方是各节点的盘看起来都格式化对了但「哪块盘在哪个目录」对不上。文档在最后一步写的验证要求是确认每个预期的挂载点都用了 XFS 且有足够空闲空间并且在配置RUSTFS_VOLUMES时使用这些验证过的挂载路径分布式部署中保持磁盘标签和挂载路径在各节点一致。RUSTFS_VOLUMES是按路径引用的不是按设备名引用的。node1 写/data/rustfs0、node2 写/data/disk0配置看着都能起来但落到纠删集上就是另一种分布了。要紧的是这类错位不会报错。路径不一致的时候服务照样正常启动控制台照样能读写监控上也不见得有哪一项会飘红。问题出在容错能力上分片没有按设计的位置散开某几块盘同时失效的概率被悄悄抬高等第一次真实故障来临才发现重建跑不完。这种问题事后极难查因为集群已经跑了好几个月布局信息还写进了存量对象的元数据里想改只能重新传一份数据。装机那天花十分钟核对路径清单是这条链路上性价比最高的一步。还有一种情况更隐蔽四块盘都挂对了路径但某台机器上的盘顺序换过/dev/sdb现在指向的是另一块盘。按设备名写进脚本的风险就在这里而按 UUID 挂载能顺带把这个隐患也挡掉因为 UUID 跟着文件系统本身走跟它现在被系统认作哪个名字无关。硬件清单页给了另一套参数它和上面那条不冲突硬件清单页里的文件系统示例长这样mkfs.xfs-f-Lrustfs_disk1-dsu256k,sw10/dev/sdbUUIDxxxx /mnt/disk1 xfs defaults,noatime,nodiratime,logbsize256k 0 0两组命令出现在同一份文档的两个页面里看上去像前后矛盾实际管的是不同层面。磁盘准备页那组管的是 inode 和目录项这条多出来的-d su256k,sw10管的是条带数据按 256 KB 的条带单元、10 个宽度的布局写配合挂载选项里的logbsize256k让日志也按同样粒度落盘。它属于装机前的决定事后想改只能重新格式化。不过这条命令别整段复制。sw是条带宽度按su的倍数算写成 10 就是十条带轮转后面的数字应该等于这个纠删集里的盘数。填错了不会有任何报错代价只是条带跟真实布局错开读写要多绕一圈性能比干脆不写还差。文档给的sw10对应的是它自己那套布局照抄到 4 盘或 16 盘的集群上等于把一个用不上的数字硬塞进去。再说收益面。条带化对大顺序 IO 的收益是明显的几个 G 的媒体文件顺序过一遍就能看出来。换成海量小对象一个请求只有几 KB 到几十 KB根本走不满一条带参数写对了也剩不下什么写错了反而添乱。小对象为主的集群直接用磁盘准备页那组命令就好不必为了迁就一个用不上的布局去记新参数。存储控制器那边还有两条文档建议RAID 全部关掉走直通模式SSD 预留 20% OP 空间。第一条和纠删码本身就是打架的RAID 的冗余逻辑和 EC 的分片冗余叠在一起既浪费容量又让故障判定变得含糊关掉它是顺理成章的。但「直通」这件事得在装机现场确认到位不同厂商的叫法不一样有些 HBA 界面里叫 JBOD有些只在 RAID 层级里留了一个 RAID-0 单盘的入口。RAID-0 单盘看着确实是一块盘交给系统控制器那层逻辑并没有真的停下来盘上报回来的是虚拟设备。现场验证也就两步看内核认出来的是不是原生块设备挑一块盘直接跑一下smartctl -a /dev/sdX能读到完整 SMART 就说明控制器没插手落到 RAID-0 单盘上OP 空间和坏盘信息都隔着一层读到的也不是原始信息。那 20% OP 也容易理解偏。OP 是盘自己物理上划出来的一块空闲区域用来做垃圾回收和磨损均衡由闪存控制器在盘内部管理XFS 层面看不见也管不着。文档说的「预留」说的是盘这一侧的安排不是让上层业务少写两成数据。靠「只写到八成满」去模拟 OP起不到任何提高耐久性的作用白白丢掉 20% 容量。算出来的可用容量不能直接拿去用EC 配置页给容量公式的时候特意在后面加了一段保留说明估算结果要为 XFS、对象元数据、版本化、未完成的上传、重建过程以及正常运维余量留出额外空间把它当作规划估算不是保证可用的空间。文档给的算例是 16 块 10 TiB 盘组成单个 16 盘纠删集配EC:4算出来约 120 TiB这个 120 TiB 是几何意义上的上限不是盘上能写进去的量。这一段扣减里最容易漏掉的是「未完成的上传」。分片上传中断之后留下的是残留分片它们不占对象配额却真占着盘清理脚本没跟上就会一直挂着。版本化也是同理同一个 key 反复覆盖写产生的历史版本都留在盘上而业务侧往往只关心最新那份。这两项加起来通常能吃掉几个百分点规模越大越可观。按这个数直接报给业务方「这个集群能放 120 TiB」跑到一个季度就可能遇到写满。更稳的做法是把这条公式算出的结果再往下压一档剩下的部分作为重建窗口期的缓冲。文档没给出具体留多少可以照一个通用标尺来定单个文件系统用到 75% 到 80% 就把它当扩容信号别往 90% 以上顶。留这一档不是为了防写入失败是为了给重建留地方。heal 期间要读校验片、把修复数据写回失效盘这批 IO 占用的空间和当时的余量直接挂钩。已经用到九成的盘坏一块之后修复数据常常写不进去本该自动完成的步骤停在那儿最后只能人工换盘、人工重建。到这一步容量吃紧带来的后果就不再是「少能写一点」而是出故障时恢复能力跟着一起没了。装完之后跑这四条确认格式化是静态操作验证也简单四步就够sudomount-afindmnt /data/rustfs0df-hT/data/rustfs0sudoxfs_info /data/rustfs0df -hT看文件系统类型和剩余空间。xfs_info看的是 inode 大小、日志块大小这些实际生效值和命令里写的参数对得上才算数它输出里的 fsgeoms 一行最直接。用的时候注意xfs_info只认挂载点。习惯性把/dev/sdb传进去是拿不到结果的命令不报错、输出也是空的很容易被读成「这台机器配置正常」。忘了挂载点就先findmnt /data/rustfs0查一下再复制过来。还有一个收尾动作值得做把mkfs和mount用过的那几个参数记进部署文档。换盘的时候会重复这一段操作记下来能省掉重新查文档的时间。按 UUID 挂载的情况下新盘换上来的第一步是blkid拿到 UUID然后改 fstab再mount -a。整个过程不涉及任何设备名也不会因为盘序变化而写错挂载点。至于 LABEL 那条路官方推荐 UUID 的其中一个理由是标签可能重复而设备名会随盘序变化。这两件事在换盘现场都真实发生选用 UUID 等于把两类意外的排查成本一起降下来。排错上还有一条提醒。磁盘准备这一步做完之后如果启动阶段报出卷无法访问先看df -hT的输出里那一行有没有挂载、文件系统类型是否正确再看xfs_info里的 inode 大小和日志块大小是不是当初设置的那组别忘了我上面说过的那条xfs_info记得传挂载点。这三项对不上基本可以断定是格式化参数没生效重跑一次mkfs比去查服务配置快。