LINUX.ORG.RU

Представлена ещё одна реализация ZFS на уровне ядра Linux

 ,


0

0

Компания KQ Infotech представила свой проект портирования файловой системы ZFS на уровень ядра Linux. В отличие от проекта реализуемого по заказу LLNL, данный проект поддерживает ZFS Posix Layer (ZPL). Это значит, что можно работать с файлами с помощью файлового менеджера. Стоит отметь что это уже третий проект связанный с портированием поддержки ZFS в ОС на базе Linux-ядра.

Вот основные возможности проектов:

  • Проект по заказу LLNL поддерживает zpool v.26, портирован на I386 и AMD64, но не поддерживает ZPL
  • Проект компании KQ Infotech поддерживает zpool v.18, поддерживается ZPL, портирован только на AMD64 (будет поддержка Fedora 12, Red Hat Enterprise Linux 6 и Ubuntu 10.04 LTS)
  • Проект ZFS-FUSE поддерживает zpool v.23, поддерживает ZPL, портирован на I386, AMD64, PowerPC и Sparc. Также присутствует в основных репозиториях популярных дистрибутивов — Fedora (начиная с 11-ой версии), Ubuntu 10.04 LTS, Debian Squeeze и т.д.

Также отмечено, что KQ Infotech не будет продвигать патч в основную ветку ядра и выпустит его под лицензией CDDL. Скорее всего модули будут собираться на машине пользователя с помощью DKMS (как это происходит с проприетарными драйверами от ATI/NVidia или FOSS модулем от программы CDEmu)

>>> Подробности

★★★★★

Проверено: mono ()

Ответ на: комментарий от Hokum

Ты что, серьёзно думаешь, что в Новосибирске мало симетров ?


а зачем хамить ?

Лично я знаю как минимум 4 места стоят Symmetrix-ы.
Но по сумме факторов сильно похоже на предбиллинг.

PS: если что, я не тот ананимус с которым был срач выше.

anonymous
()
Ответ на: комментарий от Hokum

> Во-первых, лично я ничего не использую, ынтрепрайз подразумевает наличие персонала в количестве >>1.
Приплыли... А сколько было заявлений, а оказалось...

В остальных случаях «магически» ни одной проблемы действительно не было.

Вот только это не значит, что их нет.

ext3 достаточно простая и хорошо отлаженная в реальных задачах файловая система, в этом её сила.

Да-да, настолько простая, что баги закрываются как can't fix:

Bug 506684 - Corruption on ext3/xfs with O_DIRECT and unaligned user buffers
https://bugzilla.redhat.com/show_bug.cgi?id=506684

Да че там говорить, если даже сброс кэшей дисков по fsync() сделать забыли.

anonymous
()
Ответ на: комментарий от anonymous

Если не тот, то извиняюсь.
К СТК отношения не имеем, а в Новосибирске у нас лишь одна из площадок.

Hokum ☆☆☆☆
()
Ответ на: комментарий от Hokum

> Если вы читать таки умеете, то прочитайте причину этого cantfix

Может быть чето-нибудь сделаем в 5.5? Отличная причина.

anonymous
()
Ответ на: комментарий от Hokum

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

EvgGad_303 ★★★★★
()
Ответ на: комментарий от Hokum

контора, которая по непонятным причинам дала тебе работу, может и занимается тем что ты описал. но твои посты и варианты ответов на заданые вопросы подсказывают, что ты к этому отношение имеешь максимум из-за плеча посмотреть. ынтерпрайз ты наш, с самой пер(е)довой ext3.

EvgGad_303 ★★★★★
()
Ответ на: комментарий от EvgGad_303

Да да, только у тебя настоящий enterprise, он же enterprise без ZFS не возможен :)
Ну, я не буду разрушать твои мечты, тем более, что я давно уже сказал тебе всё, что хотел.

Hokum ☆☆☆☆
()
Ответ на: комментарий от EvgGad_303

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

Hokum ☆☆☆☆
()
Ответ на: комментарий от Hokum

1. при наличии интеллекта можно делать это и не используя хамство.
2. где невежливо?

EvgGad_303 ★★★★★
()
Ответ на: комментарий от Hokum

я не говорил, что только у меня.
я не говорил, что zfs панацея. лишь ты начал кричать - zfs гуано мамонта и ненужно. непонятно только это красные глаза или же просто невежда? или все вместе?

