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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: cache

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

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

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

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


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

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

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


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

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

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

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

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

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

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

Re: cache

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

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

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

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

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

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

Hokum ☆☆☆☆ ()
Ответ на: Re: cache от Hokum

Re: cache

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: cache

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

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

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

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

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

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

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

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

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

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

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


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

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


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

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


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

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

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

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

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

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

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

EvgGad_303 ★★★★★ ()
Ответ на: Re: cache от mumpster

Re: cache

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

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

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

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

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

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

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

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

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» меня не устраивает.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

прогресс!

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

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

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


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


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

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


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

Зачем еще?

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


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

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

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

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

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

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

Re: cache

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

EvgGad_303 ★★★★★ ()
Ответ на: Re: cache от mumpster

Re: cache

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

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

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

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

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

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

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

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


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

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

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

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

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

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

прогресс!

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

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

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

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

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


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

EvgGad_303 ★★★★★ ()

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

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

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

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