файловая система

Обсуждение идей, архитектуры и проектов (как существующих, так и разрабатываемых).

Модераторы: Рождённый_в_СССР, Модераторы

Re: файловая система

Сообщение Alex2013 » 01.09.2013 14:45:46

Что то похожее на "3д ОС" я предлагал :arrow: тут
Хотя я за более "очеловеченное представление" что-бы было за что глазу зацепится . Не просто "3д" таблица а "виртуальный ландшафт " (Привет "Газнокосильщку") Память людей устроена ассоциативно что это значит ?
А то чем больше продуманных "архитектурных излишеств" тем проще будет что-то найти в тему кинули ссылку на Eagle Mode так вот это пример "улицы строительной " все крайне однотипно и однообразно . А я предлагаю представлять ос действительно в виде 3д карты "диптауна" (Виртуального города действительно напоминающего реальный хотя-бы до уровня отдельных зданий)
Alex2013
энтузиаст
 
Сообщения: 698
Зарегистрирован: 03.04.2013 11:59:44

Re: файловая система

Сообщение MylnikovDm » 24.02.2015 12:59:00

Я смотрю, тема про файловые системы заглохла...

Но если кому-то вдруг понадобится.

Во-первых, не надо путать внутреннее представление информации на диске на урвоне ОС и внешнее представление для пользователя. Это разные вещи. Представление в виде папок и дерева для пользователя не означает, что именно в этом виде данные должны хранится на диске. Раньше было именно так, внутренняя структура данных повторяла то, что видит пользователь, сейчас во многих ФС это не так.

Во-вторых, в большинстве случаев, когда в разговорах про файловые системы упоминается СУБД, то имеется в виду не реляционная СУБД! Главная особенность реляционной СУБД в том, что запись имеет фиксированную длину, поэтому имеется возможность быстро получать нужную строку записи из таблицы. Именно на этой важной особенности строится механизм индексов, без которых невозможно реализовать быстрый поиск или выборку по условию. Но при работе с произвольной, то бишь неструктурированной или плохо структурированной информацией, которая представляется в виде файлов, которые для ОС просто набор байт произвольной длины, использование именно реляционной модели неэффективно именно в силу переменной длины записей, что сводит на нет все преимущества от реляционной модели. Да, сегодня во всех реляционных СУБД имеется такое понятие как BLOB, но это расширения за рамками стандартной реляционной модели и в большиснтве случаев работает очень медленно.

В третьих, если уж вести речь об использовании реляционной модели хранения данных при разработке ФС, то это имеет смысл делать не ко всем данным, которые хранятся в ФС, а только к метаданным, которые хранятся о файлах. Старые файловые системы имели ограниченный набор характеристик файла, которые описывали его свойства. При этом они, действительно, хранились в структуре с фиксированной длиной записи, которые являлись таблицами. Недостатком этой системы было то, что раньше расширить этот набор характеристик было невозможно. Во многих современных файловых системах это уже не совсем так. Если брать ту же NTFS, то это многовекторная модель представления данных, где каждый из файлов может содержать произвольное количество векторов, а каждый из векторов может иметь произвольную длину (в пределах объёма хранилища, естетственно). При этом и сами каталоги, и главная таблица метаданных (MDT), которая описывает структуру размещения информации на диске, с точки зрения модели и системы являются такими же векторами. Другими словами, MDT хранит только описание самих векторов, то бишь номера блоков на диске, которые образуют тот или иной вектор данных, и ничего кроме этого. Всё остальное, включая всевозможные метаданные о каталогах и файлах, хранится в виде вектора, который вкладывается в MDT. Соответственно, описатель файла теперь не запись фиксированной длины в таблице каталога, как это было в FAT, а один из множества векторов каталога, который имеет переменную длину. Поэтому каталог из таблицы превратился в многовекторную структуру, где кажждый вектор является описателем либо файла, либо другого каталога, вложенного в данный. При этом само описание всех векторов хранится в MDT, а в каталогах только ссылка на номер вектора в MDT. Кстати, права на файл или папку в NTFS также представляются в виде дополнительного вектора к файлу, у которого главным вектором является собственно содержимое файла в традиционном представлении. Но в NTFS уже доступен API для работы с любым файлом как многовектороной структурой. То есть, можно прикрепить дополнительный вектор с данными к любому файлу. При этом если программа ничего не знает про то, что у файла есть дополнительные вектора, то она будет продолжать работать с ним как с обычным файлом, видя только главный вектор данных.

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

