The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Обновилась версия нативной реализации файловой системы ZFS д..., opennews (?), 15-Июн-12, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


4. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от hypro (?), 15-Июн-12, 10:09 
такое ощущение что oracle слабо финансирует разработку btrfs
Ответить | Правка | Наверх | Cообщить модератору

14. "Обновилась версия нативной реализации файловой системы ZFS д..."  –1 +/
Сообщение от Аноним (-), 15-Июн-12, 12:58 
> такое ощущение что oracle слабо финансирует разработку btrfs

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

Ответить | Правка | Наверх | Cообщить модератору

42. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от volaxyandex.ru (?), 15-Июн-12, 19:00 
> бтр подходит гораздо лучше, так как не имеет некоторых анноящих косяков дизайна ZFS

Пруф?

Ответить | Правка | Наверх | Cообщить модератору

47. "Обновилась версия нативной реализации файловой системы ZFS д..."  –1 +/
Сообщение от BratSinot (?), 15-Июн-12, 19:11 
> Не очень-то и слабо. Под специфически оракловые нужды бтр подходит гораздо лучше,
> так как не имеет некоторых анноящих косяков дизайна ZFS.

Ваш btrfs это один сплошной косяк дизайна.

Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

55. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от Аноним (-), 15-Июн-12, 21:18 
> Ваш btrfs это один сплошной косяк дизайна.

Не больший чем ZFS. По крайней мере обратное надо бы обосновать.

Ответить | Правка | Наверх | Cообщить модератору

90. "Обновилась версия нативной реализации файловой системы ZFS д..."  +1 +/
Сообщение от Аноним (-), 16-Июн-12, 14:27 
> Ваш btrfs это один сплошной косяк дизайна.

По сравнению с ZFS, бтр сдизайнен очень неплохо.

Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

49. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от iav (ok), 15-Июн-12, 19:19 
> Не очень-то и слабо. Под специфически оракловые нужды бтр подходит гораздо лучше,
> так как не имеет некоторых анноящих косяков дизайна ZFS.

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

Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

56. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от Аноним (-), 15-Июн-12, 21:20 
>> Не очень-то и слабо. Под специфически оракловые нужды бтр подходит гораздо лучше,
>> так как не имеет некоторых анноящих косяков дизайна ZFS.
> Любопытно прочитать подробнее, что за косяки, и чем анноящие. Можно ссылочку?

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

Ответить | Правка | Наверх | Cообщить модератору

66. "Обновилась версия нативной реализации файловой системы ZFS д..."  –1 +/
Сообщение от iZEN (ok), 15-Июн-12, 23:46 
>>> Не очень-то и слабо. Под специфически оракловые нужды бтр подходит гораздо лучше,
>>> так как не имеет некоторых анноящих косяков дизайна ZFS.
>> Любопытно прочитать подробнее, что за косяки, и чем анноящие. Можно ссылочку?
> Тормозной он на их базах. Впрочем не только на них. И да,
> сервак БД это не файлсерв, там сабой БД хорошо бы кеш
> отдать. Так что позволить ФС захавать 100500 гигз оперативы чтобы выправить
> ее тормоза немеряным буфером уже не получается. А вот ораклу такой
> расклад как-то не очень нравится. Наверное это и мотивировало их затеять
> ФС которая была бы лучше, в том числе и с их
> базами.

Нет, User294, ты не прав и сам об этом думаешь, но почему-то говоришь обратное.

После ухода основного разработчика Btrfs из Oracle в компанию к Стиву Возняку вряд ли что-либо путное получится из Btrfs, по крайней мере в ближайшее время. Эта ФС так и будет иметь статус экспериментальной (как и многие другие) и послужит памятником нереализованной мощи.

А ZFS тюнится по всем фронтам подо что угодно, под любые задачи, связанные с надёжным (и малонадёжным :) ) хранением данных. На уровне настроек кэшей ARC, L2ARC, на уровне блочного представления (ZVOL), на уровне методов поддержки целостности и верифицируемости реализуется куча стратегий использования. Сильное, но вместе с тем, слабое место ZFS — оперативная память, которой не хватает ВСЕГДА. ;)

Ответить | Правка | Наверх | Cообщить модератору

75. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от Аноним (-), 16-Июн-12, 06:51 
> Нет, User294, ты не прав и сам об этом думаешь, но почему-то говоришь обратное.

А это вообще не я придумал. Это кто-то из гуру (уж не помню кто, извини) анализировал устройство ФС. И ты уж прости, но я тем кто постоянно копается в ФС доверяю больше чем тебе с твоим супер-рэйдом на 6Мб/сек :). Кстати имхо тебе бы не помешал там дефрагер, судя по тому что скорость работы ниже линейной в 10 раз.

> После ухода основного разработчика Btrfs из Oracle в компанию к Стиву Возняку
> вряд ли что-либо путное получится из Btrfs,

А ничего что он заявил что он там будет работать над этой ФС? Собственно человек и род его занятий никуда не делись. А кто именно ему деньги заплатит - на что это влияет? От перемены мест слагаемых сумма не меняется.

> по крайней мере в ближайшее время.

А какое тому логическое обоснование? Ты процитировал факт. Но я не вижу ни единого аргумента почему должно быть так как ты сказал. Кстати говоря, Мавр сделал свое дело и наархитектил. Теперь очередь обычных разработчиков повкалывать. Если бы ты смотрел в логи коммитов - ты бы заметил что процесс идет и весьма недурно. А на новом месте Крис сможет оптимизить ФС под SSD. А у подобных накопителей большое будущее.

> Эта ФС так и будет иметь статус экспериментальной (как
> и многие другие) и послужит памятником нереализованной мощи.

Ну ты мечтай, это не вредно и забавно выглядит со стороны.

> А ZFS тюнится по всем фронтам подо что угодно, под любые задачи,
> связанные с надёжным (и малонадёжным :) ) хранением данных.

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

> На уровне настроек кэшей ARC, L2ARC, на уровне блочного представления (ZVOL), на уровне
> методов поддержки целостности и верифицируемости реализуется куча стратегий использования.

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

> Сильное, но вместе с тем, слабое место ZFS — оперативная память,
> которой не хватает ВСЕГДА. ;)

В базах данных ее не получится отдать ФС т.к. она самой БД нужна под ее кеши. Если и то и другое будет претендовать на кеш - сомнительно что выйдет что-то дельное. И есть риск сделать двойную работу, когда ФС отжурналит и БД отжурналит. И одно неудачно наложится на другое, спровоцировав лишнюю работу. У конкретного сочетания логик ZFS и оракла похоже все прошло по плохому сценарию в этом плане, так что оракл похоже остался недоволен и им надо что-то более подходящее.

Ответить | Правка | Наверх | Cообщить модератору

79. "Обновилась версия нативной реализации файловой системы ZFS д..."  –1 +/
Сообщение от iZEN (ok), 16-Июн-12, 07:48 
>> Нет, User294, ты не прав и сам об этом думаешь, но почему-то говоришь обратное.
> А это вообще не я придумал. Это кто-то из гуру (уж не
> помню кто, извини) анализировал устройство ФС. И ты уж прости, но
> я тем кто постоянно копается в ФС

Героев надо знать в лицо, а не только по имени. Так что не извеняю. :)

> доверяю больше чем тебе
> с твоим супер-рэйдом на 6Мб/сек :). Кстати имхо тебе бы не
> помешал там дефрагер, судя по тому что скорость работы ниже линейной
> в 10 раз.

Пул заполнен на 99%. HDD 2,5" 5400 rpm имеют максимум пропускной способности 55 МБ/с, средняя, соответственно, около 20 МБ/с, а не в 10 раз от 6 МБ/с.

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

Возняку не нужен энтерпрайз по факту. Ему интересна эмбеддовка. Вот в этом направлении и будет развиваться Btrfs, так как кто оплачивает труд, тот и рулит развитием.

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

Когда там появится fsck? Или не нужен? :))

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

Для СУБД по большому счёту не нужна универсальная ФС. Им нужно блочное устройство. ZVOL обеспечивает это, а также включаемые по желанию свойства верифицируемости (checksum) на случай ненадёжных носителей.

>> На уровне настроек кэшей ARC, L2ARC, на уровне блочного представления (ZVOL), на уровне
>> методов поддержки целостности и верифицируемости реализуется куча стратегий использования.
> Что сказать то хотел? То что ты выучил кучу умных слов -
> я понял. Но я не вижу в этом наборе слов признаков
> мыслительного процесса. Маркетинговый буллшит за таковой не считается.

Дык это не маркетинг. Это то, к чему уже привыкли на нормальных системах. А вы ещё в прошлом веке с отдельными менеджерами томов прыгаете, пытаясь сделать из них подобие RAID (относительно недавно внедрена проверка целостности md-зеркала в онлайне).

> У конкретного сочетания логик
> ZFS и оракла похоже все прошло по плохому сценарию в этом
> плане, так что оракл похоже остался недоволен и им надо что-то
> более подходящее.

Факты? Компания Oracle отказалась от ZFS в своих серверах? Btrfs она точно не использует.

Ответить | Правка | Наверх | Cообщить модератору

83. "Обновилась версия нативной реализации файловой системы ZFS д..."  +1 +/
Сообщение от AlexAT (ok), 16-Июн-12, 09:58 
> Когда там появится fsck? Или не нужен? :))

Когда fsck появится в ZFS? (риторический вопрос)

> Дык это не маркетинг. Это то, к чему уже привыкли на нормальных
> системах.

Кто привык? На каких системах? Списочек можно? Я везде вижу только ext'ы пока.

> Факты? Компания Oracle отказалась от ZFS в своих серверах? Btrfs она точно
> не использует.

Компания Oracle продает _основной_ свой продукт (СУБД) под Linux'ами и на ext'ах. Как альтернативу - на солярке и древнющем UFS. Но основное позиционирование, тем не менее, идёт не на солярку. Этого достаточно.

Ответить | Правка | Наверх | Cообщить модератору

125. "Обновилась версия нативной реализации файловой системы ZFS д..."  +1 +/
Сообщение от iZEN (ok), 16-Июн-12, 20:14 
>> Когда там появится fsck? Или не нужен? :))
> Когда fsck появится в ZFS? (риторический вопрос)

Джеф Бонвик дал понять, что fsck в ZFS не нужен из-за факта CoW-природы этой замечательной самоверифицирующейся файловой системой.

scrub с успехом заменяет классический fsck практически во всех случаях, как то: анализ проблем доступа к данным из-за физических особенностей среды хранения (вплоть до точного указания пути к повреждённому файлу), перестройка массива хранения. fsck не обладает важными свойствами, которые есть у scrub: fsck не обеспечивает точную идентификацию восстановленных данных с файлом, в котором они хранились (каталог .lost+found представляет собой сборник восстановленных данных, но не их файлов) — это делает невозможным восстановление из резервной копии именно того, что нужно за короткий промежуток времени.

>> Дык это не маркетинг. Это то, к чему уже привыкли на нормальных
>> системах.
> Кто привык? На каких системах? Списочек можно? Я везде вижу только ext'ы
> пока.

Понимаю — кругом одни Linux'ы. Не надоело? Может пора взлететь и расширить линию горизонта, а? Или "рождённый ползать летать не может" по определению классика тебе ближе по духу?

