Dlaczego system plików Linux jest zaprojektowany jako pojedyncze drzewo katalogów?

Czy ktoś może wyjaśnić, dlaczego Linux jest zaprojektowany jako jedno drzewo katalogów?

Podczas gdy w systemie Windows możemy mieć wiele dysków takich jak C:\i D:\, w systemie Unix jest jeden katalog główny. Czy jest jakiś konkretny powód?

Ponieważ system plików Unix wyprzedza Windows o wiele lat, można ponownie sformułować pytanie: „Dlaczego Windows używa osobnego oznaczenia dla każdego urządzenia?”.

Hierarchiczny system plików ma tę zaletę, że każdy plik lub katalog można znaleźć jako element podrzędny katalogu głównego. Jeśli musisz przenieść dane na nowe urządzenie lub urządzenie sieciowe, lokalizacja w systemie plików może pozostać taka sama, a aplikacja nie zobaczy różnicy.

Załóżmy, że masz system, w którym system operacyjny jest statyczny i istnieje aplikacja, która ma wysokie wymagania we / wy. Możesz zamontować / usr tylko do odczytu i umieścić / opt (jeśli aplikacja tam mieszka) na dyskach SSD. Hierarchia systemu plików nie zmienia się. W systemie Windows jest to o wiele trudniejsze, szczególnie w przypadku aplikacji, które domagają się życia pod C: \ Program Files \

Wynika to częściowo z powodów historycznych, a częściowo z tego powodu, że ma to większy sens.

Multics

Multics był pierwszym systemem operacyjnym, który wprowadził hierarchiczny system plików, jaki znamy dzisiaj, z katalogami, które mogą zawierać katalogi. Powołując się na „Ogólny cel systemu plików do dodatkowego przechowywania” RC Daley i PG Neumann:

Rozdział 2 artykułu przedstawia hierarchiczną strukturę plików, która pozwala na elastyczne korzystanie z systemu. Ta struktura zawiera wystarczające możliwości, aby zapewnić wszechstronność. (…)

Aby ułatwić zrozumienie, strukturę plików można traktować jako drzewo plików, z których niektóre są katalogami. Oznacza to, z jednym wyjątkiem, że każdy plik (np. Każdy katalog) znajduje się bezpośrednio wskazywany przez dokładnie jedną gałąź w dokładnie jednym katalogu. Wyjątkiem jest katalog główny lub katalog główny w katalogu głównym drzewa. Chociaż nie jest to wyraźnie wskazane w żadnym katalogu, katalog główny jest domyślnie wskazywany przez fikcyjną gałąź znaną systemowi plików. (…)

W dowolnym momencie uważa się, że użytkownik działa w jednym katalogu, zwanym jego katalogiem roboczym. Może uzyskać dostęp do pliku wskazanego przez pozycję w swoim katalogu roboczym, po prostu podając nazwę pozycji. Więcej niż jeden użytkownik może mieć jednocześnie ten sam katalog roboczy.

Podobnie jak w wielu innych aspektach, Multics szukało elastyczności. Użytkownicy mogą pracować w poddrzewie systemu plików i zignorować resztę, nadal korzystając z katalogów, aby uporządkować swoje pliki. Katalogi były również używane do kontroli dostępu - atrybut READ pozwalał użytkownikom na listę plików w katalogu, a atrybut EXECUTE pozwalał użytkownikom na dostęp do plików w tym katalogu (podobnie jak wiele innych funkcji, żył w Uniksie).

Multics przestrzegał także zasady posiadania pojedynczej puli pamięci. Artykuł nie porusza tego aspektu. Pojedyncza pula pamięci pasowała do ówczesnego sprzętu: nie było żadnych wymiennych urządzeń pamięci, a przynajmniej takich, na których użytkownicy by się przejmowali. Multics miał oddzielną pulę pamięci kopii zapasowych, ale była ona przezroczysta dla użytkowników.

Unix

Unix czerpał wiele inspiracji z Multics, ale dążył do uproszczenia, podczas gdy Multics do elastyczności.

Pojedynczy hierarchiczny system plików dobrze pasował do systemu Unix. Podobnie jak w przypadku Multics, pule pamięci zwykle nie były istotne dla użytkowników. Były jednak urządzenia wymienne i Unix udostępnił je użytkownikom za pomocą poleceń mounti umount(zarezerwowanych dla „superużytkownika”, tj. Administratora). W „Systemie podziału czasu UNIX” Dennis Ritchie i Ken Thompson wyjaśniają:

Chociaż katalog główny systemu plików jest zawsze przechowywany na tym samym urządzeniu, nie jest konieczne, aby cała hierarchia systemu plików znajdowała się na tym urządzeniu. Istnieje żądanie podłączenia systemu z dwoma argumentami: nazwa istniejącego zwykłego pliku i nazwa specjalnego pliku, którego powiązany wolumin pamięci (np. Pakiet dyskowy) powinien mieć strukturę niezależnego systemu plików zawierającego własną hierarchię katalogów . Efektem montowania jest spowodowanie, że odniesienia do dotychczasowego zwykłego pliku będą się odnosić do katalogu głównego systemu plików na wymiennym woluminie. W efekcie mount zamienia liść drzewa hierarchii (zwykły plik) na zupełnie nowe poddrzewo (hierarchia przechowywana na wymiennym woluminie). Po zamontowaniu praktycznie nie ma rozróżnienia między plikami na wymiennym woluminie a plikami w stałym systemie plików. Na przykład w naszej instalacji katalog główny znajduje się na małej partycji jednego z naszych dysków, podczas gdy drugi dysk, który zawiera pliki użytkownika, jest montowany według sekwencji inicjalizacji systemu. System plików montowany jest generowany przez zapis na odpowiednim pliku specjalnym. Dostępny jest program narzędziowy do tworzenia pustego systemu plików lub można po prostu skopiować istniejący system plików.

Hierarchiczny system plików ma również tę zaletę, że koncentruje złożoność zarządzania wieloma urządzeniami pamięci masowej w jądrze. Oznaczało to, że jądro było bardziej złożone, ale dzięki temu wszystkie aplikacje były prostsze. Ponieważ jądro musi dbać o urządzenia sprzętowe, ale większość aplikacji nie, jest to bardziej naturalny projekt.

Windows

Windows śledzi swoje pochodzenie z powrotem do dwóch linii: VMS , system operacyjny pierwotnie zaprojektowany dla minikomputera VAX oraz CP / M , system operacyjny zaprojektowany dla wczesnych mikrokomputerów Intel.

VMS miał rozproszony hierarchiczny system plików, Files-11 . W Files-11 pełna ścieżka do pliku zawiera nazwę węzła, oznaczenie konta w tym węźle, nazwę urządzenia, ścieżkę do drzewa katalogów, nazwę pliku, typ pliku i numer wersji. VMS miał potężną funkcję logicznej nazwy umożliwiającą definiowanie skrótów do określonych katalogów, więc użytkownicy rzadko musieliby dbać o „rzeczywistą” lokalizację katalogu.

CP / M został zaprojektowany dla komputerów z 64kB pamięci RAM i dyskietką, więc poszedł za prostotę. Nie było katalogów, ale odwołanie do pliku może zawierać wskazanie dysku ( A:lub B:).

Kiedy MS-DOS 2.0 wprowadził katalogi, zrobił to ze składnią kompatybilną z MS-DOS 1, który sam był zgodny z CP / M. Tak więc ścieżki zostały zrootowane na dysku o nazwie jednoliterowej. (Również znak ukośnika /został użyty w VMS i CP / M do uruchomienia opcji wiersza poleceń, więc inny znak musiał zostać użyty jako separator katalogu. Dlatego DOS i później Windows używają ukośnika odwrotnego, chociaż niektóre komponenty wewnętrzne również obsługują ukośnik ).

Windows zachował zgodność z DOS i podejściem VMS, więc zachowywał pojęcie liter dysku, nawet gdy stały się mniej istotne. Dzisiaj pod maską Windows używa ścieżek UNC ( pierwotnie opracowanych przez Microsoft i IBM dla OS / 2 , pokrewnych przodków). Chociaż jest to zarezerwowane dla zaawansowanych użytkowników (prawdopodobnie ze względu na wagę historii), system Windows pozwala na montowanie przez punkty ponownej analizy .

Nie ma obaw dotyczących bezpieczeństwa związanych z posiadaniem jednego drzewa katalogów.

Faceci, którzy zaprojektowali Unix, mieli spore doświadczenie z systemami operacyjnymi, które wymagały od użytkowników, aby wiedzieć, jakie urządzenie fizyczne zawiera dane zasoby. Ponieważ celem systemu operacyjnego jest stworzenie abstrakcyjnej maszyny na prawdziwym sprzęcie, pomyśleli, że o wiele łatwiej jest zrezygnować z adresowania zasobów według ich fizycznej lokalizacji i postanowili umieścić wszystko w jednym drzewie nazw.

To tylko jedna część geniuszu stojącego za projektem Uniksa .

Zauważ, że nazwy liter dysków z MS-DOS, które zachowują się we współczesnym systemie Windows, są tutaj czerwonym śledziem. Nazwy liter dysków nie są najlepszą reprezentacją struktury systemu plików, która ma wiele katalogów głównych. Są słomkowym wdrożeniem takiego systemu.

