CRAMFS(Compressed ROM File System) 是一种只读的、压缩的文件系统，通常用于嵌入式系统和嵌入式设备中。CRAMFS 设计用于将文件系统映射到只读存储介质上，如闪存、ROM 芯片或 CD-ROM，以便在资源受限的环境中提供文件系统支持。以下是 CRAMFS 文件系统的一些主要特点和概述:

• 只读文件系统: CRAMFS 是一种只读文件系统，这意味着它的内容在挂载后不能被修改。这使得它非常适合用于存储嵌入式设备中的固定文件，如系统文件、配置文件和应用程序二进制文件
• 压缩: CRAMFS 通过对文件和目录进行压缩来节省存储空间。压缩文件系统可以有效地减小文件系统的大小，从而减少了所需的存储介质空间
• 高效的访问速度: 由于 CRAMFS 是只读文件系统，它可以在挂载时对文件系统进行解压缩，并且文件系统的内容可以直接映射到内存中，因此它具有快速的访问速度
• 轻量级: CRAMFS 文件系统非常轻量级，占用的内存和存储资源非常有限。这使得它适用于嵌入式系统和嵌入式设备，这些设备通常具有有限的资源
• 只支持只读操作: CRAMFS 文件系统不支持写操作，因此无法用于存储需要动态修改的数据。它主要用于存储静态文件和只读数据
• 适用于 ROM 和闪存: CRAMFS 常用于存储在只读存储介质上，如 ROM 芯片、CD-ROM、DVD-ROM 和闪存中。它使得这些介质上的文件可以以高效的方式进行访问

CRAMFS 在只读和压缩方面具有优势，但它不适用于需要写入和修改文件的应用程序。在这种情况下，其他文件系统如 EXT4、FAT 或 JFFS2 等可能更适合用于嵌入式设备。CRAMFS 通常用于嵌入式系统中的固定文件和只读数据的存储。在 Linux 中使用 CRAMFS 需要打开内核宏 CONFIG_CRAMFS.

CRAMFS 文件系统是一个只读文件系统，可以看到映射文件的 mmap 接口使用了 generic_file_readonly_mmap 函数，generic_file_readonly_mmap 函数为文件映射的 VMA 提供的 vm_ops 接口为 generic_file_vm_ops，该数据接口实现了 fault 接口 filemap_fault，那么文件映射 VMA 发生缺页时 filemap_fault 函数会被调用.

在 CRAMFS 文件系统里，文件映射(File-Mapped) 的数据架构如上图，用户进程使用文件映射将文件映射到进程地址空间之后，进程使用 VMA 描述映射之后的虚拟内存区域，CRAMFS 文件系统会为 VMA 提供相应 generic_file_vm_ops，另外 vm_file 指向映射的文件(struct file), 其又指向唯一的 STRUCT inode, 其 mapping 成员用于指向 STRUCT address_space, 该数据结构用于维护文件与 PAGE CACHE 和 VMA 的映射关系，其中 i_mmap 成员指向一颗区间树(RB-TREE), 该区间树维护了映射到该文件的 VMA. 另外 i_pages 指向 XARRAY 数组，该数组维护了文件映射的 PAGE CACHE，每个 PAGE CACHE 对应一个 STRUCT page 数据结构，STRUCT page 的 mapping 成员反过来指向 STRUCT address_space, 那么可以知道 PAGE CACHE 被哪些 VMA 映射，因此形成了一个闭环. 当进程首次访问 VMA 虚拟内存区域时，会触发缺页异常构造这些逻辑。那么接下来通过一个实践案例了解这种异常场景，实践案例在 BiscuitOS 上的部署逻辑如下:

cd BiscuitOS
make menuconfig

  [*] DIY BiscuitOS/Broiler Hardware  --->
      [*] Virtio-BLK: CRAMFS Filesystem Disk  --->
  [*] Package  --->
      [*] Paging Mechanism  --->
          [*] Page Fault with File-Mapped CRAMFS --->

# 部署实践案例
make
# 源码目录
cd BiscuitOS/output/linux-6.0-x86_64/package/BiscuitOS-PAGING-PF-FILE-CRAMFS-default/
# 部署源码
make download
# 在 BiscuitOS 中实践
make build

BiscuitOS-PAGING-PF-FILE-CRAMFS-default Source Code on Gitee