Опять же, если мы создаём некий формализованный механизм работы с метаданными файла, который позволяет разрсширять набор характеристик файла, фактически превращяя его в некий аналог записи в таблице реляционной СУБД, то в этом случае можно говорить о том, что каталог становится аналогом таблицы в реляционной базе данных, в которой запись это файл с главным вектором нулевой длины, если нам нужны только простые поля. Если же нам нужны BLOB'ы, то тогда они добавляются к файлу как дополнительные векторы данных, один из которых мы можем объявить главным. Он будет выступать в роли файла для старых программ, которые про новую структуру ничего не знают. Опять же, для совместимости мы можем ввести понятие предопределённых обязательных полей, наличие которых позволяет данную таблицу представлять для старых программ как каталог (папку). Если этих полей нет, то старые программы такой каталог не видят, и он доступен только как таблица для новых программ.

Кстати, есть реазлизации систем электронного документооборота, которые при установке создают в системе виртуальный диск, отображающий файлы и папки, как на обычном сетевом диске. Но при этом данные на самом деле хранятся внутри реляционной СУБД и транслируются с помощью специального драйвера в представление в виде файловой системы. При этом кроме стандартных команд, которые есть в любой файловой системе, они добавляют специфичекие команды, которые доступны только для этого диска и появляются в меню проводника при правом клике на файле, типа синхронизации, сохранения изменений в хранилище, просмотра разных версий файла, откат содержимого файла к выбранной предыдущей версии, просмотр листа прохождения согласований и т.п.

Кроме того, не стоит забывать, что и реляционные СУБД не стоят на месте. Если раньше использовалась только модель хранения таблиц по строкам, то сейчас во многих СУБД, например ORACLE или PostgreSQL имеется возможность хранить таблицы по столбцам, поскольку для некоторых задач поиска и анализа это оказывается выгоднее.
MylnikovDm
новенький
 
Сообщения: 71
Зарегистрирован: 15.02.2007 21:26:10
Откуда: Челябинск

Re: файловая система

Сообщение Alex2013 » 04.04.2016 01:12:38

MylnikovDm писал(а):Я смотрю, тема про файловые системы заглохла...

Но если кому-то вдруг понадобится.

Во-первых, не надо путать внутреннее представление информации на диске на урвоне ОС и внешнее представление для пользователя. Это разные вещи. Представление в виде папок и дерева для пользователя не означает, что именно в этом виде данные должны хранится на диске. Раньше было именно так, внутренняя структура данных повторяла то, что видит пользователь, сейчас во многих ФС это не так.

Во-вторых, в большинстве случаев, когда в разговорах про файловые системы упоминается СУБД, то имеется в виду не реляционная СУБД! Главная особенность реляционной СУБД в том, что запись имеет фиксированную длину, поэтому имеется возможность быстро получать нужную строку записи из таблицы. Именно на этой важной особенности строится механизм индексов, без которых невозможно реализовать быстрый поиск или выборку по условию. Но при работе с произвольной, то бишь неструктурированной или плохо структурированной информацией, которая представляется в виде файлов, которые для ОС просто набор байт произвольной длины, использование именно реляционной модели неэффективно именно в силу переменной длины записей, что сводит на нет все преимущества от реляционной модели. Да, сегодня во всех реляционных СУБД имеется такое понятие как BLOB, но это расширения за рамками стандартной реляционной модели и в большиснтве случаев работает очень медленно.

В третьих, если уж вести речь об использовании реляционной модели хранения данных при разработке ФС, то это имеет смысл делать не ко всем данным, которые хранятся в ФС, а только к метаданным, которые хранятся о файлах. Старые файловые системы имели ограниченный набор характеристик файла, которые описывали его свойства. При этом они, действительно, хранились в структуре с фиксированной длиной записи, которые являлись таблицами. Недостатком этой системы было то, что раньше расширить этот набор характеристик было невозможно. Во многих современных файловых системах это уже не совсем так. Если брать ту же NTFS, то это многовекторная модель представления данных, где каждый из файлов может содержать произвольное количество векторов, а каждый из векторов может иметь произвольную длину (в пределах объёма хранилища, естетственно). При этом и сами каталоги, и главная таблица метаданных (MDT), которая описывает структуру размещения информации на диске, с точки зрения модели и системы являются такими же векторами. Другими словами, MDT хранит только описание самих векторов, то бишь номера блоков на диске, которые образуют тот или иной вектор данных, и ничего кроме этого. Всё остальное, включая всевозможные метаданные о каталогах и файлах, хранится в виде вектора, который вкладывается в MDT. Соответственно, описатель файла теперь не запись фиксированной длины в таблице каталога, как это было в FAT, а один из множества векторов каталога, который имеет переменную длину. Поэтому каталог из таблицы превратился в многовекторную структуру, где кажждый вектор является описателем либо файла, либо другого каталога, вложенного в данный. При этом само описание всех векторов хранится в MDT, а в каталогах только ссылка на номер вектора в MDT. Кстати, права на файл или папку в NTFS также представляются в виде дополнительного вектора к файлу, у которого главным вектором является собственно содержимое файла в традиционном представлении. Но в NTFS уже доступен API для работы с любым файлом как многовектороной структурой. То есть, можно прикрепить дополнительный вектор с данными к любому файлу. При этом если программа ничего не знает про то, что у файла есть дополнительные вектора, то она будет продолжать работать с ним как с обычным файлом, видя только главный вектор данных.

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

