logo标签列表

如何检查硬盘性能

hard-driveperformance
如何检查硬盘的性能（无论是通过终端还是图形界面）。写入速度。读取速度。缓存大小和速度。随机速度。
2类似的问题已经在以下网站上提问过：https://unix.stackexchange.com/questions/108838/how-can-i-benchmark-my-hdd，https://stackoverflow.com/questions/1198691/testing-io-performance-in-linux和https://serverfault.com/questions/219739/i-o-performance-benchmarking-linux。 - Anon
8个回答

终端方法

hdparm是一个很好的起点。

sudo hdparm -Tt /dev/sda

/dev/sda:
Timing cached reads:   12540 MB in  2.00 seconds = 6277.67 MB/sec
Timing buffered disk reads: 234 MB in  3.00 seconds =  77.98 MB/sec

sudo hdparm -v /dev/sda 会提供相关信息。

dd 可以提供写入速度的信息。

如果驱动器没有文件系统（仅在这种情况下），请使用 of=/dev/sda。

否则，将其挂载到 /tmp 目录，并写入、然后删除测试输出文件。

dd if=/dev/zero of=/tmp/output bs=8k count=10k; rm -f /tmp/output

10240+0 records in
10240+0 records out
83886080 bytes (84 MB) copied, 1.08009 s, 77.7 MB/s

图形方法

  1. 打开“Disks”应用程序。（在较旧的Ubuntu版本中，转到“系统” -> “管理” -> “磁盘实用程序”）。
    • 或者，通过命令行运行gnome-disks来启动Gnome磁盘实用程序。
  2. 在左侧窗格中选择您的硬盘。
  3. 现在，在右侧窗格中的三个点菜单按钮下点击“Benchmark Disk...”菜单项。
  4. 一个带有图表的新窗口将打开。点击“开始基准测试...”。（在较旧的版本中，您会找到两个按钮：“开始只读基准测试”和“开始读写基准测试”。当您点击任何一个按钮时，它将开始对硬盘进行基准测试。）

Screenshot

如何评估磁盘I/O性能

文章

还有其他你想要的吗？