实践案例由一个应用程序构成，进程在 23 行在 “/mnt/cramfs/” 目录下打开文件 BiscuitOS.txt 文件，该目录已经挂载为 CRAMFS 文件系统，进程接着在 29 行调用 mmap 函数将文件映射到进程的地址空间，并在 40 行对文件对应的虚拟内存进行读操作，操作完毕之后就是释放虚拟内存和关闭文件. 以上便是一个最基础的实践案例，可以知道 40 行读操作就会触发缺页，为了可以看到内存在缺页异常里的流动，在 40 行前后加上 BS_DEBUG 开关:

接着在 CRAMFS 文件映射内存缺页流程必经之路上任意位置加上 BS_DEBUG 函数，以此观察内存在某个函数里的流动，例如上图在 do_read_fault 函数的 4518 行加上 bs_debug 打印，以此确认内存流动到这里，接下来执行如下命令进行实践(需要提前打开内核宏: CONFIG_CRAMFS_FS):

# 编译应用程序
cd BiscuitOS/output/linux-6.0-x86_64/package/BiscuitOS-PAGING-PF-FILE-CRAMFS-default/
# 编译内核
make kernel
# 编译实践案例
make build

当 BiscuitOS 启动之后，直接运行 RunBiscuitOS.sh 脚本，脚本里包括实践所需的命令，可以看到进程执行之后对虚拟内存的访问引起了缺页异常，并且该案例的缺页异常处理流程打印了字符串 “CRAMFS PF on filemap_fault 0x6000000000” 两次, 那么说明实践案例分配了 PAGECACHE，同时也可以看到 PAGECACHE 按着之前分析的代码路径流动。最后开发者可以在该路径上的任何地方使用 bs_debug 查看 PAGECACHE 在缺页异常处理流程里的流动.

对于 CRAMFS 文件系统映射文件到地址空间之后，进程访问该虚拟内存时，由于 MMU 发现对于的物理内存不存在，那么触发缺页异常。在缺页异常处理函数里，其主要做三个事情，首先是分配 PAGECACHE，如上图调用 filemap_alloc_folio 函数进行分配; 当分配 PAGECACHE 之后 CRAMFS 文件系统向 BIO 层发送请求从磁盘里读取读取多个页表内容到 PAGECACHE, 由于磁盘 I/O 延迟无法立即获得文件内存，因此缺页异常会通过 VM_FAULT_RETRY 再次进行缺页处理，以确保文件内容已经更新到 PAGECACHE 里; 最后一个任务就是更新页表指向新的 PAGECACHE，以及更新页表标记为脏页等. 完成三个任务之后缺页异常处理函数就返回，那么进程可以正常访问虚拟内存. 因为 VM_FAULT_RETRY 的缘故，handle_mm_fault 会被执行两次，这么做的原因有如下:

• 磁盘 I/O 延迟: 当页面不在物理内存中，需要从磁盘加载时，可能由于磁盘 I/O 操作的延迟，内核无法立即获取所需页面。此时，内核可能会将页面标记为需要重新尝试，并等待磁盘 I/O 完成
• 页面锁定: 在某些情况下，内核可能会锁定某些页面，以确保它们在内存中不会被交换出去或释放。如果页面被锁定，内核可能会等待解锁页面后才能重新加载
• 其他临时情况: 还可能存在其他临时情况，导致页面无法立即加载到内存中。在这种情况下，内核可能会标记页面并尝试重新加载

do_read_fault 函数作为 CRAMFS 文件系统映射内存读操作导致缺页的核心处理函数，与 do_shared_fault 写缺页不同的是，其在 4522-4526 行提供了 do_fault_around 函数，该函数在文件映射的内存发生缺页时用于一种优化策略，其作用是预取(prefetch)附近的页面，以减少未来可能的缺页。这个优化策略基于以下假设:

• 文件访问通常具有局部性(locality): 即如果一个页面被访问，那么附近的页面可能在不久的将来也会被访问。这是因为文件通常以较小的块进行读取，而不是逐个字节或逐个页面
• 文件映射的内存通常是按顺序或近似顺序访问的

CRAMFS 文件系统对于 FAULT-AROUND 机制提供了 filemap_map_pages(vmf->vma->v-m_ops->map_pages) 函数来预读文件, 该函数是通用的文件预读操作，其主要任务就是未相邻的虚拟内存提前建立映射到相应 PAGECACHE 的页表，注意这里不是从磁盘读取内容，而是建立页表. FAULT AROUND 直接返回 VM_FAULT_NOPAGE，那么缺页异常函数可以直接完成. 接下来进程访问相邻的虚拟内存不会发生缺页.