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 ()

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

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

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

> Вариантов нет, скорости внутреннего sas не хватает уже сейчас, а нагрузка будет расти.

Симетр просто про запас, так как неизвестно, каковы границы этого роста


Так симетр у тебя про запас оказывается и в бою еще ни дня не работал, а ты тут с таким запалом вещаешь про настоящий ынтерпрайз и легендарную надежность, одновременно навешивая на все остальное ярлык «маркетинговый шлак»?

Не перечитал ли ты маркетингового шлака от EMС или IBM, а? Сдается мне, что перечитал.

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

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

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

Ты лучше расскажи, что у тебя болит, так как явно видно, что что-то есть.

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

ненене, дэвид блэйн, ненене
когда разносишь на много мелких lun самое оно получается, и потом на хосте уже собираешь как надо, ессессно не без помощи zfs )
на больших IO часто тупо не хватает шпинделей, и толку с 1тб дисков, когда объем базы в несколько десятков гб, но IOPS 20к, для начала?
главное чтоб host channels хватило, но в симе их вроде 16 или поправьте меня если что, лень искать.

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

> Нигде не беру, читайте тред, это не моя идея - отказаться от posix.

Это ты читай тред, и особенно внимательно вот этот пост:

http://www.linux.org.ru/jump-message.jsp?msgid=5274339&cid=5281031

ну и тот, который ты уже вторые сутки осилить не можешь тоже:

http://www.linux.org.ru/jump-message.jsp?msgid=5274339&cid=5274934

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

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

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

вот тут то и всплывают ваши познания ынтерпрайса ;)

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

>>Не перечитал ли ты маркетингового шлака от EMС или IBM, а? Сдается мне, что перечитал.

емс уж больно этим грешат...
но кто знает что есть hitachi, тихонько смеются в сторонке =)

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

> Что у вас с мозгом?

У меня с мозгом все в порядке, не переживай.

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

Это тоже понятно. Проблема в том, что ты раньше пел про то, что у тебя с ним никаких проблем, а теперь становится понятна причина, и она даже не в том, что тебе плевать на целостность, ведь в ынтерпрайзе же самое главное перформанс, а на остальное насрать. А причина оказывается гораздо проще - ты его еще ни дня не использовал. «А как дысал, как дысал» :-))

Ты лучше расскажи, что у тебя болит, так как явно видно, что что-то есть.

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

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

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

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

>>- файлы мелкие совсем, но в принципе можно менять налету
щито? размер блока записи на лету? я тоже хочу так полетать.
а по теме zfs default block size = 128kb, так чта думайте

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

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

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

> аноним, у тебя проблемы с пониманием, либо с чтением, не знаю. Разбираться не буду

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

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

было бы в порядке - не переживал бы. Но, увы, налицо проблемы.

У меня нет проблем с целостностью. Что ты там выдумываешь - это дело твоё, я тебе сказал как есть.

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

Ты потявкай ещё, потявкай.
Не хочешь читать или думать - иди нах, без тебя будет тише.

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

> Блок 8 кб

То есть у тебя большие файлы с размером записи 8К, а ты, не подумав головой, засунул это дело на ФС с recordsize по умолчанию (128К) и получил результаты всего на 10-15 процентов хуже, чем на UFS?

Да ты просто ССЗБ

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

> У меня нет проблем с целостностью.

Конечно нет. Ты ее не контролируешь, поэтому и не знаешь, есть они у тебя или нет.

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

> Oracle Solaris ZFS. How to Manage Systems with Oracle Solaris ZFS in Oracle Solaris Containers

Oracle, Oracle, Oracle(Oracle). Вот это маразм.

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

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

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

>>размер файлов можно менять.
прямо таки на лету?

Блок 8 кб.

хехе, я как раз про них и думал. подсказку уже дал, думайте.

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

> Oracle, Oracle, Oracle(Oracle). Вот это маразм.

Ну дык зайди на сайт любой крупной конторы - обнаружишь то же самое. У шапки - RedHat, RedHat, Redhat, у межделмаша - IBM, IBM, IBM..

Тебя это до сих пор удивляет?

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

>У шапки - RedHat, RedHat

Зашёл. Да - RHEL, да Red Hat Enterprise Virtualization, но Enterprise virtualization management, JBoss Enterprise Middleware.

Тебя это до сих пор удивляет?

Просто впечатление от старого сайта Sun и нынешнего. Раньше так глаз не резало, сейчас тяжело и неприятно читать НЕ рекламные статьи.

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

Читай, тюнинг проводился. Вероятно, в том числе менялся размер блока, просто не я этим занимался с zfs.

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

