5

У меня очень большой внешний диск, который я хочу использовать для резервного копирования. Часть резервных копий предназначена для разделов Windows, которые должны быть доступны из Windows, часть - резервные копии некоторых разделов Linux.

Поскольку я не могу точно предсказать размеры хранилища, я подумал о создании нескольких разделов, начиная с одной NTFS и одной как ZFS. Если у меня не хватит места на диске в ZFS, я просто добавлю еще один запасной раздел в том ZFS. Если NTFS требуется больше места, я бы изменил его размер (или, если это невозможно, пересоздаю, но это означает повторное копирование всех данных).

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

ОБНОВЛЕНИЕ: я смонтировал весь диск как зашифрованный петлевой том, используя cryptsetup . Затем я создал на нем огромную файловую систему ZFS. Если я установлю copies=2 , это тоже заканчивается поиском-адом, или есть какой-то умный механизм ZFS, который будет хранить копии всех файлов на одном диске с использованием буфера [предположение: тоже искать ад + только одна копия, потому что вам понадобится несколько устройств для нескольких копий].

1 ответ1

4

Эта установка рекомендуется или даже возможна?

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

Рекомендуется, хотя? Я бы сказал, абсолютно нет!

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

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

Когда вы добавляете дополнительное хранилище к существующему пулу, что вы и сделали бы с помощью предложенной вами схемы, уже сохраненные данные не будут автоматически перебалансированы. Вместо этого ZFS записывает новые блоки данных в vdevs, у которых больше всего свободного места, что приводит к тому, что данные распределяются по всем vdevs с течением времени по мере их записи. В вашем случае это означает, что данные будут распределены примерно так, как вы ожидаете: вновь записанные данные, включая изменения в существующие файлы, с большей вероятностью будут записаны во вновь добавленный vdev, чем в ранее существующие vdev(s). Поскольку все vdevs находятся на одном и том же физическом диске, реальная надежность от этого не увеличивается; если один диск умирает, то ваш пул умирает и забирает все ваши данные.

ZFS также пытается равномерно распределить данные внутри vdev, исходя из того, что это снижает риск локализованного физического повреждения или логических ошибок, одинаково влияющих на все копии. Это одна из основных причин, лежащих в основе структуры дерева Merkle на диске, и вероятная причина, по которой он пытается разместить copies как можно дальше друг от друга, предпочтительно на несвязанных vdevs.

Насколько я знаю, в ZFS в настоящее время нет встроенной поддержки для балансировки данных между vdevs после добавления дополнительного хранилища. Btrfs имеет команду btrfs rebalance , но ZFS не имеет ничего подобного. Вы можете немного приблизиться, скопировав данные (используя zfs send ... | zfs recv ...), но это только побочный эффект.

В итоге, я сомневаюсь, что предложенная вами установка будет значительно хуже с точки зрения поиска диска, чем аналогично настроенная ZFS на одном разделе.

Затем я создал на нем огромную файловую систему ZFS. Если я установлю копии = 2, это тоже заканчивается поиском-адом, или есть какой-то умный механизм ZFS, который будет хранить копии всех файлов на одном диске с использованием буфера [предположение: тоже искать ад + только одна копия, потому что вам понадобится несколько устройств для нескольких копий].

Во-первых, имейте в виду разницу между пулами ZFS и файловыми системами ZFS. Вы создали пул, который по умолчанию содержит одну файловую систему с тем же именем, что и у пула. Пул определяет свойства физического хранилища, такие как конфигурация vdev и минимальный размер блока (известный как ashift в ZFS), и администрируется с помощью утилиты zpool . Файловая система определяет свойства логического хранилища, такие как сжатие, квоты, точки монтирования и контрольные суммы, и управляется с помощью утилиты zfs . Это в отличие от, например, Btrfs, которые смешивают два вместе.

Во-вторых, позвольте мне кратко представить вам, как работает свойство файловой системы ZFS для copies . copies определяют избыточность сверх физической избыточности и, по сути, аналогичны созданию нескольких видимых пользователем копий одного файла (но не нарушают ментальную модель пользователя, если в файловой системе используется дедупликация). Хотя это применимо ко всем типам избыточности vdev, это проще всего проиллюстрировать с помощью зеркал: двустороннее зеркало vdev, благодаря простому свойству быть зеркалом, будет хранить две идентичные копии ваших данных. Если вы также установили copies=2 , то на каждом из двух дисков в зеркальной паре также будут храниться две копии ваших данных, в общей сложности четыре копии сохраняемых битов и общая полезная память около 25% ( по сравнению с количеством доступного хранения сырья). Простое объяснение несколько ломается с raidz N vdevs, но результат тот же: несколько копий одних и тех же битов хранятся на диске, так что в случае сбоя одного из них можно использовать другой.

По умолчанию сохраняется одна копия пользовательских данных и две копии метаданных файловой системы. Увеличивая количество copies , вы настраиваете это поведение таким образом, чтобы copies пользовательских данных (в этой файловой системе) сохранялись, а copies плюс одна копия системных метаданных (в этой файловой системе) сохранялись. Для достижения наилучшего эффекта, если вы хотите установить для копий значение больше единицы, вы должны сделать это при создании пула с помощью zpool create -O copies=N , чтобы обеспечить сохранение дополнительных копий всех метаданных корневой файловой системы.

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

Однако во время записи все копии должны быть обновлены, чтобы обеспечить их синхронизацию. Поскольку ZFS стремится размещать копии далеко друг от друга, это вводит дополнительный поиск. Также не забывайте о дизайне дерева Merkle, блоки метаданных расположены на некотором физическом расстоянии от блоков данных (например, для защиты от единственного сбоя записи, повреждающего как контрольную сумму, так и данные). Я считаю, что ZFS стремится размещать copies на расстоянии не менее 1/8 от vdev друг от друга, а блок метаданных, содержащий контрольную сумму для блока данных, всегда располагается на некотором расстоянии от блока данных.

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

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .