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

именно, только вот ответы твои не попадают ни под один из этих критериев.

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

От меня поступали и примеры и ответы, читай. То, что ты читать не умеешь или просто не в состоянии мы уже видели, но надёжда ещё есть смутная. Хотя... Я скорее предположу, что тебе будет просто лень.

Это потому, что у тебя проблемы с пониманием. Если бы с ними справился, то был бы прогресс, поциент бы задумался, почему zfs реально присутствует лишь в мидрэндже, заметил бы, что сан вообще оттуда практически не вылезает. Подумал бы ещё и понял бы, что предлагаемые технологии и решения как раз находятся в этом сегменте. И всё, дальше пошёл бы на поправку, занимался бы своим ZFS и не мешал бы большим дядям с их большими приборами.

>>я напоминаю, что 142900-09 который тут уже упоминали для решение серьёзной проблемы

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

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

про ZFS и JBOD - любому вменяемому спецу очевидно обалсть применения ZFS

и что сочетанеи его с серьёзными СХД (USP/NSC, DMX/VMX, CX) - сильно избыточно,

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

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

справится со всем этим лучше и непонятно зачем там ещё и CRC добавлять накладные

проверку можно отключать и вообще там не просто вкл/выкл.

дак разговор же за сим был, не?

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

> Не увиливай. P серия это совершенно нормальный ынтерпрайс. Конкретные решения по лпарам принимаются исходя из потребностей.

Увиливаешь здесь ты, прячась за маской капитана очевидности.

Да и сами ресурсы, если ты в теме, не так просто доступны и редко перманентно активированы.

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

>>От меня поступали и примеры и ответы, читай.

примеры это ответ «да» и тесты на форониксе?

КО в треде давно уже застрелился.

Не надо на мне ничего рубить. Сказать-то что хотел?

Это зависит от конкретной ситуации.

> потому что это специализированное железо справится со всем этим лучше и непонятно зачем там ещё и CRC добавлять накладные к 520-байтным секторам и коррекции на канальном уровне в FC.

Что это - слепая вера в непогрешимость специализированного железа? Ты ж вроде ниже пишешь, что маркетинговым клюквам не веришь? Или ты не веришь избирательно?

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

Да, и расскажи-ка, что там за коррекция на канальном уровне в FC. Желательно со ссылками.

Применение ZFS в Unified Storage как раз в строчку и подтверждает нишу этого решения.

Таким образом, NetApp тоже поставляет Entry-level storage, я тебя правильно понял?

Что ещё напрягает в ZFS - непредсказуемость куда и как лягут данные.
Только не надо рекламы как это круто и освобождает админов от работы.

А ты не напрягайся. Зачем тебе контролировать, куда и как лягут данные? Файловые системы не предоставляют средств контроля того, где будет выделен следующий блок, тебя это не напрягает?

Вот для сравнения, чтобы начать решать сложную проблему с VxVM минимально достаточно вывода vxprint и vxdisk.

Надо только предварительно занести денег за сам этот vxvm (про ограниченную бесплатную лицензию в курсе, но мы же про ынтерпрайз здесь). Ну и потом, что ты из их вывода узнаешь? Детали неоправданно сложной конфигурации? Это тебе жизнь упростит? Ну-ну... Знаешь, кто такие мазохисты?

С ZFS пока всё это значительно сложнее.

C ZFS все гораздо проще, ибо она открыта, и есть развитые средства анализа - начиная от банальных *stat и скрпитов для их обработки и заканчивая DTrace.

«ZFS годится для всего» - из их числа.

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

Я ещё вот что подумал. Ведь и лоу-энд тоже так можно прокакать.
Вот сидит, скажем, дядя - админ какого-нибудь V890+DAS, StorEDGE. Сидит, ставит новую соляру. С ZFS.
Никто его (это же лоуэнд, дядя работает за прожиточный минимум) посылать в москау учиться «готовить» зеттабайтину не посылает.
Что будет? Есть, конечно, вероятность того, что дядя энтузиаст, будет лопатить доку, интернеты и пр. И что-то таки сделает. Но небольшая.
Скорее всего будет что-нибудь вроде раскритикованной ранее ситуации, когда на самом-то деле кончится всё печально.
Куда такой дядя пошлёт после этого ZFS? Или, вы думаете, что велика вероятность того, что он покается и после работы будет за свой счёт изучать магию обращения с zfs?

