История изменений

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, выставленное вручную время.
Нам (в компании) удалось уронить ее только когда место на дисках физически кончилось, и следующая запись на диск начинала затирать текущую, активную. И то, данные остались сохранными: при попытке записать в активный снапшот система валилась в кернел паник, а т.к. на дисках есть лог изменений, то при старте она пыталась повторить эту последнюю операцию... И падала опять.
Решилось примонтированием в ридонли — система не могла трогать данные а вктивном снапшоте и продолжала работать. Эвакуация данных и проверка показали, что все до байта цело и читаемо.

//выдохнул.

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, выставленное вручную время.
Нам (в компании) удалось уронить ее только когда место на дисках физически кончилось, и следующая запись на диск начинала затирать текущую, активную. И то, данные остались сохранными: при попытке записать в активный снапшот система валилась в кернел паник, а т.к. на дисках есть лог изменений, то при старте она пыталась повторить эту последнюю операцию... И падала опять.
Решилось примонтированием в ридонли — система не могла трогать данные а вктивном снапшоте и продолжала работать. Эвакуация данных и проверка показали, что все до байта цело и читаемо.