linux知识点-存储相关（一）

（一）- IO分层

存储IO很容易成为数据处理系统的瓶颈。而IO处理能力通常落后于CPU和内存。所以Memchached、redis等技术都在直接或间接地规避IO瓶颈，从而提高系统性能。

IO系统的分层图：

上图，主要层次分三部分。磁盘（存储）、VM（卷管理）和文件系统。
File system：解决了空间管理的问题，即：数据如何存放、读取。
Buffer Cache：解决数据缓冲的问题。对读进行cache，即缓存经常要用到的数据；对写进行buffer，缓冲一定数据以后，一次性进行写入。
VM：对应上图的Vol Mgmt。跟IO没有直接关系。处于文件系统和磁盘（存储）中间。屏蔽了底层磁盘对上层文件系统的影响。VM也可以把多个磁盘合并成一个磁盘，对文件系统呈现统一的地址空间，从而实现动态扩展。
存储/磁盘：对应上图的Device Driver、IO Channel和Disk Device，数据最终落地在此层，

Logical IO vs Physical IO

逻辑IO是操作系统发起的IO，这个数据可能会放在磁盘上，也可能会放在内存（文件系统的Cache）里。
物理IO是设备驱动发起的IO，这个数据最终会落在磁盘上。
逻辑IO和物理IO不是一一对应的。

分层应用的示例：

应用的一次IO和OS的一次IO和物理盘一个IO的关系：
本质就是问一个逻辑IO是否对应一个物理IO，通过前文知道他们之间有很多层，经过各层的处理机制后，发生在物理磁盘上的IO是不确定的。可能是一对一个，也可能一个对应多个。也可能多对一。

在应用层发起一个对物理磁盘上一个1G连续数据的读取请求，那没在OS层和物理层，这个请求会被拆分吗：
应用层发起一个对物理磁盘上1G连续数据的读取请求时，该请求在OS层和物理层的处理方式涉及操作系统的I/O管理机制和磁盘硬件的物理特性。以下是针对请求是否被拆分的分析，基于磁盘I/O原理、操作系统缓冲机制及数据传输特性

OS层：
请求可能被拆分，具体取决于I/O模式和系统实现
缓冲I/O模式下大概率拆分：如果使用缓冲I/O（Buffered I/O），操作系统会将数据通过内核缓冲区（PageCache）中转。此时，1G的连续请求会被拆分成多个内存页（通常为4KB或更大）处理，以提高缓存利用率和减少中断频率。例如，内核可能按页帧大小分块读取数据到PageCache，再拷贝至用户空间
直接I/O模式下可能避免拆分：若采用直接I/O（Direct I/O），请求可绕过PageCache直接访问磁盘，理论上能减少拆分。但操作系统仍可能因块设备限制（如文件系统块大小）或DMA（直接内存访问）控制器参数，将请求拆分为多个子请求（例如按磁盘块大小划分）
影响的因素
I/O调度策略（如Linux的CFQ或Deadline调度器）可能合并或拆分请求以优化磁盘队列
连续数据虽可触发预读机制（Read-ahead）减少I/O次数，但初始请求仍可能被拆分为块序列加载到缓冲区

物理层：
请求一定会被拆分为固定大小的块
磁盘硬件的最小操作单位‌：物理磁盘（包括机械硬盘HDD和固态硬盘SSD）以扇区（Sector）为最小读写单元（通常为512B或4KB）。1G请求必须分解为数十万至数百万个扇区操作：

• 机械硬盘（HDD）通过磁头连续读取扇区，但每个扇区访问独立完成，物理上仍为多个操作1213。
• 固态硬盘（SSD）虽无寻道延迟，但需按“页”（Page，通常4KB）和“块”（Block，多个页组成）读写，请求同样会被拆分12。
  数据传输特性：物理层通过总线（如SATA或PCIe）传输数据时，采用串行或并行方式逐块传输，无法一次性处理1G数据单元。例如，串行传输逐比特发送，并行传输虽多路并发但受总线宽度限制（如64位），仍需分块处理
  DMA的作用：DMA控制器可减少CPU干预，但仍需按块大小（如4KB）分段传输数据，确保与磁盘扇区对齐

