FDRAM：内存虚拟磁盘技术解析

原创于 2025-11-04 09:09:27 发布 · 594 阅读

28 ·

CC 4.0 BY-SA版权

文章标签：

#FDRAM # tmpfs # MTD # 嵌入式系统 # 内存分区 # 虚拟磁盘 # Flash磨损 # I/O优化

AI助手已提取文章相关产品：

添加新分区FDRAM并挂载到根目录：技术深度解析

在嵌入式设备的世界里，你有没有遇到过这样的场景？系统频繁写日志，Flash寿命眼看就要耗尽；临时文件I/O成了瓶颈， /tmp 目录卡得像老式磁带机；重启后还要跑一遍 fsck ，启动时间拖得越来越长。这些问题背后，其实都指向同一个根源——我们把太多本该“短暂存在”的数据，强行塞进了为“持久存储”而生的物理介质中。

有没有一种方式，能让这些高频、临时的数据操作，不再压榨Flash，也不再拖慢系统？答案是肯定的： 用内存模拟一块高速“虚拟磁盘” ，把它挂载成一个独立分区，专用于处理那些“用完即焚”的数据。这就是本文要深入探讨的技术实践——创建名为 FDRAM 的内存分区，并将其挂载至 /fDRAM 。

别被“FDRAM”这个名字迷惑了，它不是什么神秘硬件，也不是标准术语，而是工程师们对“Fake DRAM”的一种戏称：从主内存里划出一块地，假装它是块可读写的存储设备。虽然听起来有点“骗自己”，但正是这种巧妙的虚拟化手段，在无数路由器、工业控制器和IoT设备中默默扛起了性能优化的重任。

实现这个方案的核心思路其实很朴素： 先留地，再建房，最后挂牌入住 。

第一步，“留地”——在系统启动早期就锁定一段物理内存，确保操作系统不会把它分配给其他进程。这一步通常通过内核命令行参数完成：

mem=512M memmap=64M$0x88000000

这条指令告诉内核：“我的总内存是512MB，但从地址 0x88000000 开始的64MB你别动，我要另作他用。” 这段被“圈起来”的内存从此脱离伙伴系统的管理，成为一块专属领地。

接下来，“建房”——怎么让这块内存能像磁盘一样被格式化、挂载？这里有两条技术路径。

其一是走 MTD（Memory Technology Device）子系统 路线。MTD原本是为NOR/NAND Flash设计的抽象层，但它也支持RAM类型设备。我们可以写一个简单的内核模块，把保留的内存映射为一个MTD设备：

static struct mtd_info *fDRAM_mtd;

int __init fDRAM_init(void)
{
    void *virt_addr = ioremap_nocache(0x88000000, 0x4000000); // 64MB
    if (!virt_addr)
        return -ENOMEM;

    fDRAM_mtd = kzalloc(sizeof(struct mtd_info), GFP_KERNEL);
    fDRAM_mtd->name = "fDRAM";
    fDRAM_mtd->type = MTD_RAM;
    fDRAM_mtd->size = 0x4000000;
    fDRAM_mtd->writesize = 1;
    fDRAM_mtd->flags = MTD_CAP_RAM;
    fDRAM_mtd->_read = fDRAM_read;
    fDRAM_mtd->_write = fDRAM_write;

    add_mtd_device(fDRAM_mtd);
    return 0;
}

一旦注册成功，系统就会出现 /dev/mtdblockX 这样的设备节点。这时候你就可以像操作普通磁盘一样，给它格式化一个ext4文件系统：

mkfs.ext4 /dev/mtdblock2
mkdir -p /fDRAM
mount -t ext4 /dev/mtdblock2 /fDRAM

这种方式的好处是语义完整，支持传统文件系统的权限、属性、目录结构，适合需要复杂组织形式的场景，比如OTA升级时的临时解压区。

但更多时候，我们根本不需要这么重的方案。Linux早已为我们准备了更轻量、更安全的选择—— tmpfs 。

tmpfs 是一种基于页缓存的伪文件系统，直接使用RAM作为后端存储，无需预先保留内存或编写驱动。它的使用极其简单：

mount -t tmpfs tmpfs /fDRAM -o size=64M,mode=0755

一句话搞定创建与挂载。而且 tmpfs 智能地只在真正写入数据时才分配内存，空挂载几乎不占资源。相比之下， ramfs 虽然更快，但会无限增长直至耗尽内存，容易引发OOM，因此除非你清楚自己在做什么，否则应避免使用。

说到这里，不妨对比一下几种常见方案的实际表现：

特性	FDRAM (MTD+ext4)	tmpfs	ramfs	NAND Flash
读写速度	高	极高	极高	低
持久性	否	否	否	是
可格式化	是	否	否	是
支持权限/属性	是	是	是	是
占用RAM	固定	动态	不限	不占
典型用途	高速可格式化缓存区	通用临时文件	内核内部使用	根文件系统

可以看到，对于绝大多数FDRAM应用场景， tmpfs 是更优解 ：它由内核统一管理，自动参与内存回收，安全性高，配置灵活，还不需要额外开发工作。

那这套机制具体怎么融入系统呢？来看一个典型的部署流程。

系统上电后，Bootloader将 memmap 参数传给内核，内核跳过保留区域完成初始化。随后，在用户空间启动阶段，执行如下脚本：

#!/bin/sh
mkdir -p /fDRAM
if ! mountpoint -q /fDRAM; then
    mount -t tmpfs fDRAM-tmpfs /fDRAM -o size=64M,mode=0755,uid=0,gid=0
    echo "FDRAM mounted at /fDRAM"
fi

这段脚本可以放在 /etc/rc.local 或封装为 systemd service，确保每次开机自动挂载。之后，应用程序就可以放心地往 /fDRAM 写日志、放缓存、存会话快照了。断电后一切清零，既保证了数据一致性，又免去了文件系统修复的烦恼。

如果你希望进一步提升可用性，还可以做些小技巧。例如：