Практический предел на количество снимков btrfs?
Si bien técnicamente no hay límite en la cantidad de instantáneas, pregunté en la lista de correo BTRFS:
The (practical) answer depends to some extent on how you use btrfs.
Btrfs does have scaling issues due to too many snapshots (or actually the reflinks snapshots use, dedup using reflinks can trigger the same scaling issues), and single to low double-digits of snapshots per snapshotted subvolume remains the strong recommendation for that reason.
But the scaling issues primarily affect btrfs maintenance commands themselves, balance, check, subvolume delete. While millions of snapshots will make balance for example effectively unworkable (it'll sort of work but could take months), normal filesystem operations like reading and saving files doesn't tend to be affected, except to the extent that fragmentation becomes an issue (tho cow filesystems such as btrfs are noted for fragmentation, unless steps like defrag are taken to reduce it).
Parece que usar instantáneas como una copia de seguridad de archivo similar a Time Machine/Snapper no es una buena idea.
Как человек, использующий файловую систему btrfs с Arch Linux уже почти 2 лет, я могу с уверенностью сказать, что, похоже, практического ограничение на количество снимков, которые могут быть легко доступны. Однако есть некоторые предостережения. Файловая система btrfs может привести к фрагментации. Поэтому рекомендуется использовать функцию оперативной дефрагментации, встроенную в btrfs . Кроме того, можно хорошо использовать функцию сжатия btrfs . Эти меры должны решить большинство проблем с производительностью, которые могут возникнуть на достаточно приличном компьютере из-за создания большого количества снимков.
Как вы, возможно, знаете, btrfs рассматривает подтомы как файловые системы, и, следовательно, количество снимков действительно ограничено: а именно размером файлов. Согласно btrfs вики, максимальный размер файла, который может быть достигнут, составляет 2 ^ 64 байта == 16 EiB [1].
Помимо этих ограничений, потенциально всегда могут возникнуть проблемы, когда у вас заканчивается свободное место без вашего немедленного распознавания, потому что проверка свободного места в файловых системах btrfs иногда может быть сложной, т. Е. Без возможности различать разные методы измерения свободного места в файловой системе btrfs можно легко использовать отслеживание того, сколько места фактически осталось. Один из возможных способов предотвратить этот сценарий - использование квоты. Это гарантирует, что пользователи (или пользователь, если он только один) могут использовать только определенный объем пространства. Эта концепция очень умело обсуждается здесь , а также здесь .
И последнее, но не менее важное предупреждение: я не являюсь экспертом по файловым системам btrfs и читал об этом только тогда, когда недавно у меня возник тот же вопрос. Более того, всегда существует проблема, что btrfs является «быстро движущейся целью» (я думаю, хорошая формулировка украдена с вики-страницы Arch Linux ), поэтому все может измениться.
У вас может быть в общей сложности 264 моментальных снимка и субтома.
На вики-странице btrfs design говорится (empahsis мой):
Подтома - это, по сути, именованное btree, в котором хранятся файлы и каталоги. Они имеют inodes внутри дерева корней дерева и могут иметь некорневых владельцев и группы. Подтомам может быть назначена квота блоков, и по достижении этой квоты новые записи запрещены. Все блоки и экстенты файлов внутри подтомов подсчитываются по ссылкам, чтобы обеспечить возможность создания моментальных снимков. На ФС может быть создано до 264 подтомов.
Снимки идентичны субтомам, но их корневой блок изначально разделяется с другим субтомом. Когда делается моментальный снимок, количество ссылок на корневой блок увеличивается, а система транзакций copy on write гарантирует, что изменения, сделанные либо в моментальном снимке, либо в исходном подтоме, являются приватными для этого корня. Снимки доступны для записи, и их можно создавать повторно любое количество раз. Если нужны снимки только для чтения, квота блоков для них устанавливается равной единице во время создания.