LINUX.ORG.RU

Reiser4 может войти в состав Linux во второй половине 2010 года

 , , ,


0

0

По информации от Эдуарда Шишкина, одного из активных разработчиков Reiser4, работа над данной файловой системой продолжается, несмотря на отсутствие активности в списке рассылки разработчиков ядра Linux. В настоящий момент готовится к публикации на конференции USENIX Annual 2010 документ с полным описанием архитектуры Reiser4. В документе подробно описаны все используемые в reiser4 интерфейсы, плагины и примитивы (такие, как преобразование run-time объектов). Главная задача документа - доказательство того, что в Reiser4 не дублируются функции стандартной VFS и что в файловой системе устранены все мешающие интеграции с ядром Linux недоработки.

После обсуждения документа планируется начать подготовку к интеграции кода Reiser4 в состав основной ветки ядра. При оптимальном стечении обстоятельств, Reiser4 может войти в состав ядра Linux 2.6.36, которое выйдет во второй половине следующего года.

Оригинал новости: http://www.phoronix.com/scan.php?page...

>>> Новость на opennet.ru



Проверено: maxcom ()
Ответ на: комментарий от linuxfan

>Честно говоря, не понял, при чем тут вырубание?

Как я понял, у тебя тупо образ portage в squashfs и не допускает модификации.

У меня же связка squashfs + tmpfs через unionfs.

Связка работает через демон. При старте системы подымается, при отрубании - генерит новый squashfs с обновлённым контентом.

KRoN73
()

Предвижу мега-флеймы на LKML

anonymous
()
Ответ на: Grammar Nazi от lodin

>Россия язык

>Англия порядок

Здравствуй моджахед.

Ab-1
()

арест ганса пошел на пользу - исчез источник конфликтов.

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

> emerge --sync, как раз, отработает быстро.

> А вот когда машину перед сном, скажем, вырубаешь, одно дело, конда вырубание проходит за 10 секунд, другое - за 5 минут.

Ну ни фига себе. 5 минут... эм... у меня быстрее. Секунд 10-15, максимум 20 на это уходит. 5 минут - это просто невероятно. Честно.

name_no
()
Ответ на: комментарий от MuZHiK-2

>Пользуюсь резером3 уже лет шесть - ни одного файла
Фиксед.

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

> Сказано же выше - генерация squashfs идёт, так что всё ок.

ну я ж не тупой, я ж про неё и говорю

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

Сказано же выше - генерация squashfs идёт, так что всё ок.

combine@mediacenter ~ $ time sudo /etc/init.d/squash_portage restart                               
 * Caching service dependencies ...                                                                                               [ ok ]
 * Service squash_portage stopping                                                                                                      
Parallel mksquashfs: Using 2 processors                                                                                                 
Creating 4.0 filesystem on /var/tmp/portage-current.sqfs, block size 131072.                                                            
[=================================================================================================================-] 114998/114998 100%
Exportable Squashfs 4.0 filesystem, data block size 131072
        compressed data, compressed metadata, compressed fragments
        duplicates are not removed
Filesystem size 46393.55 Kbytes (45.31 Mbytes)
        25.19% of uncompressed filesystem size (184166.46 Kbytes)
Inode table size 1495815 bytes (1460.76 Kbytes)
        34.39% of uncompressed inode table size (4349061 bytes)
Directory table size 1294019 bytes (1263.69 Kbytes)
        36.39% of uncompressed directory table size (3555537 bytes)
No duplicate files removed
Number of inodes 135828
Number of files 114995
Number of fragments 1415
Number of symbolic links  0
Number of device nodes 0
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 20833
Number of ids (unique uids + gids) 2
Number of uids 2
        root (0)
        portage (250)
Number of gids 2
        root (0)
        portage (250)
 * Service squash_portage stopped
 * Service squash_portage starting
 * Service squash_portage started

real    0m21.278s
user    0m13.852s
sys     0m8.443s
name_no
()

Эх, а я уже на ext4 её поменял. Ждём в ванильном ядре.

xetf
()

