Файловая система Tux3 (http://tux3.org/), известная своими достижениями в области производительности (в одном из тестов Tux3 смог обогнать tmpfs, что ранее считалось невозможным) предложена (https://lkml.org/lkml/2014/5/16/708) для включения в состав ядра Linux. Файловая система Tux3 разрабатывается (https://www.opennet.ru/opennews/art.shtml?num=17130) с 2008 года и является версионной файловой системой. В 2009 году работа над Tux3 была приостановлена, но в начале 2013 года проект возродился (https://www.opennet.ru/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
Новость: https://www.opennet.ru/opennews/art.shtml?num=39802
Вовремя.
В ITS это сделали в 1960 г., в RSX-11 и VMS попозже, теперь и Linux подтянулся.
Ты что-то попутал.
Сделали ... что? Tux3? Что вы там курите, гражданин?
Версионность.
Гладиолус?
> Версионность.Версионность *указателей*?
А я уж обрадовался что таки данных.
ОК, подождем еще 50 лет.
Если отпустить ручник, можно обнаружить что снапшоты - нечто такое и есть.
> в одном из тестов Tux3 смог обогнать tmpfsКак это возможно? Или это тестировалось на SSD? В таком случае ещё может быть..
очень легко! вся суть в том как это сказали -- ключевое слово "в одном" ("в одном из тестов") :-)стоит предположить что остальные операции (остальные тесты) -- там выполняются со вполне обычной или даже более медленной скоростью (по сравнению с Ext4)
тем кто минусанул -- хочу напомнить что чудес не бывает. :)в любой (популярной) файловой системе разработчики уделяют скорости -- важную роль.
разработчики какой файловой системы думают "скорость?! ды кому она нужна?"? :-)
вопрос лишь в том -- под какие виды операций-и-условий та-или-иная файловая система более оптимально подходит, а под какие виды операций-и-условий менее оптимально подходит.
...ну и конечно же в том какой ценой удаётся эта скорость.
побочные-то эффекты они обязательно будут... но нам то (пользователям) ведь главное НЕ чтобы не было бы побочных эффектов, а то чтобы эти побочные эффекты были бы НЕраздражающими для нас.
например если файловая система медленее закрывает файлы и медленее освобождает ресурсы -- то думаю это как раз хороший пример НЕраздражающего побочного эффекта. :)
> разработчики какой файловой системы думают "скорость?! ды кому она нужна?"?glusterfs :-)
Полностью согласен, тоэтому комбайн в виде zfs вполне нормально существует, потому что можно подкрутить для твоего юзкейса.
> можно подкрутить для твоего юзкейса.Да щаз. Отсутствие нормального управления памятью кеша и тормознутость дизайна без подпора много гигазов оперативы - не лечатся. Хоть крути, хоть не крути. "Крутите свои, они вам больше не понадобятся".
>без подпора много гигазов оперативыЗачем вы засунули ZFS в кофеварку?
> Зачем вы засунули ZFS в кофеварку?Правильно, кофеварки и без CoW обойдутся. Нехай рушат файлы при записи или дико тормозят.
Ну смешно ведь предъявлять кофеварочные претензии к FS, которая была сделана для совершенно других применений.
> Ну смешно ведь предъявлять кофеварочные претензии к FS, которая была сделана для
> совершенно других применений.Потому что это generic претензии к "дизайну ФС вообще", абстрактно от того под что она там делалась. Но да, вы правы - единственным вменяемым сценарием использования ZFS смотрятся файлсерверы на которых ничего другого не работает. Но это довольно нишевое применение. А btrfs делался как более-менее generic файловая система.
> Потому что это generic претензии к "дизайну ФС вообще", абстрактно от тогоНе бывает "ФС вообще", тем более их дизайнов. Это простое инженерное ремесло, верно выбранный набор компромиссов, а не абстракции из слоновой кости.
> Не бывает "ФС вообще", тем более их дизайнов. Это простое инженерное ремесло,
> верно выбранный набор компромиссов, а не абстракции из слоновой кости.Все так. И ZFS в этом плане - весьма странный монстр, единственное вменяемое примение оному в том виде каком он есть я вижу только на мощных серверах с кучей оперативы. Иначе весьма заурядные дисковые структуры будут тормозить. А рамдиски - они что, они быстрые по жизни. Поэтому чем ближе к рамдиску - тем меньше тормозов. При том сервера - целиком отданные под файлопомойку. Из-за своеобразного управления памятью, которое на десктопе/рабочей станции/сервере приложений/etc сможет вызвать море лулзов с внезапной нехваткой памяти. Хотя можно превратить юзера в педальный привод системы управления кешом и сказать что пусть вручную конфигуряет, компенсируя бестолковости дизайна руками.
> Все так. И ZFS в этом плане - весьма странный монстр, единственное
> вменяемое примение оному в том виде каком он есть я вижу
> только на мощных серверах с кучей оперативы.Оперативы нынче дешевы. За менее чем $10,000 легко получается 384 GB (и современных Xeon-овых ядер штук 12, с парой пар дисков по 3-4 TB) в 1U корпусе.
И с возможностью апгрейда до 1.5 TB RAM потом.
> тем кто минусанул -- хочу напомнить что чудес не бывает. :)А вроде никто и не говорит про чудо. Тут ведь никто не говорит, что на терабайтный винчестер влезает целый эксабайт сжатой информации?
Речь просто про performance-oriented next-gen FS со вполне правдоподобными результатами.
> performance-oriented next-genБольше булшита хорошего и разного.
>> performance-oriented next-gen
> Больше булшита хорошего и разного.Какое-то обоснование последует?
> Какое-то обоснование последует?Там в списке рассылки - "Ох, Василий Иваныч, он так мативировал, так мативировал! И вас, и меня мативировал!"
> разработчики какой файловой системы думают "скорость?! ды кому она нужна?"? :-)FUSE!!! FUSE!!! FUSE!!!
> FUSE!!! FUSE!!! FUSE!!!FAT еще. На сколь-нибудь разлапистой иерархии ему наступает это самое :)
>> разработчики какой файловой системы думают "скорость?! ды кому она нужна?"? :-)
> FUSE!!! FUSE!!! FUSE!!!FUSE это не файловая система -- это фреймворк для написания оных в юзерспейсе -- причём тормоза описаны сразу при входе в тему -- потому как переключения контекста операция ресурсоёмкая.
>> разработчики какой файловой системы думают "скорость?! ды кому она нужна?"? :-)
> FUSE!!! FUSE!!! FUSE!!!Честно сказать, я вас не понял причём тут «FUSE»…
> Честно сказать, я вас не понял причём тут «FUSE»…Тормозит хорошо. Как правило упираясь в проц, ибо переключает контексты оптом и в розницу :)
>> Честно сказать, я вас не понял причём тут «FUSE»…
> Тормозит хорошо. Как правило упираясь в проц, ибо переключает контексты оптом и
> в розницу :)1. FUSE — это не файловая система. Использование FUSE тормозит процесс, но это не говорит о тормознутости самой файловой системы (как теоретической задумки).
2. Subj-евая ФС вроде как раз говорит о том, что хочет перейти прямо в ванильное ядро. Так что, опять же, FUSE не при чём.
ага. помню шутку про фс /dev/null скорость записи в которую достигает бесконечности...
> достигает бесконечности...Беру килограмм бесконечно быстрой оперативки :).
http://lkml.iu.edu//hypermail/linux/kernel/1305.0/03713.html
> ...the code that produces this benchmark currently relies on this benchmark-specific hack to speed up inode number allocation.Угум. Метко подмечено.
>> в одном из тестов Tux3 смог обогнать tmpfs
> Как это возможно? Или это тестировалось на SSD? В таком случае ещё
> может быть..Мне кажется, что для корректного сравнения (чтобы исключить влияние аппаратной составляющей), всей тесты производились прямо в ОЗУ.
Нашли граничный случай когда диск вообще не используется, а при обработке структур в памяти tux3 работает эффективнее чем tmpfs (скажем, использует дерево, где в tmpfs список, посколько эта такая маргинальная ситуация что дерева не требует). Собственно и всё - в одном тесте вау-вау, обогнали саму tmpfs, а в других фейл на фейле.
Сравнивалась Tux3 поверх рамдиска с tmpfs. При таком раскладе вряд-ли Tux3 единственная, кто может нагнуть tmpfs.
> вряд-ли Tux3 единственная, кто может нагнуть tmpfs.Да вот единственная как оказалось...
Вах, b-tree! Великое достижение. Кста чо там, рейзеру-то долго ещё сидеть?
ему пожизненное дали
беда с этими бабами
> Вах, b-tree! Великое достижениеС годами хуже не становится
В 2019 году может подать первое прошение о досрочном освобождении. А так долго-не долго, до конца жизни, если досрочку не дадут.
так он же все, вроде
вроде в физику/математику подался
> Вах, b-tree! Великое достижение.Годы идут, а фундаментальные удачные структуры - меняются мало. А вот версионированные указатели в том виде как у них - вроде их собственное изобретение.
> Вах, b-tree! Великое достижение.Ой, а вон трансформаторы вообще более ста лет делают путем намотки медного провода вокруг железного сердечника. А оно все работает и работает.
Я и про транзисторы какбэ вкурсе, но с другой стороны мегагерцы-то поисчерпались уже лет десять тому назад.
> Я и про транзисторы какбэ вкурсе, но с другой стороны мегагерцы-тоА про микросхемы, гигагерцы и ферриты, в курсе? Держи нас в!
> мегагерцы-то поисчерпалисьИ начались ухищрения с кэшами да конвейерами.
Вот тут и выяснилось что b-tree опять живее всех живых.
> Вот тут и выяснилось что b-tree опять живее всех живых.Опять? А что, когда-то "умирали" чтоли?
Да, одно время считались очень немодными.
Много чего прогрессивного придумали, в частности многоуровневые log-structured merge-trees.
> Да, одно время считались очень немодными.Честно говоря - не заметил чтобы софт переставал ими пользоваться. Хотя это больше про софт вообще, не только файловые системы.
> Много чего прогрессивного придумали, в частности многоуровневые log-structured merge-trees.
Да разных вариантов деревьев придумано немеряно. Я просто к тому что не видел чтобы софт переставал b-tree использовать, поэтому вспоминается Марк Твен - "слухи о моей смерти были сильно преувеличены".
Практически все storage engines, появившиеся за последние годы используют модные LSM - HBase, LevelDB, SQLite 4, Cassandra
Или предлагается сбацать файловую систему на трансформаторах? :))) Мотать замучаешься
> Или предлагается сбацать файловую систему на трансформаторах? :))) Мотать замучаешьсяНет, намекается что алгоритмы типа "b-tree" вполне могут точно так же прожить свой стольник лет, припеваючи. А что им будет то?
И лампах.
Тёплую, аналоговую файловую систему.
Звуковым файлам она будет придавать прозрачную середину, графическим - объем и выразительность. А текстовым - смысл и содержательность.
> Ой, а вон трансформаторы вообще более ста лет делают путем намотки медного
> провода вокруг железного сердечника. А оно все работает и работает.И тут есть прогресс - изобретенны плоско-пластинчатые трансформаторы ,в них металических катушек и сердечников нет (кроме внешнего экрана ) .Пока по этой технологии делают блоки питания к ноутбукам .Все просто - на изолятор пластину наносят (наклеивают ) катушки индуктивности (как в совеских электромеханических часах ) и наберают нужное кол-во пластин для получение нужной мощности ,рассевание магнитного поля минимальное,соответственно выше кпд ,железа нет меньше габариты и вес .
> металических катушек и сердечников нет...
> (наклеивают ) катушки индуктивностиВзаимоисключающие параграфы - они такие...
> Взаимоисключающие параграфы - они такие...Уточню - нет магнитопровода ,то есть сердечника ,набираемого из тонких пластин .Есть только внешний очень тонкий экран ,чтобы гасить остаточное магнитное поле .Я просто хотел указать что прогресс даже с трансформаторами все таки идет ,конструкция получается меньше и легче на 30-40 % при той же мощности .
> то есть сердечника ,набираемого из тонких пластинВ исходном сообщении ничего не было про пластины, FYI. На самом деле сердечник лишь оптимизация. Он повышает индуктивность катушек. В совсем классической "железяке" первичка на частоте сети должна своей противоЭДС противостоять напряжению сети. Иначе будет сквозной ток, ограниченный лишь омическим сопротивлением обмотки (а оно у куска медной проволоки небольшое). Заканчивается сквозной ток тем что обмотка перегревается и сгорает. Железный сердечник - позволяет позволяет мотать меньше витков для равной противо-ЭДС. Учитывая что их даже так многие сотни, а то и более 1000 - понятно что на частоте сети 50Гц совсем без сердечника - просто не вариант. А пластины - потому что кусок железа не против прикинуться "лишней обмоткой" до кучи. Поскольку он замкнут сам на себя - получается обмотка с КЗ, греет сам себя, что печально. Пластины изолированные друг от друга снижают этот эффект. На более высоких частотах необходимые количества витков становятся низкими, современные трансы работающие на частотах под мегагерц с ферритовыми сердечниками (в железках на такой частоте потерь много, поэтому даже пластины не годятся, только совсем не проводящий ток сердечник) имеют весьма скромные по числу витков катушки. На еще более высоких частотах может хватить и индуктивности даже умеренной по числу витков катушки без сердечника вообще. Ничему не противоречит.
Кстати, если кто думает что транс без сердечника новье и круть - ХРЕН ВАМ! Смотрим на Теслу и его катушки, например. И понимаем, что дядька делал из г-на и палок "резонансный трансформатор с воздушным сердечником". Как-то так, да. Подобные трансформаторы только начинают использовать в цивильном виде нынче. Просто потому что Теслу может и устраивали абы-какие параметры с "схемой управления" на разрядниках. Потому что просто сделать и позволяет показывать эффектные фокусы. А чтобы аккуратно и более-менее точно рулить таким процессом - надо приличный уровень развития силовой высокочастотной электроники.
> все таки идет ,конструкция получается меньше и легче на 30-40 %
> при той же мощности .Да вообще-то даже в разы, если сравнить с классической железякой. Но общая идея у всех одинаковая.
Смешное название какой-то, как игрушка
> Смешное название какой-то, как игрушкада... :)
и эт хорошо.. так как серьезные лица в инженерном мире -- особо ни кому не нужны.
https://www.youtube.com/watch?v=oAJGT-gQnVA
Смотрим "похожие новости".
Закинут в ядро и опят забросят проект?
> опят забросят проект?Опят? В проект? Вы там это... заканчивайте с опятами, вам уже хватит.
> Закинут в ядро и опят забросят проект?Передача в ядро Linux со словами "самая быстрая ФС" подтянет огромное комьюнити. Не думаю, что после этого ФС будет заброшена.
> Передача в ядро Linux со словами "самая быстрая ФС" подтянет огромное комьюнити.
> Не думаю, что после этого ФС будет заброшена.Пока-что оно словило немало невкусной критики на этапе раннего знакомства с кодом, см. дополнение к новости.
>со словами "самая быстрая ФС" подтянет огромное комьюнити.
> Не думаю, что после этого ФС будет заброшена.Ну, слова-то "самая быстрая ФС _на _одном _отдельном тесте". Сразу как-то по-другому рисуются характер "огромного комьюнити" и [не]забрасываемость.
...может, стоило напрячься и tmpfs подтюнить? Для того "одного" теста.
>>со словами "самая быстрая ФС" подтянет огромное комьюнити.
>> Не думаю, что после этого ФС будет заброшена.
> Ну, слова-то "самая быстрая ФС _на _одном _отдельном тесте".Кто говорил про один отдельный тест? Я говорю не про сравнение с tmpfs, а про сравнение с ФС постоянного хранения данных. Я видел в Инетах, что тесты с обычным dd дают очень хорошие результаты. А это уже немаловажно.
> Сразу как-то по-другому
> рисуются характер "огромного комьюнити" и [не]забрасываемость.Нет. Ничего нового не узнал, поэтому и впечатление не изменилось.
> ...может, стоило напрячься и tmpfs подтюнить? Для того "одного" теста.
Ну, вперёд ;)
>подтянет огромное комьюнитиПокажите открытую FS, которой это удалось.
> Покажите открытую FS, которой это удалось.Ну вон EXTы или btrfs пилит довольно много народа. А баги репортит и подавно. Не знаю какие там критерии огромности, но процесс идет и это вполне засчитывается.
> Ну вон EXTы или btrfs пилит довольно много народаОчень по мелочи. Основную часть и там и там делают несколько человек.
> Очень по мелочи. Основную часть и там и там делают несколько человек.Тем не менее, список коммитеров достаточно разлапист. И они таки скостили немного работы этим нескольким. Что хорошо, не так ли?
Конечно хорошо.
Часто большое количество и качество баг-репортеров намного важнее количества (и отчасти даже качества) разработчиков.
> Часто большое количество и качество баг-репортеров намного важнее количества (и отчасти
> даже качества) разработчиков.Если разработчики бакланы - никакое количество багрепортеров не поможет. Ну как с рейзер3 vs fsck сносящий файловые системы.
А где можно увидеть список поддерживаемых и планируемых features-ов? :)
> А где можно увидеть список поддерживаемых и планируемых features-ов? :)А никаких особых мегафич. Простой и быстрый CoW-like дизайн. Рассматривай это как "ext4 сделанный на современный лад". Поэтому из фич в перспективе разве что нормальные снапшоты, что характерно для CoW-like дизайнов.
Полагаю, не только для меня это будет фичей само по себе - более-менее минимальная обновлённая FS. Как ни крути, но идеи ZFS/BTRFS - "а давайте проигнорим весь стек и будем всё делать сами" - меня не привлекают ни разу.
Концепция "универсального сервера всего" уходит, вместе с ней уходит и "универсальная fs".
Давайте проигнорим и будем делать всё сами - вполне оправдана для конкретных применений - где ZFS, где Btrfs, а где и какая-нибудь https://code.google.com/p/weed-fs/.
ФС "общего назначения" останется в итоге boot да root, а для этого что угодно сгодится.
У меня в сообщении слово "универсальная" не упоминалось ни разу. Уж чего-чего, а файловых систем в линуксе хватает - на любой вкус. И применяются соответственно. Но даже не говоря о том, что на линукс-десктопе, как правило, нужно именно что-то универсальное, ситуации, где какая-то конкретная FS сильно выигрывает - редки. Навскидку разве что какой-нибудь mailspool припомню. В остальном - интенсивная работа с диском - это обычно большие БД, где лучше всего вообще голый раздел.А с Btrfs/ZFS проблема в том, что это, по сути, архитектурные монстры. Если родной стек, основанный на lvm/md, плох - надо его править или заменять каким-то другим - но именно стеком, которым может быть использован другим кодом, а не тащить тихой сапой вещь-в-себе. К ZFS, конечно, в этом плане претензий ещё больше, учитывая её проблемы с работой с памятью на линуксе, но Btr с собственным слоем RAID - ненамного лучше.
Примерно похожая ситуация произошла в своё время с иксами, когда вместо осмысленного апгрейда протокола стали городить костыли в тулкитах и гонять битмапы через XRender, в результате убив иксы. Но там хоть основания были - в частности, куча проприетарных реализаций. А здесь... в общем, грустно это.
> Если родной стек, основанный на lvm/md, плох - надо его править
> или заменять каким-то другим - но именно стеком, которым может быть
> использован другим кодом,Капитан намекает что ты упускаешь один момент: при плотной интеграции некоторых вещей можно сделать некоторые вещи лучше. Ну например если дизайн основан на CoW то специализированные снапшоты на основе того факта что это CoW - работают лучше чем generic снапшоты на уровне блочного слоя под ФС. Прикинь, да? Аналогично бывает и с размещением данных/многодисковостью и прочая. Файловая система - владеет информацией о том где и что она размещает. А остальные слои - нет. Поэтому ФС может намного эффективнее делать вещи типа ребалансировки или убирания данных с накопителя с целью изъятия. И делать такие механизмы generic, в виде который устроит совсем разные дизайны ФС, включая еще не существующие... вот если такой слой отгрохать - ты узнаешь как выглядит настоящий оверинжиниринг :).
Ничего я не упускаю. Те же снапшоты на уровне ФС и на уровне блочного устройства - это "две большие разницы". Но многие возможности - RAID тот же, или убирание данных с накопителя - могут быть реализованы в общем слое.
А что до оверинжиниринга - ну так на то и проектирование, чтобы вдумчиво сделать нужные интерфейсы. И, разумеется, никто в здравом умен не рассчитывает на те дизайны, которых ещё нет. Ровно наоборот - поддерживаться должно то, что уже есть и доказало свою востребованность. Кстати, в своё время это крайне доходчиво объяснили Рейзеру, который тоже хотел кучу фич в обход VFS делать.
> снапшоты на уровне ФС и на уровне блочного устройства - это "две большие разницы".Именно. И на уровне ФС они лучше получаются. На уровне блочных устройств это как-то совсем уж дубово и примитивно, типа управления в этажерке братьев Райт.
> Но многие возможности - RAID тот же, или убирание данных с накопителя
> - могут быть реализованы в общем слое.Не вижу как без знания файловой системы "этот файл == те блоки" можно сделать например разные уровни RAID для разных файлов. А тезис о том что в файловой системе все файлы имеют одинаковую ценность - сомнительный и упрощенный, имхо.
> вдумчиво сделать нужные интерфейсы.
На все случаи все-равно не предусмотришь. Вообще, пингвин хорош тем что не пытается всучивать мега-решения для всего и вся в ущерб решению задач. Если где-то без расовой верноты получается лучше - там идут и делают так как лучше работает, поклав на расовую верноту. А если ставить расовую верноту выше здравого смысла - получится как в фрибзде. Где супер-мега-система журналирование, универсальный ответ на все вопросы, журналит аж целый у...щный UFS. ZFS журналит сам и по своему, ему помощь не требуется. Получилось что эти граждане здорово поработали на мусорный бак, с нулевым выхлопом. То-есть, куча работы сделана, академически все правильно, а практического результата - ноль! Все хорошо в меру.
> И, разумеется, никто в здравом умен не рассчитывает на те дизайны,
> которых ещё нет. Ровно наоборот - поддерживаться должно то, что уже есть
> и доказало свою востребованность.То что уже есть и доказало свою востребованность - работает и нефиг чинить то что не сломано. Вы же не хотите получить состояние "btrfs 5-летней давности" по всей системе, правда?
> Кстати, в своё время это крайне доходчиво объяснили Рейзеру, который тоже хотел кучу
> фич в обход VFS делать.Ну так бтр делает в обход VFS только то что у него так лучше получается. Если б Рейзер привел конкретные примеры фич, которые через VFS совсем хреново делать - я думаю какой-нибудь консенсус нашелся бы. Ну как разные уровни райда для разных файлов. У ФС это знание есть, существующие в ядре райды на такие продвинутости не рассчитаны. В этом случае всем вроде понятно почему ФСина городит RAIDы самостоятельно. А если на VFS забили с абстрактным аргументом "я лучше знаю как делать правильно" - пошлют и будут по своему правы. Ибо нефиг.
> А что до оверинжиниринга - ну так на то и проектирование, чтобы
> вдумчиво сделать нужные интерфейсы. И, разумеется, никто в здравом умен не
> рассчитывает на те дизайны, которых ещё нет. Ровно наоборот - поддерживаться
> должно то, что уже есть и доказало свою востребованность. Кстати, в
> своё время это крайне доходчиво объяснили Рейзеру, который тоже хотел кучу
> фич в обход VFS делать.Никто так внятно и не показал ту "кучу", которую хотели делать "в обход VFS".
Одни только голимые вопли. Вместо того, чтобы учить Рейзера файловым системам,
они бы лучше сами у него поучились. Ибо по умолчанию никто им в клювике хорошую
файловую систему не принесет. По умолчанию будут только дерьмо пихать :)
P.S. попробуй например не залезая на уровень ФС сделать разные уровни RAID для разных файлов. Так что ценным файлам - зеркало, всякой там порнухе - stripe, ну и так далее. Блочные устройства понятия не имеют о каких либо файлах. Такое знание только на уровне ФС имеется. И, главное, я не вижу почему так должно быть нельзя.
Для этого придумали API, чтобы разные слои абстракций могли общаться друг с другом.
> Для этого придумали API, чтобы разные слои абстракций могли общаться друг с другом.И где апи позволяющие упомянутый фортель? Нету? Ну вот поэтому и сделали на уровне ФС. Более того - файловая система с чексуммами может иметь довольно кастомные пожелания к райду, типа желания повторить обломавшийся запрос несколько раз к разным носителям покуда чексум не совпадет. И не то чтобы обычные уровни ожидают или позволяют подобные маневры, опять же. Если доводить до маразма - будет как у фрибздюков с их расово верным мегажурналированием ... аж целого одного доисторического UFS-а.
> У меня в сообщении слово "универсальная" не упоминалось ни разу.Но по смыслу-то речь шла о ней, извините если мне неверно показалось.
> Уж чего-чего,
> а файловых систем в линуксе хватает - на любой вкус. И
> применяются соответственно.Ну давайте посчитаем - (для экстремалов) 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, в результате убив иксы.Да, с точки зрения красоты модели - грустно, но ничего не поделаешь.
"Линукс-десктопу, разумеется, ФС без разницы и сам линукс-десктоп тоже никому особенно неинтересен, с точки зрения фс" - именно об этом и речь. Можете прибавить сюда и андроид-девайсы, которым всё, что надо - чтобы TRIM был. И разные роутеры, у которых свои всякие SquashFS. Остаятся, в общем-то, не так уж много. у больших - свои заморочки - напоминаю, к примеру, про гугл, сидящий на ext4 без журнала. И так далее, и тому подобное.А выбор FS начинатеся тогда, когда есть понимание, чем XFS отличается от Ext4. И да, это редкий случай.
Насчет голого раздела - ок, промахнулся. Хотя тюнинг файловой системы под БД таки довольно экзотичен и подразумевает отключение всего, чего можно.
А красота модели часто четко соответствует качеству решения. Просто потому, что "красивая" (компактная, прежде всего) модель помещается в голове и создаёт меньше всяких непредвиденных частных случаев.
> И так далее, и тому подобное.Остаётся то что в середине - серверы, но меньше чем Google, Facebook и Twitter.
Это очень, очень большой рынок. Огромный.> А выбор FS начинатеся тогда, когда есть понимание, чем XFS отличается от
> Ext4. И да, это редкий случай.Этого совершенно недостаточно. Нужно еще понимать как работает с FS СУБД, конкретная, какие в ней настройки как изменяют её поведение и что куда крутить чтобы FS, СУБД и ОС были (хотя бы иногда) не лебедем, раком и щукой.
А еще сверху СУБД есть конкретные приложения, у которых свои паттерны доступа, под которые нужно всё это настраивать с пониманием чем мы жертвуем, где, и в пользу чего.
Это случай редок настолько, что его можно считать несуществующим.> А красота модели часто четко соответствует качеству решения. Просто потому, что "красивая"
> (компактная, прежде всего) модель помещается в голове и создаёт меньше всяких
> непредвиденных частных случаев.Да, лучше быть богатым и здоровым.
В реальности же мы имеем следующие проблемы на пути в светлое будущее:
- разработчики FS не могут ориентироваться на конкретную СУБД и пытаются угодить всем, причем эмпирически
- разработчики СУБД не имеют достаточно ресурсов чтобы сделать качественный полный стек под свою конкретную СУБД
- пользователи хотят получить одновременно и высокую производительность и все плюшки развитой инфраструктуры FS и ОС
> Ну давайте посчитаем - (для экстремалов) ext2, ext3, ext4, xfs, (с натяжкой) jfs.
> Остальное под линуксом либо слишком сырое (btrfs, ZFS), либо для очень специального
> применения (exFAT, NILFS2).Есть еще F2FS, который хорошо себя показывает на флешовых носителях. Есть squashfs, специализированный но весьма полезный в своей нише. JFFS2 и ряд соседних, похожих по смыслу. Reiser3 надирает зад на мелочевке. На все вкусы, в общем.
> По сути - всего три. ext3, ext4 и xfs.
Это очень упрощенная картина мира.
> тоже никому особенно неинтересен, с точки зрения фс.
Да как сказать? Это интересно тем же разработчикам, которые используют линя на десктопе и потому шкурно заинтересованы чтобы работало хорошо. Это ж не бзда и не реактос, поэтому разработчики еще и для себя этим пользуются, кроме всего прочего.
> И кто же у нас умеет работать с голым разделом?
Оракл тот же. А так он прав - теоретически СУБД делает то же что и ФС, ФС вообще можно считать специализированной БД. Поэтому когда на ФС кладут БД - запросто может случиться двойная работа. Но укладывание на RAW раздел - неудобно с точки зрения администрирования. Вот и получаются довольно интересные взаимоисключающие параграфы. То-есть в случае БД желательно чтобы ФС была относительно тонкой подложкой которая не особо гадит своими свойствами механике делавшейся под пессимистичный случай ФС.
> Да, ничего не бывает бесплатно.
Ну вон боинги и эйрбасы летают. Хотя вполне себе архитектурные монстры.
> Там ниже уже пояснили - ничего не бывает бесплатно. Хотите высокую производительность
> - придётся лезть через слои абстракций ломая их по пути.Кроме того, слои абстракций не все и не всегда предусматривают. И тот же btrfs на абстракции кладет вроде в основном тогда когда через них нормально сделать желаемые фичи не получалось.
> Да, с точки зрения красоты модели - грустно, но ничего не поделаешь.
Красивые экспонаты пусть в музеях стоят. А на компьютерах надо чтобы работало.
> "а давайте проигнорим весь стек и будем всё делать сами" - меня не привлекают ни разу.а не подскажите -- как при помощи этого самого стека (EXT4+LVM2+<???>) -- можно было бы заменить (без отмонтирования) один HDD на другой HDD?
при условии что новый HDD -- будет мЕньшего объёма чем старый HDD. (возможно за-то новый быстрее, так что не надо тут критиковать мол новый всегда якобы больше чем старый).
То, что стек не даёт это сделать сейчас - не основание не уметь это вообще. Вполне может быть, что какая-то часть его архитектуры неудачна и его надо переделывать, хотя упомянутый юз-кейс - явно не слишком важный и частый (уж ядро-то явно чаще обновлять приходится, чем диски менять, отмонтирование - явно не слишком большая проблема). Но это ни разу не основание для клепания костылей и дублирования функционала без какой-либо надежды использования его каким-то ещё кодом.
Что скажешь насчет https://www.opennet.ru/openforum/vsluhforumID3/95893.html#57 например? Попробуй предложить как сделать слой который сможет разный уровень RAID для разных файлов. И как, хорошо получается?
Я честно сидел и пытался придумать юз-кейс, когда файлы делятся по "ценности", но при этом нельзя на основе этого деления бросить их на разные разделы. Не сумел. Если приведёте боле конкретно описание ситуации (например, в виде "как оно должно выглядеть для пользователя") - подозреваю, что решение найдётся тут же. Вообще не задействующее FS.Бардак в коде тогда и начинается, когда пытаются реализовать все хотелки вместо того, чтобы определиться, какой минимальный объем фич решает задачу.
Но в принципе - не вижу ничего невозможного. Разумеется, FS это должна будет понимать - но та же XFS, к примеру, со своими volume groups очень недалеко ушла от возможности прицепить несколько устройств и как-то мапить на них файлы. А уж какой где RAID будет - её не касается.
> Я честно сидел и пытался придумать юз-кейс, когда файлы делятся по "ценности",
> но при этом нельзя на основе этого деления бросить их на разные разделы.Знаешь, заранее подготовленные разные разделы - таки рояль в кустах. И при необходимости это реконфигурить - получается кластерфак. Совсем другое дело если ты просто ткнул ФС - мол, хочу вот это на RAID0, а это RAID1. И получил то что просил. И чтоб динамически, в рантайме можно было переходить с одного на другое, etc.
> решение найдётся тут же. Вообще не задействующее FS.
Понимаешь, есть еще такая хрень как удобство. У твоих решений есть жирный минус: они как правило подразумевают что удастся запланировать народное хозяйство на ...цать лет вперед, лучше компартии СССР. А если вдруг не угадали - начинается знатный кластерфак с тасовкой разделов. Не хочу ничего сказать, но мысль просто ткнуть ФС "а разложи ка это вот так" смотрится в целом симпатичнее чем перспектива перетряхивания разделов.
> Бардак в коде тогда и начинается, когда пытаются реализовать все хотелки вместо
> того, чтобы определиться, какой минимальный объем фич решает задачу.По минимуму летать может даже кусок тряпки и палки. Пойдем, покажем боингам и эйрбасам как самолеты надо было строить? :)
> А уж какой где RAID будет - её не касается.
Зато меня очень даже касается. И жестко конфигурить на уровне разделов какие будут райды мне кажется не очень гибким и удобным решением. Пофайлово - забористее, что ни говори.
> уж ядро-то явно чаще обновлять приходится, чем диски менятьобновление ядра -- операция занимает 1 минуту (или меньше).
замена HDD -- операция занимает несколько часов. например 12 часов.
если сервер в течении 12 часов находится в offline (пока меняются диски) -- то как-то это не хорошо :-)...
даже если desktop находится 12 часов в offline -- то это тоже как-то некомфортно..
b-tree и "заметные накладные расходы" просто несовместимы
Испортить можно всё.
Указатели это хорошо
Напоминает фрактальную структуру только с китайским дизайном
> Напоминает фрактальную структуруВот эту - http://www.tokutek.com/2013/07/tokumx-fractal-treer-indexes-.../?
Кстати, они тоже придумали FS - TokuFS