Влияние notail в reisrefs

как перестанут допиливать, потому что всё будет просто работать

В reiserfs до сих пор нерешённые тормоза с большими директориями. Размазывание метаданных по диску сейчас вообще абсурдное решение, не учитывающее никем не отключаемый read-ahead. Какая-то бредятина с двумя версиями ключей; бредятина с настройками журнала. Это всё не правится не потому что всё уже сделано, просто туда страшно лезть — вдруг поломается то, что хотя бы работает.

сейчас она очень сильно изменилась

А от 12309 она до сих пор не избавилась при активной дисковой загрузке.
У меня есть радикально простой тест - распаковать stage3 на свежий раздел. И btrfs его стабильно проваливает с жесточайшими тормозами.

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

А в 3.16 его вообще загадили: http://bugzilla.kernel.org/show_bug.cgi?id=83121

2,5 месяца это время, которое 480 машин пользователей не требовали вообще внимания, после чего у нас колл директора поделили, бабло распиливают...

А в 3.16 его вообще загадили

Последствия того самого недавнего рефакторинга.

ты уж определись, машины пользователей или инфраструктура?

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

У меня есть радикально простой тест - распаковать stage3 на свежий раздел. И btrfs его стабильно проваливает с жесточайшими тормозами.

На харде, небось? у меня на старом ssd запись при распаковке стейджа идёт на 5-10 мб/сек медленнее максимальной скорости этого самого ssd

Естественно на харде.
На SSD тестировать не айс.

они всего были год, потом у нас делёжка власти началась, так бы и дальше всё было.

а на хардах CoW-ФС будут, естественно, тормозить просто в силу архитектурных особенностей

В reiserfs до сих пор нерешённые тормоза с большими директориями

Вот, как раз одна из хреней, которая в ext4 бесит. Стоит в каталог записать десяток-другой тысяч файлов, как потом, даже после их удаления, зайти в этот, уже пустой каталог (mc, после сброса кешей) становится процессом с тормозами на десяток секунд. Бесит ужасно. Приходится удалять каталог и создавать заново.

А просто большое количество файлов — вот сейчас в reiserfs создал каталог на 100 тыс. файлов. Заходит в него в mc за секунду и с resiersf, и с ext4. Правда, создание под reisrefs заняло 14 секунд, под ext4 — 17 секунд, а удаление — наоборот, не в пользу reisrefs, 7 секунд против 1.4 сек. Но это я и по тяжёлым тестам помню, что ext4 чемпион по удалению... Так что там, где удалять нужно часто, да, ext4 рулит.

у меня на btrfs было 480 машин

опять пиз%%шь и цифры с потолка, а ведь ещё недавно пел про то как перевёл один сервак и пока норм.

В августе полностью перешёл на ext4 на всех компьютерах. Зависания пропали, и, как ни странно, КДЕ стало грузиться быстрее, особенно nepomuk.

На малопоточном чтении из небольшого числа каталогов (что и происходит при загрузки системы/софта) ext4 рулит. Я сам на неё перешёл в конце 2009-го.

Но у меня случай многопоточного чтения мелких файлов, сильно размазанных по огромному числу каталогов. И тут ext4 ведёт себя паршиво. А вот reiserfs — неожиданно (если ориентироваться на тесты) хорошо. Вот, первый раз год назад в такой ситуации попробовал вернуться на reiserfs: http://www.balancer.ru/g/p3175752

В топикстартовом случае так чётко увидеть результат не получится, поскольку я кроме перехода на reisrefs ещё серию изменений сделал, но субъективно работа на диске с кучей мелочи стала проходить намного шустрее. Операции, на которых ext4 затыкалась на десяток секунд, сейчас проходят за секунду. Где затыкалась на секунду, сейчас отрабатывает мгновенно. Включение каталога кешей через btsync подвешивала последний на минуту, а потом десяток-другой минут всё тормозило, пока шла индексация. Сейчас включение каталога завешивает btsync на десяток секунд, а последующая индексация на работу системы не влияет.

А в 3.16 его вообще загадили

Значит, пока продолжу оставаться на 3.12 :)

