实际限制btrfs快照的数量？

我正在考虑在数据驱动器上使用btrfs，以便可以使用snapper或诸如snapper之类的功能来进行基于时间的快照。我相信这将使我能够浏览数据的旧版本。这是我当前的异地备份的补充，因为驱动器故障会清除数据和快照。

据我了解，btrfs快照不会占用太多空间（元数据和已更改的块，再加上一些开销），因此空间似乎不是一个约束。

如果我有一百万个快照（例如，两年每分钟快照），假设我有足够的磁盘空间来存储数据，更改的数据和元数据，那会造成严重破坏吗？

如果快照数量有实际限制，是否取决于文件数量和/或文件大小？

作为使用btrfs文件系统Arch Linux已有近2几年时间的人，我可以放心地说，似乎可以轻松实现的快照数量没有实际限制。虽然有一些警告。btrfs文件系统可能导致碎片。因此，建议使用内置的在线碎片整理功能btrfs。此外，可以充分利用btrfs的压缩功能。这些措施应解决大多数合理的性能问题，这些问题可能在合理的体面的计算机上由于创建大量快照而出现。

如您所知，btrfs将子卷视为文件系统，因此快照的数量确实受到限制：即受文件大小的限制。根据 btrfsWiki，可以达到的最大文件大小为2^64 byte == 16 EiB^[1]。

除了这些限制之外，如果空间用完了而又没有立即意识到，则可能总会出现问题，因为检查btrfs文件系统上的可用空间有时会很棘手，即无法区分测量btrfs文件系统上可用空间的不同方法。轻松使用实际剩余空间量的跟踪。防止出现这种情况的一种可能方法是使用配额。这样可以确保用户（如果只有一个，则该用户）只能使用一定数量的空间。这个概念在这里和这里都进行了很好的讨论。

最后但并非最不重要的一个警告：我不是btrfs文件系统专家，只有当我不久前有相同问题时才阅读这些内容。此外，始终存在一个问题，btrfs即“快速移动的目标”（Arch Linux我认为从wiki页面上窃取了不错的措辞。）因此情况可能会发生变化。

从技术上讲，快照数量没有限制，但我在BTRFS邮件列表中询问：

（实用的）答案在某种程度上取决于您使用btrfs的方式。

由于快照太多，Btrfs确实存在伸缩问题（或者实际上使用快照的reflinks，使用reflink的dedup可能会触发相同的伸缩问题），因此，强烈建议每个快照子卷的快照位数到低两位数仍然是强烈的建议。

但是扩展问题主要影响btrfs维护命令本身，平衡，检查，子卷删除。虽然数百万个快照将使例如平衡实际上无法工作（虽然可以完成工作，但可能要花费数月），但是正常的文件系统操作（如读取和保存文件）不会受到影响，除非碎片成为问题（注意文件系统（例如btrfs）存在碎片，除非采取碎片整理之类的步骤来减少碎片）。

使用快照作为类似于时间机器/快照程序的存档备份似乎不是一个好主意。

您可以总共包含2 ^64个快照和子卷。

该btrfs设计wiki页面说（empahsis矿）：

子卷基本上是一个名为btree的文件和目录。它们在树的根目录树中具有inode，并且可以具有非根目录所有者和组。可以为子卷分配一定的块配额，一旦达到该配额，就不允许进行新的写操作。子卷内的所有块和文件扩展盘都经过引用计数，以允许快照。FS上最多可以创建2 ⁶⁴个子卷。

快照与子卷相同，但是快照的根块最初与另一个子卷共享。拍摄快照时，根块上的引用计数将增加，并且写时复制事务系统可确保在快照或源子卷中所做的更改对该根是私有的。快照是可写的，并且可以多次快照。如果需要只读快照，则在创建时将其块配额设置为一个。