>> Факты? Компания Oracle отказалась от ZFS в своих серверах? Btrfs она точно
>> не использует.
> Компания Oracle продает _основной_ свой продукт (СУБД) под Linux'ами и на ext'ах.
> Как альтернативу - на солярке и древнющем UFS. Но основное позиционирование,
> тем не менее, идёт не на солярку. Этого достаточно.

В последних версиях промышленной ОС Solaris файловая система UFS поддерживается в статусе "legacy" и практически не используется в продакшене в качестве основной ФС.

Ответить | Правка | Наверх | Cообщить модератору

138. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от AlexAT (ok), 16-Июн-12, 21:24 
> Джеф Бонвик дал понять, что fsck в ZFS не нужен из-за факта
> CoW-природы этой замечательной самоверифицирующейся файловой системой.

ГДЕ, блин, гарантия того, что в коде ZFS нет ошибки, благодаря которой метаданные повредятся ещё в структурах в памяти, и благополучно запишутся с модификацией всех контрольных структур? А потом тупо не прочтутся, или прочтутся не оттуда, потому что FS будет считать, что всё у неё хорошо, и все цепочки "встроенных" проверок проходят? fsck в ext'ах допустим и хорош тем, что использует алгоритмы верификации целостности FS, которые трудно реализовать "на лету" - слишком много ресурсов нужно. И к остальным FS это тоже применимо.

> не обладает важными свойствами, которые есть у scrub: fsck не обеспечивает
> точную идентификацию восстановленных данных с файлом, в котором они хранились (каталог

Когда у вас FS упадёт настолько, что перестанет монтироваться / будет выпадать в кору - вот тогда и вспомните про отсутствие fsck. Счастливчиков в инете уже навалом.

> Понимаю — кругом одни Linux'ы. Не надоело? Может пора взлететь и расширить
> линию горизонта, а?

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

Ответить | Правка | Наверх | Cообщить модератору

142. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от iZEN (ok), 16-Июн-12, 22:40 
>> Джеф Бонвик дал понять, что fsck в ZFS не нужен из-за факта
>> CoW-природы этой замечательной самоверифицирующейся файловой системой.
> ГДЕ, блин, гарантия того, что в коде ZFS нет ошибки, благодаря которой
> метаданные повредятся ещё в структурах в памяти, и благополучно запишутся с
> модификацией всех контрольных структур?

Гарантии даёт господь бог и ZDB, очевидно. :))

> А потом тупо не прочтутся, или прочтутся
> не оттуда, потому что FS будет считать, что всё у неё
> хорошо, и все цепочки "встроенных" проверок проходят?

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

> fsck в ext'ах допустим
> и хорош тем, что использует алгоритмы верификации целостности FS, которые трудно
> реализовать "на лету" - слишком много ресурсов нужно. И к остальным
> FS это тоже применимо.

Что же он такое использует, что трудно реализовать на лету? Вон, в ZFS и Btrfs не побоялись сделать верификацию данных и метаданных на лету. И ничего. Работает с приемлемой скоростью.

>> не обладает важными свойствами, которые есть у scrub: fsck не обеспечивает
>> точную идентификацию восстановленных данных с файлом, в котором они хранились (каталог
> Когда у вас FS упадёт настолько, что перестанет монтироваться / будет выпадать
> в кору - вот тогда и вспомните про отсутствие fsck. Счастливчиков
> в инете уже навалом.

Когда падает CoW-ФС и не монтируется, для восстановления используется одна из последних подтверждённых транзакций CoW, только и всего. Техника письма CoW обладает одной замечательной способностью: не писать туда, где записано ранее, а искать, находить и записывать только на свободное место. Кстати, scrub работает только на смонтированном пуле — это его ключевое отличие от классического fsck для линуксовых ФС.

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

"Неохваченные участки внутри", по-мне так, лучше оставить нубам, в противном случае приходит момент ощущения себя трактором на одной большой помойке. :))

Ответить | Правка | Наверх | Cообщить модератору

145. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от AlexAT (ok), 16-Июн-12, 22:48 
> Гарантии даёт господь бог и ZDB, очевидно. :))

Ну вот видите. Поэтому fsck обязателен. Ибо гарантии - только от всевышнего.

> Для этого есть протоколы верификации. Нет? Если появляются ошибки в непредсказуемых местах

У нас нет ошибок в труднодоступных местах (с)
Если сделать внутри ZFS полные верификации - оно будет лопатить одно чтение вечность. Полные верификации структур FS - это оффлайновый процесс, в онлайне они неприменимы в силу требований к производительности.

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

Зато самый ожидаемый отказ - потерю кеша с RAID-контроллера (села/вышла из строя BBU) оно не переносит вообще. Если интересно - можешь погуглить, как уже говорил, "счастливчиков" полно.

> Что же он такое использует, что трудно реализовать на лету? Вон, в
> ZFS и Btrfs не побоялись сделать верификацию данных и метаданных на
> лету.

Для BTRFS делается оффлайновая чекалка. Онлайновые верификации не полны математически, если их сделать полными - оно будет тормозить.

> Когда падает CoW-ФС и не монтируется, для восстановления используется одна из последних
> подтверждённых транзакций CoW

Которую чем выцепать, при отсутствии fsck? Руками? Повторяю: оно не монтируется. И не импортится. Допустим, уходит в кору при попытке импорта. Ковырять руками - долго и нудно.

> scrub работает только на смонтированном пуле

А пул не монтируется. Вообще. Засада? Засада.

Ответить | Правка | Наверх | Cообщить модератору

156. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от iZEN (ok), 16-Июн-12, 23:09 
>> Гарантии даёт господь бог и ZDB, очевидно. :))
> Ну вот видите. Поэтому fsck обязателен. Ибо гарантии - только от всевышнего.
>> Для этого есть протоколы верификации. Нет? Если появляются ошибки в непредсказуемых местах
> У нас нет ошибок в труднодоступных местах (с)
> Если сделать внутри ZFS полные верификации - оно будет лопатить одно чтение
> вечность. Полные верификации структур FS - это оффлайновый процесс, в онлайне
> они неприменимы в силу требований к производительности.

"если бы да кабы".

>> Пока что ZFS держится бодрячком в самых неожиданных
>> условиях моделирования отказов, которые другие ФС не переживают или переживают с
>> потерями.
> Зато самый ожидаемый отказ - потерю кеша с RAID-контроллера (села/вышла из строя
> BBU) оно не переносит вообще. Если интересно - можешь погуглить, как
> уже говорил, "счастливчиков" полно.

Вот поэтому ZFS не ставят на RAID и не надеются на BBU. Ну сколько об этом можно писать? Oracle официально не рекомендует эксплуатировать ZFS на аппаратных RAID.

>> Что же он такое использует, что трудно реализовать на лету? Вон, в
>> ZFS и Btrfs не побоялись сделать верификацию данных и метаданных на
>> лету.
> Для BTRFS делается оффлайновая чекалка. Онлайновые верификации не полны математически,
> если их сделать полными - оно будет тормозить.

Бонвик расписал всю математику для самоверифицирующихся ФС задолго до появления Btrfs и реализовал её в ZFS. ZFS обладает внутренними механизмами самовосстановления и есть внешний отладчик ZDB. Ей не нужен ещё один (внешний инструмент восстановления) fsck, так как протокол восстановления у ней зашит внутри, работает как в онлайне, так и в оффлайне при монтировании пула. Это доказано на практике ГОДАМИ использования как в экспериментальных целях, так и в промышленных масштабах. Btrfs всё ещё имеет экспериментальный статус и не имеет специализированного отладчика типа ZDB, поэтому для неё необходим инструмент проверки корректности состояния в оффлайне.

>> Когда падает CoW-ФС и не монтируется, для восстановления используется одна из последних
>> подтверждённых транзакций CoW
> Которую чем выцепать, при отсутствии fsck? Руками? Повторяю: оно не монтируется. И
> не импортится. Допустим, уходит в кору при попытке импорта. Ковырять руками
> - долго и нудно.

"zpool import -F poolname" в помощь. Оно либо монтируется, либо не монтируется — третьего не дано. И никакие fsck на убитом пуле ничего не восстановят, так как избыточности нет, данные из астрала fsck выцеплять не умеет.

>> scrub работает только на смонтированном пуле
> А пул не монтируется. Вообще. Засада? Засада.

"zpool import -F poolname". Прикинь, оно работает в некоторых случаях даже на FAULTED-пуле. ;) "Некоторые случаи", конечно, не относятся к сносу бошек у двух из трёх HDD в RAID-Z1 — в последнем случае данным попросту неоткуда взяться.

Ответить | Правка | Наверх | Cообщить модератору

176. "Обновилась версия нативной реализации файловой системы ZFS д..."  +1 +/
Сообщение от AlexAT (ok), 16-Июн-12, 23:52 
> "если бы да кабы".

А если еще раз перечитать - поймёшь.

> Вот поэтому ZFS не ставят на RAID и не надеются на BBU.

Вот поэтому оно идёт в итоге в задницу, ибо хороший SAS-контроллер с большим кешем за счет оптимизации транзакций по шине и переупорядочиванию записей даст производительность, которая софтрейдам не приснится никогда. А если учесть, что софтрейды (и ZFS не исключение) прилично грузят CPU и общую системную шину (особенно зеркала), то вполне очевидно, что приличная доля ресурсов системы в итоге будет сожрана обменом с диском. Hint: для того, чтобы ZFS записать данные на 2 диска в софт-зеркале, нужно передать 2 копии данных по шине. Для того, чтобы записать данные на 2 диска в хард-зеркале, нужно передать 1 копию RAID-контроллеру.

> Бонвик расписал всю математику для самоверифицирующихся ФС задолго до появления Btrfs и
> реализовал её в ZFS. ZFS обладает внутренними механизмами самовосстановления

И они так хороши, что немонтирующийся пул после слёта питания - не редкость (гуглим).

> в онлайне, так и в оффлайне при монтировании пула. Это доказано
> на практике ГОДАМИ использования как в экспериментальных целях, так и в
> промышленных масштабах.

Тю. Кто её реально использует в промышленных масштабах, огласите список.

> "zpool import -F poolname" в помощь. Оно либо монтируется, либо не монтируется

Именно. Кора. В общем, всё понятно, fail.

> "zpool import -F poolname"

Кора, либо отсутствие томов. Диски на месте. Подобных случаев в инете море.

Ответить | Правка | К родителю #156 | Наверх | Cообщить модератору

183. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от iZEN (ok), 17-Июн-12, 00:24 
>> "если бы да кабы".
> А если еще раз перечитать - поймёшь.

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

>> Вот поэтому ZFS не ставят на RAID и не надеются на BBU.
> Вот поэтому оно идёт в итоге в задницу, ибо хороший SAS-контроллер с
> большим кешем за счет оптимизации транзакций по шине и переупорядочиванию записей
> даст производительность, которая софтрейдам не приснится никогда.

Опять "если бы да кабы". ZFS масштабируется на гибридную модель хранения HDD с SSD. В SAS используется только что-то одно: либо HDD, либо SSD — это основная причина низких эксплуатационных свойств аппаратных RAID.

