ZFS. Жажду кулстори и ответов.

cast tazhate

Перешел на ZFSOnLinux на Gentoo

Хорошее:

• сжатие
• не надо думать о размерах разделов. Они легковесны как git ветки. Могу хоть 100500 ОС наставить, главное суммарное место

Плохое:

• тормозит по сравнению с reiserfs
• при выключении не отмонтируется, zfs-shutdown падает с «/ is not zfs» потому что он вообще rootfs. В итоге пул не экспортируется и я потом его руками _каждый_раз_ импорирую. Иначе не грузится и пишет corrupted data. Пока нет времени ковырять.

У меня 12 ГБ ОЗУ. Жрет случайное количество этой памяти, потом отдает назад

1. Насколько хорошо она работает под линуксом?

Не жаловались.

последняя версия поддерживается под линуксом уже? Все ли фитчи портированы и протестированы?

Да.

3. Какого состояние поддержки и развития последних трех (вопрос 2), если таки их использовать?

> zpool upgrade -v
This system supports ZFS pool feature flags.

The following features are supported:

FEAT DESCRIPTION
-------------------------------------------------------------
async_destroy                         (read-only compatible)
     Destroy filesystems asynchronously.
empty_bpobj                           (read-only compatible)
     Snapshots use less space.

The following legacy versions are also supported:

VER  DESCRIPTION
---  --------------------------------------------------------
 1   Initial ZFS version
 2   Ditto blocks (replicated metadata)
 3   Hot spares and double parity RAID-Z
 4   zpool history
 5   Compression using the gzip algorithm
 6   bootfs pool property
 7   Separate intent log devices
 8   Delegated administration
 9   refquota and refreservation properties
 10  Cache devices
 11  Improved scrub performance
 12  Snapshot properties
 13  snapused property
 14  passthrough-x aclinherit
 15  user/group space accounting
 16  stmf property support
 17  Triple-parity RAID-Z
 18  Snapshot user holds
 19  Log device removal
 20  Compression using zle (zero-length encoding)
 21  Deduplication
 22  Received properties
 23  Slim ZIL
 24  System attributes
 25  Improved scrub stats
 26  Improved snapshot deletion performance
 27  Improved snapshot creation performance
 28  Multiple vdev replacements

For more information on a particular version, including supported releases,
see the ZFS Administration Guide.

— последнее что есть в Open Source.

4. Какое количество оперативной памяти необходимо для работы, сравнимой с ext4 (без каких-либо фичт)?

1 ГБ для ARC — минимум.

О чем зависит необходимый объём?

От количества запускаемых приложений.

Что будет в случае нехватки?

Полезет в SWAP.

Насколько больше оперативы нужно в случае сжатия (тут же только проц работает, вроде)?

Нисколько.

В случае дедупликации?

Много.

В случае снапшотов?

Нисколько.

5. Насколько использование SSD ускоряет чтение/запись в случае использования в качестве L2-кэша?

Зависит от объёма читаемых данных и частоты их использования.

6. Насколько интересно с точки зрения производительности и стабильности использовать журнал на отдельном устройстве?

Журнал на отдельном устройстве однозначно ускоряет запись.

Использует ли транзакционирование через барьеры и что будет, если транзакция не допишется, а питание выключится (последнии до неё востановится?)

Используется CoW и этим всё сказано.

7. Насколько криво использовать её нативный рейд 6 поверх LVM (LVM-тома (тупо как обычные MBR-разделы, далее эти разделы в её нативный рейд), либо это лучше реализовать через md (он, вроде, куда кондомнее, точно известно, что всё будет хорошо при перестроении или расширении)?

Это бредятина. Никогда этого не делай. Для ZFS пула рекомендуется использование по одному LUNу на физическое устройство.

8. Насколько кошерно с точки зрения производительности использовать её хранения разных типов данных (не в одной ФС, вопрос вообще в производительности работы с такими данными, если только они есть в ФС): образы виртуальных машин, их клоны, снапшоты, коллекция аниме и музыки, mysql DB, NFS, iSCSI/FC file target, множество мелких файлов, рутовая файловая система генты?

Так и делают, только выставляют нужные свойства для отдельных ФС.

9. Как ZFS относится к внезапным ребутам или потере питания?

Безразлично.

Насколько хорошо она работает под линуксом? последняя версия поддерживается под линуксом уже? Все ли фитчи портированы и протестированы?

Протирована 28-ая версия пула. Работает вроде нормально, но для rootfs нужен initrd.

Какое количество оперативной памяти необходимо для работы

Чем больше, тем лучше. От восьми гигов. Готовься даже при отключенной дедупликации видеть занятыми 2-2,5 гига сразу после загрузки системы. По мере работы эта цифра будет расти, особенно если копировать на разделы ZFS крупные файлы.

Если ты не строишь систему хранения данных (файлопомойку, NAS), то профит от zfs минимальный, при максимальной потере ресурсов. Кроме того zfs за пределами sun'овского железа и Солярис'а это как домашнее порно против профессиональной студии

Во, кратко и ёмко.

Кроме того zfs за пределами sun'овского железа и Солярис'а это как домашнее порно против профессиональной студии

Неужели тебя возбуждает закадровая озвучка и имитированные оргазмы? O_o

Для пуритан: пение дворовых алкоголиков vs оперный театр

1. ХЗ
2. Под freebsd очень неплохо. Настолько, что я думаю об использовании в production
3. ХЗ
4. В базе лучше иметь не меньше 4GB. В случае нехватки будут тормоза. Для сжатия достаточно 4. Для дедупликации с нормальной скоростью - из расчета 5GB озу на 1TB данных.
5. ХЗ
6. ХЗ
7. Абсолютно криво. Под неё класть не нужно вообще ничего.
8 Разный workload работает сильно по разному.
9. Декларируется, что пофигистически, но я этому не верю.

Оффтопик-оффтопиком, но..
iZEN, гайдов по доработке свежей фряхи 9.0+ на предмет уменьшения потребления памяти и занимаемого места не знаешь?

Посмотри тут: http://wow.kamensktel.ru/doku.php/zfs

Инфа, конечно, интересная.
Но я про систему в целом)

Тогда тут: http://unixzen.ru/тюнинг-zfs-на-freebsd/

Тогда тут: http://unixzen.ru/тюнинг-zfs-на-freebsd/

Рили кул стори, бро

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

_< Садист ты, опять статью про ZFS кинул.

Я просил что-то типа Лисяровских гайдов, но не для протухших версий.

Я просил что-то типа Лисяровских гайдов, но не для протухших версий.

Эта статья предназначена для FreeBSD пользователей с ZFS версии 28 доступной с 8.3-RELEASE и 9.0-RELEASE.

Уверен, что успело протухнуть?

Но я про систему в целом)

Не понял. Чего хочешь-то?

доработке свежей фряхи 9.0+ на предмет уменьшения потребления памяти и занимаемого места

Как-то так.

Для начала: man src.conf У меня /etc/src.conf:

WITHOUT_AMD=true
WITHOUT_ASSERT_DEBUG=true
WITHOUT_ATM=true
WITHOUT_BIND_DNSSEC=true
WITHOUT_BIND_ETC=true
WITHOUT_BIND_LIBS_LWRES=true
WITHOUT_BIND_MTREE=true
WITHOUT_BIND_NAMED=true
WITHOUT_BLUETOOTH=true
WITH_BSD_GREP=true
WITHOUT_BSNMP=true
WITH_CLANG=true
WITH_CLANG_IS_CC=true
WITHOUT_CVS=true
WITHOUT_EXAMPLES=true
WITHOUT_FLOPPY=true
WITHOUT_FREEBSD_UPDATE=true
WITHOUT_GAMES=true
WITHOUT_GDB=true
WITHOUT_HTML=true
WITH_IDEA=true
WITHOUT_IPFILTER=true
WITHOUT_IPFW=true
WITHOUT_IPX=true
WITHOUT_IPX_SUPPORT=true
WITHOUT_LIB32=true
WITHOUT_LPR=true
WITHOUT_MAIL=true
WITHOUT_MAILWRAPPER=true
WITHOUT_NCP=true
WITHOUT_NDIS=true
WITHOUT_NETCAT=true
WITHOUT_NIS=true
WITHOUT_NETGRAPH=true
WITHOUT_NETGRAPH_SUPPORT=true
WITHOUT_PPP=true
WITHOUT_PROFILE=true
WITHOUT_RCS=true
WITHOUT_SENDMAIL=true
WITHOUT_SYSINSTALL=true
WITHOUT_TELNET=true
WITHOUT_WIRELESS=true
WITHOUT_WIRELESS_SUPPORT=true
WITHOUT_WPA_SUPPLICANT_EAPOL=true

Из конфигурации GENERIC-ядра можно кучу неиспользуемых устройств и опций выкинуть, чтобы собрать собственное ядро. Я удалил только одну строчку:

makeoptions	DEBUG=-g		# Build kernel with gdb(1) debug symbols

tazhate Таз, для тебя нужен специальный каст, что ли? Собственно, твоя кулстори тут больше всего и нужна, и тема эта делалась только из-за этого. :)

Добавлю еще вопрос, заметная деградация производительности на hdd наблюдается?

Ещё какая, особенно в случае дедупликации. COW же. Мне кажется, что домашней системе без SSD или вынесенного журнала, только ССЗБ юзают, которые ещё постоянно пытаются убедить общественность, что проблем у них нет, хотя рейзер работал в 3 раза быстрее. :)

Ещё какая, особенно в случае дедупликации. COW же.

Т.е с btrfs такая же фигня будет?

Включаешь lzo-сжатие и разницы в скорости почти нет.

По сравнению с чем? У тебя ж вроде на ssd btrfs?

По сравнению с без сжатия.

Вот тут один товарищ рассказывает, как он мигрировал немаленькую инсталляцию OpenAFS с Linux на Solaris 11 и ZFS. Слайды здесь. Сканает за кулстори?

А разве со сжатием на hdd не должно быть быстрее? Да и вопрос в том, не будет ли на btrfs производительность деградировать со временем.

А разве со сжатием на hdd не должно быть быстрее?

Должно, я о чём и говорю.

не будет ли на btrfs производительность деградировать со временем

Трудно сказать. Я не замечал никакой деградации, но это SSD. На HDD, возможно, будет заметно.

tazhate

Tazhate, я призываю тебя. Во имя Б-га нашего Всесвободного, rms, приди. Явись передо мною и без промедления покажись мне, здесь, за чертою этого треда, в приятном для глаз человеческом облике, не модераторском и не безобразном. Явись в сей же миг, в какой бы части света ты ни находился, и ответь на вопросы мои. Явись в сей же миг, в зримом и приятном облике, восстань из царства оффлайна, и напиши пост свой, как если бы сам читать его захотел. Таз! Таз! Таз!

1. Насколько хорошо она работает под линуксом? последняя версия поддерживается под линуксом уже? Все ли фитчи портированы и протестированы?

Более/менее. Для десктопа норм, но в продакшн я бы не рискнул. Вроде работает, но местами можно наткнуться на дедлок. Запись быстрее, чем на ext4, кстати. Поддерживается 28ая версия вроде, смотри http://zfsonlinux.org и гитхаб ихний.

2. Насколько хорошо работает в FreeBSD vs Nexenta vs OpenIndiana vs illumos?

freeBDSM - работают все фичи. Скорость надо мерять на конкретном билде, varies от почти солярной до 40-50 MiB/s. В общем, для архива - ок. Боевой хайлоад я бы не стал. Всё что на ядре illumos (openindiana, smartos, illumian, nexenta) - ну, родная среда. Набор фич отличается от Oracle Solaris, надежность примерно таже.

3. Какого состояние поддержки и развития последних трех (вопрос 2), если таки их использовать?

Мнэээ. С подержкой двояко. С одной стороны, их пилят профи. И активно: SmartOS - основа клауд провайдера, Nexenta - коммерческий сторадж. С другой стороны, их пилят профи под продажу, то есть поддержка сообщества заметно слабее, чем у линя. Но патчики ок.

4. Какое количество оперативной памяти необходимо для работы, сравнимой с ext4 (без каких-либо фичт)? О чем зависит необходимый объём? Что будет в случае нехватки? Насколько больше оперативы нужно в случае сжатия (тут же только проц работает, вроде)? В случае дедупликации? В случае снапшотов?

