Apple прекращает поддержку ZFS

Если не изменяет память, в случае с zfs при переносе винтов на другую машину даже не важен порядок следования дисков - оно само находится. Как с этим в LVM интересно.

в LVM надо просканировать (vgscan), затем активировать (vgchange -ay) тома, после этого примонтировать все фс.

post-factum> А как же HFS+?

NTFS и то лучше. В Mac OS технологии как всгеда устаревшие.

ой ли. откуда такие сведенья?

воообще непонятно откуда такое внимание к производителю сохо-техники уровня асус, с единственным отличием - по недоразумению всё еще имеющему с давних времен свою ось. собака лает - караван идёт

> в случае с zfs при переносе винтов на другую машину даже не важен порядок следования дисков - оно само находится. Как с этим в LVM интересно.

Точно также. Каждый PV имеет свой UUID, так что собирается он независимо от порядка следования винтов. Да, и вообще не важно - винт ли это, либо MD-устройство, или не устройство а раздел, либо loop-устройство, либо iSCSI либо что-то другое.

Уровня асус? я тут как нить фото выложу корпуса моего Power'а. И он еще работает. Асус бы давно рзвалился бы

> А после полной переустановки системы как там происходит воссоздание конфигурцации?

А в линуксе с LVM не надо восстанавливать конфигурацию - оно само все подхватит и найдет через pvscaln, vgscan и lvscan в init-скриптах :-)

>поэтому я с нетерпением жду появления BTRFS в Linux, ну, или же, Debian/kFreeBSD, с ядром 8.x и поддержкой ZFS :).

Поставить FreeBSD 8.0 религия не позволяет, да? Ж))

>оно само все подхватит и найдет через pvscaln, vgscan и lvscan в init-скриптах :-)

Фу-ты. Ранлевелы всякие. На каком оно там уровне "подхватиться"-то?

>Поставить FreeBSD 8.0 религия не позволяет, да? Ж))

А зачем? Юзаю OSOL 0906 + xVM (где юзается Debian) :).

>Уровня асус? я тут как нить фото выложу корпуса моего Power'а. И он еще работает. Асус бы давно рзвалился бы

у меня есть ASUS M3N купленный 6 лет назад кстате живой. это насчёт надежности ). и powerbook g4 5 лет уже отпахал на ура.

и пара материнок купленных лет 7 назад под пень4, проехали за жизнь пол европы и назад, работали в десятке серваков и вполне себе живы.

раньше железо было просто лучше. а теперь копроэкономика. интересно сколько современный mac pro протянет. асусы я вообще боюсь покупать последнее время.

ну не знаю. я щас боюсь брать что-то новое

Хоме-роутер на Linux — TRENDnet TEW-639GR — и полгода не проработал (питалово от UPS'а, так что броски напряжения исключены). Сейчас в ремонте.
Вместо него пашет дубовый D-Link DSL-504T, 2005г. выпуска.

вот еще вспомнил - есть mac mini 5 летней давности (тот первый, еще на G4), сколько он уже полных разборок-сборок пережил, не поддаётся учёту.

и был asus eeebox b206 у которого при первой же замене винта отвалился sata-разъём, причем кто был внутри, знаете что обычной замене не поддаётся, требуется тонкая пайка. вот такие нынче копродевайсы.

Вылезай из анабиоза - OpenSolaris ни на чем другом и не бывает, только на ZFS. Solaris 10 тоже уже не первый год на ZFS можно поставить

>А после полной переустановки системы как там происходит воссоздание конфигурцации?

Да никак. Автоматом подхватывается без дополнительных действий. Хоть с LiveCD загрузись, хоть винты в любом порядке поменяй, хоть в уже работающей системе местами винты меняй.

>в LVM надо просканировать (vgscan), затем активировать (vgchange -ay) тома

Никогда не делал такого. Это нужно только при горячей замене томов.

> А монолитность кода. Я думаю внутри иходников он не такой и монолитный

Код там вполне себе модульный и структурированный. И там даже вполне четко уровни выделяются (основных - три: ZPL, DMU и SPA), только интерфейс между ними не примитивно-блочный, а транзакционный. А на языке блоков ZFS взаимодействует только с устройствами, обеспечиващими долговременное хранение. Ну эти устройства ничего другого и не умеют.

> Фу-ты. Ранлевелы всякие.

Ну дык, это только у тебя в винде ранлевелы отсутствуют. А у линуксоидов LVM инициализируется перед монтированием ФС.

> Вот тут я позволю с вами не согласится. Фишки ЗФС действительно не кем не повторены

И какие же это?

fs+vm - в одном флаконе? - старая идею - osf/1 (кстати, субьба dec-а :) )
128бит? - сильно опередили время - 2^64*4К дай бог добраться лет через 30, а время жизни сегодняшних систем не превышает 10 лет.
И первое место, где это понадобиться - SAN, где уже есть и рейды, и заморозка, и все остальные навороты