Опять же, если мы создаём некий формализованный механизм работы с метаданными файла, который позволяет разрсширять набор характеристик файла, фактически превращяя его в некий аналог записи в таблице реляционной СУБД, то в этом случае можно говорить о том, что каталог становится аналогом таблицы в реляционной базе данных, в которой запись это файл с главным вектором нулевой длины, если нам нужны только простые поля. Если же нам нужны BLOB'ы, то тогда они добавляются к файлу как дополнительные векторы данных, один из которых мы можем объявить главным. Он будет выступать в роли файла для старых программ, которые про новую структуру ничего не знают. Опять же, для совместимости мы можем ввести понятие предопределённых обязательных полей, наличие которых позволяет данную таблицу представлять для старых программ как каталог (папку). Если этих полей нет, то старые программы такой каталог не видят, и он доступен только как таблица для новых программ.

Кстати, есть реазлизации систем электронного документооборота, которые при установке создают в системе виртуальный диск, отображающий файлы и папки, как на обычном сетевом диске. Но при этом данные на самом деле хранятся внутри реляционной СУБД и транслируются с помощью специального драйвера в представление в виде файловой системы. При этом кроме стандартных команд, которые есть в любой файловой системе, они добавляют специфичекие команды, которые доступны только для этого диска и появляются в меню проводника при правом клике на файле, типа синхронизации, сохранения изменений в хранилище, просмотра разных версий файла, откат содержимого файла к выбранной предыдущей версии, просмотр листа прохождения согласований и т.п.

Кроме того, не стоит забывать, что и реляционные СУБД не стоят на месте. Если раньше использовалась только модель хранения таблиц по строкам, то сейчас во многих СУБД, например ORACLE или PostgreSQL имеется возможность хранить таблицы по столбцам, поскольку для некоторых задач поиска и анализа это оказывается выгоднее.


Что-то брезжит в моем понимании ... но "массив зашумлен " ...
И почитанного вытекаю две идеи:
1 А нельзя ли что-то выиграть если позволить прикладным программам "знать о много-векторности " (в более устоявшейся терминологии это если я верно понял ПОТКИ NTFS ) современной ФС не только через механизм создания дополнительных ссылок ?
(NTFS поддерживает "альтернативные потоки данных" -ADS. Обычный файл является "неименованым потоком". Внутри файла или каталога можно создать "именованые потки".)

2 А так ли важно с точки зрения "надструктур" типа ЭглеМоде структура ФС ?
Так же как методы мнемоники как бы ничего "не зная" о физическом устройстве нашего мозга прекрасно работают после их освоения .Они создают свое виртуальное логическое "пространство состояний" (континуум ) поверх уже существующего многоуровневого "когнитивного поля " . :idea:
И при этом умудряются работать БЫСТРЕЕ и НАДЕЖНЕЕ "нативных" механизмов памяти ....

То есть идея что чем ближе уровень доступа "к железу" тем "быстрее и надежнее доступ к данным", работает только, на очень примитивных системах ...
После преодоления некой точки усложнения все может работать с точностью до наоборот . Метаданные это непросто набор кластеров и секторов с "мертвыми" данными... Методанные это что-то роде фрактала участок которого нужно получить именно с нужно нам точностью и это совсем не просто "точность до последнего бита"
Где-то это может быть слабо детализированная "иконка-указатель"("клад где-то там :arrow:" :idea: :mrgreen: ) а где-то восстановленный до уровня 3д модели ситуационный анализ катастрофы основанный на слабенькой звуковой дорожке и совершенно посторонних вроде бы данных ...
Alex2013
энтузиаст
 
Сообщения: 698
Зарегистрирован: 03.04.2013 11:59:44

Пред.

Вернуться в Операционная система

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1

Рейтинг@Mail.ru