I/Os Per Second Myths

Terry Critchley

The performance of an application depends on the availability of adequate IT resources, such as CPU, memory, storage and so on.

Storage metrics of interest are:
■ Data capacity
■ Input/output capacity (I/O performance)
■ Durability, space, cooling, cost, ROI and other mainly commercial factors.

We are concerned in this blog with the second item, I/O capability, which is not as simple as my system does X input/output operations per second (IOPs). First, let us look at some background to input/output. The classical I/O time for a disk access is:

TCPU+TCTL+TSEEK+TWAIT+TSEARCH+TACC+TXFR+TCOMP

TCPU = Time to parse and generate the I/O request in the processor

TCTL = Time for the controller to format and issue the request to the HDD, plus the time for the request to reach the HDD

TSEEK = Time to move to the correct track on the HDD (called a SEEK)

TWAIT = Time waiting to reach the required record

(In case of disk subsystems with set sector capability, the channel disconnects from the particular I/O until the record position is about to be reached on the track, then reconnects to complete the I/O. In the meantime it can do something else with its time. Prior to this feature, the channel would wait until the head reached the right position and then release it after the I/O was complete.)

TACC = Time to access the record (SEARCH) which will have an overhead depending on the format of the data (RDBMS, flat file, RAID x and so on)

TXFR = Transfer time of the accessed data to the processor via the controller/channel

TCOMP = Time to complete/post the end of the I/O.

This time is divided into 1 second to get I/Os per second (IOPs). Is physical I/O speed all that matters then?

Records: A record to an application usually means a logical record, for example, the name and address of a client. This can be made up of more than one physical record, which is normally retrieved as a block of a certain size, for example, 2048 bytes. Some though, a physical record may contain more than one logical record.

Disk Access: An I/O operation consists of several activities and the list of these depends how far you go back in the chain from data need to fulfillment. This is shown in the I/O time equation above.

Myth 1

This myth is propagated widely in internet articles and is totally erroneous, so beware. The misconception is a follows:

■ if an I/O operation (seek, search, read) takes X milliseconds, then that disk arm is capable of supporting 1000/X I/Os per second (IOPs). Yes it is, if you don't mind a response time of approximately infinity, give or take a few ms as the arm would be running at 100% utilization.

A sensible approach would be to do this calculation and settle for, say, 40% of this IOPs rate as an average which might be sustained.

Myth 2

If we make the allowance above, then a storage subsystem supporting X IOPs will perform better than one supporting 0.8X IOPs. In its raw form, this statement is not true I'm afraid, since the I/Os needed to satisfy an application's request for data depends on other factors, many within the designer's control:

■ the positioning of the physical data and its fragmentation, the former no longer in the control of the programmer, the latter a fact of life, except for the ability to defragment when necessary

■ the type of application (email, query, OLTP etc.) and access mode (random, sequential, read or write intensive)

■ block sizes and other physical characteristics, such as rotational speed (up to 15,0000 rpm)

■ the use of memory caching or disk caching, which can eliminate some I/Os

■ the design of the database layout, which is crucial and trees have been sacrificed writing about this topic

■ what RAID level, or other access method, is employed

■ the program's mode of accessing logical records (see below) might be sub-optimal (to be mild about it); does it chain reads/writes, save records or retrieve them again and so on

■ the key and indexing should be optimized to avoid long synonym chains to compose a single record - the shorter the key the greater chance of synonyms

■ Other factors and storage subsystem parameters

The upshot of this is that very fast I/O performance can be negated by poor design and often is. If the items above are properly thought through then, and only then, will the system supporting X IOPs outperform the system supporting 0.8X IOPs. These design features assume that any metadata, such as logs, indexes, copies etc. are not written to the disks containing the application data.

Dr. Terry Critchley is the Author of “High Availability IT Services” ISBN 9781482255904 (CRC Press).

Related Links

The Latest

Observability Is the New Control Plane for Enterprise Transformation

The enterprises that will define the next decade are not the ones that deployed the most technology. They are the ones who understood what their technology was actually doing. That distinction is not a philosophical point. It is the central operational challenge facing every organization that has spent the last five years modernizing at speed ...

When AI Becomes the Corporate OS

AI is becoming the operating system of the enterprise. It acts as an invisible coordination layer that understands intent, connects systems, and executes work across complex SaaS environments. Previously, employees had to click through multiple systems — CRM, ERP, support tools, collaboration platforms — to complete a single task. Now, instead of navigating each application manually, they can simply state what they need to accomplish ...

The $600 Billion Wake Up Call

In 2026, the cost of downtime or an outage is no longer just a technical inconvenience; it's a $600 billion wake up call for global businesses. As our digital ecosystems become  more interconnected, each touchpoint introduces new risks and multiplies the consequences when things go wrong. And the data is clear: aggregate downtime costs  for Global 2,000 companies have surged 50% since 2024, reaching a staggering $600 billion ...

Breaking Down Agentic AI Fragmentation and Complexity with Governance