> А если учесть, что софтрейды (и ZFS не исключение) прилично грузят CPU

Не говори того, чего сам не знаешь — ZFS не грузит CPU на дефолтных настройках. Алгоритм fletcher4 для 128k блоков практически нетребователен к ресурсам CPU.

Классические софтрейды тоже не CPU-зависимы, так как у них нет контрольных сумм для полос, которые верифицируются на лету в обычном режиме эксплуатации. Впрочем, в md-mirror такая фича недавно появилась и доступна опция верификации данных с обоих половинок зеркала в онлайне, но не сравнивал — не знаю как на скорости и на нагрузке на CPU это отражается.

> и общую системную
> шину (особенно зеркала), то вполне очевидно, что приличная доля ресурсов системы
> в итоге будет сожрана обменом с диском. Hint: для того, чтобы
> ZFS записать данные на 2 диска в софт-зеркале, нужно передать 2
> копии данных по шине. Для того, чтобы записать данные на 2
> диска в хард-зеркале, нужно передать 1 копию RAID-контроллеру.

Поэтому для ZFS рекомендуют делать по одному LUN'у на шпиндель — так разгружается аппаратная часть и оптимизируются потоки I/O.

>> Бонвик расписал всю математику для самоверифицирующихся ФС задолго до появления Btrfs и
>> реализовал её в ZFS. ZFS обладает внутренними механизмами самовосстановления
> И они так хороши, что немонтирующийся пул после слёта питания - не
> редкость (гуглим).

Не гуглим, а приводи точные ссылки на воркароунд. Ссылок нет — трепло.

Ссылка самовосстановления пула после отключения/слёта питания в этой теме: http://forum.ixbt.com/topic.cgi?id=11:43718

>> в онлайне, так и в оффлайне при монтировании пула. Это доказано
>> на практике ГОДАМИ использования как в экспериментальных целях, так и в
>> промышленных масштабах.
> Тю. Кто её реально использует в промышленных масштабах, огласите список.

Sun использовала ZFS в мобильных BlackBox-контейнерах. Об этом ещё Шварц распространялся.
ZFS — основная файловая система в современных версиях Oracle Solaris.

>> "zpool import -F poolname" в помощь. Оно либо монтируется, либо не монтируется
> Именно. Кора. В общем, всё понятно, fail.

"Кора" на какой версии пула? "-F" отрабатывает только в ZFSv28 (стала готова для эксплуатации ровно год назад), остальное — "недообновление" и ССЗБ.

>> "zpool import -F poolname"
> Кора, либо отсутствие томов. Диски на месте. Подобных случаев в инете море.

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

Ответить | Правка | К родителю #176 | Наверх | Cообщить модератору

185. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от AlexAT (ok), 17-Июн-12, 00:38 
> Поэтому для ZFS рекомендуют делать по одному LUN'у на шпиндель — так
> разгружается аппаратная часть и оптимизируются потоки I/O.

Если бы вы хоть чуть-чуть понимали аппаратуру - то не написали бы такой глупости. Доставка данных до LUN'а осуществляется по общим шинам, будь то процессорная или PCI-Express, или что еще. Ну да хрен с ней, с процессорной шиной, но вот городить по отдельному контроллеру на каждый шпиндель - как-то слегка накладно. И - да, не забываем, что пересылка данных на каждый шпиндель занимает еще шину памяти, угу.

> Не гуглим, а приводи точные ссылки на воркароунд. Ссылок нет — трепло.

Гугли.
http://kerneltrap.org/mailarchive/freebsd-fs/2010/12/18/6885731
http://freebsd.1045724.n5.nabble.com/ZFS-failed-after-hard-p... - тут автор отлечился, но через задницу
http://permalink.gmane.org/gmane.os.freebsd.devel.file-syste...
http://mail.opensolaris.org/pipermail/zfs-discuss/2009-March...
http://www.lissyara.su/articles/freebsd/file_system/zfs_reco.../ - кора после повреждения данных, fsck бы спас
http://lists.freebsd.org/pipermail/freebsd-questions/2010-Ma... - висяки
http://mail.opensolaris.org/pipermail/zfs-discuss/2011-Novem... - нелечащиеся грабли
и так далее. учитывая нераспространенность FS, уже серьезно

>[оверквотинг удален]
> Sun использовала ZFS в мобильных BlackBox-контейнерах. Об этом ещё Шварц распространялся.
> ZFS — основная файловая система в современных версиях Oracle Solaris.
>>> "zpool import -F poolname" в помощь. Оно либо монтируется, либо не монтируется
>> Именно. Кора. В общем, всё понятно, fail.
> "Кора" на какой версии пула? "-F" отрабатывает только в ZFSv28 (стала готова
> для эксплуатации ровно год назад), остальное — "недообновление" и ССЗБ.
>>> "zpool import -F poolname"
>> Кора, либо отсутствие томов. Диски на месте. Подобных случаев в инете море.
> Хотя бы одну ссылочку привести не затруднит? А то у меня другие
> данные по монтированию современных Z-пулов, весьма благоприятные.

Ответить | Правка | К родителю #183 | Наверх | Cообщить модератору

187. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от iZEN (ok), 17-Июн-12, 01:01 
>[оверквотинг удален]
>> разгружается аппаратная часть и оптимизируются потоки I/O.
> Если бы вы хоть чуть-чуть понимали аппаратуру - то не написали бы
> такой глупости. Доставка данных до LUN'а осуществляется по общим шинам, будь
> то процессорная или PCI-Express, или что еще. Ну да хрен с
> ней, с процессорной шиной, но вот городить по отдельному контроллеру на
> каждый шпиндель - как-то слегка накладно. И - да, не забываем,
> что пересылка данных на каждый шпиндель занимает еще шину памяти, угу.
>> Не гуглим, а приводи точные ссылки на воркароунд. Ссылок нет — трепло.
> Гугли.
> http://kerneltrap.org/mailarchive/freebsd-fs/2010/12/18/6885731

2010 год...

> http://freebsd.1045724.n5.nabble.com/ZFS-failed-after-hard-p...
> - тут автор отлечился, но через задницу

FreeBSD 8.1-STABLE.

> http://permalink.gmane.org/gmane.os.freebsd.devel.file-syste...

"I was able to boot to Fixit console from 8.2 LiveFS, prepare it for ZFS and mount the pool using "zpool import -Ff" command."

Почему я не удивлён?

> http://mail.opensolaris.org/pipermail/zfs-discuss/2009-March...

2009 год...

> http://www.lissyara.su/articles/freebsd/file_system/zfs_reco.../ - кора после повреждения данных

"размещено: 2011-02-04" — до появления ключа "-F" в команде монтирования FAULTED-пула. Опять мимо.

>, fsck бы спас

Не.
Вот "zpool import -F poolname" на ZFS спасает пул от окончательного разрушения, а "zpool scrub poolname" верифицирует и восстанавливает (если возможно) метаданные и данные, указывает полный список повреждённых файлов, которые подлежат восстановлению из архивных копий. А fsck в таком случае обычно всё портит и перемещает цепочки найденных байт в ничего незначащие файлы внутри каталога .lost+found. Оно нам надо? Для ZFS топорный fsck — точно нет, так как есть встроенные механизмы восстановления метаданных, и ещё есть более тонкий инструмент — ZDB.

> http://lists.freebsd.org/pipermail/freebsd-questions/2010-Ma... - висяки

2010 год.

> http://mail.opensolaris.org/pipermail/zfs-discuss/2011-Novem... -
> нелечащиеся грабли
> и так далее. учитывая нераспространенность FS, уже серьезно

"Нелечащиеся грабли" на ОДНОШПИНДЕЛЬНОЙ конфигурации пула (диск ST3808110AS, кстати), в которой в принципе отсутствует информация по избыточности для восстановления? :)) Ты это серьёзно?


Вот моя новость: https://www.opennet.ru/opennews/art.shtml?num=30797

Ответить | Правка | К родителю #185 | Наверх | Cообщить модератору

197. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от AlexAT (ok), 17-Июн-12, 09:04 
Какой бы год ни был - шанс вылезания данных проблем всё равно велик. Дело в том, что это юзают в основном энтузиасты, они и пишут. Пользователи солярки долбят саппорт оракла, в открытых форумах только 2-3 ситуации. Остальным по барабану.
Ответить | Правка | К родителю #187 | Наверх | Cообщить модератору

147. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от Аноним (-), 16-Июн-12, 22:51 
> Героев надо знать в лицо, а не только по имени. Так что

Я не сотворяю кумиров, но вполне себе наматываю на ус умные мысли.

> не извеняю. :)

Герой-аналитик, мля. Облажаться в слове "извините" - это сильно.

>> помешал там дефрагер, судя по тому что скорость работы ниже линейной в 10 раз.
> Пул заполнен на 99%.

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

> HDD 2,5" 5400 rpm имеют максимум пропускной способности 55 МБ/с,

Давай ты мне не будешь про них рассказывать, у меня вот под рукой пачка лежит. В среднем они свои 40-55 метров в секунду на линейном чтении отдают. Типично при линейном чтении можно ожидать около 50Мб/сек с диска.

> средняя, соответственно, около 20 МБ/с, а не в 10 раз от 6 МБ/с.

По моим наблюдениям, средняя там скорее мегов 40-50 в секунду получается. Больше на внешних треках, меньше на внутренних. А ты просто буратина, который загнал ФС в полную опу. Такое и дефрагер бы пару суток разгребал, если б он у тебя был, конечно. У тебя получилось много мелких фрагментов. Ну вот и скорость чтения далека от линейной. На томе мелкая лапша в не данные.

> Возняку не нужен энтерпрайз по факту. Ему интересна эмбеддовка. Вот в этом
> направлении и будет развиваться Btrfs, так как кто оплачивает труд, тот
> и рулит развитием.

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

> Когда там появится fsck? Или не нужен? :))

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

>> Есть риск делать дважды одно и то же, если не сложилось и алгоритмы неудачно наложились друг на друга.
> Для СУБД по большому счёту не нужна универсальная ФС. Им нужно блочное устройство.

Теоретически - да. Практически - админить удобно все-таки файловую систему а не просто блочные устройства.

> ZVOL обеспечивает это, а также включаемые по желанию свойства верифицируемости
> (checksum) на случай ненадёжных носителей.

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

> Дык это не маркетинг. Это то, к чему уже привыкли на нормальных системах.

Я так смотрю, ты привык и к скорости 6Мб/сек :)

> А вы ещё в прошлом веке с отдельными менеджерами томов прыгаете,

Слишком жирный наброс. Попробуй еще разок.

> Факты? Компания Oracle отказалась от ZFS в своих серверах? Btrfs она точно не использует.

Они в unbreakable Linux его уже внедряют, если уж мы тут о фактах :)

Ответить | Правка | К родителю #79 | Наверх | Cообщить модератору

168. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от iZEN (ok), 16-Июн-12, 23:30 
>> Героев надо знать в лицо, а не только по имени. Так что
> Я не сотворяю кумиров, но вполне себе наматываю на ус умные мысли.

Мысли без авторства ничего не стоят.

>> не извеняю. :)
> Герой-аналитик, мля. Облажаться в слове "извините" - это сильно.

Тест на цепляние к словам ты не прошёл. Учись дальше, студент.

>>> помешал там дефрагер, судя по тому что скорость работы ниже линейной в 10 раз.
>> Пул заполнен на 99%.
> Жесткач. Ты вообще представляешь как это выглядит? Ты свой мега-пул без ножа
> зарезал :)

Я-то? Представляю. А вот ты? Любишь потрындеть про CoW-ФС, а у самого небось только Ext4 в Ubuntu. :))

>> HDD 2,5" 5400 rpm имеют максимум пропускной способности 55 МБ/с,
> Давай ты мне не будешь про них рассказывать, у меня вот под
> рукой пачка лежит. В среднем они свои 40-55 метров в секунду
> на линейном чтении отдают. Типично при линейном чтении можно ожидать около
> 50Мб/сек с диска.

Давай проспонсируй меня на покупку нескольких HDD, чтобы разгрузить пулы и добавить свободного пространства. От ещё трёх HDD 2,5" на 640 ГБ каждый я бы не отказался — сделал бы RAID-Z1-0 и скорость I/O пула повысилась бы до 60-70 МБ/с. ;)

Но HDD нынче дороги — наращивают упущенную выгоду от затопленных производств. :))

>> средняя, соответственно, около 20 МБ/с, а не в 10 раз от 6 МБ/с.
> По моим наблюдениям, средняя там скорее мегов 40-50 в секунду получается. Больше
> на внешних треках, меньше на внутренних.

Никак не получается такая скорость на современных CoW-ФС, использующих малоскоростные шпиндели. Это скорость посекторной записи на RAW-девайсы малоскоростных шпинделей. От механики можно убежать только на SSD.

> А ты просто буратина, который загнал ФС в полную опу.

Была потребность — делаю. Чужие ощущения как бы не колышат — живу своими.

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

На пуле медиатека. Периодически сгружаются туда заранее закачанные файлы, удаляются старые.

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

Btrfs круто оптимизируют для Android-девайсов и заменят журналирующую Ext4, которая там не нужна до смерти. На большее она не способна.

>> Когда там появится fsck? Или не нужен? :))
> Вообще-то он там уже есть. Правда недоделанный. И еще ряд прикольных недеструктивных
> тулзов вытаскивающих файло без изменений в попорченную ФС. А в ZFS
> ни того ни другого нет и вообще не планируется даже.

Открой для себя ZDB и удивись.

> Когда
> выбор между фанатством к марке и доступом к данным - я
> за доступ к данным.

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

>> ZVOL обеспечивает это, а также включаемые по желанию свойства верифицируемости
>> (checksum) на случай ненадёжных носителей.
> Ну в общем ваши космические корабли бороздят просторы тихого океана, я правильно
> понял твой спич?

Скорее — СУБД не нуждается в универсальной ФС, у неё должна быть своя структура хранения на RAW-девайсе. ZVOL может предоставить такое RAW-пространство, и оно может располагаться на любом типе пула.

>> Дык это не маркетинг. Это то, к чему уже привыкли на нормальных системах.
> Я так смотрю, ты привык и к скорости 6Мб/сек :)

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


>> Факты? Компания Oracle отказалась от ZFS в своих серверах? Btrfs она точно не использует.
> Они в unbreakable Linux его уже внедряют, если уж мы тут о фактах :)

Да, внедряют — оптимистичная нотка два месяца назад появилась. :)

Ответить | Правка | Наверх | Cообщить модератору

181. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от AlexAT (ok), 17-Июн-12, 00:00 
> ... Android-девайсов ... заменят журналирующую Ext4, которая там
> не нужна до смерти.

Интересно, с чего вы взяли, что устройству, которое может быть выключено _в любой момент_ неприятным для FS образом, не нужна журналирующая FS? Механизмы левелинга, конечно, обеспечивают некоторое журналирование, но оно не учитывает особенностей FS.

Ответить | Правка | Наверх | Cообщить модератору

186. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от iZEN (ok), 17-Июн-12, 00:42 
>> ... Android-девайсов ... заменят журналирующую Ext4, которая там
>> не нужна до смерти.
> Интересно, с чего вы взяли, что устройству, которое может быть выключено _в
> любой момент_ неприятным для FS образом, не нужна журналирующая FS?

Ext4 по дефолту журналирует только метаданные. А Btrfs по дефолту делает CoW и метаданным, и данным. Пользователям хочется лучшего, очевидно, они не хотят лицезреть кашу вместо данных при отлично работающей ФС.

> Механизмы левелинга, конечно, обеспечивают некоторое журналирование, но оно не учитывает особенностей FS.

Да что там учитывать? CoW-ФС в случае внезапного пропадания питания не делает из данных каши — это очевидное преимущество перед простым журналированием одних лишь матаданных в традиционных ФС. В мобильных девайсах не так важна скорость ФС, сколько надёжность хранения.

Ответить | Правка | Наверх | Cообщить модератору

196. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от AlexAT (ok), 17-Июн-12, 09:02 
>>> В мобильных девайсах не так важна скорость ФС, сколько надёжность хранения.

А еще там очень важно то, что объем памяти крайне невелик :) Поэтому ZFS там не будет никогда, потому что не будет никогда.


Ответить | Правка | Наверх | Cообщить модератору

201. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от Аноним (-), 18-Июн-12, 08:13 
> Поэтому ZFS там не будет никогда, потому что не будет никогда.

Опять bsdшников посетил заяц несудьбы...


Ответить | Правка | Наверх | Cообщить модератору

188. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от Аноним (-), 17-Июн-12, 02:22 
> Мысли без авторства ничего не стоят.

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

>> Герой-аналитик, мля. Облажаться в слове "извините" - это сильно.
> Тест на цепляние к словам ты не прошёл. Учись дальше, студент.

А вроде бы прокатило, хоть и жирновато было :)

> Я-то? Представляю.

Не, ты не представляешь. Ты доставляешь. Лулзы.

> А вот ты? Любишь потрындеть про CoW-ФС, а у самого небось только Ext4 в Ubuntu. :))

И btrfs есть. У меня вообще накопителей - хватает. Вот только у меня хватает ума подождать зеленого свистка вверх и посмотреть на результаты масс-внедрежки до того как что-то ценное туда сгружать. А так - оно работает. Даже в убунте. Правда если оно всерьез надо - кернель лучше юзать свеженький, багов там чинят много, твикают злобно, так что юзать кернель на 2-3 минорных версии старше последнего при нужности btrfs не совсем умно.

> Давай проспонсируй меня на покупку нескольких HDD,

А оно мне надо?

> чтобы разгрузить пулы и добавить свободного пространства.

Что самое смешное, это тебе уже не сильно поможет: та лапша которая там уже получилась никуда не денется.

> пула повысилась бы до 60-70 МБ/с. ;)

Не хочу ничего сказать но что-то меня цифра в 60Мб/с на такой куче оборудования что-то не вдохновляет.

> Но HDD нынче дороги — наращивают упущенную выгоду от затопленных производств. :))

Есть слегка такое дело. Цены уже не настолько конские, но все-таки.

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

В принципе CoW фс вполне может попробовать трансформировать записи в нечто более-менее линейное. Тем более что у btrfs еще и дефрагер встроенный есть.

> Это скорость посекторной записи на RAW-девайсы малоскоростных шпинделей.

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

> От механики можно убежать только на SSD.

При таком стиле использования ФС у тебя и флеш протрется до дыр в момент. Просто потому что у встроенного контроллера не останется пространства для маневров и он будет вынужден на каждый пшик тереть блок и делать GC, чтобы хоть немного выкроить для разруливания запрошенной операции :)

>> А ты просто буратина, который загнал ФС в полную опу.
> Была потребность — делаю. Чужие ощущения как бы не колышат — живу своими.

Кто ж тебе доктор? :D

> На пуле медиатека. Периодически сгружаются туда заранее закачанные файлы, удаляются старые.

Я бы сказал что на пуле с 99% использования и скоростью 6Мб/сек - идиотека :)

> Btrfs круто оптимизируют для Android-девайсов и заменят журналирующую Ext4, которая там
> не нужна до смерти. На большее она не способна.

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

> Открой для себя ZDB и удивись.

Я что-то не понял, ты мне предлагаешь самому чтоли по 1 файлу выколупывать с помощью вьюшки-дебагилки? А если файлов 10 000? А миллион?

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

Это ты про свой пул чтоли? :)

> Скорее — СУБД не нуждается в универсальной ФС, у неё должна быть
> своя структура хранения на RAW-девайсе.

Теоретически ничему не противоречит, но админить неудобно + свою RAW девайсину 10-меговой sqlite базе - больно жирно, да? :)

> ZVOL может предоставить такое RAW-пространство, и оно может располагаться на любом типе пула.

Ну и какие БД это могут юзать?

>> Я так смотрю, ты привык и к скорости 6Мб/сек :)
> А что, мало разве? За счёт агрессивного кэширования часто используемых данных оно
> не ощущается вообще. Но когда сливаешь большой файл, то тут, да,
> наступают тормоза системы.

Ну вот, сам же и ответил на свой вопрос. Ясен пень, 6мб/сек это мало. Даже самая занюханная китайская флешка читается быстрее.

>> Они в unbreakable Linux его уже внедряют, если уж мы тут о фактах :)
> Да, внедряют — оптимистичная нотка два месяца назад появилась. :)

Его и новелл внедряет и прочие. Пока не по дефолту - типа technology preview еще. Но вполне действующее preview и в общем то юзабельное уже. Просто пока никто не дает гарантий что оно production quality и fsck еще несколько недопиленный.

Ответить | Правка | К родителю #168 | Наверх | Cообщить модератору

198. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от юзер (??), 17-Июн-12, 11:44 
Основная причина почему ZVOL может не подходить, ровно такая же как от ZPL. Так как CoW никуда не делся. Просто убрали posix layer ... Стала чуть тоньше прослойка.

RAW диски может использовать любая уважающая себя СУБД 8-) (Ну так как тут речь в основном про Оракл - то он может, в отличии от sqlite 8-))) который вы посчитали как СУБД)

Мне больше всего не хватает в btrfs следующих возможностей:
1. Гибридного хранения данных (про bcache не то - ибо привязка к блочному устройству)
2. Рейдом отличных от 0,1,10 (да читал что есть отдельные патчи, но когда сделают эту унификацию уровней raid по md, dm и btrfs - непонятно)
3. Нормальной миграции между различными уровнями RAID (тут тоже подвижки видятся)
4. Что б balance не рушил CoW на снепшотах
5. offline (!) - дедубликацию (у меня есть интервалы низкой нагрузки, во время которых я могу гонять balance и dedup-процессы)

по-большому счету всем остальным можно пользоваться уже

Ответить | Правка | Наверх | Cообщить модератору

199. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от юзер (??), 17-Июн-12, 12:28 
4. не balance конечно, а defrag
Ответить | Правка | Наверх | Cообщить модератору

202. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от Аноним (-), 18-Июн-12, 08:22 
> тут речь в основном про Оракл - то он может,

Лично мне если честно на оракл вообще глубоко плевать :)

> в отличии от sqlite 8-))) который вы посчитали как СУБД)

