Найдены уязвимости в Solaris 10 при работе с ZFS

Конечно, в США они могут быть одной компанией, т.к. ихний антимонопольный комитет "дал добро". Но не в Евросоюзе (а возможно, и в ряде других стран). На одной США долго не проживешь.

>Антимонопольный комитет Евросоюза отвергнул сделку Oracle - Sun. Вроде до января 2010 года.

Пруфлинк? Говорили, что они только будут изучать, как сделка скажется на рынке

> важно какой производит теперь и планирует производить в дальнейшем

Они уже "произвели" Unbreakable Linux . Напомнить чем он закончился? А ведь там задача была просто RHEL пересобрать - с этим даже энтузиасты на общественных началах справляются (CentOS), однако ораклы не осилили :-)

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

Умрет железное направление Sun, некоторые фичи из ZFS переедут в Oracle ASM2, в солярис будут втягиваться бэкпорты из опенсоляриса и багфиксинг. ОПЕРАЦИОНКИ ПИСАТЬ НЕ ВЫГОДНО. ЖЕЛЕЗО ПРОИЗВОДИТЬ МЕНЕЕ ВЫГОДНО ЧЕМ ТОРГОВАТЬ "ЛИЦЕНЗИЯМИ".

> Ну да ладно, все равно будет интересно посмотреть, сколько fsck 50 терабайт будет идти...

То, что у тебя в системе нет fsck.zfs означает только то, что его нет, а не то, что он будет работать быстро :-) Хотя возможно, что ты replaying journal путаешь с fsck :-)

> Солярка имела смысл под Спарк, но спарков больше не будет -- Оракл софтовая контора, а не железячная.

Sun тоже софтовая контора - своих производственных линий у него нет. И об этом заявлялось как о преимуществе. Серверы Mx000 - разработака Fujitsu-Siemens. Совместно с Sun.

По поводу ZFS в продакшене - Сан поставляет серверы с предустановленной ОС на ZFS. ZFS сертифициована Ораклом.

Так что еще раз - не нало истерик.

WTF "пачт"?

> А у меня 23 см. И чо?

Чо, девки не дают?

>И zfs, и btrfs кривы и убоги by design. Поэтому R.I.P.

Своего дизайна на суд общественности вы не представили, так чта... Застряли вы, сударь, в 20 веке... Очнитесь, а то так и жизнь мимо пройдет

> Доморощенные админы локалхостов, не понимающие этой очевидной вещи, но любящие хвастаться, у кого толще, идут в лесЪ.

Сдается, сударь, вы и есть тот самый доморощенный админ локалхоста

> Дети, вашей ZFS в продакшене еще нет и еще дооолго не будет. Если уж и меряться пиписьками, то под какой там ФС файловое хранилище CERN (20 PiB ~ 20000 TiB)?

Мсье работает в CERN'е? Если что, там нет единого файлового хранилища на 20PB, а основной носитель - так вообще ленты. А имеющиеся дисковые ресурсы распределены по тысячам узлов. Так что не надо тут. Вы, видимо, их исследование на неявных повреждений данных не читали. Так вот почитайте. Для них одна из основных головных болей - как не потерять данные экспериментов, и количество ошибок и отсутствие средств их обнаружения в используемом софте эту головную боль им нисколько не облегчают.

> ZFS ущербна от рождения, это франкенштейновский монстр, которому пришили 2 головы, пять рук, а вместо ног -- щупальца.

Где вы такую забористую траву берете, а?

>> По количеству строк кернельного кода ZFS сравнима со связкой LVM+ext4 (примерно 87000 строк и то, и другое). XFS сама по себе - без малого 87 тыщ (вместе с LVM получится под 140 тысяч). Есть вопросы?

> Вопрос в том, что функционал LVM и ext4 можно отлаживать по-отдельности, в чем и состоит преимущество. Замахаетесь баги ловить в своем монстре -- что, собственно уже мы и видим. И это только еще вершина айсберга.

Конечно, айсберг целиком можно найти на bugs.opensolaris.org. Только не надо тут про отсутствие багов в линуксе, ладно?