结论
OS层拆分是可能的但不是必然，取决于I/O模式（缓冲/直接）和系统优化策略。
物理层拆分是绝对的，因磁盘硬件和物理传输机制强制以固定块大小处理数据。
连续数据虽能提升效率（如减少寻道或触发预读），但无法改变底层分块执行的本质

（二）- IO处理模型

所有IO处理都是类似的。

IO请求的两个阶段：

等待和使用，也就是排队和服务。

• 等待资源阶段：IO请求一般需要请求特殊的资源（如磁盘、RAM、文件），当资源被上一个使用者使用没有被释放时，IO请求就会被阻塞，直到能够使用这个资源。
  在等待数据阶段，IO分为阻塞IO和非阻塞IO:
  • 阻塞IO：应用程序在进行IO操作时会一直等待，直到IO操作完成后才会继续执行下一条指令。因此，阻塞IO会阻塞应用程序的执行;
  • 非阻塞IO：应用程序在进行IO操作时不会等待，而是立即返回一个结果。如果IO操作未完成，则应用程序可以继续执行其他操作。应用程序可以不断地轮询IO操作的状态，直到IO操作完成。
• 使用资源阶段：
  真正进行数据接收和发送。此阶段，IO分为同步IO和异步IO。
  • 同步IO：应用程序在进行IO操作时会等待IO操作完成后再进行下一步操作。也就是说，应用程序需要等待IO操作返回结果后，才能继续进行其他操作。
  • 异步IO：应用程序在进行IO操作时不会等待IO操作完成，而是立即返回结果。应用程序不需要等待IO操作完成，可以继续进行其他操作。当IO操作完成后，操作系统会通知应用程序，并将结果传递给应用程序。

特点

• 阻塞IO：使用简单，问题是会形成阻塞，需要独立线程配合，而这些线程在大多数时候都是没有进行运算的。Java的BIO使用这种方式，带来的问题很明显，一个Socket需要一个独立的线程，因此，会造成线程膨胀。
• 非阻塞IO：采用轮询方式，不会形成线程的阻塞。Java的NIO使用这种方式，比BIO的优势明显，可以使用一个线程进行所有Socket的监听（select）。大大减少了线程数。
• 同步IO：一个IO操作结束之后才会返回，因此效率会低一些，但是编程简单。Java的BIO和NIO都是使用这种方式进行数据处理。
• 异步IO：只是写入了缓存，从缓存到硬盘是否成功不可知，相当于把一个IO拆成了两部分，一是发起请求，二是获取处理结果。对应用来说增加了复杂性。但是异步IO的性能是所有很好的。

OS中IO的并行

Linux 系统中，磁盘 I/O 操作不存在绝对的并行性,但通过多层次的技术手段可实现高度的并行处理能力。核心原因在于硬件限制（如磁盘磁头物理移动、SSD 通道竞争）和软件层面的协调需求
Linux 通过硬件协议支持（如 NVMe）、内核调度优化（blk-mq、io_uring）和应用层设计，实现了磁盘 I/O 的高效并行处理，尤其在多核 CPU 和 SSD 环境下接近硬件极限。但受限于物理规律（机械硬盘）和共享资源协调需求，绝对的并行性（所有操作完全同时执行）无法实现。实际开发中，需结合异步 I/O 和任务分区策略最大化并发性能

硬件与协议层的并行支持

NVMe 协议

• 现代 SSD 通过 NVMe 协议支持深度队列（如 64K 队列深度）和多队列机制，允许同时提交大量 I/O 请求。
• 每个 CPU 核心可绑定独立队列，实现硬件级并发处理
  多通道 SSD 架构
• SSD 内部通过多 NAND 通道并行读写数据，物理上支持同时处理多个 I/O 请求（但通道资源可能竞争）‌

操作系统层的并行