Скулайт конечно такая немеряная субд :)) но известен он тем что довольно заметно тормозит на btrfs - судя по всему журнальная логика хреново накладывается.

> Мне больше всего не хватает в btrfs следующих возможностей:

[...]
> 4. Что б balance не рушил CoW на снепшотах
> 5. offline (!) - дедубликацию (у меня есть интервалы низкой нагрузки, во
> время которых я могу гонять balance и dedup-процессы)

Интересно, а что если эту мыслю прям вот так вот и вфутболить им в список рассылки? Вроде бы дельно, а половина и мне бы пригодилась. Ну так, чтобы разработчики были в курсе  :). Ну кроме той части которая и так задумана но злостный WIP.

> по-большому счету всем остальным можно пользоваться уже

Вполне согласен с такой оценкой - базовая механика вроде как уже более-менее устаканивается.

Ответить | Правка | К родителю #198 | Наверх | Cообщить модератору

200. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от iZEN (ok), 17-Июн-12, 13:20 
>> Мысли без авторства ничего не стоят.
> Логика дебила. А на что влияет авторство? Типа, если Пупкин сказал то
> это фигня, а если твой кумир - то сразу фигня перестает
> быть фигней, да? :)

Видишь ли, "одним из первых эпистемологическую проблему ставит Парменид, вводя различия между истиной и мнением. Истина — это знание бытия, поэтому её главными критериями являются непротиворечивость, постоянство и вечность. Сократ разрабатывает один из первых методов познания — диалектику — прояснение идеи в процессе диалога. Истина здесь выступает в качестве консенсуса. Платон считал знания, приобретаемые людьми в течение жизни, воспоминанием уже существующего в душе человека знания. Аристотель закладывает основы рационализма, разрабатывая такой метод познания как аналитика."

>> Это скорость посекторной записи на RAW-девайсы малоскоростных шпинделей.
> В идеальном случае, если ФС грамотно все делает, скорость записи и чтения
> должна быть близка к таковой. Но при 99% занятости пространства -
> любая ФС будет действовать не "как хочется" и "как было лучше",
> а "уж как получится наколупать из остатков по чайной ложке".

Ну вот и не удивляйся, что при свободном пространстве меньше 10-15 ГБ на CoW-ФС скорость ввода-вывода проседает на порядок от максимально возможной. Я не удивляюсь — я констатирую этот факт наблюдением.

>> От механики можно убежать только на SSD.
> При таком стиле использования ФС у тебя и флеш протрется до дыр

С чего бы? Я оставляю файлы на как можно больший срок. Стираю совсем уж ненужное и потерявшее актуальность. Перезаписываю не так часто.

>> ZVOL может предоставить такое RAW-пространство, и оно может располагаться на любом типе пула.
> Ну и какие БД это могут юзать?

ЛЮБЫЕ. И те, которые умеют создавать свои структуры на RAW, и те, которые лучше всего работают на какой-либо классической ФС, в которой отформатирован ZVOL. К примеру, ZVOL можно отформатировать в UFS2 (без журнала и Soft Updates, если нужно) или даже в FAT32, и на них разместить служебные файлы СУБД. Прикинь, FAT32 на RAID-Z3 пуле ZFS — линуксоиды не могут себе представить такого извращения. :)

Ответить | Правка | К родителю #188 | Наверх | Cообщить модератору

203. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от Аноним (-), 18-Июн-12, 08:34 
>> Логика дебила. А на что влияет авторство? Типа, если Пупкин сказал то
>> это фигня, а если твой кумир - то сразу фигня перестает быть фигней, да? :)
> Видишь ли,

Вижу кучу писанины. Судя по всему - витиеватая попытка отмазаться от прямого ответа на простой вопрос.

> Ну вот и не удивляйся, что при свободном пространстве меньше 10-15 ГБ
> на CoW-ФС скорость ввода-вывода проседает на порядок от максимально возможной. Я
> не удивляюсь — я констатирую этот факт наблюдением.

Ну а что ты хотел? Чем меньше непрерывного свободного пространства - тем реже аллокатор сможет его отхапать. А т.к. CoW сам по себе городит фрагменты-выноски, все только усугубляется. Тем не менее, этот эффект есть и на обычных ФС. Просто на CoW он сильнее заметен за счет их природы.

> С чего бы? Я оставляю файлы на как можно больший срок. Стираю
> совсем уж ненужное и потерявшее актуальность. Перезаписываю не так часто.

С того что записи будут довольно неудобные для физической реализации в том что реально есть на флеше. Там еще 1 слой похожей механики работает же. И для нее совсем не подарок если файловая система начнет оптом глушить запросами "много мелких блоков разбросанных по всему диску". Erase-блоки флеша - довольно крупные сущности.

>>> ZVOL может предоставить такое RAW-пространство, и оно может располагаться на любом типе пула.
>> Ну и какие БД это могут юзать?
> ЛЮБЫЕ. И те, которые умеют создавать свои структуры на RAW,

А там вон выше утверждают что CoW никуда не девается, ну и проблема с ним стало быть тоже. На btrfs можно просто отрубить CoW там где он мешается.

> разместить служебные файлы СУБД. Прикинь, FAT32 на RAID-Z3 пуле ZFS —
> линуксоиды не могут себе представить такого извращения. :)

Я могу себе представить очень много извращений. Но не всегда могу себе представить нафиг они нужны.

Ответить | Правка | Наверх | Cообщить модератору

82. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от AlexAT (ok), 16-Июн-12, 09:55 
> я тем кто постоянно копается в ФС доверяю больше чем тебе
> с твоим супер-рэйдом на 6Мб/сек :). Кстати имхо тебе бы не

Блджад, чего-то я сразу не догадалсо. У него что, RAID1 на одном диске? xD

Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

127. "Обновилась версия нативной реализации файловой системы ZFS д..."  –1 +/
Сообщение от iZEN (ok), 16-Июн-12, 20:16 
>> я тем кто постоянно копается в ФС доверяю больше чем тебе
>> с твоим супер-рэйдом на 6Мб/сек :). Кстати имхо тебе бы не
> Блджад, чего-то я сразу не догадалсо. У него что, RAID1 на одном диске? xD

У меня-то?

На посмотри: [посмотрели и хватит]

Ответить | Правка | Наверх | Cообщить модератору

139. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от AlexAT (ok), 16-Июн-12, 21:32 
> У меня-то?
> На посмотри: [посмотрели и хватит]

И с 4 дисками оно даёт 6мб/сек? Поздравляю, вы достигли невиданных высот производительности.

Ответить | Правка | Наверх | Cообщить модератору

143. "Обновилась версия нативной реализации файловой системы ZFS д..."  –1 +/
Сообщение от iZEN (ok), 16-Июн-12, 22:48 
>> У меня-то?
>> На посмотри: [посмотрели и хватит]
> И с 4 дисками оно даёт 6мб/сек? Поздравляю, вы достигли невиданных высот производительности.

Кто сказал, что с четырёх?

6 МБ/с — это скорость I/O у заполненного на 99,9% пула raid-z1, когда свободного места около 1-2 ГБ.

Ответить | Правка | Наверх | Cообщить модератору

148. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от Аноним (-), 16-Июн-12, 22:53 
> 6 МБ/с — это скорость I/O у заполненного на 99,9% пула

Настолько эпичного забивания микроскопом гвоздей я давненько не видал. Жги еще :)

Ответить | Правка | Наверх | Cообщить модератору

80. "Обновилась версия нативной реализации файловой системы ZFS д..."  +1 +/
Сообщение от AlexAT (ok), 16-Июн-12, 09:46 
> А ZFS тюнится по всем фронтам подо что угодно, под любые задачи,
> связанные с надёжным (и малонадёжным :) ) хранением данных. На уровне
> настроек кэшей ARC, L2ARC, на уровне блочного представления (ZVOL), на уровне
> методов поддержки целостности и верифицируемости реализуется куча стратегий использования.

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

Давай начистоту: это реально пригодно только для файлопомоек с документами. Всё остальное сидит на ext'ах в силу их предсказуемости. Для БД оно не пригодно в принципе в силу двойного кеширования. Для почтовика - в силу того, что захлебнётся под sync'ами и write barrier'ами. Для web-сервера под сомнением, зависит от специфики нагрузки. Где-то, может быть, будет юзабельно. Для виртуалок непригодно в силу неизвестности специфики.

В винду бы её портнуть. Там оного сильно не хватает, а большинство компаний документы хранят именно на винде.

Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

69. "Обновилась версия нативной реализации файловой системы ZFS д..."  +1 +/
Сообщение от Fyjybv (?), 16-Июн-12, 00:38 
>А вот ораклу такой расклад как-то не очень нравится. Наверное это и мотивировало их затеять ФС которая была бы лучше, в том числе и с их базами.

Интересная мысль, кстати...

Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

70. "Обновилась версия нативной реализации файловой системы ZFS д..."  +2 +/
Сообщение от filosofem (ok), 16-Июн-12, 01:27 
Соглашусь, что интересная. Интереснее мысли использовать COW файловую систему для размещения БД может быть только мысль заменить одну COW файловую систему на другую COW файловую систему. =)
Ответить | Правка | Наверх | Cообщить модератору

76. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от Аноним (-), 16-Июн-12, 06:57 
> БД может быть только мысль заменить одну COW файловую систему на
> другую COW файловую систему. =)

У них все-таки есть отличия в логике аллокаторов. Более того - btrfs в принципе может и не делать CoW, если не надо. Если не ошибаюсь, идея была сделать выбор использовать ли CoW чуть ли не пофайлово.

Немного из их вики про опцию nodatacow:
> Performance gain is usually < 5% unless the workload is random writes to large database files

Достаточно прозрачный намек, правда? :)

Ответить | Правка | Наверх | Cообщить модератору

84. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от filosofem (ok), 16-Июн-12, 10:50 
COW чисто для примера, конечно в нем только часть проблемы. Совершенно очевидно, что ни та ни другая ФС не затачивалось под базы данных.
Наверно можно отказаться от всех плюшек вроде снэпшотов, сжатия, чексумм и пр., поменять алгоритм работы ФС, приставить парочку костыликов и получить близкую к ext3/4 производительность. Но, повторюсь, для меня очевидно, что проектировали обе ФС не под эту задачу.

Наверно самый прямой способ исправить производительность ― это оптимизировать саму СУБД под работу с этими ФС. Но ИМХО еще прямее, производительнее и универсальнее реализовать необходимый функционал внутри СУБД и не зависеть от файловой системы.

Ответить | Правка | Наверх | Cообщить модератору

94. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от ананим (?), 16-Июн-12, 15:03 
>COW чисто для примера, конечно в нем только часть проблемы. Совершенно очевидно, что ни та ни другая ФС не затачивалось под базы данных.

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

можете сравнить:
http://docs.oracle.com/cd/B28359_01/server.111/b28318/logica...
>Oracle Database allocates logical database space for all data in a database. The units of database space allocation are data blocks, extents, and segments.

и
https://btrfs.wiki.kernel.org/index.php/Main_Page
>The main Btrfs features available at the moment include:
>  Extent based file storage

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

Ответить | Правка | Наверх | Cообщить модератору

97. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от filosofem (ok), 16-Июн-12, 15:27 
>Oracle Database allocates logical database space for all data in a database. The units of database space allocation are data blocks, extents, and segments.

Писал же, если и заточат, то в большей степени СУБД под ФС, чем наоборот. И не вижу в этом логики, потому что все что надо можно реализовать в СУБД: снэпшоты, компрессию, размещение на нескольких томах, репликацию и много чего еще и многое уже реализовано и поверх ext4 это будет грубо говоря на пару порядков меньше тупить при записи и на порядок при чтении чем на Btrfs.

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

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


Ответить | Правка | Наверх | Cообщить модератору

100. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от ананим (?), 16-Июн-12, 15:46 
ответил ниже (давайте туда обсуждение и перенесём, если охота. а то прыгать надоело).

только это уточню
>И не вижу в этом логики, потому что все что надо можно реализовать в СУБД: снэпшоты, компрессию, размещение на нескольких томах, репликацию

всё это в оракле работает в стиле fuse на традиционных фс.
со всеми вытекающими.
с другой стороны воспользоваться преимуществами бтр сейчас может только субд оракл.
ну и если напишут двигун к мускулю.
который тоже оракл.
для всех остальных субд лучшим решением до сих пор являются (у в будут являтся. ибо даже нет подвижек) фс в стиле extX/ufs/raw/...

Ответить | Правка | Наверх | Cообщить модератору

103. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от filosofem (ok), 16-Июн-12, 15:56 
Да блин уже непонятно где что отвечать, три одинаковых треда. =)

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

Если это действительно так, то отчасти соглашусь. Но где посмотреть не теоретические пруфы?
Не вижу причины, почему Оракл может допилить свою СУБД, а остальные не могут.

Ответить | Правка | Наверх | Cообщить модератору

105. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от ананим (?), 16-Июн-12, 16:02 
> Да блин уже непонятно где что отвечать, три одинаковых треда. =)

ага :D

>Если это действительно так, то отчасти соглашусь. Но где посмотреть не теоретические пруфы?

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

Ответить | Правка | Наверх | Cообщить модератору

107. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от filosofem (ok), 16-Июн-12, 16:07 
>могу сказать что мэйсон эту часть уже завершил.

Тот который из Оракла ушел? =)

Ответить | Правка | К родителю #105 | Наверх | Cообщить модератору

108. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от ананим (?), 16-Июн-12, 16:13 
угу. :D

зыж
ну дык элоп тоже вон на финов работает. :D

Ответить | Правка | К родителю #107 | Наверх | Cообщить модератору

174. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от Аноним (-), 16-Июн-12, 23:48 
> ну дык элоп тоже вон на финов работает. :D

Интересное понимание работы НА финов. Мне кажется что он поработав на них угробит контору + может быть патентов немного отожмет. А финам останется зaкaпывать высушенный трупик ноклы.

Ответить | Правка | К родителю #108 | Наверх | Cообщить модератору

182. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от ананим (?), 17-Июн-12, 00:05 
неа.
отожмут все (ВСЕ!!!) патенты.

зыж
уж человеку, выжевшему в 90-е в России, это надо понимать чётко. :D

Ответить | Правка | К родителю #174 | Наверх | Cообщить модератору

126. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от Аноним (-), 16-Июн-12, 20:14 
> COW чисто для примера, конечно в нем только часть проблемы.

Проблема выглядит так: есть бд. С журналом. Обычная транзакция через журнал для CoW ФС вызовет CoW и для журнала и для БД. Итого? Два выноска вбок (журнальный и БДшный). Бессмысленно и беспощадно. Фрагментация растет, появляется куча мусора, лишних действий сделано вагон. По сути - отжурналили дважды. Нафига?

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

Судя по таким фичам как nodatacow, которые по задумке применимы аж к отдельным файлам, логично предположить что оракл просто попросил архитекта придумать что-нибудь по поводу хреновой работы CoW с "большими базами данных". Ну и придумали - если мешается, пусть будет отключабелен для "файлов с большими базами данных" :)

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

Эти плюшки, будучи применены к "большой БД с журналингом" просто угробят производительность в ноль и засрут том кучей фрагментов, при том минимум половина из них вообще отбабахана на временные служебные сущности aka кусок журнала.

А на кой хрен вам снапшоты журнала и БД, если их журналирование и так обеспечивают консистентность? Более того, откатив базу транзакций на устаревший снапшот - можно сказочно попасть на бабки, например. Журнальная логика по идее обеспечивает "все или ничего", так что или операция доходит до финиша, или полностью отменяется. А вы предлагаете выдать юзеру бабло, потом откатить снапшот (стало быть, забыв о том что выдали). И....и еще раз выдать?! Посколько баланс счета откатился на дотранзакционное состояние! Откат снапшота БД не может вынуть купюры из кармана юзера, поэтому откат в дотранзакционное состояние на этот момент времени уже будет "немного неполным". Получится состояние БД не коррелирует с фактическим состоянием дел. Получится сломанная база с недостоверными данными + сказочный залет на бабки. Юзер с радостью обнаружит что с него забыли списать то что у него звенит в кармане. И снимет еще раз.

> поменять алгоритм работы ФС, приставить парочку костыликов и получить близкую к
> ext3/4 производительность.

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

> Но, повторюсь, для меня очевидно, что проектировали обе ФС не под эту задачу.

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

> Наверно самый прямой способ исправить производительность ― это оптимизировать саму
> СУБД под работу с этими ФС.

Теоретически - это ничему такому не противоречит, в принципе это повторяющийся функционал. Особенно если вспомнить что оракль как минимум раньше мог работать на RAW разделах, не нуждаясь в ФС. Ну то-есть ФС и БД - это достаточно похожие идеи, поданные под разным видом соуса :). Практически - вам имхо не понравится поведение btrfs при попытке хреначить много мелких транзакций. Потому что она для этого не оптимизировалась.

> Но ИМХО еще прямее, производительнее и универсальнее реализовать
> необходимый функционал внутри СУБД и не зависеть от файловой системы.

Внезапно, оракль помнится умел работать на RAW разделах - совсем без ФС. Это по идее удобнее всего для базы - оверхеда от ФС нет совсем. Так что баян! Зато это оказалось нифига не удобно для сисадминов в плане администрирования...

Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

144. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от ананим (?), 16-Июн-12, 22:48 
>Проблема выглядит так: есть бд. С журналом. Обычная транзакция через журнал для CoW ФС вызовет CoW и для журнала и для БД. Итого? Два выноска вбок

хинт
UUID=6c9c74fd-da69-432c-8b64-5317c6c79979    /u01            btrfs        defaults,subvol=u01,autodefrag,inode_cache                0 0
UUID=6c9c74fd-da69-432c-8b64-5317c6c79979    /u02            btrfs        defaults,subvol=u02,autodefrag,nodatacow,inode_cache                0 0

где /u02 - субволум для журналов.

зыж
дальше полный булшит из-за не понимания вышеприведённого хинта.

Ответить | Правка | Наверх | Cообщить модератору

150. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от Аноним (-), 16-Июн-12, 22:56 
> где /u02 - субволум для журналов.

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

Ответить | Правка | Наверх | Cообщить модератору

151. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от ананим (?), 16-Июн-12, 23:01 
хм. вот в этом
>Эти плюшки, будучи применены к "большой БД с журналингом" просто угробят производительность в ноль

и далее по тексту.

как создать субволум на работающей системе в 3 секунды и смотировать его с нокоудата тоже рассказать?

Ответить | Правка | Наверх | Cообщить модератору

172. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от Аноним (-), 16-Июн-12, 23:46 
>>Эти плюшки, будучи применены к "большой БД с журналингом" просто угробят производительность в ноль
> и далее по тексту.

Так в чем предъява? В общем случае будет вот так. Без специальной доработки БД - угробят. А то что оракль насколько я понял хочет доработать (или уже?) субд чтобы так делать было не надо - логично. А они что, у себя подритовали логику журналинга, чтобы на CoW более естественно ложилось? Если что - я ни разу не оракловый DBA и потому не слежу за деталями развития их баз.

> как создать субволум на работающей системе в 3 секунды и смотировать его
> с нокоудата тоже рассказать?

Мне - нафиг не надо. Я сам с btrfs периодически играюсь в ожидании зеленого свистка о готовности к продакшну. Изенам и прочим - да как хотите, мне похрен. Я думаю что изенообразные лучше будут наслаждаться своими 6Мб/сек, мужественно преодолевая невзгоды бсджного жития :)

Ответить | Правка | Наверх | Cообщить модератору

177. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от iZEN (ok), 16-Июн-12, 23:53 
> Я сам с btrfs периодически играюсь в
> ожидании зеленого свистка о готовности к продакшну.

Жди свистка, а мы будем пользоваться. :))

> Изенам и прочим -
> да как хотите, мне похрен. Я думаю что изенообразные лучше будут
> наслаждаться своими 6Мб/сек, мужественно преодолевая невзгоды бсджного жития :)

А куда деваться? У меня спонсоров нет, чтобы купить ещё шпинделей. Или ты проспонсируешь столь ответственную операцию в период яростного отъёма денег на новые заводы? :))

Ответить | Правка | К родителю #172 | Наверх | Cообщить модератору

180. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от AlexAT (ok), 16-Июн-12, 23:57 
> А куда деваться? У меня спонсоров нет, чтобы купить ещё шпинделей.

Не надо спонсоров. Выкиньте ZFS, вставьте ext4 (ну не мамонта UFS же), и поимейте, наконец, нормальную производительность на имеющемся железе.

Ответить | Правка | К родителю #177 | Наверх | Cообщить модератору

184. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от iZEN (ok), 17-Июн-12, 00:35 
>> А куда деваться? У меня спонсоров нет, чтобы купить ещё шпинделей.
> Не надо спонсоров. Выкиньте ZFS, вставьте ext4 (ну не мамонта UFS же),
> и поимейте, наконец, нормальную производительность на имеющемся железе.

Меня устраивает. По железу я пока "дауншифтер". :) Вот когда появятся 2,5" винчестеры 1-2 ТБ за приемлемую, а не конскую цену, как сейчас, тогда обновлю парк. А пока на классические Ext4/UFS на устаревшем (а значит, снижающем свою надёжность) железе я переходить не собираюсь — данные важнее скорости. Городить огороды из классических софтверных RAID муторно, много точек отказов на каждом из уровней: HDD, драйвер контроллеров, "изношенная" дешёвая оперативная память, недостаточная верификация данных. ZFS все потенциальные точки отказов заворачивает на себя, и если пул перестаёт работать не из-за поломки HDD, то он точно останется в непротиворечивом состоянии. Для классических RAID любая поломка на линии пересылаемых данных, не связанная с HDD, скорее всего приведёт к деградации массива и поиску дорогих запчастей.

Ответить | Правка | К родителю #180 | Наверх | Cообщить модератору

194. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от Аноним (-), 17-Июн-12, 05:16 
> и поимейте, наконец, нормальную производительность на имеющемся железе.

Ну если он и ее на 99% загадит - скорость будет тоже так себе. Хотя клиника будет не настолько хардкорная, имхо.

