freepascal.ru

мучаюсь с реляционной файловой системой - никак не могу постороить её с толком - только придумаю организацию - вроде даже неплохую - начну на практике реализовывать - выясняется что некоторые важные вещи не учтены - начинаю их учитывать - теряется скорость работы, связанная с постоянной переогранизацией (кривой нормализацией) данных... я защищённый режим помойму меньше постигал, чем эти таблицы... стыдно конечно, но времени мало выделяется - я в основном занят своей дипломной и на работе грузят - всего два программера осталось - заставили 4 системы одновременно разрабатывать и буквально до нового года... Правда жизни победила - придётся делать сместь кластерной и иерархической ФС, как задумывалось раньше. Советы с работой какого либо FAT или EXT(N) отвергаю сразу (а их было много)... на это есть несколько причин...

Сделай VFS (виртуальную файловую систему), драйвер для какой-нибудь простой ФС (хоть своей, хоть чужой...) и двигайся дальше. Потом, когда реально возникнет потребность в крутой ФС, просто напишешь очередной драйвер для ФС.

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

PS: вообще, чем глубже я изучаю *nix, тем больше утверждаюсь, что нет большого смысла писать новую ОСь (в смысле ядро...). Или может лучше сделать форк какого-то существующего ядра, например Linux...

> Сделай VFS (виртуальную файловую систему)
Как я думаю речь идет о принципиально другом восприятии системы хранения информации. Т.е. возможно не будет использована иерархическая система или использована с какими-то принципами, которые не уживаются в существующих ФС. Так что VFS "не в тему".
(Хотя я могу ошибаться.) Но если всеже я прав, то так же предположу, что использование термина файловая система в данном случае не корректно и только будет сбивать с толку. Никто же не относится к РСУБД как к файловой системе (подразумевается традичионная иерархическая).

..bw

Файловая система или база данных одно и то же. Есть некоторые
отличия и всё. А вот принципиально нового представления информации
не придумано.

Alexander
поправь меня, если я не так понимаю...: из университетских лекций помню, что информацию можно представить тремя способами: линейный, иерархический и табличный (реляционный).
Ввести реляционную ФС у меня случайно как то родилось, но я уверен что далеко не первый: после долгих поисков встречал источники что этим занимались микрософт и ibm, однако какой либо технической информации я так и не нашёл. Примеров соотвественно тоже, поэтому приходится придумывать... Сейчас я от этого пока отказался, но буду счастлив, если общими усилиями мы родим соотвествие логической структуры РБД и ФС: например что может содержать в себе кортеж, когда мы говорим о файлах и каталогах? По какому принципу и сколько таблиц надо создавать? Нормализация данных вообще отдельный аспект... а так же так как реляционная модель вообще говоря логическая - то чтобы не держать всё подряд в памяти надо бы предложить достаточно оптимально и систему физического расположения на диске.

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

Да, сам натыкался на некоторые статьи, где писалось что современные ФС идут в сторону БД... эти упоминания столь туманны, что по началу даже и не знаешь что думать...

Моё мнение: никто от иерархического представления в ближайшее время отказываться не собирается.

Поясню.

Во-первых, нужно разделить внешнее представление (то, как это представляется пользователю) и внутренее устройство (то, на самом деле реализовано). Так вот, в случае с ФС, может быть так, что внешнее представление - привычное удобное иерархическое представление. А внутренняя реализация - некоторая БД, хоть иерархическая, хоть реляционная, да хоть сетевая... О том, как упаковать иерархию в РБД погугли (или пояндекси) на тему "Деревья в SQL" - найдешь одноименную статью Joe Celko. Статья не айс, но идея там описанная очень хороша для определенных операций, например, поиска в каталоге и всех его подкаталогах: с помощью одного SQL-запроса можно получить все файлы каталога и его подкаталогов, т.е. без рекурсии.

Во-вторых, современные ФС сближаются с БД в том плане, что в ФС начинают использовать журнализацию и транзакции. Ну и внутренне устройство, тоже чем-то смахивает на БД. Например, в NTFS (и, если не путаю, в ext2/ext3 и многих *nix'овых ФС) есть структура, которую никак иначе как таблицей не назовешь... она хранит описания всех файлов (inode'ы, если я не путаю терминологию *nix). Каталоги же, только ссылаются на записи в этой строке (жесткая ссылка есть ничто иное как ссылка в каталоге на inode)... Кроме того, в таких ФС есть (могут быть) и другие таблицы, например таблица свободных кластеров, таблица битых кластеров и т.п.

