Chinaunix首页 | 论坛 | 博客
  • 博客访问: 801531
  • 博文数量: 31
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 4136
  • 用 户 组: 普通用户
  • 注册时间: 2013-06-21 00:52
个人简介

余自庚寅年麦月误入Linux领域,先从事文件系统与IO之技,后及性能基准之术,上诸述之领域,吾虽有知晓,然未能精通,实为憾事!

文章存档

2016年(8)

2014年(9)

2013年(14)

分类: LINUX

2013-09-08 13:04:51

F2FS文件系统的磁盘布局分析

F2FS 将整个卷切分成大量的 Segments,每个 Segment 的大小是固定的2 MB。连续的若干个Segments 构成 Section,连续的若干个 Sections 构成 Zone。默认情况下一个 Zone 大的大小是一个 Section,而一个 Section 的大小是一个 Segment

F2FS 将整个卷切分成6个区域,除了超级块(SuperblockSB)外,其余每个区域都包含多个 Segments

 

3.1 块(Blocks)、段(Segments)、区段(Sections)、存储区(Zone

3.1.1 Blocks

(1) F2FS文件系统的所有块大小都是4KBF2FS 代码隐式地将块大小链接到系统的页大小,因而F2FS不可能在更大的页的系统上运行,如 IA64 PowerPC

(2) 块地址是32位的,最大文件系统是2^(32+12) Bytes,也就是16TB(完全大于当前的 NAND flash 设备的大小)。

 

3.1.2 Segments

(1) 连续的Blocks集合成Segments,一个Segment的大小是512Blocks(也就是2MB);

(2) 每个Segment都有一个Segment Summary Block元数据结构,描述了Segment 中的每个Block的所有者(该块所属的文件及块在文件内的偏移)。Segment Summary主要用于在执行Cleaning操作时识别哪些Blocks中的数据需要转移到新的位置,以及在转移之后如何更新Blocks的索引信息。一个Block就可以完全存储512Blockssummary信息,每个blocks都有一个1 bit的额外空间用于其它目的。

(3) 2MB是最合适的Segment大小,太大不合适,太小又会造成存储summary信息的Block空间浪费;

 

3.1.3 Sections

(1) 连续的Segments集合成SectionSection中具有的segments个数是任意的,但是要满足是2的幂;默认情况下,一个Section大小等同于一个Segment2^0 Segments);

(2) 一个Section对应log structuring的一个区域“region”,log在使用下一个Section之前,通常要从头到尾将当前的Section填满数据;

(3) 清理器Cleaner一次处理一个Section

(4) F2FS中,任意时刻都有6个“打开的”Sections用于将各种不同种类的数据(元数据、数据)分别写入到各个Sections中,实现数据分离。这样便允许文件内容(数据)与其索引信息(节点,node)分离,允许F2FS文件系统根据各种启发式方法将Sections划分成三类:即“hot”、“warm”、“cold”。例如,目录数据被当做hot来对待,使其与文件数据分离,存放到“hotSection中。Cold数据是指那些很长时间内都不会改变的数据,因而装满Cold数据的Section就不需要执行Clean操作。对于hot节点(索引信息节点),一般更新很快,一段时间之后,装满 hot 节点的Section中的有效数据(alive data)就会很少,因而选择这样的Section进行Clean操作开销就很小(因为要转移的数据很少)。


 

3.1.4 Zone

(1) 连续的Sections集合成Zone。一个Zone可以包含任意整数个Sections。默认是一个Zone中包含一个Section

(2) 设置Zone的唯一目的是尽可能将6个打开的Sections位于Flash设备的不同的子设备中。理论上,Flash设备通常是由一组相互完全独立的子设备构成,每个子设备都可单独地处理I/O请求,不同子设备可并行处理I/O请求;如果Zone的大小与子设备大小对齐,6个打开的Sections可并行写入,充分利用设备的特性;

(3) Zone构成了F2FS的“主要(main)”区域。

3.1.5 Meta  Area

F2FS有一个“meta”区域,包含了各种不同的元数据(如之前提到的segment summary),这一部分不是采用标准的log-structured流水线方式管理,因而更多的工作留给了FTL去做。有三种方法管理对“meta”区域的写操作:

a) 第一,有少量的只读数据(超级块)从来都不是不是在文件系统创建的时候立即写入;

b) 第二,对Segment Summary Block 简单采取本地更新的方法。这种本地更新可能导致文件系统奔溃后数据块“修正”内容的不确定性,但对segment summary来说这都不是问题,segment summary blocks中的数据在使用前要进行有效性验证,如果有任何信息丢失的可能,它都将会在恢复进程中从其他source中恢复。

c) 第三种方法,分配需求空间两倍大小的空间,使得每个block都有两个不同的位置:一个Primary,一个Secondary,任意时刻,两个位置的block仅有一个是live状态。因而LFSCopy-On-Write需求就可以通过向non-live位置的block写入更新后的block内容并且更新记录哪个位置的blocklive状态的方式简单实现。对于元数据来说,这种技术是实现快照功能的主要实现方法。当创建一个Checkpoint的时候,F2FS执行少量的Journaling更新到最后的组(last group),这在一定程度上减轻了FTL的工作。

阅读(16346) | 评论(2) | 转发(10) |
给主人留下些什么吧!~~

登高望远海2013-09-17 23:15:42

linkOops:关于section, 我自己不是很清楚该逻辑结构的意义, 但是进行日志写的单位应该是segment吧, 代码中都是通过CURSEG_I(sbi, type)来获取相应类型的segment进行写或者recover.

谢谢你的留言!
    看来你对F2FS的研究比我深入,佩服!我这边主要是从架构上去分析的,没有去详细读代码,文件系统的东西现在是我的兴趣,但却不是我的工作,加上我们工作加班严重,所以想深入研究也有一些客观困难。
    你提的这个问题,实际上是对的。F2FS同时维护6个日志,每个日志的存储单位是Sections,但是默认的情况下Section大小与segment大小是相同的2MB,所以你看到的代码就是以segment为单位进行日志处理的。逻辑结构Section的想法要结合SSD或Flash设备的特性来看,以Section为单位主要是考虑到一种"对齐机制",因为SSD的不同的Die是可以并行读写的,因而只要保证6个日志要写入的数据在6个不同的Die上,那么6个log就可以并行写入了,提升了处理速度。如果不是按这种“对齐”处理的话,就会出log之间的阻塞等待,增加了处理延时。
    SSD的Die是不是最小的并行写入单元,我这边不是太确定了,很早之前看过的东西,不是它就是另外一个叫做Plane的单元。

回复 | 举报

linkOops2013-09-17 15:41:47

关于section, 我自己不是很清楚该逻辑结构的意义, 但是进行日志写的单位应该是segment吧, 代码中都是通过CURSEG_I(sbi, type)来获取相应类型的segment进行写或者recover.