我们正在进行基于HMDFS的端侧互联批量小文件共享吞吐优化的项目。

经过前期通用读写测试并结合SmartPerf工具分析，我们发现HMDFS在进行跨设备文件共享时，总是需要通知文件所有者设备，以获取文件最新的元数据并在所有者端维护文件的打开信息。然而，我们发现组网设备（RK3568）间的RTT较高，对于读多写少的共享场景，每次读取都需要与文件所有者进行交互的开销太高。

基于小文件共享的特点，我们实现了两点优化：一是open-read一体操作，二是由文件所有者主动推送更新。Open-read一体操作充分考虑了小文件的大小（<1KB），在open时直接预取文件的第一个页（对于小文件而言这已经是全部的文件内容），以减少一次round-trip。文件所有者主动推送更新则是当文件内容发生修改时，主动向所有曾经访问过该文件的设备发起本地页缓存失效请求。对于非该文件持有者的设备，只要未收到失效该文件页缓存的请求，则在页缓存未被内核驱逐时均可以直接访问，而不必与文件所有者进行交互。

我们对实现进行了micro/macrobench mark。

Microbench mark中，我们在分布式文件路径下创建了不同数量大小为1K的测试文件，测试了不同线程数下对文件进行一次访问和多次访问的吞吐，结果如下图：


Macrobench mark中，我们使用了filebench的fileserver和webserver两个workload进行测试，两者的读写比分别为1:2和10:1，注意写占比高对我们的优化是不友好的。对于同一组网环境下的RK3568开发板A、B，首先在设备B上运行workload，执行完成后再在设备A上启动相同的workload，则设备A会复用设备B上已有的数据，从而达到测试跨设备文件访问性能的目的。在运行fileserver测试时，为了避免网络抖动带来的影响，我们将设备直接通过网线进行连接。以下是两个workload测试的结果，其中5.0.1_local与5.0.1_remote分别指在OpenHarmony-5.0.1-Release原始系统测试下设备B和设备A的吞吐，5.0.1_modified_remote指系统优化后设备A所测吞吐：


目前我们仅实现了针对小文件只读情况下的优化，而对于大文件、文件权限等元数据修改时访问模式的变化等情况还未涉及，且当前的实现直接修改了remote-open的路径，其实际上只考虑了小文件读写的情况。提出该PR是期待获取社区对于目前实现的意见建议，我们将根据意见进行修改以期合入主线。对于未实现的部分，如大文件的处理，我们的备选策略有：1、增加config-flag以决定是否启用该优化；2、通过文件size决定是否使用优化；3、扩展open时的flag，以确定是否启用优化。此外，也期待社区指出当前实现未考虑的corner-case，我们将一一进行修改和实现。