Для тех, кто в танке, поясняю. При сравнимом количестве строк кода в ZFS реализовано гораздо больше функционала. Почему так? Да потому что каждый этот пресловутый уровень вынужден изобретать свои собственные велосипеды, прикручивать сбоку какие-то средства интеграции с другими уровнями, потому что при проектировании никто про это даже не думал. Посмотрите, сколько раз в линуксе в разных частях реализованы битмапы. Не зря отец-основатель говорит, что линукс huge'n'bloated.

Интересно посмотреть, как BTRFS будет с багами справляться. Проекту уже 2 года, а о тестировании еще никто толком и не задумывался. В ZFS же я ztest появился вместе с первым прототипом.

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

Чтоб думать было легче и голова не вскипела, рекомендую почитать вот эту вот заметку на русском языке - http://blogs.sun.com/bonwick/ru/entry/rampant_layering_violation_russian

> То, что у тебя в системе нет fsck.zfs означает только то, что его нет, а не то, что он будет работать быстро :-) Хотя возможно, что ты replaying journal путаешь с fsck :-)

То, что у вас в системе есть fsck.ext4, говорит о том, что journal replaying может быть недостаточно, и таки придется делать fsck. Так что не обманывайте себя.

>Мсье работает в CERN'е? Если что, там нет единого файлового хранилища на 20PB, а основной носитель - так вообще ленты. А имеющиеся дисковые ресурсы распределены по тысячам узлов. Так что не надо тут. Вы, видимо, их исследование на неявных повреждений данных не читали. Так вот почитайте. Для них одна из основных головных болей - как не потерять данные экспериментов, и количество ошибок и отсутствие средств их обнаружения в используемом софте эту головную боль им нисколько не облегчают.

Мсье наверное не понял, то что в CERN'е нет единого файлового хранилища и остальное БЛА-БЛА-БЛА, еще не говорит о том, что там где то крутится zfs. Или мсье работает в CERN'е?

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

Какие средства интеграции вы о чем? Связка LVM+ЧТО ТО ТАМ, будь то RAID или FS самодостаточные еденици, это доказывает то, что к примеру FS спокой живет без LVM'а, LVM без RAID'а, а RAID без FS (по факту).

>Интересно посмотреть, как BTRFS будет с багами справляться. Проекту уже 2 года, а о тестировании еще никто толком и не задумывался. В ZFS же я ztest появился вместе с первым прототипом.

А насрать :-). Разница в том, что вам баги ZFS, как серпом по яйцам, а мне баги BTRFS фиолетово. Прошу заметить, что из тех людей кто действительно юзает linux как продакшен, ни кто не поставит все свое добро на BTRFS или на что то типа ZFS - не кошерно это и идеологически не правильно.

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

ДУМАТЬ НУЖНО МЕНЬШЕ, А СООБРАЖАТЬ БОЛЬШЕ. Огромнейший опыт свидетельствует о том, что задачу нужно разбивать на подзадачи, и если возможно решать их каждую по отдельности. И пока этот принцип отрабатывает на ура, и не только в it.

>Чтоб думать было легче и голова не вскипела, рекомендую почитать вот эту вот заметку на русском языке - http://blogs.sun.com/bonwick/ru/entry/rampant_layering_violation_russian

Все эти математические выкладки говорят лишь о том, что Jeff еще помнит программу 10 класса.

>Так что считай, что я спроектировал связку LVM+FS (любая, по вкусу, возьми, если хочешь ext4 или xfs). Она (связка) -- работает, управляема и как показывает практика, достаточно надежна. Ничем этим пока ZFS не знаменита.

А вот это хрен вам ребята. xfs конечно офигенно надежна, но не всегда гы-гы-гы. Что самое печальное, эта ситуция не меняется последние 5 лет.

2no-dashi

>Они уже "произвели" Unbreakable Linux . Напомнить чем он закончился? А ведь там задача была просто RHEL пересобрать - с этим даже энтузиасты на общественных началах справляются (CentOS), однако ораклы не осилили :-)

А что такое? Не просветишь-ли, что не так к ораклячим линуксом?

> Разница в том, что вам баги ZFS, как серпом по яйцам, а мне баги BTRFS фиолетово.

Достойны повод погреть ЧСВ) Можешь указать кого нибудь конкретно, кому "баги ZFS, как серпом по яйцам"?

> Прошу заметить, что из тех людей кто действительно юзает linux как продакшен, ни кто не поставит все свое добро на BTRFS или на что то типа ZFS - не кошерно это и идеологически не правильно.

Те кто юзает linux в продакшене смотрит в таблицы совместимости и сертификации. А "кошерность" и "идеологическая правильность" - удел красноглазых пионэров.

> Огромнейший опыт свидетельствует о том,

... что любой подход имеет свои плюсы и минусы. Плюсы ZFS очевидны. Минусы - главным образом в нарушении "основополагающих принципов" :)

> Мсье наверное не понял, то что в CERN'е нет единого файлового хранилища и остальное БЛА-БЛА-БЛА, еще не говорит о том, что там где то крутится zfs. Или мсье работает в CERN'е?

А кто-то чтоли утверждал, что там ZFS? Утверждение было что там линуксовая ФС в 20 PB. Я думаю, что чуваки из CERN'а не самоубийцы.

> Какие средства интеграции вы о чем? Связка LVM+ЧТО ТО ТАМ, будь то RAID или FS самодостаточные еденици, это доказывает то, что к примеру FS спокой живет без LVM'а, LVM без RAID'а, а RAID без FS (по факту).

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

> А насрать :-). Разница в том, что вам баги ZFS, как серпом по яйцам, а мне баги BTRFS фиолетово. Прошу заметить, что из тех людей кто действительно юзает linux как продакшен, ни кто не поставит все свое добро на BTRFS или на что то типа ZFS - не кошерно это и идеологически не правильно.

Ну про BTRFS сами разработчики пишут, что она еще ни к чему кроме как побаловаться не готова. А ZFS те кто использует линукс в промышленной эксплуатации поставить не могут по причине отсутствия оного в линуксе.

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

>ДУМАТЬ НУЖНО МЕНЬШЕ, А СООБРАЖАТЬ БОЛЬШЕ. Огромнейший опыт свидетельствует о том, что задачу нужно разбивать на подзадачи, и если возможно решать их каждую по отдельности. И пока этот принцип отрабатывает на ура, и не только в it.

Пример хотите? Знаете поди про такую семиуровневую модель OSI от небезызвестной организации ISO. И про стек протоколов, оной соответствующий, тоже знаете? Тогда почему, скажите, интернетом рулит какой-то TCP/IP, который, мягко выражаясь, не вполне строго этой модели соответствует?

>> Чтоб думать было легче и голова не вскипела, рекомендую почитать вот эту вот заметку на русском языке - http://blogs.sun.com/bonwick/ru/entry/rampant_layering_violation_russian

>Все эти математические выкладки говорят лишь о том, что Jeff еще помнит программу 10 класса.

Если вы увидели там только математически выкладки, то мне вас жаль. Видимо, в голову вы только едите.

>Они уже "произвели" Unbreakable Linux . Напомнить чем он закончился?

я не знаю чем он закончился у вас а у нас OEL используется на ура.

> То, что у вас в системе есть fsck.ext4, говорит о том, что journal replaying может быть недостаточно, и таки придется делать fsck.

Я кажется уже показывал тривиальный контрольный пример, в котором ZFS-ный алгоритм контроля целостности, используемый в этом (как там ваш журнал называется - ZIL?) лажается, так что fsck вам тоже потребуется. Только вот ее у вас нет. Хаха.

Если даже то событие, о котором вы тут талдычите, наступит, то целостность ZFS на диске не пострадает. Так что fsck не понадобится.

Ха-ха. no-dashi опять газифицировал лужу.

>так что fsck вам тоже потребуется. Только вот ее у вас нет. Хаха.

"zpool scrub <имя_пула>", неуч.

> zpool scrub <имя_пула>, неуч

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

> Если даже то событие, о котором вы тут талдычите, наступит, то целостность ZFS на диске не пострадает

Угу, ZFS из астрала достанет те данные, которые она по ошибке перезапишет из-за того, что в одном месте 1.1.1.1 преватились в 2.0.0.2

Бздунишки такие бздунишки...

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

Кажется, тут уже приводились примеры, как LVM+ext3 (или 4? че там было?) благополучно возвращает всякую херню, а ZFS обнаруживает ошибку. Ссылку найти?

