way tl; dr
Twój schemat jest zasadniczo poprawny.
/dev/<device> akta
Myślę, że najbardziej podstawowym sposobem na rozpoczęcie odpowiedzi na twoje pytanie jest to, jakie /dev/<device>są pliki. Powiedz, że masz dysk twardy. Ten dysk twardy ma tablicę partycji opartą na MBR i ma dwie partycje, jedną sformatowaną ext4 z niektórymi plikami, a drugą skonfigurowaną dla LVM. Zauważ, że ta odpowiedź mówi o tworzeniu plików w locie, co oznacza, że używasz jądra Linux. W przypadku innych jednorożców sytuacja wygląda nieco inaczej .
Po podłączeniu tego dysku twardego (lub gdy system wykryje go podczas rozruchu) plik katalogu zostanie utworzony w /devkatalogu - zwykle nazywany albo ( /dev/sd*lub w /dev/hd*zależności od kontrolera używanego do podłączenia dysku) - * list. Bajty w pliku urządzenia są zasadniczo mapowane liniowo na bajty na dysku fizycznym: jeśli użyjesz narzędzia do zapisu na początku pliku urządzenia, dane te zostaną również zapisane na fizycznym początku dysku fizycznego.
Teraz system rozumie także tabele partycji, takie jak MBR i GPT. Po utworzeniu początkowego pliku urządzenia zostanie on odczytany w celu ustalenia, czy ma on tablicę partycji. Jeśli tak, zostaną utworzone pliki urządzeń reprezentujące te partycje. Zakładając, że oryginalny plik urządzenia został wywołany /dev/sda, /dev/sda1zostanie utworzony plik urządzenia o nazwie (reprezentujący pierwszą partycję w formacie ext4), a także /dev/sda2urządzenie (reprezentujące drugą partycję LVM). Są one mapowane liniowo na odpowiednie partycje w taki sam sposób, jak cały dysk - to znaczy, jeśli użyjesz narzędzia (na przykład) do zapisu na początku /dev/sda2, zapisane dane zostaną fizycznie zapisane na początku drugiej partycji , który jest właściwie środkiem całego dysku, ponieważ tam zaczyna się druga partycja.
Bloki i sektory
To wygodny czas na rozmowę o blokach i sektorach: są to po prostu pomiary miejsca na dysku fizycznym, nic więcej (przynajmniej jeśli dobrze rozumiem). Sektor to fizyczny region na dysku twardym; to zwykle 512 bajtów - 4 KB na nowszych dyskach twardych. Blok jest również jednostką miary, prawie zawsze ma 8 KB. Kiedy ktoś mówi o czytaniu i zapisywaniu bloków, oznacza to po prostu, że zamiast czytać każdy bajt danych osobno, odczytuje i zapisuje dane w porcjach po 8 KB.
Systemy plików i i-węzły
Następnie systemy plików i i-węzły. System plików jest dość prostą koncepcją: na początku regionu, w którym znajduje się system plików (ten region jest zwykle partycją), jest wiele informacji o systemie plików. Ten nagłówek (nazywany również superblokiem, jak sądzę) jest najpierw używany do określenia, który sterownik systemu plików powinien być używany do odczytu systemu plików, a następnie jest używany przez wybrany sterownik systemu plików do odczytu plików. Jest to oczywiście uproszczenie, ale zasadniczo przechowuje dwie rzeczy (które mogą, ale nie muszą być przechowywane jako dwie odrębne struktury danych na dysku, w zależności od typu fs): drzewo katalogów i lista i-węzłów. Drzewo katalogów jest tym, co widzisz po wykonaniu polecenia a lslub atree. Drzewo katalogów określa, które pliki i katalogi są dziećmi, z których innych katalogów. Relacja rodzic / dziecko plik / katalog tworzy drzewo katalogów UNIX, jakie znamy.
Ale drzewo katalogów zawiera tylko nazwy. Te nazwy są dodatkowo powiązane z numerami i-węzłów. Numer i-węzła zawiera informacje, takie jak miejsce, w którym fragmenty pliku są fizycznie przechowywane na dysku. Sam i-węzeł jest po prostu „plikiem” bez nazwy; i-węzeł jest powiązany z nazwą za pośrednictwem drzewa katalogów. Zobacz także Co to jest superblok, i-węzeł, dentystyka i plik?
Jak dotąd, mamy następujące wyjaśnienie: /dev/sd*pliki mapowania dysków twardych, /dev/sd*#pliki mapowania na numer partycji #na /dev/sd*. System plików to struktura danych na dysku, która śledzi drzewo katalogów; na ogół jest przechowywany w partycji ( /dev/sd*#). System plików zawiera i-węzły; i-węzły to liczby reprezentujące pliki wraz z danymi powiązanymi z tymi plikami (z wyjątkiem ich nazwy i pozycji w drzewie katalogów).
Warto zauważyć, że systemy plików zazwyczaj śledzą dane w blokach. Zwykle drzewo katalogów i lista i-węzłów są przechowywane w blokach, a nie w bajtach, a i-węzły wskazują na bloki na dysku, a nie w bajtach. (Może to powodować problemy z tym, że pliki zwykle marnują pół bloku miejsca, ponieważ system plików przydzielił cały blok, ale nie musiał używać tego całego bloku w ostatniej części pliku).
Mapowanie urządzenia
Ostatnim elementem układanki jest bardzo ważny moduł w jądrze Linuksa, zwany maperem urządzeń (załaduj go modprobe dm). Maper urządzeń pozwala zasadniczo utworzyć inny plik urządzenia w /dev/mapperkatalogu. Ten plik urządzenia jest następnie mapowany na inne źródło danych, prawdopodobnie ulegając transformacji. Najprostszym przykładem jest odczyt części pliku.
Załóżmy, że masz obraz pełnego dysku wraz z tabelą partycji. Musisz odczytać dane z jednej z partycji w obrazie, ale nie możesz dostać się tylko do tej partycji, ponieważ jest to obraz całego dysku zamiast obrazu z jedną partycją. Rozwiązaniem jest znalezienie miejsca na obrazie partycji, a następnie utworzenie nowego mapowania pliku urządzenia na tę część obrazu dysku. Oto schemat:
.-------------------.
| /dev/mapper/foo | <- This is the device file created with the device mapper
.___________________.
\ /
\ /
\ / <- This is a small section of the image being mapped to
\ / the new device file
\ /
\ /
.------------------.
| diskimage.img | <- This is the full-disk image. It's a regular file.
.__________________. Notice how the mapping goes to _part_ of the file.
Innym sposobem myślenia o tym jest potok transformacji (jest to dokładniejsza metafora tego, co dzieje się wewnętrznie w jądrze). Wyobraź sobie przenośnik taśmowy. Żądanie - odczyt, zapis itp. - rozpoczyna się na jednym końcu przenośnika taśmowego w pliku urządzenia utworzonym za pomocą mapera urządzeń. Następnie żądanie przechodzi przez transformację mapowania urządzenia do pliku źródłowego. W powyższym przykładzie, to plik źródłowy jest zwykłym pliku diskimage.img. Oto schemat:
Read operation goes onto
device mapper conveyor belt
read() The device mapper transforms the read The modified read request finally
\ request by moving the requested region reaches the source file, and the data
\ Beginning of conveyor belt to read forward by some number of bytes. is retrieved from the filesystem.
\
\ .-------------------. .--------------------------. .------------------------.
\ | /dev/mapper/foo | | Transformation logic | | /path/to/diskimage.img |
\ .___________________. .___+_____+_____+_____+____. .________________________.
\-->
---------------------------------------------------------------------------------------------------------------
o o o o o o o o o o o
Zauważ, że na schemacie logika transformacji, która została połączona z maperem urządzenia, ma małe narzędzia +do manipulowania żądaniem odczytu, gdy przesuwa się po taśmie przenośnika.
Teraz nie mam ochoty kopiować tego diagramu i modyfikować go w LVM, ale w zasadzie część transformacji może być dowolna - nie tylko przesuwanie zakresu bajtów do przodu. Oto jak działa LVM: zasięg fizyczny LVM to część LVM, która znajduje się na dysku i śledzi, gdzie znajdują się dane. Pomyśl o tym jak o systemie plików LVM. W metaforze przenośnika taśmowego zasięg fizyczny jest jednym z plików źródłowych, a transformacja polega na tym, że LVM robi swoje, odwzorowując żądanie na woluminie logicznym (który jest skrajnie lewy element na przenośniku taśmowym) na dane fizyczne na dysku. A propos...
Jestem trochę zardzewiały na moich koncepcjach LVM, ale IIRC, grupa woluminów jest zasadniczo jak dysk w LVM. Ponownie, IIRC, poziomy RAID itp. Są zarządzane według grup woluminów. Wolumin logiczny jest więc jak partycja, a woluminy logiczne to tak naprawdę pliki reprezentujące je. Umieszczasz systemy plików i inne rzeczy w woluminach logicznych.
Fajną rzeczą w maperze urządzeń jest to, że wbudowana w niego logika może zostać dowolnie wstawiona do stosu danych - wystarczy zmienić nazwę urządzenia, które czytasz. Tak działają zaszyfrowane partycje ( nie schematy szyfrowania działające na poziomie plików - te używają FUSE) i tak działa LVM. W tej chwili nie mogę wymyślić żadnych innych przykładów, ale zaufaj mi, mapowanie urządzeń jest dość kiepskie.
Adresowanie bloku logicznego
Nigdy o tym nie słyszałem, więc nie mogę podać żadnych informacji na ten temat. Mam nadzieję, że ktoś przyjdzie i zredaguje tę odpowiedź.
