Jak osiodłano nas (hierarchiczny) system plików jako podstawowa struktura danych?

Jestem samoukiem i nie mam dyplomu CS. Im więcej nauczyłem się o strukturze danych, tym bardziej zastanawiam się, w dzisiejszych czasach, w jaki sposób jesteśmy nadal obciążeni systemem plików, katalogami i plikami, jako podstawową strukturą przechowywania danych w systemie operacyjnym?

Rozumiem jego prostotę, ale wydaje się, że obecnie może być dostępnych więcej opcji natywnie. O ile mi wiadomo, tylko projekt, aby poprawić podstawową funkcjonalność systemu plików ReiserFS, gdzie było można powiedzieć, co linia pliku została zmieniona przez kogo i kiedy.

Na przykład, gdybym mógł mieć natywne oznaczanie plików, w którym mógłbym oznaczać obrazy, diagramy, dokumenty do edycji tekstu, całe repozytorium kodu, wszystkie jako należące do jednego projektu, to byłoby naprawdę pomocne. Ponieważ utknąłem w paradygmacie systemu plików, wiem, że mógłbym umieścić je wszystkie w jednym folderze / katalogu, ale co, jeśli już istnieją w różnych katalogach i muszą tam pozostać? Wiem, że istnieją programy, które mogą to zrobić, ale dlaczego nie są w systemie plików?

Coś, co byłoby miło mieć, jest jakąś relacyjną funkcją w systemie plików, taką jak w przypadku RDBMS. Rozumiem, że to miało być częścią Vista / 7, ale to również nie mieści się na liście funkcji.

Jasne, każdy program może przechowywać plik binarny i mieć w nim dowolną strukturę danych, dlaczego system operacyjny nie mógł zaoferować bardziej złożonych sposobów przechowywania danych poza prostą dziedzicznością systemu plików?

Zacznij od tego: http://en.wikipedia.org/wiki/Unix_File_System

Przeczytaj to: http://www.unix.org/what_is_unix/history_timeline.html

Następnie przeczytaj to: http://www.amazon.com/UNIX-Filesystems-Evolution-Design-Implementation/dp/0471164836

Istnieje prosta odpowiedź na pytanie „dlaczego system operacyjny nie mógł zaoferować bardziej złożonych sposobów przechowywania danych poza prostą dziedzicznością systemu plików?”

Ponieważ to zbyt wiele do zrobienia dla systemu operacyjnego.

Do tego służą biblioteki i pakiety aplikacji.

Na przykład Oracle sprzedaje zestaw funkcji podobnych do systemu plików, którymi zarządzasz za pomocą zestawu narzędzi Oracle.

Python korzysta z biblioteki DBM do tworzenia bardzo wyrafinowanych struktur przechowywania na dysku.

CouchDB i Mongo (i inne) to bardzo wyrafinowane struktury pamięci, które oferują pewne funkcje podobne do baz danych.

Chodzi o to, że system operacyjny powinien zrobić minimum, a wszystko jest dodatkiem.

Krótka odpowiedź brzmi: ludzie codziennie rozumieją system plików. Przypomina im szafkę na akta. Pomyśl o stronach internetowych, a nawet aplikacjach Fat, dlaczego Twoim zdaniem Tabssą tak popularne? Ludzie mogą się z nimi identyfikować i szybko je rozumieć.

Obrazowanie próbuje nauczyć babcię przeszukiwania bazy danych w poszukiwaniu pliku na podstawie znaczników właściwości. Dzięki systemowi plików babcia wie, że plik jest tam, gdzie go umieścił .

Nawet z WinFS nie sądzę, żeby MS pozbyło się wyglądu systemu plików.

W każdej odpowiedzi jest trochę prawdy, ale nie sądzę, że to cała prawda.

To, co wymieniasz, to przede wszystkim funkcje, których tak bardzo brakuje każdego dnia zarówno użytkownikom, jak i programistom.

