LINUX.ORG.RU

reiser4 и upstream ядра linux: когда?

 , , ,


2

2

Как известно, reiser4 не включена в состав основного ядра линукс, приходится патчить. почему такая ситуация сложилась? можно ли исправить и все-таки включить в основное ядро? лично мне это неудобно, да и reiser4 няшная ФС, нища у нее найдется… готов потрудиться над исправлением и включить наконец-то, боюсь один не потянуть. призываются добровольцы,

@mandala @post-factum

★★★★★

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

Так это в четвёрке

Да, но суть фанбойства та же. Rocket science, недоступные простым смертным алгоритмы и т.п.

Кстати, ты же знаешь, почему я пишу именно 3.5/3.6?

Нет, я познакомился с линуксом во времена 3.6 (где-то 2008-й), и ReiserFS меня никогда особо не интересовала.

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

недоступные простым смертным алгоритмы

В четвёрку не смотрел, но алгоритмы в reiserfs напоминают: «бери еду, пихай её в рот. Когда еда кончится, иди туда, где есть еда».

познакомился с линуксом во времена 3.6

Там до сих пор используется два формата ключей, из 3.5 и 3.6. Определяются они по эвристикам, потому что признаков версии в них нет. Чтобы эвристики продолжали работать, текущий код ФС иногда создаёт ключи в старом формате. Поэтому она не 3.6, она 3.5/3.6. Такая вот жесть.

Я понимаю, что это был такой способ безболезненной миграции. Но всё равно жесть. Это делает код сложнее там, где эта сложность не нужна.

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

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

На SSD фрагментатор нужнее, вроде? (писать один файл в блоки одинакового износа, а не в соседние)

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

SSD хорошо справляются с выравниванием износа. Без этого на них файловые системы общего назначения дохли бы очень быстро, потому что суперблок переписывается очень часто. А он находится в фиксированном месте. Несколько раз систему запустил, и чпок, блок истёрся, больше не записывается, ФС ушла в режим только-для-чтения, система больше не грузится.

Специализированные ФС типа JFFS2 знают о подробностях устройства флеш-памяти и стараются её беречь. Но из-за этого монтируются достаточно долго: нет фиксированного суперблока, нужно осознать текущее состояние по содержимому.

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

На SSD дефрагментация нужна только чтобы меньше напрягать процессор в особо запущенных случаях. Выравнивание износа в задачи ОС не входит. Может начать входить с распространением SSD «без контроллеров» (не помню название протокола), но это не точно.

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

Я другой анорим, но всё жн. Когда у меня была suse 10.1, она после сбоя питания писала replaying transactions и много много-раз. Меня это всегда пугало: а вдруг что-нибудь повредилось. Впервые вижу специалиста, который может ответить на вопрос, стоит ли паниковать?

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

она после сбоя питания писала replaying transactions и много много-раз.

Записи критически важных данных происходят в два этапа. Сначала данные пишутся в специальное место — журнал. После этого на диск подаётся команда принудительной записи данных в хранилище. Затем данные начинают записываться в основную область файловой системы. Такой подход должен защитить журналируемые данные от сбоев питания. В теории. Если питание пропадёт до завершения записи в журнал, восстанавливать будет нечего, потому что записи в основную область ФС ещё не было. Если питание пропадёт во время записи в основную область, при монтировании ФС данные из журнала записываются в основную область. И ФС снова в непротиворечивой форме.

Все журналируемые ФС проигрывают незаконченные записи из журнала при монтировании. Но Reiserfs зачем-то пишет об этом сообщения.

Меня это всегда пугало: а вдруг что-нибудь повредилось.

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

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

стоит ли паниковать?

Жизнь — тлен. Паниковать не стоит.

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

стоит ли паниковать?

Конкуренция - она везде. И в Linux - тоже. На Бога (Богородицу) надейся, а сам не плошай. Поэтому важны и знания, и опыт.

Deleted
()

Эдуард сказал, что «пока не видит в ядре защиты от дураков» и привёл ссылку на письмо Теодора Тс'о, который призвал народ пропатчить reiser4 так, чтобы в нём «не осталось плагинов» (Линусу, видители так угодно). Дело было давно, когда Reiser4 была еще в mm-ветке, но я могу понять Эдуарда - тем более, что на тот призыв откликнулись «добровольцы», а Эдуарда не поддержал никто. Это как отдавать своего ребёнка в детсад, где тебе предложат перед этим сделать ему операцию по смене пола. Причем так, что это будет ни мальчик, ни девочка, а непойми что.

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

Параноики включают журналирование данных.

Прикинь, есть системы где оно всегда включено.

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

Это, опять же, зависит от реализации.

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

не осталось плагинов

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

Или это всё раньше там было, и сейчас уже «пропатченная от плагинов» версия?

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

Это, опять же, зависит от реализации.

Если писать в выделенный журнал, а потом в область данных, придётся писать два раза. Замедление будет минимум в два раза. Быстрее никак.

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

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

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

Нет, претензии были именно к модульности. Торвальдс сказал, что не потерпит модулей в файловой системе. Эта модульность каким-то образом ущемляет его права как маинтейнера ядра. То есть, предлагалось все модули reiser4 вытряхнуть в единое кровавое месиво. Можно себе представить объём работы, учитывая, что в reiser4 модульность заложена в основу дизайна (как модуля ядра, так и юзерспейс утилит) - там всё завязано на идентификаторы модулей (пары плагин type - плагин id). И кто потом всю эту аморфную кодовую массу будет маинтейнить? Шишкин отказался.

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

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

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

Звучит как политика. Причём такая плохая: «ты мне не нравишься».

Я тут погуглил, и нашёл вот это:

  • as long you call them «plugins» and treat them as such, I (and I suspect a lot of other people) are totally uninterested, and in fact, a lot of people will suspect that the primary aim is to either subvert the kernel copyright rules, or at best to create a mess of incompatible semantics with no sane overlying rules for locking etc.
  • the kernel does not, and will not, support «hooks» that aren’t actually used (and make sense) by normal kernel uses, for largely the same reasons. Interfaces need to be architected, make sense, and have real and valid GPL’d uses.

Тут тоже политика, но уже с конкретизированными опасениями. Против такого мало что можно сказать.

По мне, так просто личную неприязнь к Рейзеру перенесли на весь проект.

Как ни крути, Linux — это люди, которые занимаются Linux. Хочешь пропихнуть туда код, придётся сотрудничать. Причём не с кодом, а с конкретными людьми. И для этого желательно научиться не наступать на их больные мозоли. В https://lkml.org/lkml/2006/7/21/109 между строк читается: «вы там все тупые». Не самое разумное поведение.

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

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

Вопрос тебе. Как по-твоему, ZIL в ZFS - это CoW или журналирование?

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

Я не знаю, что такое ZIL, а с наскоку в этом разобраться не получится. Так что не могу ничего внятного сказать.

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

Я не знаю, что такое ZIL, а с наскоку в этом разобраться не получится. Так что не могу ничего внятного сказать.

Вопросов больше не имею.

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

ZFS Intent Log

Молодой человек, вопрос был задан не вам, так что не надо быть в каждой бочке затычкой. Я прекрасно знаю, что это такое, и как это работает. Вопрос был для i-rinat, чтобы понять, куда он относит ZIL в его системе координат в контексте этой дискуссии. и он ответил на него прямо и без экивоков, что, прямо скажем, не часто встречается в наши дни.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.