Эдуард Шишки и «B-Tree - устарело». Почему?

Вы рассчитываете на то, что Эдуард Шишкин отирается на лоре?

Шишкин - ЧСВшный болтун. Вещает «вы все идиоты и не лечитесь, а я вот-вот вам всем покажу, как надо ФС делать!» уже который год.

Болтун или нет, но btrfs гогно.

Пользовался ею, проблем не было.

А ценные мнения всяких теоретиков типа Шишкина я на своей шишке вертел)

В btrfs чтобы удалить данные надо иметь свободное место. Как они додумались до такого технического решения? Обычно же удаляешь данные когда у тебя место заканчивается. А так придется копировать все эти данные с раздела и пересоздавать раздел заново. Так что не удивлюсь что там они ещё ещё идиотские решения использовали, как Шишкин говорит.

До поры до времени

В btrfs чтобы удалить данные надо иметь свободное место. Как они додумались до такого технического решения?

Это особенность такого типа ФС.

Так что не удивлюсь что там они ещё ещё идиотские решения использовали, как Шишкин говорит.

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

Это особенность такого типа ФС.

Тогда укажите это в названии. Или хотябы в описании. Есть же специальные FS которые вообще только readonly, там удаление данные не предусмотрено в принципе и это у них указано в описании.

А идиотское решение, что ФС специально не резервирует место для этого

Точно! Та же Ext4 резервирует место для пользователя root по-умолчанию и все норм.

Я пользовался ей года три или четыре, точно не помню. Использовал сжатие, снапшоты, send/receive. Были жёсткие резеты. Всё было ок.

Потом перешёл на Манжару и пропала надобность в снапшотах перед каждым апдейтом. Ну я и переехал на ext4. Потом как-то раз снова попробовал перевести корень на Btrfs, подумал что быстрее будет. Но оказалось, что не быстрее, так что вернул ext4.

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

Есть же специальные FS которые вообще только readonly

То есть они всегда пустые? 😁

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

подумал что быстрее будет. Но оказалось, что не быстрее…

Использовал сжатие

Наверно все же быстрее (я про чтение), но на SSD это вряд ли заметно на глаз. А вот ресурс должно экономить.

Не, я исходил из непонятно откуда взявшейся мысли, что btrfs, как более современная ФС, более многопоточна и как следствие - работает быстрее на многоядерных ЦП и SSD. Тогда как ext4 в сути своей имеет очень старую архитектуру.

Оказалось, это чепуха - ext4 быстрее, чем btrfs.

btrfs, как более современная ФС, более многопоточна и как следствие - работает быстрее на многоядерных ЦП и SSD.

Я наверно ничего нового не скажу, но озвучу это. То что что что-то старое обычно означает что у людей было больше времени допилить это до рабочего состояния, больше времени чтобы исправить ошибки. Больше времени на все. Конечно это не так, если это долго не разрабатывалось, например minix. Но к ext4 это явно не относится.

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

Это логика настолько часто работает, что люди фиксят баги движка в Обливионе, Морровинде и Скайриме где у них даже нет доступа к исходникам. Вот представь себе.

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

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

если это старое кому-то интересно

Вот это ключевой момент, по-моему. Один только возраст сущности мало что решает. Плюс ещё играет роль сложность процесса сопровождения. Может показаться, что патчить игру через ассемблер это сложно, но в действительности это куда проще, чем влезть в мантейнеры ядра Linux и постоянно допиливать ФС под меняющееся API. Пусть даже при наличии исходников.

На ЛОР существует традиция вместо слов автора обсуждать личность автора. Поэтому, ничего не обсуждая, я просто оставлю тут ссылку на посты в LKML где Шишкин пишет про b-tree и btrfs.

https://lkml.org/lkml/2010/6/3/313

https://lkml.org/lkml/2010/6/18/144

Если ты не видишь проблем с надежностью btrfs и меняешь ее фичи на ext4 ТОЛЬКО из-за скорости, то тебе стоит использовать xfs – она на многих кейсах гораздо быстрее ext4:

https://www.phoronix.com/review/linux-58-filesystems

XFS у меня используется на 2-терабайтном ssd, где фильмы лежат и всякое такое файло. Не могу сказать, что вижу какую-то разницу в скорости с ext4.

Заинтересовало выказывание (или наброс) Эдуарда о том, что «B+-Tree - устарело» (мог напутать точный вид структуры данных).

То есть даже так. Тогда ответ будет: да (могу напутать).

Болтун или нет, но btrfs гогно.

Пользовался ею, проблем не было.

Тогда перефразируем: btrfs ныне уже допиленное гогно. Разные люди будут обращать преимущественное внимание на разные части данного утверждения.

Отрыв в запуске приложений интересен. Попробовать, что ли, навернуть xfs на корень)

Не могу сказать, что вижу какую-то разницу в скорости с ext4.

Так и с btrfs vs. ext4 ты ее не увидишь, все эти проценты почти невозможно заметить, только в бенчмарках.

Потом перешёл на Манжару и пропала надобность в снапшотах перед каждым апдейтом.

То есть эта ФС для глючных дистров? Хорошо придумано, молодцы разрабы 👍.

Это особенность такого типа ФС.

какого именно типа? Я про такое говно только в btrfs знаю. Ни zfs, ни какие-то другие этим не страдают.

Потому что SSD.

Так ведь оно тоже любит блоки и последовательные сканы.

Но переход на потомка сильно дешевле.

Но переход на потомка сильно дешевле.

Не понял. Где дешевле? На потомка чего? Какой переход…

ну, фыр, Б-3 ж оптимизирует количество операций произвольного ввода-вывода в ущерб нагрузке на процессор.

Потому что к изначальному b-tree прикрутили уже достаточное количество костылей и результат можно считать отдельными типами деревьев.

В случае с B+-tree, процессор операций будет делать как минимум столько же как при, например, поиске тех же данных в бинарном дереве поиска. Если B+-tree заменить на бинарное дерево поиска и считывать каждую ноду бинарного дерева поиска с диска, увеличив число операций доступа к диску, то число сравнений в проце как минимум не уменьшится. В случае с B+-Tree эффективнее будет юзаться кеш в проце на последних итерациях бинпоиска в блоке или вообще можно попробовать что-то выразить через SIMD в блоке… При работе с блоками B+-Tree в памяти совокупно всяких операций проц проделает меньше. Будет меньше уходов в ожидание данных из памяти, больше шансов намутить хороший потоковый префетч из памяти в проц, да и просто меньше переключений контекста а реальной жизни.

ты точно не ЖПТ? >_>
Вроде написано всё правильно, но непонятно, зачем.

А вот ресурс должно экономить.

В теории да, а по факту - нет https://habr.com/ru/articles/476414/ Суть в том, что у бтрфс огромное усиление записи по сравнению с теми же ext4 и xfs. Это также скажется на быстродействии при работе на блинах.

усиление записи

Что это?

Когда ты исправляешь в файлике одно -ться, а на диск после этого льётся мегабайт.

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

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

Так вот у разных файловых систем накладные расходы разнятся. У некоторых даже очень. Например по ссылке товарищ вручную записал 2 байта на диск, а фактически записалось 3 мегабайта. Причём я повторял его эксперименты и у меня были похожие результаты.

Утолщу намёк: не нужно придумывать негодную терминологию.

Ну а как вашблагородие переведет write amplification?

Утолщу намёк: не нужно придумывать негодную терминологию.

Оно придумано давно: write amplification. Данный термин давно юзается в статьях про алгоритмы хранения данных во внешней памяти (диски там всякие). Означает насколько больше на диск будет записываться физически в сравнении с тем, что хотел записать юзер. Если на каждые изменённые 32 байта на диск нужно будет скинуть 4 КБ, то write amplification будет конским и примерно равен 4096/32.

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

Буквально и означает «усиление записи». Твой алгоритм усилил запись в сравнении с изначально задуманной, это плохо. Усиливать запись на пустом месте вредно и тупо.

Оно придумано давно: write amplification

Конечно. Но «усиление записи» совсем недавно.

Один хер, языки просто разные.

стоит использовать xfs

Может конечно много чего изменилось, но xfs была одной из моих первых ФС на линуксе, и сбежал я с неё, когда она мне угробила весь раздел с невозможностью восстановления(хотя, допускаю, что я тогда не умел восстанавливать как надо), от простого отключения света. С тех пор обхожу её стороной.

На ЛОР существует традиция вместо слов автора обсуждать личность автора

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

Даже у btrfs практические внедрения есть, плюсы/минусы/нюансы известны, работа идёт. Короче, есть накопленный практический опыт. У Эдуарда есть куча пафосных реляций, а вот поторогать руками - только с высочайшего дозволения, на правильном железе, в правильной позе и фазе луны. А где для работы что-то практическое? За что-то же Хуавей зарплату ему платит.

Заинтересовало выказывание (или наброс) Эдуарда о том, что «B+-Tree - устарело»

Если он его не обосновал, то ты уже всё что тебе нужно знаешь и о высказывании, и об Эдуарде.