Я подумываю использовать ZFS для своего самодельного NAS-массива. У меня было бы 4 жестких диска в raidz на машине Ubuntu Server 10.04.
Я хотел бы использовать возможность создания снимков и дедупликации при хранении данных. Скорость меня не особо беспокоит, поскольку доступ к машине осуществляется через беспроводную сеть N, и это, вероятно, будет узким местом.
Так есть ли у кого-нибудь практический опыт работы с zfs-fuse 0.6.9 в такой (или подобной) конфигурации?
У меня есть два диска по 500 ГБ в настройке зеркала zfs-fuse на моем домашнем NAS (debian lenny). Он работает уже почти 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. Встроенная поддержка сломана и, возможно, никогда не будет готова к работе. В прошлый раз, когда я проверял, было много корпоративных установок с использованием Samba, но ни одной с использованием CIFS из-за кошмаров управления разрешениями.
Я также ежедневно использую ZFS-FUSE в Ubuntu (на персональной рабочей станции) и считаю его надежным и отличным решением. Единственные проблемы, о которых я могу думать конкретно с ZFS-FUSE:
Вы не можете отключить ZIL (кэш записи), по крайней мере, не установив флаг в исходном коде и не скомпилировав свой файл. Кстати, отключение ЗИЛа, вопреки распространенному заблуждению, не приведет к потере пула при сбое. Вы просто теряете все, что было написано в то время. Это не отличается от большинства файловых систем. Он может быть не идеальным для многих критически важных серверных сценариев (в этом случае вам, вероятно, все равно следует использовать собственный Oracle Solaris), но обычно это очень полезный компромисс для большинства случаев использования рабочих станций / личных. Для мелкомасштабной установки ZIL может быть огромной проблемой с производительностью записи, потому что по умолчанию кэш распределен между самим пулом, что может быть довольно медленным, особенно при настройке полосы четности (RAIDZx). В Oracle Solaris отключить его легко, я считаю, что это свойство пула «синхронизация» IIRC. (Я не знаю, можно ли его легко отключить в собственной версии ядра Linux.)
Также с ZFS-FUSE версия zpool недостаточно высока для поддержки лучших вариантов восстановления пула более поздних версий, поэтому, если вы все же решите выгрузить кеш записи, скажем, на один или несколько SSD или RAM-накопителей, будьте осторожны. . (И всегда отражайте его!) Если вы потеряете ЗИЛ, вы почти наверняка потеряете весь свой пул. (Это катастрофически случилось со мной еще в OpenSolaris.) Более поздние версии zpool для Oracle Solaris смягчили эту проблему. Кажется, я не могу определить, есть ли в порту Linux на уровне ядра это смягчение или нет.
Также вы можете смело игнорировать тревогу «Ошибка ZFS ARC», с которой парень, похоже, спамил обсуждения. Мой сервер сильно забит, как и бесчисленные производственные серверы по всему миру, и никогда не испытывал этого.
Лично я сильно не люблю Solaris, но ZFS просто великолепна, и теперь, когда я стал полагаться на его возможности, я не могу без него обойтись. Я использую его даже на ноутбуках с Windows. (С помощью сложного, но очень надежного решения для виртуализации и USB-накопителей, прикрепленных к крышке на липучке.)
Изменить: несколько незначительных правок для ясности, актуальности и признания ограничений производительности ZFS-FUSE.
Сейчас есть собственный порт linux ZFS. Я узнал об этом только недавно, и поэтому у меня не было возможности проверить это. Тем не менее, он находится в активной разработке, что является хорошим знаком. Возможно, стоит попробовать, если вас не пугает необходимость компилировать модуль ядра и инструменты для себя.
Если вам удастся заставить его работать, он, без сомнения, будет работать намного лучше, чем zfs-fuse.
Почему dimply не использовать opensolaris?
Вы получаете все необходимое и лучшую производительность.
Я запускал ZFS-FUSE под Ubuntu почти год без каких-либо проблем, прежде чем перенести пул на OpenSolaris. Тем не менее, требования к памяти для Dedup в пуле с несколькими ТБ, вероятно, превысят объем памяти вашего домашнего Linux-сервера. Производительность дедупликации ужасна, когда ваши таблицы дедупликации перетекают из ARC (кеш первичной памяти), если у вас нет SSD для L2ARC, чтобы они были легко доступны. Без таблиц дедупликации в памяти ряд операций может стать невероятно медленным (удаление каталога файлов, удаление снимка и т. Д.). Снимки могут работать без дедупликации и почти не имеют накладных расходов сами по себе, поэтому, если вы не храните много избыточных данных и не имеете 8-16 ГБ оперативной памяти и / или SSD для решения проблемы, я бы пропустил дедупликацию.
Также существует ошибка 3+ лет с ZFS ARC, которая все еще сохраняется!
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6522017
(Это неприятно, так как оно также выйдет за пределы виртуальных машин гипервизора!)
Понятия не имею, адресован ли ZFS-fuse этому ...