А в 3.14 как с этим? А то я Gentoo-сервер приготовил к обновлению до 3.14.14, но пока давно не перезагружал. Под Ubuntu проще, до следующей LTS можно спокойно сидеть на 3.13 :)

сервак 1, а пользователи все практически.

у меня калька 3.16, никаких проблем, стоит на btrfs.

Ты смотри на контекст, в который отвечаешь.

А в 3.14 как с этим?

Так же, как и в 3.12. Т.е. коррапшнов нет, но дедлок, появившийся в reiserfs после того, как выкинули big kernel lock, никто не отменял. Я к тому, что за reiserfs в ядре никто не отвечает. А потому твои грёзы о её рок-стабилити носят больше ностальгический характер.

здорово причесали

4.2 :) А вообще да, поддерживаю, но R4 по экспериментальности оставляет btrfs далеко позади.

Кстати, прозрачная компрессия довольно странно сделана. Решение о включении/отключении компрессии принимается исходя из сжимаемости первого кластера (64K), и если ФС решает включить компрессию — весь файл хранится в дереве. И это ппц: тридцатимегабайтный файлик удаляется одну-две секунды.

Насколько я смог понять, это очередное упрощение, коих в R4 тысячи. По хорошему, надо запилить какую-нибудь более развесистую эвристику и всё-таки хранить сжатые данные в экстентах. Хотя я матчасть в этом плане знаю чуть менее, чем никак. Можно Шишкину написать.

по скорости она хуже btrfs
btrfs

Нет такой буквы! Следующий игрок, вращайте барабан!

4.2 :)

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

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

Я как-то предлагал Шишкину запилить элементарную определялку формата файла по первым нескольким байтам. Примерно так же как это делает mediainfo. Если тип файла не определен, то можно уже применять более сложную эвристику. Но на первом этапе этого будет с головой достаточно.

Да ну. Впилить в ядро утилиту file — не лучшая идея. Проблема с имеющимся подходом в том, что файлы неоднородны, и у какого-нибудь FLAC'а первые 64K вполне могут быть метаданными или картинкой, которые запросто сожмутся до 40% от исходного размера, после чего компрессия включится и тридцать мегабайт принципиально несжимаемого потока радостно упадут в дерево.

Я не имею ни малейшего понятия о том, возможно ли так сделать, но если хотя бы записывать результат сжатия каждого кластера в отдельный экстент (или в тейл, согласно стандартной эвристике, которая formatting=tails/extents/smart) — нагрузка на дерево уже упадёт в дофига раз. Т. е. сделать ccreg40 чуть более похожим на reg40 в плане организации данных на диске.

Может проще подсмотреть как реализовано сжатие в btrfs и сделать лучше? :) Если я не ошибаюсь, Шишкин как раз работает над btrfs на основном месте работы.

Судя по вики, эвристика у них не менее дубовая — как раз-таки хранение сжатых данных не через зад сделано...

Может проще подсмотреть как реализовано сжатие в btrfs и сделать лучше? :)

Зачем разработчикам reiser4 подсматривать в btrfs, которая, в свою очередь, подсматривала в reiser4?

Шишкин как раз работает над btrfs на основном месте работы

Шишкин сказал, что над btrfs он не работает по причине указанной в его публичном интервью.

как раз-таки хранение сжатых данных не через зад сделано

Так может это и есть частичное решение проблемы — переделать хранение сжатых данных? И уже потом пытаться придумать кто-то толковое в эвристике определения сжимаемости файла.

Зачем разработчикам reiser4 подсматривать в btrfs, которая, в свою очередь, подсматривала в reiser4?

Забавно :)

А я о чём? :)

Влияние notail в reisrefs (комментарий)

Я не имею ни малейшего понятия о том, возможно ли так сделать, но если хотя бы записывать результат сжатия каждого кластера в отдельный экстент (или в тейл, согласно стандартной эвристике, которая formatting=tails/extents/smart) — нагрузка на дерево уже упадёт в дофига раз. Т. е. сделать ccreg40 чуть более похожим на reg40 в плане организации данных на диске.

Зачем разработчикам reiser4 подсматривать в btrfs, которая, в свою очередь, подсматривала в reiser4?

