F2FS源码探秘-1.5 [NAT结构解析] Node Address Table的内存管理与优化策略

1. 从“电话簿”到“内存管家”：NAT到底是什么？

大家好，我是老K，一个在存储和文件系统领域折腾了十多年的老码农。今天咱们不聊那些虚头巴脑的概念，直接扎进F2FS的源码里，看看它的核心元数据之一——Node Address Table（NAT，节点地址表）——在内存里是怎么被“伺候”得服服帖帖的。如果你之前看过一些介绍，可能知道NAT是张“地图”，记录了每个Node（节点）在闪存上的物理地址。但今天我们要聊的，远不止这张“地图”长什么样，而是F2FS这位“内存管家”是如何聪明地管理这张地图，既不让内存吃紧，又能让系统跑得飞快。

你可以把整个F2FS文件系统想象成一个超大型的公寓楼。每个文件或目录都是一个“住户”（Node），系统给每个住户分配了一个唯一的门牌号，也就是Node ID（nid）。那么问题来了，快递员（系统要读取数据时）怎么根据门牌号找到具体的房间呢？这就需要一本记录了所有房间物理位置的“超级电话簿”，这就是NAT。它本质上就是一个大数组，索引是nid，值就是这个节点数据实际存放在闪存上的物理块地址（block_addr）。

但是，这本“电话簿”如果每次都去翻厚厚的纸质版（从闪存读取），那效率就太低了。所以，F2FS的设计精髓在于：它不会傻乎乎地把整本电话簿（整个NAT）都搬进内存。想想看，一个几个T的硬盘，对应的NAT可能非常大，全放内存里太奢侈了。那怎么办？F2FS的做法是，在内存里建立一个精干的“管理处”，这个管理处的核心结构就是struct f2fs_nm_info（Node Manager Information）。它只干两件最要紧的事：第一，高效地缓存一部分最可能被用到的“住户地址信息”（NAT条目）；第二，也是更巧妙的一点，它提前准备好了一批“空房号”（free nid），当有新住户（新建文件或目录）要入住时，能瞬间分配，不用临时去翻电话簿找空号。

这就是我们这次要深挖的NAT内存管理与优化策略。我们会跟着源码，看看这个“管理处”（f2fs_nm_info）是怎么搭建起来的，它的“空房号列表”（free nid表）是如何构建和维护的，以及它用了哪些“缓存”和“索引”的妙招来提升查找效率。理解了这些，你才能真正明白F2FS在应对海量小文件、频繁文件创建删除场景时，为何能表现出色。好，废话不多说，咱们直接看代码。

2. 核心指挥部：struct f2fs_nm_info 的初始化

当我们挂载一个F2FS文件系统时，系统会调用build_node_manager函数来创建并初始化这个核心的“内存管理处”。这个过程就像给一个新楼盘组建物业中心，必须把家底摸清，把工具备齐。

