RE: Disk Device Busy (%) - What exactly is this?

From: Taylor, Chris David <>
Date: Mon, 21 Nov 2011 10:29:59 -0600
Message-ID: <>

I don't think that actually 'accurate' though.

There are real IO limits on the following: 1.) LUNS themselves (how many disks in the stripe, RAID levels) 2.) IO Controller Card between the server and the LUN or disk

NOW, the question that 'should be' asked is:

"How does my OS determine the IO capacity of my storage?"

Imagine if the OS does a statistics gathering on the IO subsystem (much like Oracle does on tables) then it can possibly "know" within a reasonable margin of error what the expected IO bandwidth is for the storage system (regardless of whether or not it is a LUN or a DISK).

So, does ANYONE know how the OS (Windows, Linux etc) tries to determine the maximum IO available across a disk or LUN?

Chris Taylor
Sr. Oracle DBA
Ingram Barge Company
Nashville, TN 37205

"Quality is never an accident; it is always the result of intelligent effort."
-- John Ruskin (English Writer 1819-1900)

CONFIDENTIALITY NOTICE: This e-mail and any attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender immediately and delete the contents of this message without disclosing the contents to anyone, using them for any purpose, or storing or copying the information on any medium.

-----Original Message-----
From: [] On Behalf Of Radoulov, Dimitre Sent: Monday, November 21, 2011 10:21 AM To: Guillermo Alan Bort
Cc: oracle-l-freelists
Subject: Re: Disk Device Busy (%) - What exactly is this?

Hi Alan,
yes, this was new to me too. In another mail Grzegorz Goryszewski have just posted a link to an article by Alex Gorbachev, which seem to confirm that too:

Quoting it:

Traditionally, it's common to assume that the closer to 100% utilization a device is, the more saturated it is. This might be true when the system device corresponds to a single physical disk. However, with devices representing a LUN of a modern storage box, the story might be completely different. [...]



Received on Mon Nov 21 2011 - 10:29:59 CST

Original text of this message