Prawidłowo zaimplementowany system plików, który obsługuje wiele katalogów głównych, umożliwia dowolne nazewnictwo woluminów, takich jak dvdrom:/path/to/file.avi. Takie jak system pozbyłby się śmiesznych problemów z interfejsem użytkownika, które nękają system Windows. Na przykład, jeśli podłączysz urządzenie takie jak kamera, interfejs użytkownika Eksploratora Windows sprawi, że uwierzysz, że istnieje urządzenie o nazwie Kamera (lub cokolwiek innego) i że masz ścieżkę podobną do tej Computer\Camera\DCIM\.... Jeśli jednak wytniesz i wkleisz tekstową wersję tej ścieżki w Eksploratorze, to tak naprawdę nie działa, ponieważ niektóre składniki nazwy ścieżki to fikcja interfejsu użytkownika, nieznana systemowi operacyjnemu. W prawidłowo wdrożonym systemie z wieloma źródłami byłoby dobrze: byłobycamera:\DCIM\...ścieżka rozpoznawana jednolicie na każdym poziomie w systemie. Co więcej, jeśli przeniesiesz stary dysk twardy ze starego komputera, nie utkniesz z jakąś nazwą litery dysku F:, ale raczej będziesz mógł nazwać go tak, jak chcesz old-disk:.

Tak więc, jeśli Unix miałby wiele katalogów głównych w strukturze systemu plików, byłoby to robione w taki sposób, a nie w MS-DOS i Windows z jednuliterowymi nazwami dysków. Innymi słowy, porównajmy tylko schemat Unixa z dobrym projektem z wieloma rootami.

Dlaczego więc Unix nie ma rozsądnej implementacji z wieloma rootami, na korzyść rozsądnej implementacji z jednym rootem? To chyba tylko dla uproszczenia. Punkty montowania zapewniają wszystkie funkcje dostępu do woluminów poprzez nazwy. Nie ma potrzeby rozszerzania przestrzeni nazw o dodatkową składnię prefiksu.

Z matematycznego punktu widzenia każdy rozłączny wykres drzewa („las”) może zostać dołączony przez dodanie węzła głównego i uczynienie z niego elementów rozłącznych.

Co więcej, jest bardziej elastyczny, że woluminy nie muszą znajdować się na poziomie głównym. Ponieważ nie ma specjalnej składni oznaczającej głośność (jest to tylko ścieżka), punkty montowania mogą znajdować się w dowolnym miejscu. Jeśli wprowadzą w trzech starych dysków na komputerze, można mieć je jako /old-disk/one, /old-disk/twoitd Można organizować dyski jednak chcesz, sposób organizowania plików i katalogów.

Można pisać aplikacje, które zależą od ścieżek, a ważność ścieżek można zachować podczas ponownej konfiguracji urządzeń pamięci masowej. Na przykład aplikacje mogą korzystać ze znanych ścieżek, takich jak /var/logi /var/lib. Od Ciebie zależy, czy /var/logi /var/libna tym samym woluminie dyskowym, czy na oddzielnym. Możesz migrować system do nowej topologii pamięci, zachowując ścieżki.

Punkty montowania są dobrym pomysłem, dlatego system Windows ma je od około 2000 roku.

Punkty montowania woluminów są odporne na zmiany systemowe, które występują, gdy urządzenia są dodawane lub usuwane z komputera. Microsoft Technet

Zarówno * nix, jak i Windows montują dyski. W systemie Windows są one automatycznie montowane w punktach montowania, które domyślnie mają rosnącą kolejność alfabetyczną. Te wartości domyślne to:

• A:i B:=> dyskietki
• C: => pierwsza partycja pierwszego dysku twardego
• D: => następna partycja lub następny dysk twardy lub napęd CD / DVD, jeśli nie ma innych partycji.

Każdy z tych punktów montowania jest katalogiem.

W * nix o punktach montowania decyduje użytkownik. Na przykład mam jedną partycję zamontowaną jako /, a drugą jako /home. Tak, /hometo osobny napęd, byłoby odpowiednikiem powiedzenia E:na Windows.

W obu przypadkach, Windows i * nix, punkty montowania są osobnymi katalogami. Jedyna różnica polega na tym, że w * nix te osobne katalogi są podkatalogami /, C:podczas gdy w Windows każdy punkt montowania jest montowany bezpośrednio pod /, My Computerpowiedzmy , pod .

