一些文件系统（尤其是 XFS 和 btrfs）支持文件块级别的写入时复制。这是通过重新链接在文件之间共享底层块直到它们被修改来完成的。
由于目录本质上是将文件名映射到 inode 的关联数组对目录做类似的事情应该很简单。
是否已开发出可以在 Linux（或任何其他类 Unix 系统）上支持此功能的文件系统？
据推测，它需要内核支持，就像使用重新链接一样。这是一个像这样的调用复制文件范围() 适用于目录。
有人积极致力于此吗？仅仅是因为还没有人愿意这样做，还是有任何理由说明这是一个坏主意或不必要的？
是否有任何需要克服的特定技术障碍？
也可以看看https://serverfault.com/questions/129969/is-there-a-way-to-create-a-copy-on-write-copy-of-a-directory 这并没有真正回答这个问题。
答案1
是否有任何需要克服的特定技术障碍？
一大障碍是语义上的差异。复制目录（在目标尚不存在的情况下）会生成其所有内容的副本，以及指向所有这些内容的新目录。特别是，这意味着虽然源目录和目标目录最终包含相同的名称，但每个名称的目标 inode 是不同的。
如果您以与克隆文件相同的方式克隆目录，则最终会得到两个目录，其内容指向相同的索引节点 - 实际上，您正在创建一个包含指向原始目录内容的硬链接的目录。这不适用于目录，并且它为文件创建了令人惊讶的语义 - 克隆dira包含file, as dirb，意味着编辑dirb/file也将编辑dira/file，这可能不是最初的意图。
因此，这意味着目录副本的共享存储在一般情况下不起作用，并且仅在少数情况下有用。
copy_file_range和FICLONE ioctl的s但是，不要假设底层存储将被共享。它们是“内核，请复制此（部分）文件”形式的请求；它们的优点是可以共享存储，而且委托复制比读取和写入更有效。例如，在网络文件系统上，克隆可以在服务器上处理，这比客户端驱动的副本要高效得多。将这种推理应用于目录副本，而不必共享底层存储，可能会很有用。
即使在有用的场景中，内核操作的实现和使用也会很复杂。
文件克隆操作需要处理单个文件，最初位于单个文件系统中。即便如此，跨多个文件系统处理副本的扩展也copy_file_range导致了一些问题。
目录的“克隆”操作会复杂得多。复制目录不仅涉及复制目录本身（IE文件名到 inode 的映射），还有目录的内容。正如已经提到的，您不能只是硬链接文件，语义会有所不同；即使这是一个可以接受的简化，您仍然需要处理无法硬链接的条目，例如您尝试克隆的目录中的目录。然后我们就得到了挂载点，“乐趣”的程度就大大提高了。当然，所有这些都是在处理权限时进行的。
假设有人实现了所有这些，那么您需要更新相关的用户空间程序以使用新操作，并使用现有代码作为后备。与单文件克隆不同，语义相当不同，并且在所有情况下拼接新函数可能并不容易。生成的文件系统语义也不同（可以说，如果是的话，可以在不破坏世界的情况下更改这些语义）值得——参见relatime和noatime）。
可能还有其他我还没有想到的障碍；但第一个表明目录实际上几乎没有机会共享存储。