决定随机写入或顺序写入的因素

时间:2018-12-12 00:52:05

标签: io

我了解随机写入和顺序写入的成本,但是谁[OS或存储驱动程序或任何其他组件]决定将write()系统调用最终以顺序写入还是随机写入的方式进行。 我所说的RAID 5 SAN存储运行环境是作为多个LUN提供给服务器的。

谢谢

Soumya

1 个答案:

答案 0 :(得分:0)

由OS /存储阵列控制器发出的I / O请求的顺序位置和大小,在潜在地基于页面高速缓存/存储控制器高速缓存聚合多个单独的写入之后,会将写入转换为随机写入或顺序写入。

对于读取,有一些API提示(posix_fadvise)可以在顺序访问的情况下触发预读。

对于写入,没有专用的标志来告知操作系统或下面的层有关写入的随机或顺序性质。

从逻辑上讲,一次写入可以视为随机写入和顺序写入,因为它始终会影响特定数量的连续字节。在同步和直接I / O的情况下,写入不会基于缓存而延迟,因此实际的执行顺序和写入时间至关重要。在任何时间点,块设备都有一个包含零个或多个写入的队列。这些写操作的大小和位置决定了它们是随机的还是顺序的。如果要处理的队列包含影响不同的非连续块的小写操作,则它们表示随机写操作,并且将“成为”随机写操作,因为这样会导致有限数量的连续块写操作。另一方面,如果这些假定的随机写入中的一个较大,并因此覆盖了大量连续块,则该写入表示顺序写入,因为结果将触发大量连续块写入。

这种情况有些细微差别,因为这些I / O请求是按特定顺序执行的。如果磁盘队列包含对块1, 2, 3, 4, 10, 11, 12, 13的写操作,则会触发两个较大的写操作,可以将其视为顺序写操作。但是,如果应用程序发出的写入顺序不同(例如由于多线程),则磁盘1, 10, 2, 11, 3, 12, 4, 13队列将基本上触发10次写操作,即使应用程序发出了两次写操作,也可以将其视为随机写操作从逻辑POV顺序写入。

情况从另外两个方面发生了变化/显着改善:

  • 使用OS页面缓存/存储控制器缓存来延迟写入
  • 使用I / O调度对写进行重新排序

在异步I / O(通常为默认设置)的情况下,写入仅会在调用期间影响OS页面缓存,并且将在后台执行或在触发同步操作(例如fsync)时执行。对于可以使用类似策略延迟写入的存储控制器缓存,也是如此。

使用写入延迟,如果单个写入会影响连续的块,并且即使它们原本是随机写入,也可能会变成顺序写入,因此可以将它们合并为大写入。即使这些写操作代表在不同的SQL语句过程中更新单个数据库页面的数据库的随机写操作,但由于时机恰到好处,如果可以汇总它们,它们也可以成为顺序写操作。

如前所述,写入顺序会影响这种情况。在写延迟的情况下,OS和/或控制器可以根据适当的标准自由地对写进行重新排序。重新排序过程可能会偏向于特定的块,较小的写入,较旧的写入以及具有更好顺序局部性的写入。如上面的示例中所示,如果调度策略优先考虑顺序,则该顺序可以将本应被认为是顺序的写入变为随机写入。

在SAN环境中,写操作是

  1. 由应用触发
  2. 由操作系统缓存/聚合/重新排序
  3. 由HBA转发
  4. 由存储阵列控制器缓存/聚合/重新排序
  5. 由磁盘聚合/重新排序并执行。

因此,尽管磁盘在I / O调度方面拥有最终决定权(可以对磁盘队列进行重新排序),因此,这是最终决定写入是顺序写入还是随机写入的地方,存储阵列控制器代表了缓存/聚合/重新排序的最后一个主要阶段。