Dlaczego musimy montować na Linuksie?

Rozumiem, co jest montowane w Linuksie i rozumiem pliki urządzeń. Jednak nie rozumiem DLACZEGO musimy montować.

Na przykład, jak wyjaśniono w zaakceptowanej odpowiedzi na to pytanie , za pomocą tego polecenia:

mount /dev/cdrom /media/cdrom

montujemy urządzenie CDROM /media/cdromi ostatecznie możemy uzyskać dostęp do plików CDROM za pomocą następującego polecenia

ls /media/cdrom

która wyświetli zawartość CDROM-u.

Dlaczego nie pominąć całkowicie montażu i wykonać następujące czynności?

ls /dev/cdrom

I umieść na liście zawartość CDROM. Spodziewam się, że jedną z odpowiedzi będzie: „ Tak właśnie zaprojektowano Linuksa ”. Ale jeśli tak, to dlaczego zostało tak zaprojektowane? Dlaczego nie uzyskać /dev/cdrombezpośredniego dostępu do katalogu? Jaki jest prawdziwy cel montażu?

Jednym z powodów jest to, że dostęp na poziomie bloku jest nieco niższy niż lsbyłby w stanie pracować. /dev/cdrom, lub dev/sda1może być odpowiednio napędem CD ROM i partycją 1 dysku twardego, ale nie implementują one ISO 9660 / ext4 - to tylko wskaźniki RAW dla urządzeń zwanych plikami urządzeń .

Jedną z rzeczy, które określa mount, jest JAK używać tego surowego dostępu - jakie moduły logiki / sterownika / jądra systemu plików będą zarządzać odczytami / zapisami lub tłumaczyć, ls /mnt/cdromw których blokach należy czytać, i jak interpretować ich zawartość blokuje na rzeczy takie jak file.txt.

Innym razem ten dostęp na niskim poziomie może być wystarczająco dobry; Właśnie czytałem i zapisałem na porty szeregowe, urządzenia USB, terminale tty i inne stosunkowo proste urządzenia. Nigdy nie próbowałbym ręcznie czytać / pisać z / dev / sda1, powiedzmy, edytować pliku tekstowego, ponieważ w zasadzie musiałbym ponownie zaimplementować logikę ext4, która może obejmować między innymi: wyszukiwanie i-węzłów pliku, znajdowanie bloki pamięci, przeczytaj cały blok, dokonaj moich zmian, napisz pełne bloki, a następnie zaktualizuj i-węzeł (być może) lub zamiast tego napisz to wszystko do dziennika - o wiele za trudne.

Jednym ze sposobów, aby to sprawdzić, jest wypróbowanie:

[root@ArchHP dev]# cd /dev/sda1
bash: cd: /dev/sda1: Not a directory

/devto katalog, w którym możesz cdi lswszystko, co lubisz. /dev/sda1nie jest katalogiem; jest to specjalny typ pliku, który jądro oferuje jako „uchwyt” dla tego urządzenia.

Zobacz wpis wikipedii na urządzeniu plików, aby uzyskać bardziej szczegółowe leczenie.

Zasadniczo i, mówiąc prosto, system operacyjny musi wiedzieć, jak uzyskać dostęp do plików na tym urządzeniu.

mount nie tylko „daje ci dostęp do plików”, ale informuje system operacyjny o tym, jaki system plików ma napęd, jeśli jest to tylko odczyt lub dostęp do odczytu / zapisu itp.

/dev/cdromjest urządzeniem niskiego poziomu, funkcje systemu operacyjnego nie wiedziałyby, jak uzyskać do nich dostęp ... wyobraź sobie, że umieściłeś w nim dziwnie sformatowany cdrom (nawet audio CD), jak lspowiedzieć, które pliki (jeśli w ogóle) są na cd-rom bez „montowania” go najpierw?

