MylnikovDm » 24.02.2015 12:59:00
Я смотрю, тема про файловые системы заглохла...
Но если кому-то вдруг понадобится.
Во-первых, не надо путать внутреннее представление информации на диске на урвоне ОС и внешнее представление для пользователя. Это разные вещи. Представление в виде папок и дерева для пользователя не означает, что именно в этом виде данные должны хранится на диске. Раньше было именно так, внутренняя структура данных повторяла то, что видит пользователь, сейчас во многих ФС это не так.
Во-вторых, в большинстве случаев, когда в разговорах про файловые системы упоминается СУБД, то имеется в виду не реляционная СУБД! Главная особенность реляционной СУБД в том, что запись имеет фиксированную длину, поэтому имеется возможность быстро получать нужную строку записи из таблицы. Именно на этой важной особенности строится механизм индексов, без которых невозможно реализовать быстрый поиск или выборку по условию. Но при работе с произвольной, то бишь неструктурированной или плохо структурированной информацией, которая представляется в виде файлов, которые для ОС просто набор байт произвольной длины, использование именно реляционной модели неэффективно именно в силу переменной длины записей, что сводит на нет все преимущества от реляционной модели. Да, сегодня во всех реляционных СУБД имеется такое понятие как BLOB, но это расширения за рамками стандартной реляционной модели и в большиснтве случаев работает очень медленно.
В третьих, если уж вести речь об использовании реляционной модели хранения данных при разработке ФС, то это имеет смысл делать не ко всем данным, которые хранятся в ФС, а только к метаданным, которые хранятся о файлах. Старые файловые системы имели ограниченный набор характеристик файла, которые описывали его свойства. При этом они, действительно, хранились в структуре с фиксированной длиной записи, которые являлись таблицами. Недостатком этой системы было то, что раньше расширить этот набор характеристик было невозможно. Во многих современных файловых системах это уже не совсем так. Если брать ту же NTFS, то это многовекторная модель представления данных, где каждый из файлов может содержать произвольное количество векторов, а каждый из векторов может иметь произвольную длину (в пределах объёма хранилища, естетственно). При этом и сами каталоги, и главная таблица метаданных (MDT), которая описывает структуру размещения информации на диске, с точки зрения модели и системы являются такими же векторами. Другими словами, MDT хранит только описание самих векторов, то бишь номера блоков на диске, которые образуют тот или иной вектор данных, и ничего кроме этого. Всё остальное, включая всевозможные метаданные о каталогах и файлах, хранится в виде вектора, который вкладывается в MDT. Соответственно, описатель файла теперь не запись фиксированной длины в таблице каталога, как это было в FAT, а один из множества векторов каталога, который имеет переменную длину. Поэтому каталог из таблицы превратился в многовекторную структуру, где кажждый вектор является описателем либо файла, либо другого каталога, вложенного в данный. При этом само описание всех векторов хранится в MDT, а в каталогах только ссылка на номер вектора в MDT. Кстати, права на файл или папку в NTFS также представляются в виде дополнительного вектора к файлу, у которого главным вектором является собственно содержимое файла в традиционном представлении. Но в NTFS уже доступен API для работы с любым файлом как многовектороной структурой. То есть, можно прикрепить дополнительный вектор с данными к любому файлу. При этом если программа ничего не знает про то, что у файла есть дополнительные вектора, то она будет продолжать работать с ним как с обычным файлом, видя только главный вектор данных.
Так что, если уж вести разговор о разработке некой новой ФС, то в начале необходимо определиться, что нас интересует в первую очередь, внутренняяя структура хранения информации или удобство её представления и использования для пользователя. Причём второе должно подразумевать соответствующий набор удобных инструментов, иначе толку не будет. Причём и на уровне командной строки, и на уровне графического интерфейса.
Опять же, если мы создаём некий формализованный механизм работы с метаданными файла, который позволяет разрсширять набор характеристик файла, фактически превращяя его в некий аналог записи в таблице реляционной СУБД, то в этом случае можно говорить о том, что каталог становится аналогом таблицы в реляционной базе данных, в которой запись это файл с главным вектором нулевой длины, если нам нужны только простые поля. Если же нам нужны BLOB'ы, то тогда они добавляются к файлу как дополнительные векторы данных, один из которых мы можем объявить главным. Он будет выступать в роли файла для старых программ, которые про новую структуру ничего не знают. Опять же, для совместимости мы можем ввести понятие предопределённых обязательных полей, наличие которых позволяет данную таблицу представлять для старых программ как каталог (папку). Если этих полей нет, то старые программы такой каталог не видят, и он доступен только как таблица для новых программ.
Кстати, есть реазлизации систем электронного документооборота, которые при установке создают в системе виртуальный диск, отображающий файлы и папки, как на обычном сетевом диске. Но при этом данные на самом деле хранятся внутри реляционной СУБД и транслируются с помощью специального драйвера в представление в виде файловой системы. При этом кроме стандартных команд, которые есть в любой файловой системе, они добавляют специфичекие команды, которые доступны только для этого диска и появляются в меню проводника при правом клике на файле, типа синхронизации, сохранения изменений в хранилище, просмотра разных версий файла, откат содержимого файла к выбранной предыдущей версии, просмотр листа прохождения согласований и т.п.
Кроме того, не стоит забывать, что и реляционные СУБД не стоят на месте. Если раньше использовалась только модель хранения таблиц по строкам, то сейчас во многих СУБД, например ORACLE или PostgreSQL имеется возможность хранить таблицы по столбцам, поскольку для некоторых задач поиска и анализа это оказывается выгоднее.
тут
) а где-то восстановленный до уровня 3д модели ситуационный анализ катастрофы основанный на слабенькой звуковой дорожке и совершенно посторонних вроде бы данных ...