Практичне обмеження кількості знімків btrfs?

Я розглядаю можливість використання btrfs на своєму накопичувачі даних, щоб я міг використовувати snapper або щось на зразок snapper, щоб зробити знімки на основі часу. Вважаю, що це дозволить мені переглядати старі версії моїх даних. Це було б доповненням до моєї поточної резервної копії сайту, оскільки несправність диска знищить дані та знімки.

З мого розуміння, знімки btrfs не займають багато місця (метадані та блоки, які змінилися, а може бути і деякі накладні витрати), тому простір не здається обмеженням.

Якщо у мене мільйон знімків (наприклад, знімок щохвилини протягом двох років), це спричинило б загрозу, якщо припустити, що у мене є достатньо місця на диску для даних, змінених даних та метаданих?

Якщо існує практичне обмеження кількості знімків, чи це залежить від кількості файлів та / або розміру файлів?

Як хтось, хто вже майже роки використовує btrfsфайлову систему, я сміливо можу сказати, що практично не існує практичного обмеження щодо кількості знімків, до яких можна легко дістатися. Однак є деякі застереження. файлова система може призвести до фрагментації. Тому доцільно використовувати вбудовану в Інтернет функцію дефрагментації . Крім того, можна добре використовувати функцію стиснення. Ці заходи повинні вирішувати більшість питань, що стосуються продуктивності, які можуть спричинитися на досить пристойному комп’ютері, створивши багато знімків.Arch Linux2btrfsbtrfsbtrfs

Як ви можете знати, btrfsтрактує підтомники як файлові системи, а отже, кількість знімків дійсно обмежена: а саме розміром файлів. Відповідно до btrfsвікі, максимальний розмір файлів, який можна досягти, є 2^64 byte == 16 EiB^[1] .

Крім цих обмежень, потенційно завжди можуть виникнути проблеми, коли у вас не вистачає місця, не одразу визнавши, тому що перевірка вільного місця у btrfsфайлових системах іноді може бути складною, тобто без можливості розмежувати різні методи вимірювання вільного простору у btrfsфайловій системі. легко використовувати відстеження, яка кількість місця фактично залишилася. Один із можливих способів запобігти цьому сценарію - використання квоти. Це гарантує, що користувачі (або користувач, якщо він лише один) можуть використовувати лише певну кількість місця. Ця концепція обговорюється дуже спритно тут і тут .

І останнє, але не менш важливе застереження: я не фахівець з btrfsфайлових систем, і читав про ці речі лише тоді, коли у мене було те саме запитання. Крім того, завжди є проблема, що btrfsце "швидка рухається ціль" (приємне формулювання викрадено зі Arch Linuxсторінки вікі, я думаю.), Щоб все змінилося.

Хоча технічно немає кількості знімків, я запитав у списку розсилки BTRFS :

(Практична) відповідь певною мірою залежить від того, як ви використовуєте btrfs.

У Btrfs виникають проблеми зі масштабуванням через занадто багато знімків (або насправді використовуються знімки з рефлінками, дедупція за допомогою посилань може викликати ті ж проблеми масштабування), і одноразові до низьких двозначних знімків за знімком підпункту залишаються настійною рекомендацією з цієї причини.

Але проблеми масштабування в першу чергу стосуються самих команд технічного обслуговування btrfs, балансування, перевірки, видалення підтомника. Хоча мільйони знімків дозволять зробити баланс, наприклад, ефективно непрацездатним (це може працювати, але це може зайняти місяці), звичайні операції з файловою системою, такі як читання та збереження файлів, не мають впливу, за винятком того, що фрагментація стає проблемою ( файлові системи файлів корови, такі як btrfs, відзначаються для фрагментації, якщо не буде вжито таких кроків, як дефрагментація для її зменшення).

Схоже, використання знімків як архівної резервної копії, подібної до машини часу / оснастки, не є хорошою ідеєю.

Ви можете мати загальну кількість 2 ⁶⁴ знімків та підпунктів.

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

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

Знімки збігаються з підтомниками , але їх кореневий блок спочатку ділиться з іншим підпунктом. Коли зроблено знімок, кількість посилань на кореневий блок збільшується, а система транзакцій копіювання при записі забезпечує зміни, внесені або до знімка, або до підпункту джерела, приватного цього кореня. Знімки можна записати, і вони можуть бути зроблені знову, будь-яку кількість разів. Якщо потрібні лише знімки для читання, їх блокова квота встановлюється на момент створення.