Z punktu widzenia użytkownika główną zaletą jest to, że mocowania są całkowicie przezroczyste. Nie muszę wiedzieć, że katalog /homeznajduje się na osobnej partycji. Mogę po prostu użyć go jako normalnego katalogu. Zamiast tego, w DOS, musiałbym jawnie nazwać to nazwą punktu montowania, powiedzmyE:\home

Napędy zewnętrzne są montowane w prawie taki sam sposób w obu systemach. Powiedz D:dla Windows i /mnt/cdromLinux. Każdy z nich jest katalogiem, naprawdę nie widzę różnicy. Po włożeniu dysku CD-ROM do napędu w systemie Windows dysk jest montowany D:tak jak w systemie Linux.

Zgadzam się z powyższymi odpowiedziami, zwłaszcza odpowiedzią Douga O'Neala, ale myślę, że wszyscy coś pomijają, podobnie jak wyraźne punkty montowania urządzeń, takie jak MS-DOS „C:” lub „A:”.

Rob Pike napisał The Hideous Name o składni nazw, ale Russ Cox sprowadził to :

Przestrzenie nazw ... są najpotężniejsze, gdy można dodać nową semantykę bez dodawania nowej składni.

Jedna przestrzeń nazw, w której urządzenia mogą być dowolnie montowane, pozwala na naprawdę elastyczne operacje. Regularnie używam /mnt/sdb1i /mnt/cdromtymczasowo umieszczam nieużywany dysk lub dysk CD w całym systemie plików. Często zdarza się, że katalogi domowe znajdują się na serwerze NFS, więc bez względu na to, na jakiej maszynie się logujesz, $HOMEwszędzie to samo .

Sprowadza się to do tego: posiadanie specjalnej składni dla specjalnych rzeczy nakłada określone ograniczenia na to, co możesz zrobić. Jeśli możesz zamontować tylko nieużywany dysk, dysk CD lub DVD lub sieciowy system plików / „share” na „E:” lub „W:” lub czymkolwiek, masz znacznie mniejszą elastyczność.

To niemądre. System Windows ma również jeden punkt hierarchii. Ale jest ukryty i niestandardowy. Jak większość rzeczy Windows.

W tym przypadku jest to koncepcja „Mój komputer”. Jest to odpowiednik root (/) w Uniksie. Pamiętaj, że root to koncepcja, która istnieje w jądrze. lubisz to czy nie. Podobnie jak Windows traktuje „Mój komputer”. oczywiście możesz zamontować partycję na rootie w Uniksie i tak właśnie robi większość ludzi. I wiele rzeczy będzie patrzeć na określoną ścieżkę dla rzeczy (np. / Etc /), ale nie jesteś przez to ograniczony. Jak najbardziej, zamontuj dyski w / C: /. nie jest to zabronione w Unixie.

C: \ nie jest katalogiem głównym w systemie Windows, jest punktem podłączenia jednej partycji. Które MUSZĄ znajdować się na najwyższym poziomie „Mój komputer”. Będąc w Uniksie, możesz zamontować partycję pod dowolnym innym drzewem. Tak więc linux może mieć C: zamontowany, /podczas gdy D: zamontowany /mnt/d/... lub nawet zainstalowany, /ale jest to trudne i zależy od tego, jak zachowują się dwa systemy plików podczas montowania na już zamontowanej ścieżce.

Możesz uzyskać dokładnie to samo, co masz w przypadku systemu Windows, „zmuszając” się do przestrzegania tych samych ograniczeń, które narzucają ci okna.

/ (treat this as "My Computer")
/c/ (mount your first data partition here)
/d/ (mount your second data partition here)

Następnie musisz przekazać opcje montowania w opcjach rozruchu. ponieważ nie będziesz mieć / etc / ... ale to także symuluje ograniczenia, jakie narzuca Windows, ponieważ to robi.

Powód, dla którego Windows ma litery dysku, prawdopodobnie sięga jeszcze dalej niż Microsoft i DOS. Przypisywanie liter do dysków wymiennych było powszechne w systemach IBM, więc Microsoft mógł po prostu działać zgodnie z instrukcjami IBM, kopiując CP / M. I początkowo DOS i tak nie miał katalogów.

Gdy MS-DOS działał na komputerach z jednym lub dwoma dyskami wymiennymi i bez stałych nośników, tak naprawdę nie potrzebowałeś systemu plików z katalogami. Na jednym, a może na dwóch 180-kilobajtowych dyskach nigdy nie było wystarczająco dużo plików, aby mieć problemy z ich organizacją.

https://en.wikipedia.org/wiki/Drive_letter_assignment

