Linux文件系统预读(一)

最新推荐文章于 2024-04-23 16:06:28 发布
转载 最新推荐文章于 2024-04-23 16:06:28 发布 · 2.2k 阅读 · 2

本文详细解析了Linux内核3.12版本中的文件系统预读机制，通过具体示例介绍了预读的设计原理和实现过程，包括同步预读与异步预读的工作流程。

        本博客主要阐述最新内核(Linux-3.12)的文件系统预读及时的设计和实现，可能有理解不全面的地方，望各位能多多指教。

        所谓预读，是指文件系统为应用程序一次读出比预期更多的文件内容并缓存在page cache中，这样下一次读请求到来时部分页面直接从page cache读取即可。当然，这个细节对应用程序透明，应用程序可能的感觉唯一就是下次读的速度会更快，当然这是好事。

        由于应用程序的访问行为存在多样性加上作者对预读的把握不是非常深入，因此，难免存在不是非常精确的地方，望多赐教。我们会通过设置几个情境来分析预读的逻辑。

情境1

// 事例代码

[cpp] view plain copy
print ? 在CODE上查看代码片 派生到我的代码片
  1. {  
  2.         ...  
  3.         f   = open("file", ....);  
  4.         ret = read(f, buf, 4096);  
  5.         ret = read(f, buf, 2 * 4096);  
  6.         ret = read(f, buf, 4 * 4096);  
  7.         ...  
  8. }  
{
        ...
        f   = open("file", ....);
        ret = read(f, buf, 4096);
        ret = read(f, buf, 2 * 4096);
        ret = read(f, buf, 4 * 4096);
        ...
}

        该场景非常简单：打开文件，共进行三次读（且是顺序读），那让我们看看操作系统是如何对文件进行预读的。

Read 1

        第一次进入内核读处理流程时，在page cache中查找该offset对应的页面是否缓存，因为首次读，缓存未命中，触发一次同步预读：