zfs с zraid - нужен для малых серверов, но там не нужны 128бит!!!

Хм. Скажите где еще сделано ленивое копирование объектов (например при снэпшотах или клонах)?

А где сделана транзакционная запись

> А ЗФС как емакс - хорошая ОС, только файлуха никакая.

Скажи, уважаемый, лично ты ее использовал и как долго? :)

>Тут вопрос в бюджете. Естественно хороший NAS будет предпочтительней.

Даже хороший NAS не догонит даже программный рэйд. Я имел в виду FC СХД.

>В настоящее время Apple ищет разработчика ФС

А они могут внести залог за Рейзера как в случае с Тупаком?

Рейзер и есть тупак.

Даже жену выпилить без kernel panic не смог.

>Все эти функции - не занятие для файловой системы.
>Этим должны заниматься lvm/mdadm и так далее. raid так вообще лучше железный)
>А то получается некий монстрик о десяти рук и восьми ног.

Это твоё персональное humble opinion, тебе сказать куда его засунуть или сам догадаешся?

Если zfs тебе не нужнa, то не трогай. Не принуждает ведь никто. Узай свои lvm/mdadm и так далее...

Знаешь как переводится "тупак" с суахили?

>Фишки ЗФС действительно не кем не повторены

А подскажи, уважаемый, а чего бы вдруг тогда нетапу судиться с санками? Тут ведь еще разобраться надо кто у кого тырил...

>>При этом производительность классического (железного) raid и устойчивость к сбоям питания на порядок выше. Что говорит о том, что это понятия совершенно разного класса.

>Насколько я помню, софтовые рейды еще полтора года назад были той же производительности при той же нагрузке на CPU. Ибо последние стали круче.

Я бы даже усугубил. Какой-нибудь NetApp мало того что софт-рейд со средним по производительности CPU и невеликой RAM (1-2Gb), так еще и файловая система у него zfs-подобная. Конкуренты утирают пот ушанкой при сравнении возможностей. убогие железные RAID, продающиеся за кучу грязных зеленых бумажек - развод для лохов

>Я бы даже усугубил. Какой-нибудь NetApp мало того что софт-рейд со средним по производительности CPU и невеликой RAM (1-2Gb), так еще и файловая система у него zfs-подобная. Конкуренты утирают пот ушанкой при сравнении возможностей.

Это zfs как-то подозрительно на вафлю от нетап похожа ;)

А что касается крутости софтрейда... ну ты это людям использующим, ну к примеру, хитачу расскажи.

Хотя, таки да кларион это самый настоящий софтрейд средствами windows xp embedded. Ну так пока только ёмс отметился.

>убогие железные RAID, продающиеся за кучу грязных зеленых бумажек - развод для лохов

Нищеброд штоле?

>Так надо использовать raid с hotspare, если так важен минимальный простой.

Ладно, а сколько займёт времени сборка массива RAID5 на 16Т при использованном объёме места на 100Г и при наличии спарника?

> this.setFatMode(true);

(setf (mode this) 'fat)

;;; так троллёвей =)

>>Я то же самое делаю на LVM и ext4/ReiserFS/XFS.

> Я то же самое делаю на LVM и ext4/ReiserFS/XFS.

Только после этого ты делаешь еще FS resize. И еще расскажи что ты делаешь когда у тебя несоклько ФС, в некоторых место заканчивается, а в некоторых - избыток :)

>Только после этого ты делаешь еще FS resize

И что? Одна команда же.

>И еще расскажи что ты делаешь когда у тебя несоклько ФС, в некоторых место заканчивается, а в некоторых - избыток :)

Добавляю в те, куда нужно не всё свободное место в LV, а сколько нужно. Соответственно, избытка большого не бывает.

Если у нас уже работающий raid то для ОС операция замены сдохшего винта при наличии hotspare будет прозрачна.
Если первоначальная сборка, то конечно долго. Но всё равно уложится при правильных дисках в несколько часов. То есть ожидание в целом незначительно, учитывая что работать оно потом будет хз сколько времени.

Ну да, это моё IMHO.
Тут просто вопрос чисто архитектурный.
Логичнее вынести эти функции из ФС, тогда другие ФС тоже смогут их использовать, не реализовывая заново для себя. Это так же логично, на мой взгляд, как и динамическая линкова.
Вопрос тут не в конкретной реализации а в архитектурном подходе.
imho.

> На решение Apple могли повлиять неясные перспективы и статус продукта: NetApp подала в суд обвиняя Sun в нарушении патентов, Sun ответила встречным иском, Oracle купила Sun.

Ну Oracle пока что еще Sun не купила. А знающие люди говорят, что просто не договорились:

http://mail.opensolaris.org/pipermail/zfs-discuss/2009-October/033125.html

Пока?

> Логичнее вынести эти функции из ФС, тогда другие ФС тоже смогут их использовать, не реализовывая заново для себя.

Только для того, чтобы другие ФС смогли использовать "эти функции", придется приделывать к "этим функциям" интерфейс блочного устройства. Вопрос - зачем? Менеджеров томов и так хватает, выбирай на вкус.

Если этого не делать, то есть экспортировать не блочный, а объектный интерфейс, придется переделывать все файловые системы, чтобы они могли им пользоваться, а это задача крайне нетривиальная, поскольку эти другие файловые системы проектировались для блочных устройств.

Впрочем, другим файловым системам никто не мешает использовать zvol'ы...

> Это так же логично, на мой взгляд, как и динамическая линкова. Вопрос тут не в конкретной реализации а в архитектурном подходе. imho.

То, о чем вы говорите, есть абсолютно логичный архитектурный подход с одной точки зрения. Подход ZFS - также архитектурно логичен с другой точки зрения. Или у вас только двоичная логика?

>> Только после этого ты делаешь еще FS resize

> И что? Одна команда же.

>> И еще расскажи что ты делаешь когда у тебя несоклько ФС, в некоторых место заканчивается, а в некоторых - избыток :)

> Добавляю в те, куда нужно не всё свободное место в LV, а сколько нужно. Соответственно, избытка большого не бывает.

То есть этb примитивные, в общем-то, операции приходится выполнять вручную. Зачем? На мой взгляд, есть и более интересные занятия, да и сложность лишняя ни к чему.

А что вы делаете, если в файловой системе, которая не умеет уменьшаться, освободилось место, которое нужно в другой файловой системе "вчера и на самолете"?

>То есть этb примитивные, в общем-то, операции приходится выполнять вручную. Зачем?

Затем, что у меня есть свобода выбора более оптимальной ФС. ZFS такой во всех смыслах не является :)

>да и сложность лишняя ни к чему.

Ну, давай сравним. Есть сторонний чистый винт. Сколько действий нужно в ZFS, чтобы расширить на него на 100Гб раздел видео? В LVM:

1. pvcreate /dev/sdc
2. vgextend my_lv /dev/sdc
3. lvextend /dev/my_lv/video -L+100G
4. xfs_growfs /dev/my_lv/video

Всё. Раздел увеличен за счёт нового диска на 100Гб. 4 операции, ввод которых (с автодополнением) занимает считанные секунды.

Сколько операций это займёт в ZFS? От и до. Даже если одну - неужели ты каждый день делаешь по сотне расширений разделов?

>А что вы делаете, если в файловой системе, которая не умеет уменьшаться, освободилось место, которое нужно в другой файловой системе "вчера и на самолете"?

Не знаю. У меня такого не бывает.

> fs+vm - в одном флаконе? - старая идею - osf/1 (кстати, субьба dec-а :) )

Это вы не об AdvFS часом?

> 128бит? - сильно опередили время - 2^64*4К дай бог добраться лет через 30, а время жизни сегодняшних систем не превышает 10 лет.

Тогда, когда это понадобится, а это может случиться и раньше, чем через 30 лет, ZFS будет к этому готова - переписывать ничего не придется. А время жизни файловых систем - оно гораздо больше 10 лет. Многим из широко используемых сегодня уже хорошо за 10 лет, а некоторым уже и до 30 недолго осталось.

> И первое место, где это понадобиться - SAN, где уже есть и рейды, и заморозка, и все остальные навороты

А что, если SAN невозможен, места не так много, а нужны и защита данных, и заморозка, и клонирование, и сжатие, и другие навороты. Все равно бежать SAN городить?

> zfs с zraid - нужен для малых серверов, но там не нужны 128бит!!!

Вам не нужно? Вот и славно. А другие как-нибудь сами разберутся, что нужно, что не нужно.

> Или у вас только двоичная логика?

А сколлькоричная у вас логика и как называются ее значения?

> Ну, давай сравним. Есть сторонний чистый винт. Сколько действий нужно в ZFS, чтобы расширить на него на 100Гб раздел видео? В LVM:

> 1. pvcreate /dev/sdc > 2. vgextend my_lv /dev/sdc > 3. lvextend /dev/my_lv/video -L+100G > 4. xfs_growfs /dev/my_lv/video

> Всё. Раздел увеличен за счёт нового диска на 100Гб. 4 операции, ввод которых (с автодополнением) занимает считанные секунды.

> Сколько операций это займёт в ZFS? От и до. Даже если одну - неужели ты каждый день делаешь по сотне расширений разделов?

Вы правы насчет отдной.

Дело тут в том, что вам это не сложно - вы LVM уже знаете как свои пять пальцев, и делаете это не задумываясь и сложность, связанную с этим, не замечаете. А ведь приходится оперировать гораздо большим количеством концепций - диск, pv, vg, lv, ФС (5) против диск и пул (2), помнить 4 команды и их правильную последовательность, правильные ключи к ним.

При этом, как вы абсолютно точно заметили, выполнение этих операций требуется довольно редко, и довольно часто не является основным занятием.

>> А что вы делаете, если в файловой системе, которая не умеет уменьшаться, освободилось место, которое нужно в другой файловой системе "вчера и на самолете"?

> Не знаю. У меня такого не бывает.

А вы попробуйте, представьте. Вдруг случится?

>Это zfs как-то подозрительно на вафлю от нетап похожа ;)

хронологически - да. но сейчас разговор о zfs, а не о wafl

>А что касается крутости софтрейда... ну ты это людям использующим, ну к примеру, хитачу расскажи.

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

> Хотя, таки да кларион это самый настоящий софтрейд средствами windows xp embedded. Ну так пока только ёмс отметился.

вот именно, куда не плюнь - везде софтрейд стоит в приличных железках. что у emc, что у netapp'a. и все эти SAN/NAS имеют приличное количество фич, которыми железные рейды похвастаться не могут

>>убогие железные RAID, продающиеся за кучу грязных зеленых бумажек - развод для лохов

>Нищеброд штоле?

фу, как толсто ;)

устрицы ел, право спорить о вкусе имею...

поучаствую в вашем треде, если вы не против

>Затем, что у меня есть свобода выбора более оптимальной ФС. ZFS такой во всех смыслах не является :)

является. главное определиться с критериями, по которым будем оценивать оптимальность. те, кто ставит на zfs наверняка имеют другой список, чем ты

>Сколько операций это займёт в ZFS? От и до. Даже если одну - неужели ты каждый день делаешь по сотне расширений разделов? вы таки будете смеяться, но бывают и такие задачи, хоть это не главное достоинство zfs

>>А что вы делаете, если в файловой системе, которая не умеет уменьшаться, освободилось место, которое нужно в другой файловой системе "вчера и на самолете"?

>Не знаю. У меня такого не бывает.

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

приверженцы заветов Кернигана и Ричи, а также те, кто считает что после выпуска Unix System III больше в систему добавить нечего, будут сейчас кидаться дерьмецом. но я не удержусь от повтора чужих мыслей о том что архитектура fs + lvm + md + dev несколько устарела. она логична, закончена и... достигла потолка своего развития. посмотрите на zfs, btrfs и другие подобные ФС с другого бока. это unix, пусть расцветают тысячи цветов. естественый (с точки зрения ФС конечно) отбор не позволит зажиться уродцам слишком долго.

А если всё-таки почитать руководство по администрированию ZFS?

Модель хранения данных по принципу пула в ZFS

Для управления физическим хранением в ZFS применяется принцип пулов устройств хранения данных. Исторически файловые системы строились на основе одного физического устройства. Для использования нескольких устройств и обеспечения избыточности данных была введена концепция диспетчера томов , обеспечивающая представление нескольких устройств в виде одного устройства, чтобы исключить необходимость изменения файловых систем. Эта разработка позволила перейти на новый уровень сложности и, в конечном счете, предшествовала определенным усовершенствованиям файловых систем, поскольку типичная файловая система не обеспечивала контроль над физическим размещением данных в виртуализированных томах.

