Pawel Jakub Dawidek, известный созданием порта ZFS и GEOM-классов eli, mirror, gate, label, journal, hsec, довел до финальной стадии и добавил (http://lists.freebsd.org/pipermail/svn-src-all/2010-February...) в дерево исходных текстов FreeBSD HEAD реализацию системы репликации устройств хранения данных (HAST), которая позволяет использовать FreeBSD для создания высоконадежных конфигураций, в которых данные синхронизированы по всем узлам кластера.HAST реализован в виде GEOM-класса, обеспечивающего синхронную репликацию блочных устройств поверх TCP/IP сетей, независимо от типа накопителя и файловой системы. HAST предусматривает возможность быстрого восстановления после сбоя, причем, при выходе из строя первичного master-узла, его функции могут быть делегированы slave-узлу. После проверки и монтирования UFS раздела или импорта ZFS пула на поврежденном узле, система автоматически синхронизирует внесенные за время восстановления изменения и продолжит работу без потери данных....
URL: http://lists.freebsd.org/pipermail/svn-src-all/2010-February...
Новость: http://www.opennet.me/opennews/art.shtml?num=25502
Давно пытался замутить кластер на ggated.
Но там были неслабыае проблемы с
отмонтированием вышедшего из строя узла.Похоже теперь удасться воплотить мечту!
HAST внушает доверие, надо бы затестить. ggated конечно совсем не для продакшена, так костыль, да еще и кривой.
ggate - замечательная вещь, но только вот предназначен он совсем не для того, чтобы использовать его с gmirror для создания отказоустойчивого хранилища.
Собсно hast юзает тот же GEOM_GATE. Просто в отличие от ggated, к нему прикручены полезные свистелки-перделки.
И самое главное, что для добавления новых свистелок не нужно корежить ядро. ;)
> Собсно hast юзает тот же GEOM_GATEНичего подобного.
Ну судя по комиту в svn, единственный GEOM класс, который он затрагивает - это GEOM_GATE. Почему же тогда ничего подобного?
и срокам уложился, молодец
плагины к сетевому стеку, оригинально
Прочитал новость, так и не понял, что хотели сказать.
Полез в первоисточник
http://wiki.freebsd.org/HAST
Смысл : горячий резерв, работает на нагрузку только один комп, второй на подхвате,
и максимум 2 компа, надеюсь пока.
Если будет развиватья дальше, то класс!
народ тут так восторгается, что даже возник интерес.
однако после прочтения вики, долго думал чем это лучше drbd.
при том, что drbd умеет master-master и stacked.
>однако после прочтения вики, долго думал чем это лучше drbd.Тем, что это BSD. Для проприетарных вендоров - критично.
Принципиально важно создать полный аналог DRBD, но с возможностью включать в проприетарные решения (т.е. под BSD лицензией и для BSD ядра).
Кому это важно? Проприетарным вендорам?
>Кому это важно? Проприетарным вендорам?Проприетарным вендорам, а значит, и BSD-сообществу.
Обеспечение полной свободы действий для проприетарных вендоров - одна из важнейших целей BSD-сообщества и основное его отличие от GNU/Linux/GPL-сообществ.
По-моему, эта цель противоречит здравому смыслу. Сетевой стек Microsoft - яркий тому пример.
>По-моему, эта цель противоречит здравому смыслу.Поясните, пожалуйста, что плохого в том, чтобы бескорыстно помогать проприетарному вендору?
Если отбросить в сторону идеологию и прочие фанатизмы.
Я и не говорил, что это плохо. Но делать это "важнейшей целью" по меньшей мере странно.
>Я и не говорил, что это плохо. Но делать это "важнейшей целью"
>по меньшей мере странно.Разработкой софта, который заведомо не должен стать проприетарным, занимаются GPL-разработчики. Их идеология отличается от нашей именно в том, что они ограничивают эту ключевую свободу - свободу проприетарного использования.
Цель BSD как раз и состоит в том, чтобы представить достойную альтернативу такой несвободной модели.Если бы это не было важнейшей целью BSD-разработчиков, они бы публиковали код под GPL.
ух ты, какой тонкий троль! тут кормиться не чем, иди дальше.
Как я понимаю, пропиетарным вендорам помогают не бесокрыстно. Проприетарщикам надо помогать либо за деньги, либо за участие в написании/совершенствовании кода.
>Как я понимаю, пропиетарным вендорам помогают не бесокрыстно. Проприетарщикам надо помогать либо за деньги, либо за участие в написании/совершенствовании кода.Это подход GPL.
Подход BSD состоит в том, чтобы все потребители, включая проприетарных вендоров, имели равные права и их участие в разработке было сугубо добровольным.
Что не так со стеком TCP/IP "Майкрософта"?
>Что не так со стеком TCP/IP "Майкрософта"?Всё так. Помогаете конкуренту вытеснить себя же с рынка серверов, передав ему бескорыстно всё лучшее и не получив ничего взамен. Где логика?
>Всё так. Помогаете конкуренту вытеснить себя же с рынка серверов, передав ему
>бескорыстно всё лучшее и не получив ничего взамен. Где логика?Логика находится там, где вы ее не ищете.
Далеко не все вопросы сводятся к конкурентной борьбе за место под солнцем. Есть же еще и соображения морального порядка.
Иногда приходится дать фору другим просто по велению совести.
Как же задолбали уже с этой легендой! Единственный косвенно подтвержденный случай заимствования - в консольном клиенте ftp.exe какой-то древней версии венды ( NT 3.51 или NT 4.0 ) нашли строку Copyright Regents of the University of California. А те, кто хоть немного знаком с внутренностями венды, сразу поймут, что встроить туда TCP/IP от BSD в виде драйвера ( а он в венде сделан именно в виде драйвера ) - та еще задачка.
А ты хотел чтобы "ОС для масс" работала на каком-нибудь своем, особенном протоколе?
>А ты хотел чтобы "ОС для масс" работала на каком-нибудь своем, особенном
>протоколе?Я бы хотел, чтобы она никогда не стала "ОС для масс". А в том, что это всё-таки произошло, может быть заслуга BSD лицензии.
>Я бы хотел, чтобы она никогда не стала "ОС для масс". А
>в том, что это всё-таки произошло, может быть заслуга BSD лицензии.
>от злости трещишь по швам прям. ну трещи-трещи, а мы дальше будем писать под BSD :)
>>Я бы хотел, чтобы она никогда не стала "ОС для масс". А
>>в том, что это всё-таки произошло, может быть заслуга BSD лицензии.
>>
>
>от злости трещишь по швам прям. ну трещи-трещи, а мы дальше будем
>писать под BSD :)Фантазёр. Просто пытался понять, что движет людьми. С чего бы мне это злиться? Наоборот рад за FreeBSD.
представьте что бы было если бы майкрософт написал свою реализацию сетевого стека, которая не совместима ни с кем. Да, они бы понесли больше расходов, но кому было бы от этого лучше?
>представьте что бы было если бы майкрософт написал свою реализацию сетевого стека,
>которая не совместима ни с кем. Да, они бы понесли больше
>расходов, но кому было бы от этого лучше?Может написал бы, а может и не написал бы. Может понёс бы больше расходов и не хватило бы денег на другие важные дела (реклама, обливание грязью открытых технологий). А так - на тебе бесплатно, пользуйся.
>народ тут так восторгается, что даже возник интерес.
>однако после прочтения вики, долго думал чем это лучше drbd.
>при том, что drbd умеет master-master и stacked.Master-master? И что будет с файловой системой на этом master-master?
>Master-master? И что будет с файловой системой на этом master-master?UFS(2) или ZFS придет капец.
А линуксовые GFS, OCFS отлично будут работать.
Посему master-master в HAST на сегодняшний день не имеет практического смысла.
Не шутите так больше. Капец им не придёт, HAST как раз направлен на то чтобы аккуратно их синхронизировать.
Учите матчасть. Обычные файловые системы невозможно "аккуратно синхронизировать" на уровне блочных устройств.
Вы наверное с FAT перепутали, дайте Давидеку время, он всё допилит.
> Вы наверное с FAT перепутали, дайте Давидеку время, он всё допилит.Прямо-таки возьмет и с нуля напишет кластерную ФС? Или до основания перелопатит UFS?
Хотелось бы знать как :)) Повторяю, с обычными ФС это невозможно принципиально.
>Не шутите так больше. Капец им не придёт, HAST как раз направлен на то чтобы аккуратно их синхронизировать.Боюсь, вы так и не поняли разницы между кластерной файловой системой и репликацией блочного устройства.
ФС то не кластерная, но и "всеобщий капец" на данный момент даже если линк между primary и secondary развалится и они некоторое время будут жить своей жизнью, не придёт. После поднятия линка данные одной стороны реплицируются на вторую и всё. В любом случае ФС останется жива.
>ФС то не кластерная, но и "всеобщий капец" на данный момент даже
>если линк между primary и secondary развалится и они некоторое время
>будут жить своей жизнью, не придёт. После поднятия линка данные одной
>стороны реплицируются на вторую и всё. В любом случае ФС останется
>жива.Только учтите, что не "данные одной стороны реплицируются на другую", а "данные primary реплицируются на secondary". И только в том случае, если secondary еще не успели смонтировать. Иначе будет потеря данных как минимум на одной ноде.
И к primary-primary режиму, кстати, это никак не относится.
>ФС то не кластерная, но и "всеобщий капец" на данный момент даже
>если линк между primary и secondary развалится и они некоторое время
>будут жить своей жизнью, не придёт. После поднятия линка данные одной
>стороны реплицируются на вторую и всё. В любом случае ФС останется
>жива.Это ни коим образом не master-master.
>Master-master? И что будет с файловой системой на этом master-master?Ответили вам там уже.
Цитирую из мейллиста переписку про HAST:
Also note that DRBD, which is on the market for a long time already can
operate also only in primary-secondary configuration for production uses.
Eventhough it supports primary-primary configuration, it is not
recommended for production use AFAIK.
Как бы умеет, но как бы и нестабилен =)
>Цитирую из мейллиста переписку про HAST:
>Also note that DRBD, which is on the market for a long
>time already can
>operate also only in primary-secondary configuration for production uses.
>Eventhough it supports primary-primary configuration, it is not
>recommended for production use AFAIK.
>Как бы умеет, но как бы и нестабилен =)Он может великолепно и очень стабильно поддерживать p-p, но без кластерной фс это не имеет никакого смысла.
По вашим комментам выше видно, что вы нифига не понимаете, поэтому постараюсь объяснить вам на пальцах.
Представим себе, что некоторая не-кластерная файловая система не защищена от повторного монтирования. Вы ее монтируете и начинаете работать с каким-то файлом. В это время другой пользователь также ее монтирует и удаляет нафиг весь каталог, в котором лежит ваш файл, и создает на месте этого каталога свой файл с таким же именем (для пущей фатальности). Когда вы захотите записать свой файл (а может, и раньше), ваша файловая система очень удивится.
Я уж не говорю про кеши, метаданные и проч.UFS(2), ZFS просто не удастся использовать одновременно на двух нодах, потому что они не позволят смонтировать себя дважды (что есть правильно), так что для primary-primary режима они бесполезны. И парочкой хуков в отдельном модуле это не решить - нужно полностью переделывать структуру файловой системы.
Блочное устройство, на уровне которого работает HAST, не может ничем в этом помочь, так как ничего не знает про файлы, каталоги и метаданные, и работает лишь байтами.
а как с этой ситуацией справляется кластерная фс?
>а как с этой ситуацией справляется кластерная фс?Просто не позволяет удалять каталог, с файлами из которого сейчас работают =)
>>а как с этой ситуацией справляется кластерная фс?
>
>Просто не позволяет удалять каталог, с файлами из которого сейчас работают =)
>У вас неправильные данные - или FS с которой вы сталкивались - не соотвествует требованиям POSIX.
никто не мешает вызвать unlink на открытый файл, а потом удалить пустой каталог - это будет как раз таки поведение POSIX, остальное.. идет лесом и куда нить на помойку.
>а как с этой ситуацией справляется кластерная фс?Тривиально. в состав "кластерной" FS входит такая хрень как DLM - distributed lock manager, который следит за возникновение конфликтов (несколько клиентов обращаются к общему ресурсу) и предпринимает какие-то действия что бы разрулить этот конфликт.
Но даже на кластерных FS - никто не гарантирует целостность данных если N клиентов пишут в файл открытый на O_APPEND, нужна внешная блокировка (хотя бы через flock()) что бы определить кто же главный.Задача кластерных FS обеспечить коректость кэшей у клиентов что бы когда один клиент читает данные, небыло
"грязных" данных на другом клиенте и читающий клиент получил конектные данные.
Сразу видно истинного прохфисионала - такие безупречные рассуждения ;-)Реализовать на уровне блочного устройства это можно и очень даже реально (погляди что такое DLM - хотя бы статью о VAX DLM на wiki) - но работать это будет ооочень медленно и практически не будет маштабироваться - так как локи прийдется брать на уровне блоков, с другой стороны исходники будут простыми.
Вас же не удивляет что RedHat cluster живет как-то себе? Хотя там обычная ext[2-3-4] + lock manager на уровне блоков.
Вас же не удивляет что несколько клиентов в Panasas или GFS или Lustre - могут разделять одну storage node?
и даже писать в одну inode с разных нод в разные диапазоны (кивок в сторону похмел-фс - которая не позволяет писать в один файл с разных нод - что делает ее ненужной для MPI приложений).весь сторадж можно представить одной инодой, extent lock's и его range - как набор блоков которые будут модифицироваться в операции, так как это блочное устройство - то кэша на него не будет по определению.
Кроме того стоит вспомнить первую реализацию журналирования блочных устройств в FreeBSD - когда через хуки в GEOM велось журналирование всех изменений (аналоги journal=data в linux).
Реализация данного механизма требует вызова функций модуля журналирования по началу IO операции с диском (FS) и по концу - ну и callback который будет вызываться когда данные попадут на persistent storage.
Ровно эти же операции нужны для реализации блокировок (начало любого IO - взятие EX лока на диапазон, конец IO релиз лока), при возникновении конфликта локов - самое простое - это вызов аналога fsync() / не помню фревый VM - возможно там можно как-то узнать какой vnode принадлежат определенные блоки диска - и сбросить на диск только этот диапазон / что бы обеспечить что все данные упадут на storage и другая нода прочитает валидные данные.Достаточно осветил вопрос - или еще пояснения нужны ?
Да, пояснения нужны.- Вы хотели сказать, что описанные вами в начале вашей реплики решения работают исключительно на уровне блочных устройств и абсолютно не представляют себе, что такое файл, каталог, etc?
- Вы полагаете, что реализация DLM для UFS через интерфейс GEOM будет более эффективна по потреблению ресурсов, масштабируемости и (особенно) по производительности, чем файловая система, изначально разработанная под кластер?
> - Вы хотели сказать, что описанные вами в начале вашей реплики решения работают исключительно на уровне блочных устройств и абсолютно не представляют себе, что такое файл, каталог, etc?Могут работать как на блочном уровне, так и на уровне файлов. В терминах DLM нету понятия файл\каталог и тп.
Есть понятие "ресурс" и тип блокировки. Данные это один тип ресурсов; каталоги, имена файлов - другой.> - Вы полагаете, что реализация DLM для UFS через интерфейс GEOM будет более эффективна по потреблению ресурсов, масштабируемости и (особенно) по производительности, чем файловая система, изначально разработанная под кластер?
Что значит файловая система разработаная под кластер - какой тип кластера имеется ввиду - HA решение или полноценный вычислительный кластер?
Я пологаю что реализовать решение для HA кластера на уровне GEOM - возможно, И для случая всего 2х нод (master<>master или master<>slave) оно будет работать с приемлимой производительностью. Для случая UFS в принципе сложно добиться хорошей производительность в случае совместного доступа к одной inode - из-за используемых непрямых указателей на блок.
У вычислительного кластера - совсем другие требования, там это решение не подойдет. Ибо типовое MPI приложение используемое в вычислениях крайне часто хочет иметь совсестный доступ к одному файлу, и количество клиенстких нод - там значительно больше :)
>Могут работать как на блочном уровне, так и на уровне файлов. В терминах DLM нету понятия файл\каталог и тп.
>Есть понятие "ресурс" и тип блокировки. Данные это один тип ресурсов; каталоги, имена файлов - другой.Пожалуйста, не увиливайте от ответа. Для того, чтобы обеспечить корректную работу фс, DLM должен с ней взаимодействовать и "знать" про файлы и каталоги, или это необязательно?
Блокировки, конечно, можно ставить и на уровне объектов фс, и на уровне блоков, но сути это не меняет. Ключевую роль играет алгоритм определения необходимости установки/снятия блокировки.>Что значит файловая система разработаная под кластер - какой тип кластера имеется ввиду - HA решение или полноценный вычислительный кластер?
А нафига, простите, для HA master-master? Ну, кроме live миграции виртуальных машин?
HA - это когда одна master вылетает, и slave быстренько восстанавливает и монтирует фс, поднимает службы master-а и берет его айпишник (например). Каким боком здесь, по-вашему, master-master и какие тогда требования к нему предъявляются?
>>Могут работать как на блочном уровне, так и на уровне файлов. В терминах DLM нету понятия файл\каталог и тп.
>>Есть понятие "ресурс" и тип блокировки. Данные это один тип ресурсов; каталоги, имена файлов - другой.
>
>Пожалуйста, не увиливайте от ответа. Для того, чтобы обеспечить корректную работу фс,
>DLM должен с ней взаимодействовать и "знать" про файлы и каталоги,
>или это необязательно?нет не обязательно. DLM работает с понятием "ресурс". в "кластерных" FS - Lustre, Panasas, GFS - такими ресурсами являются метаданные (каталоги и атрибуты inodes) и данные (диапазон смещений от начала файла).
В случае блочного устройства - будет один "ресурс" == диск - и много extent locks каждый на свой offset range.
Причем в случае устройства можно искуственно хранить не смещение с точностью до байта, а просто номер блока.>Блокировки, конечно, можно ставить и на уровне объектов фс, и на уровне
>блоков, но сути это не меняет. Ключевую роль играет алгоритм определения
>необходимости установки/снятия блокировки.Меняет. Блокировки на уровне блоков никаким образом не затрагиваю понятие "метаданные" (которыми являются каталоги и зоны блоков выделенных для inode/vnode). метаданные это ровно такие же блоки на блочном устройстве как и блоки данных выделенные для inode.
>
>>Что значит файловая система разработаная под кластер - какой тип кластера имеется ввиду - HA решение или полноценный вычислительный кластер?
>
>А нафига, простите, для HA master-master? Ну, кроме live миграции виртуальных машин?Для кластеров баз данных к примеру.
Ответа на вопрос "что в вашем понятии кластер" я так и не увидел - я знаю как миниум 3 вещи которые могут подойти под это определение, сдается что возможно еще что-то новое.
>В случае блочного устройства - будет один "ресурс" == диск - и много extent locks каждый на свой offset range.
>Причем в случае устройства можно искуственно хранить не смещение с точностью до байта, а просто номер блока.Прекрасно. То есть вы хотите сказать, что DLM может быть вообще никак не связан с файловой системой. А на основании чего он тогда снимает и устанавливает блокировки? /dev/random?
>Меняет. Блокировки на уровне блоков никаким образом не затрагиваю понятие "метаданные" (которыми являются каталоги и зоны блоков выделенных для inode/vnode). метаданные это ровно такие же блоки на блочном устройстве как и блоки данных выделенные для inode.
Не надо играть в Капитана Очевидность. Вопрос был не в этом.
> Прекрасно. То есть вы хотите сказать, что DLM может быть вообще никак не связан с файловой системой.Да не связан. В качестве такого DLM служит LDLM модуль в Lustre FS - набор абстрактных ресурсов.
в 1.x Lustre (для простоты) номер ресурса совпадает с inode no на клиенте в 2.x используются полностью абстрактные идентификаторы - FID. Cущестует 2 типа локов - plain (bitlock) & extent.
первые простейшая реализация матрицы конфликтов, вторые еще имеют параметр - "диапазон".
> А на основании чего он тогда снимает и устанавливает блокировки? /dev/random?Вы внимательно читали то что я говорил? Блочное устройство вполне себе имеет операции "начать IO", "закончить IO", "буфер упал на persistent storage".
при начале IO - можно запросить лок у DLM, при возниквении конфликта - дернуть callback который выполнит что-то типа sync/fsync (hint - sync он вобще о файлах ничего не знает - скидывает все что может на диск, таким же образом можно и page cache чистить).
Производительность это просадит - и будет требовать работы с файлами через O_DIRECT (опционально) - но еще раз скажу - реализация возможна.
>Не надо играть в Капитана Очевидность. Вопрос был не в этом.Так великий и могучий - вы бы расшифровали свой вопрос - у меня телепатия закончилась, как понял так и ответил. Возможно я не всостоянии понять ваших высоких мыслей? тогда расшифруйте ситуацию.
>В качестве такого DLM служит LDLM модуль в Lustre FS - набор абстрактных ресурсов.Таки абстрактных? И таки абсолютно не коррелирующих со структурами данных в файловой системе?
>в 1.x Lustre (для простоты) номер ресурса совпадает с inode no на клиенте
Да, действительно очень просто. Связь налицо.
>на клиенте в 2.x используются полностью абстрактные идентификаторы - FID
И по каким же алгоритмам производится распределение этих идентификаторов? Какие же данные используются в этих алгоритмах в качестве входных и выходных параметров?
>Вы внимательно читали то что я говорил? Блочное устройство вполне себе имеет операции "начать IO", "закончить IO", "буфер упал на persistent storage".
Отлично. Только на их основании вы и будете рулить локами?
А как же вы поступите с файловой системой, у которой кэш есть? По условиям задачи, блочное устройство притворяется валенком и ничего ей не объясняет, лишь выдавая отлупы при попытке записать в область с локом. Висит, понимаете ли, в кэше инфа, наконец фс хочет ее сбросить... а на персистенте уже все переменилось давно. Так что, кэш совсем запретить?
>Таки абстрактных? И таки абсолютно не коррелирующих со структурами данных в файловой системе?Таки астрактных. И одно время использовались только plain locks для защиты и данных и мета-данных. потом в в процессе оптимизации и улучшения маштабируемости - их разделили и добавили 3й (полностью абстрактный) тип локов - glimpse - задача которого просто определять кто является "владельцем" EOF и от кого это можно получить (только не надо говорить что это отображение i_size - это совсем не так)
Скажу даже больше - metadata-id - которым служит inode-no, отношения к идентификаторам на storage серверах никакого не имеет. там используется внутренная адресация внутри storage node - называется это LSM.
Так что resource_id для обращения к серверам с данными - совсем другой чем по обращению к мета-данным серверов.
>на клиенте в 2.x используются полностью абстрактные идентификаторы - FID
> И по каким же алгоритмам производится распределение этих идентификаторов? Какие же данные используются в этих алгоритмах в качестве входных и выходных параметров?FID аллоцируется на клиенте исходя из пула который был выделен данному клиенту сервисом FID'ов.
Этот FID используется в мета-дата операциях, в всех операциях связаных с data - фигурирует номер объекта и
идентификатор storage сервера, который был назначен файлу при создании файла.запрашивание что extent что glimpse, что plain/bitlock lock производится через один вызов.
ldlm_enqueue_lock($server, $resource_id, $type, &callbacks, &data);где-то так по памяти - лень код лесть.
>Отлично. Только на их основании вы и будете рулить локами?
Да (это не считая того что на GEOM уровне доступно "чуть" больше информации)
>А как же вы поступите с файловой системой, у которой кэш есть?
буквы "O_DIRECT" в сообщении выше не заметили? слово sync() которое там упоминалось с целью скинуть весь кэш на storage при обнаружении конфликта?
>А как же вы поступите с файловой системой, у которой кэш есть?
>По условиям задачи, блочное устройство притворяется валенком и ничего ей не
>объясняет, лишь выдавая отлупы при попытке записать в область с локом.
>Висит, понимаете ли, в кэше инфа, наконец фс хочет ее сбросить...
>а на персистенте уже все переменилось давно. Так что, кэш совсем
>запретить?кстати - если нода читала перед этим данные - то у нее уже есть лок и никто другой положить данные туда не может - прежде чем скинут кэш.
А если 2 ноды пишут без чтения в один файл - то тут никакая "кластерная" FS не поможет, будет каша (особенно красиво это видно с O_APPEND - там вобще строчки в перемешку могут быть)
>Eventhough it supports primary-primary configuration, it is not
>recommended for production use AFAIK.
>Как бы умеет, но как бы и нестабилен =)И кто же это так настоятельно не рекомендует использовать DRBD и говорит про него гадости?
Правильно, m-r Dawidek, автор HAST'а.Стыдно, батенька.
Я ему как-то больше доверяю, чем анонизмусам. Он не одного только HAST'а автор.
Ну а в вопросах стабильности и безопасности *nix-систем вы, очевидно, больше всего доверяете Биллу Гейтсу.
Он ведь тоже много чего накодил, даже побольше Давидека.Когда нужно подхватить радостный вопль, что ZFS is ready for production, вы слушаете только разработчиков самой ZFS. А вот когда нужно доказать обратное в отношении DRBD, вы, наоборот, прислушиваетесь исключительно к мнению его противников.
Разумеется, это вопрос вашей личной честности. Прежде всего перед самим собой. Вы не хотите быть объективным. Ну что ж, это ваша личная проблема. Остается лишь надеяться, что люди, от которых зависит многое, будут более честны перед собой, чем вы.
Тоесть вы ещё и берётесь утверждать что ZFS не готово для продакшена? А в ляликсе уже есть куча готовых для продакшена аналогов?
А для меня как-то нормально учитывать мнение специалистов в конкретной теме, а не анонизмусов и пиарастов типа БГ (когда кстати ваш великий быдлокодер уже допилит новую крутую ФС которую обещали поди лет 5 назад, ну заодно и что-нибудь из аналогов DRBD?)
Это у Вас уже не линуксофилия, это BSDфобия какая-то в развитой форме.
>Тоесть вы ещё и берётесь утверждать что ZFS не готово для продакшена?
>...
>Это у Вас уже не линуксофилия, это BSDфобия какая-то в развитой форме.Как я и предполагал, вы оказались не профессионалом, а фанатиком.
Фанатик стремится во всем видеть преимущества своей "религии" и недостатки конкурирующих "религий". Как специалист он бесполезен и даже вреден, потому что неспособен сделать разумный выбор, когда вопрос затрагивает его "религиозные" чувства.Лично я предпочитаю на серверах использовать FreeBSD. Просто потому, что знаю эту ось лучше других. Но, в отличие от вас, я способен ценить и уважать достоинства других операционных систем, в частности, Linux. Вы же, в силу своей ограниченности, на это неспособны и поэтому вынуждены регулярно вступать в противоречие со здравым смыслом и собственной совестью.
>А для меня как-то нормально учитывать мнение специалистов в конкретной теме
Простите, но вы учитываете не мнение специалистов, нет.
Вы учитываете мнение только тех, кто говорит то, что вы хотите услышать. Именно таких людей вы называете "специалистами", а тех, кто говорит неприятную правду про объект вашего поклонения, вы называете дилетантами.
Вы ничего не написали по сути вопроса. Весь ваш пафосный комментарий сводиться к формуле "Я д'Артаньян".
>Вы ничего не написали по сути вопроса.А какой смысл вести техническую дискуссию с человеком, у которого нет своего мнения?
Если я напишу про фрю что-то хорошее, независимо от того, правда это или нет, этот товарищ согласится, да еще добавит что-нибудь в духе "О, да вы не такой глупый, как я думал вначале!"
Если же я задену какой-либо недостаток его объекта обожания, он, разумеется, скажет, что я тупой аноним и ничего не понимаю.
Такого человека можно успешно заменить примитивным ботом, и никто не заметит подвоха ;-)>Весь ваш пафосный комментарий сводиться к формуле "Я д'Артаньян".
Я не ставил цели заявлять подобное :-)
Видимо, так само собой получается на фоне моего собеседника.
Нет, я не идеален и не гениален. Но стараюсь глядеть на мир объективно, и считаю, что это правильно.
Поставим вопрос другим образом - у Вас работает под нагрузкой DRBD как master-master ? Может быть вы писали какую-то софтовую часть и знаете топик лучше автора HAST?
А может всё ещё круче - вы просто аноним?
>Поставим вопрос другим образом - у Вас работает под нагрузкой DRBD как
>master-master ? Может быть вы писали какую-то софтовую часть и знаете
>топик лучше автора HAST?Еще раз повторяю - я не собираюсь вести серьезный разговор с человеком, девиз которого - "Предвзятость".
Вы слушаете лишь то, что хотите услышать, а тех, кто говорит неприятную ля вас правду, вы поливаете грязью.
Где это я полил вас грязью, кроме того что явно намекнул что вы аноним и явно ничего уровня HAST не делали. Если Вас это так задело - смените ник и напишите аналог. А то тоже как-то предвзято относитесь, что все "нелинуксоиды" сейчас бросятся кидаться в вас тем же, чем и вы.
>Eventhough it supports primary-primary configuration, it is not recommended for production use AFAIK.Спор ни о чем, на самом деле. Никто так и не потрудился правильно перевести.
Давидек вовсе не заявляет о своего лица, что DRBD primary-primary не рекомендована для продакшена. Он всего лишь вспоминает чье-то мнение (причем без ссылки на источник), да еще и выражает сомнение в том, насколько правильно он это помнит.
Так что цена утверждению в подобной формулировке - ноль, даже если бы оно принадлежало Кирку или Линусу.
Я правильно понял, что это аналог DRBD в линуксе?
В чём заключается правильность реализации?
В том, что котлеты отдельно, мухи отдельно.
GEOM_GATE в ядре работает с "дисками", а все многочисленные перделки реализованы в юзерспейсе.
Хорошо что развитие FreeBSD не останавливается.
Но плохо что файловыми системами и блочными устройствами занимается один человек. Ничего не имею против Павела - специалист отличный. Но такой обьем работы который делает он невозможно сделать в такие сроки без определенных компромисов: отсутствие оптимизации чтения в gmirror и проблемы с производительностью при ребилде, паники на gjournal, интеграция ZFS через неимоверно кривые костыли...
Академический подход к созданию лучшей свободной ОС уходит в прошлое, увы.
>Хорошо что развитие FreeBSD не останавливается.
>Но плохо что файловыми системами и блочными устройствами занимается один человек. Ничего
>не имею против Павела - специалист отличный. Но такой обьем работы
>который делает он невозможно сделать в такие сроки без определенных компромисов:
>отсутствие оптимизации чтения в gmirror и проблемы с производительностью при ребилде,
>паники на gjournal, интеграция ZFS через неимоверно кривые костыли...
>Академический подход к созданию лучшей свободной ОС уходит в прошлое, увы.Да бросьте, все ж отлично
>Да бросьте, все ж отличноОн знает о чём говорит. Его патч починки "сломанного" алгоритма load для gmirror игнорился несколько лет. Патч, вероятно, не идеален, но ничего лучше так и не зарелизено.
зарелизили же вот http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/113885