当块大小很小时,为什么我的 dd 很慢?

当块大小很小时,为什么我的 dd 很慢?

根据网上的文章,mount withnobarrier会加快磁盘速度:

  1. 将小块数据写入 img (使用barrier):慢的

    # dd if=/dev/zero of=xfs.img bs=1024 count=20000
    # mkfs.xfs xfs.img
    # mkdir -p xfs
    # mount -o loop xfs.img xfs
    # dd if=/dev/zero of=output bs=32K count=1 conv=fsync
    32768 bytes (33 kB) copied,0.01037167 s, 2.4 MB/s
    
  2. 将小块数据写入img( -o nobarrier):快速地

    # dd if=/dev/zero of=xfs.img bs=1024 count=20000
    # mkfs.xfs xfs.img
    # mkdir -p xfs
    # mount -o loop,nobarrier xfs.img xfs
    # cd xfs ; dd if=/dev/zero of=output bs=32K count=1 conv=fsync
    32768 bytes (33 kB) copied, 0.000608567 s, 53.8 MB/s
    

现在,我想重新安装/以添加nobarrier标志。所以我编辑/etc/fstab

/dev/sda2      /      xfs     defaults,nobarrier    0    0

然后mount -o remount /

但结果并不好:

# pwd
/root
# dd if=/dev/zero of=output bs=32K count=1 conv=fsync
32768 bytes (33 kB) copied, 0.00811443 s, 4.0 MB/s

我无法理解为什么nobarrier适用于 dd-img,但不适用于现有分区。谁能告诉我吗?

答案1

使用环回文件系统时,必须考虑创建它的文件系统。具体来说,尽管在回送文件系统上调用了 fsync,但内核可能不会立即将回送文件系统的写入页面刷新到包含文件系统的磁盘。这些写入可能会sync在环回上进行,但它们可能作为包含文件系统的内存中的脏页。

现在,nobarrier我不确定该选项如何与环回驱动程序以及包含的文件系统交互。因此,我做了一个实验。我添加了挂载包含文件系统的变量sync。结果如下。

(所有输出来自dd if=/dev/zero of=xfs/output bs=32K count=10000 conv=fsync

  1. 包含 fs async, 环回barrier

    32768000 bytes (33 MB) copied, 0.401873 s, 81.5 MB/s
    
  2. 包含 fs async, 环回nobarrier

    32768000 bytes (33 MB) copied, 0.0414423 s, 791 MB/s
    
  3. 包含 fs sync, 环回barrier

    32768000 bytes (33 MB) copied, 71.5749 s, 458 kB/s
    
  4. 包含 fs sync, 环回nobarrier

    32768000 bytes (33 MB) copied, 70.6415 s, 464 kB/s
    

当包含 fs 时,barrier和速度变化很大。然而,当包含的文件系统受益于页面缓存并且不受益于页面缓存时,加速大部分会消失。nobarrierasyncsync

结论是测试barriernobarrier使用环回文件系统不会有帮助。包含文件系统与内核缓存的交互将会受到阻碍。我怀疑内核缓存并不是唯一在使用环回测试性能时导致错误结果的因素。

答案2

在 Linux 上要小心这样的假设。 Linux 的优化是为了营造文件系统速度快的印象,而不是优化实际速度。

给人高速印象的原因是,当写入程序完成时,文件数据(在许多情况下)并不在磁盘上。换句话说,你无法分辨您计量的内容进行测试,因为您不知道 dd 完成后的文件系统状态。

如果您想获得可比较的结果,则需要设置一个不受指定问题影响的性能测试,因此您需要编写一个至少是计算机中本地 RAM 大小两倍的文件。

相关内容