这是我第一次敢于将 NAS 中的 18TB 磁盘格式化为 btrfs。因此，我有几个问题和担忧，希望我们的社区能够解答。
文件系统将通过客户端计算机上的 smbd 提供。这是否遗漏了 btrfs 的一些重要功能？（显然 root 可以通过 ssh 访问 NAS 来对 btrfs 文件系统进行操作）。
我听说它是一个版本控制文件系统。我想到了 Git。如果我删除了一个文件，我能 100% 成功地再次找到它吗？
我听说，即使所有文件的累计大小为 5TB，由于版本控制，18TB 的可用空间也会很快用完，并且需要 root 命令才能释放它（如果我理解正确的话，可能是压缩并删除以前的快照）。这适用吗？除了现在文件中的实际数据外，还有什么占用了大量空间？这个额外的东西包含什么信息？在空间有限的时候，完全删除与现在文件的实际数据无关的任何信息是否容易？
答案1
文件系统将通过客户端计算机上的 smbd 提供。这是否遗漏了 btrfs 的一些重要功能？（显然 root 可以通过 ssh 访问 NAS 来对 btrfs 文件系统进行操作）。
默认情况下，Btrfs 的功能与任何其他文件系统一样。它具有 SMB 服务器可能想要使用的功能，但这些功能是可选的。
例如，使用 Samba 时，您可能希望启用“btrfs”模块以便vfs objects =获得使用 reflinks 进行服务器端复制的支持（即客户端能够要求服务器将远程文件从一个文件夹复制到另一个文件夹，而无需下载并重新上传它们）。
Samba 还具有“snapper”和“shadow_copy”VFS 模块，用于与 Snapper 制作的 Btrfs 快照集成；它可以使它们在 Windows 客户端上显示为“以前的版本”（就像基于 Windows 的文件服务器上的卷影副本）。
我听说它是一个版本控制文件系统。我想到的是 Git。
在某些方面很相似，但实际上并不相同。
Btrfs 支持与 Git 提交类似的快照，但它并不打算保留所有版本的永久日志——过去的快照总是可以被删除以回收空间。（例如，可以将 Snapper 等工具配置为保留一个月的每日快照，但随着快照变旧，开始修剪它们。）
如果我删除了一个文件，我能 100% 成功地再次找到它吗？
仅当您仍有在删除该文件之前制作的早期快照时。
如果不再有对文件的引用，它就消失了——它的磁盘空间被“释放”并且可以重新使用，就像在任何其他文件系统上一样。
这类似于 Git 的行为，其中对象做如果不再有任何引用它们，则会进行垃圾收集（例如，当您修改提交时，旧的提交将有资格进行 GC；当您删除分支时，该分支所特有的所有提交和文件最终都会被 GC 并消失）。
我听说，即使所有文件的累计大小为 5TB，由于版本控制，18TB 的可用空间也会很快用完，并且需要 root 命令才能释放它（如果我理解正确的话，可能是压缩并删除以前的快照）。这适用吗？
默认情况下不会。除非您创建快照，否则不会保留旧版本的文件故意地。
尽管 Btrfs 是一个“写时复制”文件系统，其中对文件的每次更改都会分配新的空间（而不是就地覆盖文件），但这只是暂时的 - 一旦提交了新的写入，这些扇区的旧版本就会被遗忘，并且会回收相同数量的空间（除非之前的快照仍然保留对它的引用）。
因此，只有在以下情况下才会耗尽空间：1）频繁创建快照和2) 拥有在快照之间频繁更改的大文件（例如高度活跃的数据库或虚拟机，或删除后仍保留在旧快照中的下载）。不变文件的快照几乎不占用额外空间，而对非快照文件的更新会在存储新版本后立即释放以前使用的磁盘空间。
请注意，Btrfs 本身不会自动创建快照 - 您必须特意运行btrfs fi snap或设置 Snapper 或 Timeshift 等工具来实现这一点，因此这些工具也会负责自动删除旧快照（根据您设置的规则）。
话虽如此，Btrfs 的“写时复制”特性确实依赖于一些处理删除操作所需的可用空间量（因为这些操作需要写入新的元数据）。通常，Btrfs 会保留一定量的可用空间，以便您即使在容量达到 100% 的情况下仍可以删除内容，并且随着时间的推移，它在处理“无空间”情况方面已经做得更好，但从历史上看，它在达到 ENOSPC 后往往会陷入难以修复的状态。
此外，虽然 COW 不会占用空间，但它做缺点是频繁更新的文件（和元数据）的碎片化程度增加。换句话说，是的，Linux 上存在“磁盘碎片整理”。