Как мы столкнулись с (иерархической) файловой системой в качестве базовой структуры данных?

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

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

Например, если бы я мог иметь собственные теги для файлов, где я мог бы помечать изображения, диаграммы, документы для обработки текста, весь репозиторий кода, все как принадлежащие одному проекту, это было бы действительно полезно для меня. Так как я застрял в парадигме файловой системы, я знаю, что мог бы поместить все это в одну папку / каталог, но что, если они уже существуют в разрозненных каталогах, и они должны оставаться там? Я знаю, что есть программы, которые могут это сделать, но почему они не находятся в файловой системе?

Что-то, что было бы неплохо иметь, это какая-то реляционная особенность в файловой системе, как вы получаете с RDBMS. Я понимаю, что это должно было быть частью Vista / 7, но это также выпало из списка возможностей.

Конечно, любая программа может хранить бинарный файл и иметь любую необходимую ему структуру данных. Почему ОС не может предложить более сложные способы хранения данных, кроме простой иерархии файловой системы?

Начните с этого: http://en.wikipedia.org/wiki/Unix_File_System

Прочитайте это: http://www.unix.org/what_is_unix/history_timeline.html

Тогда прочитайте это: http://www.amazon.com/UNIX-Filesystems-Evolution-Design-Implementation/dp/0471164836

Есть простой ответ: «Почему ОС не может предложить более сложные способы хранения данных, кроме простой иерархии файловой системы?»

Потому что это слишком много для ОС.

Для этого предназначены библиотеки и пакеты приложений.

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

Python использует библиотеку DBM для создания очень сложных структур хранения на диске.

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

Дело в том, что ОС должна делать минимум, а все это надстройка.

Краткий ответ: каждый день люди понимают файловую систему. Это напоминает им о картотеке. Подумайте о веб-страницах и даже о толстых приложениях. Почему вы думаете, что Tabsони так популярны? Люди могут идентифицировать себя с ними и быстро понять их.

Imaging пытается научить бабушку искать файл в БД по тегам свойств. С файловой системой бабушка знает, что файл находится там, где она его положила .

Даже с WinFS я не думаю, что MS собиралась избавиться от внешнего вида файловой системы.

Здесь есть доля правды в каждом ответе, но я не думаю, что это вся правда.

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

Люди не понимают древовидную файловую систему больше, чем понимают основанную на DAG.

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

Причина, по которой мы до сих пор их используем, - это смесь подхода «это подойдет» и реальной необходимости поддерживать совместимость со старым кодом. Новый подход к хранению файлов будет означать радикальные изменения в базовом API файлового ввода-вывода, делая большую часть существующего кода бесполезной. Либо это, либо вы должны ходить на цыпочках вокруг них, поддерживая устаревший API. Помните PROGRA ~ 1.

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

Теперь я собираюсь перейти на другую сторону.

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

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

На самом деле, я однажды реализовал хранилище документов с богатыми метаданными и иерархией на основе DAG. (Это был даже не DAG произвольной формы, это была строго двухуровневая метаструктура и документы, которые могли быть дочерними для коллекции уровня 1 или уровня 2. Так что это действительно просто.)

Очевидно, что требование о том, что имена документов должны быть уникальными в пределах коллекции, должно было остаться.

И тогда проблемы начали течь. Что если вы откроете коллекцию и измените имя документа на то, что конфликтует с другой коллекцией, к которой также принадлежит документ? Мы отобразили сообщение об ошибке, но пользователи были совершенно сбиты с толку. (Это те самые пользователи, которые просили об этом требовании.)

Они пытались удалить документ, но все, что было сделано, это удалить его из коллекции. Таким образом, это все еще обнаружилось в результатах поиска. Мы попробовали это и наоборот, но потом они жаловались, что они удалили документ из коллекции A, и он волшебным образом исчез из коллекции B. Поэтому нам потребовалась и операция «unlink» и операция полного удаления.