1. 块设备多队列（blk-mq）‌

• Linux 内核的 blk-mq 框架将 I/O 请求分发到多个硬件队列，消除单队列锁竞争，显著提升多核 CPU 的并行效率

2. 异步 I/O 模型

• io_uring‌：
  • 通过环形队列实现无锁提交和完成 I/O 请求‌，用户态和内核态共享队列，减少上下文切换。
  • 支持轮询模式（Polling），完全绕过中断机制，实现超低延迟并行处理。
• AIO（内核异步 I/O）‌：
  • 允许应用异步提交 I/O 请求，但存在回调函数复杂性和缓冲区管理限制

3. 文件系统并发控制

• 日志型文件系统（如 ext4/XFS）通过日志区域批量提交写操作，但元数据更新可能需短暂锁同步。
• 新型文件系统（如 Btrfs）优化子树锁，提升并发写能力

应用层并行策略

1. 多线程/进程 I/O

• 多线程并发读写不同文件（或文件不同区域）可最大化利用硬件队列深度，实现近似并行4。

2. Direct I/O（绕过页缓存）

• 直接访问磁盘避免 Page Cache 锁竞争，适合自管理缓存的高性能数据库（如 PostgreSQL）‌45。

3. 分散-聚集 I/O（Scatter/Gather）

• readv()/writev() 单次系统调用处理多个非连续缓冲区请求，减少系统调用次数…

局限性

1. 共享资源竞争

• 多进程写同一文件时需文件锁（如 fcntl 锁）或日志协调，导致串行化。

2. 硬件瓶颈

• 机械硬盘磁头物理移动无法并行；SSD 多通道共享带宽，超负荷时仍会排队。

3. 元数据操作

• 文件创建、删除、权限修改等操作需全局锁（如 inode 锁），天然串行

存储设备的IO并行

并行性受限于硬件架构、协议设计和资源共享机制。

硬件层并行限制

1. 物理资源竞争

• 机械硬盘（HDD）‌：磁头寻道和盘片旋转需串行操作，同一时刻仅能处理一个 I/O 请求。
• SSD‌：
  • NAND 闪存芯片通过多通道（如 8-16 通道）并行读写，但通道数量有限，超负荷时仍需排队；
  • 写入前需擦除块（Erase-Before-Write），垃圾回收（GC）会暂停用户 I/O，破坏并行连续性

协议层并行机制与瓶颈

1. NVMe 协议的多队列优化

• 支持 64K 队列深度，每个队列独立处理 I/O 请求，实现逻辑并行；
• 但提交队列（SQ）和完成队列（CQ）通过 Doorbell 寄存器同步‌，主机更新 SQ 尾指针或 SSD 更新 CQ 头指针时存在串行化步骤。

2. 控制器调度瓶颈

• SSD 控制器需仲裁多队列请求，映射物理地址（FTL 转换）并协调闪存通道，高负载时成为性能瓶颈

系统层并行约束

1. 操作系统调度

• 文件系统元数据操作（如 inode 更新）需全局锁，导致串行化；
• I/O 调度器（如 Linux KYBER）在高并发时引发队列竞争。

2. 共享资源冲突

• 多进程写同一文件时需文件锁协调（如 fcntl），强制串行访问

并行是有限的优化而非绝对特性

• 逻辑并行性‌：NVMe SSD 通过多队列深度实现高并发 I/O（如企业级 SSD 支持百万级 IOPS），但受限于物理通道和控制器算力2023；
• 物理并行性‌：SSD 多通道架构提升吞吐量，但写入放大、垃圾回收等机制会中断并行流818；
• 系统瓶颈‌：协议同步点（如 Doorbell 寄存器）、内核锁竞争、资源冲突等均破坏绝对并行

（三）- IO性能的核心指标

最重要的三个指标

• IOPS：每秒钟完成处理的IO请求数量。IOPS是随机访问类型业务（OLTP类）很重要的一个参考指标。
• IO Response Time：IO的响应时间。
• Throughput：为吞吐量，数据流量，和带宽类似。

