我想知道将内存中的树结构存储为目录树以实现持久性的可行性。在我的情况下，目标文件系统将是ZFS，一旦创建了结构，多个进程将很少访问它
使用目录树作为数据树的持久性机制的性能如何
为了读取和写入树，您将在每个节点上多次调用文件系统。这比你设计的任何一个正常的代码都要昂贵得多。
这是否是一种明智的方法取决于您的使用模式。如果在一个典型的代码调用中，您希望读取整个树结构，请对其进行处理，然后完整地写出它-您最好将其整理成一个文件。然而，如果您希望只读取/处理/变异几个节点，而不在树的大部分中读取，则遍历目录结构和执行多次查找/读取以遍历存储在单个文件中的树之间的性能差异将小得多，而且为了简单/清晰/避免重新发明轮子，很可能值得执行前者。此外，如果多个进程同时执行此操作，则使用基于目录的方法锁定节点和子树会变得容易得多。
请注意，对于一些常用的文件系统，打开目录条目的时间取决于目录中的条目总数。
编辑：我用ext3为一个网站的CGI后端做过类似的事情；没有重新发明轮子使原型制作更快，维护更简单，读/写/锁定扩展得很好，但对目录结构本身的频繁更改（每秒数百次）在实际存储中效果不佳；最后，我重新构建了一些东西，这样目录树中经常添加/删除目录项的部分最终会出现在tmpfs卷上——对我来说，这组状态可以（昂贵地）在重新启动后从存储在不太易失性存储中的状态重建。我对ZFS没有什么经验，也不知道你想要的使用模式，所以不知道这是否会给你带来问题。如果我现在这样做是为了一个使用量很大的网站，我可能会推出我自己的命名锁库。
大多数文件系统都针对访问打开的文件进行了优化，因此打开/关闭文件需要花费大量时间。如果你的树的每一片叶子都很小，那么阅读/书写整个结构所需的时间会比必要的时间长很多倍。
此外，大多数文件系统都有一个最小的分配块，通常在2-8KB左右。如果你的叶子比这个小得多，你会浪费很多空间。
简而言之，你的叶子越小，这个想法就越糟糕。
如果我理解正确的话，你说的是构建一个树结构，它将提供文件系统的代码内表示，所以我怀疑在开始读取树结构时会产生开销，但随后对树的查找和遍历可能比每次访问磁盘存储更快。
可能的问题：
- 它可能会低效地使用磁盘空间（在许多文件系统中，目录是一个文件，因此会占用磁盘上的整个块…）
- 读取/写入速度会很慢，因为您进行了多次文件系统访问
- 文件系统可能/将对每个项目名称的长度和/或可用于名称的字符进行限制
- 其他进程很容易损坏您的数据和/或需要相当大的锁定成本
- 当使用固态"磁盘"时，与其他方法相比，这可能会导致更多的写入，并缩短介质的寿命
一句话：这可能不值得。