Video | The I/O Request Path: Why Unnecessary I/Os are Created

We’re going to be talking about the path that an I/O request takes from the application, all the way down to the storage.

So, let’s take an example of a typical user. This user is going to try to write and store two megabytes of data.  Let’s say it’s a Microsoft Word document.

Now, Windows doesn’t necessarily know what type of physical storage I have, nor does it really need to know.

All it’s going to take into consideration is that Windows believes that there is some type of virtual or logical description of the type of storage. It has a starting address and an end of disc location.

All the logical clusters are mapped into individual pieces, these are called clusters. And that’s identified in a file system structure called the dollar bitmap.

The dollar bitmap file contains information about which clusters are allocated and which clusters are marked as free. So, if I’m going to store and save information out of a two megabyte word document, the same would be true whether it’s SQL or whether it’s Exchange or a PowerPoint or any type of file that you’re storing.

Windows is going to look for the next available free space. So, if the next available free space is only 128 kb in size well there’s certainly not enough room to place two megabytes of data into a section of space that’s mapped to be 128 kb in size.

So, as a result you’ll have one part of the file in one location, then you might have the next piece of the file, let’s say it’s 256 kb in size, being referenced in a different location, and maybe the next chunk of space is only 64 kb in size, and that’s in another location.  So, you can say that as the number of extents to a file build up, each of these extents maps to a different range of logical clusters. As a result, each of these I/O requests has to be communicated down to the next level.

Okay, so we have one I/O, we’ll have another I/O request, a third, and a fourth in this example.

Each of these I/O requests takes a measurable amount of time. In fact, this is measured within the Microsoft windows performance monitoring utility called a split I/O. It’s where your application says do this one thing but then Windows has to translate it into multiple additional requests.

So, each of those takes a measurable amount of time; takes longer to be passed on, and makes each layer underneath this whether, it’s the Raid or SAN driver, become less and less efficient.

Because it’s less efficient, and taking more I/O request, and each I/O request takes a certain amount of time to complete. it can obviously see that storing a two megabyte file into four locations takes four times longer than it would if the file is just in one piece.

So let’s take the same example only this time, the data being written to a storage device is a two megabyte file that’s just in one piece. Well, it’s got to communicate to the dollar bitmap file. And, the dollar bitmap file again sees a start and an end location of all the clusters that are represented down at the physical storage level, and in this particular case, if it finds a chunk of free space that’s big enough to contain the entire file, then only ONE I/O request is necessary to filter on down.

So again, it becomes a question as to, how many I/Os do you really want to do? The fewer number of I/O requests that are necessary, the more efficient, the faster your applications behave.

In fact, DymaxIO, from Condusiv Technologies has a specific type of technology called IntelliWrite that allows us to locate these large chunks of free space and use those instead of allowing Windows to split the file into multiple pieces. So, if we can make a file be written in a larger, contiguous area, then the file no longer becomes fragmented, issues the fewest number of I/O requests, which makes then the underlying storage more and more efficient. Therefore, the data that comes back to the user is faster, and you can do more work in the same amount of time.