The OpenNET Project / Index page

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



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

Оглавление

Состояние развития ZFSonLinux и готовность проекта к повсеме..., opennews (?), 11-Сен-14, (0) [смотреть все]

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


12. "Состояние развития ZFSonLinux и готовность проекта к повсеме..."  +4 +/
Сообщение от Nixman (?), 12-Сен-14, 00:02 
бтэр рулит и педалит не требуя огромных ресурсов памяти и проца.
Ответить | Правка | Наверх | Cообщить модератору

36. "Состояние развития ZFSonLinux и готовность проекта к повсеме..."  +/
Сообщение от Аноним (-), 12-Сен-14, 08:18 
> бтэр рулит и педалит не требуя огромных ресурсов памяти и проца.

А также имеет потенциал для более шустрой работы. Экстенты - изначально есть, при том не обрубочные а нормальные. Наиболее тормозные места - изрядно оптимизнули в последних ядрах. В последних ядрах на глаз btrfs вообще сложно от ext4 отличить при обычном десктопном юзеже. У CoW разумеется есть слабые места. Как впрочем и у любых иных подходов. В целом симпатичненько так работает. Я его от EXT4 правда на глаз при сильном желании отличу, но не по скорости работы а по иному миганию индикатора HDD :)

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

45. "Состояние развития ZFSonLinux и готовность проекта к повсеме..."  +/
Сообщение от iZEN (ok), 12-Сен-14, 09:24 
Я слышал, что в некоторых случаях Btrfs требует процедуры ребалансинга. Ну, когда для виртуального тома места не хватает в полупустом пуле... Это так?
Ответить | Правка | Наверх | Cообщить модератору

49. "Состояние развития ZFSonLinux и готовность проекта к повсеме..."  –2 +/
Сообщение от ананим (?), 12-Сен-14, 09:40 
Нет.
Потому что там нет таких понятий как "виртуальный том" и "полупустой пул".
Ответить | Правка | Наверх | Cообщить модератору

64. "Состояние развития ZFSonLinux и готовность проекта к повсеме..."  –1 +/
Сообщение от Аноним (-), 12-Сен-14, 11:26 
В какой версии? У меня на 3.13 при работе графита - забивалось все место под данные, под метаданные ничего не оставалось. При этом места дофига (больше двух третей) свободно, но так как все зарезервировано под данные - файлы уже не записать.
Ответить | Правка | Наверх | Cообщить модератору

86. "Состояние развития ZFSonLinux и готовность проекта к повсеме..."  +/
Сообщение от Аноним (-), 12-Сен-14, 18:39 
> В какой версии? У меня на 3.13 при работе графита - забивалось
> все место под данные, под метаданные ничего не оставалось.

Это не вы тот чудак который базу с активной записью на CoW положил? Я расписал более-менее причины в другом треде, если это вы - https://www.opennet.ru/openforum/vsluhforumID3/98299.html#591 - правда мне все-равно не понятно почему GC не успевает чистить. База настолько убер-активная?

> При этом места дофига (больше двух третей) свободно, но так как все зарезервировано
> под данные - файлы уже не записать.

Там нет никакого "резерва под данные". Но сделать ФС без единого файла на которой нет места - можно. Достаточно сделать хотя-бы 1 снапшот и отрастить дельту от него побольше. В результате место уйдет на хранение снапшотов и отличий текущего вида от снапшотов :).

Да, "лабиринт отражений" требует неких ресурсов на свое существование - разные состояния не берутся из ниоткуда и хранение состояний и отличий очень даже занимает место. Эти же грабли характерны для виртуалок со снапшотами - их CoW based диски при безбашенном использовани могут достигнуть терабайтных величин при свободном месте порядка нескольких гигабайтов. Такая вот особенность технологий со множественными состояниями. Btrfs еще и на автомате временные снапшоты лепит, а потом убивает GCом, если не зафиксировать на постоянно. По поводу чего базы с множеством мелких записей такой механике не друг. Но есть chattr +C, позволяющий это пролечить (читайте маны, есть особенности).

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

98. "Состояние развития ZFSonLinux и готовность проекта к повсеме..."  +/
Сообщение от Аноним (-), 12-Сен-14, 20:34 
Ничего что запись файлов графита - этот тот самый случай, где cow мог бы проявить себя с лучшей стороны? Не говоря уже о том, что без Cow - BTRFS вообще все свои навороты теряет (контрольные суммы, компрессия...). Кстати, мне удалось добиться от BTRFS работы с графитом, отформатировал в mixed mode. Но там другие засады.
Ответить | Правка | Наверх | Cообщить модератору

