reiser4 стоит ли?

Проскакивала новсть, что btrfs уже стабильна. Я в этом не уверен. (комментарий)

Довольно бессмысленное сравнение, конечно, но всё равно интересно, почему в btrfs такой странное ограничение в 350 МБ.

Ещё интересно будет, что произойдёт, когда программы пройдутся mmap'ом по всем файлам. По цифрам в reiser4 получается 900 мегабайт двухкилобайтных файлов, что невозможно без их упаковки в дерево, причём с разбиением по частям. Если сделать mmap, ФС будет обязана их «распаковать», перенеся в обычный блок, а блоков на все файлы не хватит.

Кстати, точную причину отваливания reiser4 при высокой нагрузке нашли? Или баг просто пропал со временем?

не понимаю, как можно использовать то, что умерло уже скоро как 10 лет.

У меня обновилось ядро с 3.16 до 4.0, и вот через пару дней я заметил, что PWM интерфейсы в /sys для кулера ноута отвалились. Их просто нет. Зато развивается, ага.

Если в софте нет критичных багов, то не пофиг ли, когда он написан? Я некоторое время использовал arpwatch, который последний раз в 1996 году обновляли. И что? Работал же.

возможно майнтейнеры с конфигом ядра накосячили. just sayn

возможно майнтейнеры с конфигом ядра накосячили

Вряд ли. Нужный модуль на месте и загружен, дело не в его отсутствии. Конфигурировать в нём самом вообще нечего, он либо есть, либо его нет.

За это время туда добавляли заголовки сенсоров (temp1_label), и нумерация сдвинулась. Возможно, там что-то забыли.

Ну, в write_begin случится варнинг и возврат с ошибкой, а дальше как ядро решит. Вроде бы. А когда вызывается write_begin? При mmap'е с PROT_WRITE?

Какого отваливания? Фантомного «No space left on device»?

Какого отваливания?

Куча предупреждений в кольцевом буфере ядра, а потом «ой, всё!», и раздел больше не смонтирован.

No space left on device

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

Куча предупреждений в кольцевом буфере ядра, а потом «ой, всё!», и раздел больше не смонтирован.

А это когда такое было?

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

По идее, это проявляется, если очень интенсивно писать в несколько потоков.

В reiser4 на изоляцию и откат транзакций положили хрен, вместо этого запилив «резервирование места»: необходимое для транзакции место грубо оценивается сверху и вычитается из свободного. По окончании транзакции — возвращается.

Соответственно, простор для ложных срабатываний ENOSPC огромный. Это попытались починить: если транзакция видит ENOSPC, она сначала коммитит все остальные транзакции, ждёт их завершения и пытается выделить место повторно. Видишь, где здесь рейс?

Короче, эта идея с резервированием места там реализована через большой зад, и как сделать её по-нормальному — не очень понятно. Я пытался.

А ещё там есть такая операция, как «дозарезервировать место принудительно», которая в куче мест вызывается в середине транзакции. О том, что будет в случае фейла такого «принудительного резервирования», предлагается не думать...

А это когда такое было?

Где-то в начале 2013-го: Какие ФС у вас используются на домашнем компьютере? (комментарий)

простор для ложных срабатываний ENOSPC огромный

У btrfs та же беда: выбор между высокой скоростью параллельной работы и фантомными нехватками места и глобальными блокировками с соответствующими тормозами они сделали не в пользу тормозов.

в начале 2013-го

Вероятно, уже починили. Начиная с ядра 3.7.

Вероятно, уже починили. Начиная с ядра 3.7.

Да я помню сообщения о том, что починили. Вопрос в том, как именно ФС приходила в такое состояние.

Точную причину я не знаю. Но там всё связано с несовместимостью дефолтного ядерного ->migratepage() с r4.

что-то такое было: http://marc.info/?l=reiserfs-devel&m=135146138331012&w=3

В reiser4 на изоляцию и откат транзакций положили хрен, вместо этого запилив «резервирование места»

Ахинею давай не будем нести? Рейзер4 транзакшн дизайн - очень известный документ. Изоляцию определять должны пользователи. А поскольку в линупсе нет интерфейсов для управления транзакциями из юзерспейса, в рейзер4 по-умолчанию действует какая-то общая эвристика. А если всё подряд изолировать, ничего хорошего не получится, да? Про хрен, положенный на откат транзакций посмеялся. А уж резервирование тут каким боком «вместо» или параллельно?

Это ты сейчас говоришь про границы транзакций. Действительно, сейчас (в условиях отсутствия соответствующих интерфейсов) они определяются очень просто: один системный вызов == одна транзакция.

А я говорю про изоляцию из ACID. Если в ходе совершения транзакции возникнет непредвиденная ошибка, то reiser4 просто уронит систему: откат транзакций не предусмотрен.

Поэтому различные необходимые условия успешности транзакции проверяются до начала оной. В частности, проверяется и резервируется свободное место на диске.

откат транзакций не предусмотрен.

А как ты их предлагаешь откатывать, если они мерджатся? Процесс необратимый. Или ты предлагаешь их вообще не мерджить? Или это просто риторическое ворчание?

Я ничего не предлагаю. Я констатирую факт: откат транзакций не предусмотрен и вместо него перед внесением изменений в состояние ФС производятся разного рода проверки. И производятся хреново — бывают ложноотрицательные срабатывания (а также теоретически возможны ложноположительные, что куда хуже, но никто их ещё не ловил). Об этом речь.

Если в ходе совершения транзакции возникнет непредвиденная ошибка, то reiser4 просто уронит систему

«непредвиденная ошибка» уронит систему где угодно и с откатом транзакций и не только в reiser4.

Имеется в виду ошибка «уровнем ниже» (например, в железе), а не в алгоритме. И, вообще говоря, такие ошибки нужно обрабатывать: прерывать запись, приводить состояние в памяти обратно к консистентному (считаем, что состояние на диске консистентно всегда с точностью до ошибки записи суперблока, потому что WAFL) и перемонтировать в read-only.

Имеется в виду ошибка «уровнем ниже» (например, в железе)

Да, и я про них же. В коде ядра повсюду расставлены BUG_ON, которые роняют систему на таких ошибках.