Или господин no-dashi будет настаивать, что не обнаруживать вообще это лучше, чем обнаруживать, но с заранее известной вероятностью?

>> Если даже то событие, о котором вы тут талдычите, наступит, то целостность ZFS на диске не пострадает

>Угу, ZFS из астрала достанет те данные, которые она по ошибке перезапишет из-за того, что в одном месте 1.1.1.1 преватились в 2.0.0.2

Никто не говорил про данные. Говорили про fsck и целостность ZFS на диске. Так что думайте прежде чем бздеть :-)

> Говорили про fsck и целостность ZFS на диске.

Пока что единственнй метод проверки целостности ФС, который предложили, это scrub (проверка контрольных сумм). Вы вообще не способны проверить целостность метаданных :-)

> что не обнаруживать вообще это лучше, чем обнаруживать, но с заранее известной вероятностью?

Что лучше - иметь возможность скорректировать ошибки (вызвать fsck) или не иметь такой возможности вообще?

>> Говорили про fsck и целостность ZFS на диске.

> Пока что единственнй метод проверки целостности ФС, который предложили, это scrub (проверка контрольных сумм). Вы вообще не способны проверить целостность метаданных :-)

Целостность состояния структур ZFS на диске обеспечивается тем, что новые данные и метаданные не пишутся поверх старых. Пора бы уж усвоить. А то похоже, это у вас пробелы в подготовке по профильным дисциплинам.

>> что не обнаруживать вообще это лучше, чем обнаруживать, но с заранее известной вероятностью?

> Что лучше - иметь возможность скорректировать ошибки (вызвать fsck) или не иметь такой возможности вообще? И где гарантии, что то, что получится в результате fsck, можно будет назвать файловой системой и использовать дальше? Одна из проблем, кстати, это то, что нужно поддерживать синхронизацию между кернельым кодом и кодом e2fsprogs.

Вы про свои собственные слова давно забыли? Что, fsck из астрала данные возьмет? А с метаданными ничего не будет.

Так что идите дальше fsck'айте свои ext[234]... Сколько времени там 50 ТБ проверяться будут? Процесс вообще когда-нибудь закончится?

>Что лучше - иметь возможность скорректировать ошибки (вызвать fsck) или не иметь такой возможности вообще?

md-raid в Linux не умеет даже обнаруживать ошибки, чтобы их скорректировала fsck файловой системы:
http://www.linux.org.ru/jump-message.jsp?msgid=3262617&cid=3272939
http://www.linux.org.ru/jump-message.jsp?msgid=3262617&cid=3274139
— Linux не то что вообще не имеет возможности автоматической (без ручного вмешательства) корректировать ошибки на массивах RAID, но и обнаруживать их!

> что новые данные и метаданные не пишутся поверх старых

Привет фрагментация. Причем бешеная. Опять таки, этот вопрос уже рассматривался.

юниксойды делятся на две категории. у одних есть ZFS, другие кричат какая она хуёвая

воистину санки поступили гениально - наняли бздунов допиливать а главному конкуренту показали фигу.

> юниксойды делятся на две категории. у одних есть ZFS, другие кричат какая она хуёвая

Юниксоиды делятся на две категории - те, которые юниксоиды, и те у которых есть ZFS и putty.exe для ее администрирования :-)

>Юниксоиды делятся на две категории - те, которые юниксоиды, и те у которых есть ZFS и putty.exe для ее администрирования :-)

Толсто.

(Ни разу не видел и не работал с putty.exe.
Почему её всегда упоминают линуксоеды, когда нечем возразить бздунам, — загадка.
P.S.
Пишу из Windows XP Pro/Firefox 3.5.3)

Твое искреннее удивление "Ни разу не видел и не работал с putty.exe" в сочетании с "Пишу из Windows XP Pro" вызывают у меня искренне умиление - какой маленький зеленый троллик, его так давно никто не кормит, все кому не лень его пинают, и даже на фряху ему приходится через telnet коннектиться :-)

> Опять таки, этот вопрос уже рассматривался.

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

>> юниксойды делятся на две категории. у одних есть ZFS, другие кричат какая она хуёвая

> Юниксоиды делятся на две категории - те, которые юниксоиды, и те у которых есть ZFS и putty.exe для ее администрирования :-)