Реалистичнее надо быть, отрываться от теории иногда и видеть, что происходит на практике.

> Не надо на мне ничего рубить. Сказать-то что хотел?

Я уже все сказал, да ты не услышал. Объясни, почему в тестах межделмаш избегает конфигураций, включающих все ресурсы 595-го в один LPAR. Ты ж прочитал столько материалов про него, должее знать. Или опять слабо и будешь переводить тему, запуская фонтан говна?

Это теория. На практике они даже Уже, потому что унификация. Стараются строить всё схожих вешалках, а у санок их не хватает, в отличии от того же ибм и хапэ.

Ну так ты расскажи, зачем же такой страх нагнетать? А вдруг возьму и обделаюсь от ужаса, тебе стыдно не будет?

> Дело не в Симметрикс

Да, дело не в симметрикс, дело в кларион. один хер емсюки. И в моем ответе дело не в том, ведет себя массив как надо или нет, а в том, что zfs_nocacheflush позволяет легко и быстро это проверить.

С ZFS пока всё это значительно сложнее.

C ZFS все гораздо проще, ибо она открыта,

и есть развитые средства анализа - начиная

от банальных *stat и скрпитов для их обработки и заканчивая DTrace.

И ссылку на скрипты которые покажут как разлеглись данные в пуле тоже приведёшь ?

> Ну так ты расскажи, зачем же такой страх нагнетать?

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

А вдруг возьму и обделаюсь от ужаса, тебе стыдно не будет?

Да ты тут уже и так обделался по самые уши

Это банальщина, те же самые внедренцы всяко умеют такие вещи. Вопрос - почему не хотят? Почему всё сводится к тому, что такие массивы не нужны, трата денег и пр?

> И ссылку на скрипты которые покажут как разлеглись данные в пуле тоже приведёшь ?

Что тебе это даст? Если ответишь, скажу как посмотреть, как разлеглись блоки в пуле.

Ну так, сперва ты какую-то фигню несёшь, потом делаешь страшное лицо и таинственно затихаешь в итоге.
Блеск.
LPAR придуманы не для красоты, также как и активация. Это возможность гибко рулить, планировать и не тратить лишнего.
Но вы ведь знаете страшную тайну, да? Как только все ресурсы уходят в одну LPAR шкаф превращается в тыкву! И так до следующей переинициализации машины, да?

> Почему всё сводится к тому, что такие массивы не нужны, трата денег и пр?

Потому что ты это сам себе придумал. Массивы нужны, но это довольно дорогое удовольствие. Или ты с этим тоже спорить будешь?

> Ну так, сперва ты какую-то фигню несёшь, потом делаешь страшное лицо и таинственно затихаешь в итоге.

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

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

Как ты там говоришь.. «маркетинговый шлак». Вопрос был не об этом.

Но вы ведь знаете страшную тайну, да? Как только все ресурсы уходят в одну LPAR шкаф превращается в тыкву! И так до следующей переинициализации машины, да?

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

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

Да какие это оскорбления.. это, к сожалению, правда жизни.

Да, дело не в симметрикс, дело в кларион

слив засчитан, KB emc154421 я уже указывал:
вкратце, вопрос был - вызывает лим fsync сброс кэша в DMX/CX?
ответ был: According to EMC Engineering...не вызывает сброса кэша самих СХД. или у Вас тайное знание Флары?;)

У тебя паранойя и ты видишь то, чего нет.
Это не маркетинговый шлак, это реально работает. На практике работает.
Короче, ты опять пукнул. Я-то думал, чего лицо такое страшное сделал. А вон оно как, газу много было в кишке.

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

скажу как посмотреть, как разлеглись блоки в пуле.

то есть на docs.sun.com этого нет?
а вот для VxVM/VXFS есть готовые инструкции (для SVM тоже, кстати).
без этого для Ыnterpise оно не пригодно.
слив засчитан

И ссылку на скрипты которые покажут как разлеглись данные в пуле тоже приведёшь ?

Что тебе это даст?

Если ответишь, скажу как посмотреть, как разлеглись блоки в пуле.

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

Особенно интересует вариант, когда recordsize поменяли после того, как в zfs уже успели накидать данных или добавили новый диск.


PS: ответе в стиле «смотри исходники» - не канает.