Ludzie nie rozumieją systemu plików opartego na drzewach tak samo, jak nie zrozumieliby systemu opartego na DAG.

I absolutnie nie ma usprawiedliwienia dla żałosnych dodatków nazw plików zwanych rozszerzeniami. Są one nie tylko całkowicie nieodpowiednie do ich celu (identyfikacja typu pliku), ale także niekończące się źródło uciążliwości dla użytkowników.

Powodem, dla którego nadal ich używamy, jest mieszanka nastawienia „zrób to” i realnej potrzeby zachowania zgodności ze starszym kodem. Nowe podejście do przechowywania plików oznaczałoby radykalną zmianę w podstawowym interfejsie API we / wy plików, co spowodowałoby, że większość istniejącego kodu nie byłaby użyteczna. Albo to, albo musisz przechodzić między nimi na palcach, zachowując starsze API. Pamiętaj PROGRA ~ 1.

Sądzę, że z powyższych powodów, chociaż przyszłość może zawierać bardziej wyspecjalizowane systemy plików do specjalnych zastosowań, ale mimo że obecne architektury komputerów stacjonarnych i laptopów przetrwały, utknęliśmy w systemie plików opartym w dużej mierze na drzewie z brakiem metadanych i jego okropne małe rozszerzenia.

Teraz zamierzam zmienić stronę.

Ponieważ jest wokół nas, nigdy tak naprawdę nie doceniamy, jak zadziwiająco potężna jest metafora drzewa. Na dysku twardym mam kilkaset tysięcy plików. Jeśli muszę go znaleźć, rzadko zajmuje to więcej niż minutę, nawet jeśli niewiele wiem o pliku. Teraz wyobraź sobie to samo zadanie bez jakiejkolwiek struktury, tylko płaska lista nazwisk, przewijająca się bez końca.

Jednak wszystkie operacje są proste, nie ma strasznej akcji na odległość, nic, co zmusiłoby mnie do wtf.

Właściwie raz wdrożyłem magazyn dokumentów z bogatymi metadanymi i hierarchią opartą na DAG. (Nie był to nawet DAG o swobodnej formie, był to ściśle dwupoziomowa metastruktura i dokumenty, którymi mogą być dzieci z kolekcji poziomu 1 lub poziomu 2. Więc to naprawdę proste.)

Oczywiście wymóg, aby nazwy dokumentów były unikalne w obrębie kolekcji, musiał zostać utrzymany.

A potem problemy zaczęły płynąć. Co się stanie, jeśli otworzysz kolekcję i zmienisz nazwę dokumentu na coś, co koliduje z inną kolekcją, do której należy również dokument? Pokazaliśmy komunikat o błędzie, ale użytkownicy byli całkowicie zaskoczeni. (Są to ci sami użytkownicy, którzy poprosili o ten wymóg).

Próbowali usunąć dokument, ale wszystko, co zrobili, to usunięcie go z kolekcji. Więc nadal pojawiał się w wynikach wyszukiwania. Próbowaliśmy tego też na odwrót, ale potem narzekali, że usunęli dokument z kolekcji A i magicznie zniknął z kolekcji B. Więc potrzebowaliśmy zarówno operacji „odłączenia”, jak i operacji twardego usunięcia.

W końcu przyznaliśmy się do porażki, na szczęście wciąż na czas.

Dodatkowe aspekty wyszukiwania, które umożliwiły metadane, działały jednak absolutnie nieźle.

Szczerze mówiąc, ledwo dotykam metadanych w moich plikach na komputerze Mac. Myślę, że w ciągu ostatnich 5 lat korzystania z OSX (który obsługuje komentarze i tak dalej), użyłem metadanych może w 2 plikach. Nie mówię, że to zły pomysł.

Po prostu nie jestem pewien, jak narzut związany z tagowaniem jest dla mnie pragmatyczny.