Чего я не понимаю так это вот чего: за цену 3 медленных ноутбучных 2.5" вполне можно купить 2-3 нормальных, весьма объемистых 3.5", которые и более надежны при длительной работе. Если роялит шум и нагрев - так в природе есть "зеленые" модели, у которых скорость вращения ниже "обычных" (обычно 5400RPM или около того). В счет чего они меньше жрут, меньше греются и намного тише елозят головами. При этом свободного места будет в 2-3 раза больше за те же деньги. Для HTPC-образных файлозавалов без требования к скорости - просто клад. Но изен как обычно все сделал через ... то самое место :).

Нет, мне самому нравятся 2.5" винчи. Клевые мелкие штучки, довольно емкие уже. Просто микроскопом забивать гвозди - медленно и геморройно. И не факт что микроскоп долго протянет в таком режиме.

Ответить | Правка | К родителю #180 | Наверх | Cообщить модератору

189. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от Аноним (-), 17-Июн-12, 02:27 
> Жди свистка, а мы будем пользоваться. :))

Да пожалуйста, наслаждайтесь вашими 6мб/сек :)

> ты проспонсируешь столь ответственную операцию в период яростного отъёма денег на
> новые заводы? :))

Да ну нафиг, мне и так хорошо. И вообще, предлагаю так и оставить как эталон производительности. Будем в iZEN'ах производительность мерять. Ну там 20x - уже ничего так для десктопного HDD, etc :)

Ответить | Правка | К родителю #177 | Наверх | Cообщить модератору

93. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от ананим (?), 16-Июн-12, 14:48 
>Соглашусь, что интересная. Интереснее мысли использовать COW файловую систему для размещения БД может быть только мысль заменить одну COW файловую систему на другую COW файловую систему. =)

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

Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

96. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от filosofem (ok), 16-Июн-12, 15:19 
Вот именно аналогия.
Только наоборот вводят двойную буферизацию, трэдизацию, процессозацию и другую двойную ацию. Короче дублируют функционал СУБД еще и в ФС.
И где тут логика? Будут переносить функционал из своей прелестной СУБД в файловую систему под GPLv2, чтобы конкурентного преимущества не было больше?
Ответить | Правка | Наверх | Cообщить модератору

99. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от ананим (?), 16-Июн-12, 15:40 
Логика в вызове функций фс там, где сейчас используется юзерспейс код.
С зфс ещё хлеще - держать мапирование своих экстентов с зфс-ными блоками.
А конкурентное преимущество в увеличении ещё больших попугаев в ИХ субд.
То что на такой фс можно ещё и файлопомойку развернуть - дело 10-е. И с бизнесом их не пересекается.
Ещё раз - оракловая субд будет там отлично жить. А у конкурентов? Перепишут свои субд под логику оракл? Врядли.
Ну к мусклу можно двигун смастерить. Благо мускуль такую архитектуру имеет. Но! Внизапно, а чей сейчас мускуль то?
Вот и получается, что оракл будет работать и в кластерах, и на миксах ссд-винты, и на крипто-зипо-дедупло,.....
А для нормальной работы конкурентов старый лвм-райд и тд. При этом оракл и тут работает тоже.
Ответить | Правка | Наверх | Cообщить модератору

101. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от filosofem (ok), 16-Июн-12, 15:49 
>Логика в вызове функций фс там, где сейчас используется юзерспейс код.
>С зфс ещё хлеще - держать мапирование своих экстентов с зфс-ными блоками.

Да, логика есть конечно, но только если мы говорим про некую гипотетическую файловую систему, а не про ZFS и Btrfs, которые (с этого и начался разговор) ну просто совсем провальны в работе с очень большим количеством мелких операций.

>Ещё раз - оракловая субд будет там отлично жить. А у конкурентов?

Да, если они как-то очень хитро и активно подгоняют свою СУБД под ФС, а ФС под СУБД, тогда логика есть. Но пока об этом ничего не говорит. Может быть под ZFS, про нее мало знаю, но Btrfs уже давно самостоятельно и неспешно развивается.

Ответить | Правка | Наверх | Cообщить модератору

104. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от ананим (?), 16-Июн-12, 15:59 
>Да, если они как-то очень хитро и активно подгоняют свою СУБД под ФС, а ФС под СУБД, тогда логика есть. Но пока об этом ничего не говорит. Может быть под ZFS, про нее мало знаю, но Btrfs уже давно самостоятельно и неспешно развивается.

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

>но Btrfs уже давно самостоятельно и неспешно развивается.

как и ocfs2.
что не мешает ораклу использовать её в самых крутых инсталяциях.
а если ещё вспомнить про ceph, то с бтр оракл сможет делать инстансы ещё больше в перспективе.

Ответить | Правка | Наверх | Cообщить модератору

106. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от filosofem (ok), 16-Июн-12, 16:06 
>в любом случае - мелких файлов нет,

С мелкими файлами проблем у Btrfs нет. Проблемы при частом доступе к большому файлу. Под это в частности попадают базы данных.
Один из костыльных и способов оптимизировать это дело вроде
>у их субд запись грязных блоков идёт либо по контрольной точке (раз в 3 секунды)

тоже очевиден. Но в нем нет рокетсаенса и воспользоваться им может не только Оракл.

Ответить | Правка | Наверх | Cообщить модератору

109. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от ананим (?), 16-Июн-12, 16:25 
>С мелкими файлами проблем у Btrfs нет. Проблемы при частом доступе к большому файлу. Под это в частности попадают базы данных.

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

>Но в нем нет рокетсаенса и воспользоваться им может не только Оракл.

очевидно да.
но это - либо менять структуру тогоже постгри/огнелис/прогресс/дб2, либо писать что-то новое. а клинический ынтырпрайз на енто не пойдётЪ. :D
потом (следим за новостями с попкорном) появляются новости очередного эксадата с поддержкой вот такоговот железа с крипто/зипо/дедупо/... на уровне ядра с сопроцесоо/фпу/.. поддержкой.
и понимаем, что 1) это все только в унбрикэбл 2) у конкурентов это только в юзерспейсе 3) достичь таких объёмов в стиле fuse даже в теории низя.
как то так. вот.

Ответить | Правка | Наверх | Cообщить модератору

110. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от ананим (?), 16-Июн-12, 16:35 
зыж
к этому
>эксадата с поддержкой вот такоговот железа с крипто/зипо/дедупо/... на уровне ядра ... что 1) это все только в унбрикэбл

типа такого - http://www.fusionio.com/platforms/
куда мэйсон и свалил. :D

Ответить | Правка | К родителю #109 | Наверх | Cообщить модератору

117. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от filosofem (ok), 16-Июн-12, 18:14 
>>С мелкими файлами проблем у Btrfs нет. Проблемы при частом доступе к большому файлу. Под это в частности попадают базы данных.
> в оракловом случае не попадают.
> наоборот, ораклу пофиг на фрагментацию всего файла (большого файла. угу. на заметку).
> но не плевать на фрагментацию отдельных кусков этого файла.
> и эти куски очень сильно согласуются с контрольными точками и коммитами транзакций.

И фрагментация тоже не многое объясняет, на SSD она мало влияет на скорость, тем не менее вот недавнее сравнение нашел. ИМХО правдоподобно.
http://www.mysqlperformanceblog.com/2012/05/22/btrfs-probabl.../
Если хочется докопаться до сути, наиболее правдоподобное на мой взгляд объяснение феномена было в мэйллистах федоры. http://comments.gmane.org/gmane.linux.redhat.fedora.devel/15.... Второй пост и далее по треду. Лично мне достаточно длительного существования проблемы и отсутствия решения, чтобы говорить, что не под эти задачи систему проектировали изначально.

>>Но в нем нет рокетсаенса и воспользоваться им может не только Оракл.
> очевидно да.
> но это - либо менять структуру тогоже постгри/огнелис/прогресс/дб2, либо писать что-то
> новое. а клинический ынтырпрайз на енто не пойдётЪ. :D

Тот же мускуль что-то порядка десяти сторадж бэкендов имеет, а значит и в МарияДБ можно запилить еще скажем один. Во всяком случае не верю, что Оракл не верит, что конкуренты не способны воспользоваться его технологиями.

> и понимаем, что 1) это все только в унбрикэбл 2) у конкурентов
> это только в юзерспейсе 3) достичь таких объёмов в стиле fuse
> даже в теории низя.
> как то так. вот.

Ну да и поэтому они запилили бы свой модуль в свое анбрикабл ядро для своей базы данных, а не ФС для "враждебной" общественности.


Ответить | Правка | К родителю #109 | Наверх | Cообщить модератору

118. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от ананим (?), 16-Июн-12, 18:55 
Слишком много и по-кругу.
Опять.


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

Ответить | Правка | К родителю #117 | Наверх | Cообщить модератору

124. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от filosofem (ok), 16-Июн-12, 20:02 
ну если так, то просто рекомендую при случае попробовать более-менее загруженную базу на Btrfs положить. Тупняк настолько суров, что в него сложно поверить не проверив на своем опыте.
Ответить | Правка | К родителю #118 | Наверх | Cообщить модератору

135. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от ананим (?), 16-Июн-12, 21:05 
Только не надо мне говорить, что вы ораел дба :D

Зыж
Кстати клал. Не продуктивную, но... лучше чем зфс с настройками по феньшую.
И да, бтр для будущих версий. Которые будут на неё рассчитаны. Это новость?
Думаю как раз перед ними бтр и станет продакшн рэди.

Ответить | Правка | К родителю #124 | Наверх | Cообщить модератору

141. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от filosofem (ok), 16-Июн-12, 22:17 
>Только не надо мне говорить, что вы ораел дба :D

Нет, божеупаси админить это чудовище. У меня постгрес и немного мускулей, если считать только тех которые под нагрузкой, а так какой экзотики только нет. Я имел в виду любую СУБД на Btrfs погонять, но если можете Оракл, тем интереснее результат.

Ответить | Правка | К родителю #135 | Наверх | Cообщить модератору

146. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от ананим (?), 16-Июн-12, 22:51 
та не,
оракл не так страшен, как его малюют.

>Я имел в виду любую СУБД на Btrfs погонять, но если можете Оракл, тем интереснее результат.

для любой субд бтр с нокоудата.
для оракла - нет.
вот в этом и интерес оракла кстати :D

Ответить | Правка | К родителю #141 | Наверх | Cообщить модератору

163. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от filosofem (ok), 16-Июн-12, 23:25 
С nocowdata запись при большом количестве транзакций раза в 2 быстрее, остальное так же. При этом естественно не работают снэпшоты, а так же сжатие данных. Вот мы и отказались от сразу двух жирных плюшек.
Допустим на Оракл ДБ магическим образом не будет влиять COW и допустим она еще в 2 раза быстрее за счет какого-нибудь агрессивного кэширования. Но отставание то от ext4 на порядки под нагрузкой!
Ответить | Правка | К родителю #146 | Наверх | Cообщить модератору

169. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от Аноним (-), 16-Июн-12, 23:31 
> Но отставание то от ext4 на порядки под нагрузкой!

Не вижу никаких фундаментальных причин для того чтобы было так: в случае nodatacow оно по сути что-то типа ext4 и получится ;)

