Влияние notail в reisrefs

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

но только ядро не ниже 3.14.1 и не дебиан стейб ветки, где до сих пор она 2008 года.

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

А вот то, что после перевода ext4 в некоторых случаях на reiserfs нагрузка на систему сильно падает, видел уже своими глазами дважды. Лет 5 назад, когда ext4 стала уделывать reisrefs и я перешёл на «мейнстрим» я не сталкивался с именно такими случаями, с кучей мелочи.

Надо бы, конечно, посмотреть на btrfs сегодняшнего дня, но нужно сочинить новый хороший тест под мой случай. Хотя бы для очистки совести, чтобы в споре оперировать цифрами. А если окажется хорошим вариантом — то поменяю своё мнение. Но я не верю в чудеса :)

но только ядро не ниже 3.14.1

Тюю.... Нет, это точно не вариант для продакшна :)

Оптимальный размер блока при форматировании раздела, возможно решает многие проблемы.

Моей квалификации не хватит оценить потребный размер. А экспериментировать с созданием разных разделов, переключением боевой нагрузки и замерами ломает. По 120Гб мелочи — там только на копирование многие часы уходят :)

By default, ReiserFS stores small files and `file tails' directly into the tree.

упаковка хвостов в reiserfs не такая как в классических фс

Я, как бы, это знаю. Вопрос в том, что выгоднее при быстром процессор и медленном HDD — tail или notail :)

если дерево в кеше, а это максимально вероятно, то tail быстрее, процессор тут вообще не при делах, вычислять нечего

Должны быть какие-то howto на эту тему. Optimal block size ext3|ext4

Делал бы так: посчитать статистику размеров файлов (возможно весь набор: мода, среднее, разброс, сигма, 3*сигма) по ним можно задать рамер блока или кратный ему или округлённый

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

...что?

fixed :)

Надо бы, конечно, посмотреть на btrfs сегодняшнего дня, но нужно сочинить новый хороший тест

кастани, если в пользу будет.

про notail скажу так: notail СИЛЬНО снижает скорость копирования/перемещения мелочи.

для продакшна

reiserfs

дядя, тебе бы у нарколога провериться! оно совсем дохлое и давно не шевелится, а ты в продакшн пихать? не, я сам его юзаю (с notail), но меня так по голове ещё не били.

Приколько. Переношу сейчас кеши с нынешнего раздела с ext4 на новый resierfs (разбивка ГГГГ/ММ/* — вот по ММ и переношу) и по одному месяцу так и переключаю. Процесс копирования идёт, а LA падает прямо на глазах 10..9..8..7.

ncdu для каталога на ext4 после нескольких минут ожидания (когда кеши сбросятся) занимает 15..20 секунд. А для reisrefs — около секунды.

Конечно, тут сказывается ещё и «дефраг мувом», именно он и не даёт вывести окончательный ответ, но итог радует. По хорошему год спустя интересно бы перенести всё снова на новый раздел с ext4 и опять сравнить, будет эффект (тогда это именно «дефраг мувом» работает) или нет.

Но по старой многолетней практике с reisrefs я не помню такой сильной деградации ФС по мере активной эксплуатации, как в ext4.

дядя, тебе бы у нарколога провериться! оно совсем дохлое и давно не шевелится

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

А чему там шевелиться? Оно просто работает. Использую везде, внезапных проблем за годы использования никогда не было

оно совсем дохлое и давно не шевелится

А куда ему развиваться-то? Reiser3 законченный продукт. NTFS вон, в винде, толком не менялся последние 15 лет - и ничего, юзают, не кричат по углам что оно дохлое.

Если его не развивают - это одно. Если там не правят баги - это другое, оно может быть просто уже очень стабильно, что практика и показывает.

Я сам его юзал для почтовой иерархии, с 3млн+ мелкими файлами в maildir оно справлялось на ура, никаких падений несколько лет не было, краши переживало отлично, хоть и монтировалось несколько дольше других ФС после краша (реплеила транзакции).

Так что подбирайте инструмент под задачу, где-то одни фс хороши, где-то другие. Да, бтрфс в топку, пока это удел админов локалхоста.

В начале переноса, когда вся web-нагрузка была на ext4, перенос файлов на новый reisrefs раздел шёл со скоростью 300-400 кбайт/с. Сейчас, в конце переноса, когда нагрузка перешла в основном на resierfs, копирование идёт со скоростью 800-900кбайт/с.

та бтрф которую ты смотрел, ещё даже 1 рейд не умела, а нынешняя и 10 и 01, и даже 5 в бете, сейчас она очень сильно изменилась, но у неё есть требования для хорошей работы, своя таблица разделов, как и у zfs.

2.5Мб/с и LA упал до 3 :)

Даже если дело не в reisrefs, а лишь в «дефраге мувом», всё равно игра стоит свеч...

Вот как новое ядро перестанут рекомендовать и пара лет активной работы у энтузиастов пройдёт без нареканий — тогда и буду щупать.

А вот btrfs

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

на винде до сих пор нет бэкапов нормальных, но с этим смирились,а их бэкапы на тот же винт в 8ке это нечто.... у меня на бтрфс были тестовые площадки и файловые сервера для колл центра и тп, где тонны обращений к 1 и тому же файлу часто, и там смена ext4 на btrfs очень сильно улучшило работу шар.

бери rhel, там она и в 2.6 новая есть, просто дебиан странный, 2008 года пихает версию.

Оно просто работает. Использую везде, внезапных проблем за годы использования никогда не было

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

Да, бтрфс в топку, пока это удел админов локалхоста.

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

Думаю этот том должен быть смонтирован куда-то в хостовой системе

А, сорри, я в контексте @erzent — перепутал с ним.

я лишь попросил кастануть, если посмотришь в его сторону, и оно будет годным

Ну, если я дозрею до новых тестов, то постараюсь результаты на ЛОРе отобразить :)

бери rhel

Свят-свят. Мне CentOS'а хватает по работе.

если тебе нужно работать, а не ждать, то reiserfs с notail точно не для тебя, а с tail я его не пробовал, ибо терабайтники.

remi реп подключи и получишь свежую btrfs.

у меня на btrfs было 480 машин, за год не одной проблемы, шары были с btrfs, пережила 4 отключения электричества,они прямо в офисе,в дата центре шара на ext3.

Файловые системы — это не то, что мне нужно «свежее». Файловые системы я выбираю окаменевшие. Чтобы там уже ничего не раскрошилось и потекло :)

Винда с 7ки умеет снапшоты, на какой хочешь диск, притом это делается в пару кликов

Не слушай его, с его историями про генту, бтрфс, федору.

она и в 2000ной умела, проблема в том, что работоспособность у этой функции так себе, до btrfs/zfs этим бэкапам далеко.

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

В чем приемущества бекапов на бтрфс? И еще вопрос как таблица разделов бтра повышает производительность?

Кстати недавно баг был рейзерфс с тейлом отваливалась во время записи, к сожалению я с телефона и не в состоянии найти

Баги бывают со всеми системами.

Оптимальный размер блока при форматировании раздела

В reiserfs долгое время размер блока был фиксирован на значении 4096 байт. Теоретически была поддержка и блоков меньшего размера, но из-за какой-то завязки на размер журнала единственно возможным осталось значение 4096 байт. Подробности искать лень. Несколько месяцев назад код reiserfs причёсывали, так что может этот баг заодно и починили.

По теме tail vs. notail. Включение хвостов в дерево ключей раздувает это самое дерево ключей. Перебалансировка дерева — тормозная операция, и чем дерево больше, тем она тормознее. Да и поиск ключа в меньшем дереве быстрее. Так что лучше всегда использовать notail.

Да и поиск ключа в меньшем дереве быстрее. Так что лучше всегда использовать notail.

Даже в условиях очень быстрых простаивающих процессоров и очень загруженных дисковых систем?

Даже в условиях очень быстрых простаивающих процессоров и очень загруженных дисковых систем?

Сложно сказать, могу только гипотезы строить. Я считаю, что у небольшого количества часто используемых данных шансов выжить в кеше больше. То есть чем плотнее будут лежать метаданные, тем меньше они займут, и тем большее шансов, что они будут закешированы. Данные файлов непосредственно в дереве ключей его «разбавляют», и в итоге, даже при выполнении вызова stat для файла, с диска читаются тельца ещё пары файлов, которые рядом оказались.

но только ядро не ниже 3.14.1 и не дебиан стейб ветки, где до сих пор она 2008 года.

Уже который год это слышим. «Вот вот, уже стабильна в этом ядре...», «Уже все баги отловили, инсталль в продакшин». А по факту, как только даешь нормальную нагрузку на дисковую подсистему, система становится колом и помогает лишь хард ресет. Нет уж, лучше юзать старый reiserfs который стабилен как бревно, ест мало ресорсов и довольно быстр на мелкого и среднего размера файлах.

Сейчас меня забросают помидорами, но попробуй reiser4 как-то на досуге. В последнее время Шишкин и Шаповалов ее здорово причесали, некоторые старые баги пофиксили, добавили пару алгоритмов резервирования блоков, сделали некоторые тюны под SSD. Так же допиливают поддержку discard.

но попробуй reiser4 как-то на досуге

Года четыре назад на ней на домашней машине сидел. Поначалу система работает обалденно, быстрее, чем на ext4 или, тем более, xfs, но через пол-года активной работы превращается в тыкву. Начинает тормозить нещадно.

В последнее время Шишкин и Шаповалов ее здорово причесали

Тот же ответ, что и с btrfs — как перестанут допиливать, потому что всё будет просто работать — так и снова присмотрюсь :D А пока её щупать в работе негде. На живой сервер ставить не рискну, а на десктопах я завязал с экспериментами. Неудобно, когда нужно срочно работать, а тебе систему надо восстанавливать, потому что при эксперименте что-то не так пошло :D

Года четыре назад на ней на домашней машине сидел. Поначалу система работает обалденно, быстрее, чем на ext4 или, тем более, xfs, но через пол-года активной работы превращается в тыкву. Начинает тормозить нещадно.

Если использовать до 70% раздела, то файло не будет фрагментироваться. Разве что свободное место будет фрагментировано, если здоровое файло часто добавлять/убавлять.

Тот же ответ, что и с btrfs — как перестанут допиливать, потому что всё будет просто работать — так и снова присмотрюсь :D

Ключевое словосочетание было «на досуге». Это же не значит что прям сразу в продакшин :)

Поначалу система работает обалденно, быстрее, чем на ext4 или, тем более, xfs, но через пол-года активной работы превращается в тыкву. Начинает тормозить нещадно.

Вам нужно включить чистое журналирование. Опция монтирования txmod=journal. По умолчанию в reiser4 работает транзакционная модель, которая часть блоков коммитит при помощи техники COW (Copy-on-Write), что может вести к быстрой фрагментации.Тут подробнее: http://reiser4.wiki.kernel.org/index.php/Reiser4_transaction_models

Прошли годы и сегодня мощность CPU почти всюду избыточная, не сравнимая с прошлым. А во HDD (вариант SSD — другая история) по скорости практически не прибавили и у меня лично сейчас всё лимитирует именно HDD.

Я бы порекомендовал присмотреться к reiser4. Там идея упаковки хвостов доведена до совершенства поддержкой т.н. liquid records. С этой фичей хорошо сочетается прозрачная компрессия, т.к. коэффициент сжатия не портится внутренней фрагментацией.

на федоре у меня инфраструктура была, причём стабильная, 2,5 месяца

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

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