IOPS

IOPS (Input/Output Per Second)即每秒的I/O请求数量，I/O请求通常为读或写数据操作请求。
随机读写频繁的应用，如：小文件存储(图片)、OLTP数据库、邮件服务器，需要关注随机读写性能，IOPS是关键衡量指标。

不同类型硬盘的IOPS：

传统机械磁盘：进行数据读取时，比较重要的几个时间是：寻址时间（找到数据块的起始位置），旋转时间（等待磁盘旋转到数据块的起始位置），传输时间（读取数据的时间和返回的时间）。其中寻址时间是固定的（磁头定位到数据的存储的扇区即可），旋转时间受磁盘转速的影响，传输时间受数据量大小的影响和接口类型的影响（不用硬盘接口速度不同），但是在随机访问类业务中，他的时间也很少。因此，在硬盘接口相同的情况下，IOPS主要受限于寻址时间和传输时间。以一个15K的硬盘为例，寻址时间固定为4ms，传输时间为60s/15000*1/2=2ms，忽略传输时间。1000ms/6ms=167个IOPS。
但是随着科技发张不同的类型的硬盘的能力是不通的，几种主流硬盘的能力：
硬盘类型‌ ‌典型IOPS（4K随机）‌ ‌响应时间‌ ‌接口/协议‌
HDD (7,200 RPM) 50~200 5~20 ms SATA/SAS
SATA SSD “读: 50K~100K写: 20K~80K” 0.05~0.3 ms SATA 3.0 (6 Gbps)
NVMe SSD (消费级) “读: 200K~500K写: 150K~400K” 0.02~0.1 ms PCIe 4.0/5.0
NVMe SSD (企业级) “读: 500K~1.5M+写: 300K~800K+” <0.1 ms PCIe 4.0/5.0

影响IOPS主要的因素：

物理硬盘IOPS能力是有限的，这是整个IO系统瓶颈的最大根源。所以，如果一块硬盘不能提供，那么多块在一起并行处理，
存储硬件配置对IPOS影响最直接：
缓存：缓存的大小和命中率对IOPS有较大影响，命中率既同缓存大小有关也和缓存算法有关。
RAID级别。相同外部条件和硬件条件时候，不同的RAID级别IO的效率不同。
磁盘：磁盘的类型、磁盘数量都会影响IOPS；
对存储、操作系统的配置：条带、lun等配置、lvm 也会影响IOPS
越是高端的存储设备的cache越大，硬盘越多，一方面通过cache异步处理IO，另一方面通过盘数增加，尽可能把一个OS的IO分布到不同硬盘上，从而提高性能。文件系统则是在cache上会影响，而VM则可能是一个IO分布到多个不同设备上（Striping）。
应用读写特点也影响IOPS：
读写混合比：对读操作，一般只要cache能足够大，可以大大减少物理IO，而都在cache中进行；对写操作，不论cache有多大，最终的写还是会落到磁盘上。因此，100%写的IOPS要越狱小于100%的读的IOPS。同时，100%写的IOPS大致等同于存储设备能提供的物理的IOPS。
一次IO请求数据量的多少:一次读写1KB和一次读写1MB，显而易见，结果是完全不同的。
当时上面N多因素混合在一起以后，IOPS的值就变得扑朔迷离了。所以，一般需要通过实际应用场景的测试才能获得。

IO Response Time

O响应时间是从操作系统内核发出一个IO请求到接收到IO响应的时间。前文IOPS中也介绍了不同硬盘的响应时间，对一个OLTP系统，10ms以内的响应时间，是最佳实践。
实际IO场景中：
一个8K的IO会比一个64K的IO速度快，因为数据读取的少些。
一个64K的IO会比8个8K的IO速度快，因为前者只请求了一个IO而后者是8个IO。
串行IO会比随机IO快，因为串行IO相对随机IO说，即便没有Cache，串行IO在磁盘处理上也会少些操作。

延迟的精确组成阶段：