既然这个问题标记为11.10，我只是想指出磁盘工具也可以在Unity Dash中轻松搜索到，或者使用提供的过滤器，在应用程序镜头的附件类别下找到。 - Knowledge Cube
16我建议在测试SSD时，将/dev/urandom和/dev/zero作为dd的输入进行测试，因为数据的可压缩性对写入速度有巨大影响。 - Ian Mackinnon
3我的Ubuntu 12.04 Unity上没有这个"System ->"选项。至少我还没找到过。而且我在系统设置中也没有看到那个磁盘工具...O_o但是最后我终于成功运行了它：/usr/bin/palimpsest - Fran Marzoa
6请注意，自12.10版本以来，它被简称为“Disks”（https://apps.ubuntu.com/cat/applications/quantal/gnome-disk-utility/），可以通过Unity找到。 - Paul Lammertsma
2在Gnome上，这个选项已经移到了应用程序 --> 系统工具 --> 首选项 --> 磁盘工具。对于那些讨厌Unity的人来说。 - Ken Sharp
5现在，/tmp文件系统通常使用ramdisk。因此，写入/tmp似乎是在测试您的内存而不是磁盘子系统。 - Zoredache
如果/tmp是一个ramdisk，那么你将需要写入/home/your_user。我不认为Ubuntu使用ramdisk来存储/tmp，请参考http://askubuntu.com/questions/62928/why-doesnt-tmp-use-tmpfs和http://askubuntu.com/questions/20783/how-is-the-tmp-directory-cleaned-up。 - Panther
如此有限，Bonnie是获取除了线性读/写性能之外的任何东西的最低测试。 - akostadinov
在Ubuntu 16.04上使用SSD。对我来说，dd命令应该是dd if=/dev/zero of=/home/user/file bs=8k count=200k; rm -f /home/user/file（更改为正确的用户名）。如果使用较小的count或写入tmp，结果会不一致且过于理想化。 - Jonatan Öström
基准测试会覆盖我的磁盘数据吗？因为它也会写入基准测试。我认为它会损坏我的数据，对吗？ - Mustafa Chelik
@MustafaChelik - 是的，它会将数据写入磁盘，但不应覆盖现有数据或损坏您的磁盘。我不知道任何在不写入数据的情况下对硬盘进行基准测试的方法，哈哈。为什么您会认为将零写入临时文件会"损坏我的数据"呢？ - Panther
因为我的USB存储设备已经使用Truecrypt进行加密，所以不应该通过基准测试向其中写入任何内容。那么，如果我开始进行基准测试，我的USB存储设备的数据会受损吗？ - Mustafa Chelik
@MustafaChelik 正如我之前所说，如果您不将数据写入磁盘，那么您实际上无法对其进行基准测试。您需要解密磁盘，然后运行基准测试。您需要更改命令以考虑加密，例如 dd if=/dev/zero of=/media/your_crypt_mount_point bs=8k count=10k; rm -f /media/your_crypt_mount_point。 - Panther
@MustafaChelik，如果它只是将零写入临时文件，为什么对话框会建议在进行写入基准测试之前备份重要数据呢？ - sekrett
这样的答案很大程度上取决于所使用的发行版和窗口管理器。Disk Utility是某个底层程序的别名 - 具体是哪个程序呢？在哪个窗口管理器上？在哪个发行版上？ - Scott
@Panther，你的dd命令在硬盘和固态硬盘上给我相同的写入速度。 - Dee
磁盘有那么多漏洞...叹气 - Ricky Boyce
苏明宁是对的，我们应该使用某种同步方法；但有一个更简单的方法，conv=fdatasync可以完成任务。
dd if=/dev/zero of=/tmp/output conv=fdatasync bs=384k count=1k; rm -f /tmp/output
1024+0records in
1024+0 records out
402653184 bytes (403 MB) copied, 3.19232 s, 126 MB/s
31这是一个使用不同命令/选项的答案。我认为这个答案值得单独发布一篇帖子。 - Alaa Ali
2为什么你选择将块大小设为384k？ - Diego Fernández Durán
1@Diego 没有理由。那只是一个例子而已。你可以使用其他任何东西。（大约在4千到1百万之间）当然，更大的块大小会提供更好的性能。当然，在使用大块大小时，要减少计数数字，否则完成任务可能需要一年的时间。 - Tele
它不可靠，无法通过基准测试工具如iozone和sysbench的测试，其数字要低得多。 - MSS
3在写入数据时要小心使用零值 - 一些文件系统和磁盘会对其（以及其他可压缩数据）有特殊处理，这可能导致人为地产生过高的基准测试数值。 - Anon
1没错，Anon。但是如果你使用随机数生成器，你将测量其中一个而不是磁盘。如果你创建一个随机文件，那么你将测量读取文件而不仅仅是写入。也许你应该创建一个填充有随机字节的大内存块。 - Tele
我的Android设备中的dd命令不允许使用conv=fdatasync选项。 - Bill Zhao
如果你想要准确度，你应该使用fio。它需要阅读手册(man fio)，但它会给你准确的结果。请注意，为了得到准确度，你需要明确你想要测量的内容。以下是一些例子： 使用大块大小和队列深度32进行顺序读取速度测试（这个速度应该接近你在硬盘规格中看到的数字）：
fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=read --size=500m --io_size=10g --blocksize=1024k --ioengine=libaio --fsync=10000 --iodepth=32 --direct=1 --numjobs=1 --runtime=60 --group_reporting

大块数据QD32的顺序写入速度（这个速度应该接近您驱动器规格中所看到的数字）：

fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=write --size=500m --io_size=10g --blocksize=1024k --ioengine=libaio --fsync=10000 --iodepth=32 --direct=1 --numjobs=1 --runtime=60 --group_reporting

随机4K读取QD1（这是真正影响实际性能的数字，除非你确切知道更好的）：

fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=randread --size=500m --io_size=10g --blocksize=4k --ioengine=libaio --fsync=1 --iodepth=1 --direct=1 --numjobs=1 --runtime=60 --group_reporting

混合随机4K读写QD1与同步（这是您应该从驱动器中期望的最差情况性能，通常低于规格表中列出的数字的1%）：
fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=randrw --size=500m --io_size=10g --blocksize=4k --ioengine=libaio --fsync=1 --iodepth=1 --direct=1 --numjobs=1 --runtime=60 --group_reporting

增加--size参数以增加文件大小。使用更大的文件可能会减少您根据驱动技术和固件获得的数字。对于旋转介质来说，小文件将给出“太好”的结果，因为读头不需要移动那么多。如果您的设备接近空置状态，则使用足够大的文件来几乎填满驱动器将使每个测试都达到最坏情况。对于SSD而言，文件大小并不那么重要。
然而，请注意，对于某些存储介质，文件的大小并不像短时间内总字节数那样重要。例如，某些固态硬盘（SSD）在预擦除块上具有显著更快的性能，或者可能有用作写缓存的小型SLC闪存区域，一旦SLC缓存满了（例如三星EVO系列，其具有20-50 GB的SLC缓存），性能就会发生变化。另一个例子是希捷SMR硬盘，它们具有约20 GB的PMR缓存区域，具有相当高的性能，但一旦它满了，直接写入SMR区域的性能可能只有原始性能的10%。看到这种性能下降的唯一方法是先尽快写入20+ GB，然后立即进行真实测试。当然，这完全取决于您的工作负载：如果您的写入访问是突发性的，并且有足够长的延迟使设备清理内部缓存，较短的测试序列将更好地反映您的实际性能。如果您需要执行大量IO操作，您需要增加--io_size和--runtime参数。请注意，某些介质（例如大多数廉价闪存设备）会因此类测试而受到影响，因为闪存芯片质量差得足以迅速磨损。在我看来，如果任何设备质量不足以处理这种类型的测试，那么不管怎样都不应该用于保存任何有价值的数据。也就是说，不要重复进行1000次以上的大型写入测试，因为所有闪存单元都会有一定程度的磨损。
此外，一些高质量的固态硬盘设备可能具有更智能的磨损均衡算法，其中内部的SLC缓存具有足够的智能来在数据仍然在SLC缓存中时就进行原地替换。对于这样的设备，如果测试文件小于设备的总SLC缓存，完整的测试将始终只写入SLC缓存，从而获得比设备支持的较大写入性能更高的性能指标。因此，对于这样的设备，文件大小再次开始变得重要。如果您了解实际工作负载，最好使用实际生活中会遇到的文件大小进行测试。如果您不知道预期的工作负载，使用填充存储设备约50％的测试文件大小应该能得到所有存储实现的良好平均结果。当然，对于一个50 TB的RAID设置，使用25 TB的测试文件进行写入测试将需要相当长的时间！
请注意，fio在首次运行时会创建所需的临时文件。它将填充伪随机数据，以避免从试图在基准测试中压缩数据后写入永久存储设备的设备中获得过于优秀的数字。上述示例中的临时文件将被命名为fio-tempfile.dat，并存储在当前工作目录中。因此，您应该首先切换到要测试的设备上挂载的目录。fio还支持使用直接媒体作为测试目标，但我强烈建议在尝试之前阅读手册页面，因为一个打字错误可能会覆盖整个操作系统，当使用直接存储介质访问（例如，意外地写入操作系统设备而不是测试设备）时。
如果你有一块好的SSD，并且想要看到更高的数字，可以增加--numjobs的值。这个参数定义了读写操作的并发数。上面的例子中，numjobs都设置为1，所以测试是关于单线程的读写过程（可能还会使用iodepth来设置队列深度或QD）。高端的SSD（比如Intel Optane 905p）即使不增加numjobs的值也能获得很高的数字（比如4就足够获得最高规格的数字），但是一些“企业级”SSD需要将numjobs增加到32-128的范围才能获得规格上的数字，因为这些设备的内部延迟较高，但总吞吐量非常大。请注意，增加numjobs的值通常会增加结果中的基准性能数字，但很少反映实际世界中的性能表现。
一些fio的设置有点奇怪，可能不是最优的。例如，在使用异步I/O引擎进行直接I/O时，拥有如此巨大的块大小（2M字节）很可能会导致内核中的大量分割，从而产生额外开销。在只进行读取操作时定期发送fsync也看起来很不寻常。我同意fio很有用，但我建议读者仔细调查他们希望使用哪些参数，而不仅仅是从上面回答的20180102版本中逐字复制它们。 - Anon
@Anon: 你说得对，顺序读取的最佳设置应该是匹配/sys/block/sd?/queue/max_sectors_kb，因为它可能比实际硬件限制更低，而实际硬件限制通常远远超过上面示例中的2MB。然而，我认为由CPU引起的轻微开销与实际I/O设备的速度相比无关紧要。fsync对于读取操作来说是一个无操作，所以它不会影响结果 - 我保留它只是为了更容易理解不同命令行之间的差异。你有问题无法满足制造商的规格要求吗？ - Mikko Rantalainen
不完全是，我只是有一些在fio和Linux上的工作经验。实际上，如果你在猜测最佳块大小，最好从optimal_io_size开始（如果可用的话），但是如果它为0，你可以假设为64K字节（这是内核的默认值）。不完全是，我只是有一些在fio和Linux上的工作经验。实际上，如果你在猜测最佳块大小，最好从optimal_io_size开始（如果可用的话），但是如果它为0，你可以假设为64K字节（这是内核的默认值）。 - Anon
2我刚刚重新测试了一些设备。使用上述的顺序读取测试（2MB块大小），我从三星SSD 850 EVO获得了280 MB/s，从英特尔910 SSD获得了1070 MB/s。使用64k块大小和其他相同的命令行，我从850 EVO获得了268 MB/s，从910 SSD获得了1055 MB/s。至少对于这种类型的设备来说，使用2MB块大小似乎可以提高结果约1-5%，尽管它会导致内核将请求拆分到硬件中。我猜即使有内核优化，提交更多的系统调用的开销也比在内核内部拆分要大。 - Mikko Rantalainen
1经过进一步的测试，似乎我可以获得最高的连续吞吐量，使用小于max_sectors_kb的2的幂值。我将上述示例命令更改为使用1 MB的块大小，因为这似乎适用于真实世界的硬件。而且我还测试了在读取时fsync并不重要。 - Mikko Rantalainen
1根据驱动器的连接方式，你可能会发现你的iodepth太低了。你需要观察Linux实际发送给设备的内容以及发送深度... - Anon
1我将iodepth设置为1，用于随机访问，因为现实世界中的程序通常运行的算法/逻辑不能处理超过1的深度。结果是，如果这样的深度“太低”，则您的I/O设备不好。某些SSD设备确实会受益于超过32的深度。然而，你能指出任何需要读取访问并且能够保持高于32的iodepth的真实工作负载吗？简而言之：如果您想使用高延迟设备复制一些疯狂高的读取基准数，请使用iodepth=256 --numjobs=4，但永远不要期望在真实环境中看到这样的数字。 - Mikko Rantalainen
1大多数“真实世界”的程序实际上并没有直接提交I/O（即时输入/输出），更不用说异步操作了，所以我们的所有示例都是在非常特殊的工作负载下来推动极限基准测试领域（正如他们所说，最好的基准测试就是你的真实工作负载）。话虽如此，像同时运行多个繁忙的虚拟机这样的操作很容易产生具有极高深度的工作负载，但从磁盘角度来看，I/O通常看起来是随机的，这是一个简单的例子，可以看到类似NVMe的技术可以带来巨大的加速效果。另外，将数字设置得太高会降低吞吐量，所以需要找到一个合适的平衡点... - Anon
如果你想要图表，请查看https://askubuntu.com/q/1108347/50254 - Mikko Rantalainen
快速更新（并更正我写的错误）：正如 @mikko-rantalainen 所暗示的那样，max_sectors_kb 将控制块设备向磁盘提交的最大 I/O 大小。这是一个理想的值，因为我们假设 I/O 越大，每个 I/O 需要完成的工作就越少。稍微复杂的是，某些设备会暴露出“持续 I/O 的首选单元”值，如果存在于 /sys/block/<dev>/queue/optimal_io_size 中的值不为零（通常只发生在某些 RAID 设备上），使用该值可能会得到更好的速度。 - Anon
我认为 optimal_io_size 的真正意思是应该避免小于此大小的数据传输。例如，一个物理扇区大小为4 KB但逻辑扇区大小为512字节的硬盘可能会报告 optimal_io_size 为 4096。然而，这并不意味着写大文件的最佳方式是分多个4 KB块写入。相反，它指示如果软件可以避免使用小于 optimal_io_size 的写操作，则设备将工作得更快。 - Mikko Rantalainen
1在你提供的具体情况中，我认为你正在考虑 /sys/block/<disk>/queue/physical_block_size 与 [...]/logical_block_size（例如，一个接受512字节（逻辑）I/O的SSD，但其“块”实际上是4096字节大，这意味着它将做额外的工作来应对512字节的I/O）。在这种情况下，optimal_io_size很少会是0，但是 minimum_io_size（“首选最小粒度”）可能是4096。当我看到非零的 optimal_io_size 时，它通常很大（例如4MiB），与物理大小相比，并反映了RAID阵列条带大小。 - Anon
在SSD的情况下，文件大小并不那么重要-这是不正确的。对于写入操作来说，文件的大小可能非常重要，因为如果文件太小（和/或没有足够的写入I/O），您可能无法用尽预擦除块，并且不会看到持续写入速度降至垃圾回收速度的效果。请参阅https://www.snia.org/sites/default/education/tutorials/2011/fall/SolidState/EstherSpanjer_The_Why_How_SSD_Performance_Benchmarking.pdf以了解更多讨论内容。 - Anon
我会重新表达文件大小的问题，以使其更清晰明了。对于固态硬盘（SSD）来说，文件的大小并不重要，但总体的IO操作量可能很重要。这对于SMR硬盘也会有所不同。 - Mikko Rantalainen
1我本来也是这么想的，但在我将其写入上面的文件时，有人指出文件大小仍然很重要，因为如果SSD发现你在其缓存中进行覆写操作，它可以选择丢弃被覆写的数据。 - Anon
1此外，部分覆写会导致更多的垃圾回收工作（因为您需要读取未被覆写的数据位并保留它们），而完全覆写则可以将整个单元标记为空闲。请参阅http://codecapsule.com/2014/02/12/coding-for-ssds-part-3-pages-blocks-and-the-flash-translation-layer/了解更多背景信息。 - Anon
谢谢这个测试，我对磁盘基准测试并不是很专业，但这些结果确实反映了当我在驱动器上复制大量文件时所看到的情况。 今天我第一次使用mdadm配置了一个RAID阵列，使用了3个不同的硬盘（我的意思是，这个阵列中没有两个硬盘是相同的！）。 我有点困惑，这个RAID的性能比我的M.2 PCIe SSD（金士顿shpm228）要好。虽然我对实际速度感到满意，但我有一种微妙的感觉，似乎有些地方出了问题。 - funder7
@Funder 我假设你测试了顺序读取或顺序写入的情况。如果你在上述混合4k qd1测试中从HDD RAID中获得更好的性能，那么你可能在测试过程中犯了一些错误。我对那个特定的金士顿SSD不太熟悉，但我认为它应该不会比HDD RAID在非顺序访问方面差到哪去。话虽如此，现在我个人只使用三星、英特尔或高端A-Data SSD。另外，如果你只关心性能，Linux软件RAID在任何硬件RAID设置中都胜出。然而，写缓存的电池备份仍然是使用RAID卡的原因之一。 - Mikko Rantalainen
1@Mikko，你说得对，今天我重新尝试了一下，RAID的性能确实不如预期，可能是我做错了什么。嗯，这个固态硬盘应该足够好了，我两年前买的，价格还是很高的。品牌是HyperX，我想那是金士顿的高端系列。不过看电子商务网站上的评论，有些三星的评价最好，就价格和性能平衡而言。回到RAID，是的，我并不太在意数据冗余，我只是想建立一个阵列来提高固态硬盘和机械硬盘之间的传输速率。我以为RAID卡会更好呢！ - funder7
1@Funder RAID卡的问题在于它们基本上是在与真正的CPU竞争，而无论卡上嵌入的处理器有多慢，都比不上现代AMD或Intel CPU使用优化代码时的速度。别再买昂贵的卡了，把钱用在系统CPU上吧。Linux内核包含2-4种不同的RAID算法实现，并且内核在启动过程中对CPU进行基准测试，因此您可以获得适用于任何CPU的非常好的实现。此外，真正的CPU与RAM/磁盘缓存之间的连接要好得多，因此软件RAID的延迟也会更低。 - Mikko Rantalainen
@MikkoRantalainen，嗯，我不知道现在RAID卡最常用的接口是哪个，但我很确定你不需要相同功率的CPU来保持相同的速度水平...可能硬件卡有一个缓存用于处理高流量情况，而且它们只进行数据传输，而CPU则有许多不同的任务要处理。 我的SSD是M.2格式的，所以你也可以将其安装在其PCIe适配器上，它应该能达到6 Gb/s。我想说，使用专用的RAID卡，你就不再依赖于SSD的缓存和总线速度了。 - funder7
1@Funder 如果您将许多硬盘驱动器连接到单个具有硬件加速的RAID控制器上，系统CPU将需要更少的功率来使用RAID系统。然而，整个系统的性能可能仍然比仅使用Linux软件RAID并直接连接到磁盘要差。当然，大多数系统在没有RAID卡的情况下会用完连接器，并且根据RAID卡的实现方式，您无法通过卡直接与各个硬盘驱动器进行通信，这对于高性能软件RAID是必需的。 - Mikko Rantalainen
1为了达到最佳性能，您希望将NVMe设备直接连接到PCIe，并在其上使用Linux软件RAID。在这种情况下，限制可能是PCIe子系统和系统内存之间的最大吞吐量。 - Mikko Rantalainen
谢谢 @MikkoRantalainen，这些是很有用的信息！ - funder7
1经进一步测试，似乎我在最大扇区大小之下使用2的幂值时获得了最高的顺序吞吐量。这很可能是因为Linux内核选择以较小的尺寸分割I/O操作。详细信息请参考https://stackoverflow.com/a/59403297/2732969。 - Anon
@Anon 谢谢。我知道 max_sectors_kb，但是没有考虑到 DMA 引擎也可能限制请求的大小。 - Mikko Rantalainen
@MikkoRantalainen 喜欢这个FIO测试，以及你对它的用心。你有没有更新的版本（如果有的话，可以把它粘贴到Github GIST上）？谢谢 - undefined
@GrabbenD：就像我在回答中所写的，这取决于你想要衡量什么。我在回答中提到的四个测试至今仍然有效，但只有你自己能够确定它们是否代表了你的工作负载。 - undefined
@MikkoRantalainen：明白了，我想你可能有一个更新的清单或者一套适用于各种工作负载的完整测试。不过，我找到了这篇文章，其中列出了一份相当不错的不同测试清单：https://portal.nutanix.com/page/documents/kbs/details?targetId=kA07V000000LX7xSAG - undefined
@GrabbenD 那个页面似乎列出了比4 KB更大的块大小的测试。除非你确定，否则不应假设你的应用程序实际上具有这样的访问模式。 - undefined
我不建议使用/dev/urandom，因为它是基于软件的，速度慢得像猪一样。最好从ramdisk中获取一块随机数据。在硬盘测试中，随机性并不重要，因为每个字节都按原样写入（即使在使用dd的ssd上也是如此）。但是，如果我们使用纯零或随机数据测试去重的zfs池，性能差异就会很大。
另一个观点必须考虑同步时间的包含；所有现代文件系统都在文件操作中使用缓存。
为了真正测量磁盘速度而不是内存，我们必须同步文件系统以消除缓存效应。可以通过以下简单方法实现：
time sh -c "dd if=/dev/zero of=testfile bs=100k count=1k && sync"

使用该方法，您将获得输出：

sync ; time sh -c "dd if=/dev/zero of=testfile bs=100k count=1k  && sync" ; rm testfile 
1024+0 records in
1024+0 records out
104857600 bytes (105 MB) copied, 0.270684 s, 387 MB/s

real    0m0.441s
user    0m0.004s
sys 0m0.124s

所以磁盘数据传输速率只有104857600 / 0.441 = 237772335 B/s --> 237MB/s。
这比使用缓存时低了100MB/s以上。
祝您进行基准测试愉快，
7在写入数据时要小心使用零 - 一些磁盘（如固态硬盘）和一些文件系统会对此进行特殊处理。这样做会导致使用零缓冲区时人为地提高基准测试结果。其他高度可压缩的数据模式也可能扭曲结果... - Anon
如果你想实时监控磁盘的读写速度，可以使用iotop工具。
这对于了解磁盘在特定应用程序或工作负载下的性能非常有用。输出结果将显示每个进程的读写速度以及服务器的总读写速度，类似于top命令。
安装iotop：
sudo apt-get install iotop

运行它：
sudo iotop

这个工具对于理解一个磁盘在特定工作负载下的表现与更一般和理论性的测试相比是非常有帮助的。
为了获得更好的每个设备的统计数据，尝试使用iostat -tmxyz 10命令，它将每10秒发出一次测量。iotop非常适合找到导致大量IO的单个进程，但是iostat更适合确定负载如何分布在实际硬件设备上（例如，如果您使用LVM或RAID）。 - Mikko Rantalainen