> Юникод поддерживает? Или как все линаксовые недофс с байтиками из юзерспейса упражняется?

Не нужно.

И да, Reiser _слишком_ долго монтирует ФС без каких-либо выигрышей перед ext4. Недавно я наконец от этой бяки избавился.

anonymous
()

>а reiser4 может и неплохая фс, но ен хочется ею пользоваться из этических соображений. Како-то гадливое чувство возникает.

каждый раз как читаю сообщения подобных "этичных" возникает какое то гадливое чувство

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

+1024
Надо быть сильно травмированным, чтобы ассоциировать одни качества человека с другими. Есть страдающие аутией, и при этом хорошо считают или имеют феноминальную память. Наверное видя их, подобные индивидуумы тоже испытывают гадливое чувство, а уже потом удивляются способностям.
Саб хорош во многих смыслах, и ни какое убийство, ни даже серийное убийство этого не изменит. Пусть даже жертвоприношение, это не важно для кода и тем более не важно для использования этого кода. А если у кому-то не нравится название, то просто думайте что оно возникло как первое слово: сначала был Райзер, потом появилась fs.

ixrws
()

Позитивненько! Удачи Шишкину и всей команде! В памяти отличные впечатления когда юзал reiser3 в корне на десктопе (без каких либо проблем в течении года). На четвертый переходить не стал, думал в свете последних событий умрет. Но нет :) Словом хорошо!

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

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

Все-таки это было жертвоприношение? А я с самого начала догадывался! Пойду пацанам расскажу.

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

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

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

В одном из споров с изенем, я показывал, что после мэйксвапа помирает только xfs, да и то не целиком, так что ext3 и ext4 выживут на 100% точно также.

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

>И да, Reiser _слишком_ долго монтирует ФС

Не помню какими опциями баловался, но это вроде как решается

>без каких-либо выигрышей перед ext4.


В разы меньшее число IO-операций с диском при работе с небольшими файлами, что как бы не может не отражаться на его (диске) здоровье

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

> В разы меньшее число IO-операций с диском при работе с небольшими файлами, что как бы не может не отражаться на его (диске) здоровье

А это не задача ядерного планировщика ввода-вывода? Их в ядре целых три, если что, на всякий вкус.

Пользовался reiserfs пару лет и из особенностей, заметных на глаз, отметил только нездоровую загрузку процессора на файловых операциях по сравнению с той же ext3. А скорость, она для неспециализированных компьютеров больше от характеристик диска зависит.

Я за простые и надежные ФС, и это явно не про субж.

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

плюсую.

юзаю ReiserFS везде. очень рад, что проэкт не умер, а еще таки нормально развивается. ждем в ванильном ядре.

з.ы. на домашней:

# df -hT | grep sd
/dev/sda5 reiserfs     30G   16G   15G  51% /
/dev/sda6 reiserfs     21G   14G  6,3G  69% /mnt/temp
/dev/sda7 reiserfs     30G   24G  6,2G  80% /mnt/doc_leg0las
/dev/sda8 reiserfs     90G   74G   17G  82% /mnt/doc
/dev/sda9 reiserfs    100G   97G  3,8G  97% /mnt/working
/dev/sdb1 reiserfs    466G  410G   57G  88% /mnt/media

leg0las
()
Ответ на: комментарий от post-factum

> Нет, это не задача планировщика ввода-вывода.

Оптимизировать операции ввода-вывода - не задача ядерного планировщика? А какие задачи он у вас выполняет, за пивом бегает, что ли?

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

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

post-factum
() автор топика

Ура, наконец-то прогресс!
ЕМНИП, Шишкин этот документ начал писать вскоре после того как Ганса посадили, я думал он его быстрее должен был закончить..

Anounax
()
Ответ на: комментарий от post-factum

> Не стоит путать оптимизацию ввода-вывода и работу с маленькими файлами.

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

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

> Те, кто так не делал рисковали на ext4 получить в результате внезапной перезагрузки сюрприз

Что удивительно, ставить на /home XFS я перестал в ровности после таких симптомов. Особенно часто таким образом накрывался контакт-лист в LICQ, мир его праху.

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

