最近我使用 mdadm 创建了一个 RAID5：
mdadm --create /dev/md0 -l 5 -n 4 -c 512 /dev/sdb /dev/sdc /dev/sdd /dev/sde
通常的调整可以加速初始同步：
echo 32768 > /sys/block/md0/md/stripe_cache_size
然后我让它继续同步直到完成。
接下来，我在设备上创建并调整了一个文件系统，针对一些大文件进行了优化：
mke2fs -t ext4 -e remount-ro -Elazy_journal_init=0,lazy_itable_init=0,stride=128,stripe_width=384 -i 524288 /dev/md0
tune2fs -r0 -c0 -i12m -o ^acl,journal_data_writeback,nobarrier /dev/md0
我在 mkfs 时强制写入 ext4 数据结构，以防止通过后台初始化产生错误的基准测试。/etc/mke2fs.conf来自 Debian 9 并且未被我触及。
然后我挂载了这个文件系统：
mount -o mand,nodev,stripe=1536,delalloc,auto_da_alloc,noatime,nodiratime /dev/md0 /mnt
到目前为止一切都很好。
当我将（大）文件写入该文件系统时，iostat -x 2显示一个磁盘的加载量为 100％，其余磁盘大部分处于空闲状态。
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdb 0.00 0.00 73.50 539.00 294.00 2155.25 8.00 146.37 238.01 188.30 244.79 1.63 100.00
sdc 0.00 0.00 4.50 545.00 18.00 2179.25 8.00 2.92 5.31 3.56 5.32 0.08 4.40
sdd 0.00 0.00 2.50 545.50 10.00 2181.25 8.00 2.90 5.30 4.00 5.31 0.09 4.80
sde 0.00 0.00 33.50 514.50 134.00 2057.25 8.00 2.96 5.39 0.12 5.74 0.07 4.00
md0 0.00 0.00 0.00 67.50 0.00 56740.00 1681.19 0.00 0.00 0.00 0.00 0.00 0.00
当我再次执行所有这些步骤但省略创建日志（mke2fs -O^has_journal作为附加参数）时，磁盘负载会均匀分布在所有磁盘上。因此，日志似乎没有分布在整个磁盘上。
如何才能从日志中获益，同时又能通过均匀地加载所有磁盘（或多或少）来获得更快的速度？这是否可行，同时强制所有数据通过日志日志数据回写？
我考虑过将日志外部化，但我应该把它放在哪里呢？RAM 磁盘是易失性的，不好。几年前，有真正的基于 DRAM 的固态磁盘，并配有电池备份，但似乎这些都被基于闪存的 SSD 介质所取代。DRAM 在主要面向写入的负载下没有任何缺点。
附录：磁盘上的日志为1024M，根据本文。因此，这显然不应该是仅考虑规模的局部性问题。
答案1
从您提供给 mke2fs 和 mdadm 的条带参数来看，您指定的块大小似乎为 512k。您看到的问题是，虽然日志分布在所有磁盘上（根据文件系统大小，它将介于 128MB 到 1024MB 之间），但每次提交时需要写入日志的数据量不会很大。对于连续写入工作负载，它通常只有几个块；最多几十个。问题是这些写入必须在每次提交时同步写入磁盘，默认情况下每五秒发生一次（这意味着崩溃后，您将最多丢失 5 秒的 mdatadata 更新）。让我们假设平均事务大小为 8 个块。这意味着在同步日志提交移动到下一个磁盘之前，需要 16 次提交，即 80 秒，然后那磁盘将获取所有同步更新。
不过，还有其他事情发生。全部磁盘 (sdb..sde) 的大小为 8 个扇区，即 4k。平均请求大小进入md0 设备为 840k，这个大小还算可以，但不算大。出于某种原因，这些写入在发送到磁盘之前被分解为 ~500 个微小的 4k 写入。这是最大的问题，使用较大的块大小可能有害无益。
您使用的是哪种磁盘？它们如何连接到您的系统？解决这个问题将是您能做的最有帮助的事情。
至于将外部日志放在哪里，一般建议使用连接到系统的小型 SSD。