Zauważ, że dzieje się to automatycznie w wielu systemach operacyjnych (nawet Linux w niektórych dystrybucjach i interfejsach graficznych), ale to nie znaczy, że inne systemy nie „montują” napędów.

Dla spójności

Wyobraź sobie, że masz partycje na pierwszym dysku twardym w systemie. Na przykład /dev/sda2. Później decydujesz, że dysk nie jest wystarczająco duży, więc kupujesz drugi i dodajesz go do systemu. Nagle tak się dzieje /dev/sdai staje się obecny napęd /dev/sdb. Twoja partycja jest teraz /dev/sdb2.

Korzystając z proponowanego systemu, musisz zmienić wszystkie skrypty, aplikacje, ustawienia itp., Które uzyskują dostęp do danych na starej partycji, aby odzwierciedlić tę zmianę nazw.

Jednak montaż pozwala nadal używać tego samego punktu montowania dla tego przemienionego napędu. Trzeba by edytować, /etc/fstababy powiedzieć systemowi, że (na przykład) /media/backupjest teraz /dev/sdb2zamiast tego, ale to tylko jedna zmiana.

Pamiętaj, że współczesne systemy są jeszcze łatwiejsze. Zamiast odwoływać się do urządzenia jako /dev/sda2lub /dev/sdb2mają UUIDS, które wyglądają podobnie c5845b43-fe98-499a-bf31-4eccae14261blub mogą otrzymać bardziej przyjazne etykiety, na przykład takie, backupktóre mogą być użyte do odniesienia urządzenia podczas montażu. W ten sposób nazwa urządzenia nie zmienia się podczas dodawania nowego urządzenia, co sprawia, że ​​administracja jest jeszcze prostsza:

# mount LABEL="backup" /media/backup

Dla bezpieczeństwa

Wymagając zamontowania urządzenia, administrator może kontrolować dostęp do urządzenia. Urządzenie można usunąć po odmontowaniu, ale nie w trakcie użytkowania (chyba że chcesz utracić dane). Jeśli jesteś (byłeś) użytkownikiem systemu Windows, pamiętasz małą zieloną ikonę w obszarze powiadomień, która informuje, że możesz bezpiecznie usunąć pamięć USB? To znaczy montowanie i odmontowywanie pendrive'a za ciebie. Więc zasada nie jest tylko Uniksem / Linuksem.

Nazwałbym to historycznymi powodami. Nie chodzi o to, że inne odpowiedzi są błędne, ale w tej historii jest coś więcej.

Porównaj system Windows: system Windows został uruchomiony jako system operacyjny dla jednego komputera i dla jednego użytkownika. Ten pojedynczy komputer prawdopodobnie miał jeden napęd dyskietek i jeden dysk twardy, bez połączenia sieciowego, bez USB, bez niczego. (Windows 3.11 miał natywne możliwości sieciowe; Windows 3.1 nie .)

Sposób, w jaki narodził się Windows, był tak prosty, że nie trzeba było być fantazyjnym: po prostu zamontuj wszystko (wszystkie dwa urządzenia) automatycznie za każdym razem, nie ma (nie było) wielu rzeczy, które mogłyby pójść nie tak.

Natomiast Unix został stworzony do pracy w sieciach serwerów z wieloma użytkownikami od samego początku.

Jedną z decyzji projektowych w systemie Unix było to, że system plików powinien wyglądać jako jednolity, jednolity byt dla użytkowników końcowych, bez względu na to, na ilu komputerach dyski fizyczne zostały rozmieszczone, bez względu na rodzaj dysku i bez względu na to, który z dziesiątek komputerów użytkownik miałby do niego dostęp. Logiczna ścieżka do plików użytkownika pozostałaby taka sama, nawet gdyby fizyczna lokalizacja tych plików zmieniła się z dnia na dzień, np. Z powodu konserwacji serwera.