Дядя - админ какого-нибудь V890+DAS, StorEDGE

+1000!
это - жизнь! ну DAS обычно в этом случае - все 6/12 дисков сильверстоуна.

>>слив засчитан, KB emc154421 я уже указывал:
вкратце, вопрос был - вызывает лим fsync сброс кэша в DMX/CX?
ответ был: According to EMC Engineering...не вызывает сброса кэша самих СХД. или у Вас тайное знание Флары?;)

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

>> Да, дело не в симметрикс, дело в кларион

слив засчитан

Можешь считать так, если это потешит твое самолюбие.

KB emc154421 я уже указывал:

Быстро нагуглить ее не получается, не потому ли, что для этого нужен специальный доступ?

вкратце, вопрос был - вызывает лим fsync сброс кэша в DMX/CX?
ответ был: According to EMC Engineering...не вызывает сброса кэша самих СХД.

Только нужно добавить - сейчас. Раньше проблемы были, и требовалось специально отключать. Во всяком случае, в zfs-discuss не раз и не два с такими проблемами приходили.

C ZFS все гораздо проще...развитые средства анализа - начиная от

банальных *stat и скрпитов для их обработки и заканчивая DTrace.

я бы скакзал - анальных stat.
Вы действительно не понимаете или просто придуряетесь (тролите)?
если у Вас проблемы на FS/дисковой подсистеме - каким образом stat/dt вам поможет? Вам надо быстро понять расположение частей раздела и как наиболее просто его починить, vxprint/vxdisk такие сведения предоставляют и есть INFODOC (если на Sun/SPARC), что делать в таком случае с zfs - мне не совсем понятно что делать. Я имею в виду ZFS-8000-72 и т.п. так как «If the damage is in pool metadata that damage prevents the pool from being opened, then you must restore the pool and all its data from backup» меня не устраивает.

> Вот сидит, скажем, дядя - админ какого-нибудь V890+DAS, StorEDGE. Сидит, ставит новую соляру. С ZFS.

Никто его (это же лоуэнд, дядя работает за прожиточный минимум) посылать в москау учиться «готовить» зеттабайтину не посылает.
Что будет? Есть, конечно, вероятность того, что дядя энтузиаст, будет лопатить доку, интернеты и пр. И что-то таки сделает. Но небольшая.
Скорее всего будет что-нибудь вроде раскритикованной ранее ситуации, когда на самом-то деле кончится всё печально.
Куда такой дядя пошлёт после этого ZFS? Или, вы думаете, что велика вероятность того, что он покается и после работы будет за свой счёт изучать магию обращения с zfs?

Это ты с себя автопортрет нарисовал?

Реалистичнее надо быть, отрываться от теории иногда и видеть, что происходит на практике.

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

> Это не маркетинговый шлак, это реально работает. На практике работает.

Ну то есть ты опять ушел от ответа. Что и ожидалось.

>> скажу как посмотреть, как разлеглись блоки в пуле.

то есть на docs.sun.com этого нет?

На docs.sun.com много чего нет.

а вот для VxVM/VXFS есть готовые инструкции (для SVM тоже, кстати).

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

Бэкапы и рапликация рулят.

без этого для Ыnterpise оно не пригодно.

Ну-ну.. Ты еще вспомни давай, что для ZFS fsck нету.

что там за коррекция на канальном уровне в FC. Желательно со ссылками.

http://www.faqs.org/rfcs/rfc3643.html

про Netapp - нарекания на него есть. именно в этом ключе.

Зачем контролировать, куда и как лягут данные?

причину я уже объяснял, кстати, LVM меня этим же расстраивает.

ладно, поиграл и хватит, иди домашнее задание делать, завтра в школу...;)

ZFS...имеет границы области применимости

прогресс!

>> Что тебе это даст?

Если ответишь, скажу как посмотреть, как разлеглись блоки в пуле.

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

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

Особенно интересует вариант, когда recordsize поменяли после того, как в zfs уже успели накидать данных или добавили новый диск.

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

Зачем еще?

PS: ответе в стиле «смотри исходники» - не канает.

Ну зачем же - есть ключик -F (и дополнительно -X) для zpool import и zpool clear, позволяет легко откатиться к предыдущему состоянию в случае нарушения порядка выполнения операций блочным устройством и аварийного завершения работы. Это может произойти не только с простым диском, но и с большим массивом - если он, например, потеряет свой кэш.

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

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

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