Deloitte found that 74% of enterprises expect to deploy agentic AI solutions in the next 24 months. However, the rush to deployment is outpacing foundational work, though. Only 21% of enterprises have fully formed agent governance models in place. The result? AI agents deployed without guidance or governance begin to function as fragmented islands of complexity ...

Cloud Spend Is Rising and Cloud Optimization Is Key to Funding AI and Protecting Margins

Cloud spending is no longer viewed as a passthrough IT expense, but as a strategic financial lever that directly impacts innovation capacity, profitability and enterprise resilience, according to the CFO Cloud Cost Optimization Report from Azul ...

Building AI Agents That Build Trust

As AI moves from generating responses to performing actions, the need for trust increases exponentially. And as organizations enlist AI agents for increasingly sophisticated business processes, trust is going to be the single most important theme for spurring adoption. What can organizations do to build trustworthy AI agents? ...

Keys to Building a Partner Ecosystem That Scales

I've spent a lot of time in the channel, and one thing I keep coming back to is this: a partner program is only as good as what it looks like in the field. Many programs look great on paper, but when a partner is in front of a customer navigating a complex hybrid environment or trying to make the case for AI-powered observability, the gap between what a vendor promises and what it actually delivers becomes very clear, very fast ...

How AI Agents Are Reshaping DataOps for the Always-On Enterprise

Enterprises today operate in a real-time environment where uninterrupted access to trusted data has become a baseline expectation for users, applications and automated systems. Traditional DataOps models, built on manual effort and human triage, cannot keep pace with this always active demand. AI agents are emerging as the operational backbone, ensuring consistent data availability, reinforcing trustworthiness and enabling a level of scale that manual processes cannot achieve ...

AI Deepfakes: Rethinking Trust in the Workplace

For decades, trust in the digital workplace rested on familiar signals. We trusted faces on video calls, voices on the phone, and emails that appeared to come from people we knew. These cues felt human and intuitive. They anchored how decisions were made, approvals were granted, and access was authorized. AI-powered deepfakes have quietly broken that model ...

Nine in Ten Enterprises Plan Cloud Data Repatriation amid Rising Cloud Costs and Data Sovereignty Mandates

Cloud migration was supposed to be a one-way door. For most enterprises, it turns out it isn't. Cloud data repatriation is a real and growing trend. A new survey ... finds that 89% of organizations plan to expand their on-premises infrastructure footprint over the next two years — and 75% have already moved at least some workloads back from public cloud in the past 24 months. The findings point to a broad rethinking of where data belongs ...

I/Os Per Second Myths

Terry Critchley

The performance of an application depends on the availability of adequate IT resources, such as CPU, memory, storage and so on.

Storage metrics of interest are:
■ Data capacity
■ Input/output capacity (I/O performance)
■ Durability, space, cooling, cost, ROI and other mainly commercial factors.

We are concerned in this blog with the second item, I/O capability, which is not as simple as my system does X input/output operations per second (IOPs). First, let us look at some background to input/output. The classical I/O time for a disk access is:

TCPU+TCTL+TSEEK+TWAIT+TSEARCH+TACC+TXFR+TCOMP

TCPU = Time to parse and generate the I/O request in the processor

TCTL = Time for the controller to format and issue the request to the HDD, plus the time for the request to reach the HDD

TSEEK = Time to move to the correct track on the HDD (called a SEEK)

TWAIT = Time waiting to reach the required record

(In case of disk subsystems with set sector capability, the channel disconnects from the particular I/O until the record position is about to be reached on the track, then reconnects to complete the I/O. In the meantime it can do something else with its time. Prior to this feature, the channel would wait until the head reached the right position and then release it after the I/O was complete.)

TACC = Time to access the record (SEARCH) which will have an overhead depending on the format of the data (RDBMS, flat file, RAID x and so on)

TXFR = Transfer time of the accessed data to the processor via the controller/channel

TCOMP = Time to complete/post the end of the I/O.

This time is divided into 1 second to get I/Os per second (IOPs). Is physical I/O speed all that matters then?

Records: A record to an application usually means a logical record, for example, the name and address of a client. This can be made up of more than one physical record, which is normally retrieved as a block of a certain size, for example, 2048 bytes. Some though, a physical record may contain more than one logical record.

Disk Access: An I/O operation consists of several activities and the list of these depends how far you go back in the chain from data need to fulfillment. This is shown in the I/O time equation above.

Myth 1

This myth is propagated widely in internet articles and is totally erroneous, so beware. The misconception is a follows:

■ if an I/O operation (seek, search, read) takes X milliseconds, then that disk arm is capable of supporting 1000/X I/Os per second (IOPs). Yes it is, if you don't mind a response time of approximately infinity, give or take a few ms as the arm would be running at 100% utilization.

A sensible approach would be to do this calculation and settle for, say, 40% of this IOPs rate as an average which might be sustained.

Myth 2

If we make the allowance above, then a storage subsystem supporting X IOPs will perform better than one supporting 0.8X IOPs. In its raw form, this statement is not true I'm afraid, since the I/Os needed to satisfy an application's request for data depends on other factors, many within the designer's control:

