f2fs源码分析之文件读写过程

本篇包括三个部分:1)f2fs 文件表示方法; 2)NAT详细介绍;3)f2fs文件读写过程;4)

下面详细阐述f2fs读写的过程。

管理数据位置关键的数据结构是node,node包括三种:inode、直接node、间接node。其中inode记录了文件的基本信息,包括访问权限、文件大小、修改时间等,也有索引的功能;直接node和间接node单纯负责索引。F2fs的inode中有923个直接数据块索引,2个一级索引,2个二级索引,1个三级索引,文件的逻辑表示如下图:

inode中有923个索引项,直接node、间接node中都是有1018个索引项。

通过上图,inode中923个直接数据块索引能够索引到××K的数据,

2个一级索引能够索引到

2个二级索引能够索引到

1个三级索引能够索引到

因此,f2fs支持单文件最大3.94T,

上面介绍了f2fs三种node之间是如何配合索引文件的,但是有一个非常重要的细节:间接node的索引项记录nid号(与NAT相关),直接node的索引项中直接记录数据块地址。拿图(一)中的三级索引部分为例:

其中node block 1) 2)属于间接node,索引项中为nid号,3)和4)属于直接node,索引项中为数据块的地址。这种设计是为了解决Log-structured 文件系统中雪崩树问题,其中nid号是NAT表的下标。

f2fs文件系统中,NAT表是和文件存储强相关的一个数据结构,非常重要。因此,这篇文章的第二部分,我们就详细说说NAT表,包括它的作用以及f2fs是如何管理NAT表的。

NAT表位于元数据区,可以认为是一个大数组,数据下标是nid,每一个表项记录着一个node块的信息,包括该node块属于哪一个inode,以及该node块在磁盘上的地址。

还是以图(一)中的三级索引部分为例,我们发现,整个索引过程的真相应该是这样的:

这和图一相比已经面目全非了,图一更宏观,本图粒度更细。

到这里我们基本上可以明白f2fs为什么可以削弱雪崩树的影响了:当图中数据块因为数据变脏导致异地更新时,它的直接索引2)也会变脏,但是由于2)是一个直接索引,是node块,信息是在NAT中管理,所以只需要在NAT中update下2)的新地址就好了!这样3)中对应的索引项根本就不用变,因为3)的索引项指向的东西在NAT里呢!

这一机制有效杜绝了雪球越滚越大!但是,这种类似于”二级指针“的方法,会带来一定程度的性能开销,所以f2fs的NAT信息在内存中以链表+基数树的方式维护,以加快查找、update过程。

好了,到这里NAT的作用基本清楚了,后面读写文件的过程还会涉及nat的操作。下面介绍下NAT的存储方式:

元数据区中有两份NAT,两份NAT在元数据区中以segment的粒度交叉存放(假设每个NAT表有3个segment):

之所以准备两份NAT,是因为f2fs中有两份snapshot,NAT是和文件存储强相关的元数据,因此两份。但是两份snapshort和两份NAT之间并不是一一对应关系,如上图,并不是说第一份快照对应的NAT数据就完全存储在图中NAT0(或者NAT1)中。它是通过一个bitmap,完成NAT在block粒度上的映射:

好了,把NAT介绍完毕后,我们对f2fs文件的索引有了新的认识,下面介绍文件的读写过程:

1)首先在VFS层,

上面介绍了f2fs文件的逻辑表示,下面看f2fs源码中是如何

时间: 2024-12-22 04:56:28

f2fs源码分析之文件读写过程的相关文章

f2fs源码分析(一)mount 过程

许多文章会介绍F2FS,对于入门者来说能够了解个F2FS全貌,但是真正了解这个年轻的文件系统还是要看源码的.网上F2fs源码导读的文章,我到现在还是没看过,所以就用这几篇博客来介绍下f2fs,以期对f2fs有更加深入的认识,甚至对整个IO路径的认知有所启发. 下面 文件系统的包括文件系统在磁盘上的布局,也包括在驻留在内存中的文件系统的“驱动” mount过程主要是新建段管理器(segment manager),节点管理器(node manager).其中,段管理器是为了垃圾回收,因为垃圾回收算法

netty 5 alph1源码分析(服务端创建过程)

