f2fs解析(五)什么叫做compacted summary

f2fs中普通的summary是长这样的:每一个段的SSA block中,前半部分是这个段的SSA,然后对于HOT_DATA以及COLD_DATA段,存放是的是nat journal 和 sit journal,最后是一个ssa_footer,footer里面存放的是这个段是一个DATA段还是NODE段等信息,这是一个典型SSA的block的分布;

但是对于compact段来说,它的布局是这样的:

//------------------------------------------------------

1. nat journal

2 sit journal

3 hot data summary

4 warm data summary

5 cold data summary

//--------------------------------------------------------

基本打破了正常情况下SSA段中的分布,为什么要搞这玩意儿?

为了能够让每次写checkpoint时更加集中,这样的话并不是把ssa的更新散落在ssa区域中了!让写更加集中!

有个疑问:每次写checkpoint,假设都是采用compacted方式存储ssa的信息,那么本次写会把上次的写的给覆盖,这要怎么办呢?

回答:这是无所谓的,当这个段不是curseg的时候,这个段的ssa会写到它真正的地地方,那才是它的家,而这里的compacted 方式的ssa存储都是对于当前段。

如果你还有疑问,那么我想这应该是如何读取这个很奇葩的compacted ssa的结构了!

首先nat_journal 和 sit_journal的结构都很好读取了,因为它们本来就是定长的,但是HOT/WARM/COLD却不是定长的。

没关系,checkpoint中存储了这三个DATA段中每一个段到底有几个SSA_ENTRY,所以直接简单地读取就可以!这样curseg的数据,就能够在另一次挂载的时候完璧归赵了!

时间: 2024-08-05 11:00:27

f2fs解析(五)什么叫做compacted summary的相关文章

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

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

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_sca

f2fs解析(七)node管理器中的 free_nid 结构体

除了node_info之外, node管理器中还有还有个重要的数据结构: 145 struct free_nid { 146 struct list_head list; /* for free node id list */ 147 nid_t nid; /* node id */ 148 int state; /* in use or not: NID_NEW or NID_ALLOC */ 149 }; 这个结构体体很简单,比刚才的node_info轻量级多了,仅仅是标识了当前可以使用的n

f2fs解析(一)f2fs如何解决wandering tree

wandering tree问题是log-structured 文件系统(LFS) 特有的一个问题,因为LFS的脏数据是追加更新的,所以如果一个数据块变脏了,那么那个数据块的直接索引块.间接索引块都会变脏(因为索引的地址变脏).F2FS是如何解决这个问题呢? 我们知道F2FS中main area中共有两种类型的block:NODE和DATA,其中NODE存储文件的元数据,DATA存储文件实际的数据.其中NODE类型的block包括三类元数据:inode,直接dnode,间接dnode.其中直接d

第六十七课、经典问题解析五

一.问题一:编写一个函数判断一个变量是不是指针 1.拾遗 (1).c++中仍然支持C语言中的可变参数函数 (2).c++编译器的匹配调用优先级:重载函数-------->函数模板--------->变参函数 2.思路 (1).将变量分为两类:指针VS非指针 (2).编写函数 A.指针变量调用返回true B.非指针变量调用时返回false 3.函数模板与变参函数的化学反应 template<typename T> //优先匹配函数模板 bool IsPtr(T* v) // mat

f2fs解析(二)f2fs写checkpoint时如何冻住整个文件系统

函数write_checkpoint中,会调用block_operations,函数中有这样一段代码: retry_flush_dents: f2fs_lock_all(sbi); /* write all the dirty dentry pages */ if (get_pages(sbi, F2FS_DIRTY_DENTS)) { f2fs_unlock_all(sbi); sync_dirty_dir_inodes(sbi); if (unlikely(f2fs_cp_error(sbi

f2fs解析(三)NAT中如何区分inode和其他dnode

首先,我们要知道NAT中的每个表项都对应着MAIN AREA区域中NODE段的一个block,还要知道NODE block很特别,block末尾会有一个node footer结构: 243 struct node_footer { 244 __le32 nid; /* node id */ 245 __le32 ino; /* inode nunmber */ 246 __le32 flag; /* include cold/fsync/dentry marks and offset */ 24

f2fs解析(四)f2fs的extent特性

extent的意思是“程度”,但是我还是搞不清楚要如何把“程度”和我理解的extent联系到一起. 文件的偏移和page-cache的映射关系体现在address space 中的一颗基数树上:当基数树中的page真正落盘时,f2fs也有自己的block分配算法去存储这个page:当数据真正落盘之后,文件的逻辑偏移和其真正的block之间的关系是通过inode以及各级dnode构成的索引来建立的.如果我每次查看文件的索引都是通过读各级索引去得到最终数据块的block地址也是蛮慢的,所以索引的关系

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

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