Практическое ограничение на количество снимков btrfs?

Я рассматриваю возможность использования btrfs на моем диске с данными, чтобы я мог использовать snapper или что-то вроде snapper, чтобы делать моментальные снимки. Я верю, что это позволит мне просматривать старые версии моих данных. Это было бы в дополнение к моей текущей резервной копии вне сайта, так как сбой диска уничтожил бы данные и снимки.

Насколько я понимаю, снимки btrfs не занимают много места (метаданные и блоки, которые изменились, а также, возможно, некоторые накладные расходы), поэтому пространство не кажется ограничением.

Если у меня будет миллион снимков (например, снимок каждую минуту в течение двух лет), это вызовет хаос, если предположить, что у меня достаточно дискового пространства для данных, измененных данных и метаданных?

Если существует практическое ограничение на количество снимков, зависит ли оно от количества файлов и / или размера файлов?

Как человек, который использует btrfsфайловую систему Arch Linuxуже почти 2годы, я могу с уверенностью сказать, что практического ограничения на количество снимков, которые можно легко получить, не существует. Есть некоторые предостережения, хотя. btrfsФайловая система может привести к фрагментации. Поэтому рекомендуется использовать встроенную функцию онлайн-дефрагментации btrfs. Кроме того, можно эффективно использовать btrfsфункцию сжатия. Эти меры должны решить большинство проблем с производительностью, которые могут возникнуть на достаточно приличном компьютере при создании большого количества снимков.

Как вы, возможно, знаете, btrfsподобъемы рассматриваются как файловые системы, и, следовательно, количество снимков действительно ограничено, а именно размером файлов. Согласно btrfsвики максимальный размер файла, который может быть достигнут - 2^64 byte == 16 EiB^[1] .

Помимо этих ограничений, всегда могут быть проблемы, когда вы исчерпываете пространство без немедленного распознавания, потому что проверка свободного места в btrfsфайловых системах иногда может быть сложной, то есть без возможности различать различные методы измерения свободного пространства в btrfsфайловой системе, которые можно легко использовать трек, сколько места на самом деле осталось. Одним из возможных способов предотвращения этого сценария является использование квоты. Это гарантирует, что пользователи (или пользователь, если он только один) могут использовать только определенное количество пространства. Эта концепция очень умело обсуждается здесь и здесь .

Последнее, но не менее важное предупреждение: я не специалист по btrfsфайловым системам, и я читаю об этом только тогда, когда у меня был тот же вопрос некоторое время назад. Кроме того, всегда существует проблема, которая btrfsзаключается в «быстро движущейся цели» ( Arch Linuxя думаю, что на украденной вики-странице была украдена хорошая формулировка ), поэтому все может измениться.

Хотя технически нет ограничений на количество снимков, я спросил в списке рассылки BTRFS :

(Практический) ответ зависит в некоторой степени от того, как вы используете btrfs.

Btrfs имеет проблемы с масштабированием из-за слишком большого количества снимков (или на самом деле использование снимков reflink, дедупликация с помощью reflink может вызывать те же проблемы масштабирования), и сильная рекомендация по этой причине остается сильной рекомендацией по двойным цифрам снимков на единицу снимка.

Но проблемы масштабирования в первую очередь касаются самих команд обслуживания btrfs, баланса, проверки, удаления объема. Хотя миллионы снимков сделают баланс, например, фактически неработоспособным (это будет своего рода работа, но может занять месяцы), обычные операции файловой системы, такие как чтение и сохранение файлов, обычно не затрагиваются, за исключением случаев, когда фрагментация становится проблемой ( Файловые системы коровы, такие как btrfs, отмечаются как фрагментированные, если не предпринимаются такие шаги, как дефрагментация, чтобы уменьшить его).

Похоже, что использование моментальных снимков в качестве архивной резервной копии, похожей на машину времени / окуня, не очень хорошая идея.

Вы можете иметь в общей сложности 2 ⁶⁴ снимка и подобъема.

На btrfsвики-странице дизайна написано (empahsis my):

Подобъемы - это в основном именованное btree, которое содержит файлы и каталоги. Они имеют inode внутри дерева корней деревьев и могут иметь некорневых владельцев и группы. Субобъемам может быть назначена квота блоков, и как только эта квота будет достигнута, новые записи не будут разрешены. Все блоки и экстенты файла внутри подобъемов подсчитываются, чтобы сделать снимок. На ФС может быть создано до 2 ⁶⁴ субобъемов.

Снимки идентичны подобъемам , но их корневой блок изначально используется совместно с другим подобъемом. Когда снимок сделан, счетчик ссылок в корневом блоке увеличивается, и система транзакций копирования при записи гарантирует, что изменения, сделанные в моментальном снимке или в подобъеме источника, являются частными для этого корня. Снимки доступны для записи, и их можно снимать снова любое количество раз. Если нужны снимки только для чтения, их квота блока устанавливается на единицу во время создания.