На этот счет пословица есть: "Видит око, да зуб неймет" :-)

Господин no-dashi так и не дал ответа на вопрос, будет ли он пользоваться BTRFS (если и когда наконец допилят) или ZFS (если она вдруг появится в линуксе) или же будет героически стоять на своем и не пользоваться потому как "комбайн-все-в-одном"?

А если ZFS будет наилучшим возможным решением задачи, будет ли господин no-dashi использовать FreeBSD или OpenSolaris или будет собирать свой велосипед из костылей и подпорок, забив на свой другой принцип?

> md-raid в Linux не умеет даже обнаруживать ошибки
Изень, опять сферические кони?
Если не прибегать к трюкам как по ссылкам (грубая сила), чтобы при передаче файла что-то протухло и железо это не отследило? Я такого лет 10 уже не видел, если не делать намеренно dd, то ошибка выскочит либо по ASC/ASCQ от контроллера или диска. В остальных слуаях - глючит проц или память и ухищрения zfs - мало помогают даже на родной SPARC.

>> md-raid в Linux не умеет даже обнаруживать ошибки >Изень, опять сферические кони? >Если не прибегать к трюкам как по ссылкам (грубая сила), чтобы при передаче файла что-то протухло и железо это не отследило? Я такого лет 10 уже не видел, если не делать намеренно dd, то ошибка выскочит либо по ASC/ASCQ от контроллера или диска. В остальных слуаях - глючит проц или память и ухищрения zfs - мало помогают даже на родной SPARC.

Сударь, если вы этого не видели, это не значит, что этого не существует.

Иногда надо быть CERN'ом, чтобы производитель согласился докопаться до сути: http://indico.cern.ch/getFile.py/access?contribId=3&sessionId=0&resId...

И знаете, пример с 'dd' не такой уж надуманный. Вместо 'dd'может быть 'swap', 'mkfs' или что-нибудь еще.

Так что сферические кони - это про вас, скорее...

Btrfs такие шутки с dd тоже обнаруживает на ура, несмотря на всю свою недопиленность.

>> юниксойды делятся на две категории. у одних есть ZFS, другие кричат какая она хуёвая

>Юниксоиды делятся на две категории - те, которые юниксоиды, и те у которых есть ZFS и putty.exe для ее администрирования :-)

Не расстраивайся, глядишь и на улице линукс наступит праздник:

http://kqinfotech.wordpress.com/2009/10/23/hello-world/

> Вместо 'dd'может быть 'swap', 'mkfs
ну swap-то конечно! особенно если учесть что он может создан хоть перед swapon - его содержимое до этой команды никого не интересует.RTFM!
а про mkfs - отжиг неимоверный, гы-гы - дык это и в zfs приведёт к проблемам, я просто "поражён" с глубины Ваших знаний ;), вот, свежак:
NAME STATE READ WRITE CKSUM
V0LUME UNAVAIL 0 0 0 insufficient replicas
cxt0d0sx UNAVAIL 0 0 0 cannot open
cxt1d0sx ONLINE 0 0 0
cxt2d0sx ONLINE 0 0 0
=>http://www.sun.com/msg/ZFS-8000-D3
;-)

>> Вместо 'dd'может быть 'swap', 'mkfs > ну swap-то конечно! особенно если учесть что он может создан хоть перед swapon - его содержимое до этой команды никого не интересует.RTFM!

Сударь, RTFM - это для вас. Вы определитесь для начала, что вы имеете ввиду, прежде чем хвататься за клавиатуру, а то у вас то 'swapon', то 3 домена в Sun Fire 4800. Потом перечитайте, то что я написал, и подумайте.

В качестве примера того, что может случиться (или не случиться) с ZFS вот вам пример: http://www.linux.org.ru/view-message.jsp?msgid=3262617&page=2#comment-326...

С mkfs повторить или сами справитесь?

> NAME STATE READ WRITE CKSUM > V0LUME UNAVAIL 0 0 0 insufficient replicas > cxt0d0sx UNAVAIL 0 0 0 cannot open > cxt1d0sx ONLINE 0 0 0 > cxt2d0sx ONLINE 0 0 0

Этим-то вы чего сказать хотели?