reiser4 стоит ли?

Могу залить ядро 4.1.0-pf0

залей)

в pf ядре подефолту включена поддержка reiser4?
думаю накатить сейчас на / reiser4

e2fsck за час или за два отрабатывает?

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

а на ext4 отрабатывает за несколько минут

Но тупых недоработок в линуксе это не отменит. А при использовании кедовской или гномовской лечилки дисков, брутфорсить быстрее и на ext3 и на ext4.

Нет, pf отдельно, reiser4 отдельно.

Могу залить ядро 4.1.0-pf0

в этом ядре же есть поддержка reiser4?

залей 4.1.0-pf0 или что угодно с поддржкой reiser4 (желательно посвежее) куда тебе удобно

я хочу потестить)

а у тебя нет ftp или типо того с бинарниками ядра для арча?

куда вообще делись все pkg билды из aur связанные с этой фс?

Пардон, проблемы со связью...

ftp://intelfx.name/linux-reiser4-4.1.r5819.gbbee6f2-1-x86_64.pkg.tar

ftp://intelfx.name/linux-reiser4-headers-4.1.r5819.gbbee6f2-1-x86_64.pkg.tar

а для i686 нет?)

попробую это ядро, так вроде можно, когда система c i686 а ядро c x86_64

И точно калькулятор...

2 гига озу и amd m300 :3

Вообще-то, он умеет в x86_64.

2 гига рамы мало для x86_64

а ext4 устанавливается и глючит, но она невиноватая.

Как там, в прошлом?

linux-reiser4-4.1.r5819.gbbee6f2-1-x86_64.pkg

у меня есть патч только под 4.0.4 - reiser4-for-4.0.4

откуда ты берешь патчи?

Из головы.

Да нет, нормально. С полгода где-то жил на похожем конфиге (Z99H) с x86_64 и четверокедами.

распаковал твоё ядро, закинул в фс вручную, запилил initramfs, ребут и теперь все готово :3

какие подводные камни могут возникнуть, если я буду юзать 64 битное ядро и систему с 32 битными пакетами?

uname -m, например.

Linux arch 4.1.0-pf0-reiser4-05819-gbbee6f2 #1 SMP PREEMPT Mon Jun 29 13:22:08 MSK 2015 x86_64 GNU/Linux

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

Кстати, какой здесь планировщик по умолчанию?

cat /sys/block/sda/queue/scheduler
noop deadline cfq [bfq] 

а bfq с reiser4 дружит нормально)

А почему бы bfq не дружить с reiser4, собственно?

Кстати, я только что вернулся, так что могу поставить на сборку дефолтный арчконфиг последнего 4.1-pf+reiser4 для i686, если нужно.

думаю разницы с текущим ядром мы не заметим

спасибо, пойду ковырять корень на reiser4)

у тебя у самого какие фс стоят на обычных винтах?

Гипотетически, может начать глючить всё, что проверяет personality. Вплоть до pacman (будет пытаться ставить x86_64 пакеты).

На файлопомойке (именно на самом дисковом массиве) XFS → ext4, везде кроме этого массива — reiser4.

а /boot отдельный?

или второй груб уже дружит с reiser4?

Точно, /boot же ещё. На основной машине vfat, потому что UEFI, на остальных — ext2.

пробую грузить, ругается на неподдерживаемую фс - дело в ядре?

фс создавал так

mkfs.reiser4 -o create=ccreg40,compress=lzo1 /dev/sda4

Проверь модули, сделай depmod, перегенери initcpio (принудительно запихнув reiser4 в переменную MODULES).

initcpio нужно перегенеривать для нового ядра (-p linux-reiser4, если ты распаковал из пакета соответствующий пресет).

Как там, в прошлом?

Как там менять ПК каждый год?

Как там менять ПК каждый год?

Свой с 2009 года еще не менял. А что? ext4 работает нормально, не хуже того же ntfs.

Свой с 2009 года еще не менял. А что? ext4 работает нормально

Так сложились звёзды и разделы на винтах, а могли бы сложиться иначе.

не хуже того же ntfs.

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

сделал depmod, запихнул в модули reiser4, перегенерил и оно взлетело

оставил пока старый раздел с ext4, погоняю тесты на новой фс

пока на моём hdd разницы особо не видно(

Так сложились звёзды и разделы на винтах, а могли бы сложиться иначе.

Да я по-всякому их складывал, и через dd накатывал «на лету»

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

:) Значит надежность ext4 недооценена мною.

btrfs упаковывает мелкие файлы в B-дерево, т. е. хранит в нём айтемы переменного размера, для чего оно не предназначено. Как результат — внутренняя фрагментация дерева (≈ всё место занято узлами, в каждом из которых нет места).

reiser4, соответственно, не использует B-деревья.

Но в reiserfs 3.6 мелкие файлы хранятся в дереве. И это считалось нормальным.

После запрета аналогов direct item (не знаю, как они там называются) в btrfs, больше претензий к ней нет?

Кстати, как там с дефрагментацией reiser4?

Но в reiserfs 3.6 мелкие файлы хранятся в дереве

