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

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

"Файловая система Tux3 предложена для включения в состав ядра..."	+/–
Сообщение от opennews on 18-Май-14, 20:27
Файловая система Tux3 (http://tux3.org/), известная своими достижениями в области производительности (в одном из тестов Tux3 смог обогнать tmpfs, что ранее считалось невозможным) предложена (https://lkml.org/lkml/2014/5/16/708) для включения в состав ядра Linux. Файловая система Tux3 разрабатывается (http://www.opennet.me/opennews/art.shtml?num=17130) с 2008 года и является версионной файловой системой. В 2009 году работа над Tux3 была приостановлена, но в начале 2013 года проект возродился (http://www.opennet.me/opennews/art.shtml?num=35741) и начал интенсивно развиваться. Для хранения большинства структур используются b-tree и предложенные автором Tux3 версионированные указатели. Файловая система обеспечивает атомарные транзакции и запись в произвольные области ("write-anywhere"). Разработчики данной файловой системы считают, что CoW-подобная файловая система ("copy on write") с хорошим контролем консистентности не обязана быть ресурсоемкой и приводить к заметным накладным расходам. Поэтому, при разработке Tux3 большое внимание уделяется скорости работы файловой системы и низкому потреблению ресурсов, в частности в Tux3 используется принципиально новый вид структур - "версионированные указатели". По мнению разработчиков, кодовая база драйвера файловой системы достигла состояния, когда становится возможным включить драйвер в состав ядра Linux. Отмечатеся, что текущий код может быть интегрирован в ядро вообще без изменений API ядра. Тем не менее, некоторые изменения API могли бы позволить делать ряд операций более естественно. URL: https://lkml.org/lkml/2014/5/16/708 Новость: http://www.opennet.me/opennews/art.shtml?num=39802
Ответить | Правка | Cообщить модератору

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

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

1. "Файловая система Tux3 предложена для включения в состав ядра..."	–10 +/–
Сообщение от rob pike on 18-Май-14, 20:27
Вовремя. В ITS это сделали в 1960 г., в RSX-11 и VMS попозже, теперь и Linux подтянулся.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	14. "Файловая система Tux3 предложена для включения в состав ядра..."	+1 +/–
	Сообщение от Аноним (??) on 19-Май-14, 00:16
	Ты что-то попутал.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	19. "Файловая система Tux3 предложена для включения в состав ядра..."	+1 +/–
	Сообщение от Аноним (??) on 19-Май-14, 07:41
	Сделали ... что? Tux3? Что вы там курите, гражданин?
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	43. "Файловая система Tux3 предложена для включения в состав ядра..."	+1 +/–
	Сообщение от rob pike on 19-Май-14, 12:06
	Версионность.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	45. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от Аноним (??) on 19-Май-14, 14:44
	Гладиолус?
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	47. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от Аноним (??) on 19-Май-14, 15:11
	> Версионность. Версионность *указателей*?
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	65. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от rob pike on 19-Май-14, 16:33
	А я уж обрадовался что таки данных. ОК, подождем еще 50 лет.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	81. "Файловая система Tux3 предложена для включения в состав ядра..."	+2 +/–
	Сообщение от Аноним (??) on 20-Май-14, 09:17
	Если отпустить ручник, можно обнаружить что снапшоты - нечто такое и есть.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

2. "Файловая система Tux3 предложена для включения в состав ядра..."	+3 +/–
Сообщение от Аноним (??) on 18-Май-14, 21:17
> в одном из тестов Tux3 смог обогнать tmpfs Как это возможно? Или это тестировалось на SSD? В таком случае ещё может быть..
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	4. "Файловая система Tux3 предложена для включения в состав ядра..."	+1 +/–
	Сообщение от Xasd (ok) on 18-Май-14, 21:53
	очень легко! вся суть в том как это сказали -- ключевое слово "в одном" ("в одном из тестов") :-) стоит предположить что остальные операции (остальные тесты) -- там выполняются со вполне обычной или даже более медленной скоростью (по сравнению с Ext4)
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	9. "Файловая система Tux3 предложена для включения в состав ядра..."	+1 +/–
	Сообщение от Xasd (ok) on 18-Май-14, 23:12
	тем кто минусанул -- хочу напомнить что чудес не бывает. :) в любой (популярной) файловой системе разработчики уделяют скорости -- важную роль. разработчики какой файловой системы думают "скорость?! ды кому она нужна?"? :-) вопрос лишь в том -- под какие виды операций-и-условий та-или-иная файловая система более оптимально подходит, а под какие виды операций-и-условий менее оптимально подходит. ...ну и конечно же в том какой ценой удаётся эта скорость. побочные-то эффекты они обязательно будут... но нам то (пользователям) ведь главное НЕ чтобы не было бы побочных эффектов, а то чтобы эти побочные эффекты были бы НЕраздражающими для нас. например если файловая система медленее закрывает файлы и медленее освобождает ресурсы -- то думаю это как раз хороший пример НЕраздражающего побочного эффекта. :)
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	17. "Файловая система Tux3 предложена для включения в состав ядра..."	+2 +/–
	Сообщение от Аноним (??) on 19-Май-14, 04:12
	> разработчики какой файловой системы думают "скорость?! ды кому она нужна?"? glusterfs :-)
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	18. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от Аноним (??) on 19-Май-14, 06:28
	Полностью согласен, тоэтому комбайн в виде zfs вполне нормально существует, потому что можно подкрутить для твоего юзкейса.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	21. "Файловая система Tux3 предложена для включения в состав ядра..."	–2 +/–
	Сообщение от Аноним (??) on 19-Май-14, 07:45
	> можно подкрутить для твоего юзкейса. Да щаз. Отсутствие нормального управления памятью кеша и тормознутость дизайна без подпора много гигазов оперативы - не лечатся. Хоть крути, хоть не крути. "Крутите свои, они вам больше не понадобятся".
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	41. "Файловая система Tux3 предложена для включения в состав ядра..."	–4 +/–
	Сообщение от rob pike on 19-Май-14, 12:05
	>без подпора много гигазов оперативы Зачем вы засунули ZFS в кофеварку?
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	50. "Файловая система Tux3 предложена для включения в состав ядра..."	+1 +/–
	Сообщение от Аноним (??) on 19-Май-14, 15:22
	> Зачем вы засунули ZFS в кофеварку? Правильно, кофеварки и без CoW обойдутся. Нехай рушат файлы при записи или дико тормозят.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	63. "Файловая система Tux3 предложена для включения в состав ядра..."	–1 +/–
	Сообщение от rob pike on 19-Май-14, 16:08
	Ну смешно ведь предъявлять кофеварочные претензии к FS, которая была сделана для совершенно других применений.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	82. "Файловая система Tux3 предложена для включения в состав ядра..."	+1 +/–
	Сообщение от Аноним (??) on 20-Май-14, 09:20
	> Ну смешно ведь предъявлять кофеварочные претензии к FS, которая была сделана для > совершенно других применений. Потому что это generic претензии к "дизайну ФС вообще", абстрактно от того под что она там делалась. Но да, вы правы - единственным вменяемым сценарием использования ZFS смотрятся файлсерверы на которых ничего другого не работает. Но это довольно нишевое применение. А btrfs делался как более-менее generic файловая система.
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	90. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от rob pike on 20-Май-14, 13:57
	> Потому что это generic претензии к "дизайну ФС вообще", абстрактно от того Не бывает "ФС вообще", тем более их дизайнов. Это простое инженерное ремесло, верно выбранный набор компромиссов, а не абстракции из слоновой кости.
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	96. "Файловая система Tux3 предложена для включения в состав ядра..."	+1 +/–
	Сообщение от Аноним (??) on 20-Май-14, 20:47
	> Не бывает "ФС вообще", тем более их дизайнов. Это простое инженерное ремесло, > верно выбранный набор компромиссов, а не абстракции из слоновой кости. Все так. И ZFS в этом плане - весьма странный монстр, единственное вменяемое примение оному в том виде каком он есть я вижу только на мощных серверах с кучей оперативы. Иначе весьма заурядные дисковые структуры будут тормозить. А рамдиски - они что, они быстрые по жизни. Поэтому чем ближе к рамдиску - тем меньше тормозов. При том сервера - целиком отданные под файлопомойку. Из-за своеобразного управления памятью, которое на десктопе/рабочей станции/сервере приложений/etc сможет вызвать море лулзов с внезапной нехваткой памяти. Хотя можно превратить юзера в педальный привод системы управления кешом и сказать что пусть вручную конфигуряет, компенсируя бестолковости дизайна руками.
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	105. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от rob pike on 22-Май-14, 01:32
	> Все так. И ZFS в этом плане - весьма странный монстр, единственное > вменяемое примение оному в том виде каком он есть я вижу > только на мощных серверах с кучей оперативы. Оперативы нынче дешевы. За менее чем $10,000 легко получается 384 GB (и современных Xeon-овых ядер штук 12, с парой пар дисков по 3-4 TB) в 1U корпусе. И с возможностью апгрейда до 1.5 TB RAM потом.
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	25. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от Xaionaro (ok) on 19-Май-14, 08:35
	> тем кто минусанул -- хочу напомнить что чудес не бывает. :) А вроде никто и не говорит про чудо. Тут ведь никто не говорит, что на терабайтный винчестер влезает целый эксабайт сжатой информации? Речь просто про performance-oriented next-gen FS со вполне правдоподобными результатами.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	77. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от Аркадий (??) on 19-Май-14, 22:50
	> performance-oriented next-gen Больше булшита хорошего и разного.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	79. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от Xaionaro (ok) on 19-Май-14, 22:52
	>> performance-oriented next-gen > Больше булшита хорошего и разного. Какое-то обоснование последует?
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	97. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от Аноним (??) on 20-Май-14, 20:49
	> Какое-то обоснование последует? Там в списке рассылки - "Ох, Василий Иваныч, он так мативировал, так мативировал! И вас, и меня мативировал!"
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	51. "Файловая система Tux3 предложена для включения в состав ядра..."	–1 +/–
	Сообщение от vlikhachev (ok) on 19-Май-14, 15:26
	> разработчики какой файловой системы думают "скорость?! ды кому она нужна?"? :-) FUSE!!! FUSE!!! FUSE!!!
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	53. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от Аноним (??) on 19-Май-14, 15:30
	> FUSE!!! FUSE!!! FUSE!!! FAT еще. На сколь-нибудь разлапистой иерархии ему наступает это самое :)
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	54. "Файловая система Tux3 предложена для включения в состав ядра..."	+1 +/–
	Сообщение от pavel_simple (ok) on 19-Май-14, 15:33
	>> разработчики какой файловой системы думают "скорость?! ды кому она нужна?"? :-) > FUSE!!! FUSE!!! FUSE!!! FUSE это не файловая система -- это фреймворк для написания оных в юзерспейсе -- причём тормоза описаны сразу при входе в тему -- потому как переключения контекста операция ресурсоёмкая.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	64. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от Xaionaro (ok) on 19-Май-14, 16:11
	>> разработчики какой файловой системы думают "скорость?! ды кому она нужна?"? :-) > FUSE!!! FUSE!!! FUSE!!! Честно сказать, я вас не понял причём тут «FUSE»…
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	83. "Файловая система Tux3 предложена для включения в состав ядра..."	–1 +/–
	Сообщение от Аноним (??) on 20-Май-14, 09:21
	> Честно сказать, я вас не понял причём тут «FUSE»… Тормозит хорошо. Как правило упираясь в проц, ибо переключает контексты оптом и в розницу :)
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	91. "Файловая система Tux3 предложена для включения в состав ядра..."	+1 +/–
	Сообщение от Xaionaro (ok) on 20-Май-14, 15:50
	>> Честно сказать, я вас не понял причём тут «FUSE»… > Тормозит хорошо. Как правило упираясь в проц, ибо переключает контексты оптом и > в розницу :) 1. FUSE — это не файловая система. Использование FUSE тормозит процесс, но это не говорит о тормознутости самой файловой системы (как теоретической задумки). 2. Subj-евая ФС вроде как раз говорит о том, что хочет перейти прямо в ванильное ядро. Так что, опять же, FUSE не при чём.
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	75. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от кевин on 19-Май-14, 18:27
	ага. помню шутку про фс /dev/null скорость записи в которую достигает бесконечности...
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	98. "Файловая система Tux3 предложена для включения в состав ядра..."	–1 +/–
	Сообщение от Аноним (??) on 20-Май-14, 20:50
	> достигает бесконечности... Беру килограмм бесконечно быстрой оперативки :).
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	6. "Файловая система Tux3 предложена для включения в состав ядра..."	+2 +/–
	Сообщение от rob pike on 18-Май-14, 22:35
	http://lkml.iu.edu//hypermail/linux/kernel/1305.0/03713.html
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	78. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от ZloySergant (ok) on 19-Май-14, 22:50
	> ...the code that produces this benchmark currently relies on this benchmark-specific hack to speed up inode number allocation. Угум. Метко подмечено.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	26. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от Xaionaro (ok) on 19-Май-14, 08:36
	>> в одном из тестов Tux3 смог обогнать tmpfs > Как это возможно? Или это тестировалось на SSD? В таком случае ещё > может быть.. Мне кажется, что для корректного сравнения (чтобы исключить влияние аппаратной составляющей), всей тесты производились прямо в ОЗУ.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	74. "Файловая система Tux3 предложена для включения в состав ядра..."	–1 +/–
	Сообщение от Аноним (??) on 19-Май-14, 18:26
	Нашли граничный случай когда диск вообще не используется, а при обработке структур в памяти tux3 работает эффективнее чем tmpfs (скажем, использует дерево, где в tmpfs список, посколько эта такая маргинальная ситуация что дерева не требует). Собственно и всё - в одном тесте вау-вау, обогнали саму tmpfs, а в других фейл на фейле.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	87. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от anonymous (??) on 20-Май-14, 12:21
	Сравнивалась Tux3 поверх рамдиска с tmpfs. При таком раскладе вряд-ли Tux3 единственная, кто может нагнуть tmpfs.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	99. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от Аноним (??) on 20-Май-14, 20:51
	> вряд-ли Tux3 единственная, кто может нагнуть tmpfs. Да вот единственная как оказалось...
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

3. "Файловая система Tux3 предложена для включения в состав ядра..."	–1 +/–
Сообщение от Anonymus on 18-Май-14, 21:26
Вах, b-tree! Великое достижение. Кста чо там, рейзеру-то долго ещё сидеть?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	5. "Файловая система Tux3 предложена для включения в состав ядра..."	+1 +/–
	Сообщение от Аноним (??) on 18-Май-14, 21:57
	ему пожизненное дали
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	15. "Файловая система Tux3 предложена для включения в состав ядра..."	+11 +/–
	Сообщение от Anonymus on 19-Май-14, 00:24
	беда с этими бабами
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	7. "Файловая система Tux3 предложена для включения в состав ядра..."	+8 +/–
	Сообщение от rob pike on 18-Май-14, 22:35
	> Вах, b-tree! Великое достижение С годами хуже не становится
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	10. "Файловая система Tux3 предложена для включения в состав ядра..."	–1 +/–
	Сообщение от Эргил on 18-Май-14, 23:14
	В 2019 году может подать первое прошение о досрочном освобождении. А так долго-не долго, до конца жизни, если досрочку не дадут.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	11. "Файловая система Tux3 предложена для включения в состав ядра..."	–1 +/–
	Сообщение от Денис (??) on 18-Май-14, 23:23
	так он же все, вроде вроде в физику/математику подался
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	22. "Файловая система Tux3 предложена для включения в состав ядра..."	+1 +/–
	Сообщение от Аноним (??) on 19-Май-14, 07:47
	> Вах, b-tree! Великое достижение. Годы идут, а фундаментальные удачные структуры - меняются мало. А вот версионированные указатели в том виде как у них - вроде их собственное изобретение.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	30. "Файловая система Tux3 предложена для включения в состав ядра..."	+1 +/–
	Сообщение от Аноним (??) on 19-Май-14, 10:36
	> Вах, b-tree! Великое достижение. Ой, а вон трансформаторы вообще более ста лет делают путем намотки медного провода вокруг железного сердечника. А оно все работает и работает.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	35. "Файловая система Tux3 предложена для включения в состав ядра..."	–2 +/–
	Сообщение от Anonymus on 19-Май-14, 11:30
	Я и про транзисторы какбэ вкурсе, но с другой стороны мегагерцы-то поисчерпались уже лет десять тому назад.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	39. "Файловая система Tux3 предложена для включения в состав ядра..."	+1 +/–
	Сообщение от Andrey Mitrofanov on 19-Май-14, 11:50
	> Я и про транзисторы какбэ вкурсе, но с другой стороны мегагерцы-то А про микросхемы, гигагерцы и ферриты, в курсе? Держи нас в!
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	40. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от rob pike on 19-Май-14, 11:51
	> мегагерцы-то поисчерпались И начались ухищрения с кэшами да конвейерами. Вот тут и выяснилось что b-tree опять живее всех живых.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	52. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от Аноним (??) on 19-Май-14, 15:28
	> Вот тут и выяснилось что b-tree опять живее всех живых. Опять? А что, когда-то "умирали" чтоли?
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	62. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от rob pike on 19-Май-14, 16:04
	Да, одно время считались очень немодными. Много чего прогрессивного придумали, в частности многоуровневые log-structured merge-trees.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	102. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от Аноним (??) on 21-Май-14, 03:09
	> Да, одно время считались очень немодными. Честно говоря - не заметил чтобы софт переставал ими пользоваться. Хотя это больше про софт вообще, не только файловые системы. > Много чего прогрессивного придумали, в частности многоуровневые log-structured merge-trees. Да разных вариантов деревьев придумано немеряно. Я просто к тому что не видел чтобы софт переставал b-tree использовать, поэтому вспоминается Марк Твен - "слухи о моей смерти были сильно преувеличены".
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	104. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от rob pike on 22-Май-14, 01:28
	Практически все storage engines, появившиеся за последние годы используют модные LSM -   HBase, LevelDB, SQLite 4, Cassandra
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	37. "Файловая система Tux3 предложена для включения в состав ядра..."	–1 +/–
	Сообщение от Anonymus on 19-Май-14, 11:32
	Или предлагается сбацать файловую систему на трансформаторах? :))) Мотать замучаешься
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	55. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от Аноним (??) on 19-Май-14, 15:33
	> Или предлагается сбацать файловую систему на трансформаторах? :))) Мотать замучаешься Нет, намекается что алгоритмы типа "b-tree" вполне могут точно так же прожить свой стольник лет, припеваючи. А что им будет то?
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	66. "Файловая система Tux3 предложена для включения в состав ядра..."	+1 +/–
	Сообщение от rob pike on 19-Май-14, 16:53
	И лампах. Тёплую, аналоговую файловую систему. Звуковым файлам она будет придавать прозрачную середину, графическим - объем и выразительность. А текстовым - смысл и содержательность.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	80. "Файловая система Tux3 предложена для включения в состав ядра..."	–2 +/–
	Сообщение от maximnik0 on 20-Май-14, 00:22
	> Ой, а вон трансформаторы вообще более ста лет делают путем намотки медного > провода вокруг железного сердечника. А оно все работает и работает. И тут есть прогресс - изобретенны плоско-пластинчатые трансформаторы ,в них металических катушек и сердечников нет (кроме внешнего экрана )  .Пока по этой технологии делают блоки питания к ноутбукам .Все просто - на изолятор пластину наносят (наклеивают ) катушки индуктивности (как в совеских электромеханических часах )  и наберают нужное кол-во пластин для получение нужной мощности ,рассевание магнитного поля минимальное,соответственно выше кпд ,железа нет меньше габариты и вес  .
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	84. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от Аноним (??) on 20-Май-14, 09:25
	> металических катушек и сердечников нет ... > (наклеивают ) катушки индуктивности Взаимоисключающие параграфы - они такие...
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	88. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от maximnik0 on 20-Май-14, 13:11
	> Взаимоисключающие параграфы - они такие... Уточню - нет магнитопровода ,то есть сердечника ,набираемого из тонких пластин  .Есть только внешний очень тонкий экран ,чтобы гасить остаточное магнитное поле .Я просто хотел указать что  прогресс  даже с трансформаторами все таки идет ,конструкция получается меньше и легче на 30-40 % при той же мощности .
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	100. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от Аноним (??) on 20-Май-14, 21:53
	> то есть сердечника ,набираемого из тонких пластин   В исходном сообщении ничего не было про пластины, FYI. На самом деле сердечник лишь оптимизация. Он повышает индуктивность катушек. В совсем классической "железяке" первичка на частоте сети должна своей противоЭДС противостоять напряжению сети. Иначе будет сквозной ток, ограниченный лишь омическим сопротивлением обмотки (а оно у куска медной проволоки небольшое). Заканчивается сквозной ток тем что обмотка перегревается и сгорает. Железный сердечник - позволяет позволяет мотать меньше витков для равной противо-ЭДС. Учитывая что их даже так многие сотни, а то и более 1000 - понятно что на частоте сети 50Гц совсем без сердечника - просто не вариант. А пластины - потому что кусок железа не против прикинуться "лишней обмоткой" до кучи. Поскольку он замкнут сам на себя - получается обмотка с КЗ, греет сам себя, что печально. Пластины изолированные друг от друга снижают этот эффект. На более высоких частотах необходимые количества витков становятся низкими, современные трансы работающие на частотах под мегагерц с ферритовыми сердечниками (в железках на такой частоте потерь много, поэтому даже пластины не годятся, только совсем не проводящий ток сердечник) имеют весьма скромные по числу витков катушки. На еще более высоких частотах может хватить и индуктивности даже умеренной по числу витков катушки без сердечника вообще. Ничему не противоречит. Кстати, если кто думает что транс без сердечника новье и круть - ХРЕН ВАМ! Смотрим на Теслу и его катушки, например. И понимаем, что дядька делал из г-на и палок "резонансный трансформатор с воздушным сердечником". Как-то так, да. Подобные трансформаторы только начинают использовать в цивильном виде нынче. Просто потому что Теслу может и устраивали абы-какие параметры с "схемой управления" на разрядниках. Потому что просто сделать и позволяет показывать эффектные фокусы. А чтобы аккуратно и более-менее точно рулить таким процессом - надо приличный уровень развития силовой высокочастотной электроники. > все таки идет ,конструкция получается меньше и легче на 30-40 % > при той же мощности . Да вообще-то даже в разы, если сравнить с классической железякой. Но общая идея у всех одинаковая.
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

