是由操作系统本身造成的间歇性慢的磁盘读取速度？

根据手册页：

  -t Perform timings of device reads for benchmark and comparison purposes. For meaningful results, this operation should be repeated 2-3 times on an otherwise inactive system (no other active processes) with at least a couple of megabytes of free memory. 

所以，是的，其他进程可以干预这些结果。

还有其他方面或testing我可以运行吗？

您可以查看其他进程是否正在使用磁盘的一种方法是从主网页下载sysstat 。 Sysstat当然可以从repo中获得，但不幸的是，它不包含需要检查的pidstat命令。

自EL5.4以来，EL5内核将磁盘logging归入内核，但没有提供使用它的接口，但是一旦你完成了这个任务，pidstat就会工作。

然后运行pidstat -d命令为磁盘I / O生成有用的度量标准，特别是其他进程正在使用的磁盘。 您也可以使用pidstat -d <interval> <count>来获取正在使用的磁盘的更实时的争用指标。

任何types的虚拟机/操作系统损坏会导致这种types的行为？

操作系统的腐败是不太可能的（系统调用被搞砸了，我想）。 hdparm不利用文件系统进行testing，消除了该领域的任何放缓，包括分解问题。 如果您使用LVM，那么您碰巧正在从分段的区段中读取风险。 然而，你的例子并没有指出这一点。

虚拟机的腐败，以及任何游戏，我猜想，以及我可以想到的一些因素，但可能会包括更多：

• 磁盘所在的映像格式
• 这些数据是如何分配给底层存储机制的（这是一个逻辑卷，带有扩展盘区本身吗？）
• 如果在磁盘控制器内部进行RAID重build或其他块级维护。 如果控制器实际上是一个SAN做一些forms的RAID重新平衡IE。
• RAID中的磁盘故障迫使奇偶校验计算。
• 无论数据是通过像FusionIO这样的“快速”caching，存在于SAN中的数据caching还是电池供电的突袭卡来实际读取。
• 底层媒体是否以某种方式分层存储。
• pipe理程序引起磁盘争用，导致您的I / O请求排队更长时间。
• 导致I / O请求排队等待更长时间的SAN的磁盘争用（虚拟机驻留在共享存储上的情况非常普遍）。
• 精简configuration卷导致碎片风险很高。 如何影响你的testing完全取决于为精简configuration的程度分配了多less个块。 例如，在Linux中的LVM精简configuration中，盘区大小默认为32M，因此在磁盘上传递32M标记可能会导致额外的查找，从而导致您的时间混乱。

重build/取代虚拟机的帮助？

锅运气我猜如果它好或更糟。 看到上面可能有帮助/阻碍的环境因素。

在一天结束时，如果您正在使用卷pipe理软件或精简configuration软件在正在写入介质的数据stream中（在您的主机上，在您的VM级别，在SAN /控制器级别），您可以拥有没有可靠的期望 ，你正在做的顺序读取是真正顺序的，或者你正在写入的媒体是一致的（如果它的快速磁盘或数据被移动到慢速磁盘）。

虚拟化非常强大，因为它为主机增加了一层逻辑抽象。 但是由于这个抽象层，对它们进行任何可靠的容量pipe理也可能是可怕的。