111. "Состояние развития ZFSonLinux и готовность проекта к повсеме..."  +/
Сообщение от Аноним (-), 13-Сен-14, 01:51 
> Ничего что запись файлов графита - этот тот самый случай, где cow
> мог бы проявить себя с лучшей стороны?

CoW склонен к фрагментации, если ворклоад выглядит как множество частых мелких записей в файлы, особенно если файл патчится in place и/или часто дописывается. Работает CoW так. Любое изменение = выносок в сторону, старые данные не разрушаются и по прежнему доступны, что и позволяет просто и естественно ворочать множественными состояниями. Если выносков много, последовательное чтение будет тормозить. Куча выносков размазанных по всему диску -  не айс, особенно на механике. Фрагментация подскочит до небес, а GC будет весьма неспешно работать.

Наверное в клиническом случае может так выйти что GC вообще не будет успевать вытирать устаревший крап и место закончится. Но в этом случае проще CoW для проблемного файла или диры отключить, раз ворклоад настолько недружественный и интенсивный. Или вы просто положили btrfs на диск мизерного размера, на что он не оптимизирован по дефолту. Я не в курсе что за графит такой, но у вас скорее всего что-то из того что в https://btrfs.wiki.kernel.org/index.php/FAQ#Help.21_Btrfs_cl...

> Не говоря уже о том, что без Cow - BTRFS вообще все свои навороты теряет
> (контрольные суммы, компрессия...).

Базы данных и диски VM обычно сами реализуют некислые схемы журналирования и т.п.. Относится ли это к этому вашему графиту - я честно говоря не знаю.

> Кстати, мне удалось добиться от BTRFS работы с графитом, отформатировал в mixed mode.

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

> Но там другие засады.

Например какие? Я так сходу знаю 1: любители btrfs должны любить свежие ядра. Свежие - это последняя версия (по мнению kernel.org). Даже в 3.17 например будет починен 1 редкий но меткий баг - зависон при активной работе с компрессоваными данными, посажен в районе 3.14, при переводе фоновых работ на ядерные очереди с местечкового велосипеда.

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

149. "Состояние развития ZFSonLinux и готовность проекта к повсеме..."  +/
Сообщение от Аноним (-), 15-Сен-14, 12:19 
На фрагментацию как раз покласть - графиту нужнее успеть записать все метрики. Которые пишутся каждая в свой файл (что без CoW-а и журнала - приводит к случайному дерганью дисков постоянно). Whisper никакого журнала не делает, так что идеальная задача для CoW. А Вы ее отключать советуете... Умно!

Размер - от нескольких десятков мегабайт (в сжатом виде, для уменьшения дисковых операций), до пары террабайт. Да, приходится в mixed mode, иначе смерть через несколько дней от этого самого no space left.

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

52. "Состояние развития ZFSonLinux и готовность проекта к повсеме..."  +/
Сообщение от Andrey Mitrofanov (?), 12-Сен-14, 09:46 
> Я слышал, что в некоторых случаях Btrfs требует процедуры ребалансинга. Ну, когда
> для виртуального тома места не хватает в полупустом пуле... Это так?

Да, так же, как на твоей ZFS "в некоторых случаях" требуется $скока-скока-? гигабайт для _установки.

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

99. "Состояние развития ZFSonLinux и готовность проекта к повсеме..."  –2 +/
Сообщение от iZEN (ok), 12-Сен-14, 20:37 
> Да, так же, как на твоей ZFS "в некоторых случаях" требуется $скока-скока-?
> гигабайт для _установки.

Для функционирования ZFS нужно от четырёх гигабайт ОЗУ и 64-битная ОС.

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

102. "Состояние развития ZFSonLinux и готовность проекта к повсеме..."  –2 +/
Сообщение от bOOsteremail (?), 12-Сен-14, 22:30 
Все настраивается, ZFS очень компромиссная ФС. В отличии от многих радикальных.
Ответить | Правка | Наверх | Cообщить модератору

124. "Состояние развития ZFSonLinux и готовность проекта к повсеме..."  +1 +/
Сообщение от Аноним (-), 13-Сен-14, 06:04 
> Все настраивается, ZFS очень компромиссная ФС. В отличии от многих радикальных.

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

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

128. "Состояние развития ZFSonLinux и готовность проекта к повсеме..."  –3 +/
Сообщение от bOOsteremail (?), 13-Сен-14, 10:38 
>> Все настраивается, ZFS очень компромиссная ФС. В отличии от многих радикальных.
> Да, все настраивается, только tradeoff - выбор между дикими тормозами странной механики
> и конским потреблением памяти.

Может ты успокоишься уже? Ты в этой теме столько наболтал, что собрав твои сообщения в общем четко понятно, что ты ничерта в ZFS не понимаешь. Однажды, случайно, установив ZFS, натыкав галочки в GUI по умолчанию, получив хлам сейчас сидишь и гадишь в сторону ZFS. А ZFS не для лохов. Там понимать надо, что ты делаешь и для чего.

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

134. "Состояние развития ZFSonLinux и готовность проекта к повсеме..."  +/
Сообщение от Аноним (-), 13-Сен-14, 18:23 
> твои сообщения в общем четко понятно, что ты ничерта в ZFS
> не понимаешь. Однажды, случайно, установив ZFS, натыкав галочки в GUI по
> умолчанию, получив хлам сейчас сидишь и гадишь в сторону ZFS.

Прикольные аргументы с попыткой выдать желаемое за действительное. Только это не так. Я посмотрел на сорцы + устройство дисковых структур. На мнения тех кто занимается разработкой и изучением файловых систем. На коменты разработчиков. В сумме я подофигел от увиденного. Потому что видим мы огромный сложный пепелац с довольно странным устройством, где даже сами разработчики в половине мест не могут сказать "а зачем это было сделано вот так?". А половина вполне имеющих место быть проблем - просто заметены под ковер саночными маркетологами. Подленько и цинично.

> А ZFS не для лохов.

Да, отправь СМСку с текстом "Не лох!!!" на короткий номер. Ведь чем больше смс ты отправишь - тем больше ты не лох.

> Там понимать надо, что ты делаешь и для чего.

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

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

108. "Состояние развития ZFSonLinux и готовность проекта к повсеме..."  +/
Сообщение от fidaj (ok), 12-Сен-14, 22:57 
п%ж и провокация
http://docs.oracle.com/cd/E26502_01/html/E29007/gbgxg.html#s...

http://download.oracle.com/docs/cd/E19253-01/820-0836/820-08...
"Требования и рекомендации по программному
обеспечению и оборудованию ZFS
Убедитесь в том, что перед использованием программного обеспечения ZFS были
выполнены следующие требования и рекомендации по программному обеспечению и
оборудованию:
■ Система SPARC® или x86 под управлением выпуска Solaris 10 6/06 или более позднего.
■ Минимальная емкость диска – 128 МБ. Минимальный размер дискового
пространства для пула устройств хранения данных составляет около 64 МБ.
■ В настоящее время минимальный объем памяти, рекомендуемый для установки
системы Solaris, составляет 768 МБ. Однако для обеспечения высокой
производительности ZFS рекомендуется по крайней мере 1 ГБ памяти или более.
■ При создании зеркальной настройки дисков рекомендуется использовать несколько
контроллеров."

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

109. "Состояние развития ZFSonLinux и готовность проекта к повсеме..."  –1 +/
Сообщение от bOOsteremail (?), 12-Сен-14, 23:08 
>[оверквотинг удален]
> оборудованию:
> ■ Система SPARC® или x86 под управлением выпуска Solaris 10 6/06 или
> более позднего.
> ■ Минимальная емкость диска – 128 МБ. Минимальный размер дискового
> пространства для пула устройств хранения данных составляет около 64 МБ.
> ■ В настоящее время минимальный объем памяти, рекомендуемый для установки
> системы Solaris, составляет 768 МБ. Однако для обеспечения высокой
> производительности ZFS рекомендуется по крайней мере 1 ГБ памяти или более.
> ■ При создании зеркальной настройки дисков рекомендуется использовать несколько
> контроллеров."

Да?  А может Ораклу надо продать подороже?

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

133. "Состояние развития ZFSonLinux и готовность проекта к повсеме..."  +/
Сообщение от Аноним (-), 13-Сен-14, 17:26 
Беда... У меня на файлсервере (софтрейд, бакула, домен и еще че-то) 1ГБ ОЗУ и 32битная ОС из которых занято может 200МБ в активном режиме. Если захочу просто какой-нить дедупликации по ночам и версионности, то не потянет чтоль?
Ответить | Правка | К родителю #99 | Наверх | Cообщить модератору

83. "Состояние развития ZFSonLinux и готовность проекта к повсеме..."  +1 +/
Сообщение от Аноним (-), 12-Сен-14, 17:34 
> Я слышал, что в некоторых случаях Btrfs требует процедуры ребалансинга.

В некоторых - требует.

> Ну, когда для виртуального тома

В btrfs нет таких понятий.

> места не хватает в полупустом пуле... Это так?

Нет, не так. Ты опять где-то начитался какой-то бредятины и нифига не понялю


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

101. "Состояние развития ZFSonLinux и готовность проекта к повсеме..."  –1 +/
Сообщение от iZEN (ok), 12-Сен-14, 20:46 
>> Я слышал, что в некоторых случаях Btrfs требует процедуры ребалансинга.
> В некоторых - требует.

Конкретизируй, в каких?

>> Ну, когда для виртуального тома
> В btrfs нет таких понятий.

Подтома, subvolume.

>> места не хватает в полупустом пуле... Это так?

Места для новых метаданных не было зарезервировано - нельзя создать подтом.

> Нет, не так. Ты опять где-то начитался какой-то бредятины и нифига не
> понялю

Ну а зачем ты в теме про ZFS пишешь про Btrfs?


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

112. "Состояние развития ZFSonLinux и готовность проекта к повсеме..."  +/
Сообщение от Аноним (-), 13-Сен-14, 02:45 
> Конкретизируй, в каких?

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

Возможен также реверсный балансу процесс: можно запросить изъятие диска из пула, при этом будет проход по back references - блоки с указанного диска будут убраны на другие диски, если там есть достаточно места. После этого диск не будет содержать ни 1 блока данных и метаданных и его можно безболезненно изъять из пула. Свободное место доступное btrfs в пуле сократится на размер изъятого диска, что логично. А в ZFS штатно backrefs нет и поэтому удвинуть "вот эти блоки с вот этого диска" простыми и очевидными методами - вообще опаньки, т.к. нет простого метода понять к кому они относились и пометить перемещение, чтобы блоки искали в новом месте. Я так понимаю что человеческого изъятия диска из пула в ZFS до сих пор нет? (не очень понимаю как это можно культурно делать при дисковой механике где это заранее не предусмотрели)

Вообще, https://btrfs.wiki.kernel.org/index.php/FAQ#What_does_.22bal...

Там же рядом рассказано почему все так сложно с свободным местом ;). Даже сами разработчики согласны с тем что это не круто, но - вы готовы предложить алгоритм, готовый столкнуться с пообъектным RAID-ом? Заранее неизвестно какой RAID для какого объекта могут попросить, что доставляет.

>  Подтома, subvolume.

А, ты про них. Там скорее проблема в мелком стораже - дефолты btrfs не заточены на всякие карты памяти в пару гигз. Для любителей утонченных извращений сделали mixed mode который не страдает от гранулярности выделения чанков на данные/метаданные. Но все это актуально для мизерных носителей, когда гранулярность аллокации чанков сравнима с размером носителя. Актуально при размерах всей ФС порядка несколько Гб. На более крупных ФС оно по идее и без этого должно быть в более-менее нормальном состоянии с точностью до крох, которые мало что решают.

> Места для новых метаданных не было зарезервировано - нельзя создать подтом.

Ты думается не о том, а о выделении чанков на данные/метаданные, на мелком носителе гранулярность выделения может быть сравнима с размером носителя и может выйти дурная ситуация когда все чанки с данными или метаданными заняты, а противоположных типов чанков не хватило и вроде как места еще немного есть, но создать файл не выйдет из-за невозможности записать данные или метаданные. Но это актуально только для мелких носителей. Для больших носителей (на что btrfs в основном и заточен) - неточность в стыковке размера данных и метаданных будет в пределах погрешности.

А подтома в btrfs штука своеобразная. Это некая административная единица, подддерево которое может иметь ряд настроек отличных от остальных и ведет себя как отдельная независимая точка входа в новую ФС, по типу "/" в плане следования иерархии, снапшотирования и прочее. Но все эти "новые ФС" шарят на все и всяя пространство единого глобального пула свободного места.

> Ну а зачем ты в теме про ZFS пишешь про Btrfs?

Это не я начал. А пишу потому что анноит читать тормозизмы и/или явную дезу.

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

84. "Состояние развития ZFSonLinux и готовность проекта к повсеме..."  –1 +/
Сообщение от anonymousZ (?), 12-Сен-14, 17:54 

Не знаю что он там рулит и педалит, у него элементарные проблемы со стабильностью (на нестабильно работающих/сыплющихся дисках несколько раз получал невосстанавливаемый волюм).
На реальных системах с высоким в/в его просто невозможно использовать. И это после 7-и лет разработки...
Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

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

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




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

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