参照<Netty系列之Netty 服务端创建>,研究了netty的服务端创建过程.至于netty的优势,可以参照网络其他文章.<Netty系列之Netty 服务端创建>是 李林锋撰写的netty源码分析的一篇好文,绝对是技术干货.但抛开技术来说,也存在一些瑕疵. 缺点如下 代码衔接不连贯,上下不连贯. 代码片段是截图,对阅读代理不便(可能和阅读习惯有关) 本篇主要内容,参照<Netty系列之Netty 服务端创建>,梳理出自己喜欢的阅读风格. 1.整体逻辑图 整体将服务

飞鸽传书源码分析五-文件传输

转载请注明出处:http://blog.csdn.net/mxway/article/details/44889871 本文是在飞鸽传书源码v2.06的基础上进行分析的. 1.添加要发送的文件 文件的发送是在发送对话框中进行的,首先找到发送对话框的快捷菜单. File Transfer对应的菜单id为MENU_FILEADD,相应的command处理事件在Senddlg.cpp中的EvCommand函数中 BOOL TSendDlg::EvCommand(WORD wNotifyCode, WO

storm源码分析之topology提交过程

storm集群上运行的是一个个topology,一个topology是spouts和bolts组成的图.当我们开发完topology程序后将其打成jar包,然后在shell中执行storm jar xxxxxx.jar xxxxxxxClass就可以将jar包上传到storm集群的nimbus上,并执行topology.本文主要分析下topology的jar包是如何上传到nimbus上的.首先我们从storm的jar命令入手,jar命令的实现位于storm根目录的bin/storm文件里.定义如

Android 源码分析-Dalvik 虚拟机创建过程

更多完整项目下载.未完待续.源码.图文知识后续上传github.可以点击关于我?联系我获取 一. 介绍Dalvik 1.java的运行需要JVM,同样android中使用了java语言,也需要一个VM.针对手机处理器和内存等硬件资源不足而推出来的一款VM,为android运行提供环境,叫DVM. 2.Dalvik虚拟机允许多个instance的存在.实际上android中的每一个app都是运行在自己VM实例之中(沙盒).每一个VM实例在linux中又是一个单独的进程,所以可以认为是同一个概念.运

Netty源码分析之客户端启动过程

一.先来看一下客户端示例代码. 1 public class NettyClientTest { 2 public void connect(int port, String host) throws Exception { 3 EventLoopGroup group = new NioEventLoopGroup();//与服务端不同,客户端只需要一个IO线程组 4 5 try { 6 Bootstrap b = new Bootstrap(); 7 b.group(group) 8 .op

分布式文件系统 fastdfs 源码分析 之 文件上传流程分析

fastdfs是一个轻量级的分布式文件系统,主要由 tracker server, storage server 以及client组成,这里主要涉及两点 : 1)客户端上传文件流程和协议分析 2)实现一个简单的文件上传函数 一: 文件上传的基本流程 fastdfs中上传一个文件,主要涉及以下几个步骤: 1)上传连接请求,客户端会向tracker server发出上传文件的请求 2)tracker收到请求后,返回storage server的ip和端口 3)客户端连接storage,并且上传文件

django源码分析——静态文件staticfiles中间件

本文环境python3.5.2,django1.10.x系列 1.在上一篇文章中已经分析过handler的处理过程,其中load_middleware就是将配置的中间件进行初始化,然后调用相应的设置方法. django框架提供的认证,回话保持,静态文件调试处理等都是通过以中间件的形式来处理. 2.本节就分析一下django框架提供的staticfiles中间件,该中间件分别实现了三个框架的命令,分别为collectstatic,findstatic,runserver. 其中,runserver

wxWidgets源码分析(1) - App启动过程

目录 APP启动过程 wxApp入口定义 wxApp实例化准备 wxApp的实例化 wxApp运行 总结 APP启动过程 本文主要介绍wxWidgets应用程序的启动过程,从app.cpp入手. wxApp入口定义 wxApp通过IMPLEMENT_APP宏注册App类,这个宏同时定义了入口,实现在wx/app.h文件中. // wx/app.h 文件中定义 #define IMPLEMENT_APP(app) wxIMPLEMENT_APP(app); // 可以忽略 wxIMPLEMENT_