Насколько стабилен zfs-fuse 0.6.9 в Linux?

Я думаю об использовании ZFS для своего домашнего массива NAS. У меня было бы 4 жестких диска в raidz на машине с Ubuntu Server 10.04.

Я хотел бы использовать возможность снимка и дедупликации при хранении данных. Меня не очень беспокоит скорость, так как доступ к машине осуществляется через беспроводную сеть N, и это, вероятно, будет узким местом.

Так есть ли у кого-нибудь практический опыт использования zfs-fuse 0.6.9 в такой (или симиллярной) конфигурации?

6 ответов

Решение

На моем домашнем NAS-накопителе (debian lenny) установлены два диска емкостью 500 ГБ в зеркале zfs-fuse. Он работает уже почти 6 месяцев, и у меня не было проблем. Более подробно здесь на моем блоге.

Я знаю, что эта ветка древняя, но с тех пор многое изменилось. (Например, состояние 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, но ни одного, использующих CIFS из-за ночных кошмаров управления разрешениями.

Я также ежедневно пользуюсь ZFS-FUSE в Ubuntu (на персональной рабочей станции) и считаю, что это надежное и отличное решение. Только проблемы, которые я могу придумать, особенно с ZFS-FUSE:

  1. Вы не можете отключить ZIL (write-cache), по крайней мере, без установки флага в исходном коде и компиляции yourslef. Кстати, отключение ZIL, вопреки распространенному заблуждению, не приведет к потере пула в случае сбоя. Вы просто теряете то, что было написано в то время. Это ничем не отличается от большинства файловых систем. Он может не быть идеальным для многих критически важных серверных сценариев (в этом случае вам, вероятно, все равно следует использовать встроенный Oracle Solaris), но, как правило, он является очень выгодным компромиссом для большинства рабочих станций / личных сценариев использования. Для мелкомасштабной установки ZIL может быть огромной проблемой производительности записи, потому что по умолчанию кэш распределяется между самим пулом, что может быть довольно медленным, особенно если используется настройка полосы четности (RAIDZx). В Oracle Solaris отключить его легко, я полагаю, что это свойство синхронизации пула IIRC. (Я не знаю, может ли это быть легко отключено на родной версии ядра Linux.)

  2. Также с ZFS-FUSE версия zpool недостаточно высока, чтобы поддерживать лучшие варианты восстановления пула более поздних версий - поэтому, если вы решите разгрузить кэш записи, скажем, к одному или нескольким SSD или оперативным дискам, будьте осторожны, (И всегда отражайте это!) Если вы потеряете ЗИЛ, вы почти наверняка также потеряете весь свой пул. (Это случилось со мной в OpenSolaris.) Более поздние версии zpool в Oracle Solaris разрешили эту проблему. Кажется, я не могу определить, имеет ли порт linux уровня ядра это смягчение или нет.

Также вы можете спокойно игнорировать тревогу "Ошибка ZFS ARC", с которой парень, похоже, спамит. Мой сервер сильно забит, как и многие другие производственные серверы по всему миру, и никогда его не испытывал.

Лично, хотя мне сильно не нравится Solaris, ZFS просто удивительна, и теперь, когда я стал зависеть от его возможностей, я не могу обойтись без него. Я использую это даже на ноутбуках Windows. (С помощью сложного, но очень надежного решения для виртуализации и USB-накопителей, прикрепленных к крышке.)

Редактировать: несколько небольших изменений для ясности, актуальности и признания ограничений производительности ZFS-FUSE.

Теперь есть собственный порт Linux ZFS. Я узнал об этом только недавно, и у меня не было возможности проверить это. Однако он активно развивается, что является хорошим знаком. Вероятно, стоит попробовать, если вам не страшно собирать модуль ядра и инструменты для себя.

Если вы можете заставить его работать, он, несомненно, будет работать намного лучше, чем zfs-fuse.

Почему я не использую opensolaris?
Вы получаете все, что вам нужно, и лучшую производительность.

Я запускал ZFS-FUSE под Ubuntu почти год без каких-либо проблем, прежде чем перенести пул в OpenSolaris. Тем не менее, требования к памяти для дедупликации в пуле нескольких ТБ, вероятно, превысят объем памяти вашего домашнего сервера Linux. Производительность дедупликации ужасна, когда ваши таблицы дедупликации перетекают из ARC (основной кэш памяти), если у вас нет SSD для L2ARC, чтобы они были легко доступны. Без таблиц дедупликации в памяти ряд операций может быть невероятно медленным (удаление каталога файлов, удаление снимка и т. Д.). Моментальные снимки могут функционировать без дедупликации и почти не имеют собственных издержек, поэтому если вы не храните много избыточных данных и не имеете 8-16 ГБ оперативной памяти и / или SSD для решения проблемы, я бы пропустил дедупликацию.

Также есть ошибка на 3+ года с ZFS ARC, которая все еще сохраняется!

http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6522017

(Это отвратительно, поскольку оно также выходит за пределы виртуальной машины гипервизора!)

Понятия не имею, если ZFS-предохранитель обращается к этому...

Другие вопросы по тегам