EvgGad_303 ★★★★★
()
Ответ на: комментарий от EvgGad_303

Ещё раз всё то же самое повторять я не буду. Читайте тред, думайте. И прекратите, наконец, лгать.

Hokum ☆☆☆☆
()
Ответ на: комментарий от Hokum

> А так вполне нормальная ситуация, почитайте http://rhn.redhat.com/errata/RHBA-2009-1133.html

Типа пофиксили, а статус у бага менять не стали.. Ну ладно.

В любом случае, это контрпример к твоим словам про суперстабильность и отсутствие проблем в ext3.

И да, тестирование способно доказать наличие ошибок, но не их отсутствие.

anonymous
()
Ответ на: комментарий от anonymous

Тебе дать ссылку на багтрекер ZFS?
Я приводил аргументы, почему ext3 считается стабильной ФС, писал про собственный опыт.
Баги есть везде, про божественность ext3 я не говорил. Я был против обожествления zfs и обсирания всего, что не zfs, только и всего.

Hokum ☆☆☆☆
()
Ответ на: комментарий от Hokum

> Тебе дать ссылку на багтрекер ZFS?

Она у меня есть, не переживай.

Я приводил аргументы, почему ext3 считается стабильной ФС, писал про собственный опыт.

Я тебе привел пример недавнего бага в ext3, связанного с повреждением данных. Надо еще - есть еще. Так что не усирайся тут про какую-то особенную стабильность ext3. Тут если по одному ЛОРу пройти, можно кучу хоррор-сториз обнаружить.

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

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

Баги есть везде, про божественность ext3 я не говорил. Я был против обожествления zfs и обсирания всего, что не zfs, только и всего.

Вот только ты выбрал для этого оригинальный метод - обосрать ZFS, которую ты так и не осилил, и обвинить участников треда в том, что они в треде про ZFS обсуждают ZFS. Ну и обсирал все и вся в этом треде исключительно ты - IQ хвостострела и люми оказался значительно выше.

anonymous
()
Ответ на: комментарий от anonymous

Я тоже приводил ссылку с багом ZFS, приведшем к потере данных. Удивительные открытия, что в софте бывают баги меня не особенно фрустрируют.
Всё одно да потому. Не находятся они в одном положении, и я писал почему.
Что касается остального... Когда дебилы начинают тупить я вынужден им указать, на то, что они дебилы и что они тупят. Так что, жри дальше.

Hokum ☆☆☆☆
()
Ответ на: комментарий от Hokum

> Я тоже приводил ссылку с багом ZFS, приведшем к потере данных.

Никто не спорит. Ошибка устранена? Устранена. Все, проблемы нет.

Удивительные открытия, что в софте бывают баги меня не особенно фрустрируют.

Тебя фрустрирует то, что в треде про ZFS обсуждают ZFS, а не ext3, ага.

Всё одно да потому. Не находятся они в одном положении, и я писал почему.

Где ты писал почему? Делать какие-то абстрактные заявления - ты делал. Но почему - не писал.

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

Уймись уже. Твоя ограниченность уже даже не смешна.

anonymous
()
Ответ на: комментарий от anonymous

Меня фрустрирует то, что некоторые участники и онанисты не в состоянии читать или понимать прочитанное.

Дело не в моей ограниченности, дело в твоих отклонениях.

Hokum ☆☆☆☆
()
Ответ на: комментарий от anonymous

http://developers.sun.com/solaris/docs/wp-oraclezfsconfig-0510_ds_ac2.pdf
гы - там на странице 5 оксюморон в отношении требований к типовым СХД (пассаж про шпиндели и луны), что и требовалось доказать, Хокум прав - ZFS снаружи СХД с этой СХД - несовместим.

mumpster ★★★★★
()
Ответ на: комментарий от EvgGad_303

пре-продакшн тестировании. не так ли

нет. сразу на рабочую, потому что при тестировании всё было хорошо:-)

дисковая подсистема внутренняя или же схд

схд. таки объёмы - тоько на схд. была возможность разные попробовать,
Symmetrix - вообще с zfs несовместим, на cx4 и нашем 25xx при переезде как-то жило, но ufs - лучше.
кстати, хокум не прав, у Oracle есть СХД с ZFS внутри, Unified Storage (7xxx).

mumpster ★★★★★
()
Ответ на: комментарий от iZEN

symmetrix заявлены винчестеры до 181ГБ

о, «спецы» по симметриксам набежали!
почему не 18 гб?

mumpster ★★★★★
()
Ответ на: комментарий от mumpster

Я говорил не про СХД вообще, а про SAN с ZFS. Если там действительно внутри ZFS а не какой-то производный продукт под тем же названием, то странно. Действительно, придётся подучить матчасть, так как мне не совсем ясно зачем внутри SAN-массива полноценная ФС

Hokum ☆☆☆☆
()
Ответ на: комментарий от Hokum

>>Я тоже приводил ссылку с багом ZFS,
приводить-приводил, но понять о чем речь не в состоянии?

This happens all the time if there is no log attache to a zpool. As soon as there is a log attached to a zpool the information is safe.

удивительно как этот «гуру» с 20летним стажем такое допустил. смысл ныть про ненадежность zfs, если отключить основной механизм обеспечения целостности данных. ссзб вобщем.
на solarisinternals об этой «проблеме» уже хз когда писали.

EvgGad_303 ★★★★★
()
Ответ на: комментарий от mumpster

>>нет. сразу на рабочую, потому что при тестировании всё было хорошо:-)
а тестировали тоже с схд?

схд. таки объёмы - тоько на схд. была возможность разные попробовать,

сброс zfs кэша отключали? с этим было огребено не мало проблем с производительностью в свое время =)

EvgGad_303 ★★★★★
()
Ответ на: комментарий от EvgGad_303

Это вы у него спросите. Когда были проблемы с ext4 и барьерами, все же наезжали именно на ФС а не на собственные параметры в fstab

Hokum ☆☆☆☆
()
Ответ на: комментарий от Hokum

Чтение матчасти показало, что чудес не бывает, производительность этого SAN/NAS чуда равна производительности NAS даже в режиме SAN.

Hokum ☆☆☆☆
()
Ответ на: комментарий от EvgGad_303

непойму я

Use whole disks, not disk slices

create as many LUNs as there are physical spindles in the storage

array

так вот, либо весь диск целиком, либо как можно больше лунок - желательно столько же сколько шпинделей - это и есть взаимопротиворечивые утверждения.
вообще, после таких утверждений я не пойму почему Вы спорите с Хокумом -
совершенно чётко видно, что ZFS - нишевая ФС и она явно не для raid-СХД, а для всяких JBOD и внутренних дисков, что жизнь и опыт и подтверждают.
про целостность данных на уровне СХД - можно вспомнить хотя бы тот же CLARiiON с его 520-байтными секторами. кстати, нвоыйц Симметрикс (VMAX) - тоже с такими секторами ;-)
и ещё кстати, ZFS не первая ОС с проверками, из ширкоо известных до неё была OS/400.

mumpster ★★★★★
()
Ответ на: комментарий от EvgGad_303

cache

а тестировали тоже с схд?

естественно, но не с рабочими объёмами и рабочей нагрузкой. и без симметрикса, он у них один. был.;-)

сброс zfs кэша

а бзе кэша - зачем она такая красивая нужна? впрочем я комментарий свой уже написал zfs vs. arrays

mumpster ★★★★★
()

шо

Удивительные люди бывают слов не оберешься. :)

1. С точки зрения POSIX ZFS = любой другой POSIX compatible FS и никаких костылей ни для каких приложений выстраивать не нужно. Все будет работать и переноситься на ЛЮБЫЕ другие POSIX FS