int build_node_manager(struct f2fs_sb_info *sbi) { int err; // 第一步：先给“物业中心”划块地（分配内存） sbi->nm_info = kzalloc(sizeof(struct f2fs_nm_info), GFP_KERNEL); if (!sbi->nm_info) return -ENOMEM; // 第二步：给中心配备基础设备和名册（初始化关键信息） err = init_node_manager(sbi); if (err) return err; // 第三步：准备一批“空房号”以备不时之需（构建初始空闲nid列表） build_free_nids(sbi); return 0; }

这个函数干净利落，三步走。其中init_node_manager是重头戏，它负责填充struct f2fs_nm_info里的各个字段。我们挑几个关键的来看看：

static int init_node_manager(struct f2fs_sb_info *sbi) { struct f2fs_super_block *sb_raw = F2FS_RAW_SUPER(sbi); struct f2fs_nm_info *nm_i = NM_I(sbi); unsigned char *version_bitmap; unsigned int nat_segs, nat_blocks; // 1. 找到“电话簿”仓库的位置 nm_i->nat_blkaddr = le32_to_cpu(sb_raw->nat_blkaddr); // 2. 计算电话簿总共有多少页（多少NAT块） nat_segs = le32_to_cpu(sb_raw->segment_count_nat) >> 1; nat_blocks = nat_segs << le32_to_cpu(sb_raw->log_blocks_per_seg); // 3. 算出最大的门牌号是多少 nm_i->max_nid = NAT_ENTRY_PER_BLOCK * nat_blocks; // 可用门牌号要减去系统预留的（比如0号、元数据节点等） nm_i->available_nids = nm_i->max_nid - F2FS_RESERVED_NODE_NUM; // 4. 初始化各种管理工具和列表 nm_i->fcnt = 0; // 当前缓存的空闲nid数量 nm_i->nat_cnt = 0; // 当前缓存的NAT条目数量 // 以下两个是核心的索引结构：“基数树”+“链表”，构成一个高效缓存 INIT_RADIX_TREE(&nm_i->free_nid_root, GFP_ATOMIC); // 空闲nid的基数树 INIT_LIST_HEAD(&nm_i->free_nid_list); // 空闲nid的链表 INIT_RADIX_TREE(&nm_i->nat_root, GFP_NOIO); // 缓存NAT条目的基数树 // 5. 设置搜索起点：从上一次检查点记录的位置开始找空房号 nm_i->next_scan_nid = le32_to_cpu(sbi->ckpt->next_free_nid); // 6. 管理“电话簿”版本信息的位图（用于数据恢复，这里先不展开） nm_i->nat_bitmap = kmemdup(version_bitmap, nm_i->bitmap_size, GFP_KERNEL); ... }

我在这里踩过一个坑，早期看代码时对next_scan_nid这个字段不太在意。后来在压力测试时发现，频繁创建删除文件后，分配nid的速度有时会变慢。一查才知道，这个字段是关键。它记录了上次扫描NAT区域寻找空闲nid的“断点”。下次需要补充空闲nid时，就不用从头开始扫描了，直接从这个位置继续，避免了重复劳动，这是一个典型的增量扫描优化。

初始化完成后，nm_info这个结构体就包含了管理整个NAT所需的所有“地图信息”（起始地址、总容量）和“管理工具”（各种锁、树、列表）。但这时的“空房号列表”还是空的，这就需要build_free_nids函数上场了。

3. 精打细算：空闲NID列表的构建与维护

F2FS最让我欣赏的设计哲学之一就是“按需缓存，精打细算”。它不会一口气把NAT里所有空闲的nid（可能几百万个）都加载到内存的free nid列表里，那样太占地方了。相反，它只维护一个小规模的缓存池。build_free_nids函数就是负责把这个池子给灌上第一桶水。

void build_free_nids(struct f2fs_sb_info *sbi) { struct f2fs_nm_info *nm_i = NM_I(sbi); nid_t nid = nm_i->next_scan_nid; // 从上一次记住的位置开始扫 int i = 0; // 如果缓存池已经比较满了，这次就不干活了 if (nm_i->fcnt >= NAT_ENTRY_PER_BLOCK) return; // 大招：预读！一次性读8个NAT块到内存页缓存，减少IO等待 ra_meta_pages(sbi, NAT_BLOCK_OFFSET(nid), FREE_NID_PAGES, META_NAT, true); down_read(&nm_i->nat_tree_lock); while (1) { struct page *page = get_current_nat_page(sbi, nid); // 核心：扫描这个NAT块，把里面的空闲nid捡出来 scan_nat_page(sbi, page, nid); f2fs_put_page(page, 1); // 跳到下一个NAT块的起始nid nid += (NAT_ENTRY_PER_BLOCK - (nid % NAT_ENTRY_PER_BLOCK)); if (unlikely(nid >= nm_i->max_nid)) nid = 0; // 只扫预读的这8个块，见好就收 if (++i >= FREE_NID_PAGES) break; } // 记住这次扫到哪里了，下次接着来 nm_i->next_scan_nid = nid; ... }

这里有几个优化点非常实用：

1. 批量预读（Read-ahead）：ra_meta_pages一次性读取多个NAT块（默认8个）。因为闪存的特点是顺序读极快，随机读较慢。既然要扫描，很可能连续扫描多个块，提前把它们读到内存的页缓存里，后面用get_current_nat_page获取时几乎零延迟，这招对提升挂载速度和运行时性能很有效。
2. 扫描粒度控制：NAT_ENTRY_PER_BLOCK是一个块里能存放的NAT条目数（比如455个）。扫描以块为单位进行，逻辑清晰。
3. 循环与回绕：当nid超过最大值max_nid时，会回绕到0。这保证了扫描能覆盖整个NAT区域。

那么，具体怎么从一个NAT块里“捡”出空闲nid呢？看scan_nat_page函数：

static void scan_nat_page(struct f2fs_sb_info *sbi, struct page *nat_page, nid_t start_nid) { struct f2fs_nm_info *nm_i = NM_I(sbi); struct f2fs_nat_block *nat_blk = page_address(nat_page); block_t blk_addr; int i; i = start_nid % NAT_ENTRY_PER_BLOCK; for (; i < NAT_ENTRY_PER_BLOCK; i++, start_nid++) { ... blk_addr = le32_to_cpu(nat_blk->entries[i].block_addr); // 关键判断：物理地址为NULL_ADDR表示这个nid是“空房号” if (blk_addr == NULL_ADDR) { if (add_free_nid(sbi, start_nid, true) < 0) break; } } }

逻辑很简单：遍历这个块里的每一个条目，检查它的block_addr字段。如果这个地址是NULL_ADDR（一个特殊值，比如0xFFFFFFFF），那就说明这个nid对应的“房间”是空的，没人住。于是调用add_free_nid把它加入到我们内存中的空闲nid缓存池里。

这里我实测过一个场景：在一个几乎写满的分区上反复创建删除小文件。初期free nid池消耗很快，但build_free_nids会被周期性触发（比如在分配nid时发现池子快空了），它就会从next_scan_nid开始继续扫描NAT，寻找新的“空房号”来补充池子。这个设计使得内存占用稳定，且能适应不同使用强度的场景。

4. 高效缓存与索引：基数树（Radix Tree）的妙用

现在我们知道空闲nid被收集起来了，但怎么存、怎么取才能快呢？这就是struct f2fs_nm_info里free_nid_root和free_nid_list这对组合拳发挥作用的地方了。它们共同实现了一个高效的空闲nid缓存索引。

INIT_RADIX_TREE(&nm_i->free_nid_root, GFP_ATOMIC)初始化了一棵基数树。你可以把它理解为一个特别适合用整数（比如我们的nid）当键（key）来快速查找的哈希表。当我们通过scan_nat_page找到一个空闲nid后，add_free_nid函数会做两件事：

1. 将这个nid作为键，插入到free_nid_root这棵基数树中。
2. 同时，将这个nid对应的结构体（struct free_nid）挂到free_nid_list链表上。

为什么要用两种数据结构？

• 基数树（Radix Tree）：用于快速判定。当系统需要分配一个nid，或者需要检查一个nid是否空闲时，可以直接用nid作为键去基数树里查找，时间复杂度接近O(1)。这解决了“查得快”的问题。
• 链表（List）：用于快速分配。当需要拿出一个空闲nid分配给新文件时，直接从链表头（或尾）取一个节点就行了，也是O(1)操作。这解决了“拿得快”的问题。

这种“基数树+链表”的模式在Linux内核中非常常见，它兼顾了查找和顺序访问的效率。我印象很深的是，有一次为了排查一个nid分配偶尔变慢的问题，我们曾尝试过只用链表。结果在文件系统很大、空闲nid很多时，判断某个nid是否在空闲列表里（比如避免重复分配）需要遍历链表，效率急剧下降。换回“基数树+链表”的组合后，问题迎刃而解。

对于已经使用的、但近期可能被访问的NAT条目，F2FS也用了类似的缓存策略，即nat_root基数树。当系统通过nid查找一个节点的物理地址时，它首先会去nat_root这棵缓存树里找。如果找到了（缓存命中），就直接返回，完全不用去读闪存上的NAT块。如果没找到（缓存未命中），才去读闪存，并将读到的NAT条目插入到nat_root树中，供后续使用。这是一个典型的LRU（最近最少使用）缓存思想的变体实现，nat_cnt用来控制缓存的总量，防止内存被无限占用。

5. 实战中的优化策略与参数调优

理解了基本机制，我们来看看在实际使用中，有哪些可以观察和调整的点，这能帮你更好地理解或优化F2FS的行为。

1. 空闲NID缓存池的大小与性能平衡：nm_i->fcnt记录了当前缓存了多少个空闲nid。这个值不是固定的，它会随着系统的运行在NAT_ENTRY_PER_BLOCK和一个最小值之间动态波动。你可以通过内核的调试接口（如sysfs或debugfs）查看这个值。如果在一个频繁创建文件的场景下，你发现fcnt经常很低，且build_free_nids被频繁调用，这可能意味着默认的缓存水位（NAT_ENTRY_PER_BLOCK）对于你的负载来说偏小。虽然F2FS没有直接提供参数让你调整这个水位，但理解这一点有助于你做性能分析：频繁的NAT扫描会引入额外的元数据读取开销。

2. 预读策略的调整：build_free_nids中使用的FREE_NID_PAGES（值为8）和nm_i->ra_nid_pages（默认值）控制了预读NAT块的数量。在顺序创建大量文件的场景下，适当增加预读量（需要修改内核源码并重新编译）可能会带来一定的性能提升，因为这更大概率让下一次需要的NAT块已经在页缓存中。但预读太多又会浪费内存和带宽，需要根据实际硬件（特别是闪存的随机/顺序读取性能特征）进行权衡。

3. NAT缓存命中率的重要性：nat_root缓存树的命中率是影响文件元数据操作（如打开文件、查找目录项）速度的关键。在f2fs的统计信息中，通常会有相关的计数器。如果命中率很低，说明系统正在大量地进行NAT块的闪存读取，这可能会成为瓶颈。这种情况通常发生在遍历一个包含海量文件的目录，或者系统内存压力极大导致缓存被频繁回收时。对于目录遍历密集的应用，确保系统有足够的内存留给F2FS的元数据缓存至关重要。

4. 关于next_scan_nid的“坑”：这个字段在检查点（Checkpoint）中会被持久化。这意味着，如果系统异常崩溃，重启后F2FS会从检查点恢复，并从上一次保存的next_scan_nid位置继续扫描空闲nid。这保证了空闲nid搜索的连续性。但这里有一个潜在的极端情况：如果NAT区域中段的空闲nid被全部用完，而next_scan_nid又正好卡在中间，可能会导致它向后扫描找不到空闲nid，但前面其实还有（因为它是单向递增扫描的）。F2FS通过扫描到末尾后回绕到0（nid = 0）来解决这个问题，确保最终能覆盖全盘。但在设计自己的类似机制时，这一点需要考虑周全。

6. 与Checkpoint的联动：日志里的NAT信息

细心的你可能在build_free_nids函数的后半部分看到，它不光扫描了NAT区域，还检查了Checkpoint区域的Journal。这是F2FS保证数据一致性的重要一环。

/* 遍历log的nat_journal记录的nat_entry信息，从中寻找free nid */ down_read(&curseg->journal_rwsem); for (i = 0; i < nats_in_cursum(journal); i++) { block_t addr; nid = le32_to_cpu(nid_in_journal(journal, i)); addr = le32_to_cpu(nat_in_journal(journal, i).block_addr); if (addr == NULL_ADDR) add_free_nid(sbi, nid, true); else remove_free_nid(nm_i, nid); }

Checkpoint的Journal里保存了最近一次Checkpoint之后、尚未写回NAT区域的NAT条目变更。这些变更可能是：

• 新增节点：block_addr被赋值为有效的物理地址。这时，这个nid就不再是空闲的了，所以需要从内存的free nid列表中remove_free_nid。
• 删除节点：block_addr被置为NULL_ADDR。这时，这个nid变成了空闲的，需要add_free_nid加入列表。

这样做的好处是什么？保证了内存中free nid列表的实时性和准确性。想象一下，一个文件被删除，其对应的nid在Journal里被标记为空闲，但还没来得及写回NAT块。如果不更新内存列表，系统就不知道这个nid已经空闲了，可能还会去扫描很远的NAT块找空闲nid，效率低下。通过及时同步Journal里的信息，F2FS让空闲nid的分配总能基于最新的系统状态，大大提升了分配效率，也避免了nid的浪费。

7. 总结与个人经验分享

走读了一遍F2FS NAT内存管理的核心代码，我们可以清晰地看到它的设计脉络：以内存中的struct f2fs_nm_info为管理中心，用基数树和链表构建高效缓存与索引，采用惰性加载和增量扫描策略维护一个适度的空闲nid池，并与Checkpoint Journal联动保持状态最新。这一套组合拳，在内存占用、访问速度和数据一致性之间取得了很好的平衡。

在实际项目中使用F2FS，特别是自己定制或深度优化时，有几点经验值得分享：

• 关注free_nid_list的长度：在调试性能问题时，如果发现文件创建变慢，可以首先检查空闲nid缓存池是否见底。这可能是磁盘空间已满，或者有大量未刷新的删除操作导致空闲nid未能及时进入缓存。
• 理解基数树的作用：不要小看这个数据结构的选择。在需要频繁进行“存在性判断”的场景下，基数树相比简单的链表或数组，能带来数量级的性能提升。这在设计自己的缓存机制时是一个很好的借鉴。
• 结合SIT（Segment Information Table）看问题：NAT管理的是节点的地址，而节点最终是存放在Segment里的。有时节点分配慢，不一定是NAT的问题，也可能是没有干净的Segment可供写入（这属于SIT和垃圾回收的范畴了）。分析性能需要有一个全局视角。

最后，F2FS的代码在内存管理上还有很多细节，比如dirty_nats_ratio控制脏NAT条目写回的阈值，ram_thresh控制一些内存使用的阈值等。这些参数在内核配置中可能可以调整，但大多数情况下默认值已经过充分调优。作为开发者或者学习者，更重要的是理解这套机制背后的思想：如何用有限的内存资源，智能地管理庞大的元数据，为高速的闪存存储提供助力。希望这次对NAT内存管理的探秘，能让你在下次面对F2FS时，感觉不再是面对一个黑盒，而是一个设计精巧、有章可循的工程杰作。