btrfs 快照數量的實際限制？
我正在考慮在我的數據驅動器上使用 btrfs，以便我可以使用snapper或類似 snapper 的東西來拍攝基於時間的快照。我相信這會讓我瀏覽舊版本的數據。這將是我目前異地備份的補充，因為驅動器故障會清除數據和快照。
據我了解，btrfs 快照不會佔用太多空間（元數據和已更改的塊，可能還有一些成本），因此空間似乎不是限制。
如果我有一百萬個快照（例如，兩年內每分鐘一個快照），假設我有足夠的磁碟空間儲存數據、更改的數據和元數據，那會造成嚴重破壞嗎？
如果快照數量有實際限制，它是否取決於文件數量和/或文件大小？
雖然從技術上講，快照的數量沒有限制，但我在BTRFS 郵件列表中詢問：
（實際）答案在某種程度上取決於您如何使用 btrfs。
由於快照太多，Btrfs 確實存在擴展問題（或者實際上使用 reflink 快照使用，使用 reflink 進行重複數據刪除可能會觸發相同的擴展問題），並且每個快照子卷的單個到低兩位數的快照仍然是強烈推薦的原因。
但是縮放問題主要影響 btrfs 維護命令本身，平衡、檢查、子卷刪除。雖然數以百萬計的快照將使平衡變得不可行（它會有點工作但可能需要幾個月的時間），但正常的文件系統操作（如讀取和保存文件）不會受到影響，除非碎片成為一個問題（諸如 btrfs 之類的牛文件系統會出現碎片，除非採取諸如碎片整理之類的步驟來減少碎片）。
使用快照作為類似於時間機器/快照程序的存檔備份似乎不是一個好主意。
作為一個使用
btrfs文件系統Arch Linux近2幾年的人，我可以肯定地說，對於可以輕鬆達到的快照數量似乎沒有實際限制。不過有一些警告。btrfs文件系統會導致碎片。因此，建議使用內置的線上碎片整理功能btrfs。此外，可以很好地利用btrfs’ 的壓縮功能。這些措施應該解決大多數性能問題，這些問題可能會在相當不錯的電腦上因創建大量快照而明顯出現。您可能知道
btrfs將子卷視為文件系統，因此快照的數量確實是有限的：即文件的大小。根據btrfswiki，可以達到的最大文件大小是2^64 byte == 16 EiB$$ 1 $$.除了這些限制之外，當您在沒有立即意識到的情況下用完空間時，可能總是會出現問題，因為檢查
btrfs文件系統上的可用空間有時會很棘手，即無法區分測量btrfs文件系統上可用空間的不同方法。輕鬆跟踪實際剩餘的空間量。防止這種情況的一種可能方法是使用配額。這確保了使用者（或只有一個使用者）只能使用一定數量的空間。這個概念在這里和這裡都得到了很好的討論。最後但並非最不重要的警告：我不是
btrfs文件系統方面的專家，只是在不久前遇到同樣的問題時才閱讀這些內容。此外，總是存在btrfs“快速移動目標”的問題（Arch Linux我認為從 wiki 頁面上竊取了很好的措辭。）所以事情可能會改變。