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

19

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?

user1936
źródło
2
Jego rdzeń powinien być prosty. Opcjonalny wzdęcie, o którym wspominasz, powinno być na szczycie prostego rdzenia. Alternatywnie poczekaj dwie dekady, a ktoś na nowo opracuje pojęcie systemu plików.
Praca
3
„co jeśli już istnieją w różnych katalogach i muszą tam pozostać?” Czasami możesz użyć twardych linków, aby rozwiązać ten problem ...
FrustratedWithFormsDesigner
1
Również kilka interesujących lektur na ten temat: c2.com/cgi/wiki?FileSystemAlternatives
FrustratedWithFormsDesigner
3
Nie jest to rozwiązanie w systemie Windows 7, ale nowe biblioteki mogą dać ci niektóre funkcje, które wydają się zainteresowane: lifehacker.com/#!5464350/…
DKnight
1
Jeśli chcę umieścić plik w dwóch różnych folderach jednocześnie, umieszczam skrót do tego pliku w jednym. Wadą jest to, że jeśli przeniesiesz ten folder / plik, skrót będzie nieprawidłowy.
Mateen Ulhaq

Odpowiedzi:

17

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.

S.Lott
źródło
4
Całkiem się zgadzam. W rzeczywistości wiele z tego, o co prosił OP, jest obecne w martwym lub umierającym projekcie WinFS: en.wikipedia.org/wiki/WinFS . O ile geek mówi: „Schludnie!” doświadczony użytkownik i inżynier oprogramowania we mnie mówi: „Próbuję zbyt mocno!”
Adam Crossland,
6
„Chodzi o to, że system operacyjny powinien zrobić minimum, a wszystko jest dodatkiem”. Całkiem odważne stwierdzenie w czasach, gdy niektóre systemy operacyjne zawierają wbudowany system okienkowy, usługę indeksowania plików, odtwarzacz multimediów, pulpit zdalny, zaporę ogniową lub Netris.
biziclop,
1
@biziclop: Uzgodniony. Windows odszedł od punktu widzenia Linuksa. Nic dziwnego.
S.Lott,
1
@ S.Lott Nie zrozum mnie źle, zgadzam się z twoim podejściem, ale Windows jest obarczony tyloma bezużytecznymi śmieciami, jedna dodatkowa funkcja nie zrobi różnicy. :)
biziclop,
4
To jest filozofia Uniksa. To niekoniecznie jest właściwe. Dzięki temu (i zgodny z C) Unix jest łatwy do przeniesienia na sprzęt. Ułatwia to także klonowanie uniksów do smaków -ix takich jak dzisiaj. Jeśli funkcja jest przydatna i wszystkie programy jej potrzebują, np. Pola wejściowe sprawdzane pod kątem pisowni, oznacza to, że środowisko wykonawcze ma tę wartość. Nie potrzebujemy 400 niezależnych wersji paska wstążki.
Tim Williscroft,
8

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.

Kretynowie
źródło
9
Muszę się z tym nie zgodzić. Większość ludzi, którzy nie są zmuszeni do nawigacji w systemie plików, nie robi tego. Otwierają edytor tekstu i klikają ostatni dokument lub szukają w menu Start systemu Windows 7 itp. I wiele osób nie wie, gdzie umieszcza swoje pliki. Babci byłoby znacznie łatwiej wyszukiwać „przepisy na ciasteczka”, „zdjęcia wnuka” lub cokolwiek innego niż utrzymywać hierarchię folderów.
Mateusz
16
Może to być dla ciebie szokiem: zwykli ludzie nie rozumieją systemu plików. Nie mają najmniejszych pomysłów. I nie chodzi mi o system FS w stylu uniksowym z jego punktami montowania, dowiązaniami symbolicznymi i dowiązaniami twardymi, ale o standardową strukturę katalogów z plikami.
biziclop,
2
@ Morons, moja babcia nigdy nie wie, gdzie ona kładzie rzeczy. Gmail już zmienił mój pożądany paradygmat na system tagowania, zwłaszcza z filtrami do automatycznego tagowania rzeczy. Myślę, że paradygmat systemu plików został zaimplementowany głównie ze względu na prostotę programowania struktur drzewiastych. Ułatwia także adresowanie z perspektywy programowania. Jak określiłbyś lokalizację dokumentu w systemie opartym na znacznikach? Nie oznacza to, że nie da się tego zrobić, ale szczegóły muszą zostać dopracowane.
zzzzBov 16.03.11
3
Czy kupujesz swoje szafki z aktami pełne tysięcy folderów i dokumentów niezbędnych do działania samej szafki, które musisz przeglądać w kółko, ale uważaj, aby ich nie dotykać? Czy Twoja szafka na akta wydaje się otwierać w innym miejscu za każdym razem, gdy wyjmiesz szufladę? Itd. Itp. Zgadzam się z Matthew i biziclop - ludzie „na co dzień” nie rozumieją .
Nicole,
2
Mam dyplom CS. Ale nie wiem, w których folderach system Windows umieszcza pliki. Zwłaszcza Desktop, StartMenu, QuickLaunch i wszystkie inne foldery domyślne określone przez użytkownika / system. (Ten system pomocy M $ nie pomaga mi w wyjaśnieniu, jak nacisnąć przycisk.) Muszę zainstalować CygWin, aby móc wyszukiwać własne pliki, ponieważ nowsze funkcje wyszukiwania M $ nie znajdują już prostych istniejących plików, takich jak na win2k. Wyłączanie błędnych funkcji, takich jak ukrywanie plików systemowych, ukrywanie rozszerzeń plików, nie rozwiązuje już większości problemów. Zrezygnowałem z systemu Windows, kiedy byłem zmuszony do pracy nad (zupełnie nowym) winXP.
comonad
6

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.

biziclop
źródło
Rememebr CP / M na dysku twardym 5 MB? Mija setki plików. STRASZNY!
szybko_now
@quickly_now Ah, stary dobry CP / M. :)
biziclop,
3

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.

Paul Nathan
źródło
Nowoczesne wersje NTFS / Windows robić oferta wersjonowanie. To nie jest dokładnie na twoją twarz, ale istnieje. Nie można jednak powiedzieć, jak to się ma do VMS.
Shog9
2

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.

John Bode
źródło
1

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
Jerry Coffin
źródło
1
DIR może być w stanie to pokazać, ale tworzenie kopii zapasowej pliku z alternatywnymi strumieniami jest strasznie trudne , szczególnie dla innego systemu. Na przykład większość dzisiejszych dysków NAS korzysta z Linuksa, a systemy plików tam nie obsługują alternatywnych strumieni. Skopiuj plik ... a wszystkie inne pliki znikną.
szybko_now
Tak, zauważyłem, że większość systemów NAS jest raczej ... zakwestionowana (i to nie jest jedyny sposób). W przypadku faktycznego tworzenia kopii zapasowych i przywracania rzeczy nie powoduje to jednak problemów (przynajmniej jeśli dane oprogramowanie jest w ogóle napisane kompetentnie): BackupReadserializuje wszystkie strumienie i BackupWriteodtwarza plik (z alternatywnymi strumieniami) z format serializowany.
Jerry Coffin,
Zależy, czy chcesz, aby kopie zapasowe plików były bezpośrednio odczytywane na serwerze NAS. Jeśli to zrobisz (i unikniesz potrzeby specjalnych programów do przywracania), utkniesz w zwykłych plikach.
Szybko_nie