FAT32 подойдёт? :)

Результаты опроса поккказывают почему райзер4 никому не нужен. Лично моя точка зрения совсем другая.

Врядли :)

1) Создание и развитие свободных файловых систем с высокой производительностью/низкими требованями к железу, оптимизированных для flash-памяти, что бы вытеснить exFAT (два пункта сразу)
2) Разработка ФС с возможностями теневого копирования, встроенной системой контроля версий и возможностью хранить повторяющиеся блоки данных один раз, что бы не было разницы в производительности между простым копированием и созданием жесткой ссылки. Да, ZFS и btrfs уже есть, но пусть вначале Oracle опубликует коды первой под gpl-совместимой лицензией.
А может лучше что-то более легковесное, что будет содержать эти полезные возможности, но оставит RAID и LVM другим уровням абстракции
3) Разработка возможностей поиска файлов по ключевым словам... Но это всё возможно на другом уровне абстракции. Зачем сращивать файловую систему с реляционной СУБД?

По пунктам, которые НЕ выбрал:

Устойчивость, реализация технологий RAID и LVM в самой ФС

гы :) Это не те же ребята, которые «окна» интегрировали в ОС? :))))))

Возможности распределённого хранения данных в сети

Слишком специфично, даже не все сервера имеют такую потребность.

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