写入速度

$ dd if=/dev/zero of=./largefile bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 4.82364 s, 223 MB/s

块大小实际上相当大。你可以尝试使用更小的大小，比如64k甚至4k。

读取速度

运行以下命令以清除内存缓存

$ sudo sh -c "sync && echo 3 > /proc/sys/vm/drop_caches"

现在读取在写入测试中创建的文件：
$ dd if=./largefile of=/dev/null bs=4k
165118+0 records in
165118+0 records out
676323328 bytes (676 MB) copied, 3.0114 s, 225 MB/s
4在写入数据时要小心使用零值 - 一些文件系统和磁盘会对其（以及其他可压缩数据）有特殊处理，这可能导致人为地产生过高的基准测试数值。 - Anon
bonnie++ 是我所知道的 Linux 上最终的基准测试工具。
（我目前正在工作中准备一个带有 bonnie++ 的 Linux LiveCD，用它来测试我们的基于 Windows 的机器！）
它负责缓存、同步、随机数据、磁盘上的随机位置、小尺寸更新、大尺寸更新、读取、写入等等。对于新手来说，比较 USB 钥匙、硬盘（旋转式）、固态硬盘和基于 RAM 的文件系统可以提供非常有用的信息。
我不知道它是否包含在 Ubuntu 中，但你可以很容易地从源代码编译它。

http://www.coker.com.au/bonnie++/

3Bonnie在磁盘基准测试方面存在缺陷，能够轻易生成与系统非磁盘相关的数字，因此如果选择使用它，则需要非常谨慎。有关详细信息，请参阅Brendan Gregg的《主动基准测试：Bonnie++》链接。 - Anon
一些关于如何使用bonnie++的提示
bonnie++ -d [TEST_LOCATION] -s [TEST_SIZE] -n 0 -m [TEST_NAME] -f -b -u [TEST_USER] 
bonnie++ -d /tmp -s 4G -n 0 -m TEST -f -b -u james

更多内容请参考：简单BONNIE++示例。