Ну, меньше 4 гигов будет очень тоскливо. Если мы говорим об установке на железо. Все операции с диском сначала кешируются в памяти, а потом сливаются на винчи, раз в n секунд. Вот и получается, что от размера оперативы зависит скорость записи на диск. Есть еще тонкости, но в общем, оперативы нужно от 8-16 гигов. Чем больше лоад, тем больше нужно. Сколько именно нужно зависит от: ширины канала, одновременных потоков, работы в синхронном режиме и наличия l2 кеша. В случае нехватки - получишь скорость софт-рейда без оптимизации, то есть «прочитали журнал-записали данные-записали журнал» на каждый кусочек данных (=кластер). Ну и зачем тогда ZFS?

Да, для сжатия оперативка почти не расходуется, но без нее проц и диск будут друг-друга ждать - возможны лаги.

Дедупликация жрет оперативу люто, ЕМНИП 2 гб на 1 ТБ данных. Но там после первых 600 гб данных начнутся такие тормоза без тонкого тюнинга, что я бы не рекомендовал даже пытаться.

Дедупликацию можно включать только если ты знаешь ZFS на уровне дев-а. И знаете зачем оно тебе.

Снапшоты память не расходуют.

5. Насколько использование SSD ускоряет чтение/запись в случае использования в качестве L2-кэша?

Хорошо ускоряют, но: у них свой юзкейс. Кеш чтения полезен при высоком кеш хит ратио. То есть если дергаются все время одни файлы, или есть паттерн, который система увидит. Ну и ссд все-таки не рам, и скорость и инерция выше. Полезно конечно, но проще тупо купить памяти. У нас, например, в основном кэш хит приходится на метаданные - их мало, все в памяти.
Кэш чтения полезнее, потому что позволяет вести на нем еще один журнал всего массива. Так что общий случай - рекомендуется. Размер зависит от толщины канала на запись. Где-то было описание, поищи. Важно: здесь надежность важнее размера. Раньше вообще рекомендовали SLC ssd.
Итого: тестировать надо твой случай. На чтение полезнее добавить RAM, на запись нужен если запись синхронная или если канал >2 mbit.

6. Насколько интересно с точки зрения производительности и стабильности использовать журнал на отдельном устройстве? Использует ли транзакционирование через барьеры и что будет, если транзакция не допишется, а питание выключится (последнии до неё востановится?)

Это глубокий тюнинг. Не знаешь, что это - не лезь. Оракл так оптимизирует ZFS под базы данных, но они какбэ знают чопочом.
Я вот не знаю - и не лезу. Про недописнаую транзакцию - см п 9.
Да. Кэш записи - это как раз вынесение лога записи на отдельное устройство. Но емнип, там этот лог синхронилируется на каждом цикле слива данных на диск из памяти. То есть потерять более 30 секунд работы сервера невозможно. но это штатная работа. Без тюнинга.
А кэш записи не заменяет оперативу.