Т.е. смотри. У нас есть таблица inodes - она хранить описания файлов (атрибуты, права доступа) и, в том числе ссылку на данные файла... Есть таблица catalogs - которая хранит иерархическую структуру (как описано в приведенной выше статье) каталогов и файлов. Кортежи таблицы catalogs хранят название файла/каталога, ссылку на inode и служебные данные (для связи в иерархию)... Вот тебе и получается: внешне обычная иерархическая ФС, а внутри обычная РБД...

RaiserFS, к примеру использует ещё и B-tree для организации данных (B-tree активно используются в современных СУБД, как эффективная структура для хранения данных на внешних носителях, есть довольно много модификаций...). Более того RaiserFS может хранить несколько маленьких файлов в одном кластере (на одном листе B-tree), за счет чего достигается экономия в системах где много маленьких файлов...

shade писал(а):RaiserFS, к примеру использует ещё и B-tree для организации данных

Райзер4 (или Рейзер ?) уже не доступен для скачивания - официальный
сайт не открывается http://www.namesys.com/. Последняя официальная
версия, которую удалось добыть - под 2.6.22. Ганса уже судят не первый
год и информации о прцессе почти нет. Когда то проскакивала инфа, что
он пытался судиться с М$ насчёт использования чего то из своей ФС.
Сейчас этой инфы не видно. Надо связываться с нашими разработчиками
ФС и делать форк. Гансу же и лучше будет (если не убивал).

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

У информации может быть много измерений.
Например срок актуальности (срок жизни, изменение статуса
и самого представления(формы) во времени). Важность (изменяется под
действием внешних факторов). Оценка пользователем (изменяется
пользователем). Переход из одной формы в другую (под действием внешних факторов). Спецефические для "класса" атрибуты. ИТД.

Alexander писал(а):У информации может быть много измерений.
Например срок актуальности (срок жизни, изменение статуса
и самого представления(формы) во времени). Важность (изменяется под
действием внешних факторов). Оценка пользователем (изменяется
пользователем). Переход из одной формы в другую (под действием внешних факторов). Спецефические для "класса" атрибуты. ИТД.

В моем представлении, вся возня вокруг БД-подобных ФС поутихла как раз после того, как начали задаваться вопросом "а откуда, собственно, эти метаданные возьмутся?", и понимания того, что пользователя не удастся заставить их вводить...

Sergei I. Gorelkin писал(а):"а откуда, собственно, эти метаданные возьмутся?"

Большинство этой "метаинформации" должна извлекать из ситуации
сама ОС. Только то, что НЕИЗБЕЖНО ДОЛЖЕН вводить пользователь
он и должен вводить.

Это понятно... Но кто будет решать, что именно "неизбежно должен" пользователь? В общем-то, пользователь системе ничего не должен, а совсем наоборот.
Если я в конторе с неким определенным документооборотом работаю, мне начальник может что-нибудь такое приказать. Но опять же, это я конторе должен, а не операционной системе

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

Показательный пример - Subversion. В ранних версиях репозитарий хранили в Berkeley DB, позже перешли на обычные файлы. Этим решили тонну проблем с неснятыми локами, поломками базы, избыточным занимаемым местом...

Помойму это "должен" мы делаем сейчас и никто не возмущается : всякий отдаёт честь истории и указывает расширения - помойму замечательный принцип разделения информации - pas, doc, html... колосальный принцип разделения...
другой пример: кодек кодирует и хлоп вам avi с инфой допустим Mpeg4/mp3 выдает, сразу понятна структура файла (знающим кодирование естестно)...
идём далее - уже сейчас хороший текстовый процессор может с большой (пусть лучше с удовлетворительно большой, чтобы не придерались) вероятностью определить сходу чего там за кодировка используется (UTF X/cp N) и язык на котором написанно, при учёте, что в среднем мы вряд ли 3-мя языками пользуемся...
смотрим далее - допустим сжатые архивы однотипной инфы можно лить в один общий архив, соотвественно вообще не изменяя дерево кодирования, а легко и быстро добавлять и вынимать от туда нужный файл...

вся информация уже сегодня достаточно хорошо разделена на
1)тексты(PAS/TXT/DOC) и несжатый бред(типа BMP/WAV)
2)упаковки(ZIP/MP3/JPG)
3)программы(EXE/ELF)
на любом компе! и уже сегодня... среди неё тоже можно спокойно провести разделение по объёмам, темам, важности, типу... например тексты разделить на форматированные и линейные, на программном или естественном языке, программы на графические, звуковые, редакторы и вообще море примеров. Представляете, например, на сколько интеллектуальна будет система поиска?

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

