我有一台新的 Ubuntu 20.04 HPE DL360 Gen10 服务器，用于替换旧的 16.04 HPE DL360 Gen9 服务器，以运行 Graphite 和 Grafana。旧服务器有一个 2 TB 硬件 RAID10（4 x 1 TB SSD）ext4 文件系统，用于存储 whisper 数据，而新服务器的文件系统是一个 ~2.1 TB md 软件 RAID10（6 x 800 GB MZXL5800HBHQ-000H3 NVMe SSD）。数据大约有 110 万个 .wsp 文件，分布在大约 260 万个目录中（有些地方大约有 9 层深）。
尝试访问某些目录（在它们创建之后）会导致如下错误：
find: ‘/data/graphite/whisper/aggro/30d/1m/threads_running_current/dSystem/SysPerfSrv1/10/5/17/32’: Bad message
系统日志中出现以下错误：
Dec 21 08:31:34 graphite.example.com kernel: EXT4-fs warning (device md0p1): ext4_dirblock_csum_verify:370: inode #111153487: comm find: No space for directory leaf checksum. Please run e2fsck -D.
Dec 21 08:31:34 graphite.example.com kernel: EXT4-fs error (device md0p1): htree_dirblock_to_tree:997: inode #111153487: comm find: Directory block failed checksum
这是我在过去几个月构建此服务器并从旧服务器迁移数据以来第二次遇到此问题。第一次，我运行了命令e2fsck -y -D /dev/md/0p1，最终修复了文件系统，但将大约 85,000 个文件或部分文件恢复到lost+found。
我已经向 HPE 确认这不是硬件问题（通过从 iLO 提交 AHS 日志，该日志还确认磁盘使用的是最新固件，根据我的研究，这可能是一个问题），所以我不知道是什么原因造成的。尽管目录总数如此之多，但没有单个目录的直属子目录超过 64k，但我仍然不排除某种文件和/或目录限制，尽管我从未在之前的服务器上看到过这个问题，它是一个硬件 raid，但也是一个 4 年前的操作系统（再次，Ubuntu 16.04 与 20.04）。但是，我在 AWS EC2 实例上有一个类似的服务器，其中 whisper 数据位于大型 EBS 卷上，文件和目录数量相似，我也没有在那里看到问题。
对于进一步排除故障还有什么建议吗？
编辑：根据要求，文件系统数据和 inode 使用情况和空闲情况：
root at graphite in ~ # df -lhi /data/graphite
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/md0p1 140M 3.8M 136M 3% /data/graphite
root at graphite in ~ # df -lh /data/graphite
Filesystem Size Used Avail Use% Mounted on
/dev/md0p1 2.2T 580G 1.5T 28% /data/graphite
编辑：进一步可能有用的信息，要点显示输出tune2fs -l /dev/md0p1：https://gist.github.com/justinclloyd/9b23227015bc6589cb4c226885226d84
编辑 2：重建文件系统（但不包括软件 RAID 设备）、从实时系统复制 540 GB 数据并让其静置一段时间且几乎没有 I/O（只有服务器本身在写入 Graphite 指标，没有从其他服务器接收任何指标）后，我现在看到“错误消息”和其他错误再次出现，并且出现在未写入的目录中。这让我相信问题确实出在软件 RAID 上，也许与 Graphite 的写入 I/O 模式有关，尽管我没有真正的方法来证实这一点。
编辑 3：我收到的故障排除建议是尝试不同的文件系统类型，例如 XFS 或 ZFS。我继续删除 mdadm 阵列，并创建了一个包含磁盘和文件系统的 ZFS 池，然后复制回数据，现在让 Graphite 运行（尽管 I/O 很少），看看问题是否再次出现。
编辑 4：虽然我从来没有弄清楚为什么基于 ext4 mdadm 的文件系统会出现这些损坏问题，但经过几周的监控后，转移到 ZFS 似乎已经消除了这个问题。