各个阶段的时间构成：

• 应用层请求提交：
  用户态到内核态的系统调用耗时（如 read()/write() 上下文切换）
• 内核I/O调度与队列等待：
  关键瓶颈：请求在操作系统I/O队列中的等待时间，队列深度越大延迟非线性增长（超70%负载时延迟暴增）；
  文件系统处理（元数据锁、日志提交）及块设备层调度（如CFQ调度算法）耗时
• 驱动层传输：
  协议封装（如SCSI命令转换）、数据传输至HBA/控制器的时间。总线传输延迟（如PCIe通道传输时延）
• 存储设备物理操作
  HDD：寻道时间（磁头移动，3-15ms） + 旋转延迟（盘片转动，2-8ms） + 数据传输（0.1ms级）
  SSD：NAND闪存访问延迟（电荷读取/写入，约50-150μs），控制器处理及FTL映射表查询开销

队列等待是最大变量：尤其在高负载下，OS调度和队列拥塞可能导致延迟飙升数倍
协议差异显著：NVMe通过消除协议转换层（如SCSI）和深度队列，将驱动层延迟压缩10倍以上
SSD写放大效应：TLC/QLC SSD在垃圾回收时写入延迟可能突发增至毫秒级

不同物理介质延迟对比

阶段‌ ‌HDD延迟‌ ‌SATA SSD延迟‌ ‌NVMe SSD延迟‌
OS队列等待（满载） 5~50 ms 0.1~2 ms ‌0.02~0.3 ms‌
设备物理操作 5~20 ms 0.05~0.3 ms ‌0.01~0.1 ms‌
‌端到端总延迟‌ ‌10~70 ms‌ ‌0.1~3 ms‌ ‌0.03~0.5 ms

Throughput

这个指标衡量标识了 最大的数据传输量（不是动态变化值，是一个上限值）。如上说明，这个值在顺序访问或者大数据量访问的情况下会比较重要。尤其在大数据量写的时候。
顺序读写频繁的应用，传输大量连续数据，如电视台的视频编辑，视频点播VOD(Video On Demand)，关注连续读写性能。数据吞吐量是关键衡量指标(因为这些场景可以达到性能上限，随机小IO通常没能达到吞吐量上限IOPS就已经达到了极限)。

吞吐量的影响因素不像IOPS那样多，其受限于一些比较固定的因素，如：网络带宽、IO传输接口的带宽、硬盘接口带宽等。一般他的值就等于上面几个地方中某一个的瓶颈。
吞吐量的决定因素：
吞吐量主要取决于阵列的构架，光纤通道的大小(现在阵列一般都是光纤阵列，至于SCSI这样的SSA阵列，我们不讨论)以及硬盘的个数。阵列的构架与每个阵列不同而不同，他们也都存在内部带宽(类似于pc的系统总线)，不过一般情况下，内部带宽都设计的很充足，不是瓶颈的所在。
　　光纤通道的影响还是比较大的，如数据仓库环境中，对数据的流量要求很大，而一块2Gb的光纤卡，所能支撑的最大流量应当是2Gb/8(小B)=250MB/s(大B)的实际流量，当4块光纤卡才能达到1GB/s的实际流量，所以数据仓库环境可以考虑换4Gb的光纤卡。
　　最后说一下硬盘的限制，这里是最重要的，当前面的瓶颈不再存在的时候，就要看硬盘的个数了，我下面列一下不同的硬盘所能支撑的流量大小：
　　10Krpm 15Krpm ATA
——— ——— ———
　　 10M/s 13M/s 8M/s
　　那么，假定一个阵列有120块15K rpm的光纤硬盘，那么硬盘上最大的可以支撑的流量为120*13=1560MB/s，如果是2Gb的光纤卡，可能需要6块才能够，而4Gb的光纤卡，3-4块就够了。

注：

