[oscamp 2025A]周雨工作进展

[Dirinkbottle]

Rust 重写 lwext4 项目周报

本周工作总结

时间周期： 2025年11月19日 - 2025年11月21日

已完成内容

• 构建 ext4 基本数据结构

  • 实现了 ext4 文件系统的核心数据结构
  • 包括超级块、inode、目录项等关键结构体

• 重写数学工具和计算工具

  • 实现了 ext4 特有的计算函数
  • 包括块计算、位图操作等核心算法

• 编写全面的单元测试

  • 为基础功能编写了大量单元测试
  • 确保数据结构和计算工具的稳定性
  • 测试覆盖率达到预期标准

下周工作计划

时间周期： 2025年11月22日 - 2025年11月26日

计划完成的核心功能

• 磁盘读写功能

  • 实现块设备的读取接口
  • 实现块设备的写入接口
  • 确保数据持久化的正确性

• 块缓存功能

  • 实现块缓存机制提升性能
  • 保证缓存一致性

项目目标

• 性能提升：通过 Rust 原生实现替代 FFI 接口
• 稳定性增强：利用 Rust 的内存安全特性
• 功能完整性：保留所有原有 lwext4 的功能

[Dirinkbottle]

本周工作进展

这是第一次重写文件系统，经验有所不足。发现自己之前一直是在机械的翻译每一行代码。rust的高级特性没有用上，导致写出一个c味特浓的文件系统，我吸取了这次的教训。
我决定用rust和自己的方式先写出ext2，再扩展到ext4 。
同时在之前的重写的过程中也发现原来的lwext4有一个fcl获取的bug。在磁盘大小超过16TB时会触发，导致位截断随机覆盖磁盘块。pr如下gkostka/lwext4#88

[Dirinkbottle]

第三周工作进展

已完成的工作

1. 实现了基本的上层 ext4 API

   • 文件创建
   • 文件追加
   • 文件夹创建
   • 读文件

2. 实现了 extent 树

   • 优化了文件逻辑块寻找时的性能
   • 提高了文件操作的效率

功能测试

测试代码

mkdir(&mut block_Dev, fs, "/test_dir/");

let mut tmp_buffer: [u8; 9000] = [b'R'; 9000];

let test_str = "Hello ext4 rust!".as_bytes();

tmp_buffer[8999] = b'L';

mkfile(&mut block_Dev, fs, "//test_dir/testfile", Some(&tmp_buffer));

mkfile(&mut block_Dev, fs, "//test_dir/testfile2", Some(&test_str));

let data = read_file(&mut block_Dev, fs, "//test_dir/testfile2").unwrap().unwrap();

let string = String::from_utf8(data).unwrap();

error!("read: {}", string);

### 测试结果
[rustsbi] Implementation     : RustSBI-QEMU Version 0.2.0-alpha.2

[rustsbi] Platform Name      : riscv-virtio,qemu

[rustsbi] Platform SMP       : 1

[rustsbi] Platform Memory    : 0x80000000..0x88000000

[rustsbi] Boot HART          : 0

[rustsbi] Device Tree Region : 0x87000000..0x87000ef2

[rustsbi] Firmware Address   : 0x80000000

[rustsbi] Supervisor Address : 0x80200000

[rustsbi] pmp01: 0x00000000..0x80000000 (-wr)

[rustsbi] pmp02: 0x80000000..0x80200000 (---)

[rustsbi] pmp03: 0x80200000..0x88000000 (xwr)

[rustsbi] pmp04: 0x88000000..0x00000000 (-wr)

[ERROR] read: Hello ext4 rust!

尚未完成的工作,下周的工作

1. 日志系统

   • 文件系统事务日志
   • 崩溃恢复机制
   • 性能优化

2. Starrtos 集成与测试

   • 与 Starrtos 操作系统集成
   • 性能基准测试
   • 稳定性测试

[Dirinkbottle]

2025.12.8-2025.12.10工作总结

1.这三天通过和老师协作完成了ext4的hashtree功能,加速了目录文件的查找速度。

2.支持ordered模式的journal日志系统。

• 支持基本的元数据事物提交和回放功能
• 实现细节。通过对块设备进行包装来全盘代理ext4的写块请求，根据数据类型进行提交事物。Journal功能可以在文件系统支持的基础上动态启用。

不足和bug：

文件/文件夹的创建的边界处理还不到位。ext4的一些不常用的feature没有实现。
文件超过4g会崩盘(开发之初随意使用类型转换导致截断)

本周剩下的几天主要重心倾向于与Starryos的对接。
bug修复与细节打磨

[Dirinkbottle]

2025.12.12-2025.12.14工作总结

1.这三天主要是在实现高层api和优化性能。其次是接入starryos进行测试

不足和bug：

目前还不支持超过4G的文件读写（很快会实现，由于大量随意使用as来截断导致的）
还有truncate,symbollink等少量api未实现，导致报大量io error(已测试)

接下来2天将会修复和完成以上内容。并且进行大量测试，确保rsext4代码健壮. 然后就开始着手开始新的task

[Dirinkbottle]

2025.12.15日工作总结

1.今天将rsext4接入starryos进行了测试。

测试结果

vim安装:成功
gcc安装:成功
jouranl测试:失败 原因：rsext4后端的journal进行replay时会回放脏日志导致污染元数据造成崩盘。

性能优化

在read_at 和write_at 的api进行offset预计算，仅取出部分extend来提升读写速度。
目前rsext4的体验和lwext4无明显延迟差距。

问题

rsext4采用多缓存来减少io操作，延迟落盘。由此引发问题，如果中途断电，内存缓存丢失->journal事务没有提交->文件丢失。

下一步计划

明天将会修复journal的旧日志处理问题，继续优化读写性能。在Starryos增加新的定时任务框架，新增journal进程，在io空闲时周期性把内存缓存flush进journal/主磁盘中。

[Dirinkbottle]

2025.12.16-2025.12.18日工作总结

• 1.修复ordered模式下的journal日志功能，现在可以稳定使用
• 2.修掉了truncate导致readat/writeat/空洞崩溃的错误
• 3.largefile支持
• 4.大端序设备支持。

今日已提交pr到arceos仓库,接下来转战x86平台的驱动完善任务，将结合完成“Rust 全栈部署 AI 训练营”的任务3：libuvc获取视频流，送入rknn推理框架进行推理识别目标（没有rk3588板子，用其它推理框架代替），然后操作uart端口控制机械臂（由于没有机械臂，会模拟操作）

[Dirinkbottle]

在项目阶段基于改进文件系统选题的工作总结

根据linux标准使用RUST实现了轻量的ext4的文件系统(rsext4)，为StarryOS的文件系统选择提供了新的选择。
目前rsext4已经能成功在StarryOS上成功运行。
rsext4仓库已经transfer到starryos组织下

• 仓库链接:https://github.com/Starry-OS/rsext4