LINUX.ORG.RU
ФорумAdmin

Влияние notail в reisrefs

 , , ,


1

4

Я тут в некоторых случаях, годы спустя после ухода, понемногу снова пробую возвращаться на reisrefs. Есть подозрение (отчасти подтверждённое экспериментально, но пока не очень уверенно), что в случае, когда используется огромное количество мелочи, раскиданной по большому числу каталогов, reiserfs заметно меньше грузит систему.

Посему в новых условиях интересно переосмысление некоторых опций.

Вот, notail. По дефолту reisrefs упаковывает мелочь в хвостах, что позволяет заметно экономить место. Когда винты стали большими, то стали рекомендовать отключать упаковку через notail, мол, места итак хватает, а система грузится меньше. Система какая — очевидно, CPU? Насколько я понимаю механизм, более плотное использование дискового пространства нагрузку на диск увеличивает. Прошли годы и сегодня мощность CPU почти всюду избыточная, не сравнимая с прошлым. А во HDD (вариант SSD — другая история) по скорости практически не прибавили и у меня лично сейчас всё лимитирует именно HDD. В таком случае не получится ли небольшая прибавка именно от использования упаковки?

★★★★★

Последнее исправление: KRoN73 (всего исправлений: 1)

Ответ на: комментарий от KRoN73

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

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

i-rinat ★★★★★
()
Ответ на: комментарий от erzent

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

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

devl547 ★★★★★
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от maloi

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

erzent ☆☆
()
Ответ на: комментарий от anonymous

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

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

i-rinat ★★★★★
()
Ответ на: комментарий от erzent

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

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

maloi ★★★★★
()
Ответ на: комментарий от devl547

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

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

anonymous
()
Ответ на: комментарий от maloi

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

erzent ☆☆
()
Ответ на: комментарий от devl547

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

anonymous
()
Ответ на: комментарий от i-rinat

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

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

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

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от erzent

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от anonymous

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

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

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

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от erzent

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

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

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

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

anonymous
()
Ответ на: комментарий от iron

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

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

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

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от erzent

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

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

darkenshvein ★★★★★
()
Ответ на: комментарий от intelfx

4.2 :)

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

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

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

iron ★★★★★
()
Ответ на: комментарий от iron

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

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от intelfx

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

iron ★★★★★
()
Ответ на: комментарий от iron

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

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

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

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

anonymous
()
Ответ на: комментарий от intelfx

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

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

iron ★★★★★
()
Ответ на: комментарий от anonymous

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

Забавно :)

iron ★★★★★
()
Ответ на: комментарий от iron

А я о чём? :)

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

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

intelfx ★★★★★
()
Ответ на: комментарий от anonymous

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

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

i-rinat ★★★★★
()

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

thesame ★★★★
()
Ответ на: комментарий от i-rinat

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

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

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

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

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

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

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

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

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

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

anonymous
()

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

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

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

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

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

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от i-rinat

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

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

anonymous
()
Ответ на: комментарий от i-rinat

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

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

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

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

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

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

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

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

i-rinat ★★★★★
()
Ответ на: комментарий от anonymous

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

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

i-rinat ★★★★★
()
Ответ на: комментарий от iron

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

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

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

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

anonymous
()
Ответ на: комментарий от i-rinat

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от anonymous

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

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

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

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

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

i-rinat ★★★★★
()
Ответ на: комментарий от intelfx

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 из-за непоняток со свободным местом. Может в промышленном применении это даёт какие-то преимущества, но мне это фиолетово. Я хочу точно знать, смогу ли я записать файл на ФС, в которой кончается место.

i-rinat ★★★★★
()
Последнее исправление: i-rinat (всего исправлений: 1)
Ответ на: комментарий от i-rinat

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

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

Насчёт CoW:

  • reiser4 резервирует часть места на диске специально для truncate() — хотя резервирует она слишком много, целых 5%
  • опять же в reiser4 есть возможность сменить модель работы с дисковым пространством — только cow, только журналирование или гибрид
intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.