众所周知,文件系统中的journal device主要有两个目的:
1.保证数据的一致性;
2.缩短写响应时间
要保证数据的一致性,当然避免不了和磁盘write cache的交互,这体现在两个层次:
1.文件系统中对journal device的写
充分利用journal device的写速度快的特点,写操作先到journal device设备,一次写到journal device的事务包括要写的data和下次取它才需要的最少的meta data。如何确保这些数据彻底落到journal device上,有两种处理方式:
a.完全disable disk write cache,这样保证每次对journal device的写都已经返回;
b.利用disk write cache flush机制,在用作journal device的设备上的每次写在隔一段时间就flash write cache,或者在
2. 文件系统对物理磁盘的写
对于最终落到存储设备上的写,因为有journal device背书,可以异步也可以同步写,但要求保证对于每次写事务:写返回之前肯定能确保数据落到磁盘,而不会在write cache里。考虑到和journal device的配合,一般流程包括两个线程:
2.1落盘线程
a.从journal device读取还未了落盘的写请求记录;
a.执行真正磁盘写;
b.调用对于磁盘设备的flushwrte cache操作;
c.对于已经完全落盘的操作,从journal device中去掉对应的记录
d.返回
至此,一次彻底落盘的写才算完成。
2.2写提交线程
a.打包写请求中的data和metadata (包括offset,起始地址等),生成对journal device写的原始数据
b.从journal device上寻找合适的空间,记录上面的写请求,也就上把上面的原始数据写入;
c.如果journal device的写缓存没有关闭,刷journal device的写缓存,确保数据落到journal device物理存储设备上;
d.向上层返回写请求
至此,一次写请求返回。
根据上面分析,写响应时间是从写请求发出到写提交线程中的步骤d完成的时间。由于通常日志设备比普通磁盘的读写速度快很多,因此它能大大缩短写响应时间。但如果journal device上的写请求由于没有及时下发,被撑满了,那么它就基本上只有执行落盘线程的路径了,可也遇见此时写响应时间会急剧增加很多。
综合考虑到写提交线程和落盘线程的配合,可以看到在有文件系统journal device背书的情况下,落盘线程可以从同步写变成异步写,只要最终保证写请求能够按照先来后到的顺序落盘即可,这样理论上能够增加IO吞吐量。但是实际要达到这一效果,需要journal device和磁盘的紧密协同才行。
3.刷写缓存的操作和关闭写缓存的方法
可以参考下面对SCSI/sas盘的刷写缓存的操作:
static int flushSCSIwc(int fd) {
struct sg_io_hdr io_hdr;
unsigned char sense_b[32];
unsigned char cmdp[10];
memset(&io_hdr, 0, sizeof(struct sg_io_hdr));
memset(sense_b, 0, sizeof(sense_b));
memset(cmdp, 0, sizeof(cmdp));
io_hdr.interface_id = 'S';
io_hdr.dxfer_direction = SG_DXFER_NONE;
cmdp[0] = 0x35;
cmdp[1] = 0x00;
cmdp[2] = 0x00;
cmdp[3] = 0x00;
cmdp[4] = 0x00;
cmdp[5] = 0x00;
cmdp[6] = 0x00;
cmdp[7] = 0x00;
cmdp[8] = 0x00;
cmdp[9] = 0x00;
io_hdr.cmdp = cmdp;
io_hdr.cmd_len = sizeof(cmdp);
io_hdr.sbp = sense_b;
io_hdr.mx_sb_len = sizeof(sense_b);
io_hdr.timeout = 60000;
if(ioctl(fd, SG_IO, &io_hdr) == -1)
if(io_hdr.status != 0)
return EIO;
return 0;
}
而关闭写缓存的办法也很简单:
hdparm -W1 /dev/sdq
当然也可以用MegaCLI或者lsitutil等工具来控制。
转载于:https://blog.51cto.com/xiamachao/1930235