2. ZFS обладает рядом дополнительных возможностей, которыми можно пользоваться, а можно и не пользоваться. Вот эти самые дополнительные возможности и делают данную ФС пока самой продвинутой. Не только с точки зрения надежности хранения, но и с точки зрения удобства управления «томами». Среди наиболее важных: - отсутствие необходимости использования Volume Manager - ZFS способна управлять любым количеством физических устройств, динамически их добавлять или удалять, автоматически подставлять подменные, строить различные уровни избыточности. Если просто - управление пространством осуществляется просто и легко. Одной утилитой. - файловые системы/сетевые распределенные ресурсы/сырые устройства(далее файловая система) - создаются/удаляются/резервируются/изменяются на ходу, без риска и потери производительности, без необходимости физического перемещения данных или переразметки физических носителей. (Грубый пример - у есть 20 дисков или лун - все устройства помещаются в пул - и дальше можно делать все что угодно, не пытаясь заранее угадать сколько и чему нужно места. Потому, что любые изменения размеров файловых систем производятся прозрачно, просто и быстро - это есть основной стандартный функционал ZFS) - на каждую из файловых систем помимо стандартных опций есть дополнительные: использование алгоритмов сжатия на лету, возможность поддержания нескольких копий, дудупликация, резервирование пространства, снапшоты, репликация и т.д. - сквозной контроль целостности данных. Это не просто проверка ЦРЦ со стороны физического устройства или же массива - это реальный подсчет контрольных сумм блоков данных. Такой механизм позволяет избежать скрытых повреждений, когда данные записались на диск неправильно и этот самый диск/массив и ЦРЦ записал неправильно. Рано или поздно такие ошибки приводят к неприятностям, а отследить это средствами физических/блочных устройств нереально, просто потому что они оперируют блоками пришедшими к ним, а не данными/файлами. - транзакционность, гарантирующая консистентность ФС. И выполняющая некоторые другие функции, например группировки небольших блоков данных в большие, что бы избежать лишней фрагментации и повысить производительность. - динамическое изменение размеров блока. Не думаю, что имеет смысл рассказывать что это дает с точки зрения возможностей тюнинга. - возможность размещения логов транзакций и второго уровня кеша чтения на отдельных устройствах. Это называется Hybrid Storage Pool. Если в качестве таких устройств подставить к примеру высокоскоростные SSD-накопители - то скорость отработки операции ввода-вывода увеличится в разы. И все это прозрачно для ЛЮБЫХ приложений. и т.д.

anonymous
()

ШО2

3. ZFS никогда не проектировалась и не позиционировалась, как распределенная файловая система. Не имеет никакого смысла обвинять трактор в том, что он не летает. Он не для этого проектировался. Используйте инструмент по назначению пожалуйста.

4. СХД несовместимых с ZFS быть по-определению не может. ZFS работает с ЛЮБЫМ устройством доступным ОС. Но могут быть рекомендации - как наиболее оптимально работать с теми или иными типами физических носителей.

5. ZFS со всеми своими возможностями применена в линейке СХД Oracle Unified Storage 7000. Там множество протоколов доступа как файловых, так и блочных. И физика там есть разная от GbE до Infiniband. Тот же гибридный пул здесь может применяться для повышения производительности. Работать с подобным устройством крайне легко, поскольку все, что нужно делается на ходу. А чаще всего это изменения размеров презентуемых ресурсов. В большинстве других СХД - такая простая операция вынуждает хост перемонтировать лун и/или пересоздавать ФС, мигрировать данные и т.д.

Говорить о том, что здесь есть на уровне еще более детальном можно долго. Но лучше посмотреть хотя бы ту же вики. А еще лучше взять свои ручки и самому попробовать те вкусности, которые предлагаются. Уверен - после пары тройки часов «ковыряний» у ЛЮБОГО грамотного системного администратора будет четкое представление о том, сколько же лишних действий он совершал с другими локальными ФС и насколько оказывается жизнь проста и удобна. Приблизительно как пересесть с механической коробки передач на автомат и очень удивиться - как же все может быть уютно и прекрасно.

Почему ZFS интересна в отличае от файловых систем прошлого поколения - тем, что у нее в десятки раз больше возможностей при 100% совместимости с POSIX. Если вам ненужны эти возможности - тогда возможно лучше просто промолчать, а не пытаться выглядеть неграмотным лентяем.

Благодарю. И прошу прощения за орфографию. спелчекера нет.

anonymous
()
Ответ на: ШО2 от anonymous

...покупайте наших слонов!

Опять же, к чему это? Всё уже перетёрто по десять раз, хотите начать одиннадцатую итерацию?

Hokum ☆☆☆☆
()
Ответ на: комментарий от Hokum

С Вами, ни в коем случае. Я абсолютно уверен, что вы за 7 минут не в состоянии понять такое количество букв, уж простите.

Не пишите мне больше, потратьте время с пользой.

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

anonymous
()
Ответ на: комментарий от mumpster

дак вот, этот перечень объединяет заголовок

Storage array considerations – Consider the following points when configuring your storage arrays:

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

а бзе кэша - зачем она такая красивая нужна? впрочем я комментарий свой уже написал zfs vs. arrays