Ответить | Правка | К родителю #163 | Наверх | Cообщить модератору

173. "Обновилась версия нативной реализации файловой системы ZFS д..."  +1 +/
Сообщение от ананим (?), 16-Июн-12, 23:47 
да.
но! это субволум! и там же! и только для журналов! и в 3 сек добавить-удалить. :D
Ответить | Правка | К родителю #169 | Наверх | Cообщить модератору

193. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от Аноним (-), 17-Июн-12, 05:05 
> но! это субволум! и там же! и только для журналов! и в 3 сек добавить-удалить. :D

Я так смотрю, такие плюшки не только мне нравятся :)

Ответить | Правка | К родителю #173 | Наверх | Cообщить модератору

171. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от ананим (?), 16-Июн-12, 23:45 
>С nocowdata запись при большом количестве транзакций раза в 2 быстрее, остальное так же.

ТОЛЬКО.. ДЛЯ.. ЖУРНАЛОВ!!!
>При этом естественно не работают снэпшоты, а так же сжатие данных.

журналам не нужны. журналы сами по себе снэпшоты.

зыж
>Допустим на Оракл ДБ магическим ....

далее троллинг.
вы всё уже поняли, я уверен. :D
не айзен чай.

Ответить | Правка | К родителю #163 | Наверх | Cообщить модератору

128. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от Аноним (-), 16-Июн-12, 20:24 
> С мелкими файлами проблем у Btrfs нет.

У нее есть проблемы с "множеством мелких транзакций". Сложно знаешь ли на круизном теплоходе маневрировать так же как на прогулочном катере на 2 персоны.

Ответить | Правка | Наверх | Cообщить модератору

155. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от ананим (?), 16-Июн-12, 23:07 
да.
но у оракла все транзакции крупные.
он сбрасывает блоки на диск по чекоуту (3 раза в сек) или по коммиту.
а коммит (как говорит том кайт. и правильно говорит) в оракле надо делать только из соображений бизнес-логики, а не "как можно чаще" как в мссиквеле.

зыж
>он сбрасывает блоки на диск по чекоуту

и бтр за одну(!) операцию выделит ему столько места, сколько попросит.
сразу.
а не тюнингованный эквивалент в зфс.
и не энсать секунд как в уфс.

ззыж
именно поэтому ext4 тоже не плоха - эктенты таки есть.
это как с торрентами.
но в бтр это ещё и в рамках одного файла. ей пофиг.

Ответить | Правка | К родителю #128 | Наверх | Cообщить модератору

167. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от Аноним (-), 16-Июн-12, 23:29 
> и бтр за одну(!) операцию выделит ему столько места, сколько попросит.сразу.
> а не тюнингованный эквивалент в зфс.
> и не энсать секунд как в уфс.

Во, DBA явно заценил работу экстентного аллокатора. А бздуны орут что оно не нyжно. Лолки! :)

Ответить | Правка | К родителю #155 | Наверх | Cообщить модератору

175. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от ананим (?), 16-Июн-12, 23:49 
билятттт....тт...ъъъ
давно жду.
учавствую.
верю.
...
и тд и тп.
Ответить | Правка | К родителю #167 | Наверх | Cообщить модератору

71. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от filosofem (ok), 16-Июн-12, 01:30 
>А вот ораклу такой расклад как-то не очень нравится. Наверное это и мотивировало их затеять ФС которая была бы лучше, в том числе и с их базами.

И намного быстрее их базы на Btrfs работают, чем на ZFS? Чисто из академического интереса спрашиваю.

Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

91. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от Аноним (-), 16-Июн-12, 14:29 
> И намного быстрее их базы на Btrfs работают, чем на ZFS? Чисто
> из академического интереса спрашиваю.

На бтре они работают, на ZFS - нет (на любой более-менее серьезной нагрузке система встает колом).

Ответить | Правка | Наверх | Cообщить модератору

134. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от iZEN (ok), 16-Июн-12, 21:05 
Неужели?

"Oracle на ZFS: Учимся готовить кошек, часть I": http://yvoinov.blogspot.com/2011/01/oracle-zfs-i.html

Ответить | Правка | Наверх | Cообщить модератору

136. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от ананим (?), 16-Июн-12, 21:09 
Готовили, пробовали, знаем.
Не то.

Зыж
Ха. Желаю вам быть оракл дба на зфс.
А то на металинке сразу в сад.

Ответить | Правка | Наверх | Cообщить модератору

162. "Обновилась версия нативной реализации файловой системы ZFS д..."  +2 +/
Сообщение от Аноним (-), 16-Июн-12, 23:24 
> Ха. Желаю вам быть оракл дба на зфс.

Когда изен умрет и попадет к чертям в ад, он будет админить оракл на zfs. Вечно.

Ответить | Правка | Наверх | Cообщить модератору

95. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от ананим (?), 16-Июн-12, 15:16 
>И намного быстрее их базы на Btrfs работают, чем на ZFS? Чисто из академического интереса спрашиваю.

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

зыж
и да, лучшие результаты у сбд оракл получаются на раудевайсах (без фс вообще).
выигрыш 20-30%. а это ой как не мало.
но, в последних версиях субд от раудевайсов отказались в силу неудобства их обслуживания.
думаю бтр найдёт своё место в http://docs.oracle.com/cd/E11882_01/server.112/e18951/whatsn...

Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

98. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от filosofem (ok), 16-Июн-12, 15:38 
>думаю что следующий шаг - это внесение изменений в саму субд

Я это и говорил, соответственно согласен.
>их архитектуры совместимы настолько, что субд сможет переложить часть функциональности на бтр.

но зачем

>зыж
>и да, лучшие результаты у сбд оракл получаются на раудевайсах (без фс вообще).

Это очевидно.
А у них есть план восстановления после хардверного факапа или внезапного кернел паник, или резета, сравнимый по скорости с журналируемой ФС? ИМХО это большая ошибка исключать такой ход развития событий.
И сам не мерил, но одна бабка сказала, что на ext4 базы данных по производительности приближаются к просто блочному девайсу.

Ответить | Правка | Наверх | Cообщить модератору

102. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от ананим (?), 16-Июн-12, 15:52 
>А у них есть план восстановления после хардверного факапа или внезапного кернел паник, или резета, сравнимый по скорости с журналируемой ФС?

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

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

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

приближается. в общем случае.
но есть но!
на рау-девайсах ты рулишь сам. и если рулишь правильно, то всегда будет на ~20% быстрее.
вот только это совсем уж для простеньких установок. на серьёзных сам же скажешь нафиг-нафиг мне такое ускорение.

Ответить | Правка | Наверх | Cообщить модератору

120. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от Аноним (-), 16-Июн-12, 18:57 
> оракл ведёт редо-логи ещё со времён оно.
> это его фишка, обложенная наверное не одной сотней патенов.

Как же тогда MS в их ESE ведет подобные по смыслу логи?

Ответить | Правка | Наверх | Cообщить модератору

122. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от filosofem (ok), 16-Июн-12, 19:57 
Журналы транзакция вроде бы везде в том или ином виде реализованы, где поддерживается ACID. Плюс у многих write-ahead-log есть.
Я не спорю, потому что с Ораклом мало знаком и не исключаю что там нечто особенное, хотя и сомневаюсь в этом.
Но опять же этот особенно надежный роллбэк-лог должен не лучшим способом на производительности сказываться. Возможно те же 10-20% что и при использовании ext4
Ответить | Правка | Наверх | Cообщить модератору

137. "Обновилась версия нативной реализации файловой системы ZFS д..."  +1 +/
Сообщение от ананим (?), 16-Июн-12, 21:15 
Через задний проход.
Ответить | Правка | К родителю #120 | Наверх | Cообщить модератору

152. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от Аноним (-), 16-Июн-12, 23:02 
> Через задний проход.

А с этим никто и не спорил :). Просто более-менее характерный набор технологий все дружно передрали друг у друга.

Ответить | Правка | Наверх | Cообщить модератору

160. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от ананим (?), 16-Июн-12, 23:17 
да, но мс особенно.

зыж
если вообще кто в теме - один их отказ от кластеров чего стоит! :D
(если возник вопрос при чём тут редолги - том ещё рано говорить о качестве субд ;))

Ответить | Правка | Наверх | Cообщить модератору

164. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от Аноним (-), 16-Июн-12, 23:25 
> да, но мс особенно.

Они были бы не MS если бы хоть что-то делали не так.

> (если возник вопрос при чём тут редолги - том ещё рано говорить
> о качестве субд ;))

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

Ответить | Правка | Наверх | Cообщить модератору

178. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от ананим (?), 16-Июн-12, 23:53 
>синхронизациями транзакций

а синхронизации транзакций идёт через таймпоинты в редологах.


зыж
просьба
>(если возник вопрос при чём тут редологи - тому ещё рано говорить о качестве субд ;))

остаётся в силе ;)

Ответить | Правка | К родителю #164 | Наверх | Cообщить модератору

191. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от Аноним (-), 17-Июн-12, 04:39 
>>(если возник вопрос при чём тут редологи - тому ещё рано говорить о качестве субд ;))
> остаётся в силе ;)

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

Ответить | Правка | К родителю #178 | Наверх | Cообщить модератору

165. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от Аноним (-), 16-Июн-12, 23:26 
> на рау-девайсах ты рулишь сам. и если рулишь правильно, то всегда будет
> на ~20% быстрее.

Ну так оверхед от ФС отпадет окончательно. Логично же.

Ответить | Правка | К родителю #102 | Наверх | Cообщить модератору

179. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от ананим (?), 16-Июн-12, 23:55 
да.
но вырастет оверхед от количества настраиваемых девайсов по экспоненте.
Ответить | Правка | Наверх | Cообщить модератору

190. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от Аноним (-), 17-Июн-12, 04:33 
> но вырастет оверхед от количества настраиваемых девайсов по экспоненте.

Ну я догадываюсь насколько вы хотите админить БД в raw разделах :)

Ответить | Правка | Наверх | Cообщить модератору

166. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от Аноним (-), 16-Июн-12, 23:28 
> я говорил об удобстве обслуживания сотен и тысяч рау-девайсов в кластерах и тд.
> вот где у дба мозК вскепит.

У нас завелся Капитан-дба :)

Ответить | Правка | К родителю #102 | Наверх | Cообщить модератору

129. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от Аноним (-), 16-Июн-12, 20:25 
> И намного быстрее их базы на Btrfs работают, чем на ZFS?

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

Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

25. "Обновилась версия нативной реализации файловой системы ZFS д..."  –1 +/
Сообщение от Аноним (-), 15-Июн-12, 14:19 
а зачем его вообще спонсировать - скинтесь и спонсируйте - что то слишком много халявщиков которые поливают потом Oracle грязью.
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

29. "Обновилась версия нативной реализации файловой системы ZFS д..."  +/
Сообщение от Аноним (-), 15-Июн-12, 15:00 
> такое ощущение что oracle слабо финансирует разработку btrfs

Ну они собственно умно сделали - спонсировали аж целого архитекта. Чувак наархитектил и накодил скелетон, применив ряд вполне здравых идей от комьюнити и прочая. Спонсорство свелось аж к зарплате одного (!!!) Криса Мэйсона.

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру