Я думаю использовать ZFS для моего самодельного массива NAS. Я бы установил 4 HDD в raidz на машине Ubuntu Server 10.04.
Я хотел бы использовать возможности моментального снимка и дедупликации при сохранении данных. Скорость меня не так уж и беспокоит, так как доступ к машине осуществляется через беспроводную сеть N, и это, вероятно, будет узким местом.
Есть ли у кого-нибудь практический опыт работы с zfs-fuse 0.6.9 на такой (или похожей) конфигурации?
решение1
У меня есть два диска по 500 ГБ в настройке зеркала zfs-fuse на моем домашнем NAS (debian lenny). Он работает уже почти 6 месяцев, и у меня не было проблем. Подробнеездесьв моем блоге.
решение2
Теперь естьсобственный порт LinuxZFS. Я узнал об этом совсем недавно, и поэтому не имел возможности протестировать. Но он находится в стадии активной разработки, что является хорошим знаком. Вероятно, стоит попробовать, если только вас не пугает необходимость компилировать модуль ядра и инструменты самостоятельно.
Если вам удастся заставить его работать, он, без сомнения, будет работать гораздо лучше, чем zfs-fuse.
решение3
Я знаю, что эта тема старая, но с тех пор многое изменилось. (Например, состояние ZFS-FUSE и внутриядерных опций, спорное исчезновение «Open» Solaris и т. д.)
Прежде всего, порт ядра ZFS не будетобязательноработают намного лучше, чем ZFS-FUSE "без сомнения". Этот ответ, похоже, отражает распространенное заблуждение, что файловые системы FUSE всегда работают хуже, чем в ядре. (Если вы еще не знаете, вкратце: в теории файловые системы ядра работают лучше, при прочих равных условиях. Но есть много других факторов, влияющих на производительность, с большим влиянием, чем ядро против пространства пользователя.) Однако с ZFS-FUSE, согласно тестам, в некоторых случаях она значительно медленнее, чем родная ZFS (или BTRFS). Однако для моих целей это нормально.
Ubuntu теперь имеет пакет "ubuntu-zfs" через свою систему репозиториев PPA, который является просто хорошей упаковкой и автоматической сборкой модулей собственного проекта zfs-on-linux. Он работает в пространстве ядра и в настоящее время поддерживает более высокую версию zpool, чем zfs-fuse.
Раньше я использовал OpenSolaris на большом избыточном сервере на 20 ТБ, а теперь использую Oracle Solaris 11 на нем. У Solaris есть некоторые существенные проблемы и сложности (особенно если вам комфортно настраивать и администрировать Linux, а не старую школу UNIX), и они радикально изменили многие интерфейсы управления оборудованием и другие интерфейсы конфигурации между версиями ОС и даже обновлениями, что делает его часто очень раздражающей движущейся целью (даже после того, как вы наконец освоите версию перед обновлением до следующей). Но с правильным (совместимым) оборудованием и большим терпением для изменений, обучения и настройки, это может быть удивительным выбором с точки зрения файловой системы.
Еще один совет: не используйте встроенную поддержку CIFS. Используйте Samba. Встроенная поддержка сломана и, возможно, никогда не будет готова к использованию. В последний раз, когда я проверял, было много корпоративных установок с использованием Samba, но ни одной с использованием CIFS из-за кошмаров управления разрешениями.
Я также использую ZFS-FUSE на Ubuntu ежедневно (на персональной рабочей станции) и обнаружил, что это надежное и потрясающее решение. Единственные проблемы, которые я могу вспомнить конкретно с ZFS-FUSE, это:
Вы не можете отключить ZIL (кэш записи), по крайней мере, без установки флага в исходном коде и компиляции самого себя. Кстати, отключение ZIL, вопреки распространенному заблуждению, не приведет к потере пула при сбое. Вы просто потеряете все, что записывалось в тот момент. Это ничем не отличается от большинства файловых систем. Это может быть не идеальным для многих критически важных серверных сценариев (в этом случае вам, вероятно, в любом случае следует использовать собственный Oracle Solaris), но обычно является очень стоящим компромиссом для большинства рабочих станций/персональных случаев использования. Для мелкомасштабной установки ZIL может стать огромной проблемой производительности записи, поскольку по умолчанию кэш распределен по самому пулу, что может быть довольно медленно, особенно если используется настройка с полосой четности (RAIDZx). В Oracle Solaris отключить его легко, я считаю, что это свойство пула «sync» IIRC. (Я не знаю, можно ли его легко отключить в версии с собственным ядром Linux.)
Также в ZFS-FUSE версия zpool недостаточно высока для поддержки лучших опций восстановления пула более поздних версий, поэтому, если вы все же решите перенести кэш записи, скажем, на один или несколько SSD или RAM-дисков, будьте осторожны. (И всегда зеркалируйте его!) Если вы потеряете ZIL, вы почти наверняка потеряете весь свой пул. (Это случилось со мной катастрофически еще в OpenSolaris.) Более поздние версии zpool в Oracle Solaris смягчили эту проблему. Кажется, я не могу определить, включено ли это смягчение в порт Linux на уровне ядра или нет.
Также вы можете спокойно проигнорировать сигнализацию "ZFS ARC bug", которой этот парень, похоже, спамил обсуждения. Мой сервер сильно загружен, как и бесчисленные производственные серверы по всему миру, и я никогда с этим не сталкивался.
Лично мне, хотя я и люто не люблю Solaris, ZFS просто потрясающая, и теперь, когда я привык к ее функциям, я не могу без нее обойтись. Я использую ее даже на ноутбуках с Windows. (С помощью сложного, но очень надежного решения для виртуализации и USB-накопителей, прикрепленных на липучке к крышке.)
Редактирование: Несколько незначительных правок для ясности, релевантности и признания ограничений производительности ZFS-FUSE.
решение4
Я использовал ZFS-FUSE под Ubuntu почти год без каких-либо проблем, прежде чем перенести пул на OpenSolaris. Тем не менее, требования к памяти для дедупликации на пуле объемом в несколько ТБ, скорее всего, превысят объем памяти вашего домашнего сервера Linux. Производительность дедупликации ужасна, когда ваши таблицы дедупликации перетекают из ARC (кэш первичной памяти), если у вас нет SSD для L2ARC, чтобы держать их легкодоступными. Без таблиц дедупликации в памяти ряд операций может стать невероятно медленными (удаление каталога файлов, удаление моментальных снимков и т. д.). Моментальные снимки могут работать без дедупликации и сами по себе почти не имеют накладных расходов, поэтому, если вы не храните много избыточных данных и у вас нет 8-16 ГБ оперативной памяти и/или SSD для решения проблемы, я бы пропустил дедупликацию.