форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
Сообщение от opennews (??) on 01-Апр-12, 10:02
Крис Мэйсон из компании Oracle представил (https://lkml.org/lkml/2012/3/30/412) большую порцию изменений  в файловой системе Btrfs для будущего ядра Linux 3.4. Среди изменений интеграция подготовленных проектом SUSE патчей с улучшением обработки ошибочных ситуаций, которые позволяют файловой системе прерывать ошибочные транзакции и перейти в режим только для чтения. Также отмечается изменение метода взаимодействия метаданных со страничным кэшем, увеличение агрессивности отбрасывания страниц для метаданных, ставших ненужными, и возможность работы с метаданными блоками крупнее страницы, вплоть до 64Кб (наиболее хорошие результаты наблюдаются с блоками в 16 или 32КБ). Код с поддержкой RAID 5 и 6 запланирован для включения в состав ядра 3.5. URL: http://www.phoronix.com/scan.php?page=news_item&px=MTA3OTk Новость: http://www.opennet.dev/opennews/art.shtml?num=33498
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+9 +/–
Сообщение от Аноним (??) on 01-Апр-12, 10:02
> Код с поддержкой RAID 5 и 6 запланирован для включения в состав ядра 3.5. Вот уже совсем скоро, вот уже сейчас у нас будет БТРФС. Осталось совсем чуть, чуть. :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	22. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	–2 +/–
	Сообщение от Анон on 01-Апр-12, 13:27
	Btrfs не нужна. Её архитектура чересчур кривая, её уже не изменить. Думаю, свою нишу она займёт, но конкурентом ext4 не будет.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	30. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+6 +/–
	Сообщение от VoDA (ok) on 01-Апр-12, 15:52
	> Btrfs не нужна. Её архитектура чересчур кривая, её уже не изменить. Думаю, > свою нишу она займёт, но конкурентом ext4 не будет. Она изначально не конкурент ext4. она конкурирует либо с ZTF либо со стеком raid+lvm+ext4
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	45. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
	Сообщение от лумшт on 01-Апр-12, 18:14
	эх конкурентом зфс она не будет альтернативой да.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	77. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+2 +/–
	Сообщение от Аноним (??) on 02-Апр-12, 15:37
	ZTF - это что?
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	80. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+1 +/–
	Сообщение от Аноним (??) on 03-Апр-12, 01:04
	> ZTF - это что? Гибридная ФС: ZFS + WTF = ZTF :)
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	34. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	–2 +/–
	Сообщение от Аноним (??) on 01-Апр-12, 17:04
	> Btrfs не нужна. Вам не нужна - не пользуйтесь. А мне ври пригодитсяю > Её архитектура чересчур кривая, её уже не изменить. Ну уж не кривее EXT4, особенно поверх LVM со снапшотами или что там еще. > Думаю, свою нишу она займёт, но конкурентом ext4 не будет. Скорее, ext4 ей конкурентом не будет. Одноместный самолет не является конкурентом боингу-767, даже если в какой-то момент времени может доставить вас из точки А в точку Б быстрее.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	81. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
	Сообщение от Аноним (??) on 03-Апр-12, 01:09
	> Btrfs не нужна. Её архитектура чересчур кривая, Уже который раз прошу внятно обосновать чем именно архитектура крива. В ответ приводится или нытье Шишкина, у которого ФС вообще считай что не работает и в обозримом будущем работать не будет, или просто бред. Ну что за лузерство? Обоснуйте. Сами. Без шишкина. На основе своего понимания предмета, оценив суммарное сочетание параметров и сравнив с существующими реализациями. p.s. и кто там ныл про метаданные vs данные: Берем и до упора создаем на ФС диры и файлы 0-го размера. В конечном итоге метаданные выжирают 100% места на томе ибо имена, параметры и иерархию надо где-то хранить. Итого данных на ФС - 0 байтов, метаданных 100% тома. Заметьте, в этой формуле нигде даже тип файловой системы не фигурирует, поэтому приветы шишкину с его наездами. Пусть сперва этот юзкейс к своей ФС применит и расскажет не смущает ли его столь галимое соотношение данных к метаданным в его ФС если он такой умный :)
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

3. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	–1 +/–
Сообщение от jedie on 01-Апр-12, 10:28
А разве поддержка RAID добавляется в файловую систему? Причем тут ФС вообще. Или странная шутка первоапрельская, или я просто не знаю.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	4. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	–1 +/–
	Сообщение от Аноним (??) on 01-Апр-12, 10:53
	БТРФ это как бы клон ЗФС, а в ту запихано все что только можно
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	47. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	–3 +/–
	Сообщение от лумшт on 01-Апр-12, 19:15
	БТРФ это как бы клон ЗФС, а в ту запихано все что только нужно. \\fxd
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	57. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
	Сообщение от Аноним (??) on 02-Апр-12, 00:44
	> БТРФ это как бы клон ЗФС, а в ту запихано все что > только нужно. \\fxd Это не клон, это исправленная и переработанная версия, с учетом опыта ошибок в архитектуре ZFS.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	64. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
	Сообщение от wulf (ok) on 02-Апр-12, 01:20
	> с учетом опыта ошибок в архитектуре ZFS. И какие-же архитектурные ошибки ZFS назовет нам анонимное чудило?
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	70. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
	Сообщение от AlexAT (ok) on 02-Апр-12, 12:05
	>> с учетом опыта ошибок в архитектуре ZFS. > И какие-же архитектурные ошибки ZFS назовет нам анонимное чудило? Как минимум безумная необходимость во всей системной памяти. ARC можно уменьшать, угу, но пользоваться ей при этом трудно.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	71. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
	Сообщение от Wulf (??) on 02-Апр-12, 12:37
	> Как минимум безумная необходимость во всей системной памяти. Это чего за бред? Комфортный объем памяти для ZFS обычно грубо прикидывается как "гиг памяти на терабайт хранилища плюс гиг памяти на 50Gb level2arc". А "безумная необходимость во всей системной памяти" - плод фантазии местных дятлов. > ARC можно уменьшать, угу, но пользоваться ей при этом трудно Второй бред. У меня есть mysql-ные и оракловые сервера, у которых при 32gb ram-а объем arc-а может опускаться до 1Gb. И они прекрасно работают и не тормозят. ЧЯДНТ? Два предложения - две бреда. Вполне в местных традициях.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	73. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
	Сообщение от AlexAT (ok) on 02-Апр-12, 12:50
	> Второй бред. У меня есть mysql-ные и оракловые сервера, у которых при > 32gb ram-а объем arc-а может опускаться до 1Gb. И они прекрасно > работают и не тормозят. ЧЯДНТ? Ага. На солярке, или? Если на солярке - вопрос снят. Если нет - сколько тюнингов вы при этом делали к ZFS? Не совсем понятна необходимость дублировать системный кеш в ARC. Неужели нельзя было интегрироваться? BTRFS, к примеру, вполне себе юзает системный, и не жужжит.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	74. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
	Сообщение от Аноним (??) on 02-Апр-12, 13:17
	Почитать сорцы или хотя бы блог Бонвика уже не судьба, не? ARC сильно иначе работает, чем обычный кэш *NIX-подобных осей. Компрене ву?
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	76. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
	Сообщение от Wulf (??) on 02-Апр-12, 14:33
	> Ага. На солярке, или? Если на солярке - вопрос снят. И на солярке и на bsd Если нет - сколько тюнингов вы при этом делали к ZFS? это про стабильность или производительность? если про первое, то в 8.1 и 8.2 существуют рекомендации ограничить сверху arc на величину расхода памяти ядром и софтом и уменьшить интервал сброса транзакций на диск, дабы обезопасить от 'kmem too small' но в реальности на машинах, где это не было сделано у меня проблем не наблюдалось. в 9.0 и 8.3, на сколько понимаю, и это не нужно. сантехники переделали write-throttling, а бздюки допилили интеграцию до вменяемого состояния. > Не совсем понятна необходимость дублировать системный кеш в ARC. Неужели нельзя было интегрироваться? BTRFS, к примеру, вполне себе юзает системный, и не жужжит. сановцы, на сколько я знаю, пошли на это т.к. собирались не ZFS интегрировать в существующую VM а наоборот, VM в ZFS. А бздюкам такое положение дел досталось "по - наследству" и приоритет работ по интеграции, скажем так, невысокий. И еще, системный кеш в ARC не дублируется. Это просто две системы, выполняющие похожие функции. двойной буферизации между ними, кроме некоторых углов таких, как sendfile() нет.
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	95. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
	Сообщение от iZEN (ok) on 04-Апр-12, 04:08
	>> И какие-же архитектурные ошибки ZFS назовет нам анонимное чудило? > Как минимум безумная необходимость во всей системной памяти. Вы предпочитаете, чтобы оперативная память была на 10-20% занята 90% времени всего аптайма, как в традиционных системах хранения? :) ARC динамически изменяет свой размер, в зависимости от текущих потребностей запущенных и запускаемых приложений, но не может быть меньше 1 ГБ. > ARC можно уменьшать, угу, но пользоваться ей при этом трудно. Разве sysctl-переменные трудно подобрать под задачи? Вот отсюда почитайте: http://forum.ixbt.com/topic.cgi?id=11:43718-47#1338 и до конца обсуждения "тюнинга".
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	82. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
	Сообщение от Аноним (??) on 03-Апр-12, 05:02
	> И какие-же архитектурные ошибки ZFS назовет нам анонимное чудило? Например довольно странную стратегию аллокации блоков класса "ни два ни полтора". Вроде бы блоки уже переменной длины, но слишком мизерные чтобы посчитать это за нормальный экстентный аллокатор. Ну и нафига оно там именно такое?
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	5. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	–2 +/–
	Сообщение от gall on 01-Апр-12, 10:55
	BTRFS - не только ФС, это ещё и менеджер разделов (дикий комбаин короче)! Не unixway...
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	20. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 01-Апр-12, 12:54
	это просто у вас нет понимания что такое юникс вей.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	32. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+4 +/–
	Сообщение от pavlinux (ok) on 01-Апр-12, 16:25
	Народ ждёт! Что ж такое Unix-way FS?
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	33. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+5 +/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 01-Апр-12, 16:42
	а ничего, это же не про фс вовсе. Если в принципе можно ФС разделить на части, то это ещё не значит что так нужно делать и это будет хорошо. С ФС пошли немного другим историческим путём - сначала разделили (точнее, когда-то просто не было менеджера томов и вообще нескольких носителей), а с ростом объёмов оказалось что так делать больше не стоит.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	36. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
	Сообщение от Вася (??) on 01-Апр-12, 17:10
	"Не нравится -- не ешь!"
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	88. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
	Сообщение от Аноним (??) on 03-Апр-12, 16:35
	>  Народ ждёт! Что ж такое Unix-way FS? Судя по ненависти адептов unix-way к бинарному формату - юниксвейная ФС должна представлять собой один большой текстовый файл, непосредственно поверх блочного устройства. Плюсы: не требуется драйвер, достаточно текстового редактора, следовательно, высокая портабельность. Минусы: очень неудобно пользоваться, следовательно, практической пользы ноль. Но юниксвей, к счастью для его адептов, ничего не говорит про удобство и практическую пользу.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	41. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+1 +/–
	Сообщение от Аноним (??) on 01-Апр-12, 17:22
	> BTRFS - не только ФС, это ещё и менеджер разделов (дикий комбаин короче)! Не unixway... Не менеджер разделов, а менеджер томов. Если вы не понимаете в чем отличие, не вам рассуждать о "way-ях" вообще. А чисто технически управление томами из ФС дает ей некие плюсы: ФС в явном виде видит аллокацию места на томах и знает где и что лежит. И поэтому при нужде добавить или убрать том в пул ФС может гибко и быстро перекинуть данные на том или убрать с тома.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	58. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
	Сообщение от Аноним (??) on 02-Апр-12, 00:47
	Может, не сливать все в один ком, а сделать нормальный интерфейс для взаимодействия между уровнями? Все-таки модульность и стекируемость дают определенные преимущества: модули можно заменять, подсистемы в стеке - сочетать в различных вариантах.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	65. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
	Сообщение от gall on 02-Апр-12, 07:47
	Именно этим путём и пошёл Рейзер! Но вот жену за что...
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	96. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
	Сообщение от Masty (ok) on 04-Апр-12, 09:25
	Ну жену-то - понятно! Да и про остальное - тож. :)
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	68. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
	Сообщение от iZEN (ok) on 02-Апр-12, 09:47
	> Может, не сливать все в один ком, а сделать нормальный интерфейс для взаимодействия между уровнями? Слишком большой оверхед не только на пересчёт и подтверждение контрольных сумм данных, но и на протокол взаимодействия между уровнями. Джэф Бонвик уже показал, что будет, если использовать классический стек программных уровней абстракций и взаимодействий вместо прямой интеграции ФС и менеджера томов. > Все-таки модульность и стекируемость дают определенные преимущества: модули можно заменять, подсистемы в стеке - сочетать в различных вариантах. Когда классические ФС отличаются друг от друга только характеристиками алгоритма распределения пространства, не имея особых уникальных фич, то делать под них модульную поддержку не имеет смысла: профита мало, а геморроя с поддержкой много. Лучше абстрагировать систему хранения в наборы данных (датасеты), которое хранилище может иметь много и разных типов. Например, поддержку виртуальных томов фиксированного размера для всех классических ФС,  датасет ФС нефиксированного размера с управляемой сквозной верификацией данных. Со временем может появиться потребность в иных наборах данных, например, датасеты для ротируемого логирования, транзакционной базы данных, отдельный датасет загрузки и восстановления операционной системы и т.д.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	83. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
	Сообщение от Аноним (??) on 03-Апр-12, 05:05
	> Может, не сливать все в один ком, а сделать нормальный интерфейс для > взаимодействия между уровнями? Сильно ограничит возможности алгоритмов - сделать generic интерфейс который бы одинаково хорошо бы лег и на "классику", и на "cow-like" и на что там кто еще придумает - не больно какая простая задача. Рейзер думает что можно CoW сделать как плагин? Можно, но тогда он не сможет пользоваться всеми плюсами этой технологии. И получится довольно компромиссный уродец, и еще не факт что менее уродливый в сумме чем btrfs. Понятие уродливости может варьироваться. И не забываем что "свое не пахнет", поэтому заявления что Мэйсона, что Шишкина что Теодора Тсо что прочих воспринимаем и мотаем на ус, но понимая что сами себя они ругать не склонны и могут сделать себе скидку :)
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	25. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
	Сообщение от Аноним (??) on 01-Апр-12, 14:06
	Рейд может быть и на уровне файлов и файловой системы и логических разделов и мсдосовских и блочных устройств. Или я загнул? =) Имеется ввиду некий внутренный рейд btrfs без использования mdadm и прочего.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	27. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+1 +/–
	Сообщение от jedie on 01-Апр-12, 14:23
	конечно есть софтверный рейд. Но они часто не зависят от FS. В общем ладно.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	42. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
	Сообщение от Аноним (??) on 01-Апр-12, 17:23
	> разделов и мсдосовских и блочных устройств. Или я загнул? =) Да, вы немного загнули. Что есть "мсдосовское устройство" в Linux? :D Хотя в принципе вы правильно поняли. Например, ничему не противоречит если ФС вон тот файл сложит в 2 копиях на 2 шпинделя, а вон тот менее ценный - только 1 раз, на 1 шпиндель.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	48. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	–1 +/–
	Сообщение от лумшт on 01-Апр-12, 19:18
	> Рейд может быть и на уровне файлов и файловой системы и логических > разделов и мсдосовских и блочных устройств. Или я загнул? =) > Имеется ввиду некий внутренный рейд btrfs без использования mdadm и прочего. у меня рейд анонимусов биткоины считает.( и да именно рейд а не кластер)
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	28. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
	Сообщение от Vova (??) on 01-Апр-12, 14:33
	Нет, бтрфс умеет программно соедржать в одном разделе/диске 2 или более физических носителя
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	35. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
	Сообщение от Аноним (??) on 01-Апр-12, 17:10
	> А разве поддержка RAID добавляется в файловую систему? Причем тут ФС вообще. > Или странная шутка первоапрельская, или я просто не знаю. Нет, не шутка - в оригинале новость от 30 марта, кажется. А надо это в основном потому что так ФС может гибче решать что и как, например используя разные уровни райда для данных и метаданных. Более того, там динамическое добавление и изъятие томов - штатная фича. Файловой системе виднее что на ней хранится, поэтому она лучше сделает ребалансинг при добавлении тома или убирание данных с тома при его изъятии. Уровни типа LVM таковыми знаниями не обладают, со всеми вытекающими.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

8. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
Сообщение от chemtech (ok) on 01-Апр-12, 11:04
Интересная переписка Linus Torvalds (цитата) с Chris Mason: > Ok, so presumably num_pages (which is "num_extent_pages(eb->start, > eb->len)") cannot be zero, so I guess the code is ok. But gcc can't > know that, and it's an annoying warning. Whoops, my reply was too slow, sorry.  If you're curious my gcc that doesn't warn in 4.6.3.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

9. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	–3 +/–
Сообщение от oneonfire on 01-Апр-12, 11:21
Btrfs - это конечно же хорошо, но очень жаль, что никого не интересует Reiser4, а ведь она гораздо продуманей
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	10. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
	Сообщение от СуперАноним on 01-Апр-12, 11:49
	Шишкин вроде в нормальных отношениях с разработчиками BTRFS. Поэтому написать ему коллективное письмо с просьбой убедить разработчиков БТРа использовать инновации из Reiser4 в BTRFS2. Коль уж Торвальдсу так не нравится слово "Reiser" в названии ФС.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	12. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+2 +/–
	Сообщение от Аноним (??) on 01-Апр-12, 11:59
	> Коль уж Торвальдсу так не нравится слово "Reiser" в названии ФС. Про фамилии и личности - это, в общем-то, стеб. В подобных патчах Торвальдсу всегда не нравится одно и то же: косячность и бесполезность. Даже Шишкину влом допиливать это чудо, а над нормальными фс по несколько разработчиков трудятся на полный день. Да и в чем бонусы reiser4? Там хоть снапшоты-то есть?
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	18. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
	Сообщение от oneonfire on 01-Апр-12, 12:13
	Да мне кажется эту возможность можно добавить как плагин, было бы только кому...
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	26. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
	Сообщение от Куяврик on 01-Апр-12, 14:13
	Там система позволяет плагины. и это хорошо. при чём в FS плагины на мой взгляд очень хорошо. а вот в компиляторе - неясно зачем.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	37. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+1 +/–
	Сообщение от Аноним (??) on 01-Апр-12, 17:11
	> а вот в компиляторе - неясно зачем. Под всякие нестандартные загибоны. И да, если падение компилера из-за бага в плагине можно пережить, то вот для файловой системы это уже совсем другой уровень грабель.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	67. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
	Сообщение от Клыкастый (ok) on 02-Апр-12, 08:15
	>> а вот в компиляторе - неясно зачем. > Под всякие нестандартные загибоны. И да, если падение компилера из-за бага в > плагине можно пережить, Да и не в плагине. > то вот для файловой системы это уже совсем другой уровень грабель. да и не в плагине походу слово "плагин" тут лишнее
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	84. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
	Сообщение от Аноним (??) on 03-Апр-12, 05:23
	> Да и не в плагине. А вот это уже как повезет. Прикиньте, вопрос на миллион а тут такой факап. Не больно то приятно переживать, да? :) >> то вот для файловой системы это уже совсем другой уровень грабель. > да и не в плагине Именно. А плагинный интерфейс мало того что усложнит все, так еще и отлаженность плагинов и неизменность интерфейса - под вопросом. > походу слово "плагин" тут лишнее Вот поэтому я и думаю - а не оверкилл ли все делать через плагины? Сама ФС тоже в каком-то роде плагин к ядру. Плагин к плагину - не сильно ли круто?
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	86. "Для будущего ядра Linux 3.4 представлена большая серия..."	+/–
	Сообщение от arisu (ok) on 03-Апр-12, 12:50
	> Плагин к плагину — не сильно ли круто? авторы FUSE смотрят на тебя несколько удивлённо и озадачено.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	52. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	–1 +/–
	Сообщение от Аноним (??) on 02-Апр-12, 00:36
	> Там система позволяет плагины. и это хорошо. при чём в FS плагины на мой взгляд очень хорошо. А эти плагины позволяют сделать снапшоты, cow, сквозное чексуммирование с автоматическим восстановлением из избыточных копий?
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	69. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
	Сообщение от Я (??) on 02-Апр-12, 10:27
	и не только это
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	66. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
	Сообщение от anonymous (??) on 02-Апр-12, 08:07
	Хотелось бы, что это было реализовано, а не "позволяли плагины".
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	13. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+1 +/–
	Сообщение от Аноним (??) on 01-Апр-12, 11:59
	> Reiser4, а ведь она гораздо продуманей А в чем это проявляется, если не секрет?
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	15. "Для будущего ядра Linux 3.4 представлена большая серия..."	+4 +/–
	Сообщение от arisu (ok) on 01-Апр-12, 12:01
	>> Reiser4, а ведь она гораздо продуманей > А в чем это проявляется, если не секрет? пишут дольше. значит, дольше думали.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	16. "Для будущего ядра Linux 3.4 представлена большая серия..."	+5 +/–
	Сообщение от Аноним (??) on 01-Апр-12, 12:03
	> пишут дольше. значит, дольше думали. Тогда реактос должен вообще быть идеальной и безглючной осью :)
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	17. "Для будущего ядра Linux 3.4 представлена большая серия..."	+/–
	Сообщение от Аноним (??) on 01-Апр-12, 12:05
	> пишут дольше. значит, дольше думали. Есть подозрение, что все эти годы Шишкин думал главным образом не о том, как улучшить reiser4, а о том, что бы такое накодить, чтоб заработать на жизнь. Потому что в разработку reiser4, afaik, никто и никогда бабла не вкладывал.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	38. "Для будущего ядра Linux 3.4 представлена большая серия..."	+/–
	Сообщение от Аноним (??) on 01-Апр-12, 17:13
	> чтоб заработать на жизнь. Потому что в разработку reiser4, afaik, никто > и никогда бабла не вкладывал. Так чтобы в вас вложили бабло - кому-то должно стать понятно что вы - нужны. Именно им. Именно в таком виде. А вот с этим у излишне академствующих господ напряженка.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	59. "Для будущего ядра Linux 3.4 представлена большая серия..."	+/–
	Сообщение от Аноним (??) on 02-Апр-12, 00:55
	XFS и первый рейзер (точнее, третий) создали именно "академствующие господа". Шишкин об этом упоминал в интервью
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	85. "Для будущего ядра Linux 3.4 представлена большая серия..."	+/–
	Сообщение от Аноним (??) on 03-Апр-12, 05:24
	> XFS и первый рейзер (точнее, третий) создали именно "академствующие господа". Шишкин об > этом упоминал в интервью Ага, и где теперь SGI? Где рейзер я и так знаю. Кстати парни с amule.org громко чертыхались за то что fsck третьего рейзера сделал им из тома полные макароны.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	87. "Для будущего ядра Linux 3.4 представлена большая серия..."	+/–
	Сообщение от Аноним (??) on 03-Апр-12, 15:21
	> Ага, и где теперь SGI? SGI больше нет, но их творение их надолго пережило и сейчас успешно развивается. Это разве не показатель?
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	91. "Для будущего ядра Linux 3.4 представлена большая серия..."	+/–
	Сообщение от Аноним (??) on 04-Апр-12, 01:25
	> SGI больше нет, но их творение их надолго пережило и сейчас успешно > развивается. Это разве не показатель? Показатель чего? Обычная такая ФС, на уровне всех остальных современных. В свое время очень всех донимала убиением файлов нулями, кстати. Окончательно додавили этот фичебаг в районе 2.6.28 примерно, после чего им даже стало можно пользоваться более-менее. Загнать XFS в тормоза - не так уж и сложно. В некоторых случаях он сииииильно тупит при работе с метаданными. Например на куче мелочи ext4 его обставляет на раз. В общем SGIшники делали ФС для видеомонтажа. Да, с операциями такого плана, когда многогиговые файлы да еще в несколько потоков писать надо - оно справляется хорошо. А остальное - как повезет.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	19. "Для будущего ядра Linux 3.4 представлена большая серия..."	–2 +/–
	Сообщение от oneonfire on 01-Апр-12, 12:16
	Ну вот согласен на все 100% с человеком, продуманность архитектуры Reiser4 просто на высоте, не то что там Btrfs...
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	44. "Для будущего ядра Linux 3.4 представлена большая серия..."	+5 +/–
	Сообщение от Аноним (??) on 01-Апр-12, 18:02
	> Ну вот согласен на все 100% с человеком, продуманность архитектуры Reiser4 просто > на высоте, не то что там Btrfs... В конечном итоге засчитывается не сам по себе абстрактный полет инженерной мысли в сферическом вакууме, а как оно ездит, летает, плавает, хранит данные и прочая, увы и ах...
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	53. "Для будущего ядра Linux 3.4 представлена большая серия..."	+/–
	Сообщение от Аноним (??) on 02-Апр-12, 00:38
	> Ну вот согласен на все 100% с человеком, продуманность архитектуры Reiser4 просто > на высоте, не то что там Btrfs... Судя по отсутствию конкретного ответа - это просто повторение некой мантры, ничего не понимая в архитектурах ФС.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	72. "Для будущего ядра Linux 3.4 представлена большая серия..."	+/–
	Сообщение от z (??) on 02-Апр-12, 12:39
	Мэнсон, очевидно, всё понимает в btrfs, раз при определённых условиях она начинает пухнуть от метаданных -- кто бы говорил про архитектуру =) Дурные задумки никакое "допиливание" не исправит
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	92. "Для будущего ядра Linux 3.4 представлена большая серия..."	+/–
	Сообщение от Аноним (??) on 04-Апр-12, 01:27
	> раз при определённых условиях она начинает пухнуть от метаданных Чувак, создай у себя на ФС миллионы файлов 0-го размера. И удивись: ты записал 0 байтов полезных данных, а место куда-то схавалось. Наверное, потому что параметры файлов и их имена надо где-то хранить. Вывод: твоя ФС полный отстой. Ее кпд оказался равен нулю. Хоть я и не знаю какая у тебя ФС, но к ней это 100% применимо. Так своему шишкину и передай.
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	97. "Для будущего ядра Linux 3.4 представлена большая серия..."	+/–
	Сообщение от z (??) on 04-Апр-12, 15:17
	Некорректно выразился: не за счёт самих метаданных, конечно же, а за счёт дикой внутренней фрагментации, где метаданным тоже места не остаётся: > It is a well known fact that internal fragmentation of classic Bayer's > B-trees is restricted by the value 0.50 (see Appendix C). However it > takes place only if your tree contains records of the _same_ length > (for example, extent pointers). Once you put to your B-tree records > of variable length (restricted only by leaf size, like btrfs "inline > extents"), your tree LOSES this boundary Внимательно почитайте и вдумайтесь, на что Шишкин ругается, перед своим следующим сочинением Повторюсь: дефектный дизайн никаким допиливанием не исправить
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	21. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+5 +/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 01-Апр-12, 12:56
	Продумана с т.н. академической точки зрения, т.е. для юз.кейсов родившихся в чей-то фантазийной головое и далёких от реальных потребностей.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	29. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	–1 +/–
	Сообщение от Vova (??) on 01-Апр-12, 14:36
	проблема не втом что она "не нужна". Она как раз таки очень даже нужна. Но в ядро её принимать почему-то не хотят. Хотя я даже слышал, что рейзер4 стабильней нынешней бтрфс.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	31. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+3 +/–
	Сообщение от VoDA (ok) on 01-Апр-12, 15:57
	> проблема не втом что она "не нужна". Она как раз таки очень > даже нужна. Но в ядро её принимать почему-то не хотят. Хотя > я даже слышал, что рейзер4 стабильней нынешней бтрфс. а чего тогда эти, которым нужна, не запилили ФС до требуемого для приема уровня и не подписались на длительную поддержку своего творения в ядре?
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	60. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
	Сообщение от Аноним (??) on 02-Апр-12, 00:57
	Не сумели найти общий язык с разработчиками ядра. Конкретную причину сложно указать, но весьма вероятно, что это чистая политика и взаимоотношения, а не техническая реализация
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	61. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
	Сообщение от Аноним (??) on 02-Апр-12, 01:00
	Вдогонку. Вспомнил, Шишкин указывал, что, например, рейзер4 не принимали в ядро из-за наличия в ней менеджера томов - дескать, у нас уже есть LVM, так что используй его. Хотя той же btrfs с ее собственным менеджером томов дан зеленый свет.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	79. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
	Сообщение от ЗлО on 02-Апр-12, 18:46
	Нет, там в основном все наезды были реализацию всего через на плагины и сильное изменение семантики vfs. В btrfs таких вещей меньше. А так, наверное да интересно было бы увидеть WAFL вместо vfs...
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	39. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+1 +/–
	Сообщение от Аноним (??) on 01-Апр-12, 17:18
	> проблема не втом что она "не нужна". Она как раз таки очень > даже нужна. Но в ядро её принимать почему-то не хотят. Апстрим и даунстрим не нашли общего языка и не пришли к взаимопониманию. Вообще, рейзер - традиционная для академиков вещь. Т.е. задумано вроде бы круто с академической точки зрения, а с практической - у рейзера3 fsck до сих пор может том окончательно угробить вместо починки, чинить это никто не собирается, etc - по сути сказали что "known issue" и ... все.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	43. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
	Сообщение от oneonfire on 01-Апр-12, 17:26
	Я же написал про Reiser4, а это совсем иная файловая система чем Reiser 3
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	55. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
	Сообщение от Аноним (??) on 02-Апр-12, 00:41
	> Я же написал про Reiser4, а это совсем иная файловая система чем > Reiser 3 Но отношение Райзера к стабильности и ценности данных этот пример неплохо иллюстрирует.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	93. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
	Сообщение от Аноним (??) on 04-Апр-12, 01:31
	> Я же написал про Reiser4, а это совсем иная файловая система чем Reiser 3 ФС другая, а авторы те же самые. Где на этот раз они так же продолбутся? Что, на reiser3 томе нельзя хранить образа иных томов в reiser3 иначе fsck может "починить" фс в полные макароны? А им не кажется что добавить safeguards против таких факапов - не настолько уж и ракетная наука? Хотя конечно забавнее рассказывать о том что это ограничение ФС, а то что том при запуске fsck убился в вермишель - by design. Знаете, а мне вот ссыкотно такой by design использовать с такими known issues, даже если он и крут чисто академически...
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	46. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+2 +/–
	Сообщение от ананим on 01-Апр-12, 18:17
	> Хотя я даже слышал Слухи, скандалы, расследования. Зыж Пол-разработчика вас на это натолкнуло? Который сам не знает бу или не бу что-то там с ней делать.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	54. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
	Сообщение от Аноним (??) on 02-Апр-12, 00:39
	> проблема не втом что она "не нужна". Она как раз таки очень > даже нужна. Но в ядро её принимать почему-то не хотят. Хотя > я даже слышал, что рейзер4 стабильней нынешней бтрфс. В ядро ее не хотят принимать по очевидной причине - проблем со стабильностью полные штаны, бонусов ноль.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	63. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
	Сообщение от Аноним (??) on 02-Апр-12, 01:03
	Проблемы со стабильностью бывают как раз, когда не хватает разработчиков и тестеров, когда проектом никто не занимается. btrfs тоже, поди, немного умела сразу после своего появления на свет, но ее приняли в ядро довольно давно, несмотря на нестабильность
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

23. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
Сообщение от Raiden (ok) on 01-Апр-12, 13:46
А 1.0 или хотя бы замарозка формата и фич когда планируется? :) Какие-нить планы есть по датам? Короче объясните когда его считать стабильым истоит ли вообще ждать это в ближайшем будущем :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	24. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+1 +/–
	Сообщение от AlexAT (ok) on 01-Апр-12, 13:55
	Предположительный ответ: 1, 2 - ASAP 3 - нет, ASAP
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	40. "Для будущего ядра Linux 3.4 представлена большая серия измен..."	+/–
	Сообщение от Аноним (??) on 01-Апр-12, 17:19
	> истоит ли вообще ждать это в ближайшем будущем :) Зависит от того что понимать под ближайшим будущим :). Если завтра - нет, завтра оно готово еще не будет. Если через 1-2 годка - думаю что окончательно устаканится как раз.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема