在HLFS实现应用层面的预读

5 views
Skip to first unread message

张胜利

unread,
May 8, 2013, 9:30:34 AM5/8/13
to clo...@googlegroups.com
对于单机而言,IO严重阻碍了整体性能的提高,一方面在于读取大量小数据的文件,时间浪费在磁盘寻道上,另一方面磁盘IO的速度也提升相对较慢,现在的主流磁盘依然是7200转。
操作系统针对这两点分别实现了预读算法和读操作排队策略,每次读取的文件越大则磁盘的效率就越高,读操作排队减少了IO的空闲时间。
在大规模数据存储中,程序读取的文件顺序往往有一定的规律性,比如学校学生数据测存放,文件之间关联性很强,通过长时间跟踪程序读取文件的顺序,可得出程序读取一个文件之后,接着要读取的是哪一个文件。
综合以上说明,设想在HLFS的文件管理中建立文件之间的关联,这个关联用来描述程序读取文件的顺序。然后在读操作中实现双重读取,即在读取一个文件的时候,同时根据文件的顺序关联异步读取(后台实现)此文件之后的文件的开始部分,这样在程序需要读取的下一个文件的时候,便可先检查预读的文件是否所需文件。
如此一来,根据文件关联的命中率可提高预读效率,此策略的优势在于它实现在应用层面,对已有的预读策略不造成任何影响,同时此策略能提高IO的读操作排队,对于分布式存储的读操作提高应该很有帮助。
大家讨论下这个想法是否可行。

harryxiyou

unread,
May 8, 2013, 8:54:38 PM5/8/13
to clo...@googlegroups.com
2013/5/8 张胜利 <zhangsh...@gmail.com>:
> 对于单机而言,IO严重阻碍了整体性能的提高,一方面在于读取大量
>小数据的文件,时间浪费在磁盘寻道上,另一方面磁盘IO的速度也提
>升相对较慢,现在的主流磁盘依然是7200转。操作系统针对这两点分
>别实现了预读算法和读操作排队策略,每次读取的文件越大则磁盘的
>效率就越高,读操作排队减少了IO的空闲时间。 在大规模数据存储中,
>程序读取的文件顺序往往有一定的规律性,比如学校学生数据测存放,
>文件之间关联性很强,通过长时间跟踪程序读取文件的顺序,可得出
>程序读取一个文件之后,接着要读取的是哪一个文件。综合以上说明,
>设想在HLFS的文件管理中建立文件之间的关联,这个关联用来描述程
>序读取文件的顺序。然后在读操作中实现双重读取,即在读取一个文件
>的时候,同时根据文件的顺序关联异步读取(后台实现)>此文件之后的
>文件的开始部分,这样在程序需要读取的下一个文件的时候,便可先检
>查预读的文件是否所需文件。如此一来,根据文件关联的命中率可提高
>预读效率,此策略的优势在于它实现在应用层面,对已有的预读策略不
>造成任何影响,同时此策略能提高IO的读操作排队,对于分布式存储的
>读操作提高应该很有帮助。大家讨论下这个想法是否可行。
>

我认为可行,但是这个预读应该是对段文件的预读,因为目前HLFS只有一个
文件,所以预读方案应该针对段文件。那么给出以下step-by-step方案:

0, 给出具体预读设计方案。
1, 然后讨论设计方案是否可行,不可行则修正,可行则继续下面步骤。
2, 根据设计方案编写代码实现。
3, 测试工作,如单元测试(伴随开发过程),功能测试等。
4, 首先测出7200+转disk I/O效率,然后测出不加预读的效率,再测试
加预读的效率,两者对比,查看是否真正达到预读的效果,以便继续修正。


--
Thanks
Harry Wei

张胜利

unread,
May 9, 2013, 9:58:43 AM5/9/13
to clo...@googlegroups.com
就以已完成的多文件扩展为基础,在我的想法中需要用到多文件管理的结构。在dentry结构体中加入双向链表,分别指向前一个文件以及后一个可能文件的二维数组,这个文件列表结构体如下{  file 1,adds;
                                                                                                 file2,adds;
                                                                                                 。。。。。
                                                                                                 }
这个数组用来对应存放文件名和可能将被读取的几率。每次读取都会比较文件可能被预读的几率,数组中的文件名动态变化。
 
申请一定大小的内存,专门存放每次预读的文件,在每次读取文件之前首先检查申请的内存中预读的文件是否是所需文件,是则拷贝过去,不是则从磁盘读取,同时预读下一个文件,覆盖申请的预读专用内存。
 
关于预读的操作,一种方式是在读取当前文件时,异步预读下一个文件,这种方法可利用空闲资源。
                             另一种方式是将预读的文件放在当前文件之后,使其在逻辑上衔接,这种方法可充分利用系统预读算法,但是
                            在命中率不足时会影响效率。



--
您收到此邮件是因为您订阅了 Google 网上论坛的“cloudxy”论坛。
要退订此论坛并停止接收此论坛的电子邮件,请发送电子邮件到 cloudxy+u...@googlegroups.com
要查看更多选项,请访问 https://groups.google.com/groups/opt_out



harryxiyou

unread,
May 9, 2013, 9:27:24 PM5/9/13
to clo...@googlegroups.com
2013/5/9 张胜利 <zhangsh...@gmail.com>:
--
Thanks
Harry Wei

harryxiyou

unread,
May 9, 2013, 9:28:08 PM5/9/13
to clo...@googlegroups.com
2013/5/9 张胜利 <zhangsh...@gmail.com>:
> 就以已完成的多文件扩展为基础,在我的想法中需要用到多文件管理的结构。

也行。


--
Thanks
Harry Wei
Reply all
Reply to author
Forward
0 new messages