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

Файловая система Tux3 предложена для включения в состав ядра..., opennews (?), 18-Май-14, (0) [смотреть все] Вовремя В ITS это сделали в 1960 г , в RSX-11 и VMS попозже, теперь и Linux подт, rob pike (?), 20:27 , 18-Май-14, (1) –10 // Ты что-то попутал , Аноним (-), 00:16 , 19-Май-14, (14) +1 Сделали что Tux3 Что вы там курите, гражданин , Аноним (-), 07:41 , 19-Май-14, (19) +1 // Версионность , rob pike (?), 12:06 , 19-Май-14, (43) +1 // Гладиолус , Аноним (-), 14:44 , 19-Май-14, (45) Версионность указателей , Аноним (-), 15:11 , 19-Май-14, (47) А я уж обрадовался что таки данных ОК, подождем еще 50 лет , rob pike (?), 16:33 , 19-Май-14, (65) Если отпустить ручник, можно обнаружить что снапшоты - нечто такое и есть , Аноним (-), 09:17 , 20-Май-14, (81) +2 Как это возможно Или это тестировалось на SSD В таком случае ещё может быть , Аноним (-), 21:17 , 18-Май-14, (2) +3 // очень легко вся суть в том как это сказали -- ключевое слово в одном в одно, Xasd (ok), 21:53 , 18-Май-14, (4) +1 // тем кто минусанул -- хочу напомнить что чудес не бывает в любой популярной , Xasd (ok), 23:12 , 18-Май-14, (9) +1 // glusterfs - , Аноним (-), 04:12 , 19-Май-14, (17) +2 Полностью согласен, тоэтому комбайн в виде zfs вполне нормально существует, пото, Аноним (-), 06:28 , 19-Май-14, (18) Да щаз Отсутствие нормального управления памятью кеша и тормознутость дизайна б, Аноним (-), 07:45 , 19-Май-14, (21) –2 Зачем вы засунули ZFS в кофеварку , rob pike (?), 12:05 , 19-Май-14, (41) –4 Правильно, кофеварки и без CoW обойдутся Нехай рушат файлы при записи или дико , Аноним (-), 15:22 , 19-Май-14, (50) +1 Ну смешно ведь предъявлять кофеварочные претензии к FS, которая была сделана для, rob pike (?), 16:08 , 19-Май-14, (63) –1 Потому что это generic претензии к дизайну ФС вообще , абстрактно от того под ч, Аноним (-), 09:20 , 20-Май-14, (82) +1 Не бывает ФС вообще , тем более их дизайнов Это простое инженерное ремесло, ве, rob pike (?), 13:57 , 20-Май-14, (90) Все так И ZFS в этом плане - весьма странный монстр, единственное вменяемое при, Аноним (-), 20:47 , 20-Май-14, (96) +1 Оперативы нынче дешевы За менее чем 10,000 легко получается 384 GB и современ, rob pike (?), 01:32 , 22-Май-14, (105) А вроде никто и не говорит про чудо Тут ведь никто не говорит, что на терабайтн, Xaionaro (ok), 08:35 , 19-Май-14, (25) Больше булшита хорошего и разного , Аркадий (??), 22:50 , 19-Май-14, (77) Какое-то обоснование последует , Xaionaro (ok), 22:52 , 19-Май-14, (79) Там в списке рассылки - Ох, Василий Иваныч, он так мативировал, так мативировал, Аноним (-), 20:49 , 20-Май-14, (97) FUSE FUSE FUSE , vlikhachev (ok), 15:26 , 19-Май-14, (51) –1 FAT еще На сколь-нибудь разлапистой иерархии ему наступает это самое , Аноним (-), 15:30 , 19-Май-14, (53) FUSE это не файловая система -- это фреймворк для написания оных в юзерспейсе --, pavel_simple (ok), 15:33 , 19-Май-14, (54) +1 Честно сказать, я вас не понял причём тут 171 FUSE 187 8230 , Xaionaro (ok), 16:11 , 19-Май-14, (64) Тормозит хорошо Как правило упираясь в проц, ибо переключает контексты оптом и , Аноним (-), 09:21 , 20-Май-14, (83) –1 1 FUSE 8212 это не файловая система Использование FUSE тормозит процесс, но, Xaionaro (ok), 15:50 , 20-Май-14, (91) +1 ага помню шутку про фс dev null скорость записи в которую достигает бесконечно, кевин (?), 18:27 , 19-Май-14, (75) Беру килограмм бесконечно быстрой оперативки , Аноним (-), 20:50 , 20-Май-14, (98) –1 http lkml iu edu hypermail linux kernel 1305 0 03713 html, rob pike (?), 22:35 , 18-Май-14, (6) +2 // Угум Метко подмечено , ZloySergant (ok), 22:50 , 19-Май-14, (78) Мне кажется, что для корректного сравнения чтобы исключить влияние аппаратной с, Xaionaro (ok), 08:36 , 19-Май-14, (26) Нашли граничный случай когда диск вообще не используется, а при обработке структ, Аноним (-), 18:26 , 19-Май-14, (74) –1 Сравнивалась Tux3 поверх рамдиска с tmpfs При таком раскладе вряд-ли Tux3 единс, anonymous (??), 12:21 , 20-Май-14, (87) // Да вот единственная как оказалось , Аноним (-), 20:51 , 20-Май-14, (99) Вах, b-tree Великое достижение Кста чо там, рейзеру-то долго ещё сидеть , Anonymus (?), 21:26 , 18-Май-14, (3) –1 // ему пожизненное дали, Аноним (-), 21:57 , 18-Май-14, (5) +1 // беда с этими бабами, Anonymus (?), 00:24 , 19-Май-14, (15) +11 С годами хуже не становится, rob pike (?), 22:35 , 18-Май-14, (7) +8 В 2019 году может подать первое прошение о досрочном освобождении А так долго-н, Эргил (?), 23:14 , 18-Май-14, (10) –1 так он же все, вродевроде в физику математику подался, Денис (??), 23:23 , 18-Май-14, (11) –1 Годы идут, а фундаментальные удачные структуры - меняются мало А вот версиониро, Аноним (-), 07:47 , 19-Май-14, (22) +1 Ой, а вон трансформаторы вообще более ста лет делают путем намотки медного прово, Аноним (-), 10:36 , 19-Май-14, (30) +1 // Я и про транзисторы какбэ вкурсе, но с другой стороны мегагерцы-то поисчерпались, Anonymus (?), 11:30 , 19-Май-14, (35) –2 // А про микросхемы, гигагерцы и ферриты, в курсе Держи нас в , Andrey Mitrofanov (?), 11:50 , 19-Май-14, (39) +1 И начались ухищрения с кэшами да конвейерами Вот тут и выяснилось что b-tree опя, rob pike (?), 11:51 , 19-Май-14, (40) Опять А что, когда-то умирали чтоли , Аноним (-), 15:28 , 19-Май-14, (52) Да, одно время считались очень немодными Много чего прогрессивного придумали, в , rob pike (?), 16:04 , 19-Май-14, (62) Честно говоря - не заметил чтобы софт переставал ими пользоваться Хотя это боль, Аноним (-), 03:09 , 21-Май-14, (102) Практически все storage engines, появившиеся за последние годы используют модные, rob pike (?), 01:28 , 22-Май-14, (104) Или предлагается сбацать файловую систему на трансформаторах Мотать замуча, Anonymus (?), 11:32 , 19-Май-14, (37) –1 // Нет, намекается что алгоритмы типа b-tree вполне могут точно так же прожить св, Аноним (-), 15:33 , 19-Май-14, (55) И лампах Тёплую, аналоговую файловую систему Звуковым файлам она будет придавать, rob pike (?), 16:53 , 19-Май-14, (66) +1 И тут есть прогресс - изобретенны плоско-пластинчатые трансформаторы ,в них мета, maximnik0 (?), 00:22 , 20-Май-14, (80) –2 // Взаимоисключающие параграфы - они такие , Аноним (-), 09:25 , 20-Май-14, (84) Уточню - нет магнитопровода ,то есть сердечника ,набираемого из тонких пластин , maximnik0 (?), 13:11 , 20-Май-14, (88) В исходном сообщении ничего не было про пластины, FYI На самом деле сердечник л, Аноним (-), 21:53 , 20-Май-14, (100) Смешное название какой-то, как игрушка, Аноним (-), 23:11 , 18-Май-14, (8) –1 // да и эт хорошо так как серьезные лица в инженерном мире -- особо ни кому , Xasd (ok), 23:26 , 18-Май-14, (12) +3 // https www youtube com watch v oAJGT-gQnVA, chinarulezzz (ok), 23:39 , 18-Май-14, (13) Смотрим похожие новости , Zenitur (ok), 03:40 , 19-Май-14, (16) +2 Закинут в ядро и опят забросят проект , Аноним (-), 07:42 , 19-Май-14, (20) –1 // Опят В проект Вы там это заканчивайте с опятами, вам уже хватит , Аноним (-), 07:48 , 19-Май-14, (23) +4 Передача в ядро Linux со словами самая быстрая ФС подтянет огромное комьюнити , Xaionaro (ok), 08:37 , 19-Май-14, (27) +1 // Пока-что оно словило немало невкусной критики на этапе раннего знакомства с кодо, Аноним (-), 10:30 , 19-Май-14, (28) Ну, слова-то самая быстрая ФС _на _одном _отдельном тесте Сразу как-то по-дру, Andrey Mitrofanov (?), 10:37 , 19-Май-14, (31) // Кто говорил про один отдельный тест Я говорю не про сравнение с tmpfs, а про ср, Xaionaro (ok), 10:55 , 19-Май-14, (32) Покажите открытую FS, которой это удалось , rob pike (?), 11:21 , 19-Май-14, (34) –1 // Ну вон EXTы или btrfs пилит довольно много народа А баги репортит и подавно Не, Аноним (-), 15:43 , 19-Май-14, (59) +1 Очень по мелочи Основную часть и там и там делают несколько человек , rob pike (?), 17:50 , 19-Май-14, (73) –1 Тем не менее, список коммитеров достаточно разлапист И они таки скостили немног, Аноним (-), 09:27 , 20-Май-14, (85) Конечно хорошо Часто большое количество и качество баг-репортеров намного важнее, rob pike (?), 13:53 , 20-Май-14, (89) Если разработчики бакланы - никакое количество багрепортеров не поможет Ну как , Аноним (-), 03:00 , 21-Май-14, (101) –1 А где можно увидеть список поддерживаемых и планируемых features-ов , Xaionaro (ok), 08:19 , 19-Май-14, (24) –1   // А никаких особых мегафич Простой и быстрый CoW-like дизайн Рассматривай это ка, Аноним (-), 10:31 , 19-Май-14, (29)   // Полагаю, не только для меня это будет фичей само по себе - более-менее минимальн, Crazy Alex (ok), 11:31 , 19-Май-14, (36) +1   // Концепция универсального сервера всего уходит, вместе с ней уходит и универса, rob pike (?), 11:48 , 19-Май-14, (38)   У меня в сообщении слово универсальная не упоминалось ни разу Уж чего-чего, а, Crazy Alex (ok), 15:13 , 19-Май-14, (48) +1   Капитан намекает что ты упускаешь один момент при плотной интеграции некоторых , Аноним (-), 15:37 , 19-Май-14, (56) +1   Ничего я не упускаю Те же снапшоты на уровне ФС и на уровне блочного устройства, Crazy Alex (ok), 17:10 , 19-Май-14, (68) –1   Именно И на уровне ФС они лучше получаются На уровне блочных устройств это как, Аноним (-), 20:00 , 20-Май-14, (92)   Никто так внятно и не показал ту кучу , которую хотели делать в обход VFS Одн, Аноним (-), 14:30 , 21-Май-14, (103) +1   P S попробуй например не залезая на уровень ФС сделать разные уровни RAID для р, Аноним (-), 15:39 , 19-Май-14, (57) +1   Для этого придумали API, чтобы разные слои абстракций могли общаться друг с друг, Аноним (-), 11:19 , 20-Май-14, (86)   И где апи позволяющие упомянутый фортель Нету Ну вот поэтому и сделали на уров, Аноним (-), 20:07 , 20-Май-14, (93)   Но по смыслу-то речь шла о ней, извините если мне неверно показалось Ну давайте , rob pike (?), 16:00 , 19-Май-14, (61) –1   Линукс-десктопу, разумеется, ФС без разницы и сам линукс-десктоп тоже никому ос, Crazy Alex (ok), 17:29 , 19-Май-14, (69)   Остаётся то что в середине - серверы, но меньше чем Google, Facebook и Twitter Э, rob pike (?), 17:48 , 19-Май-14, (72)   Есть еще F2FS, который хорошо себя показывает на флешовых носителях Есть squash, Аноним (-), 20:21 , 20-Май-14, (94) +1   а не подскажите -- как при помощи этого самого стека EXT4 LVM2 -- можно , Xasd (ok), 14:47 , 19-Май-14, (46) –1   То, что стек не даёт это сделать сейчас - не основание не уметь это вообще Впол, Crazy Alex (ok), 15:21 , 19-Май-14, (49)   Что скажешь насчет http www opennet ru openforum vsluhforumID3 95893 html 57 н, Аноним (-), 15:41 , 19-Май-14, (58)   Я честно сидел и пытался придумать юз-кейс, когда файлы делятся по ценности , н, Crazy Alex (ok), 17:42 , 19-Май-14, (71)   Знаешь, заранее подготовленные разные разделы - таки рояль в кустах И при необх, Аноним (-), 20:35 , 20-Май-14, (95)   обновление ядра -- операция занимает 1 минуту или меньше замена HDD -- операци, Xasd (ok), 20:10 , 19-Май-14, (76)   b-tree и заметные накладные расходы просто несовместимы, Аноним (-), 12:05 , 19-Май-14, (42) –1 // Испортить можно всё , rob pike (?), 15:44 , 19-Май-14, (60) Указатели это хорошоНапоминает фрактальную структуру только с китайским дизайном, Аноним (-), 12:06 , 19-Май-14, (44) // Вот эту - http www tokutek com 2013 07 tokumx-fractal-treer-indexes-what-are-t, rob pike (?), 16:55 , 19-Май-14, (67) // Кстати, они тоже придумали FS - TokuFS, rob pike (?), 17:38 , 19-Май-14, (70) 1,2,3,8,16,20,24,42,44

Сообщения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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