Крис-btrfs подсматривал у Криса-reiser4? У него раздвоение личности, да?

нагрузку с hdd на cpu можно перенести с помощью компрессии. я из-за этого корень на бтр держу.

Достаточно широко известна «напряжённая переписка» Криса и Эдуарда на тему того, что tail packing, который btrfs'овцы подсмотрели у reiser{fs,4}, с B+-деревьями не работает и ведёт к неограниченной внутренней фрагментации (вследствие чего можно понасоздавать мелких файлов, поубивать из них половину и остаться с 100% занятого места).

Достаточно широко известна «напряжённая переписка» Криса и Эдуарда

Видел только интервью с Шишкиным. Где можно почитать «другую» сторону?

с B+-деревьями не работает

А что же тогда в reiserfs? Там как раз B+, разве что ссылки на следующий лист не используются.

ведёт к неограниченной внутренней фрагментации

Вот в этот тезис так и не въехал. Все так или иначе перестраивают дерево. Если оно перестраивается, в чём тогда проблема?

А что же тогда в reiserfs? Там как раз B+

Давай ты уже найдешь и откроешь определение B+-дерева, и в соседнем окне код reiserfs. И попытаешься найти в последнем примитивы-операции на B+ - дереве? Получилось?

Немного по теме:
https://twitter.com/balancer73/status/520633001625939969

Левая половина графика — загрузка системы вчера, до переноса основной части кешей на reisrefs. Потом, посередине, широкое плато на 2.5 часа — процесс переноса. Справа — результат после переноса.

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

Ещё в процессе переноса проверял — заход в каталог с 256 подкаталогами под ext4 занимал более секунды (система нагружена, напомню), под reisrefs — мгновенно.

Для теста нужно, конечно, вынести новый раздел с ext4, перекинуть данные туда и посмотреть, как изменится нагрузка, но, как обычно, лень :)

Вот в этот тезис так и не въехал. Все так или иначе перестраивают дерево. Если оно перестраивается, в чём тогда проблема?

Проблемы у тебя с матчастью. Надо перестраивать «так», а не «иначе». Перестроил «иначе», сломал условие балансировки - и твой спейс утилизейшн пошёл в туалет. Что мы и наблюдаем на примере Btrfs, ибо Крис так же, как и ты, не шарит в матчасти. У него есть только дешёвое благословение Торвальдса :)

Где можно почитать «другую» сторону?

https://lkml.org/lkml/2010/6/3/313 — кажется, это оно.

А что же тогда в reiserfs? Там как раз B+

Да, похоже, я ошибся в исходном сообщении. В btrfs, надо полагать, простые B-деревья. Хотя дисклеймер — матчасть я не знаю от слова «совсем» и занимаюсь исключительно ретрансляцией чужих слов.

соседнем окне код reiserfs

Он большой и страшный. Я написал дефрагментатор, можно я его код открою? Гляжу на него и разницы с содержимым статьи в википедии об B+ не вижу.

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

Я написал дефрагментатор, можно я его код открою?

А давай ты его не откроешь? :)

Я не хочу в угадайки играть, скажи прямо, что хотел сказать

Всего лишь опровергнуть твоё: «там как раз B+». Нет там его и в помине.

А давай ты его не откроешь? :)

$20 помогут мне забыть этот постыдный для тебя инцидент :)

Нет там его и в помине.

Несколько уровней есть? Есть. Большой fanout есть? Есть. Ссылки на данные только в листьях, а в узлах — диапазоны ключей? Тоже есть. Ссылки на соседний лист есть? Есть, но не используются.

3,5 пункта из 4-х за B+.

Что мы и наблюдаем на примере Btrfs, ибо Крис так же, как и ты, не шарит в матчасти

Что ж вы такие гениальные код не пишете? Знания матчасти есть, только толку от них нуль.

Так может это и есть частичное решение проблемы — переделать хранение сжатых данных? И уже потом пытаться придумать кто-то толковое в эвристике определения сжимаемости файла.

