LINUX.ORG.RU

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


0

2
  1. Разработка простых ФС с минимумом функционала, но экстремально высокой производительностью 404 (51%)

    ********************************************************************************************************************************************************************************************************************************************************************************************************************************

  2. Устойчивость, реализация технологий RAID и LVM в самой ФС 273 (34%)

    ************************************************************************************************************************************************************************************************************************

  3. Возможности распределённого хранения данных в сети 265 (33%)

    *****************************************************************************************************************************************************************************************************************

  4. Унификация ФС, создание дополнительных уровней абстракции данных 201 (25%)

    ***************************************************************************************************************************************************************

  5. Развитие ФС, специфичных для определённых физических носителей 198 (25%)

    ************************************************************************************************************************************************************

  6. Широкое использование технологий баз данных, минимизация различий между ФС и СУБД 162 (20%)

    ********************************************************************************************************************************

  7. Наращивание потенциала «облачных» файловых систем 125 (16%)

    ***************************************************************************************************

  8. Множественные виртуальные представления реальной ФС 124 (16%)

    **************************************************************************************************

  9. Усиление объектной компоненты, развитие концепции блоков метаданных 104 (13%)

    **********************************************************************************

  10. Другое (в комментарии) 30 (4%)

    ***********************

Всего голосов: 1886, всего проголосовавших: 798

★★★★★

Проверено: post-factum ()

Сделали бы сначала фс, которая после потери питания не теряла файлы, а то создают чуть не каждый день что-то новое, а на стабильность и стрессустойчивость особо внимания не обращают.

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

да не надо RADI и LVM, вы сделайте сначала чтобы данные не пропадали. Даже ntfs в этом плане более стабильная чем ext3.

kodx
()
Ответ на: комментарий от kodx

вы сделайте сначала чтобы данные не пропадали.

На Ext3 включайте журналирование не только метаданных файловой системы, но и самих данных. Такая мозможность есть. У UFS2 нет возможности защитить данные от разрушения, Soft Updates защищает только консистентность метаданных ФС. ZFS обеспечивает разнообразные механизмы защиты пользовательских данных, нужно только подходящим образом настроить её свойства, что новички забывают сделать.

iZEN ★★★★★
()

IMHO, на этом поприще уже все что можно было сделать сделано.

mutronix ★★★★
()
Ответ на: комментарий от prizident

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

Типичный пример так называемой «наивной» реализации

deis
()
Ответ на: комментарий от matumba

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

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

Что reiser, что btrfs (насчет других не в курсе) используют алгоритмы, которые были отработаны именно на базах данных - те же сбалансированные деревья, например

deis
()
Ответ на: комментарий от DRVTiny

> Так почему бы не применить аналогичную технологию и к файловым системам?

Сдаётся мне, что тут самое трудное будет именно стандартизировать атрибуты. А без этого вся затея не будет иметь смысл.

Ну если это будет что-то «внешнее» по отношению к собственно ФС, я не против. Но превращать саму ФС в БД...

hobbit ★★★★★
()

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

hobbit ★★★★★
()
Ответ на: комментарий от iZEN

Честно, с опциями не экспериментировал, надо глянуть. Просто когда пропали файлы после 5и раз подряд отключения питания внезапного, стало очень неприятно, особенно когда в той же ситуации ntfs (с родным драйвером и системой) нормально жил и ничего не терял.

kodx
()

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

У меня одного эта фраза ассоциируется с широкой электрификацией южных губерний?

Ttt ☆☆☆☆☆
()

Определенно во всех.

papay ★★★
()

Не стоит в ФС тянуть фишки LVM или RAID. Unix-way говорит, что каждое дело должна делать одна узкоспециальзированная подсистема, и не нужны нам ужасные и ненадёжные(в силу монструозности) ФС. Да и принцип KISS всегда помогает реализовать лучшие продукты, наиболее легко модифициуемые и расширяемые. И простые в поддержке.

Нужно реализовать и унифицировать работу с файлами, как с объектами. Развивать и обогащать подсистему, отвечающую за работу с файлами при помощи добавления унифицированных контейнеров, в которых будут располагаться различные метаданные и потоки данных.

Примерное устройство правильной подсистемы для работы с файлами.

1.Реальные устройства со своей спицификой. 2.Универсальный(абстрактынй) интерфейс доступа на чтение/запись. 3.LVM2 3.Заточенные под специфическое оборудование, и спецефические задачи, ФС. 4.Контейнеры, хранящие потоки данных и кучу метаданных к этим потокам. При этом строгая стандартизация для разных типов метаданных и данных, а также кросплатформенные сценарии для интерактивных меню, установки из таких стандартных «пакетов» ПО и т.д. Контейнеры и унифицированный доступ к ним, и их содержимому - вот что станет вершиной в цепи устройства>уровни абстракций(LVM и т.п.)>ФС>данные и метаданные. Хранить метаданные на уровне ОС не имеет смысла, т.к. при копировании на более «простую» ФС мы их потеряем:)

lucentcode ★★★★★
()
Ответ на: комментарий от lucentcode

>Хранить метаданные на уровне ОС не имеет смысла, т.к. при копировании на более «простую» ФС мы их потеряем

Почему? При копировании из MacOS на VFAT мы не теряем метаданные, они копируются как отдельный набор файлов. Конечно, это выглядит некрасиво на FAT, но и сама FAT настолько стара и дряхла, что гением чистой красоты её уже явно не назвать, так что чего смущаться морщинам на её лице?

DRVTiny ★★★★★
() автор топика

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

SpeedyWizard
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.