Сойдет не в качестве ответа «смотри в исходники»?

Быстро нагуглить ее не получается...нужен специальный доступ?

а никто не обещал что будет легко.

Раньше проблемы были, и требовалось специально отключать

отключать что? я Вам показал что Symmetrix/CX игнорируют SYNCH CACHE CDB и так было по меньешй мере с 2005г. - то бишь времени начала активного продвижения ZFS. То есть проблема опять не в СХД.

> > что там за коррекция на канальном уровне в FC. Желательно со ссылками.

http://www.faqs.org/rfcs/rfc3643.html

Ты слово correction со словом encapsulation не перепутал?

про Netapp - нарекания на него есть. именно в этом ключе.

точно также есть нарекания на EMC - только немного в другом ключе. И они уже друг друга на этот счет не один раз полили со всех сторон :-)

причину я уже объяснял, кстати, LVM меня этим же расстраивает.

А может я не понял и переспрашиваю - сначала это звучало так, что тебе это надо для решения проблем с производительностью, потом - для выковыривания данных. Так для чего тебе это? Хотя на самоа деле ответ не важен, ибо раскладка данных все время меняется (CoW, если ты помнишь).

Сойдет не в качестве ответа «смотри в исходники»?

Т.е. скриптов на не будет ?
А как же *stat, Dtrace и прочие красивые слова упомянутые раньше ?

раз уж переходите на лчиные осокрбления (вторично),
замечу, что IMHO Вы курите слишком много травы (судя по картинке) и от этого у Вас прогрессирующий ФГМ и от этого не можете понять простейших вещей, как-то: отключени cache flush глобально, что может быть нежелательно для root на ZFS и других локальных для сервера FS.
исправить это простыми (по меркам среднего админа) средствами невозможно. Отсюда простой логический вывод у людей - зачем им такое счастье если у них есть нормальные СХД где даже с UFS2 всё и так хорошо при этом всё давно известно как и что чинится, нет проблем с backup, производительность выше и будет ли выигрыш по удобству администрирования - ещё вопрос?

На мой взгляд просто ZFS ещё очень сыра для полноценного применения даже в своей естественной нише.

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

а это уже называется know-how и professional services.

> отключать что? я Вам показал что Symmetrix/CX игнорируют SYNCH CACHE CDB и так было по меньешй мере с 2005г. - то бишь времени начала активного продвижения ZFS.

Окей, даже если это и было так, как ты говоришь, так и запишем - до 2005 года EMC массивов не выпускала и микрокодов не писала.

Тебе показать сообщения об этой проблеме в zfs-discuss после 2005 года или сам справишься?

То есть проблема опять не в СХД.

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

> Т.е. скриптов на не будет ?

А как же *stat, Dtrace и прочие красивые слова упомянутые раньше ?

У тебя действительно вопрос или ты повыпендриваться? Если выпендриваться, то тут и хокума хватает.

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

Впрочем, информация о расположении блоков тебе не особо поможет и при наблюдении системы в динамике, поскольку, опять же, расположение блоков меняется с течением времени.

Если ты упорный и все-таки хочешь посмотреть где лежат блоки, можешь запустить zdb -bbbbbb <poolname> и получишь километры вывода с дампом каждого указателя в пуле. Если пул экспортирован, добавь -e

>> ZFS...имеет границы области применимости

прогресс!

Кто бы говорил. Хокум тут заусирался про то, что ZFS не кластерная система, на что ему не раз было отвечено, что это не недостаток, а особенность системы, делающая невозможной ее применение в тех местах, где, скажем, QFS отлично подойдет. Если ты не понял, то это и есть одна из границ области применимости.

Ты вроде тоже из н-ска, вас с хокумом там что, покусал кто-то?

взабыл добавить

от этого не можете понять простейших вещей, как-то: отключени cache flush глобально, что может быть нежелательно для root на ZFS и других локальных для сервера FS.

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

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

>>Ты правда веришь, что проблем в СХД не бывает?
особенно если не понимаеш о том что такое queue depth там и bb credits со стороны, сами знаете чего.
и что это не тормоза на самом деле, а банальное переполнение очереди. хотя при определенных нагрузках всплывают и тормоза.