А смысл? То, что физически разное, под «унифицированным» доступом потеряет свои приватные преимущества. Ну сделали /dev/* - и что? Опять нагородили граблей.

Широкое использование технологий баз данных

Типичное школоло с годом вращения в ИТ. ФС - это не база, как бы ни была она похожа. ФС прежде всего - это хранилище файлов на конкретном носителе, причём с учётом структуры этого носителя. Базе эта структура пофиг. Да и ОС эта «база» тоже пофиг. Всех операций с файлами дай бог пять, зачем там целый СУБДшный энжын??

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

А это не тот же пенис «распределённого хранения данных в сети»??

Усиление объектной компоненты, развитие концепции блоков метаданных

NTFS это давно имеет, но как показала практика, нафик никому не упёрлось. Да и «объективизировать» там, по большому счёту, нечего - открыл, прочёл, закрыл.

Вот куда бы ФС ещё идти - так это немного слиться со спецификой ОС: подразделять файлы (повышенной защиты, редкоиспользуемые, временные, нерасширяющиеся, и т.п.), а так же упростить служебные структуры - все эти «ноды-хреноноды» слишком много требуют, давая смешной минимум удобств. Заодно эта простая структура позволит более тривиально переносить инфу - сейчас все ФС - это такие навороченные угрёбища, которые без спец.утилит не перенести даже на гомогенную структуру.

распределённость - это хорошо. Приятно было бы ещё ФС ala БД. Тем более, что, в сущности, это одно и то же

Другое: файловые системы не должны развиваться, ибо бессмысленно

под разные задачи - разные ФС с разными направлениями развития

Reiser4.

В сторону модульности и настраиваемости под конкретные нужды.

«Усиление объектной компоненты, развитие концепции блоков метаданных». Чтобы все те фичи, которые предоставляют Непомнюк, Стриги и т.п., обеспечивались прямо в файловой системе.

А иначе позор же: как только мы переходим от мышеводства в Dolphin к низкому уровню — cp, mv — все труды по классификации, рейтингованию и тэгированию содержимого идут прахом.

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

Но в них ещё нет тэгов и виртуальных представлений :)

>А иначе позор же: как только мы переходим от мышеводства в Dolphin к низкому уровню — cp, mv — все труды по классификации, рейтингованию и тэгированию содержимого идут прахом.

+1000000, абсолютно с вами согласен!
Это давно уже должно решаться на уровне, а не на уровне приложений. Да и сколько лет прошло с момента создания HPFS, где мета-тэги уже были и мало-по малу использовались? А воз и ныне там!

> HPFS, где мета-тэги

костыли! в OS/2 все это работало через одно место. в отличие от BFS (BeOS)

Лорчую первый пункт. Но с модульностью хотя бы уровня reiser4.

Внедрения функционала систем контроля версий на уровне файловой системы.

Разработка простых и шустрых, с развитым АПИ, чтобы можно было запилить технологии БД ;-)

Нувыпонели))

Хотеть online resize в обе стороны и lvm на уровне ФС.

>Метки, теги, встроенный в сами файлы
Это свойства самих файлов. Загляни в свойства документов - там есть и теги, и метки (ключевые слова) и т.п. Вот только не пользуются этим «несферические пользователи»

Это не то.

Отметил всё.
Долой универсальную FS!!!
Даёшь специализированные FS!!!

Я, вообще-то про «востребованность». И про что, у всего есть своя специализация. На мой взгляд «содержимое документа» - это свойство «документа», а не файловой системы.

>> Но в них ещё нет тэгов и виртуальных представлений

Про представления тут уже говорили, что это дело fuse, а тэги в XFS можно приделать через дополнительные атрибуты.

>> Внедрения функционала систем контроля версий на уровне файловой системы.

nilfs, что ли?

>> online resize в обе стороны

Ext3, ext4, btrfs?

lvm на уровне ФС

Btrfs, но зачем? о_О

>а тэги в XFS можно приделать через дополнительные атрибуты

Да, но от неиндексированных тэгов никакого толку нет.

Ext3, ext4, btrfs?

Через resize2fs? Спасибо, но хотелось бы без подобных танцев. btrfs не смотрел, но разве она уже стабилизировалась?

Btrfs, но зачем? о_О

чтобы избавиться от лишней сущности (т.о. повышая общую отказоустойчивость)

Я вот собираюсь второй терабайтник покупать, и было бы здорово просто расширить на него существующую ext4 без использования lvm.

>> Да, но от неиндексированных тэгов никакого толку нет.

...и написать индексатор :) Правда, в известной степени это решение хуже DE-зависимых реализаций, поскольку, в данный момент, окажется привязанным к конкретной ФС...

>> Через resize2fs? Спасибо, но хотелось бы без подобных танцев

А что там не так? Я пробовал, чисто из любопытства, всё нормально, никаких «танцев».

но разве она уже стабилизировалась?

Нет, и вряд ли это скоро случится.

чтобы избавиться от лишней сущности (т.о. повышая общую отказоустойчивость)

Да ничего ты не повысишь. Device mapper уж точно понадёжнее дисков, на которых используется ;)

Я пробовал, чисто из любопытства, всё нормально, никаких «танцев».

Я не считаю последовательность tune2fs, parted, resize2fs, tune2fs вменяемой. Это адский вудуизм. Почему нельзя сделать ресайз со включенным журналом? Почему в NTFS это можно, а в ext3/4 - нельзя?

Да ничего ты не повысишь. Device mapper уж точно понадёжнее дисков, на которых используется ;)

Вообще-то чем меньше в системе узлов, тем она надежнее. Это основа всей идеологии отказоустойчивых систем.

>Вообще-то чем меньше в системе узлов, тем она надежнее. Это основа всей идеологии отказоустойчивых систем.

Полупроводниковая электроника как раз стала бурно развиваться из-за того, что надёжность микросхемы слабо зависела от количества элементов в ней.

>Полупроводниковая электроника как раз стала бурно развиваться из-за того, что надёжность микросхемы слабо зависела от количества элементов в ней.

Полупроводниковая электроника начала бурно развиваться задолго до микросхем :) И исключительно из-за экономичности и технологичности.

А надёжность зависит от числа элементов как и раньше. Просто каждый элемент интегральной схемы ОЧЕНЬ надёжен.

>> tune2fs

Что?

Почему нельзя сделать ресайз со включенным журналом?

ШТО?! У тебя ядро кривое, или что? Всё прекрасно делается онлайн с журналом.

>А надёжность зависит от числа элементов как и раньше. Просто каждый элемент интегральной схемы ОЧЕНЬ надёжен.

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

Значит, я отстал от жизни. Пойду перечитаю матчасть :)

>Вероятность отказа полупроводниковой микросхемы зависит от числа элементов только косвенно

Точно также, как и на печатной плате — прямо. Отказ любого элемента столь же способен привести к отказу всей схемы, как и в варианте дискретного монтажа.

>Отказ любого элемента столь же способен привести к отказу всей схемы

Ага, только вероятность отказа всей схемы гораздо сильнее зависит от площади кристалла, чем от того, один крупный элемент приходится на эту площадь или миллиард мелких.

>Ага, только вероятность отказа всей схемы гораздо сильнее зависит от площади кристалла

При чём тут площадь кристалла? Вероятность отказа пропорциональна количеству элементов. Что в дискретной схеме, что в интегральной.

чем от того, один крупный элемент приходится на эту площадь или миллиард мелких

Ога. Один крупный убить сложнее :D

Выбрал два пункта - про экстремально высокую производительность и про унификацию. Хотя прочие тоже представляют интерес.

А вот «минимизация различий между ФС и СУБД» - это, я считаю, ответ на вопрос, в каком направлении НЕ должны развиваться файловые системы. Microsoft на эти грабли уже со всего размаху наступил и быстренько слез - правильно, давайте теперь ещё всем линуксом на них наступим, заняться больше нечем.

«Microsoft сделало много неправильных ставок. Например, WinFS, рекламируемое как средство организации поиска путем представления файловой системы в виде реляционной базы данных, игнорирует тот факт, что настоящее средство для поиска это выполнение поиска. Не заставляйте меня впечатывать во все мои файлы метаданные, которые я могу искать, использую язык запросов. Просто сделайте мне одолжение и поищите впечатанную мною строку на чертовом жестком диске, быстро, используя полнотекстовые индексы и другие технологии, наскучившие еще в 1973» (Дж. Спольски, 2005 г.).

Это эффективнее решается развитием технических средств. :)

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

Хорошая идея, кстати.

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

Я говорю о ZFS в каждом каталоге! ;)

Во всех этих и многих других. Очевидно же. Только не всё в одну ФС.
//Не голосовал.

отказаустойчивость

странно проц скалывал а он работал некоторые элементы на материнки оторвал а она работает наверное всё таки не все детали входящие в систему нужны некоторые можно выкинуть 8-)

У меня мог потерял девственность от этого опроса ;) Взял «Простые ФС с офигенной производительностью», оказался в большинстве :(

>странно проц скалывал а он работал некоторые элементы на материнки оторвал а она работает наверное всё таки не все детали входящие в систему нужны некоторые можно выкинуть


Вынос мозга, а не фраза, три раза её перечитал, пока не проникся всей полнотой глубочайшего содержания.

>Не заставляйте меня впечатывать во все мои файлы метаданные, которые я могу искать, использую язык запросов

Мне жаль, но они туда впечатываются без вашего участия - теми приложениями, которые файлы создают. Да вон даже цифровой фотомыльницей, чего уж далеко ходить.
Другое дело, что формат представления этих метаданных может быть плохо структурирован или вовсе ограниченно стандартизован даже в рамках одного формата файлов. Теперь взгляните, например, на атрибуты каталога (того, который LDAP, не того, который $HOME) : здесь атрибуты и синтаксис (формат) их значений стандартизованы, здесь есть определённый scope схем, в которых атрибуты описываются и считается дурным тоном придумывать что-то с потолка, как это принято в тех же классических SQL-СУБД. Так почему бы не применить аналогичную технологию и к файловым системам? Тогда, например, значение атрибута «scale» можно было бы получить из файла шрифта, из векторного изображения, из фрагмента топографической карты. Why not?
Настоящим ужасом является по-моему ситуация наподобие той, что была в середине 90-х, когда у элементарнейшего формата BMP было минимум 4(!) типа бинарных заголовков в зависимости от того, какая ОС соответствующий файл сгенерировала.

буквально вчера удалял с ext3 две папочки, гигов по 10-15. на каждую ушло примерно по полтора часа. ну путь там было много файлов, но полтора часа....

максимальное использование шин данных + кучи процессоров для высоконагруженных систем

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

Остальное - тоже нужно, но не всё (об этом ниже).

Что не следует делать:
1. Устойчивость, реализация технологий RAID и LVM в самой ФС
Надёжность надо обеспечивать другими методами, а не костылями в ФС.

2. Широкое использование технологий баз данных, минимизация различий между ФС и СУБД
Опять - неоправданное усложнение ФС. С этой задачей прекрасно справляется программная надстройка в виде СУБД с индексатором. Засорять базовую систему нельзя.

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

4. Усиление объектной компоненты, развитие концепции блоков метаданных
Развитие концепции блоков метаданных -опять нагромождение ФС. Метаданные правильнее реализовывать на уровне формата файла, а не ФС. Хотя бы потому, что всё учесть не получится. А если и попытаться, то будет перегруженная спецификация и раздутая реализация. Кроме того встаёт вопрос о совместимости между ФС.
Объектная компонента - это другой уровень абстракции, поэтому и реализация должна быть не на уровне ФС.

Если говорить короче - всякие навороты ФС может и делают её удобной в чём-то, но гробят нафиг совместимость между другими ФС. Поэтому в ФС должны быть реализованы такие функции, которые относятся к безопасности данных (права доступа и _системные_ метаданные). Всё остальное - в юзерспейс.
Файл - это сама по себе абстракция. Надо её использовать полноценно, а не плодить дополнительные абстракции на уровне ФС.

Скорость, надежность, универсальность.