我/dev/sda使用 1MiB 块大小读取。Linux 似乎将 IO 请求限制为512KB平均大小为 512KiB。这里发生了什么？这种行为是否有配置选项？
$ sudo dd iflag=direct if=/dev/sda bs=1M of=/dev/null status=progress
1545601024 bytes (1.5 GB, 1.4 GiB) copied, 10 s, 155 MB/s
1521+0 records in
1520+0 records out
...
当我的dd命令正在运行时，rareq-sz是 512。
rareq-sz 向设备发出的读取请求的平均大小（以千字节为单位）。
——
man iostat
$ iostat -d -x 3
...
Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util
sda 309.00 0.00 158149.33 0.00 0.00 0.00 0.00 0.00 5.24 0.00 1.42 511.81 0.00 1.11 34.27
dm-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
...
内核版本是5.1.15-300.fc30.x86_64. max_sectors_kb是 1280。
$ cd /sys/class/block/sda/queue
$ grep -H . max_sectors_kb max_hw_sectors_kb max_segments max_segment_size optimal_io_size logical_block_size chunk_sectors
max_sectors_kb:1280
max_hw_sectors_kb:32767
max_segments:168
max_segment_size:65536
optimal_io_size:0
logical_block_size:512
chunk_sectors:0
默认情况下，我使用 BFQ I/O 调度程序。我也尝试在echo 0 | sudo tee wbt_lat_usec. 然后我也尝试在echo mq-deadline|sudo tee scheduler. 结果保持不变。
除了 WBT，我使用了两个 I/O 调度程序的默认设置。例如，对于mq-deadline，iosched/read_expire是 500，相当于半秒。
在上次测试期间（mq-deadline，禁用 WBT），我运行了btrace /dev/sda. 它显示所有请求被分成不相等的两半：
8,0 0 3090 5.516361551 15201 Q R 6496256 + 2048 [dd]
8,0 0 3091 5.516370559 15201 X R 6496256 / 6497600 [dd]
8,0 0 3092 5.516374414 15201 G R 6496256 + 1344 [dd]
8,0 0 3093 5.516376502 15201 I R 6496256 + 1344 [dd]
8,0 0 3094 5.516388293 15201 G R 6497600 + 704 [dd]
8,0 0 3095 5.516388891 15201 I R 6497600 + 704 [dd]
8,0 0 3096 5.516400193 733 D R 6496256 + 1344 [kworker/0:1H]
8,0 0 3097 5.516427886 733 D R 6497600 + 704 [kworker/0:1H]
8,0 0 3098 5.521033332 0 C R 6496256 + 1344 [0]
8,0 0 3099 5.523001591 0 C R 6497600 + 704 [0]
X -- split在 [软件] raid 或设备映射器设置上，传入的 i/o 可能跨越设备或内部区域，需要将其分成更小的部分以供服务。这可能表明由于该 raid/dm 设备设置不当而导致性能问题，但也可能只是正常边界条件的一部分。dm 在这方面尤其糟糕，并且会克隆大量的 i/o。
——
man blkparse
iostat忽略%util号码。在这个版本中它被破坏了。（`dd` 正在全速运行，但我只看到 20% 的磁盘利用率。为什么？）
我认为 由于基于 %utilaqu-sz也受到影响。虽然我认为这意味着它在这里会大三倍（100/34.27）。
忽略svtm号码。“警告！不要再相信这个字段。这个字段将在未来的 sysstat 版本中删除。”
为什么我的 IO 请求的大小被限制在 512K 左右？
我假设 I/O 被限制在“大约”512 KiB，因为它的提交方式和达到的各种限制（在这种情况下/sys/block/sda/queue/max_segments）。提问者花时间提供了各种辅助信息（例如内核版本和blktrace输出），让我们可以猜测这个谜团，让我们看看我是如何得出这个结论的。
为什么 [...] 限制在512K左右？
关键是要注意提问者在标题中小心地说了“关于”。虽然iostat输出让我们认为我们应该寻找 512 KiB 的值：
Device [...] aqu-sz rareq-sz wareq-sz svctm %util
sda [...] 1.42 511.81 0.00 1.11 34.27
在blktrace（通过blkparse）为我们提供了一些精确值：
8,0 0 3090 5.516361551 15201 Q R 6496256 + 2048 [dd]
8,0 0 3091 5.516370559 15201 X R 6496256 / 6497600 [dd]
8,0 0 3092 5.516374414 15201 G R 6496256 + 1344 [dd]
8,0 0 3093 5.516376502 15201 I R 6496256 + 1344 [dd]
8,0 0 3094 5.516388293 15201 G R 6497600 + 704 [dd]
8,0 0 3095 5.516388891 15201 I R 6497600 + 704 [dd]
（我们通常期望单个扇区的大小为 512 字节）因此dd，大小为 2048 个扇区（1 MiByte）的扇区 6496256的读取 I/O被分成两部分 - 从扇区 6496256 开始读取 1344 个扇区，另一个读取从扇区 6497600 开始读取 704 个扇区。因此，请求拆分前的最大大小略大于 1024 个扇区（512 KiB） ……但为什么呢？
提问者提到了内核版本的5.1.15-300.fc30.x86_64. 在Google 上搜索 linux split block i/o kernel会出现Linux Device Drivers, 3rd Edition 中的“Chapter 16. Block Drivers”，其中提到
[...]
bio_split可用于将 a 拆分bio为多个块以提交给多个设备的调用
虽然我们没有拆分bios 因为我们打算将它们发送到不同的设备（以 md 或设备映射器可能的方式），但这仍然为我们提供了一个探索的领域。在LXR 的 5.1.15 Linux 内核源中搜索bio_split包含文件的链接block/blk-merge.c。在该文件中blk_queue_split()，对于函数调用的非特殊 I/O 有blk_bio_segment_split().
（如果你想休息一下，现在是探索 LXR 的好时机。我将继续下面的调查，并尝试更简洁地前进）
在blk_bio_segment_split()该max_sectors变量最终来自对准返回的值blk_max_size_offset()，在和看起来q->limits.chunk_sectors和如果的零点然后就返回q->limits.max_sectors。四处点击，我们会看到max_sectors是如何从max_sectors_kbinqueue_max_sectors_store()中block/blk-sysfs.c导出的。回到blk_bio_segment_split()，max_segs变量来自queue_max_segments()which 返回q->limits.max_segments。继续往下blk_bio_segment_split()看，我们看到以下内容：
bio_for_each_bvec(bv, bio, iter) {
根据block/biovecs.txt我们正在迭代多页 bvec。
if (sectors + (bv.bv_len >> 9) > max_sectors) {
/*
* Consider this a new segment if we're splitting in
* the middle of this vector.
*/
if (nsegs < max_segs &&
sectors < max_sectors) {
/* split in the middle of bvec */
bv.bv_len = (max_sectors - sectors) << 9;
bvec_split_segs(q, &bv, &nsegs,
&seg_size,
&front_seg_size,
§ors, max_segs);
}
goto split;
}
因此，如果 I/O 大小大于max_sectors_kb（在提问者的情况下为 1280 KiB），它将被拆分（如果有空闲段和扇区空间，那么我们将在拆分之前尽可能多地填充当前 I/O）将其分成段并尽可能多地添加）。但在提问者的情况下，I/O“仅”1 MiB，小于 1280 KiB，所以我们不在这种情况下......进一步向下我们看到：
if (bvprvp) {
if (seg_size + bv.bv_len > queue_max_segment_size(q))
goto new_segment;
[...]
queue_max_segment_size()返回q->limits.max_segment_size。鉴于我们之前看到的一些 ( if (sectors + (bv.bv_len >> 9) > max_sectors))bv.bv_len将以字节为单位（否则为什么我们必须将其除以 512？），而提问者说的/sys/block/sda/queue/max_segment_size是 65336。如果我们知道什么是值bv.bv_len......
[...]
new_segment:
if (nsegs == max_segs)
goto split;
bvprv = bv;
bvprvp = &bvprv;
if (bv.bv_offset + bv.bv_len <= PAGE_SIZE) {
nsegs++;
seg_size = bv.bv_len;
sectors += bv.bv_len >> 9;
if (nsegs == 1 && seg_size > front_seg_size)
front_seg_size = seg_size;
} else if (bvec_split_segs(q, &bv, &nsegs, &seg_size,
&front_seg_size, §ors, max_segs)) {
goto split;
}
}
do_split = false;
因此，对于每个bv我们检查它是单页还是多页 bvec（通过检查其大小是否 <= PAGE_SIZE）。如果它是单页 bvec，我们会在段计数中添加一个并进行一些簿记。如果是多页 bvec，我们会检查它是否需要拆分成更小的段（代码中的代码会与之bvec_split_segs()进行比较get_max_segment_size()，在这种情况下，这意味着它将将该段拆分为不大于 64 KiB 的多个段（之前我们说的/sys/block/sda/queue/max_segment_size是 65336）但是有必须不超过 168 ( max_segs) 个段。如果bvec_split_segs()达到了段限制并且没有覆盖所有bv的长度，那么我们将跳转到split。但是，如果我们假设我们采用goto split 如果我们只生成 1024 / 64 = 16 个段，所以最终我们不必提交少于 1 MiB 的 I/O，所以这不是提问者的 I/O 经历的路径......
向后工作，如果我们假设“只有单页大小的段”，这意味着我们可以推导出bv.bv_offset + bv.bv_len<= 4096 并且因为bv_offset是unsigned intthen 这意味着 0 <= bv.bv_len<= 4096。因此我们也可以推导出我们从未采用过条件体导致goto new_segment更早。然后我们继续得出结论，原始 biovec 必须有 1024 / 4 = 256 个片段。256 > 168 所以我们会导致跳转到split刚刚之后，new_segment从而生成一个 168 段的 I/O 和另一个 88 段的 I/O。168 * 4096 = 688128 字节，88 * 4096 = 360448 字节但那又怎样？好：
688128 / 512 = 1344
360448 / 512 = 704
我们在blktrace输出中看到的数字是什么：
[...] R 6496256 + 2048 [dd]
[...] R 6496256 / 6497600 [dd]
[...] R 6496256 + 1344 [dd]
[...] R 6496256 + 1344 [dd]
[...] R 6497600 + 704 [dd]
[...] R 6497600 + 704 [dd]
因此，我建议dd您使用的命令行导致 I/O 形成单页 bvecs，并且由于已达到最大段数，I/O 的拆分发生在每个 I /O 的边界为672 KiB /O。
我怀疑如果我们以不同的方式提交 I/O（例如，通过缓冲 I/O）从而生成多页 bvec，那么我们会看到不同的分割点。
这种行为是否有配置选项？
排序 -/sys/block/<block device>/queue/max_sectors_kb是对通过块层提交的正常 I/O 在拆分之前可以达到的最大大小的控制，但这只是众多标准中的一个 - 如果达到其他限制（例如最大段），则基于块的 I/O 可以拆分成更小的尺寸。此外，如果您使用原始 SCSI 命令，则可以提交最大/sys/block/<block device>/queue/max_hw_sectors_kb大小的 I/O，但随后您绕过了块层，更大的 I/O 将被拒绝。
事实上，您可以Ilya Dryomovmax_segments在 2015 年 6 月的 Ceph 用户线程“krbd 将大型 IO 拆分为较小的 IO”中描述此限制，并且后来针对rbd设备进行了修复（其本身后来被修复）。
上述内容的进一步验证来自内核块层维护者 Jens Axboe题为“当 2MB 变为 512KB ”的文档，其中有一个标题为“设备限制”的部分更简洁地涵盖了最大段限制。
| 归档时间： |
|
| 查看次数： |
4149 次 |
| 最近记录： |