不同场合关注不同的指标：
不用的应用场景需要观察不同的指标，因为应用场景不同，有些指标甚至是没有意义的。
随机访问和IOPS: 在随机访问场景下，IOPS往往会到达瓶颈，而这个时候去观察Throughput，则往往远低于理论值。
顺序访问和Throughput：在顺序访问的场景下，Throughput往往会达到瓶颈（磁盘限制或者带宽），而这时候去观察IOPS，往往很小。
读取10000个1KB文件，用时10秒 Throught(吞吐量)=1MB/s ，IOPS=1000 追求IOPS
读取1个10MB文件，用时0.2秒 Throught(吞吐量)=50MB/s, IOPS=5 追求吞吐量

IOPS与IO Response Time关系紧密。
通常：IOPS增加，前期IO Response Time不变，IOPS到达一定程度响应时间会随之增加。随着IOPS一直增加，IO Response Time会陡峭上升，这时候的IOPS虽然还在提高，但是实际意义已经不大。
IOPS越接近设备的理论的最大值，IO的响应时间会成非线性的增长，会比预期超出很多。
一般来说在实际的应用中有一个70%的指导值，就是当一个系统的IO压力超出最大可承受压力的70%的时候就是必须要考虑调整或升级了。另：这个70%指导值的最佳实践也适用于CPU响应时间，一旦CPU超过70%，系统将会变得受不了的慢。

监控工具差异
iostat 显示的是设备响应时间（不含OS队列）
应用层感知的延迟需专用工具（如 fio 的 lat 指标）

写延迟高于读延迟：因存储设备需确保数据持久化（如SSD的Program/Erase周期）

（四）一些其他IO/指标/概念

IO Chunk Size
即单个IO操作请求数据的大小。
一次IO操作是指从发出IO请求到返回数据的过程。IO Chunk Size与应用或业务逻辑有着很密切的关系。比如像Oracle一类数据库，由于其block size一般为8K，读取、写入时都此为单位，因此，8K为这个系统主要的IO Chunk Size。
IO Chunk Size小，考验的是IO系统的IOPS能力；
IO Chunk Size大，考验的时候IO系统的IO吞吐量。

Queue Deep
数据库的SQL是可以批量提交的，这样可以大大提高操作效率。IO请求也是一样，IO请求可以积累一定数据，然后一次提交到存储系统，这样一些相邻的数据块操作可以进行合并，减少物理IO数。而且Queue Deep如其名，就是设置一起提交的IO请求数量的。一般Queue Deep在IO驱动层面上进行配置。
Queue Deep与IOPS有着密切关系。Queue Deep主要考虑批量提交IO请求，自然只有IOPS是瓶颈的时候才会有意义，如果IO都是大IO，磁盘已经成瓶颈，Queue Deep意义也就不大了。一般来说，IOPS的峰值会随着Queue Deep的增加而增加(不会非常显著)，Queue Deep一般小于256。

随机IO、顺序IO
随机访问的特点是IO请求的数据在磁盘上的位置跨度很大（如：分布在不同的扇区），因此N个非常小的IO请求（如：1K），必须以N次IO请求才能获取到相应的数据。
顺序访问的特点跟随机访问相反，它请求的数据在磁盘的位置是连续的。当系统发起N个非常小的IO请求（如：1K）时，因为一次IO是有代价的，系统会取完整的一块数据（如4K、8K），所以当第一次IO完成时，后续IO请求的数据可能已经有了。这样可以减少IO请求的次数。这也就是所谓的预取。
随机访问和顺序访问同样是有应用决定的。如数据库、小文件的存储的业务，大多是随机IO。而视频类业务、大文件存取，则大多为顺序IO。
机械硬盘的连续读写性很好， 但随机读写性能很差。这是因为磁头移动至正确的磁道上需要时间，随机读写时，磁头不停的移动，时间都花在了磁头寻道上，所以性能不高。 如下图：