> Проблема была с обнулением файлов после внезапной перезагрузки (к примеру, из-за отсутствия электричества). Тут даже описывалось, что правильно писать конфиги (и другие важные файлы) в два захода: первым скидывать данные во временный файл, вторым переименовывать под каким нужно именем. Те, кто так не делал рисковали на ext4 получить в результате внезапной перезагрузки сюрприз.

На своей шкуре два раза ощущал. Два раза во время обновления системы. Два раза восстанавливать приходилось ось.

blackst0ne
()

Давно пора. Уже полгода два раздела на reiser4 - полет нормальный.

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

> корень домашней дженты на 3 - жена не дает перейти на 4 ку ;)

ну ты в курсе, что надо делать, да? :)

anonymous
()

>Юникод поддерживает? Или как все линаксовые недофс с байтиками из юзерспейса упражняется?

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

black7
()

>> ext3 -- это то убожество, которое обнуляло содержимое файлов? Кушай свой кактус, приятного аппетита.

>Каким неудачником нужно быть, чтобы заставить ext3 так жестко глюкануть?


вантузятником, очевидно же

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

>Те, кто так не делал рисковали на ext4 получить в результате внезапной перезагрузки сюрприз.

топиковое трололо ж вроде писало про ext3?
у меня на нескольких машинках именно ext3, перебои всякие бывали, но за 9 лет использования проблем не встретил

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

>mksquashfs со сжатием = ускорение в 2-3 раза при первом обращении. При последующих обращениях замеры непринципиальны, т. к. файлы уже закешированы.

они вообщето и без этого чудесно кешируются, если только у тебя не 64Мб ОЗУ, нищеброд, бггг

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

>корень домашней дженты на 3 - жена не дает перейти на 4 ку ;)

Ганс эту проблему решил.

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

>>Чисто из интереса: что ты имел в виду когда спрашивал хранит ли система иена в юникоде: utf-8 или utf-16?

>Это непринципиально. Важно, чтобы внутренняя кодировка была бы стандартизованной и одинаковой на всех поддерживаемых системах, а не байтики, как в ext*

Зачем? Что плохого в байтиках?

sstass
()

> Когда-то был печальный опыт использования reiser3 (накрылась через 2 недели).

ну что за бред, ваш печальный опыт говорит только о вашем опыте. И что в файловой системе может накрыться за 2 недели? или вы ее ради эксперимента поставили на умирающий винт? Ну так тут никакая ФС не поможет.

У меня был радостный опыт использования reiserfs на большом кол-ве компьютеров (что-то порядка 1000). :)

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

>А это не задача ядерного планировщика ввода-вывода? Их в ядре целых три, если что, на всякий вкус.

Нет, reiserfs/reiser4 просто генерируют меньше метаданных, поскольку они плотно упакованы в btree, а не образуют slack-space как в случае с инодами в ext*

>Я за простые и надежные ФС, и это явно не про субж.


У ФС как логической структуры не может быть такого понятия как "надёжность"

>за простые


Сиди тогда на чём сидишь и не высовывайся

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

>перебои всякие бывали, но за 9 лет использования проблем не встретил

вот именно - "не встретил", а вот у людей, к примеру, во времена 2.6.19 торренты сыпались :)

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

во времена 2.6.19 торренты были признаком буржуйства как показатель наличия безлимитного инета :D

ps тупо шутка, не надо воспринимать пост серьезно :)

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

> Убить reiser3? Тогда она точно была стабильной? rebuild-tree делали?

супротив rm -rf / ниодин rebuild-tree не помог бы ему. :)

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

>они вообщето и без этого чудесно кешируются

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

Если мозг еще не до конца выжжен гнойным конъюнктивитом, то ты сможешь понять, почему закешировать ужатый до 46 мб образ squashfs быстрее, чем 600-700 мегабайт тысяч мелких файлов.

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

>Гы-гы. Какого из?

"Гыгыгы". Вопросы научись сначала формулировать. Как подростковая каша в голове пройдет, так сам поймешь дефективность ext*, reiser* и xfs за компанию.

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