B vs B+.

После запрета аналогов direct item (не знаю, как они там называются) в btrfs

А btrfs уже не занимается аналогом tail packing?

B vs B+.

Я плаваю в терминологии. Ключевое отличие B+ — это ссылка на следующий лист?

А btrfs уже не занимается аналогом tail packing?

Это выключается, как выключалось в reiserfs.

Ключевое отличие B+ — это ссылка на следующий лист?

Одно из отличий B+ — хранение K вместо K-V в узлах.

Это выключается, как выключалось в reiserfs.

Логично. Просто reiserfs не деградирует при включенном tail packing (точнее, может, и деградирует, но обратимо — внешняя фрагментация), а btrfs имеет все шансы деградировать.

Соответствующая ссылка на письмо Шишкина всем известна и приводилась уже с десяток раз; с тех пор они «исправили» проблему как минимум один раз, уменьшив ограничение на размер встраиваемого в дерево хвоста... но что-то это как-то не того.

Другие претензии к btrfs мне неизвестны. (Да, я здесь занимаюсь исключительно ретрансляцией результатов уже проведённых до меня изысканий, естественно.)

Одно из отличий B+ — хранение K вместо K-V в узлах.

То есть во внутренних узлах только диапазоны ключей, а данные — только в листьях? Тогда в Btrfs используются B+-деревья.

Гляжу в https://btrfs.wiki.kernel.org/index.php/On-disk_Format#Basic_Structures и вижу тоже самое, что и в reiserfs 3.6. Внутренние узлы, листья, данные в листьях заполняются с конца. Прямо один в один, разве что размеры структур отличаются.

Просто reiserfs не деградирует при включенном tail packing

Тут как посмотреть. С одной стороны вусмерть деградирует. Разбрасывает по диску листья так, что всё свободное место оказывается фрагментировано. Файлы уже при первой записи разбиваются на кусочки, что довольно печально.

С другой стороны, если всё удалить, то место опять освободится. Так как пространство для блоков дерева совпадает с пространством для блоков данных, удаление всех файлов уменьшает дерево до минимального, и всё место освобождается. В btrfs пространства для дерева и данных по умолчанию разделены и там разбухание дерева приведёт к тому, что большая часть места будет выделено под дерево и для данных места не останется. Но с другой стороны, при нормальном использовании (часто ты забиваешь весь диск двухкилобайтными файлами?) метаданные будут собраны в одном месте, а не разбросаны по диску. IMHO это хорошая идея.

btrfs упаковывает мелкие файлы в B-дерево, т. е. хранит в нём айтемы переменного размера

переменного до определённого размера (по умолчанию 4 Кб, для уменьшения фрагментации дерева можно уменьшить хоть до нуля)

reiser4, соответственно, не использует B-деревья

только вот у него своих проблем хватает

Соответствующая ссылка на письмо Шишкина всем известна и приводилась уже с десяток раз

только мало кто понимает сути того, что там писалось, ну хоть ты понимаешь и ладно

с тех пор они «исправили» проблему как минимум один раз, уменьшив ограничение на размер встраиваемого в дерево хвоста... но что-то это как-то не того

а что тебе нужно «того»?

слушай, вот такой вопрос: если используя btrfs на HDD, сделать очень большой размер inline (скажем, в 100 Гб), то получится, что все файлы до этого размера будут паковаться в дерево? т.е. в ФС не будет разделения на данные и метаданные, всё будет лежать одним куском, и соответственно, головкам нужно будет меньше летать туда-сюда и скорость работы с файлами повысится? или нет?

кстати посоны вбросте кто-нибудь, ext3 собираются из ядра удалить https://lkml.org/lkml/2015/7/15/438

сделать очень большой размер inline (скажем, в 100 Гб), то получится, что все файлы до этого размера будут паковаться в дерево?

Ну да, если фрагменты можно будет резать на части. Насколько я помню, они в btrfs записываются только целиком, так что ограничение на 3900 с чем-то байт. А вообще я что-то такое слышал, называлось оно Write Anywhere File Layout.

т.е. в ФС не будет разделения на данные и метаданные, всё будет лежать одним куском, и соответственно, головкам нужно будет меньше летать туда-сюда и скорость работы с файлами повысится? или нет?

Нет, не одним куском. Служебная часть метаданных будет сильно разбавлена собственно данными. Чтобы прочитать список файлов в директории, придётся собирать данные по мелким кусочкам с большого количества мест. Я считаю, что лучше им лежать действительно рядом, компактно. Если директория влазит в 128 килобайт (read_ahead_kb), она будет считана за один заход.

К счастью, я не занимаюсь разработкой ФС.

Значит, я ошибся и дело не в B vs B+... В reiserfs v3 эти самые деревья как-то особо похачены.

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

как в итоге решили эту проблему с btrfs.

Да никак не решили. Сейчас проверил на 4.0 ядре на разделе в один гигабайт. Что с max_inline, что без, получается записать только 350 мегабайт двухкилобайтных файлов.

А вот в reiserfs влезло 950 мегабайт без notail (o_O) и 500 мегабайт с notail.

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