Ключевые слова:fs, (найти похожие документы)
From: jkeks <jkeks@mail.ru>
Newsgroups: email
Date: Mon, 9 Dec 2003 14:31:37 +0000 (UTC)
Subject: Введение в опреционные системы с многослойными файлами
спердатор: введение в опреционные системы с многослойными файлами
Операционные системы с подобной технологией на данный момент (2003г.)
отсутствуют.
Однако это не значит, что эта технология не имеет будущего. Майкрософт
выпустила Longhorn в которой сочетаются приципы NTFS и SQL
И это произошло только спустя много лет после создания классических принципов.
На самом деле предлагаемая технология вносит не так и много изменений.
Та же древовидная структура, однако файлы представляют собой не единое целое
информационное пространство, а некий массив, или хэш, или таблица или любая
сложная структура подчиняющаяся некоторым правилам.
Хорошим примером будет язык программирования - Perl, где любая сложная
структура строиться на основе некольких простых объектах.
только каждая такая структура - это есть один файл.
Можно привести еще один пример, где каждый файл представляет собой объект со
свойствами и методами. Классы же определяют тип коплекса данных (тип
совокупности слоев)
Ну а слои, слои - это определенные участки файла содержащие типизированные
данные.
В случае примера с Перлом: у нас имеется массив массивов. Этот массив - файл,
а массивы массива - это слои.
Для чего нужны такие слои ?
Основной задачей является - разделение всех данных на типы.
Вообще предистория данной статьи такова, что уже не один год идет борьба между
Perl и PHP. И то что в PHP считают плюсом (встраивание кода в html), на самом
деле является минусом,(хотя это лично мое мнение) Разделение дизайна от
контента и от кода, вот к чему необходимо привести это направление, чтобы
каждая технология смогла независимо резвиваться.
Дак вот.. в случае с html. Дизайн хранится в одном слое, контент в другом,
что-то еще в другом и т.д.
хэ... чего-то не хватает правда ведь ?
Не хватает связей между слоями.
Связи - это аналог функции #include в Си, который хранит ссылки на включаемые
участки информации из других слоев.
Эти ссылки могут быть прозрачны для чтения информации.
Представим файл, где слой 1:
АБВГДИЙКЛМН
Слой 2:
ЖЗ
Слой 1 имеет внутреннюю информацию примерно следющую:
05:слой2:0:2
что означает поместить в слой 1 в позицию 05 из слоя2 из позиции 0 взять 2
байта.
В результате при чтении файла получим:
АБВГДЖЗИЙКЛМН
Однако мы можем прочитать лишь первый слой и тогда мы прочитаем:
АБВГДИЙКЛМН
а можем отедльно обратиться ко второму слою.
Но я описал самую простую ситуацию, когда всего 2 слоя, в данной технологии
много трудностей (рекруссивные сылки, а что если несколько ссылок на три слоя,
а читаются только два ?, и т.п.)
На самом деле все еще немного сложнее, ведь привыкшие к классическим осям
людям сложно понять новые принципы.
А наш следующий принцип - отсутствие файлов и слоев.
Как ? и зачем я тогда рассказывал о слоях ?
Дело в том, что я описал, что такое - слой, что это определенный подуровень
разделения типов данных.
В UNIX более элегантно подошли к этому вопросу, где устройства выглядят как
папки.
Давайте забудем что у нас есть даже папки.
Надо забыть, что нету содержимого файлов (по простой причине того что нету
файло)
Вся сурь работы операционной системы сводится к обработке одного хэша, причем
не простого хэша, а где в качестве значений ключей являются ключи.
Тогда нам открываются безкрайние просторы.
МОжно представить себе:
{c:}{windows}{temp}{virus.htm}{<html>assle</html>}
Давайте условимся называть это вектором.
Этот вектор как видно показывает нам полный пусть в понимании нынешней ОСи
windows до файла, включая его содержимое.
Закрыли глаза, теперь снова абстрагируемся от форточек.
Что это ?
{c:}{windows}{temp}{virus.htm}{<html>assle</html>}{assle}
Наш вектор теперь заканчивается ключом assle, дак что значит virus.html - это
не файл ?
Ничего не получается.. ну хорошо..
Если вы так хотите: Содержимое файлов может так же быть именем для следующего
ключа.
Если выражаться нормальным языком, то мы уходим от органичения на длинну имени
файла.
Давайте возьмем другой пример:
{.}{dev}{hd0}{block}{AAAAAAAAAAAA...}{BBBBBBBBBB....}{c}{.}
Нулевой вектор
Но мы говорили о хэше без значений, это же значит что у кажого ключа может
быть своя ветка.
И действительно..
Мы можем нарисовать следующее
{.}{dev}{hd0}{block}{AAAAAAAAAAAA...}{z}
{x}
{c}
{BBBBBBBBBB.....}{z}
{x}
{c}
{СССССССССССС...}{z}
{x}
{c}
у ключа block есть три ключа, у кажого из которых еще по три.
И каждый ключ мы можем назвать файлом (если уж нам так нравится это название)
даже если этот ключ имеет ссылки на другие ключи.
Теперь вернемся к вопросу о слоях (про которые я говорил, что они нахрен не
нужны на самом деле.
Если мы обзовем ключ block - файлом, тогда ключи
AAAAAAAAAAAA...
BBBBBBBBBB.....
СССССССССССС...
будут якобы слоями, но теперь у нас огромное преимущество - если мы назовем
СССССССССССС... - файлом, тогда слоями будут
z
x
c
т.е. мы имеем безграничное число слоев, и безграничное число слоев в слоях и
т.д.
Теперь взглямнем сюды:
{a}{ala.64мб..la{al}}{b}
как нам добраться до ключа b ?
1.{a}{ala.64мб..la{al}}{b}
2.{a}{{al}}{b}
3.{a}{ala.64мб..la}{b}
эти векторы аналогичны.
А следующий пример заставит упасть вас в обморок:
{.}{dev}{hd0}{block}{AAAAAAAAAAAA...}{z{{BBBBBBBBBB.....}{z}}}
{x}
{c}
{BBBBBBBBBB.....}{z}
{x}
{c}
{СССССССССССС...}{z}
{x}
{c}
в векторе
{.}{dev}{hd0}{block}{AAAAAAAAAAAA...}{z}
конечный ключ будет иметь значени евтки {BBBBBBBBBB.....}{z}
Дело в том, что алиас - это на самом деле ссылка, если грубо говоря алиас он в
том случае, если у нас он заключен в одни фигурные скобки, а ссылка, то в
двойные.
Нет,я вовсе не объясняю синтаксис будущей файловой системы, а пишу об этих
условностях ради понимания принципов работы.
Вообщем-то вот мы и добились того чего хотели.. универсальной системы, где очень
примитивные принципы, однако эта универсальность даст значительно больше чем
сейчас.
Хотя кто я такой чтобы это утверждать ?
я просто так думаю.
______________________________
by jkeks in 14 ноября 2003 г.
mailto:keks_revda@uraltc.ruhttp://revda.bizhttp://jkeks.far.ru