В конце концов мы уступили поражение, к счастью, еще вовремя.

Тем не менее, дополнительные аспекты поиска, которые сделали возможными метаданные, сработали абсолютно.

Честно говоря, я едва касаюсь метаданных в моих файлах на Mac. Я думаю, что за последние 5 лет использования OSX (который поддерживает комментарии и т. Д.) Я использовал метаданные, возможно, для 2 файлов. Не сказать, что это плохая идея.

Я просто не уверен, насколько прагматичны накладные расходы для тегов.

Я думаю, что самая приятная особенность файловой системы, о которой я знаю, - это система управления версиями на уровне файловой системы, которая работает между разделами. Это было сделано на VAXen в 70-х и начале 80-х, не зная, почему он не завоевал популярность в Unix и NTFS / Windows.

Я работал с неиерархическими файловыми системами на старых версиях, таких как HP3000 и Encore / Gould. У вас не было каталогов; у вас была группа и учетная запись, а файлы назывались « group . account . file », например, «users.jbode.myfile1», «dev.jbode.main» и т. д.

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

Я не вижу, где (по крайней мере, некоторые) текущие файловые системы действительно должны сделать много [Edit: что-нибудь, чтобы быть честным], чтобы поддерживать теги. Когда вы приступаете к этому, поддержка тегов означает немного больше, чем некоторые дополнительные данные, связанные с файлом, но не записывается в поток байтов для этого файла.

NTFS (чтобы выбрать один пример, который широко используется) может сделать это просто отлично: что касается NTFS, файл не обязательно является одним потоком байтов. В NTFS вы можете связать произвольное количество потоков данных с одним именем файла. Каждый файл имеет (возможно, пустой) «первичный поток», который не имеет имени. Однако он также может иметь произвольное количество других потоков, каждый из которых должен иметь имя. Используя это, было бы действительно тривиально добавить поток с именем (только для примера) «теги» в существующий файл и (очевидно, достаточно) записать ваши теги в этот поток.

После этого наступает несколько более сложная часть: заставить ваши инструменты использовать теги, которые вы там поместили. В идеале, вы, вероятно, захотите проиндексировать их для быстрого поиска, чтобы вы могли делать такие вещи, как создание «виртуального каталога» из всех файлов с определенным тегом.

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

Если бы мне на мгновение позволили быть циничным, я бы сказал, что неизбежно, что эта функция NTFS останется почти полностью проигнорированной и неизвестной. В конце концов, он прост в использовании и не требует специального API или чего-либо еще. Вы можете использовать его в полностью переносимом C, C ++ или любом другом, что позволит вам указать произвольное имя файла. Вот небольшой фрагмент кода, демонстрирующий создание файла с AFS:

#include <fstream>

int main() {
    std::ofstream out("test.txt");
    std::ofstream tag("test.txt:tags");

    out << "This is the output file";
    tag << "tag1 tag2";

    return 0;
}

И вот код для чтения и отображения тегов:

#include <fstream>
#include <iterator>
#include <iostream>
#include <string>

int main() { 
    std::ifstream tags("test.txt:tags");

    std::copy(std::istream_iterator<std::string>(tags),
          std::istream_iterator<std::string>(),
          std::ostream_iterator<std::string>(std::cout, " "));
    return 0;
}

Все очень просто и легко. Обратите внимание, что, хотя я написал только тривиальный бит данных, вы можете рассматривать AFS как любой другой файл - все обычные «вещи» работают так же, как и все остальное. При обычном отображении каталога все, что будет отображаться, - это первичный поток (например, размер, показанный для файла, будет размером первичного потока), но, если вы хотите его увидеть, dir может также отображаться информация об альтернативных потоках. с /Rфлагом. Например, листинг для файла, созданного выше, выглядит так:

03/16/2011  08:22 PM                23 test.txt
                                     9 test.txt:tags:$DATA
               1 File(s)             23 bytes