7. Насколько криво использовать её нативный рейд 6 поверх LVM (LVM-тома (тупо как обычные MBR-разделы, далее эти разделы в её нативный рейд), либо это лучше реализовать через md (он, вроде, куда кондомнее, точно известно, что всё будет хорошо при перестроении или расширении)?

Что-то я таких половых извращений не понимаю. Совсем. ZFS поверх другого менеджера томов? Все недостатки обоих без единого плюса. Другой менеджер томов поверх ZFS? Ремонтопригодности не прибавится, а гемору...
Если хочется использовать zfs без ведома ОС, маунти по NFS.
Если хочется потестить ZFS в виртуалке, то все пойдет. Но скорость и надежность естественно от хоста зависят а не от того, как там в виртуалке.

8. Насколько кошерно с точки зрения производительности использовать её хранения разных типов данных (не в одной ФС, вопрос вообще в производительности работы с такими данными, если только они есть в ФС): образы виртуальных машин, их клоны, снапшоты, коллекция аниме и музыки, mysql DB, NFS, iSCSI/FC file target, множество мелких файлов, рутовая файловая система генты?

А не знаю. То есть сразу скажу, что MySQL не рекомендую. Медленнее EXT. Потому что ZFS сама по себе DB. Остальное... Ну, это не продакшн, но виртуалки, рутовая и медиаколлекция уживутся легко.

Снапшоты они из коробки.
Вот iScsi — это отдельная история, я бы не стал мешать в одной машине таргет и файл-шару. Они по-разному оптимизируются.
Впрочем, поковырять на коленке без претензий по скорости - можно.

9. Как ZFS относится к внезапным ребутам или потере питания?

Пофигистично. Пока изменения файловой системы не записаны,их нет в журнале, когда они есть в журнале - они уже консистентны. А предыдущая версия ФС не удаляется, там же данные пишутся не на то же место, а в новое, а потом переключаются указатели.
То есть ФС будет консистентна, но данные будут на момент последней удачной записи на диск. 5-30 секунд в зависимости от версии Zpool, или, если тюнилась ZFS, выставленное вручную время.
Нам (в компании) удалось уронить ее только когда место на дисках физически кончилось, и следующая запись на диск начинала затирать текущую, активную. И то, данные остались сохранными: при попытке записать в активный снапшот система валилась в кернел паник, а т.к. на дисках есть лог изменений, то при старте она пыталась повторить эту последнюю операцию... И падала опять.
Решилось примонтированием в ридонли — система не могла трогать данные а вктивном снапшоте и продолжала работать. Эвакуация данных и проверка показали, что все до байта цело и читаемо.

//выдохнул.

Kindly_Cat А многие не верят в магию :( Может Пиковую Даму или Жвачного Короля теперь призвать? :)

Нижайше приклоняюсь пред твоими знаниями, о великий дух! Ныне, коли на то будет твоя воля, перейди обратно в царство мира оффлайнового, не причинив вреда ни человеку, ни животному, ни юзеру. Админь!

За пост огроменное спасибо, думаю, надо будет попробовать на бзде в виртуалке её покрутить, выделив через LVM (хоть и не тру) разделы на хардах и ссд.

Не надо лвм, серьезно. Ему надо отдавать винчи целиком. Лучше файлов насоздовай и их через ло подключи.

Спасибо, слайды торт.

Не надо лвм, серьезно. Ему надо отдавать винчи целиком.

>Лучше файлов насоздовай и их через ло подключи.

http://i1209.photobucket.com/albums/cc390/tkdguy25/U-mad-bro-.jpg

Я, всё-таки, не совсем понимаю, по какой причине нельзя использовать LVM (в случае обычной нарезки диска на куски, как GPT, без всяких фитч)? Мне, например, совершенно не интересно отдавать под одну систему в себе несколько хардов и SSD, при этом я не понимаю, в чём у ZFS может быть отличии при данной работе (когда она использует разделы в LVM как отдельные харды, делая RAID-Z и раздел на SSD для L2 кеша) от работы на хардах напрямую? Раньше была проблема с непрозрачностью кешей и барьеров, но сейчас это уже не проблема же.

Для десктопа норм, но в продакшн я бы не рискнул

Я пораскинул мозгом и решил, что на десктопе ZFS точно не нужна.

А что ж с ней по-твоему не так кроме того, что клон только с read-only снапшота делать можно?

Жрёт память совершенно невменяемо: 2-2,5 Гб сразу после загрузки системы - это фейл для десктопа. Да и постоянный гемор с initrd при обновлениях ядра напрягает.

Разве не достаточно просто вызвать genkernel?

ARC динамический и освобождает память по первому требованию ОС.

Я, всё-таки, не совсем понимаю, по какой причине нельзя использовать LVM (в случае обычной нарезки диска на куски, как GPT, без всяких фитч)?

Да почему же нельзя? Можно. ZFS сожрет все, что выглядит как блочное устройство... Но получится как в том анекдоте про удаление гланд через задницу.

Нам (в компании) удалось уронить ее только когда место на дисках физически кончилось, и следующая запись на диск начинала затирать текущую, активную. И то, данные остались сохранными: при попытке записать в активный снапшот система валилась в кернел паник, а т.к. на дисках есть лог изменений, то при старте она пыталась повторить эту последнюю операцию... И падала опять.

Так это она, похоже, пыталась проиграть журнал подтвержденных транзакций (aka ZIL), а для полного проигрывания не хватало места. Вот и падала. Как вариант, можно было его дропнуть при импорте, чтобы потом почистить место. Естественно, дропание ZIL означает потерю консистентности данных с точки зрения приложения, но в режиме readonly ZIL так и так не проигрывается, так что разницы особой нет.

А затираться ничего не затиралось.