О том что инфа обязанна быть реляционной понять можно легко - по расширениям и их содрежимому, по неудачным попыткам микрософта в виде Program Files и My Documents, по различию в кодировках и борьбе с этими различиями...

помойму все постоянно ходят вокруг да около, придумывают какие то свалки инфы одного типа, которые быстро приходят в мусорку на винте, борятся с преобразованием типов и пишут DLL... но никто не хочет увидеть очевидного: всё систематизированно!

Не надо искать порядка в иерархии - она кривая, как и её деревья,
таблицы спасут мир

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

Рожденный_в_СССР писал(а):Помойму это "должен" мы делаем сейчас и никто не возмущается : всякий отдаёт честь истории и указывает расширения - помойму замечательный принцип разделения информации - pas, doc, html... колосальный принцип разделения...

Расширения указываем не мы - это делают программы, создающие файлы. Мы же (если говорить о виндовых пользователях, коих большинство) в массе своей вообще об этих расширениях понятия не имеем.

Рожденный_в_СССР писал(а):Представляете, например, на сколько интеллектуальна будет система поиска?

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

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

Я все вот к чему: работа с типами информации - это не уровень файловой системы, это уровень приложений (которые сейчас уже почти всегда выходят за рамки одного компьютера). От файловой системы требуется минимальная поддержка типа "вот тут изменилось, переиндексируй".

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

не согласен. привожу пример, того что у меня было не далее как сегодня утром: я пью чай, собираюсь на работу, звонит подруга просит скинуть ей насканированный файл книжки для дипломной - лезу на диск C, среди огромной кучи барахла отыскиваю папку с документами, среди кучи барахла в этой папке отыскиваю папку со сканированными вещами, там копаюсь, открывая всё подозрительное, пока не найду то, чего мне нужно... проблемы на лицо:
1) в том что если распихать это барахло совсем по науке, то выйдет огромная вложенность, если не распихивать - выйдет свалка - постоянно нужно думать о какой то середине
2) какого хера мне запоминать какие то там насканированные месяц назад книги да ещё и не для себя? как я её назвал и куда поместил? команду в стиле locate разве что по расширению искать - и получу огромную кучу всего подряд... это же сдохнуть можно...
в суме от этих проблем не поможет не иерархия ФС не какой-либо поисковик вообще... потому что что искать я сам с трудом представляю, вернее как обяснить поиску что я хочу? А сколько много времени тратиться у всех на подобные операции?

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

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

ДА! Вы вправе спросить а что же дальше и в чём выигрыш? А я спрошу а где же ваша фантазия? Очевидно её держит иерархия - директории и файлы, вы мыслите ими... это не правильно... не нада каждый раз искать среди кучи файлов нужный ориентируясь то на расширение, то на объём, то на имя и т.д. давайте пофантазируем, какие реально выигрыши будут...
Вот как я себе это представляю на деле:
Так как, как понятие файл - у нас теперь не набор кластеров с именем и типом, а просто строка(картеж) в таблице, в которой указанны все свойства файла, его местонахождени (на секторах диска) и т.д. то файлы именуем по тому что там есть: типа "моя курсовая работа за 1 курс", аналогично тому, что сейчас в винде... только с чистой совестью не боясь "~" и "..." или недопустимых знаков аля ":\"... также можно указать некую аналогию папкам - типа категория "Универ" в отдельной вкладке... всё, больше никаких путей и прочего... программа сама должна пробить в таблице тип информации в файле, его кодировку, каким класом программ открывать и каким редактировать, что то вроде кодов, ну и всего остального по мелочам. Во время открытия файлов - запускаем соотвествующую программу - причем не ищем её судорожно по диску, не копаемся в пуске и не вспоминаем её названия - а просто вызываем что-то типа обращения в консоле к SQL: Editors.Text.PDF и он выдает нам все доступные едиторы пдф - в нем нажимаем открыть далее не надо копаться по всему "My Computer" от папки к папке, вспоминая пути - выходит окно, аналогичное обычному хелпу в винде/лазарусе... в нем в ключевой строке пишем курсовая, в одну секунду из соответствующей таблицы выскакивает все PDF с текстом курсовая, никаких путей и прочего... обычный select * from pdf_files where... операция на секунду... а вот среди этой кипы уже не нада думать - тыкаем как в хелпе на каждую строчку - смотрим как нить предпросмотр, даты, размеры, прогу, которой создали... имхо проще найти, если даже внешний ключ забыли (то название файла) можно критиковать, но так же можно и развить идею дальше. Например появится возможность писать в консоле команды в стиле скопировать на флешку, всё что сделал для работы вчера (интелект налицо) а не набор папок, в каждой из которых ещё не все файлы мне нужны на флешке...

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

