The Life of an I/O Request

[ Team LiB ]

The Life of an I/O Request DB2 issues I/O requests via the OS Kernel routines. If SMS or DMS file containers are being used, these requests go through the OS file system code. If DMS device containers are used, DB2 issues I/O requests that are passed to the appropriate device drivers by the OS Kernel. The file system is not used in this case. In either case, the actual request is transferred to the host adapter. Figure 6.2 is an example of an I/O request using the Small Computer System Interface (SCSI). Figure 6.2. The life of an I/O. In Figure 6.2, DB2 issues a call (I/O request) to the OS. The OS Kernel routine passes the request to either the OS file system, or in the case of DMS devices, directly to the SCSI device driver. The SCSI device driver sends the appropriate SCSI command to the target device. The target device receives the request and immediately checks its own internal buffers for the data; if not found, the device must perform a disk seek operation to retrieve the requested data. The device issues the seek and disconnects from the bus to wait for the seek to complete. In the meantime another request can be sent by the adapter over the bus to a different disk. The second disk device receives the request, checks its own buffer, and starts the seek to retrieve the data and disconnect from the bus. In the meantime, the seek to the first device completes and this device gains control of the bus and transfers the data. The I/O operation is thus complete. It is important to note that Figure 6.2 illustrates a single request; however the process works the same way for multiple requests. Multiple requests can be processed if containers are on separate physical disks. DB2 will use a separate prefetcher per container. In that case, while the first disk is seeking and has given up control of the bus, the next request from the queue is processed, for example, to Disk2. Disk2 checks its buffer and has to do a seek, causing it to give up control of the bus. Meanwhile, the I/O on Disk1 completes so Disk1 can now transfer the data while Disk2 seeks, and so on. See Figure 6.3 for a sample tablespace disk layout. Figure 6.3. Sample disk layout. In the example, three physical disks enable multiple disk seek operations to occur. And, having the data spread over three host adapters ensures that required throughput and high availability can be attained. These disks are configured in a RAID-1 configuration. However, the second copy of the data is not shown. In the next section, we show an example that illustrates how to design and configure tablespaces in a RAID-5 ESS environment.

[ Team LiB ]