Wydzielali logiczny system plików, ścieżki do plików, z fizycznych urządzeń, na których te pliki były przechowywane. Powiedzmy, że serwer A zwykle hostuje / home, ale serwer A wymaga konserwacji: wystarczy odmontować serwer A i zamontować serwer zapasowy B na / home, a nikt oprócz administratorów nawet by tego nie zauważył.
(W przeciwieństwie do konwencji systemu Windows nadawania różnych nazw różnym urządzeniom fizycznym - C :, D: itd. - co działa wbrew przejrzystości, o którą dążył Unix).

W takim otoczeniu nie można po prostu zamontować wszystkiego w zasięgu wzroku, nie chcąc,

W dużej sieci pojedyncze dyski i komputery są ciągle bez prowizji. Administratorzy potrzebują możliwości określenia, co jest zamontowane, gdzie i kiedy, np. W celu kontrolowanego wyłączenia jednego komputera, podczas gdy inny komputer przejmie hostowanie tych samych plików.

Dlatego z historycznego punktu widzenia: Windows i Unix pochodzą z różnych środowisk. Możesz to nazwać różnicą kulturową, jeśli chcesz:

• Unix narodził się w środowisku, w którym administrator musiał kontrolować montowanie; z kilkudziesięciu urządzeń pamięci masowej w sieci administrator musi zdecydować, co zostanie zamontowane, gdzie i kiedy.
• Windows narodził się w środowisku, w którym nie było administratora i tylko dwa urządzenia pamięci masowej, a użytkownik prawdopodobnie wiedziałby, czy ich plik znajduje się na dyskietce, czy na dysku twardym.
• (Linux narodził się oczywiście jako system operacyjny na jednym komputerze, ale od samego początku został wyraźnie zaprojektowany tak, aby jak najbardziej naśladować Uniksa na komputerze domowym).

Ostatnio systemy operacyjne zbliżają się do siebie:

• Linux dodał więcej rzeczy dla jednego komputera i dla jednego użytkownika (np. Automounting); ponieważ często był używany w ustawieniach jednego komputera.
• Windows dodał więcej bezpieczeństwa, sieci, wsparcia dla wielu użytkowników itp .; sieci stały się coraz bardziej wszechobecne, a Microsoft zaczął tworzyć system operacyjny również dla serwerów.

Ale nadal łatwo powiedzieć, że oba są wynikiem różnych tradycji.

Obecne rozwiązanie ma kilka zalet. Można je pogrupować w zalety blokowych plików specjalnych i zalety punktów montowania.

Pliki specjalne to pliki reprezentujące urządzenia. Jednym z pomysłów, na których zbudowano uniks, jest to, że wszystko jest plikiem. Ułatwia to wiele rzeczy, na przykład interakcja użytkownika to po prostu odczyt i zapis pliku na urządzeniu tty, który jest plikiem specjalnym. podobnie sprawdzanie uszkodzonych bloków, partycjonowanie lub formatowanie dysku to tylko operacje na plikach. Nie ma znaczenia, czy dysk to mfm, ide, scsi, fiberchanel, czy coś innego to tylko plik.

Ale z drugiej strony możesz nie chcieć zajmować się całym dyskiem lub partycją tylko plikami, aw wielu przypadkach więcej plików zmieści się na dysku. Mamy więc punkty montowania. Punkt montowania pozwala na umieszczenie całego dysku (lub partycji) w katalogu. W moich czasach Slackware, gdy dysk twardy dobrej wielkości miał kilkaset MB, często używano CD jako / usr i dysku twardego dla /, / usr / local i swap. Lub możesz umieścić / na jednym dysku i / home na innym.

Teraz zauważyłem, że wspominałeś o montowaniu CD na / media / cdrom, co jest przydatne na komputerach z tylko jednym napędem cdrom, ale co jeśli masz więcej niż jeden? gdzie powinieneś zamontować drugi? czy trzeci? czy piętnasty? z pewnością możesz użyć / media / cdrom2 itp. Lub możesz zamontować go na / src / samba / resources / windows-install lub / var / www, lub gdziekolwiek ma to sens.

