Брайан Белендорф (Brian Behlendorf (http://ru.wikipedia.org/wiki/%D0%91%D0%B... создатель http-сервера Apache, представил (http://www.github.com/behlendorf/zfs/) новую версию проекта, в рамках которого ведется работа по реализации родной поддержки файловой системы ZFS (http://ru.wikipedia.org/wiki/Zettabyte_File_System) для Linux. В отличие от системы ZFS-FUSE (http://zfs-fuse.net/), работающей на пользовательском уровне через подсистему FUSE, новый проект реализован в виде модуля Linux-ядра. Как известно интеграции кода ZFS в Linux-ядро мешает несовместимость лицензий GPLv2 и CDDL, что исключает возможность смешивания кода под данными лицензиями. Для обхода данного ограничения, Белендорф воспользовался (http://wiki.github.com/behlendorf/zfs/faq) простым и очевидным методом - он решил распространять свой продукт целиком под лицензией CDDL в виде отдельно загружаемого модуля к Linux ядру.
В силу специф...URL: http://www.github.com/behlendorf/zfs/
Новость: http://www.opennet.me/opennews/art.shtml?num=26751
iZen удавиться :)
В этом предложении нужно или мягкий знак убрать или пунктуации чуток добавить.
Разумеется "удавится". Прошу прощения!
делегация бывших лоровцев?
>В этом предложении нужно или мягкий знак убрать или пунктуации чуток добавить.Вообще, оба смысла получаются вполне нормальные :P.
Я-то? Нисколечко.Так тонко затроллить линуксятников лицензированием модуля под CDDL — я до такого не мог додуматься. А он смог!
Вот на чём Торвальдс-со-товарищи будет рвать свои пингвинячьи плавки, но поделать ничего не сможет. :))
Теперь армия тестеров на благо CDDL серьёзно прибавиться и, что самое главное, код не утащат в GPL!
>Вот на чём Торвальдс-со-товарищи будет рвать свои пингвинячьи плавки, но поделать ничего
>не сможет. :))Что ему рвать то? Open Solaris, *BSD - R.I.P., чего ему боятся? Haiku? Не смешите.
>>Вот на чём Торвальдс-со-товарищи будет рвать свои пингвинячьи плавки, но поделать ничего
>>не сможет. :))
>
>Что ему рвать то? Open Solaris, *BSD - R.I.P., чего ему боятся?
>Haiku? Не смешите.Что, уже R.I.P.? Странно, аптайм пока не падал...
Вы кстати про Minix забыли. Вот уж об что Линус локти обкусает, так это об mach kernel.
>Вы кстати про Minix забыли. Вот уж об что Линус локти обкусает,
>так это об mach kernel.Уже лет 15, как кусает, да.
>Вы кстати про Minix забыли.Ага, Таненбаум какашками кидался еще лет ~15 назад? Вот только история сама определила кто и что, увы :). Ну в общем приходите еще лет через 15... :D.
>Вот только история сама
>определила кто и что, увы :). Ну в общем приходите еще
>лет через 15... :D.Что винда круче всех, по Вашей логике это история показала?
А что будет через 15 лет?
История не показала, что венда круче. Совсем.
>История не показала, что венда круче. Совсем.Как же так, ведь количество инсталляций много больше чем других систем, т.е. её используют больше и чаще. История ведь именно в этом плане показала "кто и что" для юзера294 или что он имел ввиду?
Я имел в виду развитие системы в целом. Ну и собственно частично использование системы связано с успехами развития. Систему которая нифига не умеет, очевидно, никто и юзать не станет. По причине технической невозможности, разумеется.
>Я имел в виду развитие системы в целом. Ну и собственно частично
>использование системы связано с успехами развития. Систему которая нифига не умеет,
>очевидно, никто и юзать не станет. По причине технической невозможности, разумеется.
>Да Вы что?! Вспомните что писали на форумах про Linux 15 лет назад или уже забыли, так вот абсолютно тоже, что и Вы, только вместо поделки Таненбаума в сравнении стоял Linux, а вместо Linux - винда и самое смешное, что аргументация была абсолютно такой же.
>Как же так, ведь количество инсталляций много больше чем других систем, т.е.
>её используют больше и чаще.Автомобили среднего класса более популярны, чем более дорогие. Означает ли это, что дорогие автомобили - гумно? Нет. Выбор составляют из возможностей. Ну не могут хомяки в консоли работать, да и чёрт с ними.
>Автомобили среднего класса более популярны, чем более дорогие. Означает ли это, что
>дорогие автомобили - гумно? Нет. Выбор составляют из возможностей. Ну не
>могут хомяки в консоли работать, да и чёрт с ними.Совершенно глупое сравнение, Вы хотя бы предположите каковы причины меньшей популярности более _дорогих_ автомобилей по сравнению с средним классом.
> Вы хотя бы предположите каковы причины меньшей популярности более
>_дорогих_ автомобилей по сравнению с средним классом.В одном случае деньги, в другом неосиляторство. Люди не используют линукс, потому что они неосиляторы! Они не могут его использовать не потому что денег не хватает, как в случае с автомобилем, а потому что осилить не могут или не хотят (вы же не хотите всю жизнь пахать на Лимузин, верно?).
> используют больше и чащеАга, вспомните еще сколько в макдоналдсах жрут.
>Ага, вспомните еще сколько в макдоналдсах жрут.Ну во-первых, сколько?
А во-вторых, обоснуйте ка "технологическое отставание" макдональдса перед пельменной или Вам сказали гамбургеры - бяка и Вы везде это пишите?
> А во-вторых, обоснуйте ка "технологическое отставание" макдональдса
> перед пельменной или Вам сказали гамбургеры - бяка и Вы везде это пишите?http://www.compromat.ru/page_10524.htm
;)
А вообще в Макдональдсах едой-то даже не пахнет.
Я не умею есть то, что там продается.
>Что винда круче всех, по Вашей логике это история показала?Я что-то не вижу в топ500 завалов винды. Так ли уж она круче то? И миллионы точек доступа, роутеров и прочих телевизоров и сетевых жестких дисков что-то ну совсем не на винде делают. Есть сервера, мобильные устройства, etc, etc. И что характерно - винды там или совсем нет или она занимает весьма унылые позиции. Единственное место где она выперла - десктопы. И ... все. А так ли уж эпичен этот win? :)
>Единственное место - десктопыподумаешь, какая мелочь
>>Единственное место - десктопы
>
>подумаешь, какая мелочьДа, _мелочь_ телефонов уже больше, скоро будет больше смартфонов.
>Я что-то не вижу в топ500 завалов винды.=))) священная корова апологетов Linux топ500, ну как же её не вспомнить, только как оно связано с тем, что на
>Так ли уж она круче то? И миллионы точек доступа, роутеров и прочих телевизоров и
>сетевых жестких дисков что-то ну совсем не на винде делают.Т.е. Вы считаете, что на этом всём так процветает Linux благодаря исключительно преимуществу технологическому преимуществу и затраты на ОС здесь ни при чём, и сколько этих устройств было 15 лет назад?
Кстати, Вы знаете количество установленных домофонов, неужели это говорит о большем технологическом совершенстве их прошивок.>сервера, мобильные устройства, etc, etc. И что характерно - винды там
>или совсем нет или она занимает весьма унылые позиции.Ой, зайдите в 100 средних фирм и спросите какие серверы они используют для обеспечения своей инфраструктуры, результаты Вас ошеломят!
Мало того зайдите в любой салон мобильной связи и попросите телефон с Linux проследите за реакцией консультанта, после, спросите про телефон с виндой.
>Единственное место где она выперла - десктопы. И ... все. А так ли
>уж эпичен этот win? :)Не эпичен, только именно винда показывает насколько Linux популярнее Minix или *BSD.
Вы всегда приводите в аргумент популярность, оная ни о чём не говорит, Вы поймите!
>Ой, зайдите в 100 средних фирм и спросите какие серверы они используют
>для обеспечения своей инфраструктуры, результаты Вас ошеломят!100 "средних" это SMB? Тогда, вероятно, результаты ошеломят Вас.
В SOHO действительно на серверах гораздо чаще Win Server, но еще как бы не чаще, у них вообще нет сервера :)
К сожалению, скорее всего именно так:Solaris 1992 - 201x
А на старом железе гонять можно сколько угодно. Смерть ПО - это отсутствие следующей версии в активной разработке.
>К сожалению, скорее всего именно так:
>Solaris 1992 - 201xЗнаете, сколько таких прогнозов уже не сбылось?
>А на старом железе гонять можно сколько угодно. Смерть ПО - это отсутствие следующей версии в активной разработке.И как это относится к Solaris?
Наверное сани с какого-то перепуга продались Ораклу именно потому что дела у них шли лучше некуда, да?... oO
>Вот на чём Торвальдс-со-товарищи будет рвать свои пингвинячьи плавки, но поделать ничего не сможет. :))Встречаясь с создателем ZFS он ничего не кусал.
а все вопили что оно там не нужно....
>а все вопили что оно там не нужно....А в опенсорсе все просто - кому нужно, тот и упирается. А уж как дальше пойдет - если оно кому-то еще нужно, будет проще. Если никому не нужно - загнется. Ну и так далее.
P.S. костыль конечно зачетный, но как-то уже слишком поздно, btrfs явно достигает готовности к продакшну и будет работать сразу в ядре, без костылей, подпорок и с некоторыми фичами которые ZFSу попросту слабо.
> с некоторыми фичами которые ZFSу попросту слабо.с какими?
gpl
Давайте ограничимся полезными фичами и не будем троллить свистелками и перделками из разряда морали.
>Давайте ограничимся полезными фичами и не будем троллить свистелками и перделками из
>разряда морали.Люди без морали живут по закону джунглей. Их общество обычно не вызывает приятных чувств, даже у них самих.
это какой такой закон джунглей?в этом мире из-за морали погибло больше людей чем от техногенных аварий...
и погибшим ни разу не было приятно погибать из-за морали других людей...
не смешите мои тапки, нужно будет, вас убьют когда вы в домашнем халате до мусоропровода пойдете, и никого за это не накажут. а напьетесь с соседом и устроит он вам понажовщину - думать о конституции и морали он не будет. так что как и в джунглях: думать головой и остерегаться.
Давайте тогда амнистируем всех маньяков и серийных убийц? И особо бойким анонимам типа вас в подъезд их поселим. Как, не хотите? :)
И с каких это пор GPL стала фичей?
С тех с каких линукс стал обходить в развитии остальные системы, очевидно :D.
Логика как обычно вам неведома.
>Логика как обычно вам неведома.Анонимы как всегда самокритичны :-)
Изъятие тома из пула без гигантского траха, например. Ну да, не предусмотрели эту операцию в структурах ФС ZFS и как-то уже поздно что-то менять, ФС устроена так как устроена. А в btrfs вот предусмотрели.
Интересно, что ты запоешь, когда таковая поддержка появится, вместе с поддержкой расширения raid-z
Лично я запою что угодно и как угодно, лишь бы появилась возможность наращивать raidz, но ИМХО там by design это невозможно.
>Лично я запою что угодно и как угодно, лишь бы появилась возможность
>наращивать raidz, но ИМХО там by design это невозможно.Никогда не говори никогда. Наращивание RAID-Z - возможно, даже увеличение четности возможно, впрочем, как и уменьшение количества дисков. Просто пока не реализовано.
>Просто пока не реализовано.Так можно сказать про что угодно, хоть про чартерные рейсы на луну. И правда, никаких теоретических препятствий для чартерных рейсов на луну по цене билета на самолет - нет. В теории. На практике все как-то несколько менее радужно.
> В теории. На практике все как-то несколько менее радужно.точно так же можно сказать про то, что никаких теоретических препятствий к реализации дедупликации в btrfs нет. но на практике все как-то несколько менее радужно.
дальше будем продолжать?
>точно так же можно сказать про то, что никаких теоретических препятствий к
>реализации дедупликации в btrfs нет. но на практике все как-то несколько
>менее радужно.А, собственно, есть какие-то серьезные трудности на этом пути? Могу представить себе например крайне эффективный дедуп виртуальных окружений с одинаковой ОС: базовая живет как снапшот, а довески из изменений настроек и т.п. контейнеров - писать по CoW логике, при этом десяток контейнеров будет занимать места почти как один. И собссно трудно себе представить где дедупликация актуальнее, нужнее и эффективнее.
>дальше будем продолжать?
Уломали, как говорится, "поживем - увидим".
> Могу представить себе например крайне эффективный дедуп виртуальных окружений с одинаковой ОС: базовая живет как снапшот, а довески из изменений настроек и т.п. контейнеров - писать по CoW логике, при этом десяток контейнеров будет занимать места почти как один. И собссно трудно себе представить где дедупликация актуальнее, нужнее и эффективнее.Вот только это не дедупликация, а обычное клонирование. А теперь представь, что ты в каждое из этих виртуальных окружений вкатил одно и то же обновление. Сколько копий этого обновления у тебя будет на дисках? Вот тут-то настоящая дедупликация и окажется кстати.
>>дальше будем продолжать?
>Уломали, как говорится, "поживем - увидим".Вот-вот. Вообще смысл исходного сообщения был в том, что "невозможно by design" не соответствует действительности. Оно возможно, просто никто за это пока не взялся.
>Интересно, что ты запоешь, когда таковая поддержка появится, вместе с поддержкой
>расширения raid-zНу, появится и хорошо. А у вас есть оценки времени, когда это случится? А то учитывая геморность задачи из-за неприспособленности к этому ФС + то что там кишки саней хавает Оракль и хрен бы его там знает что учудит оракль - а нынешнее поколение админов на пенсию к тому моменту не уйдет еще?
>>Интересно, что ты запоешь, когда таковая поддержка появится, вместе с поддержкой
>>расширения raid-z
>
>Ну, появится и хорошо. А у вас есть оценки времени, когда это
>случится?Думаю, что раньше, чем разработчики BTRFS скажут, что она стала стабильной.
> А то учитывая геморность задачи из-за неприспособленности к этому ФС
>+ то что там кишки саней хавает Оракль и хрен бы его там знает что учудит ораклькоторому ZFS уже сегодня приностит деньги, в то время как BTRFS пока деньги только потребляет, то конечно неизвестно, что там кто учудит.
> а нынешнее поколение админов на пенсию к тому моменту не уйдет еще?
Если нынешнему поколению до пенсии осталось месяц-два - то имеют шанс уйти раньше, чем это случиться
>которому ZFS уже сегодня приностит деньги, в то время как BTRFS пока
>деньги только потребляет, то конечно неизвестно, что там кто учудит.А скажите пожалуйста, кому? Назовите хотя бы одну крупную инсталляцию, а то в продакшене, где нужны плюшки по управлению томами, ФС и причим все больше VxFS пользуют, хотя оно и денег стоит, и немаленьких
>>которому ZFS уже сегодня приностит деньги, в то время как BTRFS пока
>>деньги только потребляет, то конечно неизвестно, что там кто учудит.
>
>А скажите пожалуйста, кому? Назовите хотя бы одну крупную инсталляцию, а то
>в продакшене, где нужны плюшки по управлению томами, ФС и причим
>все больше VxFS пользуют, хотя оно и денег стоит, и немаленькихSun Storage 7000, внезапно.. И да, посмотрите вокруг - примеров масса.
Упссссссссссссс!Это название компании???? :D Или вы не поняли вопроса?
Пока известно одно: ZFS для малого бизнеса. На hi-end она не тянет.
зы. еще раз осмотрелся: VxFS, CXFS, raw dev. и даже старая ufs.
Да, девелоперы как один на ZFS - на себе тестят. :)
>Это название компании???? :D Или вы не поняли вопроса?Это название линейки продуктов, если вы, сударь, не поняли ответа.
Если сомневаетесь, то сходите посмотрите сами:
http://www.oracle.com/us/products/servers-storage/storage/op...
>Пока известно одно: ZFS для малого бизнеса. На hi-end она не тянет.Это расхожее мнение в кругах красноглазых фанатов и продавцов VxFS и прочих коммерческих решений. Будете аргументировать или так и оставите расхожим мнением?
>зы. еще раз осмотрелся: VxFS, CXFS, raw dev. и даже старая
>ufs.Смотрите шире, ибо давно известно: "всякий кулик свое болото хвалит".
>Да, девелоперы как один на ZFS - на себе тестят. :)Было бы странно, если бы было по-другому. Не находите?
>Sun Storage 7000, внезапно.. И да, посмотрите вокруг - примеров масса.Про эти хранилки на базе интеловых серверов я как бэ в курсе, благо работаю в дисти, санки мы в том числе возим пачками... Только опять же, хранилки вышли на рынок совсем недавно, и не скажу, что от этого сильно пострадал бизнес ЕМС или НР, да тех же санок выпускающих железки традиционной архитектуры. Жезезки несомненно прикольные, и даже покупаются, но доля рынка несерьезная. Возвращаемся к вопросу - назовите хоть одну компанию использующую ZFS на серьезных задачах, биллинг там или еще чего подобное? Все что я знаю - если не нужны плюшки управления томами, кластера и т.д. - старая добрая FFS/UFS, там где нужны - VxFS, и сильно реже CFS
>>Sun Storage 7000, внезапно.. И да, посмотрите вокруг - примеров масса.
>
>Про эти хранилки на базе интеловых серверов я как бэ в курсе,на базе серверов Sun, использующих процессоры AMD, если быть точнее.
>благо работаю в дисти, санки мы в том числе возим пачками...
>Только опять же, хранилки вышли на рынок совсем недавно, и не
>скажу, что от этого сильно пострадал бизнес ЕМС или НР, даМожно подумать, железки от EMC или HP сразу же отхватили серьезную долю рынка, стоило им только на этот рынок выйти. И можно подумать, что они готовы со своей долей легко расстаться, стоит только новому игроку появиться на рынке.
>тех же санок выпускающих железки традиционной архитектуры. Жезезки несомненно прикольные, и
>даже покупаются, но доля рынка несерьезная.Доля рынка имеет свойство меняться с течением времени, правда ведь? Ну и не секрет, что рынок систем хранения данных гораздо более консервативен, чем, скажем, рынок серверный.
> Возвращаемся к вопросу - назовите
>хоть одну компанию использующую ZFS на серьезных задачах, биллинг там или
>еще чего подобное?Серьезные задачи биллингом не ограничиваются, и многие под биллинг вообще не используют файловые системы. Что значит "еще чего подобное"? OLTP-приложения? Для некоторых банальный Email может быть серьезнее всякого там биллинга и подобного.
Имеющий гугл да отыщет :-)
Вот вам пару ссылок для начала:
http://www.sun.com/software/solaris/success_stories.jsp
http://www.nexenta.com/corp/collateral-library
Вот эти товарищи недавно добавили к своему спектру продуктов NAS-голову на базе NexentaStor:
Наверное, они сделали это исключительно потому что ZFS никуда не годится, кроме малого бизнеса...
Или вы хотели услышать названия российских компаний?
Можно посмотреть архивы zfs-discuss - время от времени там возникают темы о Success Stories, ну и вообще кто туда пишет.
>Думаю, что раньше, чем разработчики BTRFS скажут, что она стала стабильной.Уверены? А то они это довольно скоро скажут. И ведь главное не соврут даже.
>Если нынешнему поколению до пенсии осталось месяц-два - то имеют шанс уйти
>раньше, чем это случитьсяА что, такое за месяц сделают? И прям вот так за месяц это будет стабильно и безглючно работать во всех позах? Звучит круто, но как-то слишком уж хорошо чтобы быть правдой.
>>Думаю, что раньше, чем разработчики BTRFS скажут, что она стала стабильной.
>
>Уверены? А то они это довольно скоро скажут. И ведь главное не
>соврут даже.Cудя по http://fedoraproject.org/wiki/Btrfs_in_Fedora_13 это произойдет не раньше, чем осенью следующего года
>
>>Если нынешнему поколению до пенсии осталось месяц-два - то имеют шанс уйти
>>раньше, чем это случиться
>
>А что, такое за месяц сделают? И прям вот так за месяц
>это будет стабильно и безглючно работать во всех позах? Звучит круто,
>но как-то слишком уж хорошо чтобы быть правдой.Так что до осени следующего года еще есть время.
>Cудя по http://fedoraproject.org/wiki/Btrfs_in_Fedora_13 это произойдет не раньше,
>чем осенью следующего годаА в MeeGo уже поюзали, кстати. Не знаю куда и нафига они так торопятся, но факт. И ядерщики вроде обещали заявить ее стабильной в 35-м ядре. Думается оно быстрее чем к осени выйдет. Ну понятно что это стабильное оно будет в том же духе как ZFS у бздунов, т.е. доверяй но проверяй и вообще подожди пока баги вытопчут до того как своими данными рисковать :). Но юзабельности для некритичных применений оно достигнет уже буквально вот-вот.
>Так что до осени следующего года еще есть время.
Поживем - увидим, как что и чего. И я вот могу видеть btrfs который уже начинает бегать всерьез. Кажется я забыл учесть эффект усиления разработки от совместной работы и оно будет готово даже быстрее чем я подумал.
Хотя бы тем, что будет работать через device-mapper. В mdraid, в отличае от бесполезного dmraid, именно это всегда и было неудобно.Впрочем, ZFS во Фре тоже не через Geom работает.
>Впрочем, ZFS во Фре тоже не через Geom работает.Че, правда? И давно?
>Впрочем, ZFS во Фре тоже не через Geom работает.Действительно что-ли? А через что тогда? :)
>>Впрочем, ZFS во Фре тоже не через Geom работает.
>
>Действительно что-ли? А через что тогда? :)Хорошо, не до конца точно выразилась, и давно не читала хандбук, и ZFS смотрела только на OpenSolaris. Имела ввиду грабли, с которыми сталкивался вот этот человек:
http://habrahabr.ru/blogs/bsdelniki/77722/
Для обычных дисков в geom такую ситуацию представить себе просто невозможно.
>Имела ввиду грабли, с которыми сталкивался вот этот человекНу кто ж ему злобный буратино, если он при создании пула использовал физическое именование (/dev/da*) GEOM-провайдеров вместо GPT UUID (/dev/gtpid/6e56389f-81a6-11de-8aa6-02508d92a2eb) или GPT Label (/dev/gpt/disk*)?
>Для обычных дисков в geom такую ситуацию представить себе просто невозможно.
Скажем так, вы несколько не правы. Все носители — "обычные диски" (как блочные устройства) — работают как GEOM-провайдеры. Почитайте man glabel(8) и tunefs(8) про их метки и идентификаторы.
>>Имела ввиду грабли, с которыми сталкивался вот этот человек
>
>Ну кто ж ему злобный буратино, если он при создании пула использовал
>физическое именование (/dev/da*) GEOM-провайдеров вместо GPT UUID (/dev/gtpid/6e56389f-81a6-11de-8aa6-02508d92a2eb) или GPT Label
>(/dev/gpt/disk*)?По тому, что не очевидно :)
Geom, и его пользовательские интерфейсы живут своей жизнью, а ZFS своей.
Я бы даже сказала, что лучше добавлять вообще хотя бы слайс с меткой(или просто слайс), что бы можно было заменить умерший диск на диск другой геометрии.>>Для обычных дисков в geom такую ситуацию представить себе просто невозможно.
>
>Скажем так, вы несколько не правы. Все носители — "обычные диски" (как
>блочные устройства) — работают как GEOM-провайдеры. Почитайте man glabel(8) и tunefs(8)
>про их метки и идентификаторы.Да, я опять криво выразилась. Конечно, там могут быть не только "обычные диски", но и слайсы, и лэйблы сверху слайсов, и даже импортированные устройства по какому-нибудь протоколу вроде AoE.
с какими?
Что-то я тут http://www.codestrom.com/wandering/2009/03/zfs-vs-btrfs-comp... кроме online resizing пожалуй ничего и не нашёл.
Что-то? ZFS не умеет менять размер на лету? Это кто не осилил изучить матчасть?Когда к ZFS-пулу добавляешь устройство верхнего уровня, то размер пула автоматически увеличивается, соответственно, свободное место, доступное файловым системам в пуле — тоже.
Для уменьшения размеров пула... Тут да, нужно изгальнуться со снапшотами/клонами файловых систем, чтобы их перетасовать в пул меньшего размера.
Zfs не умеет увеличивать раздел raidz и raidz2. Одним 0 и 1 рейдом сыт не будешь, без raidz zfs теряет одну из самых вкусных фич.Кроме того, в zfs нет дефрагментации. Недостаток многие пользователи уже заценили - в СOW ФС можно быстро случайно писать, но вот потом при попытке будто бы "линейного" чтения из файла можно получить черепашью скорость.
>Zfs не умеет увеличивать раздел raidz и raidz2. Одним 0 и 1
>рейдом сыт не будешь, без raidz zfs теряет одну из самых
>вкусных фич.Несколько RAID-5(-6) массивов, помещённых в один пул, не теряют в надёжности. Тем более, если есть носители горячей замены. Например, можно держать в пуле несколько RAIDZ и один-два носителя горячей замены для устройств верхнего уровня пула. При этом полезный объём будет таким же, как если бы использовалось одно устройство верхнего уровня RAIDZ*.
>Кроме того, в zfs нет дефрагментации.У неё и фрагментация на нуле, поскольку используются блоки данных переменного размера и большая память для кэширования часто используемых данных.
>Недостаток многие пользователи уже заценили - в СOW ФС можно быстро случайно писать, но вот потом при попытке будто бы "линейного" чтения из файла можно получить черепашью скорость.
Не замечал. Интенсивно использую носитель с ZFS около 6 месяцев. Винчестер заполнен наполовину.
> Несколько RAID-5(-6) массивов, помещённых в один пул, не теряют в надёжности. Тем более, если есть носители горячей замены. Например, можно держать в пуле несколько RAIDZ и один-два носителя горячей замены для устройств верхнего уровня пула. При этом полезный объём будет таким же, как если бы использовалось одно устройство верхнего уровня RAIDZ*Это называется "сделать RAID 50 из RAID5". Да, это есть. Если вы можете на это пойти, т.е есть куда вставить пачку дисков и не против потрерять еще один-два диска на избыточность.
Расширения существующего RAIDZ, скажем из конфигурации 6 дисков перейти к 8 невозможно. А в серваке 8 мест под диски, и что прикажете делать? ага, бэкапить все, уничтожать рейд, создавать новый на 8 дисков..И не надо давать отмазки, zfs не поддерживает ни расширение, ни уменьшение. Только добавление новых дисков в пул с последующим страйпингом на него новых данных. Расширение рейда невозможно.
> Не замечал. Интенсивно использую носитель с ZFS около 6 месяцев. Винчестер заполнен наполовину.
Если поработать с заполнением 90% или агрессивно использовать снапшоты, скорость реально падает. Иногда может в десятки раз. Само по себе это не фатально. Фатально то, что кроме как бэкап-переформатировать-восстановить это не лечится.
> У неё и фрагментация на нуле, поскольку используются блоки данных переменного размера и большая память для кэширования часто используемых данных.
Хех, если бы. Говорю же - когда много что случайно пишется, с дизайном COW возникает фрагментация "последовательных" данных. Записать быстро выходит (за счет чего zfs заруливает некоторые другие вещи), а прочитать потом - фиг.
Зачем писать "на нуле" когда по инету полно примеров zfs с производительностью, убитой фрагментацией? На родной солярке. Но этому и btrfs будет подвержена, разница в том, что там есть инструмент для лечения, а в zfs нет..
http://www.mail-archive.com/zfs-discuss@opensolaris.org...
> zfs не поддерживает ни расширение, ни уменьшение. Только добавление новых дисков в пул с последующим страйпингом на него новых данных. Расширение рейда невозможно.wrong.
ZFS поддерживает поочередную замену менее емких дисков в RAIDZ* на более емкие, с промежуточным resilvering'ом (a.k.a "zpool scrub"). Размер pool'а увеличится после замены последнего диска.
Да, диск заменить можно. Но обычно не нужно (куда старые девать? выкидывать?). А вот довоткнуть и расширить таким образом - нужно.
>Да, диск заменить можно. Но обычно не нужно (куда старые девать? выкидывать?).Использовать для менее критичных задач, например. С возрастом диски лучше не становятся.
>> Несколько RAID-5(-6) массивов, помещённых в один пул, не теряют в надёжности. Тем более, если есть носители горячей замены. Например, можно держать в пуле несколько RAIDZ и один-два носителя горячей замены для устройств верхнего уровня пула. При этом полезный объём будет таким же, как если бы использовалось одно устройство верхнего уровня RAIDZ*
>
>Это называется "сделать RAID 50 из RAID5". Да, это есть. Если вы
>можете на это пойти, т.е есть куда вставить пачку дисков и
>не против потрерять еще один-два диска на избыточность.
>Расширения существующего RAIDZ, скажем из конфигурации 6 дисков перейти к 8 невозможно.
>А в серваке 8 мест под диски, и что прикажете делать?
>ага, бэкапить все, уничтожать рейд, создавать новый на 8 дисков..Ох и тупо вы подошли к планированию RAID. :) А вам не приходило в голову, что пулы можно комбинировать (вложить один в другой)? Правда, свободные места распределятся уже по пулам, но найти применение такой конфигурации уже легче (в случае частичной замены дисков на более ёмкие), чем делать из 8 дисков одно виртуальное устройство в пуле.
>Если поработать с заполнением 90% или агрессивно использовать снапшоты, скорость реально падает.
>Иногда может в десятки раз. Само по себе это не фатально.
>Фатально то, что кроме как бэкап-переформатировать-восстановить это не лечится.Автор ZFS пишет, что у него не та система, что у вас (основной вывод в конце цитаты):
"Карты пространства имеют несколько интересных свойств:
* Не требуют инициализации: карта пространства без записей показывает, что операций выделения и освобождения блоков не было, все пространство доступно
* Хорошо масштабируются: поскольку новые диапазоны только добавляются в конец объекта "карта пространства", для получения наилучшей производительности в памяти нужно хранить только лишь последний блок этого объекта, вне зависимости от того, пространством какого размера мы управляем
* Не подвержены патологиям: карты пространства можно эффективно обновлять, независимо от последовательности операций выделения и освобождения
* Одинаково эффективны при выделении свободного места, как при пустом, так и при заполненном пуле (в отличие от битовых карт, на сканирование которых требуется всё больше и больше времени по мере их наполнения)Помимо этого, нужно отметить, что когда свободное пространство, описываемое картой, полностью исчерпано, для ее представления достаточно одного диапазона. Поэтому карты пространства имеют прекрасное свойство: по мере приближения заполненности пула к 100%, карты пространств�� начинают буквально "испаряться", занимая всё меньше и меньше места, давая возможность максимально использовать имеющееся дисковое пространство для хранения полезной информации."
http://blogs.sun.com/bonwick/ru/category/ZFS
>А вам не приходило в голову, что пулы можно комбинировать (вложить один в другой)?Что это вы тут имеете ввиду?
>Винчестер заполнен наполовину.Заполни его процентов на 90-95, желательно записывая файло чем-то типа торентов и зацени, потом нам доложишь как оно (да, я добрый, я знаю :D).
> Заполни его процентов на 90-95, желательно записывая файло чем-то типа торентов и зацени,
> потом нам доложишь как оно (да, я добрый, я знаю :D)Неважно, чем его заполнить -- хоть образами BD. Скорость будет черепашьей.
Я задавал этот вопрос на Sun Tech Days 2008 архитектору ZFS. Он ответил буквально следующее:
-- Ввиду специфики работы Copy-on-Write аллокатор будет тормозить _всегда_ при малом остатке выделяемого пространства -- хоть в случае ZFS, хоть в случае Squid'а. Мы пытаемся бороться с этой проблемой, но в данном случае инвестировать в какие-то супероптимизированные алгоритмы смысла не имеет -- при современной стоимости дискового пространства проще добавить дисков в пул.
Так что вот так вот.
P.S: Угадайте, почему при инсталляции FreeBSD рекомендуют делать своп в два раза больше размера физического ОЗУ, при этом не забывая добавить, что как только своп заполнится наполовину, ОЗУ надо добавлять. Правильно, для того, чтобы быстро работал Zone Allocator в ядре. Он ведь тоже Copy-on-Write...
там, где принимают решения, нету понятия супероптимизация любой ценой, там есть понятие целесообразность за вот эти бабки.PS я лично такое не одобряю как юзер\разработчик
>> Заполни его процентов на 90-95, желательно записывая файло чем-то типа торентов и зацени,
>> потом нам доложишь как оно (да, я добрый, я знаю :D)
>
>Неважно, чем его заполнить -- хоть образами BD. Скорость будет черепашьей.При заполненности 95% скорость будет черепашьей на любой ФС, даже не CoW. Просто в случае с ФС из прошлого века добавить места - это целая история (и иногда проще плюнуть, чем связываться), в то время как с BTRFS и ZFS это делается легко и просто.
>>> Заполни его процентов на 90-95, желательно записывая файло чем-то типа торентов и зацени,
>>> потом нам доложишь как оно (да, я добрый, я знаю :D)
>>
>>Неважно, чем его заполнить -- хоть образами BD. Скорость будет черепашьей.
>
>При заполненности 95% скорость будет черепашьей на любой ФС, даже не CoW.
>Просто в случае с ФС из прошлого века добавить места -
>это целая история (и иногда проще плюнуть, чем связываться), в то
>время как с BTRFS и ZFS это делается легко и просто.Что-то Вы путаете :) Если имелись ввиду ext2 и xfs, конечно: всегда парой команд увеличивались, и уменьшались (в случае с ext[234]). Естественно, при использовании LVM под ФС
даже и без LVM, но xfs может только расти
>даже и без LVM, но xfs может только растиА я разве написала по-другому :)?
>даже и без LVM, но xfs может только растиУв. Аноноим как бы ставит нам нетривиальную задачу:
Дано: ФС заполнена на 90-95% и начала тормозить.
Вопрос: Как уменьшить её размер, чтобы перестало тормозить?
> Естественно, при использовании LVM под ФСВот именно об этом и речь. Ну и о всяких других приятностях, вроде зависимости максимального размера ФС от размера блока, выбранного в момент создания и т.д.
>> Естественно, при использовании LVM под ФС
>
>Вот именно об этом и речь. Ну и о всяких других приятностях,
>вроде зависимости максимального размера ФС от размера блока, выбранного в момент
>создания и т.д.Не использовать LVM в Linux довольно глупо: такой же способ наказать себя, как и не использовать geom во фре, хотя и с другими плюсами и минусами (с путающимися дисками и точками монтирования, глючными фэйк-рейдами через atacontrol, вместо gmirror и тд)
В линухе все завязано на device-mapper, и его использование, самый верный путь. Взамен Вы получаете кучу других плюсов.
>Не использовать LVM в Linux довольно глупо: такой же способ наказать себя,
>как и не использовать geom во фре, хотя и с другими
>плюсами и минусами (с путающимися дисками и точками монтирования, глючными фэйк-рейдами
>через atacontrol, вместо gmirror и тд)Так никто не спорит. Вот только жить приходится в далеко не идеальном мире, где можно встретить все, что угодно. К тому же, LVM ничем не поможет, если достигнут максимальный размер файловой системы для размера блока, выбранного при ее создании. Или если есть место, но кончились иноды, или еще чего.
>Так никто не спорит. Вот только жить приходится в далеко не идеальном
>мире, где можно встретить все, что угодно.Мы приципиально, что бы не браться за что-то кем-то криво настроенное, пересетапливаем все клиентские серверы по нашим шаблонам и инструкциям (с предоставлением, обычно, нашего временного сервера что бы не было даунтайма сервисам).
В большой(и не только большой, где хотя бы несколько серверов) сети, с вменяемым IT-отделом, имхо, нужно поступать так же. Косолапо настроенных сервисов не должно быть, или, в крайнем случае, все баги и косолапости должны быть отражены во внутреннем багтракере, и должна быть нормальная документация.
>К тому же, LVM
>ничем не поможет, если достигнут максимальный размер файловой системы для размера
>блока, выбранного при ее создании. Или если есть место, но кончились
>иноды, или еще чего.В линухе такое обилие файловых систем с разными характеристиками под разные задачи, что это давно не актуально. А исчерпать место на той же ext4 очень и очень сложно.
Правда, жалко, что пока ext4 не работает с OVZ-ядрами, но это временно.Во фре же мы видим лишь достаточно специализированную ZFS и допотопную UFS.
Тогда как btrfs не будет единственной фс, когда будет достаточно стабильна, хотя бы по тому, что как и ZFS не является параллельной ФС.
>>Так никто не спорит. Вот только жить приходится в далеко не идеальном
>>мире, где можно встретить все, что угодно.
>
>Мы приципиально, что бы не браться за что-то кем-то криво настроенное, пересетапливаем
>все клиентские серверы по нашим шаблонам и инструкциям (с предоставлением, обычно,
>нашего временного сервера что бы не было даунтайма сервисам).Вы, конечно, молодцы.
>В большой(и не только большой, где хотя бы несколько серверов) сети, с
>вменяемым IT-отделом, имхо, нужно поступать так же. Косолапо настроенных сервисов не
>должно быть, или, в крайнем случае, все баги и косолапости должны
>быть отражены во внутреннем багтракере, и должна быть нормальная документация.И в идеальном мире все действительно должно быть так, как вы описываете. Но к сожалению суровая реальность дана нам в ощущениях.
>В линухе такое обилие файловых систем с разными характеристиками под разные задачи,
>что это давно не актуально. А исчерпать место на той же ext4 очень и очень сложно.ext4 - давно? По мне так совсем недавно.
>Правда, жалко, что пока ext4 не работает с OVZ-ядрами, но это временно.
Вот видите, вы и сами пишете, что еще и не везде ее использовать можно.
Да тут собственно не только о Линуксе речь. Если взять ту же VxFS, то там тоже есть (во всяком случае, были, когда я в последний раз заглядывал в документацию по пятой версии) разные "забавные" ограничения, вроде зависимости максимального размера.
Думаю, что подобные "сюрпризы" все еще имеются много где. Конечно, они постепенно отживают свое, но тем не менее.
>Тогда как btrfs не будет единственной фс, когда будет достаточно стабильна, хотя
>бы по тому, что как и ZFS не является параллельной ФС.pNFS наше все :-)
> глючными фэйк-рейдами через atacontrolвот тут пожалуйста по подробнее, где там глюки и где фейк.
>> глючными фэйк-рейдами через atacontrol
>
>вот тут пожалуйста по подробнее, где там глюки и где фейк.Хорошо про фейк-рейды, например, написано тут:
http://3nity.ru/viewtopic.php?f=24&t=13008
Учите матчасть!
В кратце, "китайская", в худшем значении этого нарицательного слова железка с софтовым рейдом "индусской" (аналогично "китайской") реализации всегда хуже, чем
нормальный софт-рейд(mdraid, geom/gmirror/gstripe),созданный разработчиками ОС, разработавшими, например, файловую систему. Даже если эти разработчики и написали драйвер для фейк-рейда, все равно он будет заведомо хуже, чем нормальный софт-рейд, который пилили несколько лет.
З.Ы. конечно, те же аппаратные Adaptec, тоже не насквозь американские, тем, кто захочет придраться, предлагаю обратить внимание на кавычки в посте.
Но бюжет на разработку нормального контроллера и фейк-рейда может отличаться не на один порядок (как и человеко-часы коммюнити на разработку md/geom, и постинг багов, которые постят просто чаще из-за большей распространенности, и чаще исправляют)
далеко не факт.пример: купил один винт, создал на нем фс и сразу же забил на 99 процентов под завязку за один заход в один поток фильмами по 50 гигабайт и выложил в локалку для файлопомойки.
старые винты на которых это все файло было - распродал\раздал нуждающимся.
>Я задавал этот вопрос на Sun Tech Days 2008 архитектору ZFS. Он
>ответил буквально следующее:
>-- Ввиду специфики работы Copy-on-Write аллокатор будет тормозить _всегда_ при малом
>остатке выделяемого пространства --В чем-то он тут прав - для CoW механики это и правда неудобная ситуация, придется часто дергаться на сборку мусора чтобы вообще хоть что-то смочь записать. И фрагментация взлетит до небес, при том сильнее чем на классической ФС по идее. Вот только ... делая сборку мусора логично сделать до кучи некую дефрагментацию, оно прямо напрашивается, блин. Операции достаточно похожие по смыслу и делая первое явно можно попутно сделать и второе. Насколько я понял - сани при сборе мусора почему-то до кучи и дефраг - не делают?oO Кто там хорошо в устройстве ФС шарит - пролейте свет на этот вопрос?
>>Я задавал этот вопрос на Sun Tech Days 2008 архитектору ZFS. Он
>>ответил буквально следующее:
>>-- Ввиду специфики работы Copy-on-Write аллокатор будет тормозить _всегда_ при малом
>>остатке выделяемого пространства --
>
>В чем-то он тут прав - для CoW механики это и правда
>неудобная ситуация, придется часто дергаться на сборку мусора чтобы вообще хоть
>что-то смочь записать.Какая сборка мусора, ты о чем?
> И фрагментация взлетит до небес, при том сильнее чем на классической ФС по идее.
Все носятся с этой фрагментацией как с писаной торбой. Безусловно, последовательное чтение объекта, состоящего из блоков маленького размера, которые расположены случайным образом, будет страдать, если нет никаких других механизмов с этим бороться. Но далеко не все задачи в современном IT мире сводятся к последовательному чтению. Если же чтение случайное - то случайный разброс блоков вообще пофиг, более того, он может оказаться выигрышнее, нежели их строго последовательное расположение.
Плюс с эффектами оной можно бороться не только дефрагментацией. Есть такое слово - кэширование. Знакомо?
> Вот только ... делая сборку мусора логично сделать до кучи некую дефрагментацию, оно прямо напрашивается, блин.
Дефрагментация имеет смысл на не-CoW системах. Для систем, построенных на CoW, смысла гораздо меньше - потому как CoW будет тут же эффект от дефрагментации нивелировать. Тем не менее, смысл есть - имеет смысл дефрагментировать свободное пространство и неизменяемые данные (снимки).
Специально для тебя повторяю еще раз: дефрагментация - не единственный способ борьбы с эффектами от фрагментации.
>Какая сборка мусора, ты о чем?Слияние снапшотов и подобные по смыслу операции для расчистки тома, которые придется делать чтобы освободить место на нем. Собственно CoW логика кроме плюсов имеет и минусы - если что-то пишется в сторонку, это во первых вызывает усиление фрагментации а во вторых добавляет новые данные. И если ничего по этому поводу не делать - место то не резиновое, бесконечно дописывать в сторонку - не выйдет. Если честно - я не очень сильно изучал как ZFS разруливает подобные ситуации (в манах это как-то мало упоминается) и вы в своем вправе вправить мне мозг. Единственное что я понял из манов - что в ZFS по сути не делается каких-то специальных потуг дефрага при подобных операциях.
>> И фрагментация взлетит до небес, при том сильнее чем на классической ФС по идее.
>Все носятся с этой фрагментацией как с писаной торбой.Дык я не виноват что фрагментированый доступ убивает скорость доступа на механических дисках в уйму раз, как и стопицот лет назад.
>Безусловно, последовательное чтение объекта, состоящего из блоков маленького размера, >которые расположены случайным образом, будет страдать, если нет никаких других
>механизмов с этим бороться. Но далеко не все задачи в современном IT мире
>сводятся к последовательному чтению.Знаете как про это говорят? :) "С пола упасть нельзя!" :).Действительно, если ФС уже и так в полной ж... - хуже ей уже не будет, как ни извращайся :)
>более того, он может оказаться выигрышнее, нежели их строго последовательное
>расположение.Скорее, я сделаю ставку на "монопенисуально". Рандом доступ на то и рандом. Если это не так - значит это уже не рандом.
>Плюс с эффектами оной можно бороться не только дефрагментацией. Есть такое слово
>- кэширование. Знакомо?Знакомо. Но при современных объемах дисков более-менее полно их закешировать нереально. А так то ессно да, можно быстро выдавить в кеш а там пусть себе ФС хоть час педалит. Только палка о двух концах. Куча данных в оперативке имеет свойство теряться при сбоях + это не заслуга файловой системы, а заслуга кеша, как ни крути.
>Дефрагментация имеет смысл на не-CoW системах.
Да и на CoW имеет смысл. Тем более что логично накладывается на процедуру слияния-удалния снапшотов и т.п. - почему бы при слиянии заодно и блоки попоследовательнее не выстроить до кучи? Вполне логичное решение ведь.
>Для систем, построенных на CoW, смысла гораздо меньше
ИМХО это сильно зависит от того как используется ФС. В упомянутом случае (торент) это имеет стопроцентный смысл. Потому что торент сам по себе то срач блоками разводит, CoW ему еще подыграет а из-за засранного на 90% тома без больших свободных линейных кусков вообще получится полный крантец. А вот если этот мяумикс отдефрагить - так как бы скачанные файлы никто и не модифицирует особо, например...
>- потому как CoW будет тут же эффект от дефрагментации нивелировать.
Только в случае интенсивной дозаписи. И как бы далеко не любой файл в ФС подвергается постоянной интенсивной записи. Посему оно будет нивелировано только для постоянно записываемых файлов которые и на обычной то ФС засираются. К слову на обычной ФС они засираются несколько меньше, т.к. ФС может переписат блок прямо в файле, оставив доступ последовательным, а в CoW логике так уже не катит.
>Тем не менее, смысл есть - имеет смысл дефрагментировать
>свободное пространство и неизменяемые данные (снимки).Кроме того - а некоторые файлы вообще мало или редко меняются. Упомянутое вами валидно если файл меняется часто и много. Только при этом CoW неплохой срач разведет. Да, запись будет быстрой, но это будет иметь свои минусы. Не бывает халявы нахаляву :)
>Специально для тебя повторяю еще раз: дефрагментация - не единственный способ борьбы
>с эффектами от фрагментации.Угу, конечно. Если все хранить в RAMдиске, доступ к ним будет моментальным. Только это не достоинство ФС ни разу, и без гигантских дисковых буфферов все это будет крайне уныло тормозить. Уж не потому ли ZFS и требует вагон памяти для нормальной работы? :)
> если что-то пишется в сторонку, это во
>первых вызывает усиление фрагментации а во вторых добавляет новые данные. И
>если ничего по этому поводу не делать - место то не
>резиновое, бесконечно дописывать в сторонку - не выйдет.Ранее занятое место освобождается, если на него более никто не ссылается. Место, на которое ссылаются снимки, освобождается тогда, когда удаляются снимки. Не думаю, что где-то принципиально по-другому
> Единственное что я понял из манов - что в
>ZFS по сути не делается каких-то специальных потуг дефрага при подобных
>операциях.А в BTRFS делаются? Ссылочку можно?
>>Плюс с эффектами оной можно бороться не только дефрагментацией. Есть такое слово
>>- кэширование. Знакомо?
>
>Знакомо. Но при современных объемах дисков более-менее полно их закешировать нереально.Хорошо что знакомо. Следующий вопрос. Что такое "рабочий набор" представляешь?
Никто в здравом уме не будет кэшировать диски целиком. Нужно закэшировать рабочий набор, который, как правило, бывает на порядок-другой меньше по размеру, чем все данные приложения.
>А так то ессно да, можно быстро выдавить в кеш а там пусть себе ФС хоть час педалит. Только палка о двух концах. Куча данных в оперативке имеет свойство теряться при сбоях + это не заслуга файловой системы, а заслуга кеша, как ни крути.В случае классической ФС, жестко завязанной на кэш VM - да. Следующий вопрос - что такое ARC, L2ARC и как они связаны и зачем они нужны, понимаешь?
>>Дефрагментация имеет смысл на не-CoW системах.
>
>Да и на CoW имеет смысл.О чем я и говорил чуть дальше.
> Тем более что логично накладывается на
>процедуру слияния-удалния снапшотов и т.п. - почему бы при слиянии заодно
>и блоки попоследовательнее не выстроить до кучи? Вполне логичное решение ведь.А поподробнее? Чтобы всем была понятна твоя логика.
>Только в случае интенсивной дозаписи.
А говоря CoW, мы ведь имеем ввиду запись, не так ли?
>И как бы далеко не любой файл
>в ФС подвергается постоянной интенсивной записи. Посему оно будет нивелировано только
>для постоянно записываемых файлов которые и на обычной то ФС засираются.Естественно, для немодифицируемых файлов это тоже имеет смысл, но я бы сказал что в третью очередь, после свободного пространства и неизменяемых данных. И кстати, большинство их этих малоизменяемых файлов наверняка будут целиком в каком-нибудь снимке, так что на них тоже снизойдет благодать в виде живительной дефрагментации
>>Тем не менее, смысл есть - имеет смысл дефрагментировать
>>свободное пространство и неизменяемые данные (снимки).
>
>Кроме того - а некоторые файлы вообще мало или редко меняются. Упомянутое
>вами валидно если файл меняется часто и много. Только при
>этом CoW неплохой срач разведет. Да, запись будет быстрой, но это
>будет иметь свои минусы. Не бывает халявы нахаляву :)Чтение можно сделать не менее быстрым, используя L2ARC. Но в классических ФС ничего подобного нету, впрочем, и в BTRFS тоже пока не наблюдается.
>>Специально для тебя повторяю еще раз: дефрагментация - не единственный способ борьбы
>>с эффектами от фрагментации.
>
>Угу, конечно. Если все хранить в RAMдиске, доступ к ним будет моментальным.Боюсь, мошна не выдержит все хранить в рамдиске, так как много памяти и слотов для нее - удовольствие не из дешевых.
>Только это не достоинство ФС ни разу, и без гигантских дисковых
>буфферов все это будет крайне уныло тормозить. Уж не потому ли
>ZFS и требует вагон памяти для нормальной работы? :)Ну-ну. Там, где ты со своим рамдиском упрешься в ограничения количества и емкости модулей памяти платформы, ZFS позволит запихнуть парочку емких SSD для L2ARC. Ты будешь и дальше утверждать, что это не достоинство ФС?
>Я задавал этот вопрос на Sun Tech Days 2008 архитектору ZFS. Он
>ответил буквально следующее:Думаю, что ответ, полученный в 2008 году, можно уже и забыть. С тех пор много чего изменилось, да и сейчас не стоит на месте.
А что такого принципиально крутого и нового сделано за 2 года? Структуры то все те же самые по сути, куда ж они денутся то. Посему общие их свойства останутся теми же что и два года назад. При том думается товарисч архитект прав и не только насчет ZFS-а, а насчет CoW вообще. Ну да, неудобно CoW-у будет работать при душняке места в общем случае. Но чем лучше ФС выдерживает всякие издевательства не становясь жутко тормозной, тем лучше.
>А что такого принципиально крутого и нового сделано за 2 года? Структуры
>то все те же самые по сути, куда ж они денутся
>то.Святая простота. Структура, используемая для хранения информации о свободном месте на диске действительно одна и та же. Но она никакого отношения не имеет к политике поиска и выделения места, которую можно менять как заблагорассудится. Сдается мне, я тебе это уже объяснял. Сколько еще нужно обеден?
>Посему общие их свойства останутся теми же что и два
>года назад. При том думается товарисч архитект прав и не только
>насчет ZFS-а, а насчет CoW вообще.Ты бы хоть имя своего "товарища архитекта" выучил, чтоли.
>Ну да, неудобно CoW-у будет
>работать при душняке места в общем случае. Но чем лучше ФС
>выдерживает всякие издевательства не становясь жутко тормозной, тем лучше.Про BTRFS в этом плане неизвестно пока вообще ничего. Вон, твой авторитет fresco обещал отписаться по результатам, так что посмотрим.
>P.S: Угадайте, почему при инсталляции FreeBSD рекомендуют делать своп в два раза
>больше размера физического ОЗУ, при этом не забывая добавить, что как
>только своп заполнится наполовину, ОЗУ надо добавлять.Помню, такое я читал в устаревшем хэндбуке у Лукаса, который рассказывал, как надо правильно устанавливать и настраивать FreeBSD 4.11. Но ведь до 2002 года трудно было представить обычный писюк с >=1ГБ RAM на борту. Это было слишком дорого. А при ~256МБ ОЗУ размер SWAP естественным образом укладывался в формулу SWAP_SIZE=2*RAM_SIZE+N [Mb], где параметр N — уже зависел от задач, не связанных с обслуживанием операционной системы.
>Правильно, для того, чтобы быстро работал Zone Allocator в ядре. Он ведь тоже Copy-on-Write...
Неправильно.
>>Кроме того, в zfs нет дефрагментации.
>
>У неё и фрагментация на нуле, поскольку используются блоки данных переменного размера
>и большая память для кэширования часто используемых данных.Оба два неправы. При постраничной работе с большими файлами (читай, базами данных) при перезаписи страницы пишутся в новое место (COW так работает). В результате один большой многогиговый файл оказывается размазанным по диску как каша по тарелке. Дефрагментация, кстати, простая - достаточно скопировать фрагментированные файлы, они запишутся по возможности линейно.
>У неё и фрагментация на нуле, поскольку используются блоки данных переменного размера
>и большая память для кэширования часто используемых данных.Чувак, а тебя не смущает что смысл работы CoW - в том что измененный блок файла пишется в НОВОЕ место на диске. Что хотя и дает недеструктивную запись, но в отместку просто ПО ОПРЕДЕЛЕНИЮ означает некую фрагментацию. Ведь если блок файла в стороне - он, очевидно, отдельный фрагмент, yeah? :D
> Чувак, а тебя не смущает что смысл работы CoW - в том что измененный блок файла пишется в НОВОЕ место на диске. Что хотя и дает недеструктивную запись, но в отместку просто ПО ОПРЕДЕЛЕНИЮ означает некую фрагментацию. Ведь если блок файла в стороне - он, очевидно, отдельный фрагмент, yeah? :DНу означает, ну и че дальше? При размере блока в 128К эффекты от непоследовательного расположения блоков ощущаются сильно меньше, чем при размере блока в 4К (128К - это все равно что 32 последовательных блока по 4К). А когда у тебя много устройств в пуле, предвыборка работает, да еще какая-нибудь ReadZillа имеется - вообще можешь ничего не заметить.
Сколько еще раз тебе это объяснять нужно?
>> Чувак, а тебя не смущает что смысл работы CoW - в том что измененный блок файла пишется в НОВОЕ место на диске. Что хотя и дает недеструктивную запись, но в отместку просто ПО ОПРЕДЕЛЕНИЮ означает некую фрагментацию. Ведь если блок файла в стороне - он, очевидно, отдельный фрагмент, yeah? :D
>
>Ну означает, ну и че дальше? При размере блока в 128К эффекты
>от непоследовательного расположения блоков ощущаются сильно меньше, чем при размере блока
>в 4К (128К - это все равно что 32 последовательных блока
>по 4К). А когда у тебя много устройств в пуле, предвыборка
>работает, да еще какая-нибудь ReadZillа имеется - вообще можешь ничего не
>заметить.
>
>Сколько еще раз тебе это объяснять нужно?А когда в пуле всего два диска, например, два локальных SAS (или SSD) под зеркало в обычном 1u сервере под тяжелую БД?
cow, как уже сказали, часто значит большой и лишний оверхед. ZFS, и, вероятно будет btrfs, это мощнейшая файловая система, но пихать ее в каждую дырку, имхо, очень не разумно :(
А под эту задачу ext4 будет смотреться гораздо лучше.
>А когда в пуле всего два диска, например, два локальных SAS (или
>SSD) под зеркало в обычном 1u сервере под тяжелую БД?два диска... сервер 1u... тяжелая БД... Как-то не вяжется.
>cow, как уже сказали, часто значит большой и лишний оверхед.
Насчет большой и лишний можно поспорить, но накладные расходы безусловно есть. Но там, где все настолько тяжело, что они становятся недопустимы, скорее будут использовать дисковые массивы напрямую, безо всяких файловых систем.
>ZFS, и, вероятно будет btrfs, это мощнейшая файловая система, но пихать ее в
>каждую дырку, имхо, очень не разумно :(
>А под эту задачу ext4 будет смотреться гораздо лучше.Лучше или хуже - зависит не от ФС как таковой, а от требований к проекту. Не находите?
Где-то действительно будет лучше обойтись чем-нибудь простым как палка - типа ext4 или UFS. Где-то еще - может потребоваться что-то с большими возможностями и/или гарантиями.
>>А когда в пуле всего два диска, например, два локальных SAS (или
>>SSD) под зеркало в обычном 1u сервере под тяжелую БД?
>
>два диска... сервер 1u... тяжелая БД... Как-то не вяжется.Хорошо, средне-тяжелая... У проектов еще бывает бюджет :) А два SSD по iops заткнут за пояс если не low-end DAS, то любой старый сервер 2U набитый SCSI точно (хотя у SSD и ресурс никакой, в ряде случаев они рулят)
>>cow, как уже сказали, часто значит большой и лишний оверхед.
>
>Насчет большой и лишний можно поспорить, но накладные расходы безусловно есть. Но
>там, где все настолько тяжело, что они становятся недопустимы, скорее будут
>использовать дисковые массивы напрямую, безо всяких файловых систем.Да, тут Вы безусловно правы! raw-device рулят (как и снапшоты Logical Volume без файловой системы)
>>ZFS, и, вероятно будет btrfs, это мощнейшая файловая система, но пихать ее в
>>каждую дырку, имхо, очень не разумно :(
>>А под эту задачу ext4 будет смотреться гораздо лучше.
>
>Лучше или хуже - зависит не от ФС как таковой, а от
>требований к проекту. Не находите?
>
>Где-то действительно будет лучше обойтись чем-нибудь простым как палка - типа ext4
>или UFS. Где-то еще - может потребоваться что-то с большими возможностями
>и/или гарантиями.И тут Вы правы: что просто мне не нравится _в_ситуации_, так это то, что с ZFS долгое время носились как с писанной торбой, толкая ее в каждую дырку, и превознося чудесные особенности.
Несомненно, под сторадж из кучи SATA-дисков под бэкапы, файлохранилище, и т д, она просто непревзойденная, но вот на других задачах, имхо, не так и нужна, где более удобны совсем другие файловые системы.
>>>А когда в пуле всего два диска, например, два локальных SAS (или
>>>SSD) под зеркало в обычном 1u сервере под тяжелую БД?
>>
>>два диска... сервер 1u... тяжелая БД... Как-то не вяжется.
>
>Хорошо, средне-тяжелая... У проектов еще бывает бюджет :)Ага, именно. И с точки зрения бюджета у ZFS тоже все неплохо, как, впрочем, и у ext4, XFS и кого там еще.
> А два SSD по
>iops заткнут за пояс если не low-end DAS, то любой старый
>сервер 2U набитый SCSI точно (хотя у SSD и ресурс никакой,
>в ряде случаев они рулят)А гибридный пул позволит объединить преимущества дешевых емких медленных дисков с дорогими быстрыми маложивущими SSD, эффективно используя ресурс последних.
>Да, тут Вы безусловно правы! raw-device рулят (как и снапшоты Logical Volume
>без файловой системы)Я тут скорее даже не про LVM'ы, а про всякие монструозные дисковые массивы со встроенной репликацией, снимками клонами и прочими плюшками.
>>Лучше или хуже - зависит не от ФС как таковой, а от
>>требований к проекту. Не находите?
>>
>>Где-то действительно будет лучше обойтись чем-нибудь простым как палка - типа ext4
>>или UFS. Где-то еще - может потребоваться что-то с большими возможностями
>>и/или гарантиями.
>
>И тут Вы правы: что просто мне не нравится _в_ситуации_, так это
>то, что с ZFS долгое время носились как с писанной торбой,
>толкая ее в каждую дырку, и превознося чудесные особенности.Ну, скажем прямо, особенности действительно есть, и неплохие, за один сквозной контроль целостности можно много дать. Впрочем, у любой медали две стороны... :-)
>Несомненно, под сторадж из кучи SATA-дисков под бэкапы, файлохранилище, и т д,
>она просто непревзойденная, но вот на других задачах, имхо, не так
>и нужна, где более удобны совсем другие файловые системы.Безусловно есть задачи, где ZFS просто неприменима - например, там, где нужен одновременный доступ к носителям с двух или более машин. Но ограничивать сферу использования ZFS только бэкапами и файлохранением тоже не стоит.
>> А два SSD по
>>iops заткнут за пояс если не low-end DAS, то любой старый
>>сервер 2U набитый SCSI точно (хотя у SSD и ресурс никакой,
>>в ряде случаев они рулят)
>
>А гибридный пул позволит объединить преимущества дешевых емких медленных дисков с дорогими
>быстрыми маложивущими SSD, эффективно используя ресурс последних.Иногда в серверах банально не хватает корзин, я по тому и упомянула 1u машину.
>Ну, скажем прямо, особенности действительно есть, и неплохие, за один сквозной контроль
>целостности можно много дать. Впрочем, у любой медали две стороны... :-)Он не везде нужен: raid вообще не средство гарантии сохранности информации, он им не может быть просто по дизайну идеи. Такой гарантией может быть только off-site бэкап.
Не должно существовать проекта без географически удаленного бэкапа, но может существовать проект без рейда.
Рейд лишь средство добавления девяток после запятой в уровень стабильности сервиса: в случае порчи данных/файловой системы гарантирован даунтайм на восстановление из бэкапов, но рейд не может нас предостеречь от софтовой ошибки(когда данные, записанные на файловую систему уже некорректны), от взлома сервера (и rm -rf /, или компроментации и тотального трояненья данных) от банального уничтожения сервера по-отдельности, или с дата-центром(как это было недавно с хостинг.уа)Настоящие гарантии могут дать только бэкапы, причем глубокие, за длительное время, так как часто порча данных обнаруживается не сразу. А в случае с бэкапами, к каждому бэкапу достаточно прикладывать md5 сумму тарболла бэкапа, что бы знать, что он побился (на, например, софтовом рейде md 5/6 без батарейки)
raid 1 обеспечивает, по возможности, только целостность файловой системы (и то, не до конца) > raid5/6, за счет контроля четности обеспечивают целостность блоков данных (но не данных самой файловой системы) > raidZ обеспечивает целостность и данных, но не предоставляет гарантий того, что данные не попали на диск в уже испорченном виде.
Таким образом, контроль целостности данных, это лишь фича(которая имеет свою цену, и не маленькую!), которая нужна не всем, и которая ничего, на самом деле, гарантировать не может, а гарантировать (или, почти гарантировать, так как, если верите, знаете, что человек предполагает, а вот Бог решает) могут только off-site бэкапы.
>Безусловно есть задачи, где ZFS просто неприменима - например, там, где нужен
>одновременный доступ к носителям с двух или более машин. Но ограничивать
>сферу использования ZFS только бэкапами и файлохранением тоже не стоит.Согласна, но на опеннет ее любят превозносить как некий универсальный "эликсир" от всех проблем!
ZFS, несомненно, выдающаяся ФС, которая более чем достойна высоких оценок и даже восхищения, но это всего лишь навсего файловая система, да еще и достаточно специализированная, и применимая не на всех задачах!Если честно, я бы больше всего хотела бы, что бы кто-то сделал софтовое решение проблемы хранения off-site бэкапов: за 40 лет так ничего лучше лент в банковской яйчейке и не придумали, а библиотека с автолоэдером, что бы не руками ленты тасовать, стоит очень и очень недешево!
>Иногда в серверах банально не хватает корзин, я по тому и упомянула
>1u машину.Так вроде давно уже делают одноюнитовые машинки, в которые можно и 8 дисков напихать, так что это не бог весть какая проблема. На мой взгляд, гораздо сложнее в этом плане со слотами для модулей памяти - если их вдруг оказалось мало, то это означает переход в другой класс, с соответствующим увеличением цены.
>>Ну, скажем прямо, особенности действительно есть, и неплохие, за один сквозной контроль
>>целостности можно много дать. Впрочем, у любой медали две стороны... :-)
>
>Он не везде нужен: raid вообще не средство гарантии сохранности информации, он
>им не может быть просто по дизайну идеи.Кто говорил про RAID? RAID и контроль целостности между собой никак не связаны, как, впрочем, и RAID и сохранность информации или контроль целостности и сохранность информации.
>Такой гарантией может быть только off-site бэкап. Не должно существовать проекта без географически удаленного бэкапа, но может существовать проект без рейда.
Не спорю.
>Рейд лишь средство добавления девяток после запятой в уровень стабильности сервиса: в случае порчи данных/файловой системы гарантирован даунтайм на восстановление из бэкапов, но рейд не может нас предостеречь от софтовой ошибки(когда данные, записанные на файловую систему уже некорректны), от взлома сервера (и rm -rf /, или компроментации и тотального трояненья данных) от банального уничтожения сервера по-отдельности, или с дата-центром(как это было недавно с хостинг.уа)
Так речь об этом и не шла. Речь шла о сквозном контроле целостности. Никогда не приходилось поиском источника неявного повреждения данных заниматься? Врагу не пожелаешь такое "развлечение"
Кстати, вот Apache Software Foundation считает, что ZFS оказалась весьма полезна в ситуации восстановления после взлома сервера: http://blogs.apache.org/infra/entry/apache_org_downtime_report
>Настоящие гарантии могут дать только бэкапы, причем глубокие, за длительное время, так как часто порча данных обнаруживается не сразу. А в случае с бэкапами, к каждому бэкапу достаточно прикладывать md5 сумму тарболла бэкапа, что бы знать, что он побился (на, например, софтовом рейде md 5/6 без батарейки)А я бы предпочел, чтобы за меня это делал компутер, он ведь для этого создан. Зачем мне лишняя забота - поддерживать в актуальном состоянии контрольные суммы бэкапов?
А под ручку со сквозным контролем целостности ходит обнаружение и исправление ошибок при наличии избыточности.
>raid 1 обеспечивает, по возможности, только целостность файловой системы (и то, не до конца) > raid5/6, за счет контроля четности обеспечивают целостность блоков данных (но не данных самой файловой системы)Ну вот. Вы же сами выше писали, что он только добавляет девятки после запятой, а теперь утверждаете, что он обеспечивает целостность блоков данных. Сможете на пальцах объяснить, как он это делает? Попробуйте, хотя бы самой себе.
> raidZ обеспечивает целостность и данных, но не предоставляет гарантий того, что данные не попали на диск в уже испорченном виде.
Так этого и RAID-0/1/5/6 да и другие ФС не обеспечивают тоже. И что теперь, на основании этого отказаться от плюсов сквозного контроля целостности при передаче и хранении данных?
>Таким образом, контроль целостности данных, это лишь фича(которая имеет свою цену, и
>не маленькую!),Которая имела немаленькую цену, когда процессоров был один, ядро у него было одно, и частота этого ядра была 5 МГц. И эта цена падает с каждым днем, а значение и польза - наоборот растут.
> которая нужна не всем, и которая ничего, на самом деле, гарантировать не может, а гарантировать (или, почти гарантировать, так как, если верите, знаете, что человек предполагает, а вот Бог решает) могут
только off-site бэкапы.
А как насчет раннего обнаружения этих самых ошибок, чтобы они не попали в самые глубокие офф-сайт бэкапы? А то представляете картину маслом: восстанавливаем последний бэкап - а там ошибка, восстанавливаем предпоследний - а там тоже ошибка, и так до самого первого. Ладно, если он прокатит - восстановимся, но время простоя-то какое будет? А что если и в самом первом ошибка?
>Согласна, но на опеннет ее любят превозносить как некий универсальный "эликсир" от
>всех проблем!Ну эликсир то вряд-ли, но вот повод задуматься - это да.
>ZFS, несомненно, выдающаяся ФС, которая более чем достойна высоких оценок и даже
>восхищения, но это всего лишь навсего файловая система, да еще и
>достаточно специализированная, и применимая не на всех задачах!Я бы все-таки сказал, что представление о ZFS как "всего-лишь навсего файловой системе" несколько наивно. Это скорее интегрированная система управления хранением данных.
>Если честно, я бы больше всего хотела бы, что бы кто-то сделал
>софтовое решение проблемы хранения off-site бэкапов: за 40 лет так ничего
>лучше лент в банковской яйчейке и не придумали, а библиотека с
>автолоэдером, что бы не руками ленты тасовать, стоит очень и очень
>недешево!Хранение больших архивов информации в течение длительных промежутков времени - дело крайне недешевое. И тенденций к изменениям вроде пока не наблюдается
>>Иногда в серверах банально не хватает корзин, я по тому и упомянула
>>1u машину.
>
>Так вроде давно уже делают одноюнитовые машинки, в которые можно и 8
>дисков напихать, так что это не бог весть какая проблема. На
>мой взгляд, гораздо сложнее в этом плане со слотами для модулей
>памяти - если их вдруг оказалось мало, то это означает переход
>в другой класс, с соответствующим увеличением цены.Я же не зря написала про бюджет :) бывают и 4 сокета в 1u корпусе, но сколько они стоят?
Вот у проекта может быть в бюджете статья на выделенный database сервер, но может не быть на то, что Вы описываете выше. И в таком случае достаточно бюджетная машинка с зеркалом на том же md (да и geom) из SSD дисков может быть гораздо удобнее, а лишние деньги можно потратить на CPU/озу>>Он не везде нужен: raid вообще не средство гарантии сохранности информации, он
>>им не может быть просто по дизайну идеи.
>
>Кто говорил про RAID? RAID и контроль целостности между собой никак не
>связаны, как, впрочем, и RAID и сохранность информации или контроль целостности
>и сохранность информации.raid это девятки после запятой в надежности работы сервиса. Контроль целостности нужен для добавления девяток, что бы _уменьшить_(но не исключить) необходимость восстановления из бэкапов
>>Рейд лишь средство добавления девяток после запятой в уровень стабильности сервиса: в случае порчи данных/файловой системы гарантирован даунтайм на восстановление из бэкапов, но рейд не может нас предостеречь от софтовой ошибки(когда данные, записанные на файловую систему уже некорректны), от взлома сервера (и rm -rf /, или компроментации и тотального трояненья данных) от банального уничтожения сервера по-отдельности, или с дата-центром(как это было недавно с хостинг.уа)
>
>Так речь об этом и не шла. Речь шла о сквозном контроле
>целостности. Никогда не приходилось поиском источника неявного повреждения данных заниматься? Врагу
>не пожелаешь такое "развлечение"в случае железных проблем, или совсем бюджетного железа (без ECC памяти), или некоторых софтовых глюков (наверное, самый частый случай) ZFS будет закономерно писать на диск уже испорченные данные, испорченные до попадания их к ZFS.
>Кстати, вот Apache Software Foundation считает, что ZFS оказалась весьма полезна в
>ситуации восстановления после взлома сервера: http://blogs.apache.org/infra/entry/apache_org_downtime_reportТак я и не отрицаю полезность фич ZFS, но отрицаю ее "особый" и уникальный статус: имхо, не более чем очень хорошая файловая система, и даже лучшая в мире для некоторых задач
>Я бы все-таки сказал, что представление о ZFS как "всего-лишь навсего
>файловой системе" несколько наивно. Это скорее интегрированная система управления хранением данных.Хорошо, очень хорошая "интегрированная система управления данными", лучшая в мире в каких-то очень узких и специальных применениях
>>Настоящие гарантии могут дать только бэкапы, причем глубокие, за длительное время, так как часто порча данных обнаруживается не сразу. А в случае с бэкапами, к каждому бэкапу достаточно прикладывать md5 сумму тарболла бэкапа, что бы знать, что он побился (на, например, софтовом рейде md 5/6 без батарейки)
>
>А я бы предпочел, чтобы за меня это делал компутер, он ведь
>для этого создан. Зачем мне лишняя забота - поддерживать в актуальном
>состоянии контрольные суммы бэкапов?ZFS Вам _не_ может дать такой гарантии. Почему, смотрите выше. Для того, что бы смогла, из интегрированной системы хранения данными нужно сделать нечто большее: дать гарантии отсуствия глюков в тех данных, что передаются ZFS, и добавить избыточности ECC/registred памяти, так как на обычных серверах ее часто не хватает, так как ошибки памяти совсем не редкость(личный опыт, не один раз делала те же ремапы, когда сервис не поднимался).
>А под ручку со сквозным контролем целостности ходит обнаружение и исправление ошибок
>при наличии избыточности.Оно не дает никаких гарантий того, что Ваши данные будут целостны. Их могут дать _только_ бэкапы, и процедура переодического восстановления из бэкапов (и тестов того, что восстановлено), и то, с оговорками
>>raid 1 обеспечивает, по возможности, только целостность файловой системы (и то, не до конца) > raid5/6, за счет контроля четности обеспечивают целостность блоков данных (но не данных самой файловой системы)
>
>Ну вот. Вы же сами выше писали, что он только добавляет девятки
>после запятой, а теперь утверждаете, что он обеспечивает целостность блоков данных.
>Сможете на пальцах объяснить, как он это делает? Попробуйте, хотя бы
>самой себе.Целостность дает несколько дополнительных девяток после запятой к надежности, поэтому в SAN часто используется raid 60, вместо raid, например, 10, который быстрее (и raid6 для хранения данных без требования высокой производительности), хотя еще играет роль то, что raid6 вообще надежнее на современных больших дисках, с которыми вероятность вылета второго HDD во время ребилда не так уж и мала.
>> raidZ обеспечивает целостность и данных, но не предоставляет гарантий того, что данные не попали на диск в уже испорченном виде.
>
>Так этого и RAID-0/1/5/6 да и другие ФС не обеспечивают тоже. И
>что теперь, на основании этого отказаться от плюсов сквозного контроля целостности
>при передаче и хранении данных?Без, например, ECC памяти на low-end серверах, да, отказаться, так как ничего на самом деле не гаратирует (так как просто в нем нет смысла) а в остальных случаях думать, не принесет ли с собой это какие-то неудобства (например, фрагментацию из-за COW-записи)
Объясню на пальцах: raid5 на терабайтниках и еще больших дисках(особенно десктопных) имеет достаточно большой шанс смерти во время ребилда, чем raid6, но:
1. Он быстрее на запись
2. Удобнее для маленьких массивов из четырех шпинделей (и, тем более, из трех), так как всего один диск теряется на избыточность.
raid5 до сих пор используется, и он надежнее, чем одиночный диск без массива (хотя с очень бизнес-критикал использованием он уже не совместим)
3. Часто защита от риска потери данных, пара девяток после запятой в raid6, стоят для проекта дороже, и бесполезнее, чем объем и бюджет(в raid5), ведь все равно есть бэкапы, а от всех рисков _остановки_(а не уничтожения!) сервиса не застрахуешься!, тогда как риск просадки производительности, во время возрастания нагрузки на проект, и остановки сервиса(от чего, на самом деле и защищает raid или zfs), больше вероятности второго вылета диска, когда даже первый вылет не факт, что когда-то случится!с ZFS все точно так же: сквозной контроль целостности часто слишком избыточен, и совсем не нужен для проекта, если остальные компоненты системы совсем не такого уровня защиты.
>>Таким образом, контроль целостности данных, это лишь фича(которая имеет свою цену, и
>>не маленькую!),
>
>Которая имела немаленькую цену, когда процессоров был один, ядро у него было
>одно, и частота этого ядра была 5 МГц. И эта цена
>падает с каждым днем, а значение и польза - наоборот растут.Больше вопрос в iops'ах, с которыми у ZFS не всегда все хорошо
>только off-site бэкапы.
>
>А как насчет раннего обнаружения этих самых ошибок, чтобы они не попали
>в самые глубокие офф-сайт бэкапы?Для этого есть мониторинг. ZFS не может гарантировать того, что на ZFS у Вас верные данные!
А то представляете картину маслом: восстанавливаем
>последний бэкап - а там ошибка, восстанавливаем предпоследний - а там
>тоже ошибка, и так до самого первого. Ладно, если он прокатит
>- восстановимся, но время простоя-то какое будет? А что если и
>в самом первом ошибка?Нужно было отработать процедуру восстановления, и регулярно ее производить, так как ZFS так же не может гарантировать от такой ситуации.
>>Согласна, но на опеннет ее любят превозносить как некий универсальный "эликсир" от
>>всех проблем!
>
>Ну эликсир то вряд-ли, но вот повод задуматься - это да.Вам тоже: не все фичи в любых случаях полезны.
>>Если честно, я бы больше всего хотела бы, что бы кто-то сделал
>>софтовое решение проблемы хранения off-site бэкапов: за 40 лет так ничего
>>лучше лент в банковской яйчейке и не придумали, а библиотека с
>>автолоэдером, что бы не руками ленты тасовать, стоит очень и очень
>>недешево!
>
>Хранение больших архивов информации в течение длительных промежутков времени - дело крайне
>недешевое. И тенденций к изменениям вроде пока не наблюдаетсяВот-вот, имхо, индустрия идет куда-то не туда, именно какое-то гениальное решение для удешевления надежных бэкапов и нужно гораздо больше всех COW, ZFS, кластеров, параллельных ФС, raid-массивов, и тд
>Я же не зря написала про бюджет :) бывают и 4 сокета
>в 1u корпусе, но сколько они стоят?
>Вот у проекта может быть в бюджете статья на выделенный database сервер,
>но может не быть на то, что Вы описываете выше. И
>в таком случае достаточно бюджетная машинка с зеркалом на том же
>md (да и geom) из SSD дисков может быть гораздо удобнее,
>а лишние деньги можно потратить на CPU/озуНу так в ZFS зеркало тоже есть. И потом, обычный пул при необходимости можно легко превратить в гибридный.
>raid это девятки после запятой в надежности работы сервиса. Контроль целостности нужен
>для добавления девяток, что бы _уменьшить_(но не исключить) необходимость восстановления из
>бэкаповЕще раз - RAID и контроль целостности не связаны друг с другом. Контроль целостности может быть без RAID, и RAID без контроля целостности тоже. И оба вместе могут быть
>в случае железных проблем, или совсем бюджетного железа (без ECC памяти), или
>некоторых софтовых глюков (наверное, самый частый случай) ZFS будет закономерно писать
>на диск уже испорченные данные, испорченные до попадания их к ZFS.Блин, да этому подвержена любая файловая система, причем тут ZFS?
>>А я бы предпочел, чтобы за меня это делал компутер, он ведь
>>для этого создан. Зачем мне лишняя забота - поддерживать в актуальном
>>состоянии контрольные суммы бэкапов?
>
>ZFS Вам _не_ может дать такой гарантии.Сумбур у вас в мыслях какой-то. Вы предлагаете класть рядом с каждым файлом еще один небольшой файлик хэшем. Я говорю, что мне такой геморрой ни к чему, файловая система с этим справится гораздо лучше.
Вы начинаете про какие-то гарантии.
>Почему, смотрите выше. Для того,
>что бы смогла, из интегрированной системы хранения данными нужно сделать нечто
>большее: дать гарантии отсуствия глюков в тех данных, что передаются ZFS,
>и добавить избыточности ECC/registred памяти, так как на обычных серверах ее
>часто не хватает, так как ошибки памяти совсем не редкость(личный опыт,
>не один раз делала те же ремапы, когда сервис не поднимался).Так можно договориться до того, что компьютеру вообще никаких задач доверять нельзя, ибо гарантировать целостность всего и вся невозможно. Но однако же люди этим пользуются. А все потому, что допускают какой-то уровень ошибок.
>>А под ручку со сквозным контролем целостности ходит обнаружение и исправление ошибок
>>при наличии избыточности.
>
>Оно не дает никаких гарантий того, что Ваши данные будут целостны. Их
>могут дать _только_ бэкапы, и процедура переодического восстановления из бэкапов (и
>тестов того, что восстановлено), и то, с оговоркамиЯ не говорю об абстрактных гарантиях целостности данных в вакууме. Я говорю о сквозном контроле целостности данных при их хранении долговременном хранении на дисках и передаче из памяти на диск и обратно.
Так вот, если данные хранятся с избыточностью, контроль целостности позволяет, во-первых, существенно расширить класс обнаруживаемых ошибок - от явных типа полного отказа и/или ошибок чтения/записи, с обнаружением и обработкой которых неплохо справляется RAID, до явных + неявных, вроде фантомных записей и прочих веселостей, которые RAID не обнаруживает, а во-вторых, попытаться исправить ошибку, используя имеющуюся избыточность.
>[оверквотинг удален]
>>после запятой, а теперь утверждаете, что он обеспечивает целостность блоков данных.
>>Сможете на пальцах объяснить, как он это делает? Попробуйте, хотя бы
>>самой себе.
>
>Целостность дает несколько дополнительных девяток после запятой к надежности, поэтому в SAN
>часто используется raid 60, вместо raid, например, 10, который быстрее (и
>raid6 для хранения данных без требования высокой производительности), хотя еще играет
>роль то, что raid6 вообще надежнее на современных больших дисках, с
>которыми вероятность вылета второго HDD во время ребилда не так уж
>и мала.Вы смешиваете в одну кучу RAID и контроль целостности. Простая задача. Есть RAID-5 из 4 дисков плюс диск для четности. Есть полоска RAID, в которой содержимое дисков с данными не совпадает с вычисленным содержимым диска с четностью. Ваши действия? Как RAID-5 поможет вам гарантировать целостность?
>>Так этого и RAID-0/1/5/6 да и другие ФС не обеспечивают тоже. И
>>что теперь, на основании этого отказаться от плюсов сквозного контроля целостности
>>при передаче и хранении данных?
>
>Без, например, ECC памяти на low-end серверах, да, отказаться, так как ничего
>на самом деле не гаратирует (так как просто в нем нет
>смысла)Ну если вы до сих пор не видите смысла, то вперед - отказывайтесь. Я уже подустал это объяснять, но попробую сделать это еще один раз.
Если контроль целостности в конфигурации с избыточностью показал наличие ошибки, то на основании этой информации вы можете сделать вывод о том, где эта ошибка - на каком диске. Если диск установить не удается, это может означать что ошибка была внесена в данные, пока они еще были в памяти, но уже после того, как была вычислена их контрольная сумма.
Если контроль целостности ошибок не показывает, но ошибка тем не менее есть (с точки зрения приложения), то может сфокусироваться на поиске ошибок в памяти, приложениях, ядре и т.п., исключив все компоненты связанные с передачей и долговременным хранением данных на внещних носителях.
>с ZFS все точно так же: сквозной контроль целостности часто слишком избыточен,
>и совсем не нужен для проекта, если остальные компоненты системы совсем
>не такого уровня защиты.Если вы считаете, что в контроле целостности нет никакой пользы, то я уже и не знаю, как вам объяснять. Думаю, подрастете - поймете. Или когда на собственной шкуре испытаете, что такое искать неявную ошибку в сложной системе, особенно состоящей и продуктов разных производителей.
>>>Таким образом, контроль целостности данных, это лишь фича(которая меет свою цену, и
>>>не маленькую!),
>>
>>Которая имела немаленькую цену, когда процессоров был один, ядро у него было
>>одно, и частота этого ядра была 5 МГц. И эта цена
>>падает с каждым днем, а значение и польза - наоборот растут.
>
>Больше вопрос в iops'ах, с которыми у ZFS не всегда все хорошоЭээ. Сквозной контроль целостности - это контрольные суммы. Причем тут IOPs'ы?
>>А как насчет раннего обнаружения этих самых ошибок, чтобы они не попали
>>в самые глубокие офф-сайт бэкапы?
>
>Для этого есть мониторинг. ZFS не может гарантировать того, что на ZFS
>у Вас верные данные!Мониторинг без контроля целостности может быть позволит вовремя заметить некоторые явные ошибки. Неявные ошибки мониторинг не найдет. ZFS не претендует на гарантирование того, что данные, поступившие ей от пользователя, верны. Но по крайней мере она гарантирует, что ошибки при передаче и хранении будут обнаружены.
>>Ну эликсир то вряд-ли, но вот повод задуматься - это да.
>
>Вам тоже: не все фичи в любых случаях полезны.Я вот тоже задумался - как еще более доходчиво донести до вас смысл того, о чем я говорю;
>Вот-вот, имхо, индустрия идет куда-то не туда, именно какое-то гениальное решение для
>удешевления надежных бэкапов и нужно гораздо больше всех COW, ZFS, кластеров,
>параллельных ФС, raid-массивов, и тдДешевый, быстрый, надежный - выберите любые два из трех :-)
>Ну так в ZFS зеркало тоже есть. И потом, обычный пул при
>необходимости можно легко превратить в гибридный.Только зачем в этом случае ZFS? Что бы все тормозило из-за COW(напомню, у нас задача database сервер), и нельзя было занять больше половины совсем недешевого объема SSD-дисков? Вспомним так же о нецелевом расходовании ОЗУ... А если у этой машины меньше 8 Гигов ОЗУ? на Xeon54[0-9]\{2\} таких машин(которые не могли съесть больше 8 гигов, и были достаточно бюджетные) было достаточно много.
Имхо, mdraid/gmirror как raw device (точнее, в Linux LVM-том сверху mdraid) будет гораздо более адекватным выбором!
>>raid это девятки после запятой в надежности работы сервиса. Контроль целостности нужен
>>для добавления девяток, что бы _уменьшить_(но не исключить) необходимость восстановления из
>>бэкапов
>
>Еще раз - RAID и контроль целостности не связаны друг с другом.
>Контроль целостности может быть без RAID, и RAID без контроля целостности
>тоже. И оба вместе могут бытьКонтроль целостности это не более чем одна-две девятки после запятой к надежности, аптайму, но не гаратии сохранения данных, которую может дать только off-site бэкап! Еще одна фича рейд-массивов (в аппаратных, например, такой фичей является батарейка, защищающая кэш, или флэш-память, а так же контроль четности блоков данных, гарантирующих в 5-6-м рейдах восстановление битых блоков данных)
>>в случае железных проблем, или совсем бюджетного железа (без ECC памяти), или
>>некоторых софтовых глюков (наверное, самый частый случай) ZFS будет закономерно писать
>>на диск уже испорченные данные, испорченные до попадания их к ZFS.
>
>Блин, да этому подвержена любая файловая система, причем тут ZFS?При том, что в ряде случаев проверка целостности данных ZFS, с которой тут так носятся, это ненужная фича, лишь еще одна девятка после запятой, которая нужна не всем, и которая имеет свою, совсем не дешевую цену.
>>>А я бы предпочел, чтобы за меня это делал компутер, он ведь
>>>для этого создан. Зачем мне лишняя забота - поддерживать в актуальном
>>>состоянии контрольные суммы бэкапов?
>>
>>ZFS Вам _не_ может дать такой гарантии.
>
>Сумбур у вас в мыслях какой-то. Вы предлагаете класть рядом с каждым
>файлом еще один небольшой файлик хэшем. Я говорю, что мне такой
>геморрой ни к чему, файловая система с этим справится гораздо лучше.Это у Вас сумбур. Та же Bacula прекрасно умеет работать с хэшами, для бэкапа GNU tar/ssh разумнее считать хэш до передачи серверу бэкапов, на стороне клиента, так как при передаче по сети бэкап уже может испортиться
>Вы начинаете про какие-то гарантии.
Именно! Контроль целостности данных, это лишь еще одна девятка после запятой в степени гарантии стабильности сервиса, и _не_более_!
>Так можно договориться до того, что компьютеру вообще никаких задач доверять нельзя,
>ибо гарантировать целостность всего и вся невозможно. Но однако же люди
>этим пользуются. А все потому, что допускают какой-то уровень ошибок.Ну вот Вы и поняли мою мысль: контроль целостности данных нужен _не_всегда_, так как он имеет свою, весьма недешевую цену
>>>А под ручку со сквозным контролем целостности ходит обнаружение и исправление ошибок
>>>при наличии избыточности.
>>
>>Оно не дает никаких гарантий того, что Ваши данные будут целостны. Их
>>могут дать _только_ бэкапы, и процедура переодического восстановления из бэкапов (и
>>тестов того, что восстановлено), и то, с оговорками
>
>Я не говорю об абстрактных гарантиях целостности данных в вакууме. Я говорю
>о сквозном контроле целостности данных при их хранении долговременном хранении на
>дисках и передаче из памяти на диск и обратно.А зачем это, если память, например, не ECC, и приложение работает не очень стабильно?
Нет смысла обеспечивать "сквозной контроль целостности" ненужная фича, да еще и достаточно дорогая (куча оперативки, общая тяжеловесность ZFS, фрагментация, и т д)Или, например, это видео-хостинг, где один битый пиксель видео-файла за год ни на что не повлияет?
>Так вот, если данные хранятся с избыточностью, контроль целостности позволяет, во-первых, существенно
>расширить класс обнаруживаемых ошибок - от явных типа полного отказа и/или
>ошибок чтения/записи, с обнаружением и обработкой которых неплохо справляется RAID, до
>явных + неявных, вроде фантомных записей и прочих веселостей, которые RAID
>не обнаруживает, а во-вторых, попытаться исправить ошибку, используя имеющуюся избыточность.Это лишь один из методов. Вместо этого, специализированная система мониторинга вроде Zabbix/Nagios позволит выявить ошибку в работе приложения, а не фантомные изменения в одном пикселе.
Кучу раз видела сервера под той же FreeBSD с UFS с сотнями файлов в lost+found после жестких ребутов, и... они работали, представляете? Даже без журнала!>[оверквотинг удален]
>>raid6 для хранения данных без требования высокой производительности), хотя еще играет
>>роль то, что raid6 вообще надежнее на современных больших дисках, с
>>которыми вероятность вылета второго HDD во время ребилда не так уж
>>и мала.
>
>Вы смешиваете в одну кучу RAID и контроль целостности.
>Есть
>RAID-5 из 4 дисков плюс диск для четности. Есть полоска RAID,
>в которой содержимое дисков с данными не совпадает с вычисленным содержимым
>диска с четностью. Ваши действия? Как RAID-5 поможет вам гарантировать целостность?Я Вам уже в прошлый раз сказала, что Вам не хватает знаний. Читайте доки не только про ZFS, расширьте кругозор, почитайте те же IBM-овские редбуки, узнаете много нового.
>[оверквотинг удален]
>основании этой информации вы можете сделать вывод о том, где эта
>ошибка - на каком диске. Если диск установить не удается, это
>может означать что ошибка была внесена в данные, пока они еще
>были в памяти, но уже после того, как была вычислена их
>контрольная сумма.
>
>Если контроль целостности ошибок не показывает, но ошибка тем не менее есть
>(с точки зрения приложения), то может сфокусироваться на поиске ошибок в
>памяти, приложениях, ядре и т.п., исключив все компоненты связанные с передачей
>и долговременным хранением данных на внещних носителях.Вместо этого проще мониторить работу приложения :) Чем вводить дополнительные абстракции в виде ZFS, которая все равно не может гарантировать нахождения на диске целостных данных.
На файлопомойке с какими-то отвественными данными, ECC registred памятью, двумя блоками питания (с отключением работающего нестабильно, что бы память/cpu/мосты всегда работали стабильно), несомненно, сквозной контроль целостности данных ZFS более чем пригодится, и он тут будет лучшим в мире :)
>>с ZFS все точно так же: сквозной контроль целостности часто слишком избыточен,
>>и совсем не нужен для проекта, если остальные компоненты системы совсем
>>не такого уровня защиты.
>
>Если вы считаете, что в контроле целостности нет никакой пользы, то я
>уже и не знаю, как вам объяснять. Думаю, подрастете - поймете.
>Или когда на собственной шкуре испытаете, что такое искать неявную ошибку
>в сложной системе, особенно состоящей и продуктов разных производителей.Предлагаю Вам самому подрасти, и почитать, хотя бы, как работает raid5/6, а то, похоже, что Вы сознательно ограничили свой кругозор ZFS, FreeBSD, Solaris(?), даже про device-mapper пытаетесь рассуждать, не зная, что это, но самое главное, повторюсь, пытаетесь сравнивать ZFS с raid5/6, при этом не подозревая о том, как он работает!
>>Больше вопрос в iops'ах, с которыми у ZFS не всегда все хорошо
>
>Эээ. Сквозной контроль целостности - это контрольные суммы. Причем тут IOPs'ы?COW есть причина тормозов во многих случаях, которая лечится только дополнительными шпинделями и другими _дорогими_ и излишними ухищрениями.
Так как контроль целостности лишь одна из фич рейда, повышающая его надежность, зачем она в половине задач? Если не поняли, прочитайте еще раз, если опять не поняли, вернитесь к моему прошлому примеру из raid5, почему его выбрали вместо шестого на виртуальной задаче, тогда как он менее надежен>>>А как насчет раннего обнаружения этих самых ошибок, чтобы они не попали
>>>в самые глубокие офф-сайт бэкапы?
>>
>>Для этого есть мониторинг. ZFS не может гарантировать того, что на ZFS
>>у Вас верные данные!
>
>Мониторинг без контроля целостности может быть позволит вовремя заметить некоторые явные ошибки.
>Неявные ошибки мониторинг не найдет.А их нужно находить, если все и так работает?
>ZFS не претендует на гарантирование того,
>что данные, поступившие ей от пользователя, верны.Именно!
>Но по крайней мере
>она гарантирует, что ошибки при передаче и хранении будут обнаружены.А зачем это, если гораздо больше вероятность того, что данные будут испорчены из-за ошибки приложения/памяти/cpu? по крайней мере на SOHO/SMB железе/серверах?
Только лишние сложности и сущности, которые противоречат приципу KISS.
Устал я вам на уже черт знает какой раз объяснять, что RAID и контроль целостности есть вещи независимые, вы почему-то упорно отказываетесь это понимать. Уверяю вас, про RAID и его плюсы, минусы и родовые травмы я знаю достаточно, гораздо больше уровня всяких там редбуков. Вы же, почему-то, вместо того чтобы попытаться задуматься и ответить на вопросы, начинаете утверждать, что это я ничего не знаю. Давайте, вы сначала на вопросы ответите, а потом попробуете делать утверждения. Привожу их еще раз для ясности:1) RAID5, 4 диска с данными, 1 диск с четностью, содержимое дисков с четностью не соответствует содержимому дисков с данными. Как, на ваш взгляд, RAID в этой ситуации может обеспечить целостность данных
2) Как вы себе видите использование возможностей dm-ioband вместе с ZFS
Поймите, я не хочу сказать, что RAID-5/6, LVM, dm-ioband, хэши, Bacula, Zabbix, ext4, BTRFS и т.п. не нужны, убоги или что-то в этом духе, а ZFS uber alles. Все хорошо на своем месте. Я просто вижу ваши заблуждения по многим вопросам, которые вы сами не видите. Вопрос в том хотите ли вы их увидеть? Если хотите, давайте начнем с попыток ответа хотя бы на 1 вопрос из двух выше. Если не хотите, можете не трудиться и не рекомендовать мне еще раз пойти почитать редбуки, поскольку я в этом случае предпочту закончить "тормозить прогресс" и пойду лучше займусь написанием чего-нибудь полезного.
>Устал я вам на уже черт знает какой раз объяснять, что RAID
>и контроль целостности есть вещи независимые,Кто Вам это сказал? Сохранность данных может обеспечить _исключительно_ только бэкап.
Тут работает бинарная логика (да/нет), если механизм _не_может_ применяться для сохранности данных (как не может применяться механизм контроля четности ZFS на "боевом", но не бэкап сервере, когда на последнем все плюсы ZFS очевидны, хотя и не уникальны), он может применяться _только_ для повышения аптайма сервису(в том числе сокращением времени восстановления из бэкапов), и все тут, больше ни для чего.
То есть, с точки зрения бинарной логики, это новая фича рейд-массивов(применимая исключительно(!) для повышения надежности сервиса, например, сервиса бэкапа, или файлохранилища), такая же как батарейка,защищающая кэш, или новомодная флэш-память, вместо батарейки.> вы почему-то упорно отказываетесь это
>понимать.Имхо, это про Вас
Уверяю вас, про RAID и его плюсы, минусы и родовые
>травмы я знаю достаточно,Не верю(с)
>гораздо больше уровня всяких там редбуков.
Ого :)
>же, почему-то, вместо того чтобы попытаться задуматься и ответить на вопросы,
То же самое могу повторить и про Вас :)
>начинаете утверждать, что это я ничего не знаю.
Именно, со все большей степенью уверенности...
> Давайте, вы сначала
>на вопросы ответите,не буду, это называется "бесплатный консалтинг", почитайте, пожалуйста, доки, прежде чем начинать спорить :)
>При том, что в ряде случаев проверка целостности данных ZFS, с которой
>тут так носятся, это ненужная фича,Чтооооо? O_o
>лишь еще одна девятка после
>запятой, которая нужна не всем, и которая имеет свою, совсем не
>дешевую цену.А вы в курсе, что у ZFS есть свойство, поддерживать контроль целостности или не поддерживать, какие контролирующие алгоритмы использовать, и его, между прочим, можно оперативно изменять в ту или иную сторону?
Кстати, ни один RAID не восстанавливает данные, если его физическая целостность не нарушена. При софтверных ошибках на таком RAID похеренные данные практически невосстановимы. А ZFS _обнаруживает_ такие случаи легко и непринуждённо, даёт сигнал об этом, если не может справится с этим самостоятельно, в статусе пула. Если может справится, то делает это по-тихому, без сообщений.
>>При том, что в ряде случаев проверка целостности данных ZFS, с которой
>>тут так носятся, это ненужная фича,
>
>Чтооооо? O_oИменно. Это не всегда нужная фича _лишь_ высокой доступности, которая не может отменить off-site бэкап: технология, уменьшающая вероятность развертывания бэкапа, и так достаточно маленькую
>>лишь еще одна девятка после
>>запятой, которая нужна не всем, и которая имеет свою, совсем не
>>дешевую цену.
>
>А вы в курсе, что у ZFS есть свойство, поддерживать контроль целостности
>или не поддерживать, какие контролирующие алгоритмы использовать, и его, между прочим,
>можно оперативно изменять в ту или иную сторону?Да, проприетарные прошивки таким похвастаться не могут, несомненно, zfs в этом вопросе лучшее в мире решение :)
>Кстати, ни один RAID не восстанавливает данные, если его физическая целостность не
>нарушена. При софтверных ошибках на таком RAID похеренные данные практически невосстановимы.Почитайте про raid 5/6. Конечно, сами данные это не блоки данных raid-массива _под_файловой системой, но все же идея и технология совсем не уникальна.
>Если может справится, то делает это по-тихому, без сообщений.
Это обязательно? Впрочем, для блоков данных, для которых нет парити, raid5/6 это может делать тихо, а может и кричать по SNMP, все зависит от прошивки, и в ряде случаев действительно не меняется...
>Да, тут Вы безусловно правы! raw-device рулят (как и снапшоты Logical Volume
>без файловой системы)Однако, линуксовый LVM отстал в своём развитии на несколько лет от ZFS. В частости, вместе с Ext4 LVM может обеспечить функциональность только UFS2, так как никаких инкрементных снапшотов не поддерживает. Говорят ещё, что при создании снапшота средствами LVM и оставлении его на носителе весьма заметная часть вычислительных ресурсов при записи и перезаписи файлов тратится на поддержание логической структуры снапшота от изменений, так, что носители с живыми снапшотами становятся РЕЗКО тормозными.
>>Да, тут Вы безусловно правы! raw-device рулят (как и снапшоты Logical Volume
>>без файловой системы)
>
>Однако, линуксовый LVM отстал в своём развитии на несколько лет от ZFS.Очень субъективно. LVM это аналог Geom. В отличае от Geom, у device-mapper/lvm есть кластерные расширения, и еще миллион и одна фича.
ZFS вообще не UNIX-way, а комбаин, включающий файловую систему.
>Говорят ещё, что при
>создании снапшота средствами LVM и оставлении его на носителе весьма заметная
>часть вычислительных ресурсов при записи и перезаписи файлов тратится на поддержание
>логической структуры снапшота от изменений, так, что носители с живыми снапшотами
>становятся РЕЗКО тормозными.Да, такая проблема есть, поэтому мы снапшоты используем только для бэкапов(с той же виртуалки, ее lv снимается снапшот, монтируется, и делается инкрементальная копия), после создания бэкапа снапшот удаляем.
Но решением этой проблемы занимаются.
В этом отношении, ZFS, как и железные SAN/DAS, конечно, лучше.Но везде есть свои недостатки, разумеется, device-mapper, Linux вообще, и любой дистрибутив, как и та же фря, Солярка не идеальны, и каждая платформа и технология обладает недостатками, которые нужно не боятся признать.
>>>Да, тут Вы безусловно правы! raw-device рулят (как и снапшоты Logical Volume
>>>без файловой системы)
>>
>>Однако, линуксовый LVM отстал в своём развитии на несколько лет от ZFS.
>
>Очень субъективно. LVM это аналог Geom. В отличае от Geom, у device-mapper/lvm
>есть кластерные расширения, и еще миллион и одна фича.Про HAST Project вы не в курсе что ли?
http://www.opennet.me/opennews/art.shtml?num=25502
>Про HAST Project вы не в курсе что ли?
>http://www.opennet.me/opennews/art.shtml?num=25502В курсе, что до production этому не один год. А Clvm уже куча лет :)
Прежде чем эту штуку во фре допилят, в Linux заменят lvm на более продвинутый менеджер, например, Zumastor.
>А когда в пуле всего два диска, например, два локальных SAS (или
>SSD) под зеркало в обычном 1u сервере под тяжелую БД?
>
>cow, как уже сказали, часто значит большой и лишний оверхед. ZFS, и,
>вероятно будет btrfs, это мощнейшая файловая система, но пихать ее в
>каждую дырку, имхо, очень не разумно :(
>А под эту задачу ext4 будет смотреться гораздо лучше.Интересно, линуховый LVM может предоставить RAW-пространство (как это делает GEOM и Zvol в любых конструкциях программных RAID) или только пространство с заранее созданной файловой системой под файлы базы данных?
>[оверквотинг удален]
>>SSD) под зеркало в обычном 1u сервере под тяжелую БД?
>>
>>cow, как уже сказали, часто значит большой и лишний оверхед. ZFS, и,
>>вероятно будет btrfs, это мощнейшая файловая система, но пихать ее в
>>каждую дырку, имхо, очень не разумно :(
>>А под эту задачу ext4 будет смотреться гораздо лучше.
>
>Интересно, линуховый LVM может предоставить RAW-пространство (как это делает GEOM и Zvol
>в любых конструкциях программных RAID) или только пространство с заранее созданной
>файловой системой под файлы базы данных?Конечно, может! про LVM нужно понять, что lvm это лишь интерфейс с device-mapper, на который в Linux стараются максимально завязать работу с блочными устройствами.
В этой череде mdraid выбивается из общей категории :(А вот btrfs, уже нет.
>Ну означает, ну и че дальше? При размере блока в 128К эффекты от
>непоследовательного расположения блоков ощущаются сильно меньше, чем при размере
>блока в 4КПростите, дядя, а ничего что даже современные "классические" ФС, да хоть тот же EXT4, оперируют довольно большими экстентами и стараются группировать данные последовательно? Явно будучи в состоянии соорудить аналог 128К блока или скольковаамтамнадо из 4К блоков и оформить сие компактной структурой. Особенно если буферизуя побольше, блаблабла. Ну и нафига тогда все этим навороты с блоками переменной длины, если в стопицот раз более простой дизайн достигает примерно такого же по смыслу поведения?
>(128К - это все равно что 32 последовательных блока по 4К).
Вот только любая нормальная современная ФС как я понимаю банальо вфигачит при такой нужде экстент, который и записан будет последовательно и метаданных о нем - мизерное количество. И усе. Это будет чем-то хуже всех этих аццких изощрений с блоками переменной длины? oO
>А когда у тебя много устройств в пуле, предвыборка работает, да
>еще какая-нибудь ReadZillа имеется - вообще можешь ничего не заметить.Да понятно что обсирон ФС можно вытянуть до некоторой степени жирными буферами и параллельной работой девайсами. Вот только это как бы не заслуга ФС... :P.
>Сколько еще раз тебе это объяснять нужно?
Ой, ладно вам ерничать. Вы вроде в ФС шарите, давайте без особых грубостей? :)
> Простите, дядя, а ничего что даже современные "классические" ФС, да хоть тот же EXT4, оперируют довольно большими экстентами и стараются группировать данные последовательно?Ничего. Минимальной единицей выделения у них все равно является блок, на x86 - чаще всего 4К (по размеру страницы). Так что при определенных условиях ext4 может ничем принципиально не отличаться от ext3.
> Явно будучи в состоянии соорудить аналог 128К блока или скольковаамтамнадо из 4К блоков и оформить сие компактной структурой. Особенно если буферизуя побольше, блаблабла.
Может. ext4, да и даже UFS2 в FreeBSD это собственно и делают.
> Ну и нафига тогда все этим навороты с блоками переменной длины, если в стопицот раз более простой дизайн достигает примерно такого же по смыслу поведения?
Затем, что самое интересное начинается тогда, когда возникают снимки и клоны, которых в этих самых "классических" чаще всего нету ни в каком виде.
> Вот только любая нормальная современная ФС как я понимаю банальо вфигачит при такой нужде экстент, который и записан будет последовательно и метаданных о нем - мизерное количество. И усе. Это будет чем-то хуже всех этих аццких изощрений с блоками переменной длины? oO
Маленькое уточнение - при наличии кусков свободного пространства больших размеров. При их отсутствии - будет выделять такими кусками, вплоть до минимальных.
> Да понятно что обсирон ФС можно вытянуть до некоторой степени жирными буферами и параллельной работой девайсами. Вот только это как бы не заслуга ФС... :P.
Классической, жестко завязанной на кэш VM - да, не заслуга. Но кто сказал, что не может быть других путей?
> Ой, ладно вам ерничать. Вы вроде в ФС шарите, давайте без особых грубостей? :)Начни с себя - перестань употреблять словечки вроде "обсирон" и им подобные. Есть вопросы - спрашивай, есть возражения - аргументируй, только по делу, а не так чтобы потроллить
>Ничего. Минимальной единицей выделения у них все равно является блок, на x86
>- чаще всего 4К (по размеру страницы).И что дальше? ZFS тоже может юзать мелкие блоки. И? :)
>Так что при определенных условиях ext4 может ничем принципиально не отличаться от ext3.
Ну так то же самое можно сказать и про ZFS вероятно. Грубо говоря если хочется распихать 128К данных а непрерывных 128К областей найти вдруг не удалось (а иначе какие проблемы то пхнуть 128К областью?) - вариантов вижу два. Вариант номер раз - разбить на более мелкие куски и распихать хоть куда-нибудь, раз уж том так засран - тут уже не до крутых оптимизаций, хоть куда бы распихать и разрулить запрос. Вариант два - совсем завернуть запись как технически невозможную. И хотя оба варианта хреновы, первый имхо предпочтительнее. А ZFS что при этом сделает? Внезапно родит из вакуума свободного местечка чтобы разложить непрерывный блок? Или чего? Ну или чем таким его поведение в таких ситуациях будет отличаться в лучшую сторону? И собственно а из-за чего?
>Может. ext4, да и даже UFS2 в FreeBSD это собственно и делают.
А что, в UFS2 уже родили экстенты, чтобы такие фокусы были более-менее эффективны? Они ж вроде заломались переделывать классическую структуру ФС чтобы сэкономить на кодинге? Как я понимаю, затея с экстентами по физическому смыслу в принципе похожа на те же самые блоки переменной длины но с очень крутыми диапазонами длин (в EXT4 до 128 мегов на экстент, если не глючу) и достаточно компактной записью в метаданные по этому поводу, с весьма хорошим соотношением между размером данных и метаданных в большинстве случаев, и обработка таких структур достаточно быстрая.
>Затем, что самое интересное начинается тогда, когда возникают снимки и клоны, которых
>в этих самых "классических" чаще всего нету ни в каком виде.А попробуйте объяснить мне глобальную физическую/логическую разницу между блоками переменной длины и записи в виде экстента, например? Собственно а что если рассмотреть экстент как этакий блок переменной длины с очень широким диапазоном размеров? При том в допущении что ФС должна стараться пихать данные не очень фрагментированно - с экстентами получается заметно эффективнее по метаданным и скорости их педалинга как правило :)
>Маленькое уточнение - при наличии кусков свободного пространства больших размеров. При
>их отсутствии - будет выделять такими кусками, вплоть до минимальных.А ZFS что по такому поводу сделает?! Магическим образом родит недостающие непрерывные блоки чтоли? Я вижу ровно два способа разрулить такую ситуацию: раскроить запрос на запись на более мелкие записи и впихать их куда-нибудь хоть как-нибудь, или совсем отказать в операции вернув ошибку. А что еще можно сделать то в такой ситуации? oO Лично мне симпатичнее все-таки первый вариант, хоть он и ведет к усилению ж...ы с фрагментацией тома, т.к. тормоза все-таки лучше отказа в обслуживании.
>Классической, жестко завязанной на кэш VM - да, не заслуга. Но кто
>сказал, что не может быть других путей?Может быть и могут быть. Однако кардинально перекроить лэйаут ФС и избавиться от некоторых его странностей и упущений - несколько проблематично когда ФС уже вышла и юзается оравой народа.
>Начни с себя - перестань употреблять словечки вроде "обсирон" и им подобные.
Собственно, я назвал ситуацию так как пришло в голову и отражает суть. Это не является каким-то специальным наездом, просто не придумалось более емкого и меткого термина отражающего суть явления. Кстати это даже не наезд на конкретную ФС а всего лишь скорее описание некоей ситуации. Поэтому зря вы так нервно реагируете, имхо. Особенно учтя что неудобные ситуации можно создать практически любой ФС, идеальных то - не бывает ;)
>Есть вопросы - спрашивай, есть возражения - аргументируй, только по делу,
>а не так чтобы потроллитьДа, собственно, троллинг самоцелью не является. Как максимум иногда в процессе не сдерживаюсь и перегибаю с едкостью коментов. Вы тоже не паинька. Ваши симпатии видно невооруженным глазом ;).
>>Ничего. Минимальной единицей выделения у них все равно является блок, на x86
>>- чаще всего 4К (по размеру страницы).
>
>И что дальше? ZFS тоже может юзать мелкие блоки. И? :)ZFS может использовать блоки размером от 512 байт. И?
>>Так что при определенных условиях ext4 может ничем принципиально не отличаться от ext3.
>
>Ну так то же самое можно сказать и про ZFS вероятно. Грубо
>говоря если хочется распихать 128К данных а непрерывных 128К областей найти
>вдруг не удалось (а иначе какие проблемы то пхнуть 128К областью?)Просто если выделение места осуществляется все время блоками по 128К - то есть неплохие шансы, что среди вновь освобожденных блоков будут нужные размеры, и их можно будет использовать.
>- вариантов вижу два. Вариант номер раз - разбить на более
>мелкие куски и распихать хоть куда-нибудь, раз уж том так засран
>- тут уже не до крутых оптимизаций, хоть куда бы распихать
>и разрулить запрос. Вариант два - совсем завернуть запись как технически
>невозможную. И хотя оба варианта хреновы, первый имхо предпочтительнее.В некоторых случаях может быть и наоборот, но в больщинстве случаев первый вариант предпочтительнее.
>А ZFS что при этом сделает? Внезапно родит из вакуума свободного местечка чтобы
>разложить непрерывный блок? Или чего? Ну или чем таким его поведение
>в таких ситуациях будет отличаться в лучшую сторону? И собственно а
>из-за чего?ZFS соберет блок нужного размера из блоков меньшего размера, при этом этом уровни выше SPA даже не будут об этом подозревать. Так что не переживайте, все будет в порядке. Кстати, политику выбора блоков в таких ситуациях можно легко поменять - можно не пытаться искать размеры побольше, а просто идти последовательно, пока не наберется нужный размер.
>>Может. ext4, да и даже UFS2 в FreeBSD это собственно и делают.
>
>А что, в UFS2 уже родили экстенты, чтобы такие фокусы были более-менее
>эффективны?Для этого не нужны экстенты - нужно просто выделять блоки последовательно, если есть такая возможность. UFS2 делает именно так. При этом уже даже блока в 128K достаточно для работы с современными дисками на скорости пластин диска.
>Они ж вроде заломались переделывать классическую структуру ФС чтобы сэкономить
>на кодинге? Как я понимаю, затея с экстентами по физическому смыслу
>в принципе похожа на те же самые блоки переменной длины но
>с очень крутыми диапазонами длин (в EXT4 до 128 мегов на
>экстент, если не глючу)Похоже, да.
> и достаточно компактной записью в метаданные по
Да, если экстентов мало и они большие. Если их много и они маленькие, метаданных может понадобиться много.
>этому поводу, с весьма хорошим соотношением между размером данных и метаданных
>в большинстве случаев, и обработка таких структур достаточно быстрая.Ага, пока не понадобится,например, сжатие. Как только понадобится сжатие, лучше оперировать логическими блоками фиксированного размера, сжимая их по одному - это позволяет просто реализовывать seek по сжатому файлу. В случае же одного большого последовательного сжатого экстента перемещение в конец файла будет ну очень небыстрой операцией.
>А попробуйте объяснить мне глобальную физическую/логическую разницу между блоками переменной длины и
>записи в виде экстента, например? Собственно а что если рассмотреть экстент
>как этакий блок переменной длины с очень широким диапазоном размеров? При
>том в допущении что ФС должна стараться пихать данные не очень
>фрагментированно - с экстентами получается заметно эффективнее по метаданным и скорости
>их педалинга как правило :)Да я уже запарился тебе объяснять. С экстентами получается эффективнее до тех пор, пока не начнутся сжатие и/или снимки/клоны. Про сжатие я уже сказал. Давай про снимки. Пусть у тебя есть один большой файл из 1 экстента в 128МБ и ты сделал снимок. Вначале снимок не отличается от состояния файловой системы. Предоложим, что ты захотел записать 1 байт в середину файла. Тебе нужно будет начать изгаляться, чтобы отразить сей факт - разбить один экстент на 3. При следующей записи еще раз и так далее и далее и даллее.
В итоге ты можешь получить херову уйму небольших экстентов. Не, можно конечно делать CoW эсктентами по 128МБ, то про пропускную способность при этом можно забыть.
>>Классической, жестко завязанной на кэш VM - да, не заслуга. Но кто
>>сказал, что не может быть других путей?
>
>Может быть и могут бытьДа не может быть, а есть. L2ARC например.
> Однако кардинально перекроить лэйаут ФС и избавиться
>от некоторых его странностей и упущений - несколько проблематично когда ФС
>уже вышла и юзается оравой народа.Знаешь, какой сейчас текущий номер версии формата? 26, ЕМНИП. Так что не надо тут про проблематично. Очень многие вещи можно менять без особых проблем. А все, что касается политик - так вообще и без изменения форматов.
>>Начни с себя - перестань употреблять словечки вроде "обсирон" и им подобные.
>
>Собственно, я назвал ситуацию так как пришло в голову и отражает суть.Если оно и отражает суть, то главным образом того, что ты не вполне в теме, поэтому недостаток аргументов компенсируешь цветистостью выражений.
>Это не является каким-то специальным наездом, просто не придумалось более емкого
>и меткого термина отражающего суть явления. Кстати это даже не наезд
>на конкретную ФС а всего лишь скорее описание некоей ситуации.Мне уже изрядно набило оскомину. Можешь продолжать в том же духе конечно, но рискуешь оказаться в игноре. Так что хозяин - барин.
>Поэтому зря вы так нервно реагируете, имхо. Особенно учтя что неудобные ситуации
>можно создать практически любой ФС, идеальных то - не бывает ;)Уж это то, поверь, я знаю и без тебя.
>>Есть вопросы - спрашивай, есть возражения - аргументируй, только по делу,
>>а не так чтобы потроллить
>
>Да, собственно, троллинг самоцелью не является. Как максимум иногда в процессе не
>сдерживаюсь и перегибаю с едкостью коментов. Вы тоже не паинька. Ваши
>симпатии видно невооруженным глазом ;).Да я их и не скрываю, что не мешает мне трезво смотреть на другие вещи.
>Zfs не умеет увеличивать раздел raidz и raidz2. Одним 0 и 1
>рейдом сыт не будешь, без raidz zfs теряет одну из самых
>вкусных фич.Судя по ссылке http://www.codestrom.com/wandering/2009/03/zfs-vs-btrfs-comp... btrfs вообще убожище, больше чем raid 10 не умеет, несколько копий не умеет, по людски лить пулы для бекапов (send/receive) не умеет, дедубликацию не умеет, компресию тоже через жопу поддерживает.
Всего то аргументов - умеет онлайн ресайзинг. Не смешите, в рейд 1 и zfs такое умеет.
Или это ссылка такая старая?
>Судя по ссылке http://www.codestrom.com/wandering/2009/03/zfs-vs-btrfs-comp... btrfs вообще убожище, больше чем raid
>10 не умеет, несколько копий не умеет, по людски лить пулы
>для бекапов (send/receive) не умеет, дедубликацию не умеет, компресию тоже через
>жопу поддерживает.
>Всего то аргументов - умеет онлайн ресайзинг.Точнее - удаление устройств из ФС. Причем этот ресайзинг делается путем перемещения использованных chunks (кусков диска, чанков) с удаляемого диска не другие, для чего нужно, чтобы на остальных дисках было достаточно пустых чанков. А много свободного места не означает много свободных чанков - если в чанке записан хотя бы один самый маленький экстенет, то этот чанк уже не пустой. Так что на пустых дисках это работает, а вот как будет работать после использования в течение некоторого времени и при наличии снимков - это еще вопрос. Балансировка же экстентов между дисками пока только в планах.
>Не смешите, в рейд 1 и zfs такое умеет.
Ну отцепить подзеркало - не бог весть какая проблема. Вот целиком убрать устройство верхнего уровня пока нельзя (за исключением LogZill'ы).
>Или это ссылка такая старая?Да не такая уж и старая. Несколько копий метаданных оно умеет, называют это metadata mirroring, насчет данных не уверен, то думаю тоже могут.
Ну а все остальное у них в планах типа: https://btrfs.wiki.kernel.org/index.php/Project_ideas
Гляжу я на эти планы, и не могу отделаться от ощущения, что все это где-то уже видел.
Наконец-то, читая комментарии, встретил разбирающегося в файловой системе человека! Меня очень давно интересовал вопрос: можно ли сделать при помощи ZFS мега-массив из огромного количества Floppy-дисководов? Или подключить один Floppy-дисковод к существующим устройствам? Сохранятся ли данные, если вытащить дискету, или если на ней появятся сбойные секторы? При условии наличия большого количества свободного места на других дисках.
>конец-то, читая комментарии, встретил разбирающегося в файловой системе человека! Меня очень давно интересовал вопрос: можно ли сделать при помощи ZFS мега-массив из огромного количества Floppy-дисководов?Да вы, батенька, затейник :-) Сделаете обычную Floppy-дискету на 64 мегабайта - тогда сможете :-)
Iomega ZIP-Drive?
>Iomega ZIP-Drive?Ну вы и извращенцы :) а чем вам жесткие диски с sata или sas не подошли? Горячее подключение они вполне допускают...
Называть копирование информации в новый пул с последующим удалением старого «перетасовать в пул меньшего размера» — это несколько некорректно, вы не находите?
А именно уменьшение — ждём уже с ноября.Кстати, уменьшение объёма и удаление устройства — тоже разные вещи. Скажем, сейчас можно заменить одно из входящих в пул устройств другим, но невозможно уменьшить их число. То есть вы не можете заменить 4 диска по 30 гигов одним на 500. Вам придётся создать новый пул и перенести в него данные.
>Кстати, уменьшение объёма и удаление устройства — тоже разные вещи. Скажем, сейчас можно заменить одно из входящих в пул устройств другим, но невозможно
>уменьшить их число.С маленькой оговоркой: невозможно уменьшить число только виртуальных устройств верхнего уровня, участвующих в пуле ZFS на правах основных устройств памяти.
А что из себя представляют виртуальные устройства (ВУ) верхнего уровня, надо объяснять?
Объясняю для тех, кто не изучил матчасть. ВУ верхнего уровня может представлять из себя один физический носитель; два или более носителей, объединённых в зеркало; массив raidz; массив raidz2. Группа ВУ, входящих в пул, обеспечивает единое адресуемое пространство; по ВУ "размазываются" блоки данных созданных внутри пула файловых систем и Z-томов.>То есть вы не можете заменить 4 диска
>по 30 гигов одним на 500. Вам придётся создать новый пул
>и перенести в него данные.Ага. Только это делается очень быстро и без крови:
1) создаём новый пул из новых дисков;
2) делаем снимок со старого пула;
3) переносим снимок в новый пул;
4) удаляем старый пул;
5) меняем свойство точки монтирования нового пула на место старого;
6) физически отсоединяем ненужные диски.
> btrfs явно достигает готовности к продакшнуОткрываем https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Mul... и читаем:
Btrfs can do raid0, raid1, raid10 and it can duplicate metadata on a single spindle.А теперь берем сервер к примеру с 12 SATA дисками и делаем для примера из 10-ти raidz2 + 2 spare. И механизм целостности данных есть, и не очень много емкости дисковой пропало... Чтобы оно еще и летало, добавляем в zpool пару SSD в качестве log и cache устройств.
С одной оговоркой только - все это делаем средствами BTRFS ;)Ну и кто от кого далеко по фичам?
>А в опенсорсе все просто - кому нужно, тот и упирается.Быть может Ораклу понадобится ZFS в Linux и он её перелицензирует под что нибудь более либеральное?
CDDL и так либеральнее некуда.
Есть куда. Вы про такие лицензии, как BSD и MIT, например, слышали?
>Есть куда. Вы про такие лицензии, как BSD и MIT, например, слышали?Слышал. И что?
> И что?То, что они не копилефт, в отличии от CDDL. А значит CDDL считаться либеральной не может. Зачем вообще её создали? Чем она лучше той же GPL? Ничем. Хотя ответ очевиден. Sun просто не хотел делиться с Linux-сообществом, ведь тогда бы у его Солярки не было фактически ничего нового.
> То, что они не копилефт, в отличии от CDDL.А я где-то утверждал, что она копилефт? Из вашего же "Быть может Ораклу понадобится ZFS в Linux и он её перелицензирует под что нибудь более либеральное?" читалось что этим самым более либеральным является GPL. Простите великодушно, если вы так не думали.
> А значит CDDL считаться либеральной не может.
Понятия о либеральности могут быть несколько разными.
> Зачем вообще её создали? Чем она лучше той же GPL? Ничем.
Тем, что она не вирусная, и в большей степени отвечает интересам коммерческого использования результатов разработки. И это не все.
> Хотя ответ очевиден. Sun просто не хотел делиться с Linux-сообществом, ведь тогда бы у его Солярки не было фактически ничего нового.
Вы не находите противоречия - мы тут вроде как порт ZFS в Линукс обсуждаем? Или по вашему поделиться означает дать право перелицензировать как угодно и делать все что угодно? Почему бы в таком случае Линукс не перелицензировать под что-нибудь менее вирусное? Ан, нельзя говорят: "иных уж нет, а те далече". А мне вот почему-то кажется что это просто удобная отговорка, поскольку в результате возни с перелицензированием можно просто напросто потерять контроль над проектом. Впрочем, это мое мнение и вы можете быть с ним не согласны.
>> Зачем вообще её создали? Чем она лучше той же GPL? Ничем.
>
>Тем, что она не вирусная, и в большей степени отвечает интересам коммерческого
>использования результатов разработки. И это не все.То, что не копилефт свободные лицензии "более отвечают интересам коммерческого использования" тезис достаточно спорный (хотя и придуман, конечно, не Вами), что бы после него добавлять "имхо", иначе это, простите, провокация и троллинг.
Не отрицайте, пожалуйста, существование других точек зрения, например, на то, что копилефт-лицензия всегда защищает первоначального разработчика, и его коммерческие интересы, заставляя все форки выкладывать патчи.
>>> Зачем вообще её создали? Чем она лучше той же GPL? Ничем.
>>
>>Тем, что она не вирусная, и в большей степени отвечает интересам коммерческого
>>использования результатов разработки. И это не все.
>
>То, что не копилефт свободные лицензии "более отвечают интересам коммерческого использования" тезис
>достаточно спорный (хотя и придуман, конечно, не Вами)Речь идет конкретно о CDDL, а не о "не копилефт свободных лицензиях", к которым CDDL не относится даже с точки зрения FSF.
>него добавлять "имхо", иначе это, простите, провокация и троллинг.А вы не провоцируйтесь и не тролльте, а то приписываете мне тут то, чего я не говорил.
>Не отрицайте, пожалуйста, существование других точек зрения, например, на то, что копилефт-лицензия
>всегда защищает первоначального разработчика, и его коммерческие интересы, заставляя все форки
>выкладывать патчи.Я ничего не отрицаю, даже больше - я никому ничего не навязываю. Более того, CDDL делает в сущности это же - она заставляет проекты, использующие исходные коды под CDDL открывать изменения в заимствованных файлах, но она не заставляет их использовать CDDL для всех остальных файлов в проекте.
Плюс, исходный разработчик может даже после того, как он продал все права на свою исходную разработку кому-то еще, и использовать открытые под CDDL части своей разработки, возвращая изменения к ним, и делая что угодно с остальными частями своего нового проекта.
>>него добавлять "имхо", иначе это, простите, провокация и троллинг.
>
>А вы не провоцируйтесь и не тролльте, а то приписываете мне тут
>то, чего я не говорил.Хорошо, извините, просто у BSD-фанатиков есть тезис: "BSD-like лицензии более удобны для коммерческого использования", этот тезис активно муссируется, и часто преподносится фанатиками, как это часто делают фанатики, как нечто бесспорное, и не имеющее других точек зрения
> А я где-то утверждал, что она копилефт?Вы говорите, что либеральней быть не может, будто не знаете, что такое копилефт :)
> читалось что этим самым более либеральным является GPL.
Нет, наоборот. Однако, я не сторонник либеральных лицензий везде, а только тогда, когда они необходимы.
> Понятия о либеральности могут быть несколько разными.
/* Следовательно, либеральные лицензии не являются копилефтом, в отличие от многих других лицензий открытого и свободного ПО. */
http://ru.wikipedia.org/wiki/%D0%9B%D0%B...
> Тем, что она не вируснаяВ чём это заключается?
> Или по вашему поделиться означает дать право перелицензировать как угодно и делать все что угодно?
Нет. Но здесь явно прослеживается то, о чём я говорю (по крайней мере мне так кажется). Вот вы, если бы не хотели, чтобы ваша ФС нативно использовалась на Linux, чтобы сделали? Правильно, использовали бы лицензию несовместимую с GPL.
> Почему бы в таком случае Линукс не перелицензировать под что-нибудь менее вирусное?
Чтобы код "украли"? Ну уж нет. Я не говорю, что CDDL надо менять на BSDL, например, по уму надо было не жадничать, а предусмореть будет ли возможна работа FS на всех свободных ОС или нет. А вот с проприетарщиками могли бы не делиться.
>> А я где-то утверждал, что она копилефт?
>
>Вы говорите, что либеральней быть не может, будто не знаете, что такое
>копилефт :)Да ладно. Я ж говорю, что понятие о либеральности может быть немного разным. А по сравнению с GPL она уж точно либеральнее.
>> читалось что этим самым более либеральным является GPL.
>
>Нет, наоборот. Однако, я не сторонник либеральных лицензий везде, а только тогда,
>когда они необходимы.То есть вы намекали, что может быть перелицензируют под BSD/MIT-like? Почему было сразу прямо так и не сказать? Ну и смысл-то подобного действия в чем?
>> Тем, что она не вирусная
>
>В чём это заключается?Не, ну неужели не знаете?
>> Или по вашему поделиться означает дать право перелицензировать как угодно и делать все что угодно?
>
>Нет. Но здесь явно прослеживается то, о чём я говорю (по крайней
>мере мне так кажется). Вот вы, если бы не хотели, чтобы
>ваша ФС нативно использовалась на Linux, чтобы сделали? Правильно, использовали бы
>лицензию несовместимую с GPL.Как мы видим, лицензия CDDL не помешала портировать во FreeBSD, FUSE, теперь уже Линукс, NetBSD где-то на подходе. И это не предел. Все остальное - разговоры в пользу бедных, и поиски оправдания ничего не делать и посылать пользователей нафик с из желаниями. Это, конечно, мое мнение, и я в курсе, что несогласных с ним гораздо больше, чем согласных.
К тому же, несовместимость CDDL и GPL никем не рассматривалась в суде, так что все рассуждения о несовместимости относятся больше к сфере интеллектуальных упражнений. Это, опять же, мое частное мнение.
>> Почему бы в таком случае Линукс не перелицензировать под что-нибудь менее вирусное?
>
>Чтобы код "украли"? Ну уж нет. Я не говорю, что CDDL надо
>менять на BSDL, например, по уму надо было не жадничать, а
>предусмореть будет ли возможна работа FS на всех свободных ОС или
>нет. А вот с проприетарщиками могли бы не делиться.То есть вы считаете, что люди из Сана, которые работали над созданием Соляриса долгие годы, поступили не по уму, заставив контору выпустить все под CDDL (по крайней мере, такая версия озвучена некоторыми на тот момент сотрудниками в известном дебиановском видео)? Пожадничали? То есть вы отказываете им в праве иметь собственное мнение о том? Они просто обязаны были сделать так, чтобы всем вокруг было удобно, пусть даже и в ущерб себе? И при этом, говоря о перелицензировании Линукса под чем-нибудь менее вирусным, вопрошаете: "Чтобы код "украли""? Детский сад, ей богу.
>в ущерб себе? И при этом, говоря о перелицензировании Линукса под
>чем-нибудь менее вирусным, вопрошаете: "Чтобы код "украли""? Детский сад, ей
>богу.Вы манипулируете фактами: перелицензирование Линукса под другой лицензией практически не реально,даже если бы и возникло такое желание у коммюнити и/или Торвальдса, так как в отличае от кода Sun, копирайт на каждой строчке стоит не того, кто управляет проектом (то есть, Sun в случае OpenOffice, ZFS) а того, кто код написал.
Поэтому предполагать в трезвом уме, что Linux так просто может взять и изменить лицензию, нельзя, и аргументом тезис о том, что такая лицензия была выбрана Sun специально, что бы не попала в Linux может быть.
>>в ущерб себе? И при этом, говоря о перелицензировании Линукса под
>>чем-нибудь менее вирусным, вопрошаете: "Чтобы код "украли""? Детский сад, ей
>>богу.
>
>Вы манипулируете фактами: перелицензирование Линукса под другой
>лицензией практически не реально, даже если
>бы и возникло такое желание у коммюнити и/или Торвальдса, так как
>в отличае от кода Sun, копирайт на каждой строчке стоит не
>того, кто управляет проектом (то есть, Sun в случае OpenOffice, ZFS)
>а того, кто код написал.С чего это вдруг я манипулирую? В 2000 году никто даже и не продполагал, что можно открыть исходники Соляриса - все считали, что там все запущено, куча кода от разных контор с разными лицензиями, и с этим никогда не разобраться. Что мы имеем на сегодня - практически весь код открыт. Так что тот, кто хочет что-то сделать - ищет возможности это сделать, а кто не хочет - ищет оправдания, чтобы этого не делать.
>Поэтому предполагать в трезвом уме, что Linux так просто может взять и
>изменить лицензию, нельзя, и аргументом тезис о том, что такая лицензия
>была выбрана Sun специально, что бы не попала в Linux может
>быть.Мнение насчет возможности перелицензирования Линукса под GPLv3 - оно даже не мое, оно самого отца-основателя, который говорил, что готов рассматривать такую возможность при условии, что Сан выпустит ZFS не только под CDDL, но и под GPLv3.
Я понимаю, конечно, что я могу быть не в трезвом уме, но вы же не будете обвинять в этом самого отца-основателя?
>Мнение насчет возможности перелицензирования Линукса под GPLv3 - оно даже не мое,
>оно самого отца-основателя, который говорил, что готов рассматривать такую возможность при
>условии, что Сан выпустит ZFS не только под CDDL, но и
>под GPLv3.
>
>Я понимаю, конечно, что я могу быть не в трезвом уме, но
>вы же не будете обвинять в этом самого отца-основателя?Под CDL, BSD-like уже не возможно, так как слишком много кода "несогласных" пришлось бы переписать.
Поэтому аргумент о том, что можно выбрать для проекта(в отрыве от ZFS, для абстрактного проекта) лицензию, специально не совместимую с linux kernel вполне имеет право на жизнь.
>Под CDL,CDDL?
>BSD-like уже не возможно, так как слишком много кода "несогласных"
>пришлось бы переписать.Слишком много - это сколько? А вдруг несогласных гораздо меньше, чем кажется? Вдруг они на самом деле хотят этого, но стесняются попросить Линуса?
>Поэтому аргумент о том, что можно выбрать для проекта(в отрыве от ZFS,
>для абстрактного проекта) лицензию, специально не совместимую с linux kernel вполне
>имеет право на жизнь.Такая точка зрения имеет право на жизнь. Вот только она слабо канает как аргумент в поддержку позиции, что Сан сделал CDDL специально, чтобы нагадить линуксу.
>Такая точка зрения имеет право на жизнь. Вот только она слабо канает
>как аргумент в поддержку позиции, что Сан сделал CDDL специально, чтобы
>нагадить линуксу.Имхо, в последние годы Sun не отрицал, что RedHat, Novell и другие конторы, строящие бизнес вокруг Linux, его конкуренты.
Разве это не хороший ход, с точки зрения почившего Sun, подгадить конкуренту?
>
>>Такая точка зрения имеет право на жизнь. Вот только она слабо канает
>>как аргумент в поддержку позиции, что Сан сделал CDDL специально, чтобы
>>нагадить линуксу.
>
>Имхо, в последние годы Sun не отрицал, что RedHat, Novell и другие
>конторы, строящие бизнес вокруг Linux, его конкуренты.Ну даже если это и так, что из того? Конкуренция - это же хорошо, это здорово, это не дает застаиваться и загнивать, заставляет быть честным. При всем при этом Сан продавал и Линукс в том числе, причем от обоих названных конкурентов, а в последнее время даже виндоус официально поддерживал.
>Разве это не хороший ход, с точки зрения почившего Sun, подгадить конкуренту?
Каким образом подгадить-то? Я чего-то не понимаю вашей логики. Детский сад какой-то.
Оглядываясь назад, я бы сказал наоборот, что Сан делал такие глупости, что этим только и делал, что помогал Линуксу расти и становиться на ноги. Одно закрытие Соляриса для платформы x86 чего стоит. А вы заладили - "нагадил, нагадил".
Если бы в свое время они послушали Ларри МакВоя и открыли Солярис еще в середине девяностых - вот это можно было бы с некоторой натяжкой назвать "нагадили".
>Каким образом подгадить-то? Я чего-то не понимаю вашей логики.Скорее, делаете вид. А если правда(во что я не верю), еще раз перечитайте эту дисскуссию
>>Поэтому аргумент о том, что можно выбрать для проекта(в отрыве от ZFS, для абстрактного проекта) лицензию, специально не совместимую с linux kernel вполне имеет право на жизнь.и этот человек еще о BSD фанатиках рассуждает
>>>Поэтому аргумент о том, что можно выбрать для проекта(в отрыве от ZFS, для абстрактного проекта) лицензию, специально не совместимую с linux kernel вполне имеет право на жизнь.
>
>и этот человек еще о BSD фанатиках рассуждаетКакие фанатики? О чем Вы? Обыкновенный коммерческий интерес почившего Sun: подгадить Linux конкурентам, и не позволить использовать "их" ZFS с RHEL, SLE, и т д.
Это просто бизнес. Да и моральное право на такие действия у них было, единственное только что, после этого нельзя утверждать, что это Linux виноват, что нет ZFS в ядре, нет, это виноват почивший Sun.FreeBSD же они никогда не то, что не считали за конкурентов, вообще не замечали, судя по поддержке Java, и т д, хотя, конечно, по-человечески по отношению к своим клиентам они в этом были не правы.
Именно по этому во фре поддержка ZFS есть в апстриме, а в Linux никогда не будет, если Oracle не сменит лицензию.А для примера, на сколько реально Linux сменить лицензию, предлагаю Вам обратную ситуацию: завтра выходит новость, что FreeBSD сменила лицензию на GPLv3, или AGPL, ради какой-нибудь фичи в Linux (не важно какой, но вот ее захотели в коммюнити, и все тут! Ситуация виртуальная).
Ваши действия, мысли, эмоции? А Ваших друзей, коллег? Нужно это проекту, или нет?
Имхо, нет, и это просто не реально(!)
фантазируем..
>То есть вы намекали, что может быть перелицензируют под BSD/MIT-like?Я бы не сказал, что в данном случае это необходимость. Под GPL лучше - проприетарщики останутся с носом.
>Не, ну неужели не знаете?
Не знаю, что такое "вирусная".
>И при этом, говоря о перелицензировании Линукса под
>чем-нибудь менее вирусным, вопрошаете: "Чтобы код "украли""? Детский сад, ей
>богу.Если Linux перелицензируют, не дай бог под BSD, то его могут украсть проприетарщики. Я об этом.
>То есть вы считаете, что люди из Сана, которые работали над созданием
>Соляриса долгие годы, поступили не по уму, заставив контору выпустить все
>под CDDL (по крайней мере, такая версия озвучена некоторыми на тот
>момент сотрудниками в известном дебиановском видео)? Пожадничали? То есть вы отказываете
>им в праве иметь собственное мнение о том? Они просто обязаны
>были сделать так, чтобы всем вокруг было удобно, пусть даже и
>в ущерб себе?В мире СПО не любят (по крайней мере, я так считаю) жадин и скряг. Если уж делишься, так делись нормально. А то с проприетарщиками делимся, а с Linux и прочими ОС под GPL - нет? Их право. Но вам не кажется, что это тормозит прогресс?
>>То есть вы намекали, что может быть перелицензируют под BSD/MIT-like?
>
>Я бы не сказал, что в данном случае это необходимость. Под GPL
>лучше - проприетарщики останутся с носом.Да дались вам эти проприетарщики. О себе думайте, а не о том, чтоб они с носом остались.
>>Не, ну неужели не знаете?
>
>Не знаю, что такое "вирусная".И при этом рассуждаете "на счет перелицензировать линукс под чем-нибудь менее вирусным"
>>И при этом, говоря о перелицензировании Линукса под
>>чем-нибудь менее вирусным, вопрошаете: "Чтобы код "украли""? Детский сад, ей
>>богу.
>
>Если Linux перелицензируют, не дай бог под BSD, то его могут украсть
>проприетарщики. Я об этом.Они его и так крадут. Некоторых иногда за это преследуют, и они делают вид, что что-то там открывают.
>В мире СПО не любят (по крайней мере, я так считаю) жадин
>и скряг. Если уж делишься, так делись нормально. А то
>с проприетарщиками делимся, а с Linux и прочими ОС под GPL
>- нет? Их право. Но вам не кажется, что это тормозит
>прогресс?Что-то я как-то не наблюдаю особых толп проприетарщиков, которые прямо набросились на ZFS и утащили ее к себе. Все больше как-то открытые системы. Был один, который вроде собирался, да потом передумал почему-то. С чего бы это, не знаете?
А тормозит прогресс не это - тормозим прогресс тут мы с вами, поскольку вместо того, чтобы пойти и написать что-нибудь еще, мы треплемся тут в форуме. Как у одного известного разработчика OpenSolaris написано в подписи - "You will contribute more with mercurial than with thunderbird."
> И при этом рассуждаете "на счет перелицензировать линукс под чем-нибудь менее вирусным"Я не знаю таких унылых слов.
> А тормозит прогресс не это - тормозим прогресс тут мы с вамиДа, но я о том, что была бы ZFS в Linux ядре - люди бы вряд ли стали писать замену в виде btrfs, а занились бы чем то более полезным, например.
>> И при этом рассуждаете "на счет перелицензировать линукс под чем-нибудь менее вирусным"
>
>Я не знаю таких унылых слов.Расширяйте свой словарный запас и не только. Сходите на LORe спросите, в чем вирусность GPL, вам там объяснят. Хотя, впрочем, думаю вы и так прекрасно это знаете.
>> А тормозит прогресс не это - тормозим прогресс тут мы с вами
>
>Да, но я о том, что была бы ZFS в Linux ядре
>- люди бы вряд ли стали писать замену в виде btrfs,
>а занились бы чем то более полезным, например.А почему ZFS должна быть именно в ядре? Кто мешает использовать ее в виде отдельного модуля? stable_api_is_nonsense.txt? Так может пора пересмотреть необходимость в постоянной ломке интерфейсов? Представляете, сколько человеко-лет смогла бы сэкономить в этом случает RedHat, не занимаясь портированием нужных вещей из ванильного ядра, в котором постоянно все ломают, в свои стабильные версии? Мне кажется, это было бы гораздо более полезным, чем разговоры в пользу бедных о том, что все, что ни делается, должно выпускаться под GPL.
Почему вы не требуете наличия non-free VxFS в ядре?
Понимаете, никто не заставлял людей писать BTRFS. И совсем не факт, что даже если бы ZFS была в ядре, никто бы не стал писать BTRFS.
>А почему ZFS должна быть именно в ядре? Кто мешает использовать ее
>в виде отдельного модуля? stable_api_is_nonsense.txt? Так может пора пересмотреть необходимость в
>постоянной ломке интерфейсов? Представляете, сколько человеко-лет смогла бы сэкономить в этом
>случает RedHat, не занимаясь портированием нужных вещей из ванильного ядра, в
>котором постоянно все ломают, в свои стабильные версии?Нет, все правильно: end-user'ы получают новые фичи, RedHat, IBM, Novell, Google, и т д новые _протестированные_ фичи, а Linux быстрое развитие, такое, что конкуренты "Сперва не замечали, потом смеялись, а теперь начали бояться"(с).
В результате, он зарулил сейчас по распространенности все остальные платформы. Зачем менять эту крайне удачную стратегию? Не вижу в ней ничего плохого!
Просто не используйте пионерские ядра на серверах :)>Понимаете, никто не заставлял людей писать BTRFS. И совсем не факт, что
>даже если бы ZFS была в ядре, никто бы не стал
>писать BTRFS.Вот тут соглашусь :)
>Хотя, впрочем, думаю вы и так прекрасно это знаете.Я знаю что такое GPL. Но не считаю её вирусной.
>Почему вы не требуете наличия non-free VxFS в ядре?Скорей стану требовать исключения блобов из ядра, но с выходом libre-kernel - это не проблема.
> Я знаю что такое GPL. Но не считаю её вирусной.Только менее вирусной она от этого не становится
Кстати. О таком пути говорили, помнится, как только выяснилось, тчо лицензии несовместимы. Поразительно, что так долго ждали...
Боялись задолбаться допиливать под все новые версии ядра, как и в случае с NTFS.Вот кто-то не боится.
Ну, это уже вопрос хорошей коммуникации с ядерными разработчиками. Насколько я понимаю, преимущество нахождения в ядре в том, что если кто-то вносит несовместимые изменения, то он же старается пофиксить и поломанный код, + знает, куда обращаться, если сам не может. По ка FS не допилена и широкоизвестна (то есть ее в ядро бы и не взяли), это некритично. А если допилят - можно и договориться, чтобы сообщали. Будет, так сказать, неформальная часть ядра.
к зфс это все-равно не относится. cddl несовместима с гпл, а гпл как известно требует от распространяющего, чтобы весь код конечной программы был под ней.
>Ну, это уже вопрос хорошей коммуникации с ядерными разработчиками. Насколько я понимаю,это скорее вопрос грамотности портирования. Здесь все сделано очень красиво - реалиован "клей" позволяющий склеить практически немодифицированные исхолники ZFS, экспортирующие наружу солярисный VFS, с линуксовым VFS. Так что в случае глобальных перемен в линуксовом VFS переделывать придется только этот "клей". Клей этот называется Solaris Porting Layer.
Вот вам и причина неудовлетворительной производительности linux
Пруфы будут?
http://www.phoronix.com/scan.php?page=article&item=linux_win...
>http://www.phoronix.com/scan.php?page=article&item=linux_win...По мне - Ubuntu не совсем Linux. Сравнивайте Макинтош и виндвос с Linux. Например, Альт, Дебиан и SuSE. В идеале - Gentoo. Фороникс вроде Arch осваивать начинает...
>По мне - Ubuntu не совсем LinuxНа главной странице Ubuntu.com нет ни слова про Linux, потому что Linux - это не модно.
> Вот вам и причина неудовлетворительной производительности linuxЭээ.. Это к чему было? Или лишь бы чего-нибудь ляпнуть?
>Боялись задолбаться допиливать под все новые версии ядра, как и в случае
>с NTFS.
>
>Вот кто-то не боится.Поэтому разработчик и выложил готовые src.rpm только под шестой rhel с его стабильным API/ABI (что бы можно было пользоваться 7 лет)
Правда, кроме RHEL, еще ФС еще тестировалась под Ubuntu.
>Кстати. О таком пути говорили, помнится, как только выяснилось, тчо лицензии несовместимы.
>Поразительно, что так долго ждали...да уж, только мы на опеннете обсудили btrfs - а тут же такой ход... Брайан опеннет читает, к гадалке не ходи.
>Поразительно, что так долго ждали...Дождались. Теперь в каждой новости про ядро, хомячки будут спрашивать _нас, когда же наконец починят, отвалившийся у _них аж NN релизов тому: 1) блоб от NVidia; 2) клей от Белендорфа.
>>Поразительно, что так долго ждали...
>
>Дождались. Теперь в каждой новости про ядро, хомячки будут спрашивать _нас, когда
>же наконец починят, отвалившийся у _них аж NN релизов тому: 1)
>блоб от NVidia; 2) клей от Белендорфа.Незатейливый такой FUD.
Очевидно, Брайан в первую очередь ориентируется на RedHat, который все-таки постабильнее будет, чем ванильное ядро, в котором, как известно, постоянная ломка и переделывание всего что можно возведено чуть ли не в ранг абсолютного добра.
>Незатейливый такой FUD.
>ванильное ядро, в котором, как известно,
>чуть ли не в ранг абсолютного добра.Да, согласен. Про Абсолютное Добро -- гораздее затейливее.
>>Незатейливый такой FUD.
>>ванильное ядро, в котором, как известно,
>>чуть ли не в ранг абсолютного добра.
>
>Да, согласен. Про Абсолютное Добро -- гораздее затейливее.stable_api_nonsense.txt
почитайте на досуге.
дык проект уже давно существует)zfs-0.4.9 tgz | zip ZFS Version 0.4.9 2010-05-23
...........
zfs-0.4.1 tgz | zip ZFS Version 0.4.1 2009-01-21
странный ход при то что btrfs допиливается и скоро будет тестироваться на хомяках
как прекрасно процветает копирастия в мире опенсоурса - все почитают и соблюдают чужие лицензии, никакого перацтва...
Ну, копирасы хотели чтобы с ними играли по их правилам? Отлично, как говорится, "кто к нам с чем и зачем, тот от того и - того!". Вот пусть теперь и соблюдают лицензии, раз уж они так этого хотели. Например типа GPL, GFDL и прочих CreativeCommons-ов и чего там еще. Ахахаха, человек всегда побеждал не большими мускулами и даже не длинным баксом. Поэтому уж кто-кто а програмеры в пролете явно не будут.
наконец-то... ZFS давно ждал под Linux :)
Ну вот и сбылась перво апрельская шутка - http://code.google.com/p/zfs-linux/source/browse/trunk/zfs.c
>www.pavlinux.ruZAO MTU-Intel 27 Smolenskaya-Sennaya Sq., bld. 2 119121, Moscow Russia
FreeBSD nginx/0.7.62маскируешся)
Он просто некрофил ;)
Фейл месяца ;)
Те, у кого OpenVZ, вероятно сий поделкой заинтересуются - в силу того, что CoW очень даже для OpenVZ нужен. Я - не исключение.Однако btrfs уже выходит на порог -stable - дисковый формат финализирован, теперь только фиксят баги, из которых фатальных находится все меньше и меньше. И в RHEL6 beta оно уже в статусе tech preview, что как бы намекает.
Поэтому как только будет btrfs - естественно, сразу же будет переход на btrfs по мере возможности (плановый). А пока что можно потестить на мелких хостингах и эту надстройку, правда ей до массового продакшна еще больше, чем самой ZFS, но может хоть работать будет стабильно.
> правда ей до массового продакшна еще больше, чем самой ZFSО, да. Что-то я не припомню падения серверной фермы Sun Microsystems. :)
>[оверквотинг удален]
>
>Однако btrfs уже выходит на порог -stable - дисковый формат финализирован, теперь
>только фиксят баги, из которых фатальных находится все меньше и меньше.
>И в RHEL6 beta оно уже в статусе tech preview, что
>как бы намекает.
>
>Поэтому как только будет btrfs - естественно, сразу же будет переход на
>btrfs по мере возможности (плановый). А пока что можно потестить на
>мелких хостингах и эту надстройку, правда ей до массового продакшна еще
>больше, чем самой ZFS, но может хоть работать будет стабильно.Извините, но это все, имхо, от неумеренной экономии: используйте PVC вместо OVZ, и будете не только экономить дисковое место, но и RAM с помощью vzfs, если для Вас это важно...
Прошу прощения, но с их безумными ценами percpu*percontainer*permonth оно мне выйдет куда дороже, чем диски и память, в которые вклад разовый.
>Прошу прощения, но с их безумными ценами percpu*percontainer*permonth оно мне выйдет куда
>дороже, чем диски и память, в которые вклад разовый.А Вы покупайте "вечные" лицензии, и не ведитесь на лохотрон с "арендой", и подумайте, так ли Вам нужен SUS(хотя и он, имхо, не такой дорогой). end-user'ы оценят ту же VZPP.
Нормальная машина(SAS raid10) под Virtuozzo/OpenVZ стоит все равно ~140-170k рублей, не вижу проблемы в том, что бы заплатить в два раза больше за двухсокетовую PVC.
>Однако btrfs уже выходит на порог -stable - дисковый формат финализированВ ваших фантазиях.
Примерно месяц назад в мейл листе был выложен патч уменьшающий тормоза BTRFS в ситуации когда осталось свободного места ~10%, в описании особо отмечено что формат данных на диске будет изменен без этого не обойтись
>В ваших фантазиях.
>Примерно месяц назад в мейл листе был выложен патч уменьшающий тормоза BTRFS
>в ситуации когда осталось свободного места ~10%, в описании особо отмечено
>что формат данных на диске будет изменен без этого не обойтисьЕсть разница между инкрементальным и несовместимым изменением. Инкрементальные изменения формата ничего страшного собой не представляют.
Позитивно. Через год ко всем кроме вантузятников (не к ночи будь помянуты) можно будет со спокойной душой в гости с винтом с ZFS ходить. Если конечно скептики не задолбают Брайана фразами типа "вантуз - наще фсё", "btrfs forever в каждую дырку" и т.д. и т.п. и х.з.. При всём том парке файловых систем которые наворотили в ляликсе возмущения "зачем ZFS если когданибудь btrfs" как-то стёбно смотрятся.
>Позитивно. Через год ко всем кроме вантузятников (не к ночи будь помянуты)Вантузятники вроде тоже выражали заинтересованность в портировании ZFS на вантуз. Не знаю, нашли ли они финансирование под это дело, как Брайан.
> При всём том парке файловых систем которые наворотили в ляликсе возмущения "зачем ZFS если когданибудь btrfs" как-то стёбно смотрятся.
Линаксоеды такие линаксоеды. Сколько было песен спето, про то, что ZFS - это комбайн-все-в-одном-и-не-нужно, но как только появилась BTRFS, про комбайн-все-в-одном как-то резко подзабылось, хотя по сути - то же самое :-)
https://btrfs.wiki.kernel.org/index.php/FAQ#Does_the_Btrfs_m...
если комбайн с ракетным ускорителем и ионной пушкой - да, такой комбайн нужен
>>Позитивно. Через год ко всем кроме вантузятников (не к ночи будь помянуты)
>
>Вантузятники вроде тоже выражали заинтересованность в портировании ZFS на вантуз. Не знаю,
>нашли ли они финансирование под это дело, как Брайан.а им искать незачем, они просто сделают и не спрашивая возьмут денежку с серверных систем.
здорово, но поздно. народ переходит на btrfs.у меня лично она работает на разделе, хранящем 250 гигов "долгого ящика" -- ISO'шники, фильмы, прочая фигня. соответственно, при форматировании раздела эти 250 гигов перекочевали сначала на временный винт, потом обратно. от прироста скорости записи в сравнении с ZFS и reiserfs был, честно говоря, в шоке. работает стабильно (ubuntu 10.04. linux-2.6.32), каши не просит. можно пользоваться!
ИМХО, модуль ZFS для линукса, да еще создаваемый по заказу федерального министерства, нужен исключительно для миграции. сами понимаете, с чего на что.
>сами понимаете, с чего на что.NFS-ы, самбы и FUSE-ы, полагаете, _не_ достаточно мазохистичны в сравнении с?..
ну, FUSE модуль стабильно никогда не работал.а так логично получается: система стоит на одном диске, сторэдж -- на остальных. меняем систему, цепляем существующий пул -- и никакого гемора с переносом данных.
nfs нужен, samba - только для совместимости (вместо ldap\ad есть более вменяемые аналоги, как файлообмен - иногда катит, но nfs шустрее все равно), fuse нужен только для небольшой части задач (только когда в гости с ntfs приходят + всякие извраты типа sshfs)
>ИМХО, модуль ZFS для линукса, да еще создаваемый по заказу федерального министерства,
>нужен исключительно для миграции. сами понимаете, с чего на что.Неужели с Solaris'а на Линукс?
прикиньте?! вот уроды, правда?:)
>прикиньте?! вот уроды, правда?:)То есть я угадал, да?
> в сравнении с ZFS и reiserfsXFS, конечно. опечатался.
>здорово, но поздно. народ переходит на btrfs.Ога, так и запишем - народ в лице fresco переходит на btrfs. Отучаемся говорить за всех, не?
>у меня лично она работает на разделе, хранящем 250 гигов "долгого ящика"
>-- ISO'шники, фильмы, прочая фигня. соответственно, при форматировании раздела эти 250
>гигов перекочевали сначала на временный винт, потом обратно.А как же пресловутая конвертация из ext3? Не рискнули?
> от прироста скорости записи в сравнении с ZFS и reiserfs был, честно говоря, в
>шоке. работает стабильно (ubuntu 10.04. linux-2.6.32), каши не просит. можно пользоваться!Цыферками не поделитесь? А то "в шоке" - это как-то очень субъективно и может трактоваться по разному.
> Ога, так и запишем - народ в лице fresco переходит на btrfs.я не только на своем примере, много где уже видел.
> А как же пресловутая конвертация из ext3? Не рискнули?
у меня нет и никогда не было ext2/3/4
> Цыферками не поделитесь?
на том конкретном старом 500Gb HDD reiserfs давала записи 30Мб/с, XFS -- 35 Мб/с, btrfs -- 60 Мб/с
>> Ога, так и запишем - народ в лице fresco переходит на btrfs.
>
>я не только на своем примере, много где уже видел.О массовом переходе говорить, как мне кажется, преждевременно. Если уж сами разработчики _надеются_, что более-менее стабильной она станет к Fedora 16-17.
>> А как же пресловутая конвертация из ext3? Не рискнули?
>
>у меня нет и никогда не было ext2/3/4Понятно.
>> Цыферками не поделитесь?
>
>на том конкретном старом 500Gb HDD reiserfs давала записи 30Мб/с, XFS --
>35 Мб/с, btrfs -- 60 Мб/сМегабит? Думаю, что все-таки мегабайт, что для старого диска есть близко к скорости линейной записи. Чего и следовало ожидать, в общем-то. А когда начинается падение скорости не измеряли? Ну там при 70-80-90 : заполненности?
диск не столь уж стар, года 3 ему. думаю, без ФС метров 80-90 в секунду он давать на моей системе в состоянии.как заполнится на 90% -- могу отписать :)
Кстати, о каше.
Сколько кэши?
> диск не столь уж стар, года 3 ему. думаю, без ФС метров 80-90 в секунду он давать на моей системе в состоянии.Три года для винта - это уже возраст.
> как заполнится на 90% -- могу отписать :)
Давай, интересно будет посмотреть
Ну слава богу. Я уж боялся так и придется жить с btrfs, по сути со студенческим закосом под ZFS.
>Ну слава богу. Я уж боялся так и придется жить с btrfs,
>по сути со студенческим закосом под ZFS.А зря: btrfs, в отличае от этой реализации zfs, работает через device-mapper, что банально очень удобно.
>>Ну слава богу. Я уж боялся так и придется жить с btrfs,
>>по сути со студенческим закосом под ZFS.
>
>А зря: btrfs, в отличае от этой реализации zfs, работает через device-mapper,
>что банально очень удобно.Что, в самом деле? Странно как-то. ZFS вообще все равно, что за блочное устройство внизу, лишь бы но кэш флаши честно отрабатывало. Правда пробовали и не работает?
Хотя смысла использовать ZFS поверх Device Mapper никакого нет, если честно. Только лишняя сущность с лишней сложностью добавляется.
>Хотя смысла использовать ZFS поверх Device Mapper никакого нет, если честно. Только
>лишняя сущность с лишней сложностью добавляется.Вы просто не умеете готовить device-mapper, и не знаете, что он дает :) например, погуглите по kpartx, dm-ioband, и т д.
Ничего революционного в этом нет, но завязаны-то эти технологии на device-mapper! А плыть по течению, разворачивая решение linux-way (как и Debian-way, RedHat-way, FreeBSD-way, и т д, в зависимости от проекта) всегда проще и эффективнее, чем придумывая свои велосипеды
>>Хотя смысла использовать ZFS поверх Device Mapper никакого нет, если честно. Только
>>лишняя сущность с лишней сложностью добавляется.
>Вы просто не умеете готовить device-mapper, и не знаете, что он дает :) например, погуглите по kpartx, dm-ioband, и т д.Да я вобщем-то и не претендовал на мастерство в "готовке" device-mapper. Так что можете объяснить мне, какую пользу вы видите от использования dm-ioband вместе с ZFS.
>>>Хотя смысла использовать ZFS поверх Device Mapper никакого нет, если честно. Только
>>>лишняя сущность с лишней сложностью добавляется.
>>Вы просто не умеете готовить device-mapper, и не знаете, что он дает :) например, погуглите по kpartx, dm-ioband, и т д.
>
>Да я вобщем-то и не претендовал на мастерство в "готовке" device-mapper. Так
>что можете объяснить мне, какую пользу вы видите от использования dm-ioband
>вместе с ZFS.Читайте файл /usr/share/doc/dm-ioband/README о том, что это такое, и зачем нужно.
>>Да я вобщем-то и не претендовал на мастерство в "готовке" device-mapper. Так
>>что можете объяснить мне, какую пользу вы видите от использования dm-ioband
>>вместе с ZFS.
>
>Читайте файл /usr/share/doc/dm-ioband/README о том, что это такое, и зачем нужно.Опять вы мимо кассы. Я знаю, что это такое и зачем это нужно. Давайте, покажите мне, где там написано, как получить пользу от использования dm-ioband вместе с ZFS.
>>>Да я вобщем-то и не претендовал на мастерство в "готовке" device-mapper. Так
>>>что можете объяснить мне, какую пользу вы видите от использования dm-ioband
>>>вместе с ZFS.
>>
>>Читайте файл /usr/share/doc/dm-ioband/README о том, что это такое, и зачем нужно.
>
>Опять вы мимо кассы. Я знаю, что это такое и зачем это
>нужно. Давайте, покажите мне, где там написано, как получить пользу от
>использования dm-ioband вместе с ZFS.Как уже выше сказала, бесплатный консалтинг это зло. Спор должен быть на равных, а Вы еще ни разу, на моей памяти, ни о чем, кроме ZFS ни с кем не спорили (имхо, у Вас ограниченный кругозор)
Мне не нужен dm-ioband бо я не занимаюсь шаред хостингом, как и прочая ограничивающая пердь, мне вообще всегда нужна максимальная скорость моего рейда/канала в инет/количества памяти и тд, так же как вобщем-то мне не уперлась и сама виртуализация, возможностей виртуалбокса хватает выше крыши. Вам как и вашей конторе все технологии интересны _только_ с точки зрения виртуализации. Там подрезать, тут ограничить, и еще вот там пямяти отжать. В итоге у вас одно желание - запустить на достаточно дешевом сервере стотыщпицот виртуалок, и продавать их по 20 копеек, а заказчики пусть мучаются, нехай их приложения тормозят и сайты по 3 минуты открываются. Вам важно как можно больше виртуалок запихать в серваг. Я вообще не вижу где между вашими запросами и моими поставить знак равенства. Будет потребная реализация этой фс в линуксе перейду на нее как на дефолтную. Очевидно что btrfs будет только в линуксе и нигде больше. Сейчас файло на потаскушнике приходится таскать на позорной ntfs, а винт с zfs можно будет сунуть уже в 3 операцинки.
>Мне не нужен dm-ioband бо я не занимаюсь шаред хостингом, как и
>прочая ограничивающая пердь, мне вообще всегда нужна максимальная скорость моего рейда/канала
>в инет/количества памяти и тд, так же как вобщем-то мне не
>уперлась и сама виртуализация, возможностей виртуалбокса хватает выше крыши. Вам как
>и вашей конторе все технологии интересны _только_ с точки зрения виртуализации.
>Там подрезать, тут ограничить, и еще вот там пямяти отжать. В
>итоге у вас одно желание - запустить на достаточно дешевом сервере
>стотыщпицот виртуалок, и продавать их по 20 копеек, а заказчики пусть
>мучаются, нехай их приложения тормозят и сайты по 3 минуты открываются.
>Вам важно как можно больше виртуалок запихать в серваг.Мы не продаем хостинг конечным клиентам, а виртуализация применима далеко не только для хостинга, даже скорее не для хостинга. Если Вы достаточно богаты, что бы выделять по железке на каждый сервис, что ж... Вам можно только позавидовать.
Тот же dm-ioband удобен тем, что на смешанном сервере (какой-нибудь Tomcat Application с базой на этой же железке) можно поставить разный вес по i/o для базы данных, и самого Tomcat, и это скажется положительным образом на стабильности сервиса, и не позволит ни Tomcat'у съесть все ресурсы дисковой подсистемы, ни СУБД.
А еще, есть многие другие удобные фичи device-mapper, тот же luks, например...
З.Ы. Имхо, dm-ioband удобнее CFQ, и просто лучше работает, хотя, к сожалению, и не в апстриме...
>Очевидно что btrfs будет только в линуксе и нигде
>больше. Сейчас файло на потаскушнике приходится таскать на позорной ntfs, а
>винт с zfs можно будет сунуть уже в 3 операцинки.Тут я с Вами согласна, только ZFS вряд ли попадет в апстримное ядро (а, значит, в любые дистрибутивы), если Oracle не сменит политику
>>Очевидно что btrfs будет только в линуксе и нигде
>>больше. Сейчас файло на потаскушнике приходится таскать на позорной ntfs, а
>>винт с zfs можно будет сунуть уже в 3 операцинки.
>
>Тут я с Вами согласна, только ZFS вряд ли попадет в апстримное
>ядро (а, значит, в любые дистрибутивы), если Oracle не сменит политикуА какие плюсы от присутствия в апстриме, в котором постоянно все ломают? Вот SystemTap не в апстриме, но это не мешает Редхату его развивать, поддерживать и рекомендовать к использованию.
И если вдруг клиенты РедХата захотят использовать ZFS на своем любимом РедХате, придумать причину для отказа РедХату будет гораздо труднее, чем Линусу и компании.
Так что поживем - увидим. В то, что кто-то сделает порт ZFS для линукс опеннтовско-лоровские аналитеги тоже не верили. И что мы видим?
>Как уже выше сказала, бесплатный консалтинг это злоГде вы тут бесплатный консалтинг разглядели? Я вас никакой консалтинг не просил - ни платный, ни бесплатный. Да и вообще - не боитесь, что почитав эти дискуссии, ваши потенциальные заказчики не придут к вам ни за платным, ни даже за бесплатным консалтингом.
> Спор должен быть на равных, а Вы еще ни разу, на моей памяти, ни о чем, кроме ZFS ни с кем не спорили (имхо, у Вас ограниченный кругозор)
Могу посоветовать вам больше заботиться о широте своего кругозора и глубине знаний в профильных областях, чем о широте моего, об этом я позабочусь сам. Я могу вам сказать совершенно определенно, что в части особенностей практического применения LVM, ext4, dm-ioband, vzfs, KVM и много чего еще вы определенно знаете больше меня просто потому, что я не пользуюсь всем этим каждый день, а интересуюсь для широты того самого кругозора. В фундаментальных же вопросах, связанных с хранением данных, ваши познания как минимум недостаточно глубоки, что я со стороны вижу, а вы сами - нет. Впрочем, вам это похоже не интересно, так что продолжайте оставаться в неведении.
Насчет "ни о чем, кроме ZFS" вы абсолютно не правы - только в этом обсуждении было затронуто множество тем. Впрочем, можно признать, что имеет место быть некоторый уклон в сторону хранения данных и всего что с этим связано. Но что поделать - одна из областей профессиональных интересов.
>Да и вообще - не боитесь,
>что почитав эти дискуссии, ваши потенциальные заказчики не придут к вам
>ни за платным, ни даже за бесплатным консалтингом.Все это можно найти в сети, и Вы слишком плохо обо мне думаете: консалтинг нужен для тех, кто не хочет пользоваться поиском(из-за показной лени, и желания заплатить, что бы все сразу рассказали). Что касается Вас, давно бы почитали, после всех намеков, как происходит consistency check у разных вендоров raid-массивов, и для raid5/6 что такое bad stripes, и т д
Нет, Вы уперлись зачем-то в свой ZFS, и не видите, не хотите понимать, и не верите, что похожие фичи (но только не на уровне данных, а блоков рейд-массива, что в большинстве случаев достаточно, и даже это не всегда нужно) есть и в raid5/6.
Почему достаточно, я пояснила выше (так как это просто фича высокой доступности)Сознательно же не писать какую-то информацию глупо и не честно по отношению к колегам, и противоречит духу OpenSource :)
>> Спор должен быть на равных, а Вы еще ни разу, на моей памяти, ни о чем, кроме ZFS ни с кем не спорили (имхо, у Вас ограниченный кругозор)
>В фундаментальных же вопросах, связанных с хранением данных, ваши познания как
>минимум недостаточно глубоки, что я со стороны вижу, а вы сами
>- нет.Может быть, но я в Вашем случае увидела то же самое :)
Про себя я уверена, что вообще знаю гораздо меньше, чем мне хотелось бы!
И, может быть, кажется посетителям этого форума: уверена, что сюда ходят люди, в целом гораздо более опытные, и обладающие большим багажем знаний.
> Что касается Вас, давно бы почитали, после всех намеков, как происходит consistency check у разных вендоров raid-массивов, и для raid5/6 что такое bad stripes, и т дНе, вы на самом деле считате, что я ничего не знаю про RAID? Я уже два раза предлагал, предлагаю в третий - давайте рассмотрим простой пример. Предположим, есть RAID5 из 4 дисков с данными, четырех дисков с данными, одним диском с четностью. Предположим, на нем есть страйп, XOR блоков которого не дает в резульате все нули (или все единицы, не принципиально). Как определить, на каком из пяти дисков неправильные данные? Что будет делать RAID-контроллер? Что он будет делать, если один из дисков будет неисправен?
>Нет, Вы уперлись зачем-то в свой ZFS,
Вам показалось. Контроль целостности есть не только в ZFS, но и в btrfs и некоторых других системах тоже, правда реализован везде немного по-своему, поэтому в части полноты контроля они могу отличаться. Так что дело не в ZFS, а все-таки в контроле целостности самом по себе и его плюсах, которые он может дать.
>и не видите, не хотите понимать, и не верите, что похожие фичи (но только не на уровне данных, а блоков рейд-массива, что в большинстве случаев достаточно, и даже это не всегда нужно) есть и в raid5/6.
Я вам не спроста подсовываю пример - дело в том, что то, что вы называете "похожими фичами", на самом деле имеет весьма мало общего с контролем целостности.
Достаточно этих ваших "подобных фич" или нет, вы поймете тогда, когда столкнетесь с необходимостью поиска источника неявного повреждения данных.
>Сознательно же не писать какую-то информацию глупо и не честно по отношению к колегам, и противоречит духу OpenSource :)
>
>Может быть, но я в Вашем случае увидела то же самое :)Чтобы не быть голословной, не моглы бы вы написать, что же такое вы увидели? Иначе получается, что вы ведете себе ровно в соответствии с вашими словами выше - глупо, нечестно по отношению к коллегам и противореча духу OpenSource. И не надо больше про консалтинг, ладно?
>> Что касается Вас, давно бы почитали, после всех намеков, как происходит consistency check у разных вендоров raid-массивов, и для raid5/6 что такое bad stripes, и т д
>
>Не, вы на самом деле считате, что я ничего не знаю про
>RAID? Я уже два раза предлагал, предлагаю в третий - давайте
>рассмотрим простой пример. Предположим, есть RAID5 из 4 дисков с данными,
>четырех дисков с данными, одним диском с четностью.Вам кол, пойдите, пожалуйста, поучитесь, а потом начинайте спорить :(
(подсказка для начала обучения, почитайте чем raid5 отличается от raid4)
>Чтобы не быть голословной, не моглы бы вы написать, что же такое
>вы увидели?Увы, необразованность. Надеюсь, дальше тут не будет упорства в невежестве и фанатизма, так как это уже будет не грустно, а смешно.
Я сама такой же была где-то года два тому назад, но вовремя удержалась от того, что бы начать на форумах доказывать свое "мнение". Прошу не обижаться, тема старая, ее уже большинство опеннетовцев не читает, но советую сперва подучить основы, а потом начинайте спорить, хотя, конечно, не знать что-то не стыдно, стыдно в этом упорствовать (да и у меня тоже кое-где до сих пор пробелы, в том, что знать нужно)>Иначе получается, что вы ведете себе ровно в соответствии
>с вашими словами выше - глупо, нечестно по отношению к коллегам
>и противореча духу OpenSource.Я давала Вам достаточно много подсказок, на основе которых Вы бы _могли_ воспользоваться гуглом, и давно уже прекратить эту нелепую дисскуссию, Вы слишком многого не знаете :(
>И не надо больше про консалтинг, ладно?
Не буду. Советую пойти на платные курсы (у нас нет и вряд ли будет когда-нибудь, поэтому коммерческого интереса нет), или заройтесь в редбуки того же IBM.
Если хватит терпения, через пол-года будете меня в мои ляпы тыкать :)
>>Не, вы на самом деле считате, что я ничего не знаю про
>>RAID? Я уже два раза предлагал, предлагаю в третий - давайте
>>рассмотрим простой пример. Предположим, есть RAID5 из 4 дисков с данными,
>>четырех дисков с данными, одним диском с четностью.
>
>Вам кол, пойдите, пожалуйста, поучитесь, а потом начинайте спорить :(Вы не пединститут случайно закончили?
>(подсказка для начала обучения, почитайте чем raid5 отличается от raid4)
О, знаем отличия RAID5 от RAID4! Ну хоть что-то из Редбуков усвоили. Подсказка вам - в данном примере различия некритичны, тем более в контексте одного страйпа. Хотите - пусть будет RAID4.
Может все-таки попытаетесь на вопрос ответить, а?
>Увы, необразованность. Надеюсь, дальше тут не будет упорства в невежестве и фанатизма,
>так как это уже будет не грустно, а смешно.Факты?
>Я сама такой же была где-то года два тому назад, но вовремя
>удержалась от того, что бы начать на форумах доказывать свое "мнение".Увы, вы его даже не пытаетесь доказывать. Да и зачем это делать, ведь троллить просто так гораздо веселее.
>Прошу не обижаться, тема старая, ее уже большинство опеннетовцев не читает,
>но советую сперва подучить основы, а потом начинайте спорить, хотя, конечно,
>не знать что-то не стыдно, стыдно в этом упорствовать (да и
>у меня тоже кое-где до сих пор пробелы, в том, что
>знать нужно)Вот именно в этом вы и упорствуете - вы даже не пытаетесь понять, то что я хочу вам помочь понять, не отсылая, заметьте, к гуглам и редбукам. Ну что ж, ваше право.
>Если хватит терпения, через пол-года будете меня в мои ляпы тыкать :)
ЧСВ не зашкаливает?
>[оверквотинг удален]
>О, знаем отличия RAID5 от RAID4! Ну хоть что-то из Редбуков усвоили.
>Подсказка вам - в данном примере различия некритичны, тем более в
>контексте одного страйпа. Хотите - пусть будет RAID4.
>
>Может все-таки попытаетесь на вопрос ответить, а?
>
>>Увы, необразованность. Надеюсь, дальше тут не будет упорства в невежестве и фанатизма,
>>так как это уже будет не грустно, а смешно.
>
>Факты?Мне не интересно больше спорить с Вами. Через год-два, когда перечитаете эту тему, поймете почему.
Не будьте клоуном, пожалуйста. Больше отвечать в этот тред не буду.Спорить нужно на равных, а Вы только смешите, так как Вас даже не осадил факт уличения того, что Вы не знаете основ(чем отличается raid 4 от raid5 и 6, а так же того, еще в прошлой дисскуссии с месяц тому назад, и в этой, что Вы не удосужились прочитать, как raid 5/6 восстанавливает блоки данных, хотя Вам на это неоднакратно намекалось)
Начните сегодня вечером чтение с того, как работает raid5/6. Объяснять это я Вам не буду, так как это не этично (не заставит Вас начать учиться), и вообще-то, все-таки стоит денег, но Вы упорно пытаетесь меня заставить выдать Вам текст, тогда как он гуглится за пять минут.
>[оверквотинг удален]
>raid 4 от raid5 и 6, а так же того, еще
>в прошлой дисскуссии с месяц тому назад, и в этой, что
>Вы не удосужились прочитать, как raid 5/6 восстанавливает блоки данных, хотя
>Вам на это неоднакратно намекалось)
>
>Начните сегодня вечером чтение с того, как работает raid5/6. Объяснять это я
>Вам не буду, так как это не этично (не заставит Вас
>начать учиться), и вообще-то, все-таки стоит денег, но Вы упорно пытаетесь
>меня заставить выдать Вам текст, тогда как он гуглится за пять
>минут.Ну что ж - слив засчитан :-)
>Ну что ж - слив засчитан :-)Да уж, Вам. Не знать, что такое raid4 или raid5, это epic fail.
Предсказываю: когда подрастете, и начнете, наконец, читать оригинальнульную документацию на английском, а потом дорастете до чтения док вендоров по аппаратным raid-массивам, если вдруг вспомните про эту тему,
Вам станет мучительно стыдно за свою необразованность, что даже_сейчас_ Вы не понимаете, что за дурость Вы в нескольких местах этой темы написали.
Писать в чем именно Вы не правы, я не буду, так как, повторюсь, это не способствует процессу обучения, а Вы, кажется, не совсем идиот и фанатик, и из Вас еще получится хороший спец :)
>>Ну что ж - слив засчитан :-)
>
>Да уж, Вам. Не знать, что такое raid4 или raid5, это epic
>fail.Вы х зареклись писать сюда?
>Предсказываю: когда подрастете, и начнете, наконец, читать оригинальнульную документацию на английском, а потом дорастете до чтения док вендоров по аппаратным raid-массивам, если вдруг вспомните про эту тему,
Знаете, у вас был шанс понять кое-что, о чем не пишут в документации вендоров по аппаратным RAID-массивам. Вы этим шансом не воспользовались.
>Вам станет мучительно стыдно за свою необразованность, что даже_сейчас_ Вы не понимаете,
>что за дурость Вы в нескольких местах этой темы написали.Я неоднократно просил вас привести примеры моей дурости и необразованности. Вы не смогли, как и не смогли рассказать, что с вашей точки зрения будет делать RAID-массив в достаточно простой ситуации. Чувствуете подвох, но не знаете где он? Так и не узнаете, если не попробуете.
>Я неоднократно просил вас привести примеры моей дурости и необразованности. Вы не
>смогли,Вы учитесь манипулированию фактами у Microsoft и Get The Facts? Имейте ввиду, что на фоне epic fail не всегда получается черное представить красным, а красное зеленым :)
Для Вас: Вы даже не знаете, чем отличается raid5 от raid4
Для остальных _образованных_людей(так как Вы настолько ленивы, что не умеете пользоваться гуглом, а я Вам ссылкой тыкать не буду из принципиальных соображений, уже просто за Ваше недостойное поведение - раньше из нежелания испортить Вам процесс обучения): Он не знает, что такое badstripes, чем raid5 отличается от raid6, и что такое parity блоки.
Может быть, тут найдется кто-то, кто ему расскажет :)
>>Я неоднократно просил вас привести примеры моей дурости и необразованности. Вы не
>>смогли,
>
>Вы учитесь манипулированию фактами у Microsoft и Get The Facts? Имейте ввиду,
>что на фоне epic fail не всегда получается черное представить красным,
>а красное зеленым :)
>
>Для Вас: Вы даже не знаете, чем отличается raid5 от raid4Еще раз - вам показалось. RAID5 и RAID4, состоящие из одинакового количества дисков, используют один диск для четности, остальные для данных, и отличаются по сути только политикой использования дисков - в RAID4 четность всегда на одном диске, в RAID5 четность тоже на одном диске, но в пределах страйпа. В следующих один за другим страйпах диск для хранения четности меняется. Поскольку в примере я предложил рассматривать лишь один страйп, различия между RAID-4 и RAID-5 становятся не важны. Вы же к этому прицепились, напоминая студента-первокурсника, который выучил определения, и решил, что он уже так много знает. Я вам на этот момент уже уазал, вы же продолжаете упорствовать, по непонятной мне причине. Или вы считаете, что в RAID-5 четность чередуется и внутри страйпа?
>Для остальных _образованных_людей(так как Вы настолько ленивы, что не умеете пользоваться гуглом,
>а я Вам ссылкой тыкать не буду из принципиальных соображений, уже
>просто за Ваше недостойное поведение - раньше из нежелания испортить Вам
>процесс обучения): Он не знает, что такое badstripes, чем raid5 отличается
>от raid6, и что такое parity блоки.Повторяю еще раз - вам показалось.
>>Для Вас: Вы даже не знаете, чем отличается raid5 от raid4
>
>Еще раз - вам показалось.Прекратите, пожалуйста, зажигать и быть клоуном, не смешно и надоело :(
Если Вы употребляете много умных слов, это не значит, что Вы понимаете их значение.
Теперь точно больше отвечать в ветку не буду, можете объявлять о сливах и победах дальше, как Вам будет удобно :)
Люди, знающие _основы_ все равно все поймут, а тратить время на Ваше обучение, при злостном нежелании признавания факта того, что Вы _ничего_ не знаете, да еще и, простите, обвинении меня в чем-то, больше не буду.Буду благодарна, когда найдете через несколько лет, когда повзрослоеете, и извинитесь.
Удачи.
>[оверквотинг удален]
>Теперь точно больше отвечать в ветку не буду, можете объявлять о сливах
>и победах дальше, как Вам будет удобно :)
>Люди, знающие _основы_ все равно все поймут, а тратить время на Ваше
>обучение, при злостном нежелании признавания факта того, что Вы _ничего_ не
>знаете, да еще и, простите, обвинении меня в чем-то, больше не
>буду.
>
>Буду благодарна, когда найдете через несколько лет, когда повзрослоеете, и извинитесь.
>
>Удачи.Ну все понятно. Когда аргументов нет, только и остается, что перейти на личности. Вы не устали обсуждать тут мою персону?
Может уже перестанем обсуждать меня, и обсудим таки пример? Я надеюсь, интерес-то есть?
Да у sHaggY_caT что-то свое в голове повернулось, не выходит у вас конструктива. Со стороны видно, что она не предлагает разобрать пример с фактами, а всевремя какие подсказки и намеки делает. Зачем собственно? А взгляд на рейд с т.з. политики размещения страйпов мне понравился и имхо ничему не противоречит.
>Да у sHaggY_caT что-то свое в голове повернулось, не выходит у вас
>конструктива. Со стороны видно, что она не предлагает разобрать пример с
>фактами, а всевремя какие подсказки и намеки делает. Зачем собственно? А
>взгляд на рейд с т.з. политики размещения страйпов мне понравился и
>имхо ничему не противоречит.А речь была об этом (начало мана Maintenance Best Practices for Adaptec RAID Solutions):
Run regular consistency checks on the system:
Verification is designed to proactively detect hard disk media defects while the array is online and
redundant. A RAID-5 or RAID-6 array is inconsistent when the data and parity do not match. Likewise, a
RAID-1 array is inconsistent when the data and mirror do not match.
The verification process issues commands to each drive in the array to test all sectors. When a bad
sector is found, the RAID controller instructs the hard drive to reassign the bad sector, and then
reconstructs the data using the other drives. The affected hard drive then writes data to the newly
assigned good sector. These operations continue so that all sectors of each configured drive are
checked, including hot spares. As a result, bad sectors can be remapped before data loss occurs.Резюме: консистент-чек, в, например, кроне рулит.
И перед этим выше:
Hard drive media defects and other drive quality issues have steadily improved over time, even as drive sizes
have grown substantially. However, hard drives are not expected to be totally free of flaws. In addition, normal
wear on a drive may result in an increase in media defects, or “grown defects,” over time. The data block
containing the defect becomes unusable and must be “remapped” to another location on the drive. If a bad
block is encountered during a normal write operation, the controller marks that block as bad and the block is
added to the “grown defects list” in the drive’s NVRAM. That write operation is not complete until the data is
properly written in a remapped location. When a bad block is encountered during a normal read operation, the
controller will reconstruct the missing data from parity operations and remap the data to the new location. A
condition known as a double fault (“bad stripe”) occurs when a RAID controller encounters a bad block on a
drive in a RAID volume and then encounters an additional bad block on another hard drive in the same data
stripe. This double fault scenario can also occur while rebuilding a degraded array, leaving the controller with
insufficient parity information to reconstruct the data stripe. The end result is a rebuild failure with the loss of
any data in that stripe, assuming the stripe is in the user data area.То есть, можем и восстановить, и отремапить бэд-сектор.
Что касается тонкостей, как это делает raidz, или, например, raid1e, raid5, raid6, это лишь тонкости, и плюсы-минусы конкретных реализаций, не позволяющие отказаться от бэкапа, или мониторинга _работы_ приложений, и лишь добавляющие какие-то единицы к общей стабильности сервиса, но не гарантии сохранности данных.
Что касается моего поведения, повторюсь, оно действительно было недостойным.
Вообще то речь шла о том что имея расхождение в xor сумме невозможно однозначно определить блок в котором ошибка, т.е. если блок прочитался с ошибкой рейд 5(да и 4) не сможет восстановить страйп, это если диск отказался выдать блок тогда мы знаем какого блока просто нет и его можем восстановить. это простая булева логика. (про 6й рейд ещё не знаю как там суммы делаются)
> Вообще то речь шла о том что имея расхождение в xor сумме невозможно однозначно определить блок в котором ошибкаИменно! Как, впрочем, и имея различие в содержимом разных дисков зеркала. Без дополнительной информации определить, какой диск содержит неправильные данные - невозможно.
> т.е. если блок прочитался с ошибкой рейд 5(да и 4) не сможет восстановить страйп, это если диск отказался выдать блок тогда мы знаем какого блока просто нет и его можем восстановить. это простая булева логика.
Строго говоря, в ситуации, когда один диск не вернул данные, мы можем восстановить только некоторое содержимое блока, которое будет давать в результате XOR с остальными 0 (ну или соответствовать другой половине зеркала). Но сказать, правильное это содержимое или нет - нельзя, не привлекая дополнительной информации, разумеется.
> (про 6й рейд ещё не знаю как там суммы делаются)
Там ситуация немножко получше, пока ошибок только одна. Как только их становится две, все сводится к предыдущему случаю.
Но и это еще не все. Профилактическая проверка это, конечно, неплохо, она действительно делает полезное дело, выявляя однократные явные ошибки до того, как произойдет вторая, предотвращая потерю всего тома. Ведь чаще всего именно так и поступают RAID-контроллеры, во всяком случае относительно недорогие, при обнаружении двух явных ошибок в страйпе RAID. Альтернативой является возврат ошибки ввода-вывода при попытке чтения компонента страйпа, содержащего ошибку, но насколько часто так поступают - мне неведомо.
С неявными ошибками - проявляющимися ненулевым результатом XOR содержимого всех дисков страйпа - все еще менее весело. Во-первых, очевидно, что таковая проверка может произойти только при условии, что избыточность еще имеется - если избыточности уже нет, то поздно пить боржоми. Во-вторых, что делать при ее обнаружении? Варианты:
1) считать, что содержимое дисков с данными правильно, и чинить содержимое диска с четностью; при этом, если это действительно было так, то все станет хорошо - содержимое диска с четностью станет правильным. Если неправильным было содержимое какого-либо диска с данными, то в результате действий по этому правилу, мы уничтожим правильное содержимое диска с четностью, которое позволило бы нам вычислить правильное содержимое диска с данными, знай мы о том, какой именно это диск.
2) выбирать диск, содержимое которого считать неправильным, некоторым случайным образом; очевидно, что в этом случае шансы выбрать правильный диск гораздо меньше шансов выбрать неправильный (если речь не идет о зеркале)
3) использовать в качестве критерия дополнительную информацию о дисках типа SMART; понятно, что гарантии того, что в результате будет идентифицирован диск с неправильным содержимым, тоже нет никакой
4) возвращать ошибку при попытке чтения любого из компонентов страйпа
Как поступает конкретный контроллер - одним его разработчикам ведомо, и даже может меняться в зависимости от версии прошивки (если только код прошивки не открыт, но я пока таких не видел). С моей точки зрения самый правильный вариант - четвертый, поскольку в этом случае прекращается дальнейшее распространение ошибки. Но чаще всего имеет место быть первый вариант. Естественно, такая профилактическая проверка возможна только в случае, если еще есть избыточность.
Но и это еще не все. Пусть мы обнаружили рассогласование во время профилактической проверки, и даже выбрали четвертый вариант и стали возвращать ошибку при дальнейших попытках чтения. Но что если перед этим мы много раз читали компоненты этого страйпа? Это означает, что ошибка могла распространиться дальше, причем, в худшем случае, оставаясь незамеченной. Это означает, что она могла попасть в бэкапы, в другие системы, и так далее. Можно ли было это предотвратить? Конечно, можно было бы попробовать, прочитав содержимое остальных компонентов страйпа и выполнив те же действия, что и при профилактической проверке. Но - это бы привело к существенному снижению производительности при отсутствии более-менее твердых гарантий обнаружения ошибки. Делает ли так какой-либо из традиционных аппаратных RAID контроллеров? Я не знаю, но очень сомневаюсь, что такой найдется.
Но и это еще не все. Пусть даже мы не обнаружили рассогласования и все вроде бы хорошо. Рассмотрим пример: пусть A, B, C и D означают содержимое дисков данными данными одного страйпа с первого по четвертый, а P означает содержимое диска с четностью, который будем считать пятым, то есть наш страйп в начале выглядит так: ABCDP. Предположим, мы хотим заменить содержимое второго диска на X, для этого нам придется вычислить новое содержимое для диска с четностью, назовем его Q, и выполнить две операции записи с тем, чтобы наш диск приобрел следующий вид: AXCDQ. Но что если эти операции дисками никогда не выполнятся (в силу, к примеру, одной и той же ошибки в микрокоде)? Наш страйп сохранит свой первоначальный вид, и даже будет без проблем проходить верификацию. Будет ли он при этом содержать правильные данные? Очевидно, что нет.
Также не нужно забывать о том, что современный RAID-контроллер - это довольно сложный программно-аппаратный комплекс, и чем больше возможностей предоставляет его прошивка, тем больше шансов, что в ее код вкрадется ошибка. Плюс разные проблемы к аппаратными компонентами, чаще всего с кэшем и батарейками.
При этом, имея в наличии дополнительную информацию - контрольную сумму всех компонентов страйпа, содержащих данные, вычисленную алгоритмом с более-менее приемлемыми свойствами по обнаружению ошибок, хранящуюся отдельно от страйпа - мы сможем во всех рассмотренных случаях обнаружить ошибку, и дальше, при наличии избыточности выявить ее источник методом перебора вариантов, либо, если избыточности нет или перебор вариантов не дал результата, сможем вернуть ошибку ввода-вывода, предотвращая дальнейшее распространение ошибки в данных.
Естественно, одной контрольной суммы мало - нужен еще и доступ к информации об избыточности и каждому компоненту страйпа в отдельности.
Для зеркала накладные расходы попадают в погрешность измерений, но для RAID4/5/6 накладные расходы становятся ощутимее, поскольку для проверки контрольной суммы нужно прочитать все компоненты страйпа, содержащие данные. Соответственно с точки зрения количества случайных операций чтения такой страйп будет равен самому медленному диску в страйпе, а не сумме IOPs дисков с данными.
Вот RAID-Z именно так и поступает, с той лишь дополнительной разницей, что страйпы в нем не имеют фиксированного размера - каждый логический блок файловой системы рассматривается как полный страйп. Естественно, это делает RAID-Z мало пригодным для нагрузок, где преобладают случайные операции чтения. Этот недостаток может быть нивелирован большими кэшами - либо в ОЗУ, либо на SSD (ReadZilla). Впрочем, на потоковое (в том числе - многопотоковое) чтение это не влияет, так все равно нужно будет читать все компоненты страйпа.
Ну и давно известно, что для зады банных зеркало предпочтительнее RAID5 ;-)
Так и не поняла, ждете Вы от меня ответа, или ответили кому-то еще (так как вела себя в отношении Вас действительно отвратительно, не знаю, что на меня нашло),>[оверквотинг удален]
>Именно! Как, впрочем, и имея различие в содержимом разных дисков зеркала. Без
>дополнительной информации определить, какой диск содержит неправильные данные - невозможно.
>
>> т.е. если блок прочитался с ошибкой рейд 5(да и 4) не сможет восстановить страйп, это если диск отказался выдать блок тогда мы знаем какого блока просто нет и его можем восстановить. это простая булева логика.
>
>Строго говоря, в ситуации, когда один диск не вернул данные, мы можем
>восстановить только некоторое содержимое блока, которое будет давать в результате XOR
>с остальными 0 (ну или соответствовать другой половине зеркала). Но сказать,
>правильное это содержимое или нет - нельзя, не привлекая дополнительной информации,
>разумеется.Любой контроллер, если диски не десктопные, и не пытаются сами обрабатывать ремапы, _знает_ о ремапе, поэтому ситуация i/o ошибки, при чтении данных, должна обрабатываться верно (или вообще выкидыванием диска, или ремапом с помощью контроллера)
Что касается случаев "просто отличаются данные", ну что ж, не повезло. Если Вы еще раз внимательно перечитаете нашу дисскуссию, мой основной тезис был о том, что сквозной контроль четности всего навсего еще одна (или две) девятки к _надежности_ сервиса и его аптайму, не всегда нужные.
Почему это выродилось в поливание друг друга грязью, сперва осторожное, а потом острое, я не понимаю :(>Вот RAID-Z именно так и поступает, с той лишь дополнительной разницей, что
>страйпы в нем не имеют фиксированного размера - каждый логический блок
>файловой системы рассматривается как полный страйп. Естественно, это делает RAID-Z мало
>пригодным для нагрузок, где преобладают случайные операции чтения. Этот недостаток может
>быть нивелирован большими кэшами - либо в ОЗУ, либо на SSD
>(ReadZilla). Впрочем, на потоковое (в том числе - многопотоковое) чтение это
>не влияет, так все равно нужно будет читать все компоненты страйпа.
>
>
>Ну и давно известно, что для зады банных зеркало предпочтительнее RAID5 ;-)... и Часто вообще без файловой системы...
Не для Вас, а для новичков, так как Вы, похоже, это знаете, вполне жизнеспособный _бюджетный_ вариант:
mdraid под lvm vg, а под базу raw device из lv. Бэкапы можно снимать со снапшота из lv
> Так и не поняла, ждете Вы от меня ответа, или ответили кому-то еще (так как вела себя в отношении Вас действительно отвратительно, не знаю, что на меня нашло),Я рад, что здравый смысл все-таки возобладал.
> Любой контроллер, если диски не десктопные, и не пытаются сами обрабатывать ремапы, _знает_ о ремапе, поэтому ситуация i/o ошибки, при чтении данных, должна обрабатываться верно (или вообще выкидыванием диска, или ремапом с помощью контроллера)
Вы тут про явные ошибки говорите. А еще бывают неявные, и чем дальше пухнут диски, уплотняется запись, увеличиваются размеры и усложняется микрокод этих дисков, сокращаются сроки выхода их на рынок, тем неявных ошибок становится больше. И это не только к дискам относится, это относится и к аппаратным RAID-контроллерам тоже. И это не мои измышления, это подтверждается исследованиями. Например, CERN еще в 2007 году исследование специально на эту тему проводил: http://indico.cern.ch/getFile.py/access?contribId=3&sessionI...
>Что касается случаев "просто отличаются данные", ну что ж, не повезло.
Вот так просто - "ну что ж, не повезло"? А как же надежность и все такое прочее?
>Если Вы еще раз внимательно перечитаете нашу дисскуссию, мой основной тезис был о том, что сквозной контроль четности всего навсего еще одна (или две) девятки к _надежности_ сервиса и его аптайму, не всегда нужные.
А как же расширение класса обнаруживаемых ошибок, возможность исправление ошибок при наличии избыточности, возможность предотвращения дальнейшего распространения ошибки? Возможность изоляции источника ошибки, наконец?
Вот посмотрел вверх и вижу:> raid 1 обеспечивает, по возможности, только целостность файловой системы (и то, не до конца)
> raid5/6, за счет контроля четности обеспечивают целостность блоков данных (но не данных самой
> файловой системы)RAID1/5/6 обеспечивал бы целостность, если бы мог гарантировать, что вернет в точности те блоки, которые были записаны ранее, или ошибку. Поскольку это RAID1/5/6 не может гарантировать, то говорить о целостности в применении к RAID5/6 неуместно.
Вот еще:
>Еще одна фича рейд-массивов (в аппаратных, например, такой фичей является батарейка, защищающая кэш, или флэш-память, а так же контроль четности блоков данных, гарантирующих в 5-6-м рейдах восстановление битых блоков данных)
Энергонезависимая память (ака "батарейка") - это не просто "фича", это в RAID5/6 средство борьбы с родовой травмой, известной как Write Hole. Без нее RAID5/6 не может _гарантировать_ корректность своего функционирования в случае внезапного пропадания питания.
Потом, что вы понимаете под надежностью сервиса? Сервис, который оперирует ошибочными данными, выдавая непонятно какие результаты - это надежный сервис или нет? А что, доступ к дискам есть, какие-то данные читаются, записываются, машина работает, процессы выполняются, аптайм не пострадал. Выходит надежный сервис? Или нет?
На мой взгляд, вы путаете доступность блочного устройства с надежностью и доступностью сервиса, это блочное устройство использующее. Действительно, RAID1/5/6 позволяют создать блочное устройство, которое будет защищено от явных ошибок и отказов отдельных дисков, и таким образом увеличить время доступности этого блочного устройства и MTBF. К надежности и доступности сервиса это имеет опосредованное отношение, так как если блочное устройство будет доступно, но база данных, на нем хранящаяся, будет падать, из-за того, что получает назад совсем не то, что записывала, то что будет с надежностью и аптаймом сервиса, построенного сверху этой базы данных?
Конечно, если рассматривать как сервис предоставление блочных устройств для их использования кем-то, то да, улучшенная по сравнению с отдельным диском доступность RAID1/5/6 будет означать улучшенную доступность сервиса, но надежность этого сервиса все равно будет не очень.
Конечно, есть сервисы типа гугла, где нет особой разницы, сколько ошибок в результатах поиска, если этих результатов много. Но это скорее исключение, чем правило, это во-первых, а во-вторых, связанным с этим сервисом задачам типа учета количества показов рекламы надежность уже не по барабану.
> Почему это выродилось в поливание друг друга грязью, сперва осторожное, а потом острое, я не понимаю :(
Вобщем, не обижайтесь, тезисов у вас было много разных, а вот с обоснованием их было не очень. Поэтому все и скатилось туда, куда скатилось. Но, как говорится, кто старое помянет... :-)
>> Так и не поняла, ждете Вы от меня ответа, или ответили кому-то еще (так как вела себя в отношении Вас действительно отвратительно, не знаю, что на меня нашло),
>
>Я рад, что здравый смысл все-таки возобладал.Если я перед Вами извинилась, и признала то, что вела с Вами себя просто по-свински, это не означает, что согласилась с предметом спора.
>> Любой контроллер, если диски не десктопные, и не пытаются сами обрабатывать ремапы, _знает_ о ремапе, поэтому ситуация i/o ошибки, при чтении данных, должна обрабатываться верно (или вообще выкидыванием диска, или ремапом с помощью контроллера)
>
>Вы тут про явные ошибки говорите. А еще бывают неявные, и чем
>дальше пухнут диски, уплотняется запись, увеличиваются размеры и усложняется микрокод этих
>дисков, сокращаются сроки выхода их на рынок, тем неявных ошибок становится
>больше. И это не только к дискам относится, это относится и
>к аппаратным RAID-контроллерам тоже. И это не мои измышления, это подтверждается
>исследованиями. Например, CERN еще в 2007 году исследование специально на эту
>тему проводил: http://indico.cern.ch/getFile.py/access?contribId=3&sessionI...Ну да, еще у NetApp было исследование (о том, что raid5 Must Die, в связи с размером дисков)
>>Что касается случаев "просто отличаются данные", ну что ж, не повезло.
>
>Вот так просто - "ну что ж, не повезло"? А как же
>надежность и все такое прочее?А ее и с ZFS тоже нет, почему см. выше.
>>Если Вы еще раз внимательно перечитаете нашу дисскуссию, мой основной тезис был о том, что сквозной контроль четности всего навсего еще одна (или две) девятки к _надежности_ сервиса и его аптайму, не всегда нужные.
>
>А как же расширение класса обнаруживаемых ошибок, возможность исправление ошибок при наличии
>избыточности, возможность предотвращения дальнейшего распространения ошибки? Возможность изоляции источника ошибки, наконец?В 6-м рейде это есть, есть в ряде случаев и в пятом. Завтра появится что-то кроме ZFS, которое добавит какой-то новый элемент к _стабильности_ сервиса (какую-нибудь гарантию переноса данных от приложения на диск, даже через сеть в точном виде), но все равно полной надежности сервиса достичь не получится.
Не нужно это в больше чем половине задач, особенно если железо не очень хорошее.
>[оверквотинг удален]
>неуместно.
>
>Вот еще:
>
>>Еще одна фича рейд-массивов (в аппаратных, например, такой фичей является батарейка, защищающая кэш, или флэш-память, а так же контроль четности блоков данных, гарантирующих в 5-6-м рейдах восстановление битых блоков данных)
>
>Энергонезависимая память (ака "батарейка") - это не просто "фича", это в RAID5/6
>средство борьбы с родовой травмой, известной как Write Hole. Без нее
>RAID5/6 не может _гарантировать_ корректность своего функционирования в случае внезапного пропадания
>питания.Это фича, как и в ZFS фича сквозной контроль целостности, так как позволяет бороться с "родовой травмой" жестких дисков :)
>Потом, что вы понимаете под надежностью сервиса? Сервис, который оперирует ошибочными данными,
>выдавая непонятно какие результаты - это надежный сервис или нет? А
>что, доступ к дискам есть, какие-то данные читаются, записываются, машина работает,
>процессы выполняются, аптайм не пострадал. Выходит надежный сервис? Или нет?Естественно, это менее нестабильный сервис. Но в ряде случаев даже raid5 выгоднее, чем raid6, см. выше мой пример.
Более того, для ряда задач, особенно SOHO/SMB, это будет _избыточно_ стабильно.
>[оверквотинг удален]
>надежности и доступности сервиса это имеет опосредованное отношение, так как если
>блочное устройство будет доступно, но база данных, на нем хранящаяся, будет
>падать, из-за того, что получает назад совсем не то, что записывала,
>то что будет с надежностью и аптаймом сервиса, построенного сверху этой
>базы данных?
>
>Конечно, если рассматривать как сервис предоставление блочных устройств для их использования кем-то,
>то да, улучшенная по сравнению с отдельным диском доступность RAID1/5/6 будет
>означать улучшенную доступность сервиса, но надежность этого сервиса все равно будет
>не очень."Не очень" для кого? Кроме того, в ряде случаев, raid5/6 (особенно 6) может гарантировать восстановление данных в лабораторных условиях(далеких от реальных), в которых Вы показываете преимущества ZFS, которые и так очевидны, но не так очевидна их полезность кроме некоторых _специальных_ применений.
Еще раз, куда вероятнее, что ошибка произойдет в памяти, или в приложении, или даже в CPU (отказал куллер, отказал мониторинг, пошли ошибки, это гораздо вероятнее, кроме того данные в памяти, и тут может даже и ОС упасть, не говоря о том, что какие-то данные испортятся на диске)
>Конечно, есть сервисы типа гугла, где нет особой разницы, сколько ошибок в
>результатах поиска, если этих результатов много. Но это скорее исключение, чем
>правило, это во-первых, а во-вторых, связанным с этим сервисом задачам типа
>учета количества показов рекламы надежность уже не по барабану.Кто-то для критичных сервисов отменил репликацию БД, и контроль данных средствами приложений?
>> Почему это выродилось в поливание друг друга грязью, сперва осторожное, а потом острое, я не понимаю :(
>
>Вобщем, не обижайтесь, тезисов у вас было много разных, а вот с
>обоснованием их было не очень. Поэтому все и скатилось туда, куда
>скатилось. Но, как говорится, кто старое помянет... :-)--------------------
Еще раз: тут бинарная логика,
- Либо ZFS это _исключительно_ средство хранения данных (для домашней фотоколлекции под эту роль, наверное, подойдет), в которой оно никак не смотрится, если только не используется под backup-сервер, на котором она будет более чем к месту (хотя ленты, особенно под zero-копии, имхо, интереснее) для, например, инкрементов и одной-двух последних zero. Хотя VTL с ZFS на рынке пока особенно не видно, (поправьте, если не права)
- Либо это средство повышения стабильности работы самого сервиса, и тогда улучшенный поиск ошибок, сквозной контроль целостности, и т д, это лишь фичи высокой доступности (чем быстрее мы найдем ошибку, тем быстрее поднимем сервис, тем больше по итогам года у нас будет девяток), но с некоторыми задачами она справляется не очень хорошо (поиск ошибок в работе сервиса лучше получается у специализированного мониторинга, зачем плодить сущности?), а ценность некоторых в большинстве применений сомнительна.
Так же она не очень хорошо смотрится для сервисов с высокими пиковыми нагрузками (по i/o, и, например, временному занятию большей части доступного места)
Если бы все вертелось вокруг необходимости восстановления блоков данных, никто бы на критичных к производительности и доступности сервисах не использовал raid10
--------------------Вы опять начинаете переход на личности, давайте тут и сейчас прекратите, или извинятся, в следующий раз, придется уже Вам :)
>>Я рад, что здравый смысл все-таки возобладал.
>
>Если я перед Вами извинилась, и признала то, что вела с Вами
>себя просто по-свински, это не означает, что согласилась с предметом спора.Я вижу. Я только одного не понимаю - в моем предыдущем ответе ZFS нигде не упомянута (разве что в заголовке), речь идет про RAID и отсутствие в нем контроля целостности, вопреки вашим утверждениям. Вы же упорно возвращаетесь к ZFS, выгодам, нужности/ненужности. Зачем? Контроль целостности есть не только в ZFS, поэтому вполне может рассматриваться самостоятельно. Выгода и нужность/ненужность - вещи субъективные, поэтому чего о них спорить? Вы скажете выгодно, я скажу нет, и каждый будет прав по-своему.
Но это никак не отменит того факта, что RAID1/5/6 гарантирует защиту только от явных ошибок дисков.
Впрочем, в ZFS контроль целостности весьма неплохо реализован, так что можно ее можно использовать, чтобы говорить о контроле целостности не как о некоторой абстрактной "фиче", а как о конкретной реализованной возможности :-)
>А ее и с ZFS тоже нет, почему см. выше.
В том смысле, который в это вкладываете вы - действительно нет. Вот только беда в том, что если доводить все до абсурда, то придется признать, что вычислительной техникой лучше не пользоваться вообще, так как вероятность ошибки всегда существует.
>В 6-м рейде это есть, есть в ряде случаев и в пятом.
Вобщем, я не знаю как еще объяснять, что RAID1/5/6 гарантированно защищают только от явных ошибок дисков. Кое-какие дополнительные проверки там возможны (и соответствующие примеры рассматривались), только вот на практике их не используют, потому что гарантий они не добавляют, а негативное влияние на производительность оказывают.
В случае RAID6 при полной избыточности еще можно пытаться делать перебором поиск диска, содержащего неправильные данные, в случае обнаружения рассогласования содержимого дисков с данными с содержимым дисков с четностью, при условии, что только содержимое только одного диска неправильно, а содержимое всех остальных правильно. Но опять же на практике так никто не делает, насколько мне известно. Во всех остальных случаях - гарантий нет.
>Не нужно это в больше чем половине задач, особенно если железо не
>очень хорошее.Даже если железо не очень хорошее, в результате можно ограничить область распространения ошибки, ограничить область поиска ошибки, что для не очень хорошего железа лишним не будет, в силу того, что в не очень хорошем железе возможности диагностики зачастую тоже далеки от очень хороших.
>Это фича, как и в ZFS фича сквозной контроль целостности, так как
>позволяет бороться с "родовой травмой" жестких дисков :)Ладно, уговорили, только вот почему только "родовой травмой" жестких дисков? Ошибками во всем стеке ввода вывода уж тогда. Ну и в ZFS вы можете этот контроль целостности для своих данных и отключить (и сэкономить какие-то крохи процессорного времени), но для метаданных его отключить нельзя, поэтому гарантиями, предоставляемыми контролем целостности, ZFS для своих метаданных будет продолжать пользоваться. В случае RAID5/6 без батарейки получаются не только тормоза, но и "Write Hole".
>Еще раз, куда вероятнее, что ошибка произойдет в памяти, или в приложении, или даже в CPU (отказал куллер, отказал мониторинг, пошли ошибки, это гораздо вероятнее, кроме того данные в памяти, и тут может даже и ОС упасть
пусть падает - это не страшно, это как раз таки способ ограничения дальнейшего распространения ошибки - аварийно завершить работу, чтобы дать возможность средствам диагностики и/или кластеризации сделать свое дело.
>Кто-то для критичных сервисов отменил репликацию БД, и контроль данных средствами приложений?
Никто, конечно, не отменял. А что если приложение контроль не делает? Ну вот досталось оно вам такое и никуда не денешься? Или реплицировать некуда, бюджет не позволяет? Как то бы уже определиться - все таки он есть или его нет.
Кстати, о бюджете. Аппаратный RAID-контроллер тоже отдельного бюджета требует :-) Ведь нужно купить контроллер, купить поддержку (ну или еще один на всякий случай. А ZFS - доступна и за так.
> Еще раз: тут бинарная логика,
Эх, если бы все было так просто.
> но с некоторыми задачами она справляется не очень хорошо (поиск ошибок в работе сервиса лучше получается у специализированного мониторинга, зачем плодить сущности?)
А кто вам сказал, что ZFS занимается поиском ошибок в работе сервиса? Она занимается своим делом - хранением данных, и либо делает это хорошо, возвращая именно те данные как были сохранены, либо честно признается, что не смогла, сигнализируя об этом приложению, и сообщая об обнаруженной ошибке тому, кто действительно занимается сбором рапортов об ошибках от всех подсистем, а не только от файловой системы, поиском корреляций, постановкой диагноза и принятием необходимых мер. В OpenSolaris'е этим занимается демон fmd, являющейся одним из составных элементов Fault Management Architecture - системы (архитектуры) управления сбоями. Вот только не думаю, что вместе с ZFS Брайан портировал в Линукс и FMA. Да и зачем - если все из OpenSolaris в Линукс портировать, то OpenSolaris ведь получится :-)
Вобщем, мне все ясно. Вам это не нужно, ваши задачи и задачи ваших клиентов этого не требуют, либо вы не видите, где это можно применить, либо сознательно отказываетесь видеть. Вот и славно. Мне - нужно, плюсы я продемонстрировал, минусы тоже. Надеюсь, тот, кому нужно и интересно - тот увидел и сделал выводы.
Ох, сколько от вас пустых разглагольствований. Почитайте лучше это: http://blogs.sun.com/bonwick/ru/category/ZFS>Но это никак не отменит того факта, что RAID1/5/6 гарантирует защиту только
>от явных ошибок дисков.Ага. Когда один/два диска ушли в полный отвал и не отвечают.
Лично у меня есть интерес и свободное время, чтобы проверить насколько работает ZFS под Linux.
Уважаемая, sHaggY_caT, Вы не правы. Еpic fall скорее у Вас чем у Anon Y Mous, который привёл хороший пример ситуации, в которой RAIDN (N, в данном случае не принципиален) не сможет определить сбойный шпиндель.Мне действительно жаль, что уровень тестостерона заставил Вас быть необъективной. Рекомендую подумать над примером Anon Y Mous ещё раз.
>Уважаемая, sHaggY_caT, Вы не правы. Еpic fall скорее у Вас чем у
>Anon Y Mous,Хорошо, я соглашаюсь с мнением большинства, и приношу извинения Anon Y Mous. В моих высказываниях речь была о том, что в ряде случаев raid5/6 может восстановить, при консистент-чеке, сбойный сектор прозрачно.
Что данная идея, как бы она не была реализована в zfs, не является чем-то уникальным.А так же мысль о том, что сквозной контроль целостности в raidz, и сам raidz, как и любой raid, лишь фича высокой доступности, и нужна не на всех задачах, особенно в ущерб производительности по IOPs.
З.Ы. но raid5, перепутанный с raid4, это действительно смешно, и именно это и заставило меня прекратить дисскуссию.
З.З.Ы. перечитала свой текст, действительно вела себя отвратительно, если они принимаются, еще раз приношу свои извинения Anon Y Mous.
>Прошу не обижаться, тема старая, ее уже большинство опеннетовцев не читает,Мне вот абсолютно фиолетово, сколько опеннетовцев ее читает
Лично я вообще не вижу никакой пользы от использования ZFS в Linux.
>Лично я вообще не вижу никакой пользы от использования ZFS в Linux.Ваше право! Продолжайте пользоваться тем, что приносит вам лично пользу.
>Лично я вообще не вижу никакой пользы от использования ZFS в Linux.
>вы наивно полагаете что есть какая-то польза в супер-анонимах. да.
А при чём здесь ники? Ники они такие ники, могут быть весьма разнообразны. Замечено, когда овтетить больше нечего, некоторые начинают придираться к никам.
о, да. ато супераноним как я вижу обосновал не нужность zfs в линуксе. шикарно.
Между прочим, смотрю, тут многие пеняют на Linux Kernel за stable_api_nonsense.txt.Stable API для системы такой сложности, тем более, открытой по исходному коду - это действительно нонсенс. В том же вантузе сейчас наблюдается полнейший бардак с десятками одного и того же API/ABI разных версий, в результате чего его все равно сломали, в частности - DirectX 10/11 - подтверждение тому, что идея стабильных API кончилась признанием ее идиотизмом.
А текст весьма технически грамотный. Stable API нужно держать там, где нет возможности поправить и перекомпилить при изменениях. Поскольку ядро открыто по исходному коду, и мейнтенеры конкретного API обычно сами вносят изменения в драйвера - необходимость в стабильности API отпадает практически полностью.
Сам вот недавно в своей разработке сломал ABI ядра CentOS. А куда деваться, если потребовался срочный бэкпорт патча, затрагивающего структуру skb, из новых ядер.
>в результате чего его все равно сломали, в частности - DirectX 10/11 - подтверждение тому, что идея стабильных API кончилась признанием ее идиотизмомИдиотизм - это когда интерфейс меняется несколько раз за год. А до десятилетнего срока поддержки многим открытым системам следует ещё дорасти.
Это для проприетарщины - идиотизм. А для открытого софта изменение API ничем таким особо не угрожает, нормальная практика.Насчет десятилетнего срока поддержки - как вы думаете, почему провалилась Vista? И почему провалится 7? Потому что там тот самый пресловутый API, к которому все привыкли (и не только DX) переломали начисто. В итоге имеем полуработующий гибрид новой системы и старого софта.
посмотрите на freebsd для сравнения
>как вы думаете, почему провалилась Vista?Потому что 5.1 good enough чтобы сэкономить в период кризиса
>И почему провалится 7?
И почему же провалится 7?
http://www.3dnews.ru/software-news/prodano_100_mln_kopii_win.../>В итоге имеем полуработующий гибрид новой системы и старого софта
Почему-то на прогрессивном и прямом линуксе доступны 3.5 инди поделки в отличие от
>[оверквотинг удален]
>
>>И почему провалится 7?
>
>И почему же провалится 7?
>http://www.3dnews.ru/software-news/prodano_100_mln_kopii_win.../
>
>>В итоге имеем полуработующий гибрид новой системы и старого софта
>
>Почему-то на прогрессивном и прямом линуксе доступны 3.5 инди поделки в отличие
>отО да! Только недавно в сети(по данным интернет-счетчиков) Win7 стало больше, чем WinVista.
Нельзя говорить и о полном провале, но и тех успехов, о которых запевает Microsoft, нет и в помине, куча народа как не уходила с WinXP, так и не собирается уходить, а бизнес Apple уже стоит больше, чем бизнес Microsoft. Успех? Наверное, с точки зрения GetTheFacts, да, головокружительный! Даже не нужно все время врать, меняя значение слов на противоположное (как обычно), достаточно лишь умолчать о _некоторых_ фактах, что бы успех действительно показался головокружительным :)
Вот только WinVista продавалась, почти исключительно, через насилие над ноутбучными вендорами, и очень немногие пользователи продолжали ее использовать, хотя продажи били все рекорды :)
Кто-то даже Виста Бизнес покупал, с правом даунгрейда, представляете, какие продажи? Пиратствующие деятели все равно покупали ноут с Вистой, а легальные пользователи покупали ее _два_ раза(!)
=====================
Что касается нестабильного API в Линухе, честно не понимаю, что в этом плохого. Если он Вам нужен(как многим, в том числе нам на серверах), есть CentOS/RHEL, большинству же, как показывает сравнительная, с другими *nix-like системами, популярность Ubuntu на десктопах, он нафик не нужен, а Вы поете старую песню, оторванную от реальности, и рассказываете страшные сказки, которые не страшные, а наоборот :)
>Что касается нестабильного API в Линухе, честно не понимаю, что в этом
>плохого. Если он Вам нужен(как многим, в том числе нам на
>серверах), есть CentOS/RHEL, большинству же, как показывает сравнительная, с другими *nix-like
>системами, популярность Ubuntu на десктопах, он нафик не нужен, а Вы
>поете старую песню, оторванную от реальности, и рассказываете страшные сказки, которые
>не страшные, а наоборот :)Как что плохого в нестабильном API? Плохо то, что при выходе очередной версии популярного пакета программ приходится адаптировать в существующую инфраструктуру. Зачастую такая адаптация стоит очень больших денег, времени и нервов, не говоря уже о полной/чистовой переустановке операционной системы (это к вопросу обновлений Ubuntu 9.x -> 10.x). Ну и к чему такое приводит? Правильно! :) К Windows-way: если хочешь, чтобы программа работала правильно, переустанови Windows на заново отформатированный винчестер.
>Как что плохого в нестабильном API? Плохо то, что при выходе очередной версии популярного пакета программ приходится адаптировать в существующую инфраструктуру. Зачастую такая адаптация стоит очень больших денег, времени и нервов, не говоря уже о полной/чистовой переустановке операционной системы (это к вопросу обновлений Ubuntu 9.x -> 10.x). Ну и к чему такое приводит? Правильно! :) К Windows-way: если хочешь, чтобы программа работала правильно, переустанови Windows на заново отформатированный винчестер.Чушь. На RHEL-ветках ядер 2.6.9 и 2.6.18 с OVZ-патчами прекрасно работает подавляющая часть ПО и последних дистрибутивов, хотя иногда и возникают проблемы(вроде последних с udev), они всегда решаются.
К чему этот пример про OpenVZ? К тому, что подавляющему большинству user-mode приложений индеферентны изменения в ядре, а для исчезающего количества тех, что вроде VirtualBOX ломаются, можно использовать вот это:
http://en.wikipedia.org/wiki/Dynamic_Kernel_Module_Support
> Stable API для системы такой сложности, тем более, открытой по исходному коду - это действительно нонсенс.Да ладно уж. Почему-то некоторые другие системы имеют стабильный интерфейс для написания драйверов и живут себе.
По-моему так основной смысл этой всей ломки - борьба с проприетарными драйверами. Все остальное = вторично.
>> Stable API для системы такой сложности, тем более, открытой по исходному коду - это действительно нонсенс.
>
>Да ладно уж. Почему-то некоторые другие системы имеют стабильный интерфейс для написания
>драйверов и живут себе.
>
>По-моему так основной смысл этой всей ломки - борьба с проприетарными драйверами.
>Все остальное = вторично.Нет, имхо, дело в другом, два варианта, и оба, имхо, верные:
- Как бы это цинично не звучало, бетатестинг новых новшеств, для production систем (на тех, кого некоторое количество глюков в обмен на постоянную, взрывную революцию, слом одних фич в ущерб других устраивает)Многие домашние пользователи, в том числе и я, получают удовольствие от возможности потрогать будущее :)
Конечно, на серверах такое лучше не использовать, или использовать с очень большими оговорками (хотя не один раз видела и нормально работающие серверы на Fedora, как бы это страшно не звучало)- Скорость развития. Нельзя не видеть того факта, что Linux ощутимо потеснил проприетарные UNIX-ксы, и не секрет, что до недавнего времени, большая часть новых клиентов RH были как раз с HP-UX, AIX, IRIX, Solaris, и тд, все это стало возможно благодаря тому, что появился сравнимый функционал по гораздо меньшей цене за железо, и постоянно появляется новый, не в ущерб развитию, и, при наличии промышленных RHEL/SLE, не в ущерб концепции развития мейнстримного ядра.
Конечно, это сейчас вызовет флейм, но и нельзя не видеть того, что Linux здорово обогнал FreeBSD и другие свободные системы(разве что, за исключением OpenSolaris), тогда как в 90-х ситуация была совсем другой.
Что касается проприетарных драйверов, Linux-ядро(как проект) != проекту GNU, и благодаря Линусу все-таки никто не стремится извести под корень ту же Nvidia, или создать проблемы писателям проприетарных драйверов под те же raid-массивы, и т д(хотя последними проще таки пользоваться не на свежих бубунтах/федорках, а на RHEL/CentOS/SLE/может быть, Debian и Ubuntu LTS), хотя уже давно можно было, как Вы уже сами писали, перейти на GPLv3, которая бы закрыла эту лавочку окончательно.
В результате, _все_ в плюсе, никто не получает негатива, кроме, может быть, конкурентов и фанатиков на форумах, которым успех Linux как серверной платформы не нравится.
>бетатестинг новых новшеств, для _production систем_
>Многие _домашние_ пользователиВам ничего не кажется странным?
>Конечно, это сейчас вызовет флейм
*и в ОЧЕРЕДНОЙ РАЗ производится вброс про freebsd*
>В результате, _все_ в плюсе
Ага. А тем временем Novell ищет покупателя
P.S. Казалось бы, при чём здесь ZFS (давно и успешно портированная в "отсталую" фряху)
>>бетатестинг новых новшеств, для _production систем_
>>Многие _домашние_ пользователи
>
>Вам ничего не кажется странным?Мне это кажется правильным. Linux на десктопе _сейчас_ больше система для IT-ков, а они вполне могут пользоваться напильником. Меня Fedora и тот процент глюков, что в ней есть, вполне устраивают, а десктоп не есть production-сервер: всегда можно воспользоваться другой машиной, или переставить ОС в крайнем случае, достаточно, что бы окружение сохранилось, скопировать хомяк.
>>Конечно, это сейчас вызовет флейм
>
>*и в ОЧЕРЕДНОЙ РАЗ производится вброс про freebsd*Да, согласна, не очень красиво. Надеюсь, он ни к чему не приведет. Тем не менее, я уверена в этом тезисе(в количестве функционала).
Но FreeBSD интересная система, так как Gentoo использовать на серверах извращение (без строгого релиз-цикла)>>В результате, _все_ в плюсе
>
>Ага. А тем временем Novell ищет покупателяВ новостях была информация о том, что они стали интересны для покупателей прежде всего из-за своих Линуксовых успехов. Раньше же не были никому нужны, так как были вендором той самой полуумершей Netware
>P.S. Казалось бы, при чём здесь ZFS (давно и успешно портированная в
>"отсталую" фряху)Если бы при этом еще и центр разработки сместился из OpenSolaris во FreeBSD, можно было бы говорить об инновациях, а так, это заслуга целиком и полностью Sun.
Напротив, уже Linux-овый device-mapper портируют в Опёнка, так кто донор и локомотив развития?
При этом, конечно, в Линуксе куча проблем по сравнению с проприетарными UNIX-платформами, даже в RHEL/SLE, хотя бы с той точки зрения, что разорение RedHat себе вполне можно представить, а вот HP с их HP-UX очень трудно.
Ладно - подождем пару лет
Может к этому моменту допилят ZFS в Linux до того состояния что можно будет использовать
>Ладно - подождем пару лет
>Может к этому моменту допилят ZFS в Linux до того состояния что
>можно будет использоватьЯ думаю, что через год можно будет использовать BTRFS, зачем будет нужна ZFS, по крайней мере на серверах, а не "поменяться" фильмами?
Еще один такой же механизм, существующий сам по себе, в обход device-mapper, как и mdraid?
>>Ладно - подождем пару лет
>>Может к этому моменту допилят ZFS в Linux до того состояния что
>>можно будет использовать
>
>Я думаю, что через год можно будет использовать BTRFS, зачем будет нужна
>ZFS, по крайней мере на серверах, а не "поменяться" фильмами?
>Еще один такой же механизм, существующий сам по себе, в обход device-mapper,
>как и mdraid?Честно говоря все равно как оно там работает - в обход или напрямую.
Если через год можно будет использовать BTRFS - очень хорошо, но я в этом не уверен.
Скорее всего примерное также - пройдет пара лет до более-менее стабильного состояния.
На серверах пока страшно даже ext4 использовать :)
Кстати, ZPL пока что нифига не реализован :-) Так что файловые системы пока создавать нельзя, только тома ;-)