技術乾貨 | 漫遊Linux塊IO

在計算機的世界裡，我們可以將業務進行抽象簡化為兩種場景—— 計算密集型和 IO密集型。這兩種場景下的表現，決定這一個計算機系統的能力。資料庫作為一個典型的基礎軟體，它的所有業務邏輯同樣可以抽象為這兩種場景的混合。因此，一個資料庫系統效能的強悍與否，往往跟作業系統和硬體提供的計算能力、IO能力緊密相關。

除了硬體本身的物理極限，作業系統在軟體層面的處理以及提供的相關機制也尤為重要。因此，想要資料庫發揮更加極限的效能，對作業系統內部相關機制和流程的理解就很重要。

本篇文章，我們就一起看下 Linux中一個IO請求的生命週期。Linux發展到今天，其內部的IO子系統已經相當複雜。每個點展開都能自成一篇，所以本次僅是對塊裝置的寫IO做一個快速的漫遊，後續再對相關專題進行詳細分解。

SYSCALL_DEFINE3(write, unsigned int, fd, const char __user *, buf,
		size_t, count)
{
	struct fd f = fdget_pos(fd);
	ssize_t ret = -EBADF;
	if (f.file) {
		loff_t pos = file_pos_read(f.file);
		ret = vfs_write(f.file, buf, count, &pos);
		if (ret >= 0)
			file_pos_write(f.file, pos);
		fdput_pos(f);
	}
	return ret;
}

const struct file_operations def_blk_fops = {
	.open		= blkdev_open,
    ... ...
	.read		= do_sync_read,
	.write		= do_sync_write,
    ... ...
};

const struct file_operations_extend  ext4_file_operations = {
	.kabi_fops = {
    ... ...
		.read		= do_sync_read,
		.write		= do_sync_write,
    ... ...
		.open		= ext4_file_open,
    ... ...
};

ssize_t __generic_file_aio_write(struct kiocb *iocb, const struct iovec *iov,
				 unsigned long nr_segs, loff_t *ppos)
    ... ...
	if (io_is_direct(file)) {
    ... ...
		written = generic_file_direct_write(iocb, iov, &nr_segs, pos,
							ppos, count, ocount);
    ... ...
	} else {
		written = generic_file_buffered_write(iocb, iov, nr_segs,
				pos, ppos, count, written);
	}
    ... ...

	do_blockdev_direct_IO 
		-> dio_bio_submit 
			-> submit_bio

struct bio {
	sector_t		bi_sector; //io的起始扇區
... ...
	struct block_device	*bi_bdev;	//對應的塊裝置
... ...
	bio_end_io_t		*bi_end_io;	//io結束的回撥函式
... ...
	struct bio_vec		*bi_io_vec;	//記憶體page列表
... ...
};

struct request_queue {
	... ...
	struct elevator_queue	*elevator;	//排程器
	request_fn_proc		*request_fn;	//請求處理函式
	make_request_fn		*make_request_fn;	//請求入隊函式
	... ...
	softirq_done_fn		*softirq_done_fn;	//軟中斷處理
	struct device		*dev;
	unsigned long		nr_requests;
	... ...
};

void blk_queue_bio(struct request_queue *q, struct bio *bio)
{
    ... ...
	el_ret = elv_merge(q, &req, bio);		//嘗試將bio合併到已有的request中
	... ...
	req = get_request(q, rw_flags, bio, 0);	//無法合併，申請新的request
    ... ...
	init_request_from_bio(req, bio);
}
void blk_flush_plug_list(struct blk_plug *plug, bool from_schedule)
{
    ... ...
			__elv_add_request(q, rq, ELEVATOR_INSERT_SORT_MERGE);	//將request插入request_queue的elevator排程器
    ... ...
}

Linux中提供了不同型別的request_queue，一個是本文主要涉及的single-queue，另外一個是multi-queue。single-queue是在早期的硬體裝置（例如機械硬碟）只能序列處理IO的背景下建立的，而隨著更快速的SSD裝置的普及，single-queue已經無法發揮底層儲存的效能了，進而誕生了multi-queue，它最佳化了很多機制，使IOPS達到了百萬級別以上。至於multi-queue和single-queue的詳細區別，本篇不做討論。

每個佇列都可以配置不同的排程器，常見的有noop、deadline、cfq等。不同的排程器會根據IO型別、程式優先順序、deadline等因素，對request請求進一步進行合併和排序。我們可以透過sysfs進行配置，來滿足業務場景的需求：

在IO經過通用塊層的處理和排程後，就進入到了裝置驅動層，就開始需要和儲存硬體進行互動。

以scsi驅動為例：在scsi的request處理函式scsi_request_fn中，迴圈從request_queue中取request，並建立scsi_cmd下發給註冊到scsi子系統的裝置驅動。需要注意的是，scsi_cmd中會註冊一個scsi_done的回撥函式。

static void scsi_request_fn(struct request_queue *q)
{
	for (;;) {
		... ...
		req = blk_peek_request(q);		//從request_queue中取出request
		... ...
        cmd->scsi_done = scsi_done;		//指定cmd完成後回撥
		rtn = scsi_dispatch_cmd(cmd);	//下發將request對應的scsi_cmd
		... ...
	}
}
int scsi_dispatch_cmd(struct scsi_cmnd *cmd)
{
	... ...
	rtn = host->hostt->queuecommand(host, cmd);
    ... ...
}

struct request_queue *scsi_alloc_queue(struct scsi_device *sdev)
{
    ... ...
	q = __scsi_alloc_queue(sdev->host, scsi_request_fn);
    ... ...
	blk_queue_softirq_done(q, scsi_softirq_done);
	... ...
}

void __blk_complete_request(struct request *req)
{
			... ...
			raise_softirq_irqoff(BLOCK_SOFTIRQ);
			... ...
}

而BLOCK_SOFTIRQ軟中斷的處理函式就是之前註冊的scsi_softirq_done，透過自下而上層層回撥，到達bio_end_io，完成整個IO的生命週期。

	-> scsi_finish_command
    	-> scsi_io_completion
    		-> scsi_end_request
    			-> blk_update_request
    				-> req_bio_endio
    					-> bio_endio