W rzeczywistości Linux oparty jest na Uniksie (lub jest Uniksem, patrz dyskusja ), a Unix pochodzi ze środowiska mainframe, gdzie używanie wielu urządzeń było dość oczywiste. Montowanie urządzeń w obrębie jednego drzewa katalogów zapewnia maksymalną elastyczność i nie ogranicza liczby urządzeń, do których system operacyjny może uzyskać dostęp.

Z drugiej strony litery DOS dla napędów to dobry projekt na komputer z 1 lub 2 stacjami dyskietek i pojedynczym dyskiem. Duża dyskietka 5,25 'to zawsze A :, mała 3,5' to zawsze B :, a napęd dyskowy to zawsze C :. Zawsze wiesz, czy skopiujesz plik na dyskietkę lub gdzieś na dysk. Nie potrzebujesz żadnej elastyczności, jeśli nie możesz fizycznie podłączyć więcej niż 2 stacji dyskietek i 2 (lub 4) dysków twardych.

Projekt DOS był bardziej przyjazny dla użytkownika końcowego, podczas gdy projekt Uniksa jest przyjazny dla administratora. Teraz litery dysków są obciążeniem dla systemu Windows, użytkownicy bardziej polegają na automatycznym otwieraniu okna eksploratora z wymienną zawartością dysku niż znajomością jego litery ... Ubuntu robi to samo.

Właściwie to nie prawda. Windows używa innego schematu ścieżek (cóż, nie tego samego)

„Litery jednostek” to tylko coś, co łatwo zapamiętać, ścieżki, dyski i partycje.

Ścieżki ARC definiują ścieżkę do pliku w systemie Windows (ale są widoczne dla użytkownika tylko podczas rozruchu):

http://support.microsoft.com/kb/102873

https://serverfault.com/questions/5910/how-do-i-determine-the-arc-path-for-a-particular-drive-letter-in-windows

W systemie Windows NT nie ma związku między dyskami, partycjami i literami jednostek: Możesz „umieścić” cały wolumin w folderze (np .: c: \ myseconddisk może być całym dyskiem fizycznym!)

Dwie rzeczy, na które chciałbym zwrócić uwagę -

1. Dyski twarde w systemie Linux są tak naprawdę przypisane do liter / nazw, takich jak / dev / sdb1. Można je jednak zamontować w dowolnym miejscu, do którego można uzyskać dostęp ze struktury single / root
2. Najczęstszym powodem, dla którego ludzie (w tym ja w przeszłości) mieli osobne dyski w systemie Windows, było posiadanie miejsca do przechowywania dokumentów, muzyki, programów itp., Aby gdy Windows nieuchronnie wymagał ponownej instalacji lub wymiany, czy to uaktualnienia, czy wirusa awaria systemu plików, nadal był dostęp do tych plików. Nie mam tego problemu w systemie Linux - system plików jest znacznie bardziej niezawodny, system operacyjny nie pęka, chyba że przez jakieś bezpośrednie działanie lub pomyłkę z mojej strony (och, przełomowe repozytorium, spróbujmy!), I aktualizacje są o DUŻO prostsze. I w rzadkim przypadku musiałem zainstalować ponownie, ponieważ całe oprogramowanie było dostępne za pośrednictwem repozytoriów lub ppa, które dodałem (i mogłem z łatwością skopiować mój katalog domowy z dysku na żywo),

Jeśli spojrzysz w przeszłość, zobaczysz również, że Unix zaczął się w czasie 8 ścieżkowych systemów taśm dla audio i 9 ścieżkowych systemów danych IBM (8 ścieżek / 8 bitów dla danych, jeden dla parzystości). Technicznie bardzo podobnie.

W tym czasie informacje o lokalizacji plików były przechowywane w częściach informacji na taśmie oraz w przód i wstecz zdefiniowane podczas odczytywania danych z taśmy (jak plik, z pozycją początkową i sygnaturą końcową); wyjaśnia również, dlaczego nie miałeś tylko jednego FAT na początku dysku - miałeś wiele, aby przyspieszyć wyszukiwanie. A jeśli miałeś wiele napędów, były one połączone w / dev i poprzez adres pliku przeniesionego między urządzeniami.

Wierzę, że możesz mieć pogląd, że zaczął się po prostu wcześniej i że decyzja za obszarem MS Dos (CP / M) i późniejszym Windows NT jest po prostu związana z literami dysków mainframe VM zamiast z pojedynczym punktem wejścia, ponieważ w tym czasie wyglądała bardziej współczesne, dzisiejsze ilości danych nie istniały i nie sądzili, że ostatecznie nie będziesz mieć wystarczającej liczby liter dysku lub że będzie zbyt zagracony.

Przyporządkowanie napędu 9-ścieżkowego i litery napędu