■ the positioning of the physical data and its fragmentation, the former no longer in the control of the programmer, the latter a fact of life, except for the ability to defragment when necessary

■ the type of application (email, query, OLTP etc.) and access mode (random, sequential, read or write intensive)

■ block sizes and other physical characteristics, such as rotational speed (up to 15,0000 rpm)

■ the use of memory caching or disk caching, which can eliminate some I/Os

■ the design of the database layout, which is crucial and trees have been sacrificed writing about this topic

■ what RAID level, or other access method, is employed

■ the program's mode of accessing logical records (see below) might be sub-optimal (to be mild about it); does it chain reads/writes, save records or retrieve them again and so on

■ the key and indexing should be optimized to avoid long synonym chains to compose a single record - the shorter the key the greater chance of synonyms

■ Other factors and storage subsystem parameters

The upshot of this is that very fast I/O performance can be negated by poor design and often is. If the items above are properly thought through then, and only then, will the system supporting X IOPs outperform the system supporting 0.8X IOPs. These design features assume that any metadata, such as logs, indexes, copies etc. are not written to the disks containing the application data.

Dr. Terry Critchley is the Author of “High Availability IT Services” ISBN 9781482255904 (CRC Press).

Related Links

The Latest

Observability Is the New Control Plane for Enterprise Transformation

The enterprises that will define the next decade are not the ones that deployed the most technology. They are the ones who understood what their technology was actually doing. That distinction is not a philosophical point. It is the central operational challenge facing every organization that has spent the last five years modernizing at speed ...

When AI Becomes the Corporate OS

AI is becoming the operating system of the enterprise. It acts as an invisible coordination layer that understands intent, connects systems, and executes work across complex SaaS environments. Previously, employees had to click through multiple systems — CRM, ERP, support tools, collaboration platforms — to complete a single task. Now, instead of navigating each application manually, they can simply state what they need to accomplish ...

The $600 Billion Wake Up Call

In 2026, the cost of downtime or an outage is no longer just a technical inconvenience; it's a $600 billion wake up call for global businesses. As our digital ecosystems become  more interconnected, each touchpoint introduces new risks and multiplies the consequences when things go wrong. And the data is clear: aggregate downtime costs  for Global 2,000 companies have surged 50% since 2024, reaching a staggering $600 billion ...

Breaking Down Agentic AI Fragmentation and Complexity with Governance

Deloitte found that 74% of enterprises expect to deploy agentic AI solutions in the next 24 months. However, the rush to deployment is outpacing foundational work, though. Only 21% of enterprises have fully formed agent governance models in place. The result? AI agents deployed without guidance or governance begin to function as fragmented islands of complexity ...

Cloud Spend Is Rising and Cloud Optimization Is Key to Funding AI and Protecting Margins

Cloud spending is no longer viewed as a passthrough IT expense, but as a strategic financial lever that directly impacts innovation capacity, profitability and enterprise resilience, according to the CFO Cloud Cost Optimization Report from Azul ...

Building AI Agents That Build Trust

As AI moves from generating responses to performing actions, the need for trust increases exponentially. And as organizations enlist AI agents for increasingly sophisticated business processes, trust is going to be the single most important theme for spurring adoption. What can organizations do to build trustworthy AI agents? ...

Keys to Building a Partner Ecosystem That Scales

I've spent a lot of time in the channel, and one thing I keep coming back to is this: a partner program is only as good as what it looks like in the field. Many programs look great on paper, but when a partner is in front of a customer navigating a complex hybrid environment or trying to make the case for AI-powered observability, the gap between what a vendor promises and what it actually delivers becomes very clear, very fast ...

How AI Agents Are Reshaping DataOps for the Always-On Enterprise

Enterprises today operate in a real-time environment where uninterrupted access to trusted data has become a baseline expectation for users, applications and automated systems. Traditional DataOps models, built on manual effort and human triage, cannot keep pace with this always active demand. AI agents are emerging as the operational backbone, ensuring consistent data availability, reinforcing trustworthiness and enabling a level of scale that manual processes cannot achieve ...

AI Deepfakes: Rethinking Trust in the Workplace

For decades, trust in the digital workplace rested on familiar signals. We trusted faces on video calls, voices on the phone, and emails that appeared to come from people we knew. These cues felt human and intuitive. They anchored how decisions were made, approvals were granted, and access was authorized. AI-powered deepfakes have quietly broken that model ...

Nine in Ten Enterprises Plan Cloud Data Repatriation amid Rising Cloud Costs and Data Sovereignty Mandates

Cloud migration was supposed to be a one-way door. For most enterprises, it turns out it isn't. Cloud data repatriation is a real and growing trend. A new survey ... finds that 89% of organizations plan to expand their on-premises infrastructure footprint over the next two years — and 75% have already moved at least some workloads back from public cloud in the past 24 months. The findings point to a broad rethinking of where data belongs ...