架空的的理想文件系统设计,又名:如果穿越回 1970 年,你该怎么设计文件系统

2016-08-29 19:03:39 +08:00
 schezukNewTos

你有没有遇到过如下的困扰?

这些不是你的错,是文件系统设计的错。

文件系统的设计在不断发展之中,以适应新的硬件带给我们的更多可能性空间。
以 M$为例,从最早把所有文件都存在根目录下的 8-bit FAT,
到初次引入树状目录的 MS-DOS 2 ,到支持硬链接的 NTFS 。
文件组织理念逐渐进步——虽然早在 M$开始做任何操作系统之前这些就已经应用了。

传统的文件系统的思维是,储存文件的最近快照,并用目录树组织它、用文件名描述它。
这种静态僵化思维违反文件变动的本质,缺失重要的必需功能,不得不以外部应用补全。
文件的组织、查找、整理、版本维护、删除恢复,用户要么借助工具,要么掣肘于困难。

自 JFS 起引入了日志, WinFS 引入了标签(虽然成了先烈), APFS 引入了写入时复制。
这些都证明,传统的文件系统的思维,显露出的不灵活不适用的特点已经得到关注了。

让我们回到文件的本质吧:
文件是一段变化的数据,和对这一忒修斯之船的一组可变的描述。
任何设计若轻视文件的变化本质,静态看待其内容和描述,都会迫使用户持续陷入困扰。
(请读者联系亲身体验)。

版本标签概念进入到文件系统中,就像日志和软硬链接一样理所当然。
——虽然肯定有人为链接破坏了文件在目录树下唯一定位的特性而经历过困惑。
——那么这些人还会为不完全路径访问、副本的取消、复制概念的消失而惊讶。

一个理想的文件系统,他应当具有如下的特征:

这个架空的文件系统,其文件组织应当包括一下三个要素:
文件节点(inode),文件特征(meta),文件内容(content)。

文件节点是操作文件的独一凭据,是记录文件存在的根本标识。文件特征记载于此。
它使用链表记录文件的流变过程,链表上的每一个 hash 指向存储在硬盘上的一个版本。

文件内容是文件的数据本体,如文本,图片视频二进制数据, Office 文件,文件包……
写入打开一个文件创建一个新的文件内容,它暂存挂载在文件节点上,当写完则转正。
转正即哈希并提交到文件节点,文件内容按版本单独存放,互相不覆盖,同哈希则 GC 。
不同文件可绑定同一文件内容。需要压缩或者加密的,也在这一层次上进行操作。

文件内容根据可修改 IMMUTABLE 与可随机写入 Random-accessible 分为四类:
可修改、可随机写入:文本和某些二进制文件,行插入不影响有效性,需记录版本。
可修改、不可随机写入:日志文件,流媒体等,文件尾部不断追加,无需记录版本。
不可修改、可随机写入:数据库等等,由对应的应用自行管理写入,无需记录版本。
不可修改、不可随机写入:图像、媒体、文件包等,要么从不修改,要么记录版本。

文件特征全面取代目录树、文件名、文件权属和文件头,记录数据本体以外的信息。
它单独记录在链表上面。同时,创建、每次修改、删除,都同步到文件系统的索引上。
索引筛选取代目录访问,索引不能直接操作,通过操作特征来修改,用于按标签筛选。
文件元数据与文件内容独立,但是文件内容的可修改性、随机写入性、哈希是元数据。

文件的每一条元数据称为一个标签(tag),传统的文件夹代替以按标签筛选。
标签可以代替文件头:文件的每一条媒体信息都作为一条标签存储在文件元数据中。
标签可以代替文件名、扩展名、时间:同时取代了魔术字,文件头的标题、时间等等。
标签可以代替文件权属,文件权属应当同时精确到用户和应用,例: auth:usr1/app1 。
标签可以代替目录树:多数情况下重名文件分属不同用户应用,以文件权属代替。
标签必要的时候可以有多个级别,文件权属是用例之一,标签筛选也可以指定级别。

该文件系统采用与传统不同的一套 API 。随之而来的是完全不同的使用理念。
——尽管迫于历史包袱,可能仅限于理论讨论、思想实验,或作为一层虚拟界面层。
在计算机的早期采用固然好,但当时的硬件性能不足以支持,实在是很遗憾的事。

寻找文件通过提供一个标签字典或字符串,包含文件权属。返回一个文件节点号数组。
因为标签和历史版本消除了存储多个副本的必要,绝大多数情况只会有一个返回值。
万一有多个返回值意味着违背了这一设计哲学,用户可以添加标签区分、或合并副本。

访问文件通过文件节点号。返回记载标签和哈希的版本数组。有一个独特的暂存 API 。
读取文件读取指定哈希对应的文件内容,暂存文件创建一个可以写入的文件内容。
写入文件将暂存区转正,文件标签的修改也在此时保存到该文件节点的链表中。
本地不应当复制。用户 /计算机间可以创建副本,但授权应当改变。备份同理变更标签。
下载被抄送取代,接收方应当妥善接收标签,并作本地化,因为这是文件系统的一部分。


以上脑洞由 WinFS 、 APFS 、 Git 、 REST 等启发,可以视作无脑黑 Unix FS 和对 M$的吹捧。
作者本人,思虑不周。欢迎批评,谢勿转载。

4811 次点击
所在节点    程序员
44 条回复
soland
2016-08-30 15:51:57 +08:00
@schezukNewTos 不要把失败推到习惯惯性太大上面去,失败唯一的原因就是做的不够好,不能在实际使用中提供超越性的体验。
levn
2016-08-30 16:11:12 +08:00
……一般文件以物件逻辑处理就可以了
int64ago
2016-08-31 00:35:05 +08:00
1970 年有 Google 吗?
没有

那我写不出程序的
mokiki
2022-04-05 22:49:25 +08:00
我也来讨论一下。

我认为文件系统路径就是一种标签,路径比标签还多一点前后级的关系信息。比如 “音乐 /华语 /周杰伦” 中,这三个文件夹的名字都是标签。

我理想中的文件系统是本身提供多文件路径的,比如电影 头文字 D ,可以归类到 “电影 /华语 /周杰伦”和“电影 /飙车”里。

文件系统提供标签索引缓存加速,文件管理器提供高级搜索选择功能。比如我在文件管理器中输入周杰伦,文件管理器会显示周杰伦的歌曲和电影。而且文件管理器会在周杰伦前面显示“音乐 /华语” 和 “电影 /华语”,此时我点击音乐,文件列表中就只剩周杰伦的歌曲了。

其它功能,比如文件数据写入时文件系统要计算 hash 值,作为文件完整性保障,并让 IPFS 、syncthing 等同步共享软件可以直接用,免除重复计算。当然可能还要提供加密压缩功能。

我想问大家,如果在 Linux 下提供 posix 兼容需要怎么写这个文件系统驱动?

如果我想用 rust 开发,应该怎么开始?

请大家指教。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/302524

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX