存储基准测试 - 非常喜欢Wi-Fi benchmarking - 广泛误解的黑色艺术。几十年来，管理员和爱好者一直被读取或写大量数据来“获得大数字”，以MB/sec获得数字，并将其称为一天。不幸的是，典型磁盘的实际工作量看起来并不是那样的，而且“简单的速度测试”并没有重现许多瓶颈，这些瓶颈会减慢现实世界系统中的磁盘访问。
测试和基准磁盘的最现实方法当然是使用它们并查看会发生什么。不幸的是，这既不是非常可重复的，也不容易分析。因此，我们确实需要一种人工基准测试工具，但是我们希望可以智能地使用一种智能测试存储系统的现实场景，以对我们的日常用法建模。幸运的是，我们不必发明这种工具 - 已经有一个免费的开源软件工具称为fio，甚至是跨平台！
我们将引导您了解Windows，Mac和Linux计算机上FIO的一些简单但有效的用途，但是在此之前，让我们从更基本的角度谈论存储系统。
吞吐量，延迟，IOPS和缓存
吞吐量
最常见于MB/sec的存储系统中最常见的吞吐量是谈论存储性能的最常用方式。存储系统中有几个用于吞吐量的扼流点 - 首先也是最重要的是物理介质本身的速度。如果您在7200rpm的传统生锈磁盘上有一个头部，则可以收到或关闭磁盘的数据受到磁盘的限制，而磁盘将受到头部下方的物理部门/块数量的限制。您还受到控制器和电缆的带宽的限制 - 例如，现代SATA链接通常以6Gbps运行，而现代SAS链接最多可以运行22.5Gbps。
这里的情况有些复杂，因为我们正在混合单元 - NOTICE在MB/sec中的Big B，而Gbps中的小B。这就是字节和位之间的区别。您将Gbps除以8，以获取GB/SEC，然后乘以1024以获取MB/sec。因此，从理论上讲，SATA-3 6GBPS链接可以提高到768MB/秒。实际上，您无法以完整的理论链接速度以SATA或SAS总线的方式移动数据，但是您可以相当接近。还值得注意的是，即使有许多磁盘连接到控制器，大多数SATA控制器的移动数据也不会超过单个链接可以管理的数据 - 因此，在大约700 mb/sec的阵列瓶颈中，甚至在阵列瓶颈中看到许多非常快速的固态驱动器。
潜伏期
延迟是同一性能硬币的另一面。如果吞吐量是指您可以在磁盘上或磁盘上移动多少个字节的数据，则延迟（通常以毫秒为单位测量）将读取或写入单个块所需的时间。大多数最糟糕的存储瓶颈是影响吞吐量的延迟问题，而不是相反。
在常规的旋转锈盘中，有两个主要的延迟来源：旋转潜伏期和寻求延迟。寻求延迟是将机械臂移动磁盘头的移动所需的时间，将磁盘头安装到磁盘上的正确轨道上。一旦头部移至正确的轨道，驱动器就必须等待正确的扇区在头部下方旋转 - 这是旋转潜伏期。寻求和旋转潜伏期的组合通常总计达到15ms至25ms之间。
您可以通过思考实验看到潜伏期如何影响吞吐量。如果我们具有相当快的旋转磁盘，最大吞吐量为180MB/sec，总访问延迟为16ms，并且我们以最大碎片的工作负载来呈现它，这表明没有两个块被编写/是按顺序写入/的，那么我们可以做一些数学来提出该吞吐量。假设磁盘上有4KB的物理块，每SEEK 4KB除以0.016秒，=仅250kb/sec。哎哟!
IOPS
IOPS的输入/输出操作的缩写是测量的指标，您通常会听到真正的存储工程师在讨论。这听起来确实意味着什么 - 磁盘服务有多种不同的操作？以相同的方式，“吞吐量”通常是指磁盘的最大吞吐量，具有非常大的读取或写入，IOPS通常是指磁盘可以在低端服务的最大操作数量 - 4K随机读取和写入。
固态磁盘不会遭受寻求或旋转延迟的困扰，但是4K随机输入/输出（I/O）仍然会出现问题。在引擎盖下，消费者SSD并不是真正的单个“磁盘”，它是一个小密封盒中的突袭阵列，其磁盘本身内部有自己的复杂控制器管理和写入。 SSD控制器本身会并行跨物理闪光介质的多个频道写入条纹，并且如果幸运的是，如果用户很幸运，那么在这些频道上均匀地划分的写作也将以相同的方式读取，从而最大化吞吐量。
当固态磁盘带有4K随机I/O工作负载时，如果它无法找到某种方法来汇总和并行化请求，则最终将以较低的速度瓶颈，这取决于闪光介质的单个单元格能够读取或写入数据块的速度。影响并不像生锈磁盘那样引人注目，但仍然很重要 - 在180MB/sec的吞吐量中，生锈盘可能会跌至4K随机I/O的250kb/sec，可降至500MB/sec的SSD可能会降至约40mb/sec左右。
尽管您可以根据4K随机I/O和IOPS来讨论吞吐量，而IOPS则根据顺序1MB I/O而言，这不是通常使用每个术语的方式。通常，您应该期望通过磁盘在最佳条件下移动多少数据来讨论吞吐量，而在“低端咕unt”磁盘下，磁盘即使在最差的工作负载下也能够。对于典型的台式PC使用，IOPS远比吞吐量重要得多，因为有很多慢的4K随机I/O，并且在发生时会减慢整个系统的速度。
缓存
如上所述，非优化的工作负载损害了性能，并严重伤害了他们。值得庆幸的是，对于用户来说，数十年的研发已经向我们介绍了各种技巧，以避免探索我们存储的最差性能特征，尤其是生锈的存储。操作系统同时使用读取缓存和写缓冲区来最大程度地减少操作中必要的寻求数量，并避免需要一遍又一遍地读取经常需要的块。
写缓冲区允许操作系统存储许多小的I/O请求，并将其提交大量磁盘。一个兆字节的数据是很少的数据，但是它仍然达到256 4KB块，如果您必须将每个块用单个操作编写，则可以将磁盘的整个服务能力绑定到完整的一秒钟。另一方面，如果您可以在写缓冲区中汇总这256个块，然后将它们汇总为单个操作，则避免所有访问延迟，并且可以将相同数量的数据保存在或多或少的一百秒钟或多或少。此聚合还可以极大地帮助以后阅读速度。如果以后需要将大多数相同的块读成小组，则该驱动器可以避免在它们之间寻求，因为它们都是首先作为小组编写的。
读取缓存可以使系统不必一遍又一遍地对相同块的不必要的重复请求捆绑存储。如果您的操作系统有大量的RAM可用，则每次从磁盘中读取数据时，它都会使其在内存中保持周围的副本。如果另一个程序稍后要求相同的块，则操作系统可以直接从缓存请求，这可以使驱动器的有限资源可用于读取或写入请求，而必须击中实际磁盘。
某些SSD型号在磁盘本身上具有额外的非易失性写作缓存，该磁盘本身由更快，更昂贵的闪光介质制成。例如，TLC或QLC（Quad Layer Cell）SSD可能具有几GB（多层单元格）介质，以用作写入缓冲液；这使SSD能够跟上典型的台式机工作负载所需的写作，但使用更快的MLC缓冲液，但是如果持续的沉重写入太长时间了，快速MLC缓冲液填充填充物，而吞吐量降低到较慢的TLC或QLC媒体可以管理的。这通常可能是“脱落悬崖”类型的情况，因为较慢的媒体通常不仅必须维持持续的写作，而且可以继续播放快速MLC缓冲区已接受的写作。
实际对存储访问进行建模
现在我们对存储系统中的疼痛点有所了解，很明显，我们不应该仅使用一个简单的工具[dd](https://en.wikipedia.org/wiki/Dd_(Unix)）读取或编写大量数据，并产生大量数字。这些巨大的数字与每个磁盘在更现实的工作负载下的性能并不十分相关，因此，我们希望生成更真实的访问模式进行测试。
这是fio进来。FIO是灵活输入/输出测试仪的简短，可以配置为在太阳下几乎所有存储工作负载建模。真正的存储工程师 - 至少那些正在正确执行工作的工程师将首先分析服务器或服务的实际存储访问模式，然后编写FIO脚本以建模这些精确模式。通过这种方式，他们不仅可以为其一般性能测试磁盘或数组，而且还可以非常适用于其确切的工作负载。
我们在这里不会是如此具体，但是我们将使用FIO来建模并报告桌面和服务器存储常见的某些关键用法模式。其中最重要的是4K随机I/O，我们在上面进行了详细讨论。 4K随机是痛苦的生活，这是您使用传统硬盘驱动器的快速计算机突然听起来像在磨咖啡的原因defenestrate沮丧。
接下来，我们在16个平行过程中查看64K随机I/O。对于繁忙的计算机来说，这是一种中间的工作负载，有很多要求相对较少的数据的要求，但是也有很多并行过程。在现代系统上，大量的并行过程很好，因为它有可能允许OS汇总许多小请求，以分为一些较大的请求。尽管距离4K随机I/O的惩罚效果不及64K随机I/O足以显着减慢大多数存储系统的降低。
最后，我们通过1MB随机I/O来查看高端吞吐量 - 您可以期望从系统中看到的最大数字中的一些。从技术上讲，您仍然可以通过要求FIO生成真正的顺序请求来获得一个“稍微*”的数字，但是在现实世界中，这些请求消失了。如果您的操作系统需要在系统日志上写几行，或者从系统库中读取几个kb的数据，则您的“顺序”读取或写入有效地将有效地变为1MB随机I/O，因为它与其他过程共享时间。
安装FIO
windows
您可以在https://bsdio.com/fio/。请注意，在运行其中一个安装程序时，您可能会收到智能屏幕警告，因为它们没有数字签名。这些软件包由丽贝卡·克兰（Rebecca Cran）提供，无需保修。
请注意，Windows的IOENEEN可用选择有限，这将为您稍后选择命令行参数提供信息。在大多数情况下，Windows用户应使用--ioengine=windowsaio（异步输入/输出）及其FIO参数。
linux / freebsd
Linux和BSD分布用户的说明从一个到另一个方面有所不同，但是FIO几乎在所有主要存储库中，因此归结为<package manager> install fio对于绝大多数。
** Debian或Ubuntu：**sudo apt install fio
** freebsd：** sudo pkg install fio
比大多数发行版，CentOS（和红帽企业Linux）的主要存储库具有更有限的主要存储库；如果还没有，则需要将EPEL存储库添加到CentOS/RHEL中才能获取FIO。
** Centos/Rhel：**sudo yum install epel-release -y ; sudo yum install fio
你明白了。
macos
在Mac上，您需要通过Brew安装FIO。如果您尚未在终端上安装啤酒，请发出以下命令：
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
一方面，以上是可恶的程序；另一方面，您可以确认被拉下的脚本告诉您它将要做的一切，然后再做之前，并停下来允许您同意它。如果您足够偏执，则可能希望下载文件，对其进行检查，然后将其作为单独的步骤运行。请注意，Homebrew Install脚本不需要Sudo特权，实际上，如果您尝试使用Sudo执行它，则实际上拒绝运行。
安装酿造后，您现在可以轻松安装FIO：
brew install fio
使用 fio
现在，您可以使用FIO进行基准存储。 首先，将目录更改为实际要测试的位置：如果您在主目录中运行FIO，则将测试计算机的内部磁盘，如果您在USB便携式磁盘上的目录中运行它，则将对该便携式磁盘进行基准测试。在要测试的磁盘中的某个地方，您可以实际运行FIO。
婴儿的第一个fio跑步
首先，我们将检查简单4K随机写测试所需的语法。 （Windows用户：替代--ioengine=windowsaio为了--ioengine=posixaio在这个和未来的命令中。）
fio --name=random-write --ioengine=posixaio --rw=randwrite --bs=4k --numjobs=1 --size=4g --iodepth=1 --runtime=60 --time_based --end_fsync=1
让我们分解每个论点的作用。
--name=是必需的参数，但基本上是对人类友好的绒毛 - Fio将根据该名称创建文件，以测试您当前的工作目录内。
--ioengine=posixaio设置模式FIO与文件系统进行交互。 POSIX是标准窗口，Mac，Linux和BSD都可以理解，因此非常适合可移植性 - 尽管在FIO本身中，Windows用户需要调用Windows用户--ioengine=windowsaio， 不是--ioengine=posixaio， 很遗憾。 AIO代表异步输入输出，这意味着我们可以以OS决定完成它们的任何顺序排队以完成多个操作。 （在此特定示例中，后来的论点有效地将其无效。）
--rw=randwrite确切的意思是它的含义：我们将在当前工作目录中对测试文件进行随机写入操作。其他选项包括Seqread，Seqwrite，Randread和Randrw，所有这些都应该是相当自我解释的。
--bs=4k阻止4K。这些是很小的个人操作。这是痛苦的生活；它在磁盘上很难，这也意味着在SATA，USB，SAS，SMB或我们与磁盘之间的任何其他命令频道中的大量额外开销，因为必须为每个4K数据命令单独的操作。
--size=4g我们的测试文件的大小为4GB。 （我们只是创建一个，请参阅下一个参数。）
--numjobs=1我们只创建一个文件，然后在该文件中运行一个命令操作的单个过程。如果我们想模拟多个并行过程，我们会这样做，例如--numjobs=16，将创建16个单独的测试文件--size大小和16个单独的过程同时在它们上进行操作。
--iodepth=1这就是我们愿意在操作系统队列中堆叠命令的深度。由于我们将其设置为1，因此实际上与同步IO引擎几乎相同 - 我们一次只要求一次操作，并且OS必须确认我们要求的每项操作，然后我们才能要求另一个操作。 （在我们要求进行更多操作之前，它不必满足请求本身，它只需要承认我们实际要求它即可。）
--runtime=60 --time_based跑步六十秒 - 即使我们早点完成，也只需重新开始，继续前进，直到60秒开始。
--end_fsync=1在所有操作都被排队之后，请保持计时器的运行，直到OS报告说，其中最后一个已成功完成 - IE，实际上写给了磁盘。
解释FIO的输出
这是从Ubuntu工作站上运行4K随机I/O的整个输出：
```shell unwrap root@banshee:/tmp# fio –name=random-write –ioengine=posixaio –rw=randwrite –bs=4k –size=4g –numjobs=1 –runtime=60 –time_based –end_fsync=1 random-write: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=posixaio fio-3.12 Starting 1 process Jobs: 1 (f=1): [w(1)][100.0%][eta 00m:00s]
random-write: (groupid=0, jobs=1): err= 0: pid=16109: Wed Feb 5 15:09:36 2020 write: IOPS=32.5k, BW=127MiB/s (133MB/s)(8192MiB/64602msec); 0 zone resets slat (nsec): min=250, max=555439, avg=1388.31, stdev=833.19 clat (nsec): min=90, max=20251k, avg=9642.34, stdev=179381.02 lat (usec): min=3, max=20252, avg=11.03, stdev=179.39 clat percentiles (usec): | 1.00th=[ 4], 5.00th=[ 4], 10.00th=[ 4], 20.00th=[ 5], | 30.00th=[ 6], 40.00th=[ 6], 50.00th=[ 7], 60.00th=[ 8], | 70.00th=[ 9], 80.00th=[ 10], 90.00th=[ 11], 95.00th=[ 12], | 99.00th=[ 17], 99.50th=[ 20], 99.90th=[ 43], 99.95th=[ 77], | 99.99th=[12387] bw ( KiB/s): min=22256, max=613312, per=100.00%, avg=335527.28, stdev=162778.06, samples=50 iops : min= 5564, max=153328, avg=83881.88, stdev=40694.66, samples=50 lat (nsec) : 100=0.01%, 250=0.01%, 500=0.01%, 750=0.01%, 1000=0.01% lat (usec) : 2=0.01%, 4=13.96%, 10=68.85%, 20=16.68%, 50=0.41% lat (usec) : 100=0.04%, 250=0.01%, 500=0.01%, 750=0.01%, 1000=0.01% lat (msec) : 2=0.01%, 10=0.01%, 20=0.01%, 50=0.01% cpu : usr=6.35%, sys=11.96%, ctx=2348924, majf=0, minf=48 IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0% submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% issued rwts: total=0,2097153,0,1 short=0,0,0,0 dropped=0,0,0,0 latency : target=0, window=0, percentile=100.00%, depth=1
Run status group 0 (all jobs): WRITE: bw=127MiB/s (133MB/s), 127MiB/s-127MiB/s (133MB/s-133MB/s), io=8192MiB (8590MB), run=64602-64602msec
Disk stats (read/write): md0: ios=71/749877, merge=0/0, ticks=0/0, in_queue=0, util=0.00%, aggrios=351/737911, aggrmerge=0/12145, aggrticks=1875/260901, aggrin_queue=30910, aggrutil=83.73% sdb: ios=342/737392, merge=0/12663, ticks=1832/241034, in_queue=28672, util=83.35% sda: ios=361/738430, merge=0/11628, ticks=1918/280768, in_queue=33148, util=83.73%
这似乎很多。 但是，在大多数情况下，您可能只有一块可能会关心的 - 直接在“运行状态0（所有作业））下：”是汇总吞吐量的一条。 FIO能够像您想执行复杂的工作负载模型一样，并行运行许多截然不同的作业。但是，由于我们只运行一个工作组，因此我们只有一条聚合可以查看。
Run status group 0 (all jobs): WRITE: bw=127MiB/s (133MB/s), 127MiB/s-127MiB/s (133MB/s-133MB/s), io=8192MiB (8590MB), run=64602-64602msec
首先，我们看到MIB/SEC和MB/SEC的输出。 MIB的意思是“ Mebibytes”（以两个权力为单位），其中MB的意思是“ Megabytes”，以十大势力为单位。 MEBIBYTES -1024X1024字节 - 操作系统和文件系统实际上是哪些测量数据，因此这就是您关心的读数。
Run status group 0 (all jobs): WRITE: bw=127MiB/s (133MB/s), 127MiB/s-127MiB/s (133MB/s-133MB/s), io=8192MiB (8590MB), run=64602-64602msec
除了只有一个工作组外，我们在此测试中只有一个工作 - 例如，我们没有要求FIO运行16个并行4K随机写过程 - 因此，尽管第二位显示最小和最大范围，但在这种情况下，这只是整体聚合的重复。如果我们有多个过程，我们会看到此处代表的最快过程的最慢过程。
Run status group 0 (all jobs): WRITE: bw=127MiB/s (133MB/s), 127MiB/s-127MiB/s (133MB/s-133MB/s), io=8192MiB (8590MB), run=64602-64602msec ```
最后，我们获得了64602毫秒写给磁盘的总I/O —8192MIB。将8192MIB除以64.602秒，令人惊讶的是，您将获得126.8mib/sec，最多可达127mib/sec，这正是Fio在汇总吞吐量的第一个街区中告诉您的。
如果您想知道Fio为什么在此运行中写8192mib而不是仅4096mib，尽管我们--size论点是4G，只有一个过程运行 - 这是因为我们使用了--time_based和--runtime=60。而且，由于我们在快速存储介质上进行测试，因此我们在终止之前设法循环循环两次。
您可以从完整的FIO输出中挑选出更多有趣的统计数据，包括利用率百分比，每个过程和CPU利用率，但出于我们的目的，我们将坚持从现在开始的总吞吐量。
ARS推荐测试
单4KIB随机写过程
fio --name=random-write --ioengine=posixaio --rw=randwrite --bs=4k --size=4g --numjobs=1 --iodepth=1 --runtime=60 --time_based --end_fsync=1
这是一个随机4K写作的单个过程。这是痛苦真正生活的地方。基本上，这是您可以要求磁盘做的最糟糕的事情。在现实生活中最常发生这种情况的地方：复制主目录和互联网，操纵电子邮件内容，一些数据库操作，源代码树。
当我在Ubuntu工作站中针对高性能SSD进行此测试时，他们推动了127mib/sec。在机架下方的服务器仅在其“高性能” 7200rpm Rust Disk上管理33mib/sec …但是即使到那时，这种速度的绝大多数也是因为数据是异步编写的，允许操作系统将其划分为较大，更高效的写入操作。
如果我们添加参数--fsync=1，迫使操作系统执行同步写入（呼叫fsync在编写每个数据块之后）图片变得更加严峻：高性能SSD上的2.6mib/sec，但在“高性能”生锈上只有184Kib/sec。当数据不同步时编写数据时，SSD的速度比Rust快四倍，但是当减少到最坏情况时，14次倍。
16平行64KIB随机写过程
fio --name=random-write --ioengine=posixaio --rw=randwrite --bs=64k --size=256m --numjobs=16 --iodepth=16 --runtime=60 --time_based --end_fsync=1
这次，我们正在创建16个独立的256MB文件（当全部组合在一起时，总计4GB），并且我们会发出64kb封锁的随机写操作。我们正在使用16个单独的流程并行运行，并且我们在停下来之前，我们将同时排队16个同步的操作，并等待OS开始确认其收据。
这是一个非常繁忙的系统的相当不错的近似值。它没有做任何特别令人讨厌的事情，例如运行数据库引擎或从用户主目录中复制大量的互联网 - 但它正在应对一堆应用程序，同时进行中等要求。
这也是繁忙的多用户系统（如NAS）的一个相当不错的，有点悲观的近似，它需要同时为不同用户处理多个1MB操作。如果几个人或过程试图一次读取或写大文件（照片，电影等），则操作系统试图同时喂食所有数据。这很快将其变为多个随机小块访问的模式。因此，除了“繁忙的桌面有很多应用程序”之外，还要将“忙碌的文件服务器与几个人积极使用它”。
观看此操作在控制台上播放时，您会看到速度的变化更多。例如，我们尝试的4K单个过程测试首先在我的MacBook Air的内部驱动器上写了一个相当一致的11MIB/sec，但是在运行期间，这项16个过程的作业在约10MIB/sec和300mib/sec之间波动，平均为126mib/sec。
您在这里看到的大多数变体都是由于操作系统和SSD固件有时能够汇总多个写入。当它设法将它们汇总在一起时，它可以以允许并行写入SSD内所有单个物理媒体条纹的方式编写它们。有时，最终仍然不得不放弃并仅写入单个物理媒体条纹，或者在SSD固件级别进行垃圾收集或其他维护操作，需要在后台短暂运行，从而减慢速度。
单1MIB随机写过程
fio --name=random-write --ioengine=posixaio --rw=randwrite --bs=1m --size=16g --numjobs=1 --iodepth=1 --runtime=60 --time_based --end_fsync=1
这非常接近实际情况进行现实世界中的现实系统的最佳情况。不，它的速度不如单个真正连续写的快速…但是1MIB封锁足够大，以至于非常接近。此外，如果从字面上同时请求其他磁盘活动，则几乎可以立即立即将“连续”写入“连续”写入为此水平，因此这是对典型系统中存储性能的上端的更真实测试。
进行此测试时，您会在SSD上看到一些怪异的波动。这在很大程度上是由于SSD的固件在任何给定时间的运气都更好或更糟的是，当它试图排队操作时，它可以立即清洁所有物理媒体条纹。 Rust磁盘会倾向于提供更一致的，尽管通常较低，但在整个运行中的吞吐量通常会提供。
您还可以看到，如果您耗尽了船上写缓存，则可以看到SSD的性能从悬崖上掉下来-TLC和QLC驱动器往往具有由MLC或SLC媒体更快的速度较小的小型缓存区域。一旦筋疲力尽，磁盘就必须下降到直接写给数据最终降落的TLC/QLC媒体较慢的媒体。这是三星EVO和Pro SSD之间的主要区别 - EVO具有慢速的TLC媒体，具有快速的MLC缓存，Pros在整个SSD中使用了更高的性能，更高的MLC MLC媒体。
如果您对TLC或QLC磁盘保持沉重写作的能力有任何疑问，则可能需要在此处延长您的时间持续时间。如果您随着工作的进行观看吞吐量的现场直播，当您用完缓存时，您会立即看到影响 - 相当稳定的，几百-Mib/sec吞吐量会突然跌至一半或更低的速度，并且稳定也较小。
但是，您可能会选择相反的位置 - 您可能不会期望经常持续的沉重写作，在这种情况下，您实际上对缓存行为更感兴趣。这里重要的是，您既了解要测试的内容，又了解如何准确测试。
结论
使用FIO绝对是真正的书呆子（或专业）的练习。它不会握住您的手，尽管它提供了令人难以置信的详细结果，但它们并没有为您自动制作成漂亮的图表。
如果所有这些感觉都太多了，您也可以找到更简单的图形工具，例如HD Tune Pro对于Windows。 HD Tune Pro的费用为35美元，或者有一个有限的非Pro版本，可以免费使用。这是一个很好的工具，它将制作闪亮的图形，但是对于高级用户而言，它更有限制，而Make-It-Easy用户界面的价格是，您与所做工作的技术现实相距甚远。
学习使用FIO意味着真正的学习异步和同步写作之间的差异，并且绝对知道它将在个人论点基础上以非常低的水平做什么。您不能确定像HD Tune Pro这样的工具在引擎盖下实际上在做哪些工具，并且必须在不同的操作系统上处理不同的工具，这意味着更难直接比较和对比结果。