[cpp] view plain copy
print ? 在CODE上查看代码片 派生到我的代码片
  1. static void do_generic_file_read(struct file *filp, loff_t *ppos,read_descriptor_t *desc, read_actor_t actor)  
  2. {  
  3.     ......  
  4.     for (;;) {  
  5.         ......  
  6.         cond_resched();  
  7. find_page:  
  8.         // 如果没有找到，启动同步预读  
  9.         page = find_get_page(mapping, index);  
  10.         if (!page) {  
  11.             page_cache_sync_readahead(mapping,ra, filp,index, last_index - index);  
static void do_generic_file_read(struct file *filp, loff_t *ppos,read_descriptor_t *desc, read_actor_t actor)
{
	......
	for (;;) {
		......
		cond_resched();
find_page:
		// 如果没有找到，启动同步预读
		page = find_get_page(mapping, index);
		if (!page) {
			page_cache_sync_readahead(mapping,ra, filp,index, last_index - index);

该同步预读逻辑最终进入如下预读逻辑：

[cpp] view plain copy
print ? 在CODE上查看代码片 派生到我的代码片
  1. // 注意: 这里的offset 和req_size其实是页面数量  
  2. static unsigned long ondemand_readahead(struct address_space *mapping,  
  3.            struct file_ra_state *ra, struct file *filp,  
  4.            bool hit_readahead_marker, pgoff_t offset,  
  5.            unsigned long req_size)  
  6. {  
  7.     unsigned long max = max_sane_readahead(ra->ra_pages);  
  8.     // 第一次读文件，直接初始化预读窗口即可  
  9.     if (!offset)  
  10.         goto initial_readahead;  
  11.         ......  
  12. initial_readahead:  
  13.     ra->start = offset;  
  14.     ra->size = get_init_ra_size(req_size, max);  
  15.     // ra->size 一定是>= req_size的，这个由get_init_ra_size保证  
  16.     // 如果req_size >= max,那么ra->async_size = ra_size  
  17.     ra->async_size = ra->size > req_size ? ra->size - req_size : ra->size;  
  18.   
  19. readit:  
  20.     /* 
  21.      * Will this read hit the readahead marker made by itself? 
  22.      * If so, trigger the readahead marker hit now, and merge 
  23.      * the resulted next readahead window into the current one. 
  24.      */  
  25.     if (offset == ra->start && ra->size == ra->async_size) {  
  26.         ra->async_size = get_next_ra_size(ra, max);  
  27.         ra->size += ra->async_size;  
  28.     }  
  29.   
  30.     return ra_submit(ra, mapping, filp);  
  31. }  
// 注意: 这里的offset 和req_size其实是页面数量
static unsigned long ondemand_readahead(struct address_space *mapping,
		   struct file_ra_state *ra, struct file *filp,
		   bool hit_readahead_marker, pgoff_t offset,
		   unsigned long req_size)
{
	unsigned long max = max_sane_readahead(ra->ra_pages);
	// 第一次读文件，直接初始化预读窗口即可
	if (!offset)
		goto initial_readahead;
        ......
initial_readahead:
	ra->start = offset;
	ra->size = get_init_ra_size(req_size, max);
	// ra->size 一定是>= req_size的，这个由get_init_ra_size保证
	// 如果req_size >= max,那么ra->async_size = ra_size
	ra->async_size = ra->size > req_size ? ra->size - req_size : ra->size;

readit:
	/*
	 * Will this read hit the readahead marker made by itself?
	 * If so, trigger the readahead marker hit now, and merge
	 * the resulted next readahead window into the current one.
	 */
	if (offset == ra->start && ra->size == ra->async_size) {
		ra->async_size = get_next_ra_size(ra, max);
		ra->size += ra->async_size;
	}

	return ra_submit(ra, mapping, filp);
}

        读逻辑会为该文件初始化一个预读窗口：(ra->start, ra->size, ra->async_size)，本例中的预读窗口为(0,4,3)，初始化该预读窗口后调用ra_submit提交本次读请求。形成的读窗口如下图所示：


        图中看到，应用程序申请访问PAGE 0，内核一共读出PAGE0 ~PAGE3，后三个属于预读页面，而且PAGE_1被标记为PAGE_READAHEAD，当触发到该页面读时，操作系统会进行一次异步预读，这在后面我们会仔细描述。

        等这四个页面被读出时，第一次读的页面已经在pagecache中，应用程序从该page中拷贝出内容即可。

Read 2

        接下来应用程序进行第二次读，offset=4096， size=8192。内核将其转化为以page为单位计量，offset=1，size=2。即读上面的PAGE1和PAGE2。

        感谢第一次的预读，PAGE1和PAGE2目前已经在内存中了，但由于PAGE1被打上了PAGE_AHEAD标记，读到该页面时会触发一次异步预读：

[cpp] view plain copy
print ? 在CODE上查看代码片 派生到我的代码片
  1. find_page:  
  2.         ......  
  3.         page = find_get_page(mapping, index);  
  4.         if (!page) {  
  5.             page_cache_sync_readahead(mapping,  
  6.                     ra, filp,  
  7.                     index, last_index - index);  
  8.             page = find_get_page(mapping, index);  
  9.             if (unlikely(page == NULL))  
  10.                 goto no_cached_page;  
  11.         }  
  12.         if (PageReadahead(page)) {  
  13.             page_cache_async_readahead(mapping,ra, filp, page,index, last_index - index);  
  14.         }  
find_page:
		......
		page = find_get_page(mapping, index);
		if (!page) {
			page_cache_sync_readahead(mapping,
					ra, filp,
					index, last_index - index);
			page = find_get_page(mapping, index);
			if (unlikely(page == NULL))
				goto no_cached_page;
		}
		if (PageReadahead(page)) {
			page_cache_async_readahead(mapping,ra, filp, page,index, last_index - index);
		}

[cpp] view plain copy
print ? 在CODE上查看代码片 派生到我的代码片
  1. static unsigned long  
  2. ondemand_readahead(struct address_space *mapping,  
  3.            struct file_ra_state *ra, struct file *filp,  
  4.            bool hit_readahead_marker, pgoff_t offset,  
  5.            unsigned long req_size)  
  6. {  
  7.     unsigned long max = max_sane_readahead(ra->ra_pages);  
  8.   
  9.     ........  
  10.       /* 如果: 
  11.        * 1. 顺序读(本次读偏移为上次读偏移 (ra->start) + 读大小(ra->size,包含预读量) -  
  12.        *    上次预读大小(ra->async_size)) 
  13.        * 2. offset == (ra->start + ra->size)??? 
  14.        */  
  15.     if ((offset == (ra->start + ra->size - ra->async_size) || offset == (ra->start + ra->size))) {  
  16.           // 设置本次读的offset,以page为单位  
  17.         ra->start += ra->size;   
  18.         ra->size = get_next_ra_size(ra, max);  
  19.         ra->async_size = ra->size;  
  20.         goto readit;  
  21.     }  
static unsigned long
ondemand_readahead(struct address_space *mapping,
		   struct file_ra_state *ra, struct file *filp,
		   bool hit_readahead_marker, pgoff_t offset,
		   unsigned long req_size)
{
	unsigned long max = max_sane_readahead(ra->ra_pages);

	........
      /* 如果:
       * 1. 顺序读(本次读偏移为上次读偏移 (ra->start) + 读大小(ra->size,包含预读量) - 
       *    上次预读大小(ra->async_size))
       * 2. offset == (ra->start + ra->size)???
       */
	if ((offset == (ra->start + ra->size - ra->async_size) || offset == (ra->start + ra->size))) {
	      // 设置本次读的offset,以page为单位
		ra->start += ra->size; 
		ra->size = get_next_ra_size(ra, max);
		ra->async_size = ra->size;
		goto readit;
	}

        经历了第一次预读，文件的预读窗口状态为(ra->start,ra->size, ra->async_size)=(0, 4, 3)，本次的请求为(offset,size)=(1, 2)，上面代码的判断条件成立，因此我们会向前推进预读窗口，此时预读窗口变为(ra->start,ra->size, ra->async_size) = (4, 8, 8)

        由于本次是异步预读，应用程序可以不等预读完成即可返回，只要后台慢慢读页面即可。本次预读窗口的起始以及大小以及预读大小可根据前一次的预读窗口计算得到，又由于本次是异步预读，因此，预读大小就是本次读的页面数量，因此将本次预读的第一个页面(PAGE 4)添加预读标记。


        由于上面的两次顺序读，截至目前，该文件在操作系统中的page cache状态如下：


Read 3

        接下来应用程序进行第三次读，顺序读，范围是[page3, page6]，上面的预读其实已经将这些页面读入page cache了，但是由于page4被打上了PAGE_READAHEAD标记，因此，访问到该页面时会触发一次异步预读，预读的过程与上面的步骤一致，当前预读窗口为(4,8,8)，满足顺序性访问特征，根据特定算法计算本次预读大小，更新预读窗口为(12,16,16)，新的预读窗口如下：


        对该情境简单总结下，由于三次的顺序读加上内核的预读行为，文件的page cache中的状态当前如下图所示:


Linux文件系统预读(三)
kai_ding的专栏
02-28 2079
前面两篇关于文件系统的预读我们通过实例阐述了应用程序的顺序读而触发操作系统对文件大小预取情况，本篇博客我们主要描述预读如何解决交织读的问题。所谓的交织读指的是多线程（进程）读同一个打开的文件描述符，单个线程的顺序读在操作系统看来可能会变成随机读。同样我们还是结合实例来分析。 事例代码 { ...... f = open("file", ......)
3、预读机制与预读失效
最新发布
bamboo_tt的博客
10-21 323
预读机制（Readahead）是操作系统或数据库的一种性能优化策略：当程序读取某个文件块时，系统会预先把后续相邻的数据块也加载到内存中以减少将来可能发生的磁盘 I/O。📖例子（Linux Page Cache）磁盘最小读取单位是 4KB block；操作系统不仅读 [0,4KB)，还会额外读 [4KB,8KB)、[8KB,12KB)、[12KB,16KB)；这样下一次若访问 8KB 数据时，就可以直接命中缓存。📈减少磁盘 I/O 次数，提高吞吐量。
Linux Kernel I_O预读算法及性能.pdf
10-23
Linux Kernel I_O预读算法及性能.pdf
Linux内核的文件预读
guogaofeng1219的专栏
03-25 1075
from: http://os.51cto.com/art/200711/60574.htm编者按：Linux文件预读算法磁盘I/O性能的发展远远滞后于CPU和内存，因而成为现代计算机系统的一个主要瓶颈。预读可以有效的减少磁盘的寻道次数和应用程序的I/O等待时间，是改进磁盘读I/O性能的重要优化手段之一。本文作者是中国科学技术大学自动化系的博士生，他在1998年开始学习Linux，为了优化服务器的
linux 预读机制 （linux4.14）
geshifei的博客
10-12 1768
文件一般是顺序访问的，访问[A, B]范围的数据后，接下来很可能访问[B+1, B+N]数据。由于访问磁盘、flash等存储器件比较耗时，在访问 [A, B]的时候，如果提前把[B+1, B+N]数据从存储器件读取到ram中，那么后继需要用[B+1, B+N]数据时，就不需要耗时的disk io从存储器件读取数据了，从而提高性能。
浅析Linux文件系统管理.pdf
09-06
本文主要探讨了在Red Hat 9.0环境下Linux文件系统的管理，包括磁盘管理的各个方面。 1. Linux 文件系统类型 Linux 支持多种文件系统，如ext2、ext3和ext4，其中Red Hat 9.0默认使用ext3文件系统。ext3是一种日志...
Linux内核的文件预读.pdf
09-06
1. 预读准备：在 read() 系统调用中，内核会预读一个较大的数据块，通常是 128KB。 2. 数据传输：当应用程序需要读取数据时，内核会从预读的数据块中提供数据。 3. 缓存维护：内核会维持一个缓存来存储预读的数据，...
文件系统预读机制的代码分析
chensong_2000的博客
04-23 1109
（14）或者，还有一个分支，还可以进入函数blk_mq_delay_run_hw_queues，启动kblockd_workqueue，回调函数是blk_mq_run_work_fn，这个读取是在kworker的上下文中，是一个异步的IO过程，代码路径在本文后面介绍。（10）调用blk_mq_attempt_bio_merge合并bio，同时调用blk_mq_bio_to_request将bio转换为request，调用blk_add_rq_to_plug将request添加到tsk->plug中。
文件的预读
qq_41104683的博客
06-12 458
为了优化读取文件的时间延迟，文件系统(FS)在去磁盘读取文件时会有一个read_ahead的动作。主要思路是：当FS发现用户读取文件是按照文件的顺序读取，FS就假定用户在下一次读取时大概率会读取下一个block。所以FS在把当前的block读取到内存后，会发送读取下一个block的命令，然后将当前block数据返回给用户。这样用户在处理数据的时候，磁盘IO也在并行的执行(如果是DMA的方式，磁盘IO在完成之后，会通过中断的方式告诉FS)
Linux 文件预读
赶路人儿
10-08 686
Linux文件预读算法磁盘I/O性能的发展远远滞后于CPU和内存，因而成为现代计算机系统的一个主要瓶颈。预读可以有效的减少磁盘的寻道次数和应用程序的I/O等待时间，是改进磁盘读I/O性能的重要优化手段之一。本文作者是中国科学技术大学自动化系的博士生，他在1998年开始学习Linux，为了优化服务器的性能，他开始尝试改进Linux kernel，并最终重写了内核的文件预读部分，这些改进被收录到Linux Kernel 2.6.23及其后续版本中。 从寄存器、L1/L2高速缓存、内存、闪存，到磁盘/光盘/磁带
ZFS文件系统的预读策略
06-28
ZFS预读算法,对缓存预读策略感兴趣的可以参考。可以对应内核代码进行阅读理解。
Linux 读文件 - readahead预读算法
GetnextWindow的专栏
07-02 1448
根据ondemand_readahead中initial_readahead label处逻辑看，ra->size是由get_init_ra_size函数计算，该函数第一个参数是应用read的数据页（每个数据页4K)的数量，该场景每次读取4K bytes,相当于调用get_init_ra_size（1，32）返回4。这里async readahead就是指generic_file_buffered_read函数中的：page_cache_async_readahead函数调用。: 开始预读的数据页索引，
Linux内核的文件预读详细详解
日积月累终会滴水穿石
04-06 617
Linux文件预读算法磁盘I/O性能的发展远远滞后于CPU和内存，因而成为现代计算机系统的一个主要瓶颈。预读可以有效的减少磁盘的寻道次数和应用程序的I/O等待时间，是改进磁盘读I/O性能的重要优化手段之一。本文作者是中国科学技术大学自动化系的博士生，他在1998年开始学习Linux，为了优化服务器的性能，他开始尝试改进Linux kernel，并最终重写了内核的文件预读部分，这些改进被收录到Lin...
Linux文件系统预读的情景分析
Linux阅码场
04-06 1332
本文系转发，分析Linux文件系统同步和异步的预读机制，有图有真相，比较形象。预读可以提高CPU和硬盘工作的并行度，减小APP延迟。主要阐述内核(linux-3.12)的文件系统预读及时的设计和实现，可能有理解不全面的地方，望各位能多多指教。        所谓预读，是指文件系统为应用程序一次读出比预期更多的文件内容并缓存在page cache中，这样下一次读请求到来时部分页面直接从page ca
Linux readahead文件预读
谨以此记录下自己的每一点、每一滴、每一步,以督促自己，不忘目标，不忘理想。
03-31 1459
​ Linux read/mmap 时将文件从磁盘读区到内存当中，read读取文件操作必然会带来IO如果能直接从内存当中读取文件这样就能有效的解决IO及延迟问题。page cache的诞生就是解决这个问题，文件读取后将文件对应的物理page 添加到redix tree当中管理后续在做同样的读取操作时就直接从page cache当中直接读取文件。这个机制本质上来讲与硬件架构的cache原理上是想通的，理解cache机制有助于理解page cache。
文件系统的预读
ljyss9的博客
10-04 433
最近在做迁移工作，从hdfs迁移到我司的分布式文件系统，但是我也是非常无语，我司文件系统竟然没有做预读。。对于大量顺序读的场景，这个是非常吃亏的。对于跨机房场景，原Hdfs可达到100M+/s的读速度，但是现在却仅有几十M/s。对于这个问题，等待底层文件系统添加预读确实是最根本的解决方法，但是面对发布时间周期长，排期封板等问题，我们就打算在自己的插件上先简单实现预读功能。 ...
Linux内核的文件预读机制详解
私房菜
08-26 1391
为什么需要文件预读机制？ 算法磁盘I/O性能的发展远远滞后于CPU和内存，因而成为现代计算机系统的一个主要瓶颈。预读可以有效的减少磁盘的寻道次数和应用程序的I/O等待时间，是改进磁盘读I/O性能的重要优化手段之一。 从寄存器、L1/L2高速缓存、内存、闪存，到磁盘/光盘/磁带/存储网络，计算机的各级存储器硬件组成了一个金字塔结构。越是底层存储容量越大。然而访问速度也越慢，具体表现为更小的带宽和更大的延迟。因而这很自然的便成为一个金字塔形的逐层缓存结构。由此产生了三类基本的缓存管理和优化问题： 预取
一个关于linux文件预读机制问题
weixin_33670786的博客
04-03 437
一个关于linux文件预读机制问题 曾经，有人问我这样一个问题： 一个Native 程序 mmap 了一个文件，如果什么都不读 RSS是0，但是读一个字节，RSS就变成64k，这个在哪儿能控制大小？mmap不同大小，这个读一个字节的申请的物理也不同，貌似跟文件大小有关系，不过这个应该可以配置吧？ 其实： 我的回答如下：读取文件，还与预读机制有关系，在读取文件时，预读机制会多读一些。物理内存以页为单...
深入理解Linux文件系统模拟技术
模拟Linux文件系统可以有不同的目的，例如在教学和学习中提供一个可控的环境来展示和测试Linux的文件系统操作；在软件开发中模拟特定的文件系统行为，以便于进行测试和调试；或者在数据恢复工作中模拟受损的文件系统...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值