Нет там ограничений на размер LUNa. Внутренние ограничения нас не касаются, это дело массива.
Раздел можно сделать любой из разумных.
Остальное не критично.

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

Да, на лету, есть ограничение, система проверяет, можно ли дописывать файл или надо создавать новый.

Hokum ☆☆☆☆ ()

Почетная ветка! Прям битва системных инженеров :) Улучшает настроение адназначна!

ЗЫ Извините не удержался.

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

> Читай, тюнинг проводился.

Читаю, вот прямо здесь:

Вероятно, в том числе менялся размер блока, просто не я этим занимался с zfs.

То есть ты понятия не имеешь, что было или не было сделано, и даже делал это не ты.

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

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

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

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

> Просто впечатление от старого сайта Sun и нынешнего. Раньше так глаз не резало, сейчас тяжело и неприятно читать НЕ рекламные статьи.

Ну шо поделаешь - новая метла по новому метет. Не зацикливайся да и делов..

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

> контролирую, но без сквозняков

Расскажи как, а?

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

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

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

скорее инженеров с маркетологами

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

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

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

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

А что будешь делать, если в момент расчета хэша для манифеста ты прочитаешь уже неправильные данные?

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

> скорее инженеров с линаксоедами

fixed

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

> Не я, так как я не умею, и не имею желание готовить ZFS.

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

Ну предполагай дальше. Только не оперируй своими предположениями и полученными результатами на публике - ты просто смешон.

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

Тогда будут проблемы с эцп, которая передаётся с данными. Хотя, чего в жизни не бывает, те же коллизии.

То же самое, что буду делать в случае падения ZFS.
Рыдать и рвать на себе волосы.
Я уже неоднократно отмечал, что инструмент должен быть адекватен задаче.
У меня нет задач, в которых требовалось бы использовать возможности ZFS. Целостность данных это хорошо, но ZFS их не гарантирует, он лишь снижает риски. Вопрос в том, какой ценой.

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

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

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

>Я уже неоднократно отмечал, что инструмент должен быть адекватен задаче.

КО

У меня нет задач, в которых требовалось бы использовать возможности ZFS.

Ну что за бред. Вы же сами сказали, что

Не я, так как я не умею, и не имею желание готовить ZFS.

Конечно вы не будете использовать то, что не знаете. Опять КО.

Зачем вы спорите? Вы уже показали, что как минимум малоопытны в системных интеграциях - вы взяли малознакомый вам инструмент (ZFS) и начали на нём тестировать какой-то продакшн. И о чудо! Оно тормозит! Ну надо же. С чего бы это? А если б летало и вы внедрили, а инструмент малознаком.. Заказчика для вас - подопотный кролик для роста вашего экпиренса.

Что вы делаете в треде ZFS?

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

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

Анон, ты бредишь. Я ZFS осилить даже не пытался (оно мне не надо), а спросил про супер-POSIX возможности из чистого любопытства.

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

Целостность данных это хорошо, но ZFS их не гарантирует, он лишь снижает риски.

Абзац.

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

ГДЕ, ГДЕ БЛ№%Ь, я говорил про ограничение РАЗМЕРА lun?
извините, не удержался, но эти ваши вопросы из ниоткуда в никуда потихоньку перестают доставлять, а скорее наоборот...

Внутренние ограничения нас не касаются, это дело массива.


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

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

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

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

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

скорее системных экстрасенсов - у меня не работает, но пофиг что я не знаю как и почему, пойду на гуще погадаю Ж)

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

> а спросил про супер-POSIX возможности из чистого любопытства.

под какими веществами ты был, когда увидел что-то про супер-POSIX возможности? Если счас не под веществами, иди перечитай еще раз.

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

>>Да, на лету, есть ограничение, система проверяет, можно ли дописывать файл или надо создавать новый.

buffer overflow
kernel panic

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

> Тогда будут проблемы с эцп, которая передаётся с данными.

А если твой манифест с хэшем повредится или пропадет вообще, что будешь делать? Данные выкинешь или тупо хэш пересчитывать.

То же самое, что буду делать в случае падения ZFS.

Рыдать и рвать на себе волосы.



А еще толдычишь нам тут про правила ынтерпрайза.. Бэкап то забыл сделать, да?

Я уже неоднократно отмечал, что инструмент должен быть адекватен задаче.

У меня нет задач, в которых требовалось бы использовать возможности ZFS.



Тогда что ты делаешь в этом треде? Пришел какашками покидаться? Тогда не обижайся, когда тебя носом в твои собственные какашки тыкают.

Целостность данных это хорошо, но ZFS их не гарантирует, он лишь снижает риски.

Вопрос в том, какой ценой.



Ясно какой- гораздо меньшей, чем цена твоего симметрикса :-)

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