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
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.