Sergei I. Gorelkin писал(а):Я все вот к чему: работа с типами информации - это не уровень файловой системы

Сейчас так. А вообще это именно её уровень. Причём не (/ не только)
с типами, а и с самой информацией.

Рождённый_в_СССР писал(а):Помойму это "должен" мы делаем сейчас и никто не возмущается : всякий отдаёт честь истории и указывает расширения - помойму замечательный принцип разделения информации - pas, doc, html... колосальный принцип разделения...

Да, именно так. А то, что пользователь не всегда умеет с этим
работать ничего не значит. Если он хочет что то делать он должен
разбираться в типах файлов, если нет - многие задачи он решить
не сможет. Так сейчас.

Sergei I. Gorelkin писал(а):Связать исходники с бинарником, или файл с его архивом - можно запросто, причем даже на уровне современных ФС

Эээто как ?

Sergei I. Gorelkin писал(а): Начинать компилить бинарник при изменении исходника, или при передаче бинарника на другой комп выводить радостное сообщение о том, что исходники больше недоступны? Ни то, ни другое пользователя в восторг явно не приведет.

Приведёт, приведёт. Механизмы наследования / связи должны быть, но и не только они.

Sergei I. Gorelkin писал(а):Если я в конторе с неким определенным документооборотом работаю, мне начальник может что-нибудь такое приказать. Но опять же, это я конторе должен, а не операционной системе

Дожен это не значит что ОС, если ей инфа потребуется, возмёт тебя
могучей рукой и заставит что то сделать. Тебя заставит желание
улучшить работу со своей инфой.

Вот песня / музыка - она тебе может нравиться, быть пофигу или не нравиться. Также и кино. Собственная фотография. Программа.
Человек.

Такие разные ТИПЫ, а ОЦЕНКА их похожая. И здесь, в основном, может
сказать только ползователь. В основном, значит, что можно приводить
статистику востребованности, но это почти всегда не верно. Могут
быть и другие методы автоматики. Не значит ли, что ОС должна
поддерживать оценку ? Сразу.

А у музыки могут быть автор, исполнитель, жанр, темп, про что,
весёлая/грустная, детская, не детская(например матерная) - уровень
грубости / слащавости, политическая, религиозная.

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

Часть этих атрибутов приемлимы и к фильмам и к другим типам.

Есть и не атрибутные вещи. Информация может изменяться по важности
и другим атрибутам с течением времени по весьма хитрому алгоритму.
Новости устаревать и либо удаляться автоматически, либо уходить
в архив, в том числе в зависимости от их смысла. ИТД. При приходе
новой версии / качества (и высокой оценки этого пользователем) чего
либо, старая (связь!) терять важность или вообще удаляться.

Сейчас количество информации резко растёт и пользователь физически
не может работать с ней сам напрямую.

Так как, как понятие файл - у нас теперь не набор кластеров с именем и типом, а просто строка(картеж) в таблице, в которой указанны все свойства файла, его местонахождени (на секторах диска) и т.д. то файлы именуем по тому что там есть: типа "моя курсовая работа за 1 курс", аналогично тому, что сейчас в винде... только с чистой совестью не боясь "~" и "..." или недопустимых знаков аля ":\"... также можно указать некую аналогию папкам - типа категория "Универ" в отдельной вкладке... всё, больше никаких путей и прочего...

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

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

уникальный ключ - это и есть путь к файлу
если человек грамотно создает каталоги, то проблемы не будет
а если не грамотно, то он также неграмотно напишет ключ и ничего потом не найдет

так сейчас все так вроде и есть

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

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

в прямом понимании граматно - это помнить все файлы на вашем диске... неужели вы некогда не искали что нить вроде eMule Incoming среди кучи папок?... неужели вы не рылись в деревьях иерархии по всему кому в поисках где же там хелп, который шёл с пхп?... не пытались найти старую программу с названием, которое давно забыто? а самое обидное, что чаще всего после того как находите - там большая свалка однотипных файлов и там уже нада искать свой а-ля index...

обычный поисковик тоже вещь далеко не удобная - чтобы получать эти индификаторы... к нему я лично прибегаю крайне редко, когда никаких других надежд уже нет... причем этот процесс иногда бывает догим (индексация в линуксе, поиск в винде), зачем? если всё можно искать проще... за 1 вхождение в 1-3 таблицы (зависит от заданной конкретизации)

всё таки попробуйте на секунду представить как бы было без путей, без папок и файлов...