最新消息:

Sheepdog块设备驱动

未分类 admin 3165浏览 0评论

最初刚开始玩Sheepdog(Distributed Storage System for QEMU/KVM)的时候就想着要是能把它作为一个像硬盘一样的块设备,直接挂在终端机器上就好玩了,直到最近工作不是特别忙的时候才有时间想想这事情,花了好几个晚上终于把给Sheepdog写好了一个块设备驱动sheepdev,可以把集群中创建好的VDI直接注册到kernel中,然后使用用户态的相关工具fdisk/mkfs/mount等对这个块设备进行分区格式化挂载等,代码已经提交到upstream,至于还要修改几次,最终能不能merge到upstream中去都还不确定,先简单记录一下自己的工作经历。

块设备驱动作为一个kernel module,在module init的时候我注册了一个proc entry /proc/sheep,通过这个proc entry对这个块设备进行控制,比如:

echo “add 127.0.0.1:7070 a5d05d” > /proc/sheep

可以将VDI Id为a5d05d的VDI作为一个块设备安装到本地,/dev目录下会出现一个/dev/sheepa这样的块设备文件,添加第二个后出现/dev/sheepb,以此类推。

也可以通过下面的方法来删除已经注册上来的块设备:

echo “del sheepa” > /proc/sheep

在安装块设备的时候根据用户提供的VDI Id和sheep地址,首先来向sheep创建一个长连接,并通过该连接向sheep获取该VDI的inode数据,该长连接创建后会一起保持用于driver与sheep的通信,只有获取inode的过程是同步的,后期的读写操作都是异步进行的。

在获取到inode数据之后,inode中包含了这个VDI的size等信息,在创建disk之前这个size信息是唯一需要从sheep获取的,关于sector size这些信息,由于我们是一个虚拟的块设备,都延用了内核通用的块设备大小512字节,sectors数也是通过inode->size/kernel_sector_size计算出来的,创建disk的函数如下:

static int sheep_add_disk(struct sheepdev *dev)
{
	int ret;
	struct request_queue *queue;

	dev->disk = alloc_disk(SHEEP_BLKDEV_MINORS);
	if (!dev->disk) {
		DBPRT("allocate gendisk failuren");
		ret = -EBUSY;
		return ret;
	}
	queue = blk_init_queue(sheep_request, &dev->que_lock);
	/* 4M boundary */
	blk_queue_segment_boundary(queue, 0x3fffff);
	dev->disk->major = sheepdev_major;
	dev->disk->first_minor = dev->minor * SHEEP_BLKDEV_MINORS;
	dev->disk->queue = queue;
	dev->disk->fops = &sheepdev_ops;
	dev->disk->private_data = dev;
	snprintf(dev->disk->disk_name, sizeof(dev->disk->disk_name),
		 SHEEP_BLKDEV_NAME"%c", dev->minor + 'a');

	set_capacity(dev->disk, dev->sectors);
	add_disk(dev->disk);

	return 0;
}

调用set_capacity()之后kernel会调用check_partition()进行分区检查,这时候如果request处理流程还没有完成的话,kernel会hang在set_capacity(),所以在最初编码测试的阶段add_disk()之前我先把capacity设置为0。

在这里调用了blk_queue_segment_boundary()这个函数把请求的boundary设置了4M,sheepdog的文件存储是4M大小的固定块文件,超出4M处理起来就麻烦了。

在add_disk()函数完成之后kernel就开始发request过来了,这时候的request处理函数必须要打通的。

request中包含了经过io scheduler合并过的bio,我们只需要把这些bio连接起来当做一个大的读/写请求发出去便可以了,sheepdev用了一个单一个长连接来处理sheep的读写请求,但创建了两个内核线程sheep_req和sheep_fin。

sheep_request()这个callback函数会将block层发来的请求摘出来放到一个pending_request队列中,每放进一个请求后就会唤醒sheep_req线程,sheep_req这个kernel thread做的事情是从这个队列中把请求取出来,然后根据请求的内容来确定是读还是写,然后把读/写的数据连接合并,不论读写sheep_req都会把请求直接发送出去,而不会同步地等待返回的数据,然后sheepdev会把这个请求再放入一个finish_list队列中,这时候请求附加了一个sheepdog协议中的请求号,每一个请求客户端都会对其进行+1,一般的cs通信协议都会有这样一个请求ID号,用于协议的异步处理,我之前的hybrid聊天客户端也用了这种办法。

sheep_req在向finish_list中放入一个请求后便会去唤醒sheep_fin这个kernel thread,sheep_fin被唤醒后会去读与sheep的长连接中的数据,获取一个请求的response,这个response消息中包含了一个请求ID,sheepdev根据这个ID来从finish_list中找出对应的request,并根据response的结果调用下面的函数结束这个request:

static void sheep_end_request(struct request *req, int ret)
{
	struct request_queue *q = req->q;
	unsigned long flags;

	spin_lock_irqsave(q->queue_lock, flags);
	__blk_end_request_all(req, ret);
	spin_unlock_irqrestore(q->queue_lock, flags);
}

Sheepdog我认为有一点设计不合理的地方就是在创建某个object对象之后,对应的inode数据不会被sheep自动更新,而是需要依靠客户端程序来更新,这样就给客户端的实现带来了一些繁琐,如果修改的话涉及到的代码范围比较广(collie/qemu),我也不打算对它做什么修改了。

由于Sheepdog这个问题,对于SD_OP_CREATE_AND_WRITE_OBJ这样的请求而言,它返回后并不能代表这个block request的结束,必须等待更新inode的请求结束后才可以决定对应的block request是否结束。

关于这个驱动目前核心的就这些东西,没有什么特别复杂的东西,只是一些kernel driver设计的繁琐的东西,原理了解了就很简单了。

FROM:http://basiccoder.com/sheepdog-block-device-driver.html

转载请注明:爱开源 » Sheepdog块设备驱动

您必须 登录 才能发表评论!