ZFS полностью исключает процесс управления томами. Вместо принудительного создания виртуализированных томов ZFS объединяет устройства в пул устройств хранения данных. Пул устройств хранения данных описывает физические характеристики хранения (размещение устройств, избыточность данных и т.д.) и выступает в качестве хранилища данных для создания файловых систем. Файловые системы больше не ограничиваются отдельными устройствами, что позволяет им совместно использовать пространство в пуле. Предварительное определение размера файловой системы больше не требуется, поскольку файловые системы автоматически расширяются в рамках пространства, выделенного для пула устройств хранения данных. При добавлении нового хранилища все файловые системы в пуле могут немедленно начать использование дополнительного пространства без вмешательства администратора. Во многих отношениях пул устройств хранения данных выступает в качестве системы виртуальной памяти. При добавлении в систему модуля DIMM оперативной памяти операционная система не требует вызова определенных команд для настройки памяти и ее назначения отдельным процессам. Все процессы в системе автоматически используют дополнительную память.

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

Для каждого виртуального устройства, добавляемого в пул, ZFS динамически создает чередование полос во всех доступных устройствах. Решение о расположении данных принимается при записи, поэтому во время распределения пространства чередование полос фиксированной ширины не создается. При добавлении виртуальных устройств в пул ZFS постепенно переносит данные в новое устройство для поддержания производительности и политики распределения пространства. Каждое виртуальное устройство также может представлять собой зеркало или устройство RAID-Z, содержащее другие дисковые устройства или файлы. Эта конфигурация обеспечивает гибкость в управлении характеристиками отказоустойчивости пула.

...

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

Сколько операций это займёт в ZFS? От и до. Даже если одну - неужели ты каждый день делаешь по сотне расширений разделов?

Добавление устройств в пул устройств хранения данных

Добавить пространство в пул можно динамически путем добавления нового виртуального устройства верхнего уровня. Это пространство немедленно становится доступным для всех наборов данных в пуле. Для добавления в пул нового виртуального устройства используется команда zpool add. Пример:

# zpool add zeepool mirror c2t1d0 c2t2d0

Формат указания виртуальных устройств совпадает с форматом команды zpool create, при этом применяются те же правила. Для устройств выполняется проверка на использование; изменить степень избыточности при помощи этой команды без параметра -f невозможно. Эта команда также поддерживает параметр -n, предназначенный для выполнения пробного прогона. Пример:

# zpool add -n zeepool mirror c3t1d0 c3t2d0
would update ’zeepool’ to the following configuration:
      zeepool
        mirror
            c1t0d0
            c1t1d0
        mirror
            c2t1d0
            c2t2d0
        mirror
           c3t1d0
           c3t2d0

Этот синтаксис позволяет добавить зеркальные устройства c3t1d0 и c3t2d0 в существующую конфигурацию zeepool.

В последнем примере аналог RAID-10 может получится, то есть страйп-массив из трёх зеркал. То есть существующий пул в любой момент можно расширить за счёт подсоединения ещё одного устройства хранения (в данном случае ещё одной зеркальной пары) всего одной командой.

>хронологически - да. но сейчас разговор о zfs, а не о wafl

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

>вот именно, куда не плюнь - везде софтрейд

Неправда. Большинство нормальных хранилок имеет выделенные ресурсы (ASIC-и, процессоры и т.п.) именно для обсчета рейдов и это имеет свои плюсы. Главный из которых - гарантированный уровень производительности, для midrange свой, для hiend-а свой. Из известных мне именно блочных хранилок только кларион совмещает обсчет рейда и сервисные функции (ОС, снэпшоты и прочее) на одном проце - обычном зеоне.

А упомянутый нетап это все-таки файловый доступ, отсюда и функционал вафли. FCP он тоже умеет, но любой нормальной хранилке сольет. Там луны выдаваемые по FC это фактически здоровые файлы поверх фс.

SS7000 в живую не видел - только читал и симулятор крутил, но что-то как-то не верится, что прям убийца всего и вся... Но это тоже файлер (с ядреным цифс-ом ;), так что нормальным СХД не конкурент.

А ZFS мне кажется локальным решением - наверное удобно и просто, полчаса чтения манов и ты "админ". Но в рамках крупной инфраструктуры с единым хранилищем большая часть плюшек и вкусностей zfs теряют смысл. Остается разве что на потеху скучающему слоуварис админу, с психикой попорченой слайсами и UFS-ом.

>фу, как толсто ;)

Ну про "грязные зеленые бумажки" тоже почетный перл.

>всего одной командой.

Круто, ага. А теперь выведи диск из пула?

>Неправда. Большинство нормальных хранилок имеет выделенные ресурсы (ASIC-и, процессоры и т.п.) именно для обсчета рейдов и это имеет свои плюсы

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

>А упомянутый нетап это все-таки файловый доступ, отсюда и функционал вафли.

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

> FCP он тоже умеет, но любой нормальной хранилке сольет. Там луны выдаваемые по FC это фактически здоровые файлы поверх фс.

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

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