Linux Core Design basis (vi) The block I/O layer

A block device is a data table device that can have a fixed size of random access devices. such as a hard disk; character devices (such as serial ports and keyboards) that are entered in order by the flow of characters. The difference is whether there is enough random access to the data--at this point, you can jump from one location to the access device and location at your own whim. More complex, in fact the kernel in the block device up and down a large effort-block I/O layer.

Basic concepts

• The smallest addressable unit in a block device is a sector.
• The minimum addressing unit of a file system is a block.

• The so-called buffer is the representation of the block in memory.
• For a buffer (block), the kernel needs to know its control information. A structure is needed to describe the description-the buffer head.

I/O scheduling mechanism
First of all, I/O scheduling here refers to disk scheduling. Disk addressing is a very time-consuming operation. For the various disk I/O requests that exist at the same time, we need to use some I/O Scheduler to implement the most time-saving request processing--I/O Scheduler, which arranges the entire request queue in the direction of sector growth. The order in which all requests are arranged in an orderly manner on the hard disk is not only to shorten the addressing time for a single request, but to optimize the disk addressing time for all requests by keeping the disk head moving in a straight line direction.

The sorting algorithm is similar to the elevator schedule-the elevator cannot jump from one layer to the next, and it should move in one direction. When you reach the last layer in the same direction, turn around and move in one direction. So I/O Scheduler is called Elevator dispatch.

In addition to sorting, merging is also a way to reduce the disk addressing time. Merging is the combination of two or more requests into a new request, which compresses the cost of multiple requests into the cost of a single request, and, more importantly, simply passes the request to disk with an addressing command. You will be able to access the area of the disk that has to be addressed multiple times before the request is merged, reducing the number of disk addresses.

Sort. Reduce addressing time. And the combination, reduce the number of addresses, the two common as I/O Scheduler guidelines. The following is a look at the five Linux actually used I/O scheduler. (1) Linus Elevator When a request is added to the queue. There are four possible actions that can occur:

• Suppose a request for an adjacent disk sector operation already exists in the queue. Then the new request will be merged into a single request with this already existing request.
• Assuming there is a request in the queue that is too long, the new request will be inserted at the end of the queue to prevent other old requests from starving.
• Suppose there is an appropriate insertion position in the queue in the order of sector orientation. Then the new request will be inserted into the location, ensuring that the requests in the queue are arranged in the order of the physical location of the visited disk.
• Suppose there is no suitable request insertion location in the queue. The request is inserted into the tail of the queue.

(2) Finally deadline I/O schedulerOther requests that result in a remote location from a continuous request to the same location on the disk will never be executed, which is a very unfair hunger phenomenon.

In the deadline I/O scheduling. Each request has a time-out, by default. The time-out for the read request is 500ms. The write request is 5s, the deadline I/O scheduling request is similar to Linus Elevator, also maintains the request queue in the order of the physical location of the disk, this queue is called the sort queue. When a new request is submitted to the sort queue, the deadline I/O Scheduler is similar to the Linus elevator when performing merge and insert requests, but the deadline I/O also inserts them into the extra queue at the same time by the request type.

Read requests are inserted sequentially into a particular read FIFO queue, and write requests are inserted sequentially into a specific write FIFO queue, although the normal queue is ordered in the disk sector. However, these queues are organized in FIFO (in chronological order), resulting in new queues being added to the tail of the queue for normal operations. The deadline I/O removes the request from the header of the sort queue. Push into the dispatch queue and submit the request to the disk driver by the dispatch queue. This ensures minimal request addressing.

The timeout for the deadline I/O now reads and writes the request timeout for the FIFO queue header. The scheduler extracts the request for service. There is no need to worry about the unfairness of requesting services. (3) Pre-measured I/O scheduler basically with the last term. It's just that it can predict. Suppose that the read request is one after the other, and for the time being the read request is continually addressed. And interrupts the in-progress write request, which can damage the system's global throughput. Suppose we can wait for a single read request to be uniformly addressed, which avoids a large number of addressing operations. After a request is submitted, the pre-test will then have an I/O request coming in the waiting period. Thus intentionally waiting for a moment (not a commit request to return to processing other requests immediately), which is the ingenious point of pre-I/O.

Such a prediction relies on a series of revelations and statistical work. (4) Fully-impartial queuing I/O scheduler it maintains a queue for each process, requests an increase in queue operations with the Linus elevator for four operations, which in fact provides fairness at the process level. (5) The I/O Scheduler for empty operations is not sorted. It is not pre-measured. It simply merges-merging adjacent requests. and the maintenance request queues are in near-FIFO order.

Copyright notice: This article Bo Master original article. Blog, not reproduced without consent.

Linux Core Design basis (vi) The block I/O layer