Tytuł pytania brzmi: Dlaczego musimy montować w systemie Linux?

Jeden ze sposobów interpretacji tego pytania: Dlaczego musimy wydawać jawne mountpolecenia, aby systemy plików były dostępne w systemie Linux?

Odpowiedź: my nie.

Nie musisz jawnie montować systemów plików, możesz ustawić, aby odbywało się to automatycznie, a dystrybucje Linuksa już to robią dla większości urządzeń, tak jak robią to Windows i Mac.

Więc prawdopodobnie nie o to chciałeś zapytać.

Druga interpretacja: dlaczego czasami musimy wydawać jawne mountpolecenia, aby udostępnić systemy plików w systemie Linux? Dlaczego nie sprawić, że system operacyjny zawsze zrobi to za nas i ukryje przed użytkownikiem?

Oto pytanie, które czytam w tekście pytania, kiedy zadajesz:

Dlaczego nie pominąć całkowicie montażu i wykonać następujące czynności

ls /dev/cdrom

i czy na liście znajduje się zawartość płyty CD-ROM?

Prawdopodobnie masz na myśli: dlaczego po prostu nie masz tego polecenia

ls /media/cdrom

robi teraz?

W takim przypadku /dev/cdrombyłoby to drzewo katalogów, a nie plik urządzenia. Tak więc wydaje się, że Twoim prawdziwym pytaniem jest: po co plik urządzenia?

Chciałbym dodać odpowiedź do tych, które już zostały podane.

Dlaczego użytkownicy widzą pliki urządzeń?

Ilekroć korzystasz z dysku CD-ROM lub innego urządzenia do przechowywania plików, używane jest oprogramowanie, które interpretuje wszystko, co znajduje się na dysku CD-ROM, jako drzewo katalogów plików. Jest on wywoływany za każdym razem, gdy używasz lsinnego polecenia lub aplikacji, która uzyskuje dostęp do plików na dysku CD-ROM. To oprogramowanie jest sterownikiem systemu plików dla konkretnego systemu plików używanego do zapisywania plików na dysku CD-ROM. Ilekroć wyświetlasz, odczytujesz lub zapisujesz pliki w systemie plików, zadaniem tego oprogramowania jest upewnienie się, że odpowiednie operacje odczytu i zapisu na niskim poziomie są wykonywane na danym urządzeniu. Kiedykolwiek jesteś mountsystemem plików, mówisz systemowi, którego sterownika systemu plików użyć dla tego urządzenia. Czy robisz to jawnie za pomocąmountpolecenie lub pozostaw to systemowi operacyjnemu, aby wykonało się automatycznie, trzeba będzie to zrobić, i oczywiście oprogramowanie sterownika systemu plików będzie musiało tam być.

Jak działa sterownik systemu plików? Odpowiedź: robi to poprzez czytanie i zapisywanie do pliku urządzenia. Dlaczego? Odpowiedź, jak już wspomniałeś: Unix został zaprojektowany w ten sposób. W Uniksie pliki urządzeń są powszechną abstrakcją niskiego poziomu dla urządzeń. Naprawdę oprogramowanie specyficzne dla urządzenia (sterownik urządzenia) dla określonego urządzenia ma zaimplementować otwieranie, zamykanie, czytanie i zapisywanie na urządzeniu jako operacje na pliku urządzenia. W ten sposób oprogramowanie wyższego poziomu (takie jak sterownik systemu plików) nie musi wiedzieć tyle o wewnętrznym działaniu poszczególnych urządzeń. Niskopoziomowe sterowniki urządzeń i sterowniki systemu plików mogą być zapisywane osobno przez różne osoby, pod warunkiem, że uzgodnią wspólny sposób komunikowania się między sobą i do tego służą pliki urządzeń.

Tak więc sterowniki systemu plików potrzebują plików urządzeń.

Ale dlaczego my, zwykli użytkownicy, widzimy pliki urządzeń? Odpowiedź jest taka, że ​​Unix został zaprojektowany do użytku przez programistów systemów operacyjnych. Został zaprojektowany, aby umożliwić użytkownikom pisanie sterowników urządzeń i sterowników systemu plików. Tak właśnie się pisze.

To samo dotyczy Linuksa: możesz napisać własny sterownik systemu plików (lub sterownik urządzenia), zainstalować go, a następnie użyć. To sprawia, że ​​Linux (lub jakikolwiek inny wariant Uniksa) jest łatwo rozszerzalny (i to jest powód, dla którego Linux został uruchomiony): kiedy pojawia się jakiś nowy sprzęt lub pojawia się nowy, mądrzejszy sposób implementacji systemu plików , ktoś może napisać kod, aby go wesprzeć, sprawić, by działał i wniósł go do systemu Linux.

Pliki urządzeń ułatwiają to.

Wiele silników baz danych może pracować bezpośrednio z surowymi dyskami lub partycjami. Na przykład MySQL:

http://dev.mysql.com/doc/refman/5.7/en/innodb-raw-devices.html

Pozwala to uniknąć narzutu związanego ze przeglądaniem sterowników systemu plików, gdy wszystko, czego tak naprawdę potrzebuje silnik DB, to jeden ogromny plik, który wypełnia dysk.

Ponieważ /dev/cdromjest urządzeniem, podczas gdy /media/cdromjest systemem plików . Musisz zamontować ten pierwszy na drugim, aby uzyskać dostęp do plików na CD-ROM.

Twój system operacyjny już automatycznie instaluje systemy plików root i użytkownika z fizycznego urządzenia dysku twardego podczas uruchamiania komputera. To tylko dodaje więcej systemów plików do użycia.

Wszystkie systemy operacyjne to robią - jednak niektóre (takie jak Windows, kiedy montuje dysk CD-ROM D:) robią to w sposób transparentny. Linux pozostawia to tobie, abyś miał większą kontrolę nad procesem.

Dzieje się tak, ponieważ w przypadku wielu multimediów dla interfejsów użytkownika komputerów stacjonarnych i laptopów niejednoznaczność co do tego, co zrobić, gdy nośnik jest włożony, ponieważ intuicja użytkownika polega na tym, że włożenie dysku do fizycznego pudełka, z którym użytkownik wchodzi w interakcje, nie różni się, powiedzmy, , wkładając go do urządzenia obok komputera, który ma połączenie sieciowe.

Dlatego w podstawowym znaczeniu interfejs użytkownika dla mediów musi traktować dwa rodzaje potencjalnych zdarzeń montowania w podobny sposób, a komputery nie mogą obsługiwać montowań sieciowych w tak intuicyjny sposób, jak to możliwe dla montowań sieciowych z innymi interfejsami użytkownika na komputerach, takich jak smartfony, tablety i komputery do noszenia, które nie mają możliwości wstawienia fizycznych nośników do urządzenia. (Zwróć uwagę, jak straszny jest interfejs iPhone'a do przełączania kart SIM, do których włożono jeden rodzaj fizycznych urządzeń z iOS.

Należy również zauważyć, że inne popularne podejścia do interfejsów użytkownika dla tego typu fizycznych urządzeń (na przykład Windows 98, Windows 8, Mac OS X 10.2 (Jaguar) i Mac OS X 10.9 (Mavericks)) mają takie same problemy i użyj dodatkowych okien dialogowych z interfejsem GUI, aby rozwiązać potencjalne zamieszanie (na przykład system Windows 8 jest zwykle skonfigurowany tak, aby pytać o każdą nową włożoną płytę CD, czy powinien być zamontowany jako system plików, nośnik muzyczny lub, w razie potrzeby, kolekcja filmów MP4 ). Nie ma powodu, dla którego żadne z tych okien dialogowych użytkownika nie może być używane z Linuksem lub innymi systemami UNIX.