Myślę, że najprzyjemniejszą funkcją systemu plików, jaką znam, byłby system wersjonowania na poziomie systemu plików ... który działa między partycjami. Zostało to zrobione na VAXen w latach 70. i na początku 80., nie jestem pewien, dlaczego nie przyjęło się w systemach Unix i NTFS / Windows.

Pracowałem z niehierarchicznymi systemami plików na starszych minisach, takich jak HP3000 i Encore / Gould. Nie miałeś katalogów; masz grupę i konto, a pliki zostały nazwane jako „ grupa . konto . plik ”, na przykład „users.jbode.myfile1”, „dev.jbode.main” itp.

Teraz są to stare systemy, w których poszczególne miejsca na dysku były w pojedynczych megabajtach, więc nie jest tak, że potrzebowałeś zbyt wielu poziomów, aby uporządkować swoje rzeczy, ale z perspektywy użytkownika i programisty systemy hierarchiczne są znacznie ładniejsze.

Nie wiem, gdzie (przynajmniej niektóre) obecne systemy plików naprawdę muszą zrobić wiele [Edycja: cokolwiek, szczerze mówiąc], aby obsługiwać tagi. Gdy przejdziesz do tego, obsługa tagów oznacza niewiele więcej niż dodatkowe dane związane z plikiem, ale nie jest zapisywana w strumieniu bajtów dla tego pliku.

NTFS (aby wybrać przykład, który jest szeroko używany) może to zrobić dobrze: jeśli chodzi o NTFS, plik niekoniecznie jest pojedynczym strumieniem bajtów. W systemie plików NTFS można powiązać dowolną liczbę strumieni danych z jedną nazwą pliku. Każdy plik ma (prawdopodobnie pusty) „główny strumień”, który nie ma nazwy. Może jednak również mieć dowolną liczbę innych strumieni, z których każdy musi mieć nazwę. Korzystając z tego, naprawdę trywialne byłoby dodanie strumienia o nazwie (na przykład) „tagi” do istniejącego pliku i (oczywiście wystarczające) zapisanie tagów w tym strumieniu.

Potem przychodzi nieco trudniejsza część: zdobycie narzędzi do korzystania z tagów, które tam umieściłeś. Najlepiej byłoby, gdybyś chciał je zindeksować w celu szybkiego wyszukiwania, abyś mógł zrobić takie rzeczy, jak utworzenie „wirtualnego katalogu” wszystkich plików z określonym znacznikiem.

Przynajmniej z mojej perspektywy system plików ma już to, co jest potrzebne - powinien przechowywać i odzyskiwać dane, i może to zrobić doskonale teraz. Wykorzystywanie tych danych jest zadaniem innych narzędzi. Narzędzia te obecnie nie istnieją, ale infrastruktura systemu plików je obsługuje.

Jeśli pozwolę sobie przez chwilę być cynicznym, powiedziałbym, że było nieuniknione, że ta funkcja NTFS pozostanie prawie całkowicie zignorowana i nieznana. W końcu jest prosty w obsłudze i nie wymaga żadnego specjalnego API ani niczego innego. Możesz używać go całkiem nieźle w całkowicie przenośnym języku C, C ++ lub cokolwiek innego, co pozwoli ci określić dowolną nazwę pliku. Oto krótki kod demonstrujący tworzenie pliku z 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;
}

A oto kod do odczytu i wyświetlania tagów:

#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;
}

Wszystko bardzo proste i łatwe. Zauważ, że chociaż napisałem tam tylko trywialny kawałek danych, możesz traktować AFS tak jak każdy inny plik - wszystkie zwykłe „rzeczy” działają tak samo, jak z czymkolwiek innym. W normalnym widoku katalogu wszystko, co się pokaże, to strumień główny (np. Rozmiar pokazany dla pliku będzie miał rozmiar strumienia głównego), ale jeśli chcesz go zobaczyć, dir może również wyświetlać informacje o alternatywnych strumieniach z /Rflagą. Na przykład lista plików utworzonych powyżej wygląda następująco:

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