缓存IO
缓存I/O又被称作标准I/O，大多数文件系统的默认I/O操作都是缓存I/O。在Linux的缓存I/O机制中，数据先从磁盘复制到内核空间的缓冲区，然后从内核空间缓冲区复制到应用程序的地址空间。
读操作：操作系统检查内核的缓冲区有没有需要的数据，如果已经缓存了，那么就直接从缓存中返回；否则从磁盘中读取，然后缓存在操作系统的缓存中。
写操作：将数据从用户空间复制到内核空间的缓存中。这时对用户程序来说写操作就已经完成，至于什么时候再写到磁盘中由操作系统决定，除非显示地调用了sync同步命令
缓存I/O的优点：1）在一定程度上分离了内核空间和用户空间，保护系统本身的运行安全；2）可以减少读盘的次数，从而提高性能。
缓存I/O的缺点：在缓存 I/O 机制中，DMA 方式可以将数据直接从磁盘读到页缓存中，或者将数据从页缓存直接写回到磁盘上，而不能直接在应用程序地址空间和磁盘之间进行数据传输，这样，数据在传输过程中需要在应用程序地址空间（用户空间）和缓存（内核空间）之间进行多次数据拷贝操作，这些数据拷贝操作所带来的CPU以及内存开销是非常大的。

直接IO
直接IO就是应用程序直接访问磁盘数据，而不经过内核缓冲区，这样做的目的是减少一次从内核缓冲区到用户程序缓存的数据复制。比如说数据库管理系统这类应用，它们更倾向于选择它们自己的缓存机制，因为数据库管理系统往往比操作系统更了解数据库中存放的数据，数据库管理系统可以提供一种更加有效的缓存机制来提高数据库中数据的存取性能。
直接IO的缺点：如果访问的数据不在应用程序缓存中，那么每次数据都会直接从磁盘加载，这种直接加载会非常缓存。通常直接IO与异步IO结合使用，会得到比较好的性能。（异步IO：当访问数据的线程发出请求之后，线程会接着去处理其他事，而不是阻塞等待）

单块磁盘一些相关概念：
rpm：Revolution Per Minute，意为每分钟旋转的圈数。磁盘旋转速度，即磁盘每分钟旋转的圈数。它是影响磁盘读取速度的重要因素之一,常见的磁盘rpm有5400转、7200转、10000转等。

寻道时间：Tseek是指将读写磁头移动至正确的磁道上所需要的时间。寻道时间越短，I/O操作越快，目前磁盘的平均寻道时间一般在3－15ms。
常见磁盘平均物理寻道时间为：
7200转/分的STAT硬盘平均物理寻道时间是10.5ms
10000转/分的STAT硬盘平均物理寻道时间是7ms
15000转/分的SAS硬盘平均物理寻道时间是5ms

旋转延迟：Trotation是指盘片旋转将请求数据所在扇区移至读写磁头下方所需要的时间。旋转延迟取决于磁盘转速，通常使用磁盘旋转一周所需时间的1/2表示。比如，7200 rpm的磁盘平均旋转延迟大约为601000/7200/2 = 4.17ms，而转速为15000 rpm的磁盘其平均旋转延迟为2ms。
常见硬盘的旋转延迟时间为：
7200 rpm的磁盘平均旋转延迟大约为601000/7200/2 = 4.17ms
10000 rpm的磁盘平均旋转延迟大约为601000/10000/2 = 3ms，
15000 rpm的磁盘其平均旋转延迟约为601000/15000/2 = 2ms。

数据传输时间：Ttransfer是指完成传输所请求的数据所需要的时间，它取决于数据传输率，传输时间=数据大小/数据传输率。目前IDE/ATA能达到133MB/s，SATA II可达到300MB/s的接口数据传输率，数据传输时间通常远小于前两部分消耗时间。简单计算时可忽略。

磁盘服务时间：即磁盘完成一个I/O请求所花费的时间，它由寻道时间、旋转延迟和数据传输时间三部分构成。

单磁盘最大IOPS的理论计算方法:
IOPS = 1000 ms/ (寻道时间 + 旋转延迟)。可以忽略数据传输时间。所以7200、10000、15000 rpm的磁盘对应的理论最大iops分别为 68、100、142