Крис Мэйсон из компании Oracle представил (https://lkml.org/lkml/2012/3/30/412) большую порцию изменений в файловой системе Btrfs для будущего ядра Linux 3.4. Среди изменений интеграция подготовленных проектом SUSE патчей с улучшением обработки ошибочных ситуаций, которые позволяют файловой системе прерывать ошибочные транзакции и перейти в режим только для чтения. Также отмечается изменение метода взаимодействия метаданных со страничным кэшем, увеличение агрессивности отбрасывания страниц для метаданных, ставших ненужными, и возможность работы с метаданными блоками крупнее страницы, вплоть до 64Кб (наиболее хорошие результаты наблюдаются с блоками в 16 или 32КБ). Код с поддержкой RAID 5 и 6 запланирован для включения в состав ядра 3.5.URL: http://www.phoronix.com/scan.php?page=news_item&px=MTA3OTk
Новость: http://www.opennet.me/opennews/art.shtml?num=33498
> Код с поддержкой RAID 5 и 6 запланирован для включения в состав ядра 3.5.Вот уже совсем скоро, вот уже сейчас у нас будет БТРФС. Осталось совсем чуть, чуть. :)
Btrfs не нужна. Её архитектура чересчур кривая, её уже не изменить. Думаю, свою нишу она займёт, но конкурентом ext4 не будет.
> Btrfs не нужна. Её архитектура чересчур кривая, её уже не изменить. Думаю,
> свою нишу она займёт, но конкурентом ext4 не будет.Она изначально не конкурент ext4. она конкурирует либо с ZTF либо со стеком raid+lvm+ext4
эх конкурентом зфс она не будет альтернативой да.
ZTF - это что?
> ZTF - это что?Гибридная ФС: ZFS + WTF = ZTF :)
> Btrfs не нужна.Вам не нужна - не пользуйтесь. А мне ври пригодитсяю
> Её архитектура чересчур кривая, её уже не изменить.
Ну уж не кривее EXT4, особенно поверх LVM со снапшотами или что там еще.
> Думаю, свою нишу она займёт, но конкурентом ext4 не будет.
Скорее, ext4 ей конкурентом не будет. Одноместный самолет не является конкурентом боингу-767, даже если в какой-то момент времени может доставить вас из точки А в точку Б быстрее.
> Btrfs не нужна. Её архитектура чересчур кривая,Уже который раз прошу внятно обосновать чем именно архитектура крива. В ответ приводится или нытье Шишкина, у которого ФС вообще считай что не работает и в обозримом будущем работать не будет, или просто бред. Ну что за лузерство? Обоснуйте. Сами. Без шишкина. На основе своего понимания предмета, оценив суммарное сочетание параметров и сравнив с существующими реализациями.
p.s. и кто там ныл про метаданные vs данные:
Берем и до упора создаем на ФС диры и файлы 0-го размера. В конечном итоге метаданные выжирают 100% места на томе ибо имена, параметры и иерархию надо где-то хранить. Итого данных на ФС - 0 байтов, метаданных 100% тома. Заметьте, в этой формуле нигде даже тип файловой системы не фигурирует, поэтому приветы шишкину с его наездами. Пусть сперва этот юзкейс к своей ФС применит и расскажет не смущает ли его столь галимое соотношение данных к метаданным в его ФС если он такой умный :)
А разве поддержка RAID добавляется в файловую систему? Причем тут ФС вообще.
Или странная шутка первоапрельская, или я просто не знаю.
БТРФ это как бы клон ЗФС, а в ту запихано все что только можно
БТРФ это как бы клон ЗФС, а в ту запихано все что только нужно. \\fxd
> БТРФ это как бы клон ЗФС, а в ту запихано все что
> только нужно. \\fxdЭто не клон, это исправленная и переработанная версия, с учетом опыта ошибок в архитектуре ZFS.
> с учетом опыта ошибок в архитектуре ZFS.И какие-же архитектурные ошибки ZFS назовет нам анонимное чудило?
>> с учетом опыта ошибок в архитектуре ZFS.
> И какие-же архитектурные ошибки ZFS назовет нам анонимное чудило?Как минимум безумная необходимость во всей системной памяти. ARC можно уменьшать, угу, но пользоваться ей при этом трудно.
> Как минимум безумная необходимость во всей системной памяти.Это чего за бред? Комфортный объем памяти для ZFS обычно грубо прикидывается как "гиг памяти на терабайт хранилища плюс гиг памяти на 50Gb level2arc". А "безумная необходимость во всей системной памяти" - плод фантазии местных дятлов.
> ARC можно уменьшать, угу, но пользоваться ей при этом трудно
Второй бред. У меня есть mysql-ные и оракловые сервера, у которых при 32gb ram-а объем arc-а может опускаться до 1Gb. И они прекрасно работают и не тормозят. ЧЯДНТ?
Два предложения - две бреда. Вполне в местных традициях.
> Второй бред. У меня есть mysql-ные и оракловые сервера, у которых при
> 32gb ram-а объем arc-а может опускаться до 1Gb. И они прекрасно
> работают и не тормозят. ЧЯДНТ?Ага. На солярке, или? Если на солярке - вопрос снят. Если нет - сколько тюнингов вы при этом делали к ZFS?
Не совсем понятна необходимость дублировать системный кеш в ARC. Неужели нельзя было интегрироваться? BTRFS, к примеру, вполне себе юзает системный, и не жужжит.
Почитать сорцы или хотя бы блог Бонвика уже не судьба, не? ARC сильно иначе работает, чем обычный кэш *NIX-подобных осей. Компрене ву?
> Ага. На солярке, или? Если на солярке - вопрос снят.И на солярке и на bsd
Если нет - сколько тюнингов вы при этом делали к ZFS?
это про стабильность или производительность?
если про первое, то в 8.1 и 8.2 существуют рекомендации ограничить сверху arc на
величину расхода памяти ядром и софтом и уменьшить интервал сброса транзакций
на диск, дабы обезопасить от 'kmem too small' но в реальности на
машинах, где это не было сделано у меня проблем не наблюдалось.
в 9.0 и 8.3, на сколько понимаю, и это не нужно. сантехники переделали
write-throttling, а бздюки допилили интеграцию до вменяемого состояния.> Не совсем понятна необходимость дублировать системный кеш в ARC. Неужели нельзя было интегрироваться? BTRFS, к примеру, вполне себе юзает системный, и не жужжит.
сановцы, на сколько я знаю, пошли на это т.к. собирались не ZFS интегрировать в существующую VM а наоборот, VM в ZFS. А бздюкам такое положение дел досталось "по - наследству" и приоритет работ по интеграции, скажем так, невысокий. И еще, системный кеш в ARC не дублируется. Это просто две системы, выполняющие похожие функции. двойной буферизации между ними, кроме некоторых углов таких, как sendfile() нет.
>> И какие-же архитектурные ошибки ZFS назовет нам анонимное чудило?
> Как минимум безумная необходимость во всей системной памяти.Вы предпочитаете, чтобы оперативная память была на 10-20% занята 90% времени всего аптайма, как в традиционных системах хранения? :)
ARC динамически изменяет свой размер, в зависимости от текущих потребностей запущенных и запускаемых приложений, но не может быть меньше 1 ГБ.
> ARC можно уменьшать, угу, но пользоваться ей при этом трудно.
Разве sysctl-переменные трудно подобрать под задачи?
Вот отсюда почитайте: http://forum.ixbt.com/topic.cgi?id=11:43718-47#1338
и до конца обсуждения "тюнинга".
> И какие-же архитектурные ошибки ZFS назовет нам анонимное чудило?Например довольно странную стратегию аллокации блоков класса "ни два ни полтора". Вроде бы блоки уже переменной длины, но слишком мизерные чтобы посчитать это за нормальный экстентный аллокатор. Ну и нафига оно там именно такое?
BTRFS - не только ФС, это ещё и менеджер разделов (дикий комбаин короче)! Не unixway...
это просто у вас нет понимания что такое юникс вей.
Народ ждёт! Что ж такое Unix-way FS?
а ничего, это же не про фс вовсе.Если в принципе можно ФС разделить на части, то это ещё не значит что так нужно делать и это будет хорошо. С ФС пошли немного другим историческим путём - сначала разделили (точнее, когда-то просто не было менеджера томов и вообще нескольких носителей), а с ростом объёмов оказалось что так делать больше не стоит.
"Не нравится -- не ешь!"
> Народ ждёт! Что ж такое Unix-way FS?Судя по ненависти адептов unix-way к бинарному формату - юниксвейная ФС должна представлять собой один большой текстовый файл, непосредственно поверх блочного устройства.
Плюсы: не требуется драйвер, достаточно текстового редактора, следовательно, высокая портабельность.
Минусы: очень неудобно пользоваться, следовательно, практической пользы ноль. Но юниксвей, к счастью для его адептов, ничего не говорит про удобство и практическую пользу.
> BTRFS - не только ФС, это ещё и менеджер разделов (дикий комбаин короче)! Не unixway...Не менеджер разделов, а менеджер томов. Если вы не понимаете в чем отличие, не вам рассуждать о "way-ях" вообще. А чисто технически управление томами из ФС дает ей некие плюсы: ФС в явном виде видит аллокацию места на томах и знает где и что лежит. И поэтому при нужде добавить или убрать том в пул ФС может гибко и быстро перекинуть данные на том или убрать с тома.
Может, не сливать все в один ком, а сделать нормальный интерфейс для взаимодействия между уровнями?
Все-таки модульность и стекируемость дают определенные преимущества: модули можно заменять, подсистемы в стеке - сочетать в различных вариантах.
Именно этим путём и пошёл Рейзер! Но вот жену за что...
Ну жену-то - понятно! Да и про остальное - тож. :)
> Может, не сливать все в один ком, а сделать нормальный интерфейс для взаимодействия между уровнями?Слишком большой оверхед не только на пересчёт и подтверждение контрольных сумм данных, но и на протокол взаимодействия между уровнями. Джэф Бонвик уже показал, что будет, если использовать классический стек программных уровней абстракций и взаимодействий вместо прямой интеграции ФС и менеджера томов.
> Все-таки модульность и стекируемость дают определенные преимущества: модули можно заменять, подсистемы в стеке - сочетать в различных вариантах.
Когда классические ФС отличаются друг от друга только характеристиками алгоритма распределения пространства, не имея особых уникальных фич, то делать под них модульную поддержку не имеет смысла: профита мало, а геморроя с поддержкой много.
Лучше абстрагировать систему хранения в наборы данных (датасеты), которое хранилище может иметь много и разных типов. Например, поддержку виртуальных томов фиксированного размера для всех классических ФС, датасет ФС нефиксированного размера с управляемой сквозной верификацией данных. Со временем может появиться потребность в иных наборах данных, например, датасеты для ротируемого логирования, транзакционной базы данных, отдельный датасет загрузки и восстановления операционной системы и т.д.
> Может, не сливать все в один ком, а сделать нормальный интерфейс для
> взаимодействия между уровнями?Сильно ограничит возможности алгоритмов - сделать generic интерфейс который бы одинаково хорошо бы лег и на "классику", и на "cow-like" и на что там кто еще придумает - не больно какая простая задача. Рейзер думает что можно CoW сделать как плагин? Можно, но тогда он не сможет пользоваться всеми плюсами этой технологии. И получится довольно компромиссный уродец, и еще не факт что менее уродливый в сумме чем btrfs. Понятие уродливости может варьироваться. И не забываем что "свое не пахнет", поэтому заявления что Мэйсона, что Шишкина что Теодора Тсо что прочих воспринимаем и мотаем на ус, но понимая что сами себя они ругать не склонны и могут сделать себе скидку :)
Рейд может быть и на уровне файлов и файловой системы и логических разделов и мсдосовских и блочных устройств. Или я загнул? =)
Имеется ввиду некий внутренный рейд btrfs без использования mdadm и прочего.
конечно есть софтверный рейд. Но они часто не зависят от FS. В общем ладно.
> разделов и мсдосовских и блочных устройств. Или я загнул? =)Да, вы немного загнули. Что есть "мсдосовское устройство" в Linux? :D
Хотя в принципе вы правильно поняли. Например, ничему не противоречит если ФС вон тот файл сложит в 2 копиях на 2 шпинделя, а вон тот менее ценный - только 1 раз, на 1 шпиндель.
> Рейд может быть и на уровне файлов и файловой системы и логических
> разделов и мсдосовских и блочных устройств. Или я загнул? =)
> Имеется ввиду некий внутренный рейд btrfs без использования mdadm и прочего.у меня рейд анонимусов биткоины считает.( и да именно рейд а не кластер)
Нет, бтрфс умеет программно соедржать в одном разделе/диске 2 или более физических носителя
> А разве поддержка RAID добавляется в файловую систему? Причем тут ФС вообще.
> Или странная шутка первоапрельская, или я просто не знаю.Нет, не шутка - в оригинале новость от 30 марта, кажется. А надо это в основном потому что так ФС может гибче решать что и как, например используя разные уровни райда для данных и метаданных. Более того, там динамическое добавление и изъятие томов - штатная фича. Файловой системе виднее что на ней хранится, поэтому она лучше сделает ребалансинг при добавлении тома или убирание данных с тома при его изъятии. Уровни типа LVM таковыми знаниями не обладают, со всеми вытекающими.
Интересная переписка Linus Torvalds (цитата) с Chris Mason:
> Ok, so presumably num_pages (which is "num_extent_pages(eb->start,
> eb->len)") cannot be zero, so I guess the code is ok. But gcc can't
> know that, and it's an annoying warning.Whoops, my reply was too slow, sorry. If you're curious my gcc that
doesn't warn in 4.6.3.
Btrfs - это конечно же хорошо, но очень жаль, что никого не интересует Reiser4, а ведь она гораздо продуманей
Шишкин вроде в нормальных отношениях с разработчиками BTRFS. Поэтому написать ему коллективное письмо с просьбой убедить разработчиков БТРа использовать инновации из Reiser4 в BTRFS2. Коль уж Торвальдсу так не нравится слово "Reiser" в названии ФС.
> Коль уж Торвальдсу так не нравится слово "Reiser" в названии ФС.Про фамилии и личности - это, в общем-то, стеб.
В подобных патчах Торвальдсу всегда не нравится одно и то же: косячность и бесполезность. Даже Шишкину влом допиливать это чудо, а над нормальными фс по несколько разработчиков трудятся на полный день. Да и в чем бонусы reiser4? Там хоть снапшоты-то есть?
Да мне кажется эту возможность можно добавить как плагин, было бы только кому...
Там система позволяет плагины. и это хорошо. при чём в FS плагины на мой взгляд очень хорошо. а вот в компиляторе - неясно зачем.
> а вот в компиляторе - неясно зачем.Под всякие нестандартные загибоны. И да, если падение компилера из-за бага в плагине можно пережить, то вот для файловой системы это уже совсем другой уровень грабель.
>> а вот в компиляторе - неясно зачем.
> Под всякие нестандартные загибоны. И да, если падение компилера из-за бага в
> плагине можно пережить,Да и не в плагине.
> то вот для файловой системы это уже совсем другой уровень грабель.
да и не в плагине
походу слово "плагин" тут лишнее
> Да и не в плагине.А вот это уже как повезет. Прикиньте, вопрос на миллион а тут такой факап. Не больно то приятно переживать, да? :)
>> то вот для файловой системы это уже совсем другой уровень грабель.
> да и не в плагинеИменно. А плагинный интерфейс мало того что усложнит все, так еще и отлаженность плагинов и неизменность интерфейса - под вопросом.
> походу слово "плагин" тут лишнее
Вот поэтому я и думаю - а не оверкилл ли все делать через плагины? Сама ФС тоже в каком-то роде плагин к ядру. Плагин к плагину - не сильно ли круто?
> Плагин к плагину — не сильно ли круто?авторы FUSE смотрят на тебя несколько удивлённо и озадачено.
> Там система позволяет плагины. и это хорошо. при чём в FS плагины на мой взгляд очень хорошо.А эти плагины позволяют сделать снапшоты, cow, сквозное чексуммирование с автоматическим восстановлением из избыточных копий?
и не только это
Хотелось бы, что это было реализовано, а не "позволяли плагины".
> Reiser4, а ведь она гораздо продуманейА в чем это проявляется, если не секрет?
>> Reiser4, а ведь она гораздо продуманей
> А в чем это проявляется, если не секрет?пишут дольше. значит, дольше думали.
> пишут дольше. значит, дольше думали.Тогда реактос должен вообще быть идеальной и безглючной осью :)
> пишут дольше. значит, дольше думали.Есть подозрение, что все эти годы Шишкин думал главным образом не о том, как улучшить reiser4, а о том, что бы такое накодить, чтоб заработать на жизнь. Потому что в разработку reiser4, afaik, никто и никогда бабла не вкладывал.
> чтоб заработать на жизнь. Потому что в разработку reiser4, afaik, никто
> и никогда бабла не вкладывал.Так чтобы в вас вложили бабло - кому-то должно стать понятно что вы - нужны. Именно им. Именно в таком виде. А вот с этим у излишне академствующих господ напряженка.
XFS и первый рейзер (точнее, третий) создали именно "академствующие господа". Шишкин об этом упоминал в интервью
> XFS и первый рейзер (точнее, третий) создали именно "академствующие господа". Шишкин об
> этом упоминал в интервьюАга, и где теперь SGI? Где рейзер я и так знаю. Кстати парни с amule.org громко чертыхались за то что fsck третьего рейзера сделал им из тома полные макароны.
> Ага, и где теперь SGI?SGI больше нет, но их творение их надолго пережило и сейчас успешно развивается. Это разве не показатель?
> SGI больше нет, но их творение их надолго пережило и сейчас успешно
> развивается. Это разве не показатель?Показатель чего? Обычная такая ФС, на уровне всех остальных современных. В свое время очень всех донимала убиением файлов нулями, кстати. Окончательно додавили этот фичебаг в районе 2.6.28 примерно, после чего им даже стало можно пользоваться более-менее.
Загнать XFS в тормоза - не так уж и сложно. В некоторых случаях он сииииильно тупит при работе с метаданными. Например на куче мелочи ext4 его обставляет на раз. В общем SGIшники делали ФС для видеомонтажа. Да, с операциями такого плана, когда многогиговые файлы да еще в несколько потоков писать надо - оно справляется хорошо. А остальное - как повезет.
Ну вот согласен на все 100% с человеком, продуманность архитектуры Reiser4 просто на высоте, не то что там Btrfs...
> Ну вот согласен на все 100% с человеком, продуманность архитектуры Reiser4 просто
> на высоте, не то что там Btrfs...В конечном итоге засчитывается не сам по себе абстрактный полет инженерной мысли в сферическом вакууме, а как оно ездит, летает, плавает, хранит данные и прочая, увы и ах...
> Ну вот согласен на все 100% с человеком, продуманность архитектуры Reiser4 просто
> на высоте, не то что там Btrfs...Судя по отсутствию конкретного ответа - это просто повторение некой мантры, ничего не понимая в архитектурах ФС.
Мэнсон, очевидно, всё понимает в btrfs, раз при определённых условиях она начинает пухнуть от метаданных -- кто бы говорил про архитектуру =) Дурные задумки никакое "допиливание" не исправит
> раз при определённых условиях она начинает пухнуть от метаданныхЧувак, создай у себя на ФС миллионы файлов 0-го размера. И удивись: ты записал 0 байтов полезных данных, а место куда-то схавалось. Наверное, потому что параметры файлов и их имена надо где-то хранить.
Вывод: твоя ФС полный отстой. Ее кпд оказался равен нулю. Хоть я и не знаю какая у тебя ФС, но к ней это 100% применимо. Так своему шишкину и передай.
Некорректно выразился: не за счёт самих метаданных, конечно же, а за счёт дикой внутренней фрагментации, где метаданным тоже места не остаётся:> It is a well known fact that internal fragmentation of classic Bayer's
> B-trees is restricted by the value 0.50 (see Appendix C). However it
> takes place only if your tree contains records of the _same_ length
> (for example, extent pointers). Once you put to your B-tree records
> of variable length (restricted only by leaf size, like btrfs "inline
> extents"), your tree LOSES this boundaryВнимательно почитайте и вдумайтесь, на что Шишкин ругается, перед своим следующим сочинением
Повторюсь: дефектный дизайн никаким допиливанием не исправить
Продумана с т.н. академической точки зрения, т.е. для юз.кейсов родившихся в чей-то фантазийной головое и далёких от реальных потребностей.
проблема не втом что она "не нужна". Она как раз таки очень даже нужна. Но в ядро её принимать почему-то не хотят. Хотя я даже слышал, что рейзер4 стабильней нынешней бтрфс.
> проблема не втом что она "не нужна". Она как раз таки очень
> даже нужна. Но в ядро её принимать почему-то не хотят. Хотя
> я даже слышал, что рейзер4 стабильней нынешней бтрфс.а чего тогда эти, которым нужна, не запилили ФС до требуемого для приема уровня и не подписались на длительную поддержку своего творения в ядре?
Не сумели найти общий язык с разработчиками ядра. Конкретную причину сложно указать, но весьма вероятно, что это чистая политика и взаимоотношения, а не техническая реализация
Вдогонку. Вспомнил, Шишкин указывал, что, например, рейзер4 не принимали в ядро из-за наличия в ней менеджера томов - дескать, у нас уже есть LVM, так что используй его. Хотя той же btrfs с ее собственным менеджером томов дан зеленый свет.
Нет, там в основном все наезды были реализацию всего через на плагины и сильное изменение семантики vfs.
В btrfs таких вещей меньше.А так, наверное да интересно было бы увидеть WAFL вместо vfs...
> проблема не втом что она "не нужна". Она как раз таки очень
> даже нужна. Но в ядро её принимать почему-то не хотят.Апстрим и даунстрим не нашли общего языка и не пришли к взаимопониманию. Вообще, рейзер - традиционная для академиков вещь. Т.е. задумано вроде бы круто с академической точки зрения, а с практической - у рейзера3 fsck до сих пор может том окончательно угробить вместо починки, чинить это никто не собирается, etc - по сути сказали что "known issue" и ... все.
Я же написал про Reiser4, а это совсем иная файловая система чем Reiser 3
> Я же написал про Reiser4, а это совсем иная файловая система чем
> Reiser 3Но отношение Райзера к стабильности и ценности данных этот пример неплохо иллюстрирует.
> Я же написал про Reiser4, а это совсем иная файловая система чем Reiser 3ФС другая, а авторы те же самые. Где на этот раз они так же продолбутся? Что, на reiser3 томе нельзя хранить образа иных томов в reiser3 иначе fsck может "починить" фс в полные макароны? А им не кажется что добавить safeguards против таких факапов - не настолько уж и ракетная наука? Хотя конечно забавнее рассказывать о том что это ограничение ФС, а то что том при запуске fsck убился в вермишель - by design. Знаете, а мне вот ссыкотно такой by design использовать с такими known issues, даже если он и крут чисто академически...
> Хотя я даже слышалСлухи, скандалы, расследования.
Зыж
Пол-разработчика вас на это натолкнуло?
Который сам не знает бу или не бу что-то там с ней делать.
> проблема не втом что она "не нужна". Она как раз таки очень
> даже нужна. Но в ядро её принимать почему-то не хотят. Хотя
> я даже слышал, что рейзер4 стабильней нынешней бтрфс.В ядро ее не хотят принимать по очевидной причине - проблем со стабильностью полные штаны, бонусов ноль.
Проблемы со стабильностью бывают как раз, когда не хватает разработчиков и тестеров, когда проектом никто не занимается. btrfs тоже, поди, немного умела сразу после своего появления на свет, но ее приняли в ядро довольно давно, несмотря на нестабильность
А 1.0 или хотя бы замарозка формата и фич когда планируется? :) Какие-нить планы есть по датам? Короче объясните когда его считать стабильым истоит ли вообще ждать это в ближайшем будущем :)
Предположительный ответ:
1, 2 - ASAP
3 - нет, ASAP
> истоит ли вообще ждать это в ближайшем будущем :)Зависит от того что понимать под ближайшим будущим :). Если завтра - нет, завтра оно готово еще не будет. Если через 1-2 годка - думаю что окончательно устаканится как раз.