Ты не понял. «через зад» оно в btrfs сделано. В reiser4 c хранением сжатых данных как-раз всё нормально. Вот бенчмарк, который красноречиво показывает, что и у кого сделано через зад:

https://reiser4.wiki.kernel.org/images-reiser4/f/fb/Compilebench-0.6.pdf

Там внизу - расход дискового пространства. Это не ошибка :)

3,5 пункта из 4-х за B+.

А самое главное-то где? Я про операции удаления/добавления ключа. Пилите, Шура, пилите (с)

Немного по теме

Ну вот, диванные теоретики зафлудили твои благие начинания :)

Ну, я решил, что хуже с tail, как минимум, не будет и не стал включать notail :) Не могу без тестов сказать, какой вариант лучше (а нормально тестировать ломает), но по совокупности всех действий польза налицо. У меня впервые за последние пару лет лампочка HDD не непрерывно горит, а мигает, да ещё со скважинностью едва за половину (на глаз) :)

Ещё вот перенесу статику на внешний сервер и есть надежда, что совсем нагрузка спадёт :)

А самое главное-то где?

Без операций на структуре данных она бесполезна, это правда. Но операции не являются её неотъемлемой частью. Удалить ключ? Сомкнём лист, обновим родителей, если нужно. Добавить? Вставим новый лист. По ходу дела можно и перепаковать. Я всё ещё не вижу отличий от B+.

Пилите, Шура, пилите

ЧСВ зашкаливает? Ты аноним, на авторитет тут не получится опереться. А загадки твои уже поднадоели.

По ходу дела можно и перепаковать

Как это «можно и перепаковать»? Т.е. захотел перепаковал, захотел - не перепаковал? А что это вообще за операция такая «перепаковать»? Где она в определении B+-дерева?

А загадки твои уже поднадоели.

Ты пытаешься подменить свою некомпетентность моей «загадочностью». При чем тут ЧСВ? Как освоишь B+-деревья - приходи, продолжим искать их в reiserfs.

Как это «можно и перепаковать»? Т.е. захотел перепаковал, захотел - не перепаковал?

Именно так. Покажи мне в определении B+ дерева необходимость все листья держать заполненными. Затем. Если два листа заполнены на треть каждый, кто мешает упаковать их содержимое в один лист? Глубина дерева от этого не изменится.

Где она в определении B+-дерева?

В твоём определении B+-дерева? Ты уверен, что единственно верное определение вообще есть?

Как освоишь B+-деревья - приходи, продолжим искать их в reiserfs

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

https://lkml.org/lkml/2010/6/3/313 — кажется, это оно.

Почитал тред. Первое сообщение пропустили мимо, а когда через 15 дней poweruser о нём напомнил, Шишкин был первый, кто толкнул дискуссию в флейм:

It must be a highly unexpected and difficult question for file system developers: «how efficiently does your file system manage disk space»?

Решение о включении в дерево всего, что размером меньше свободного места в листе было изначально глупым, но об этом мало кто думал. Кстати, в тот момент, когда я первый раз попробовал создать том btrfs, max_inline уже было ограничено значением 256. По вопросу больших xattr я не в курсе. Если они до сих пор включаются вне зависимости от размера, а не выносятся в отдельный блок, тогда то письмо всё ещё актуально. Если же xattr тоже исправили, хватит бередить флейм четырёхлетней давности.

А, да, чтобы прояснить свою позицию в споре reiser4 vs. btrfs. Мне не нравятся ФС с CoW из-за непоняток со свободным местом. Может в промышленном применении это даёт какие-то преимущества, но мне это фиолетово. Я хочу точно знать, смогу ли я записать файл на ФС, в которой кончается место.

Вспомни контекст, в котором я привёл эту ссылку. Она была приведена не с целью доказать, что btrfs — плохая ФС, а затем, чтобы обосновать вот это:

btrfs, которая, в свою очередь, подсматривала в reiser4

Насчёт CoW:

• reiser4 резервирует часть места на диске специально для truncate() — хотя резервирует она слишком много, целых 5%
• опять же в reiser4 есть возможность сменить модель работы с дисковым пространством — только cow, только журналирование или гибрид

Ясно. Спасибо за объяснение.