Як ми потрапили до (ієрархічної) файлової системи як до базової структури даних?

Я самоучка і не маю ступеня 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 (та інші) - це дуже складні структури зберігання, які пропонують деякі функції, схожі на базу даних.

Справа в тому, що ОС повинна робити мінімум, і все є додатком.

Коротка відповідь: Щодня люди розуміють файлову систему. Це нагадує їм файл кабінету. Подумайте про веб-сторінки та навіть програми Fat, чому ви вважаєте, що Tabsвони такі популярні? Люди можуть ідентифікувати їх і швидко їх розуміти.

Зображення намагається навчити бабусю шукати БД для файлів на основі тегів властивостей. За допомогою файлової системи бабуся знає, що файл знаходиться просто там, де вона його розмістила .

Навіть з WinFS я не думаю, що MS збирається позбутися вигляду файлової системи.

У кожній відповіді є трохи правди, але я не думаю, що це вся правда.

Перелічені в основному функції, які щодня дуже не вистачають користувачам та розробникам.

Люди не розуміють файлову систему на основі дерева, ніж розуміють DAG-систему.

І зовсім немає виправдання для жалюгідних додатків імен файлів, що називаються розширеннями. Вони не тільки повністю непридатні за своїм призначенням (визначення типу файлу), але і нескінченне джерело неприємностей для користувачів.

Причина, по якій ми все ще їх використовуємо, - це суміш ставлення «що робити» та реальної потреби підтримувати сумісність із старішим кодом. Новий підхід до зберігання файлів означатиме докорінну зміну базового API вводу / виводу файлів, що робить більшість існуючих кодів марними. Або це, або вам доведеться накидати пальці навколо них, зберігаючи застарілий API. Запам'ятайте PROGRA ~ 1.

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

Тепер я перейду на боки.

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

І все-таки всі операції прості, на відстані немає ніяких моторошних дій, нічого, що змусило б мене піти на wtf.

Насправді я один раз реалізував сховище документів з багатими метаданими та ієрархією на основі DAG. (Це навіть не була вільна форма DAG, це була строго дворівнева метаструктура та документи, які могли бути дітьми або рівня 1, або колекції 2 рівня. Отже, це дійсно просто.)

Очевидно, вимога про те, що назви документів мають бути унікальними в колекції, повинна залишатися.

І тоді проблеми почали текти. Що робити, якщо відкрити колекцію та змінити назву документа на те, що стикається з іншою колекцією, до якої також належить документ? Ми відобразили повідомлення про помилку, але користувачі були повністю озадачені. (Це ті самі користувачі, які просили цю вимогу.)

Вони намагалися видалити документ, але все, що було, було видалити з колекції. Тож воно все-таки виявилося в результатах пошуку. Ми також спробували це навпаки, але потім вони скаржилися, що вони видалили документ із колекції A, і він магічно зник із колекції B. Тож нам знадобилася як операція "від’єднання", так і жорстке видалення.

Врешті-решт ми поступилися поразкою, на щастя, ще вчасно.

Додаткові аспекти пошуку метаданих, можливо, працювали абсолютним лікуванням.

Якщо чесно, я ледве торкаюся метаданих своїх файлів на Mac. Я думаю, що за останні 5 років використання OSX (який підтримує коментарі тощо) я використовував метадані, можливо, на 2 файлах. Не кажучи, що це погана ідея.

Я просто не впевнений, наскільки накладні позначення тегів для мене прагматичні.

Я думаю, що найприємнішою функцією файлової системи, про яку я знаю, була б система версій на рівні файлової системи ..., яка працює на перехресних розділах. Це було зроблено на VAXen у 70-х та на початку 80-х, не впевнений, чому він не наздогнав Unix та NTFS / Windows.

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

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

Я не бачу, де (принаймні деякі) поточні файлові системи насправді потребують багато [редагувати: що завгодно] для підтримки тегів. Коли ви переходите до нього, підтримка тегів означає трохи більше, ніж деякі додаткові дані, пов’язані з файлом, але не записуються в потік байтів для цього файлу.

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