一个IO传奇的一生-4

块设备buffer cache机制

 

在EXT3文件IO踏上新的征程之前，需要介绍一位EXT3文件IO的同伴，他们即将踏上相同的旅程。只不过这位同伴没有经历过EXT3文件系统的精彩，却领略了另外一番略有差别的风情。这位同伴是在块设备写操作时创建诞生的，我们可以称它为块设备IO。

在很多�22>.writepages = generic_writepages,

.releasepage    = blkdev_releasepage,

.direct_IO  = blkdev_direct_IO,

};

对于EXT3文件而言，write_begin会进行日志操作，块设备文件系统没有这种操作，只会进行一些page页初始化方面的工作。对于write_end函数，EXT3文件系统会清除日志，并且需要通知writeback守护线程去回写数据。对于块设备文件系统而言，write_end函数的主要工作就是将page页标识成脏，然后通知回写线程去处理这个块设备中的脏页。实现设置脏页的函数说明如下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

static int __block_commit_write(struct inode *inode, struct page *page, unsigned from, unsigned to) { unsigned block_start, block_end; int partial = 0 ; unsigned blocksize; struct buffer_head *bh, *head; blocksize = 1 << inode->i_blkbits; for (bh = head = page_buffers(page), block_start = 0 ; bh != head || !block_start; block_start=block_end, bh = bh->b_this_page) { block_end = block_start + blocksize; if (block_end <= from || block_start >= to) { if (!buffer_uptodate(bh)) partial = 1 ; } else { set_buffer_uptodate(bh); /*将page页和inode设置成脏，等待回写调度处理*/ mark_buffer_dirty(bh); } clear_buffer_new(bh); } /* * If this is a partial write which happened to make all buffers * uptodate then we can optimize away a bogus readpage() for * the next read(). Here we 'discover' whether the page went * uptodate as a result of this (potentially partial) write. */ if (!partial) SetPageUptodate(page); return 0 ; }

从整个分析来看，裸块设备的写操作中Cache的机制、原理和EXT3并没有什么本质上的区别。大家都采用了radix tree管理的page cache。如果不采用Direct_IO的方式，那么都会首先将数据写入page cache，然后再通过writeback机制将数据回写到磁盘。整个机制是完全相同的。所不同的是，EXT3和块设备的缓存块大小是不相同的。对于EXT3而言，缓存块大小就是page size，对于块设备而言，缓存块大小会采用一定的策略得到。具体关于buffer cache的缓存块大小参考《Linux中Buffer cache性能问题一探究竟》。

虽然块设备和EXT3文件看上去差别很大，但是，由于系统所要解决的问题基本类似，因此，在IO处理的机制上是类似的。好！言归正传，到目前为止，EXT3文件IO以及块设备IO都已经准备完毕，writeback回写机制已经已经将这些IO统统回写到底层设备中。这些IO都将离开短暂的page cache，一同踏上块设备层，即将面临块设备层即公平又难以公平的调度处理过程。

 

本文出自 “存储之道” 博客，转载请与作者联系！