Skip to content

Latest commit

 

History

History
51 lines (26 loc) · 2.31 KB

3.18 提议.md

File metadata and controls

51 lines (26 loc) · 2.31 KB
Raw

  • 对 GDBFS 做修改

    • 目前的 GDBFS 的 fuse 只是自动把对文件的操作转发到数据库上
    • 他们的架构是：本地有一个永久文件夹 A 用来存所有文件
      • 挂载 FUSE 的时候，另一个文件夹 B 会镜像 A 文件夹的文件
      • 同时，对 B 的所有操作会触发数据库更新
      • 他们把 FUSE 用成了 hook……

  • 想法1：让图结构反映实际的目录结构

  • 想法2：让目录结构反映图结构。不知道 FUSE 框架能不能实现

    • 如果不能实现，那就魔改 FUSE（确信
    • 隔壁 git 已经被做成 FUSE 了，这个或许也行。
    • 一些初步想法：比如弄一些不能被列出，但能进入的文件夹，用这些文件夹实现图链接。

What

图文件系统。以图的形式组织文件关系。

Why

In my experience, when one presents a model and then finds it necessary to “hack” the model to be usable, it suggests that maybe the model is wrong – or at least not optimal.

问题：我们开始使用 “链接” 和各种索引来在文件系统中跳转。这说明纯粹的树形结构可能并不是文件系统的最好选择。

How

前几年 OSH 关于图文件系统的项目基本实现了与 “图” 相关的工作。我希望在图文件系统与传统树形文件系统之间架起桥梁，建立某种映射关系。

重点：

  1. 兼容性。我们希望整个文件系统在两种视角下都能合理有效地工作。

  2. 功能性。现有的图文件系统都只是在传统文件系统的组织形式基础上又套一层图数据库系统。传统文件系统适应于树形结构，通常会提供一些只有树形结构才能使用的功能，例如 文件夹权限/加密、软硬链接、文件夹透明压缩 等。如果我们能兼容树形结构，则这些功能都可以派上用场。

  3. 效率。图文件系统不能只停留在概念和 demo 阶段。效率问题可能出在两方面，

    1. 图数据库的计算和更新。做 index，hash。提供接口，通用？
    2. 文件系统本身的效率。例如 FUSE 在极端情况下速度会大幅降低

    这些都可以优化。

    其实还可以考虑定制一下底层的文件系统。毕竟把喷气机翅膀粘在拖拉机上肯定是飞不起来的。这个还需要确定性能瓶颈。