зачем загружать системную память, забивать попусту очередь (я про host port queue depth если что), когда для этих целей в схд имеется NVSRAM.
уметь правильно приготовить есть залог успеха =)
а нужна для удобства и чтоб не тратиться на vxvm :p

естественно, но не с рабочими объёмами и рабочей нагрузкой. и без симметрикса, он у них один. был.;-)


я на 90% уверен, что собака порылась именно в cache flush, только отключать это надо надо стороне схд, иначе, в случае чего, рискуете остаться, в лучшем случае, в сингл моде =)

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

EvgGad_303 ★★★★★
()
Ответ на: шо от anonymous

>>Если в качестве таких устройств подставить к примеру высокоскоростные SSD-накопители - то скорость отработки операции ввода-вывода увеличится в разы.

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

EvgGad_303 ★★★★★
()
Ответ на: ШО2 от anonymous

>>Если вам ненужны эти возможности - тогда возможно лучше просто промолчать

+1

EvgGad_303 ★★★★★
()
Ответ на: комментарий от anonymous

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

Hokum ☆☆☆☆
()
Ответ на: комментарий от EvgGad_303

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

Hokum ☆☆☆☆
()
Ответ на: комментарий от Hokum

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

ага, то-то у Cимантека направление «Server and Storage Management» показывает результаты хуже чем планировалось и хотелось. Не знаю, по какому ты там рынку общую практику имеешь ввиду, но в европах и прочих америках есть совершенно четкий тренд - люди экономят бабки и отказываются от новых инсталляций VSF в пользу ZFS.

Ну а то, что ты не сумел приготовить сам или найти рецептов как приготовить в интернете или найти отзывы тех, кто с успехом использует - так это тебе надо гугл-фу тренировать

anonymous
()
Ответ на: комментарий от Hokum

твоя практика нам уже известна, к тому же, по собственному же заявлению, информация о zfs является устаревшей, на примере квот, хотя бы. так что звиняйте - не аргумент.
мы испытываем и разрабатываем решения на зфс уже года 3, и больше года успешно реализуем у клиентов. за это время повидали много разных чудес, но, _как правило_, все решается вдумчивым курением, и местами правкой, инфраструктуры заказчика. конечно, бывают исключения, но я это отметил в одном из первых постов.
а твоя отмазка про исторически сложившийся raid1 для random write вызывает сомнения в знакомстве с ынтерпрайз. изначально спроектировать с учетом специфики приложения и предполагаемого роста никак неполучается?

EvgGad_303 ★★★★★
()
Ответ на: комментарий от Hokum

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

Парниша, так ты такой же маркетолог - втюхиваешь тут ext3 и симметриксы..

anonymous
()
Ответ на: cache от mumpster

>> сброс zfs кэша

а бзе кэша - зачем она такая красивая нужна?

Мумпстер, ты еще в прошлый раз успел продемонстрировать свой уровень познаний. В этот раз продолжаешь. Хоть бы почитал чего, ссылки тебе еще в прошлый раз давали.

Некоторые массивы, в ответ на команду сбросить кэш, действительно начинают это делать. Емсюки этим страдают, а вот Хитачи нет. Поэтому чтобы получить нормальную производительность на Емсюках в качестве бэк-энда, нужно zfs'у установить переменную zfs_nocacheflush в 1. Ну либо настроить массив, так чтобы он ерундой не занимался.

Кэш при этом как работал, так и работает и делает свое дело - как ARC в ZFS, так и кэш массива.

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

впрочем я комментарий свой уже написал zfs vs. arrays

Этот свой комментарий забудь и никому не показывай, и попроси модеров чтобы пост удалили, чтобы не позориться

anonymous
()
Ответ на: комментарий от Hokum

> Чтение матчасти показало, что чудес не бывает, производительность этого SAN/NAS чуда равна производительности NAS даже в режиме SAN.

Какую матчасть читал? Ссылочку не запостишь?

anonymous
()
Ответ на: комментарий от anonymous

>>нужно zfs'у установить переменную zfs_nocacheflush в 1.

лучше на схд, я выше написал чем это чревато, преценденты у клиентов с шаловливыми ручками имеются ))
но если / не zfs, то по барабану.

EvgGad_303 ★★★★★
()
Ответ на: комментарий от Hokum

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

зы но реальную причину знает только он.

EvgGad_303 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.