往年实现分析

注重的地方

文档数量庞大。

文档中需要包含整个开发流程，需要列举并详细说明涉及到的技术要点和原理，以及配有丰富的示意图和代码段。

在这个队伍的文档实现中，很大部分是分析原版 UBIFS 的实现逻辑和代码理解，另外一部分有基于这些理解对技术进行的调研以及自己的实现逻辑。

总代码大。

去除重复文件后统计文件行数如下：

-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
C                               48           6044          12432          30124
C/C++ Header                    13            713           4033           4173
-------------------------------------------------------------------------------
SUM:                            61           6757          16465          34297
-------------------------------------------------------------------------------

看起来原版 UBIFS 的代码量就是很大，总大小有 1.5MiB，队伍自己的实现暂未统计。

从「智能」这一点出发。

PPT：
1. 『智能：针对不同的情况能够进行不同的处理，从而提升整体性能』
2. 『相较于ai，其只是低级层面的智能』
项目中「智能」的实现：
1. 通过判断文件名的方式来判断使用的压缩算法和参数，即压缩算法和等级的自适应
2. 通过检查压缩效果是否合适来判断是否继续压缩，压缩效果不好可能其数据本身就是压缩文件，则再次不压缩
3. 利用文件系统中的局部性
4. 在 Flash 后期容易产生错误的时候转用纠错能力更强的算法
5. 冷热数据判别
UBIFS 部分使用到了 Log-Structured 文件系统，即划分了一部分空间来给 Journal 做直接写入

可以改进的地方

联系题目，有没有没有做的点？
1. 纠删码（可以是联合信源信道编码）
2. 数据块选择、擦除策略
3. Cache 机制
测试、展示不够规范。
1. 演示视频中，不断切换测试脚本和开发环境，并通过切换分支的方式切换功能和版本。
  
  这样看视频的人很难看懂在做什么，看懂了也很难说明当前的设计有哪些提升。如果演示的时候就能直观地用自动化脚本生成测试报告，如表格、统计图等，会更加有表现力，更能说服评委。
2. 没有使用通用的测试脚本或者软件，而是选择自己写脚本测试，难以说明提升。
  
  测试中大部分测试使用 3~11MiB 大小的连续读写，或者直接使用上百 MiB 的大文件连续读写，这不仅不能说明问题，而且也没有解决实际问题。在复杂的文件读写环境中，大部分读写应该是 4KiB 随机读写，这在其他的文件系统论文中是最重要的指标之一，视频中没有体现。
测试环境不对。

既然是适用于 Flash 的文件系统，就应该统计和 Flash 相关的数据，从而衡量这个文件系统对 Flash 的稳定性、寿命、速度的综合影响，但是测试中只是在本机上进行了速度的测试，这难以说明问题。

我的提议是建立一个 Flash 仿真程序，真正计算在 Flash 中的读写频率、位置等信息，并模拟 Flash 芯片的具体延迟给出具体读写速度。

其次，对 Flash 芯片的检错、纠错测试也应该基于 Flash 仿真，而不是在内存中写入值。

⚠️可能能够仿真的只有裸 Flash 环境。
性能并不算非常优秀。

有些展示出来的功能点，还不如原版 UBIFS，不过优化的点看起来数据都不错。
纠错算法和 UBIFS 本身不太兼容。
如果实现机器学习层面的『智能』？
UBIFS 本身是 2009 年的论文，应该在此基础上也有更多的优化实现。
功能拓展
1. 与嵌入式功能结合：如果将内存的一部分放到 Flash 上做 Swap，能不能在文件系统层面做优化
2. 与 SSD 主控的功能结合：项目中没有实现 Trim 方案，即自动数据整理，我们可以针对这个功能点做实现。（如果是基于有 FTL 的 Flash，这个可能就做不到）
3. 与 SSD 算法结合：Flash 做块擦除更方便，能不能结合硬件信息做块擦除（仅裸 Flash？）
4. 更新的技术：
  1. 有没有更好的纠错码？SSD 内部一般用什么算法？适合软件模拟吗？
  2. 有没有能结合 CPU Cache 和 Flash Cache 的算法？怎么实现？
5. AI 怎么说：结合 SSD 主控原理分析本题的更多突破口
  1. 更好的垃圾回收算法：在 SSD 中，垃圾回收算法是一个非常重要的算法，可以考虑将 SSD 中的垃圾回收算法与 Flash 文件系统中的垃圾回收算法相结合，从而提高 Flash 文件系统的性能和稳定性。
  2. 更好的预测算法：在 SSD 中，预测算法可以帮助提高读取性能和减少读取延迟，可以考虑将预测算法与 Flash 文件系统中的读取算法相结合，从而提高 Flash 文件系统的读取性能和稳定性。
  3. 更好的写入算法：在 SSD 中，写入算法可以帮助提高写入性能和减少写入延迟，可以考虑将写入算法与 Flash 文件系统中的写入算法相结合，从而提高 Flash 文件系统的写入性能和稳定性。
  4. 更好的数据压缩算法：在 SSD 中，数据压缩算法可以帮助提高存储密度和减少读取和写入延迟，可以考虑将数据压缩算法与 Flash 文件系统中的数据压缩算法相结合，从而提高 Flash 文件系统的存储密度和稳定性。
  5. 更好的数据分配算法：在 SSD 中，数据分配算法可以帮助提高存储效率和减少写入延迟，可以考虑将数据分配算法与 Flash 文件系统中的数据分配算法相结合，从而提高 Flash 文件系统的存储效率和稳定性。
  6. 更好的**数据保护（安全性）**算法：在 SSD 中，数据保护算法可以帮助提高数据的安全性和可靠性，可以考虑将数据保护算法与 Flash 文件系统中的数据保护算法相结合，从而提高 Flash 文件系统的安全性和可靠性。
  7. 更好的**块管理（与实际硬件数据结合）**算法：在 SSD 中，块管理算法可以帮助提高存储效率和减少写入延迟，可以考虑将块管理算法与 Flash 文件系统中的块管理算法相结合，从而提高 Flash 文件系统的存储效率和稳定性。
  8. 更好的缓存算法：在 SSD 中，缓存算法可以帮助提高读取性能和减少读取延迟，可以考虑将缓存算法与 Flash 文件系统中的缓存算法相结合，从而提高 Flash 文件系统的读取性能和稳定性。
  9. 更好的并发算法：在 SSD 中，并发算法可以帮助提高存储效率和减少写入延迟，可以考虑将并发算法与 Flash 文件系统中的并发算法相结合，从而提高 Flash 文件系统的存储效率和稳定性。
  10. 更好的数据清理算法：在 SSD 中，数据清理算法可以帮助提高存储效率和减少写入延迟，可以考虑将数据清理算法与 Flash 文件系统中的数据清理算法相结合，从而提高 Flash 文件系统的存储效率和稳定性。
  嗯……比我想的周全。

AquaFS Docs

往年实现分析

往年实现分析