f2fs源码解析(五) node管理结构梳理

node是f2fs重要的管理结构, 它非常重要! 系统挂载完毕后, 会有一个f2fs_nm_info结构的node管理器来管理node的分配. f2fs_nm_info中最让人疑惑的是几颗基数树:

 490 struct f2fs_nm_info {
 491     block_t nat_blkaddr;        /* base disk address of NAT */
 492     nid_t max_nid;          /* maximum possible node ids */
 494     nid_t next_scan_nid;        /* the next nid to be scanned */
 497     /* NAT cache management */
 498     struct radix_tree_root nat_root;/* root of the nat entry cache */
 499     struct radix_tree_root nat_set_root;/* root of the nat set cache */
 501     struct list_head nat_entries;   /* cached nat entry list (clean) */
 502     unsigned int nat_cnt;       /* the # of cached nat entries */
 503     unsigned int dirty_nat_cnt; /* total num of nat entries in set */
 505     /* free node ids management */
 506     struct radix_tree_root free_nid_root;/* root of the free_nid cache */
 507     struct list_head free_nid_list; /* a list for free nids */
 509     unsigned int fcnt;      /* the number of free node id */
 512     /* for checkpoint */
 513     char *nat_bitmap;       /* NAT bitmap pointer */
 514     int bitmap_size;        /* bitmap size */
 515 };

三棵基数树分别是: nat_root, nat_set_root, free_nid_root;

首先, 对于整个node管理器来说, 一个核心的结构体是node_info:

 46 struct node_info {
 47     nid_t nid;      /* node id */
 48     nid_t ino;      /* inode number of the node‘s owner */
 49     block_t blk_addr;   /* block address of the node */
 50     unsigned char version;  /* version of the node */
 51     unsigned char flag; /* for node information bits */
 52 };
 53
 54 struct nat_entry {
 55     struct list_head list;  /* for clean or dirty nat list */
 56     struct node_info ni;    /* in-memory node information */
 57 };

发现node_info和f2fs_nat_entry【磁盘上的存储】长得太像了, 甚至比 struct f2fs_nat_entry 还要多出来一个flag 位来表示这个节点的一些属性!

266 struct f2fs_nat_entry {267     __u8 version;       /* latest version of cached nat entry */
268     __le32 ino;     /* inode number */
269     __le32 block_addr;  /* block address */
270 } __packed;

这个core数据结构被两个结构控制:一个是基数树【负责索引】,一个是链表。

时间: 2024-08-25 16:19:42

f2fs源码解析(五) node管理结构梳理的相关文章

十五.jQuery源码解析之Sizzle总体结构.htm

Sizzle是一款纯javascript实现的css选择器引擎,它具有完全独立,无库依赖;小;易于扩展和兼容性好等特点. W3C Selectors API规范定义了方法querySelector()和querySelectorAll(),但是IE6,7不支持这两个方法. 在Sizzele内部,如果浏览器支持方法querySelectorAll(),则调用该方法查找元素,如果不支持,则模拟该方法的行为. Sizzle支持几乎所有的css3选择器,并且会按照文档位置返回结果. 上面截取的只是Siz

Spring 源码解析之DispatcherServlet源码解析(五)

Spring 源码解析之DispatcherServlet源码解析(五) 前言 本文需要有前四篇文章的基础,才能够清晰易懂,有兴趣可以先看看详细的流程,这篇文章可以说是第一篇文章,也可以说是前四篇文章的的汇总,Spring的整个请求流程都是围绕着DispatcherServlet进行的 类结构图 根据类的结构来说DispatcherServlet本身也是继承了HttpServlet的,所有的请求都是根据这一个Servlet来进行转发的,同时解释了为什么需要在web.xml进行如下配置,因为Spr

redis源码解析之内存管理

zmalloc.h的内容如下: 1 void *zmalloc(size_t size); 2 void *zcalloc(size_t size); 3 void *zrealloc(void *ptr, size_t size); 4 void zfree(void *ptr); 5 char *zstrdup(const char *s); 6 size_t zmalloc_used_memory(void); 7 void zmalloc_enable_thread_safeness(v

iOS即时通讯之CocoaAsyncSocket源码解析五

接上篇:iOS即时通讯之CocoaAsyncSocket源码解析四         原文 正文待补...

Tomcat请求处理过程(Tomcat源码解析五)

前面已经分析完了Tomcat的启动和关闭过程,本篇就来接着分析一下Tomcat中请求的处理过程. 在开始本文之前,咋们首先来看看一个Http请求处理的过程,一般情况下是浏览器发送http请求->建立Socket连接->通过Socket读取数据->根据http协议解析数据->调用后台服务完成响应,详细的流程图如上图所示,等读者读完本篇,应该就清楚了上图所表达的意思.Tomcat既是一个HttpServer也是一个Servlet 容器,那么这里必然也涉及到如上过程,首先根据HTTP协议

Samba 源码解析之内存管理

由于工作需要想研究下Samba的源码,下载后发现目录结构还是很清晰的.一般大家可能会对source3和source4文件夹比较疑惑.这两个文件夹针对的是Samba主版本号,所以你可以暂时先看一个.这里我选择Source3. 阅读源码最好要动手编译并安装,但这里我偷个懒直接在ubuntu上安装跳过了编译步骤.首先从client开始看起.SMBclient的所有命令的对应code都在source3/client/client.c中,我们由浅入深,挑一个比较简单的命令来看下它的执行流程,将简单的命令分

Curator源码解析(五)Curator的连接和重试机制

转载请注明出处: jiq?钦's technical Blog 本文将主要关注Curator是如何处理连接丢失和会话终止这两个关键问题的. 1.   连接丢失的处理 Curator中利用类ConnectionState来管理客户端到ZooKeeper集群的连接状态,其中用到原子布尔型变量来标识当前连接是否已经建立: private finalAtomicBoolean isConnected= newAtomicBoolean(false); 在事件处理函数中(ConnectionState实现

Linux源码解析-内核栈与thread_info结构详解

1.什么是进程的内核栈? 在内核态(比如应用进程执行系统调用)时,进程运行需要自己的堆栈信息(不是原用户空间中的栈),而是使用内核空间中的栈,这个栈就是进程的内核栈 2.进程的内核栈在计算机中是如何描述的? linux中进程使用task_struct数据结构描述,其中有一个stack指针 struct task_struct { // ... void *stack; // 指向内核栈的指针 // ... }; task_struct数据结构中的stack成员指向thread_union结构(L

AFNetworking (3.1.0) 源码解析 <五>

这次主要开始讲解一下文件夹Serialization下的类AFURLRequestSerialization. AFURLRequestSerialization类遵守`AFURLRequestSerialization`和`AFURLResponseSerialization`协议,提供一个查询字符串/表单编码的参数序列化和默认请求头的具体的基本的实现,以及响应状态代码和内容类型验证.也就是对发出的请求进行一些处理. 处理HTTP的任何请求或响应序列化被鼓励归入“AFHTTPRequestSe