8. "Файловая система Tux3 предложена для включения в состав ядра..."	–1 +/–
Сообщение от Аноним (??) on 18-Май-14, 23:11
Смешное название какой-то, как игрушка
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	12. "Файловая система Tux3 предложена для включения в состав ядра..."	+3 +/–
	Сообщение от Xasd (ok) on 18-Май-14, 23:26
	> Смешное название какой-то, как игрушка да... :) и эт хорошо.. так как серьезные лица в инженерном мире -- особо ни кому не нужны.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	13. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от chinarulezzz (ok) on 18-Май-14, 23:39
	https://www.youtube.com/watch?v=oAJGT-gQnVA
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

16. "Файловая система Tux3 предложена для включения в состав ядра..."	+2 +/–
Сообщение от Zenitur (ok) on 19-Май-14, 03:40
Смотрим "похожие новости".
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

20. "Файловая система Tux3 предложена для включения в состав ядра..."	–1 +/–
Сообщение от Аноним (??) on 19-Май-14, 07:42
Закинут в ядро и опят забросят проект?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	23. "Файловая система Tux3 предложена для включения в состав ядра..."	+4 +/–
	Сообщение от Аноним (??) on 19-Май-14, 07:48
	> опят забросят проект? Опят? В проект? Вы там это... заканчивайте с опятами, вам уже хватит.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	27. "Файловая система Tux3 предложена для включения в состав ядра..."	+1 +/–
	Сообщение от Xaionaro (ok) on 19-Май-14, 08:37
	> Закинут в ядро и опят забросят проект? Передача в ядро Linux со словами "самая быстрая ФС" подтянет огромное комьюнити. Не думаю, что после этого ФС будет заброшена.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	28. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от Аноним (??) on 19-Май-14, 10:30
	> Передача в ядро Linux со словами "самая быстрая ФС" подтянет огромное комьюнити. > Не думаю, что после этого ФС будет заброшена. Пока-что оно словило немало невкусной критики на этапе раннего знакомства с кодом, см. дополнение к новости.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	31. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от Andrey Mitrofanov on 19-Май-14, 10:37
	>со словами "самая быстрая ФС" подтянет огромное комьюнити. > Не думаю, что после этого ФС будет заброшена. Ну, слова-то "самая быстрая ФС _на _одном _отдельном тесте". Сразу как-то по-другому рисуются характер "огромного комьюнити" и [не]забрасываемость. ...может, стоило напрячься и tmpfs подтюнить? Для того "одного" теста.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	32. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от Xaionaro (ok) on 19-Май-14, 10:55
	>>со словами "самая быстрая ФС" подтянет огромное комьюнити. >> Не думаю, что после этого ФС будет заброшена. > Ну, слова-то "самая быстрая ФС _на _одном _отдельном тесте". Кто говорил про один отдельный тест? Я говорю не про сравнение с tmpfs, а про сравнение с ФС постоянного хранения данных. Я видел в Инетах, что тесты с обычным dd дают очень хорошие результаты. А это уже немаловажно. > Сразу как-то по-другому > рисуются характер "огромного комьюнити" и [не]забрасываемость. Нет. Ничего нового не узнал, поэтому и впечатление не изменилось. > ...может, стоило напрячься и tmpfs подтюнить? Для того "одного" теста. Ну, вперёд ;)
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	34. "Файловая система Tux3 предложена для включения в состав ядра..."	–1 +/–
	Сообщение от rob pike on 19-Май-14, 11:21
	>подтянет огромное комьюнити Покажите открытую FS, которой это удалось.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	59. "Файловая система Tux3 предложена для включения в состав ядра..."	+1 +/–
	Сообщение от Аноним (??) on 19-Май-14, 15:43
	> Покажите открытую FS, которой это удалось. Ну вон EXTы или btrfs пилит довольно много народа. А баги репортит и подавно. Не знаю какие там критерии огромности, но процесс идет и это вполне засчитывается.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	73. "Файловая система Tux3 предложена для включения в состав ядра..."	–1 +/–
	Сообщение от rob pike on 19-Май-14, 17:50
	> Ну вон EXTы или btrfs пилит довольно много народа Очень по мелочи. Основную часть и там и там делают несколько человек.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	85. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от Аноним (??) on 20-Май-14, 09:27
	> Очень по мелочи. Основную часть и там и там делают несколько человек. Тем не менее, список коммитеров достаточно разлапист. И они таки скостили немного работы этим нескольким. Что хорошо, не так ли?
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	89. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от rob pike on 20-Май-14, 13:53
	Конечно хорошо. Часто большое количество и качество баг-репортеров намного важнее количества (и отчасти даже качества) разработчиков.
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	101. "Файловая система Tux3 предложена для включения в состав ядра..."	–1 +/–
	Сообщение от Аноним (??) on 21-Май-14, 03:00
	> Часто большое количество и качество баг-репортеров намного важнее количества (и отчасти > даже качества) разработчиков. Если разработчики бакланы - никакое количество багрепортеров не поможет. Ну как с рейзер3 vs fsck сносящий файловые системы.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

24. "Файловая система Tux3 предложена для включения в состав ядра..."	–1 +/–
Сообщение от Xaionaro (ok) on 19-Май-14, 08:19
А где можно увидеть список поддерживаемых и планируемых features-ов? :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	29. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от Аноним (??) on 19-Май-14, 10:31
	> А где можно увидеть список поддерживаемых и планируемых features-ов? :) А никаких особых мегафич. Простой и быстрый CoW-like дизайн. Рассматривай это как "ext4 сделанный на современный лад". Поэтому из фич в перспективе разве что нормальные снапшоты, что характерно для CoW-like дизайнов.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	36. "Файловая система Tux3 предложена для включения в состав ядра..."	+1 +/–
	Сообщение от Crazy Alex (ok) on 19-Май-14, 11:31
	Полагаю, не только для меня это будет фичей само по себе - более-менее минимальная обновлённая FS. Как ни крути, но идеи ZFS/BTRFS - "а давайте проигнорим весь стек и будем всё делать сами" - меня не привлекают ни разу.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	38. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от rob pike on 19-Май-14, 11:48
	Концепция "универсального сервера всего" уходит, вместе с ней уходит и "универсальная fs". Давайте проигнорим и будем делать всё сами - вполне оправдана для конкретных применений - где ZFS, где Btrfs, а где и какая-нибудь https://code.google.com/p/weed-fs/. ФС "общего назначения" останется в итоге boot да root, а для этого что угодно сгодится.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	48. "Файловая система Tux3 предложена для включения в состав ядра..."	+1 +/–
	Сообщение от Crazy Alex (ok) on 19-Май-14, 15:13
	У меня в сообщении слово "универсальная" не упоминалось ни разу. Уж чего-чего, а файловых систем в линуксе хватает - на любой вкус. И применяются соответственно. Но даже не говоря о том, что на линукс-десктопе, как правило, нужно именно что-то универсальное, ситуации, где какая-то конкретная FS сильно выигрывает - редки. Навскидку разве что какой-нибудь mailspool припомню. В остальном - интенсивная работа с диском - это обычно большие БД, где лучше всего вообще голый раздел. А с Btrfs/ZFS проблема в том, что это, по сути, архитектурные монстры. Если родной стек, основанный на lvm/md, плох - надо его править или заменять каким-то другим - но именно стеком, которым может быть использован другим кодом, а не тащить тихой сапой вещь-в-себе. К ZFS, конечно, в этом плане претензий ещё больше, учитывая её проблемы с работой с памятью на линуксе, но Btr с собственным слоем RAID - ненамного лучше. Примерно похожая ситуация произошла в своё время с иксами, когда вместо осмысленного апгрейда протокола стали городить костыли в тулкитах и гонять битмапы через XRender, в результате убив иксы. Но там хоть основания были - в частности, куча проприетарных реализаций. А здесь... в общем, грустно это.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	56. "Файловая система Tux3 предложена для включения в состав ядра..."	+1 +/–
	Сообщение от Аноним (??) on 19-Май-14, 15:37
	> Если родной стек, основанный на lvm/md, плох - надо его править > или заменять каким-то другим - но именно стеком, которым может быть > использован другим кодом, Капитан намекает что ты упускаешь один момент: при плотной интеграции некоторых вещей можно сделать некоторые вещи лучше. Ну например если дизайн основан на CoW то специализированные снапшоты на основе того факта что это CoW - работают лучше чем generic снапшоты на уровне блочного слоя под ФС. Прикинь, да? Аналогично бывает и с размещением данных/многодисковостью и прочая. Файловая система - владеет информацией о том где и что она размещает. А остальные слои - нет. Поэтому ФС может намного эффективнее делать вещи типа ребалансировки или убирания данных с накопителя с целью изъятия. И делать такие механизмы generic, в виде который устроит совсем разные дизайны ФС, включая еще не существующие... вот если такой слой отгрохать - ты узнаешь как выглядит настоящий оверинжиниринг :).
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	68. "Файловая система Tux3 предложена для включения в состав ядра..."	–1 +/–
	Сообщение от Crazy Alex (ok) on 19-Май-14, 17:10
	Ничего я не упускаю. Те же снапшоты на уровне ФС и на уровне блочного устройства - это "две большие разницы". Но многие возможности - RAID тот же, или убирание данных с накопителя - могут быть реализованы в общем слое. А что до оверинжиниринга - ну так на то и проектирование, чтобы вдумчиво сделать нужные интерфейсы. И, разумеется, никто в здравом умен не рассчитывает на те дизайны, которых ещё нет. Ровно наоборот - поддерживаться должно то, что уже есть и доказало свою востребованность. Кстати, в своё время это крайне доходчиво объяснили Рейзеру, который тоже хотел кучу фич в обход VFS делать.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	92. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от Аноним (??) on 20-Май-14, 20:00
	> снапшоты на уровне ФС и на уровне блочного устройства - это "две большие разницы". Именно. И на уровне ФС они лучше получаются. На уровне блочных устройств это как-то совсем уж дубово и примитивно, типа управления в этажерке братьев Райт. > Но многие возможности - RAID тот же, или убирание данных с накопителя > - могут быть реализованы в общем слое. Не вижу как без знания файловой системы "этот файл == те блоки" можно сделать например разные уровни RAID для разных файлов. А тезис о том что в файловой системе все файлы имеют одинаковую ценность - сомнительный и упрощенный, имхо. > вдумчиво сделать нужные интерфейсы. На все случаи все-равно не предусмотришь. Вообще, пингвин хорош тем что не пытается всучивать мега-решения для всего и вся в ущерб решению задач. Если где-то без расовой верноты получается лучше - там идут и делают так как лучше работает, поклав на расовую верноту. А если ставить расовую верноту выше здравого смысла - получится как в фрибзде. Где супер-мега-система журналирование, универсальный ответ на все вопросы, журналит аж целый у...щный UFS. ZFS журналит сам и по своему, ему помощь не требуется. Получилось что эти граждане здорово поработали на мусорный бак, с нулевым выхлопом. То-есть, куча работы сделана, академически все правильно, а практического результата - ноль! Все хорошо в меру. > И, разумеется, никто в здравом умен не рассчитывает на те дизайны, > которых ещё нет. Ровно наоборот - поддерживаться должно то, что уже есть > и доказало свою востребованность. То что уже есть и доказало свою востребованность - работает и нефиг чинить то что не сломано. Вы же не хотите получить состояние "btrfs 5-летней давности" по всей системе, правда? > Кстати, в своё время это крайне доходчиво объяснили Рейзеру, который тоже хотел кучу > фич в обход VFS делать. Ну так бтр делает в обход VFS только то что у него так лучше получается. Если б Рейзер привел конкретные примеры фич, которые через VFS совсем хреново делать - я думаю какой-нибудь консенсус нашелся бы. Ну как разные уровни райда для разных файлов. У ФС это знание есть, существующие в ядре райды на такие продвинутости не рассчитаны. В этом случае всем вроде понятно почему ФСина городит RAIDы самостоятельно. А если на VFS забили с абстрактным аргументом "я лучше знаю как делать правильно" - пошлют и будут по своему правы. Ибо нефиг.
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	103. "Файловая система Tux3 предложена для включения в состав ядра..."	+1 +/–
	Сообщение от Аноним (??) on 21-Май-14, 14:30
	> А что до оверинжиниринга - ну так на то и проектирование, чтобы > вдумчиво сделать нужные интерфейсы. И, разумеется, никто в здравом умен не > рассчитывает на те дизайны, которых ещё нет. Ровно наоборот - поддерживаться > должно то, что уже есть и доказало свою востребованность. Кстати, в > своё время это крайне доходчиво объяснили Рейзеру, который тоже хотел кучу > фич в обход VFS делать. Никто так внятно и не показал ту "кучу", которую хотели делать "в обход VFS". Одни только голимые вопли. Вместо того, чтобы учить Рейзера файловым системам, они бы лучше сами у него поучились. Ибо по умолчанию никто им в клювике хорошую файловую систему не принесет. По умолчанию будут только дерьмо пихать :)
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	57. "Файловая система Tux3 предложена для включения в состав ядра..."	+1 +/–
	Сообщение от Аноним (??) on 19-Май-14, 15:39
	P.S. попробуй например не залезая на уровень ФС сделать разные уровни RAID для разных файлов. Так что ценным файлам - зеркало, всякой там порнухе - stripe, ну и так далее. Блочные устройства понятия не имеют о каких либо файлах. Такое знание только на уровне ФС имеется. И, главное, я не вижу почему так должно быть нельзя.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	86. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от Аноним (??) on 20-Май-14, 11:19
	Для этого придумали API, чтобы разные слои абстракций могли общаться друг с другом.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	93. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от Аноним (??) on 20-Май-14, 20:07
	> Для этого придумали API, чтобы разные слои абстракций могли общаться друг с другом. И где апи позволяющие упомянутый фортель? Нету? Ну вот поэтому и сделали на уровне ФС. Более того - файловая система с чексуммами может иметь довольно кастомные пожелания к райду, типа желания повторить обломавшийся запрос несколько раз к разным носителям покуда чексум не совпадет. И не то чтобы обычные уровни ожидают или позволяют подобные маневры, опять же. Если доводить до маразма - будет как у фрибздюков с их расово верным мегажурналированием ... аж целого одного доисторического UFS-а.
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	61. "Файловая система Tux3 предложена для включения в состав ядра..."	–1 +/–
	Сообщение от rob pike on 19-Май-14, 16:00
	> У меня в сообщении слово "универсальная" не упоминалось ни разу. Но по смыслу-то речь шла о ней, извините если мне неверно показалось. > Уж чего-чего, > а файловых систем в линуксе хватает - на любой вкус. И > применяются соответственно. Ну давайте посчитаем - (для экстремалов) ext2, ext3, ext4, xfs, (с натяжкой) jfs. Остальное под линуксом либо слишком сырое (btrfs, ZFS), либо для очень специального применения (exFAT, NILFS2). По сути - всего три. ext3, ext4 и xfs. И разница между ними не очень-то большая. > Но даже не говоря о том, что на линукс-десктопе, > как правило, нужно именно что-то универсальное, ситуации, где какая-то конкретная FS > сильно выигрывает - редки. Навскидку разве что какой-нибудь mailspool припомню. В Нет, не показалось. Линукс-десктопу, разумеется, ФС без разницы и сам линукс-десктоп тоже никому особенно неинтересен, с точки зрения фс. > остальном - интенсивная работа с диском - это обычно большие БД, > где лучше всего вообще голый раздел. И кто же у нас умеет работать с голым разделом? Из NoSQL (в широком смысле, включая document-oriented и графовые СУБД) - никто, PostgreSQL тоже не умеет. > А с Btrfs/ZFS проблема в том, что это, по сути, архитектурные монстры. Да, ничего не бывает бесплатно. > Если родной стек, основанный на lvm/md, плох - надо его править > или заменять каким-то другим - но именно стеком, которым может быть > использован другим кодом, а не тащить тихой сапой вещь-в-себе. Вопрос в том кто же это будет делать. Ядерщики о проблемах постгресовцев вот недавно услышали впервые и вообще очень удивились - https://lwn.net/Articles/591723/ Послали их тесты писать. > К ZFS, > конечно, в этом плане претензий ещё больше, учитывая её проблемы с > работой с памятью на линуксе, но Btr с собственным слоем RAID > - ненамного лучше. Там ниже уже пояснили - ничего не бывает бесплатно. Хотите высокую производительность - придётся лезть через слои абстракций ломая их по пути. Ровно то же что и с денормализацией БД. > Примерно похожая ситуация произошла в своё время с иксами, когда вместо осмысленного > апгрейда протокола стали городить костыли в тулкитах и гонять битмапы через > XRender, в результате убив иксы. Да, с точки зрения красоты модели - грустно, но ничего не поделаешь.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	69. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от Crazy Alex (ok) on 19-Май-14, 17:29
	"Линукс-десктопу, разумеется, ФС без разницы и сам линукс-десктоп тоже никому особенно неинтересен, с точки зрения фс" - именно об этом и речь. Можете прибавить сюда и андроид-девайсы, которым всё, что надо - чтобы TRIM был. И разные роутеры, у которых свои всякие SquashFS. Остаятся, в общем-то, не так уж много. у больших - свои заморочки - напоминаю, к примеру, про гугл, сидящий на ext4 без журнала. И так далее, и тому подобное. А выбор FS начинатеся тогда, когда есть понимание, чем XFS отличается от Ext4. И да, это редкий случай. Насчет голого раздела - ок, промахнулся. Хотя тюнинг файловой системы под БД таки довольно экзотичен и подразумевает отключение всего, чего можно. А красота модели часто четко соответствует качеству решения. Просто потому, что "красивая" (компактная, прежде всего) модель помещается в голове и создаёт меньше всяких непредвиденных частных случаев.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	72. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от rob pike on 19-Май-14, 17:48
	> И так далее, и тому подобное. Остаётся то что в середине - серверы, но меньше чем Google, Facebook и Twitter. Это очень, очень большой рынок. Огромный. > А выбор FS начинатеся тогда, когда есть понимание, чем XFS отличается от > Ext4. И да, это редкий случай. Этого совершенно недостаточно. Нужно еще понимать как работает с FS СУБД, конкретная, какие в ней настройки как изменяют её поведение и что куда крутить чтобы FS, СУБД и ОС были (хотя бы иногда) не лебедем, раком и щукой. А еще сверху СУБД есть конкретные приложения, у которых свои паттерны доступа, под которые нужно всё это настраивать с пониманием чем мы жертвуем, где, и в пользу чего. Это случай редок настолько, что его можно считать несуществующим. > А красота модели часто четко соответствует качеству решения. Просто потому, что "красивая" > (компактная, прежде всего) модель помещается в голове и создаёт меньше всяких > непредвиденных частных случаев. Да, лучше быть богатым и здоровым. В реальности же мы имеем следующие проблемы на пути в светлое будущее:   - разработчики FS не могут ориентироваться на конкретную СУБД и пытаются угодить всем, причем эмпирически   - разработчики СУБД не имеют достаточно ресурсов чтобы сделать качественный полный стек под свою конкретную СУБД   - пользователи хотят получить одновременно и высокую производительность и все плюшки развитой инфраструктуры FS и ОС
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	94. "Файловая система Tux3 предложена для включения в состав ядра..."	+1 +/–
	Сообщение от Аноним (??) on 20-Май-14, 20:21
	> Ну давайте посчитаем - (для экстремалов) ext2, ext3, ext4, xfs, (с натяжкой) jfs. > Остальное под линуксом либо слишком сырое (btrfs, ZFS), либо для очень специального > применения (exFAT, NILFS2). Есть еще F2FS, который хорошо себя показывает на флешовых носителях. Есть squashfs, специализированный но весьма полезный в своей нише. JFFS2 и ряд соседних, похожих по смыслу. Reiser3 надирает зад на мелочевке. На все вкусы, в общем. > По сути - всего три. ext3, ext4 и xfs. Это очень упрощенная картина мира. > тоже никому особенно неинтересен, с точки зрения фс. Да как сказать? Это интересно тем же разработчикам, которые используют линя на десктопе и потому шкурно заинтересованы чтобы работало хорошо. Это ж не бзда и не реактос, поэтому разработчики еще и для себя этим пользуются, кроме всего прочего. > И кто же у нас умеет работать с голым разделом? Оракл тот же. А так он прав - теоретически СУБД делает то же что и ФС, ФС вообще можно считать специализированной БД. Поэтому когда на ФС кладут БД - запросто может случиться двойная работа. Но укладывание на RAW раздел - неудобно с точки зрения администрирования. Вот и получаются довольно интересные взаимоисключающие параграфы. То-есть в случае БД желательно чтобы ФС была относительно тонкой подложкой которая не особо гадит своими свойствами механике делавшейся под пессимистичный случай ФС. > Да, ничего не бывает бесплатно. Ну вон боинги и эйрбасы летают. Хотя вполне себе архитектурные монстры. > Там ниже уже пояснили - ничего не бывает бесплатно. Хотите высокую производительность > - придётся лезть через слои абстракций ломая их по пути. Кроме того, слои абстракций не все и не всегда предусматривают. И тот же btrfs на абстракции кладет вроде в основном тогда когда через них нормально сделать желаемые фичи не получалось. > Да, с точки зрения красоты модели - грустно, но ничего не поделаешь. Красивые экспонаты пусть в музеях стоят. А на компьютерах надо чтобы работало.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	46. "Файловая система Tux3 предложена для включения в состав ядра..."	–1 +/–
	Сообщение от Xasd (ok) on 19-Май-14, 14:47
	> "а давайте проигнорим весь стек и будем всё делать сами" - меня не привлекают ни разу. а не подскажите -- как при помощи этого самого стека (EXT4+LVM2+<???>) -- можно было бы заменить (без отмонтирования) один HDD на другой HDD? при условии что новый HDD -- будет мЕньшего объёма чем старый HDD. (возможно за-то новый быстрее, так что не надо тут критиковать мол новый всегда якобы больше чем старый).
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	49. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от Crazy Alex (ok) on 19-Май-14, 15:21
	То, что стек не даёт это сделать сейчас - не основание не уметь это вообще. Вполне может быть, что какая-то часть его архитектуры неудачна и его надо переделывать, хотя упомянутый юз-кейс - явно не слишком важный и частый (уж ядро-то явно чаще обновлять приходится, чем диски менять, отмонтирование - явно не слишком большая проблема). Но это ни разу не основание для клепания костылей и дублирования функционала без какой-либо надежды использования его каким-то ещё кодом.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	58. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от Аноним (??) on 19-Май-14, 15:41
	Что скажешь насчет http://www.opennet.me/openforum/vsluhforumID3/95893.html#57 например? Попробуй предложить как сделать слой который сможет разный уровень RAID для разных файлов. И как, хорошо получается?
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	71. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от Crazy Alex (ok) on 19-Май-14, 17:42
	Я честно сидел и пытался придумать юз-кейс, когда файлы делятся по "ценности", но при этом нельзя на основе этого деления бросить их на разные разделы. Не сумел. Если приведёте боле конкретно описание ситуации (например, в виде "как оно должно выглядеть для пользователя") - подозреваю, что решение найдётся тут же. Вообще не задействующее FS. Бардак в коде тогда и начинается, когда пытаются реализовать все хотелки вместо того, чтобы определиться, какой минимальный объем фич решает задачу. Но в принципе - не вижу ничего невозможного. Разумеется, FS это должна будет понимать - но та же XFS, к примеру, со своими volume groups очень недалеко ушла от возможности прицепить несколько устройств и как-то мапить на них файлы. А уж какой где RAID будет - её не касается.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	95. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от Аноним (??) on 20-Май-14, 20:35
	> Я честно сидел и пытался придумать юз-кейс, когда файлы делятся по "ценности", > но при этом нельзя на основе этого деления бросить их на разные разделы. Знаешь, заранее подготовленные разные разделы - таки рояль в кустах. И при необходимости это реконфигурить - получается кластерфак. Совсем другое дело если ты просто ткнул ФС - мол, хочу вот это на RAID0, а это RAID1. И получил то что просил. И чтоб динамически, в рантайме можно было переходить с одного на другое, etc. > решение найдётся тут же. Вообще не задействующее FS. Понимаешь, есть еще такая хрень как удобство. У твоих решений есть жирный минус: они как правило подразумевают что удастся запланировать народное хозяйство на ...цать лет вперед, лучше компартии СССР. А если вдруг не угадали - начинается знатный кластерфак с тасовкой разделов. Не хочу ничего сказать, но мысль просто ткнуть ФС "а разложи ка это вот так" смотрится в целом симпатичнее чем перспектива перетряхивания разделов. > Бардак в коде тогда и начинается, когда пытаются реализовать все хотелки вместо > того, чтобы определиться, какой минимальный объем фич решает задачу. По минимуму летать может даже кусок тряпки и палки. Пойдем, покажем боингам и эйрбасам как самолеты надо было строить? :) > А уж какой где RAID будет - её не касается. Зато меня очень даже касается. И жестко конфигурить на уровне разделов какие будут райды мне кажется не очень гибким и удобным решением. Пофайлово - забористее, что ни говори.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	76. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от Xasd (ok) on 19-Май-14, 20:10
	> уж ядро-то явно чаще обновлять приходится, чем диски менять обновление ядра -- операция занимает 1 минуту (или меньше). замена HDD -- операция занимает несколько часов. например 12 часов. если сервер в течении 12 часов находится в offline (пока меняются диски) -- то как-то это не хорошо :-)... даже если desktop находится 12 часов в offline -- то это тоже как-то некомфортно..
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

42. "Файловая система Tux3 предложена для включения в состав ядра..."	–1 +/–
Сообщение от Аноним (??) on 19-Май-14, 12:05
b-tree и "заметные накладные расходы" просто несовместимы
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	60. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от rob pike on 19-Май-14, 15:44
	Испортить можно всё.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

44. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
Сообщение от Аноним (??) on 19-Май-14, 12:06
Указатели это хорошо Напоминает фрактальную структуру только с китайским дизайном
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	67. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от rob pike on 19-Май-14, 16:55
	> Напоминает фрактальную структуру Вот эту - http://www.tokutek.com/2013/07/tokumx-fractal-treer-indexes-.../?
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	70. "Файловая система Tux3 предложена для включения в состав ядра..."	+/–
	Сообщение от rob pike on 19-Май-14, 17:38
	Кстати, они тоже придумали FS - TokuFS
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

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

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