В каких направлениях должны развиваться файловые системы?

> В каких направлениях должны развиваться файловые системы?

Во многих из перечисленных. Но ноиболее интересным мне кажется (если я правильно понял, что подразумевается под этим пунктом) «Множественные виртуальные представления реальной ФС».

Не увидел в списке такого пункта, как развитие средств и способов журналирования, версионирования и создания снапшотов. Остальное из перечисленного либо уже реализовано в достаточной мере, либо не нужно.

Множественные виртуальные представления реальной ФС

Это должно решаться средствами типа fuse, а той ФС, которая на диске.

s/а той ФС/а не той ФС/

>Множественные виртуальные представления реальной ФС

Виртуальные представления - когда объекты файловой системы могут быть представлены в любой удобной структуре. Примером можно назвать файловую систему QNX, где основа является пакетно-ориентированной версионной, но виртуальное представление позволяет приложениям видеть традиционную nix-подобную структуру.

>Не увидел в списке такого пункта, как развитие средств и способов журналирования, версионирования и создания снапшотов.

Версионирование - полезная фича, пожалуй, стоит добавить. Реализуется и как virtual view, но сами по себе версии должны конечно поддерживаться на low-level

Эффективный поиск. Семантический или какой угодно. Метки, теги, встроенный в сами файлы. Это облегчит поиск и в Сети.

Плюсую, снапшоты - это вкусная вещь.

>Плюсую, снапшоты - это вкусная вещь.
Ну так есть же уже в LVM. Или вы о множестве контрольных точек для «оката»?

Теги хочу. И автоматическую индексацию, чтобы проще было искать. Т.е. ФС по сути должна содержать базу данных, в которой нужный инод можно найти не только по имени файла, но и по меткам.

>Ну так есть же уже в LVM

Как оно там реализовано - это мрак.

чой-то я не понял
а разве производительность имеет отношение к надёжности? о_О
в нормальных фс ака reiserfs (3* которая) эти понятия друг другу не мешают абсолютно
итого - хде пункт «и максимальная производительность и максимальная надёжность»?
все эти недофс ака экст сливают по обоим параметрам райзеру

расстрелять!

расстрелять!

>но сами по себе версии должны конечно поддерживаться на low-level
расстрелять!

>можно найти не только по имени файла, но и по меткам.
Проблема в том, что во многих ФС для nix есть поддержка метаданных, но нет... «клиентской части», которая их использует. То есть можно хранить исчерпывающую информацию, например, о какой-нибудь фотографии, включая географические координаты, контактные данные автора, настройки, при которых была осуществлена съёмка, краткое описание... и т.д., и т.п. - например, как метаданные в XML-формате. Но если эта информация никем не используется и все приложения всё равно ради «универсальности» так и будут пользоваться методиками каменного века, изучая бинарные заголовки файлов (как правило, не заполняемые и на 10% возможного или заполняемые чисто формально), то и поддержка метаданных будет бесполезна.
Поддержка метаданных может быть в Mac OS X, в OS/2, да и в оффтопике наконец, но в Linux, где традиционно стандартом является «широкий ассортимент» этих самых стандартов - это всё бесполезно. Да и где в той же фундаментальной GlibC хоть слово о чтении метаданных файлов? GlibC прочно засела в юрском периоде и вылезать оттуда не собирается, потому что ну зачем это нужно, если nix'ы - это сплошь сервера, где по определению от метаданных профита мало...

в таком чтоб больше порнухи на хард влезало, безо всяких облачных концепций и унифицированных абстракций.

man архиваторы

хотя прон...не - не пожмёшь
задача нереализуема
потому нахер

Иди so see. Или предлагай что-то получше.

megabaks

расстрелять!

Надо:
1. Унификация ФС, создание дополнительных уровней абстракции данных,
то есть весь зоопарк существующих ФС можно гибко интегрировать в единую универсальную ФС на уровне её списка свойств.
2. Устойчивость, реализация технологий RAID и LVM в самой ФС,
то есть необходима и обязательна реализация сквозной целостности данных, «верификации-в-обработке».
3. Усиление объектной компоненты, развитие концепции блоков метаданных
и отсюда вытекает следующий пункт
4. Множественные виртуальные представления реальной ФС
5. Возможности распределённого хранения данных в сети,
что, кстати, сейчас очень востребовано, особенно в кластерах.

Не надо:
1. Широкое использование технологий баз данных, минимизация различий между ФС и СУБД,
так как усложняет ядро унифицированной ФС.
2. Наращивание потенциала «облачных» файловых систем,
так как «облака» — частный случай распределённых вычислений.

Под вопросом:
1. Развитие ФС, специфичных для определённых физических носителей
2. Разработка простых ФС с минимумом функционала, но экстремально высокой производительностью
поскольку из носителей у нас только: динамическая память, магнитные поверхности, лазерные диски и флэш, а MRAM находится в стадии разработки.

О, тут знатные эксперты по файловым системам. Будет весело.

Вообще, опрос противоречив. Есть множество систем разной направленности, и каждая развивается себе куда нужно.

Я бы ещё добавил в то, что нужно от ФС: Возможность распадаться на составляющие её ветви без разрушения, например, большую ФС хотелось бы разделять логически по подкаталогам без разрушения, переносить отдельные ветви каталогов на другой носитель, объединять каталоги с разных носителей. Другими словами, делать безболезненное прозрачное урезание размера ФС и, наоборот, расширение её на другие носители.

>например, большую ФС хотелось бы разделять логически по подкаталогам без разрушения, переносить отдельные ветви каталогов на другой носитель, объединять каталоги с разных носителей.

Вы прямо о LDAP в мире ФС говорите :)

Длинные варианты, опять пингвины будут в два ряда...

Другое. Необходима быстрая и устойчивая кластерная ФС.

Ext4 и XFS уже есть :)

• Разработка простых ФС с минимумом функционала, но экстремально высокой производительностью
• Развитие ФС, специфичных для определённых физических носителей

Внутреннюю память многих модных нынче устройств можно расширить только SD-картами.

RAID+Возможности распределённого хранения данных в сети получается. Вы можете выбрать два варианта. Плюс конечно совместный доступ, нет такого варианта... Но если всё писать, тут получился бы список на сотню пунктов, без обиняков. По-моему даже и больше можно. Решил, что нехай будет ещё и «Другое» :)

Метки, версионирование, внешние носители.

В направлении Reiser4 :)

> Разработка простых ФС с минимумом функционала, но экстремально высокой производительностью

Прежде всего СКОРАСТЬ!!!!111

Множественные виртуальные представления реальной ФС

Это что-то типа WinFS?

Cогласен. Самый логичный ответ тут - Облачные технологии, элементарно же, за ними будущее

* Разработка простых ФС с минимумом функционала, но экстремально высокой производительностью
* Унификация ФС, создание дополнительных уровней абстракции данных

Я за простые быстрые ФС с унифицированным функционалом.

Странный опрос.

Для разных задач разные фс. Где-то важна скорость, где-то возможности распределённого хранения данных с резервированием и т.д.

В чем смысл темы?

А нафига 'развивать' то что прекрасно работает? Чтобы всё это усложнялось тормозило и имело кучу багов?

А реальные направления развития:

лучшая поддержка различных физических носителей, (нормально фс для usb/sd сейчас просто НЕТУ)

изменение размера блоков данных.

что тут ещё сказать???

В направлении длины имени файла в 255 и больше знаков Юникода :(

Унификация ФС, создание дополнительных уровней абстракции данных

Развитие ФС, специфичных для определённых физических носителей

Наращивание потенциала «облачных» файловых систем

Разработка простых ФС с минимумом функционала, но экстремально высокой производительностью

Проголосовал за эти варианты.

> В направлении длины имени файла в 255 и больше знаков Юникода :(

Зачем? Такие длинные имена очень редко встречаются. А если встречаются, то тем кто их создал нужно немедленно оторвать руки, в целях профилактики.

А где пункт «стабилизация уже существующих решений»?

Хотелось бы что-то такое же удобное, как hg, но на уровне файловой системы: коммиты, ветки, логи. В принципе, в zfs необходимый функционал есть, нужно только накрутить поверх фронтенд с похожим интерфейсом.

http://www.linux.org.ru/forum/general/5957886

поддерживаю

Всё кроме «Разработка простых ФС с минимумом функционала, но экстремально высокой производительностью». Скорость вообще не важна.

* Возможности распределённого хранения данных в сети
* Развитие ФС, специфичных для определённых физических носителей
* Унификация ФС, создание дополнительных уровней абстракции данных
* Широкое использование технологий баз данных, минимизация различий между ФС и СУБД
* Наращивание потенциала «облачных» файловых систем
* Усиление объектной компоненты, развитие концепции блоков метаданных

Разработка простых ФС с минимумом функционала, но экстремально высокой производительностью

Очень туманный пункт.

>Разработка простых ФС с минимумом функционала, но экстремально высокой производительностью

В сочетании с

Развитие ФС, специфичных для определённых физических носителей

- вполне разумно.

>В направлении Reiser4 :)
Идея правильная, но все же пишут на PHP и Java то, что приносит тугрики здесь и сейчас, так что на перспективу работать особо и некому. А так как Reiser4 - это не какой-то сверхновый функционал, а «всего лишь» сильная алгоритмическая база, то и нет заинтересованности в ней. Капитализму нужны не совершенные решения, а чистая прибыль здесь и сейчас. Поэтому облачные технологии будут развиваться, кластерные ФС тоже, а скорость будет обеспечивать стремительно дешевеющее железо, а не умные алгоритмы. У Reiser4 нет будущего в мире без идеалов и долгосрочного планирования.

Думаю, что ФС должна быть простая и надёжная

Разработка простых ФС с минимумом функционала, но экстремально высокой производительностью

Остальное некритично.