Es ist mir etwas peinlich, diese Frage zu stellen, aber ich würde gerne ein Diagramm sehen, das zeigt, wie die folgenden Dinge zusammenhängen. Es wäre schön, wenn das Diagramm auch alle Transformationen enthalten würde, die für die Zuordnung zwischen den verschiedenen Ebenen erforderlich sind.
So wie ich es verstehe, glaube ich, dass sie auf folgende Weise zusammenhängen, aber ich bin mir nicht sicher, ob mein Verständnis zu 100 % korrekt ist.
.-----------------.
| inode |
'-----------------'
|
.-----------------.
| EXT4 |
'-----------------'
|
.---------------------.
| logical volume (LV) | --- part of LVM
'---------------------'
|
.-------------------.
| volume group (VG) | --- part of LVM
'-------------------'
|
.---------------.
| /dev/<device> |
'---------------'
|
.--------------------------------.
| Logical Block Addressing (LBA) |
'--------------------------------'
|
.-----------------.
| blocks/sectors |
'-----------------'
|
HDD
_.-----._
.- -.
|-_ _-|
| ~-----~ |
| |
`._ _.'
"-----"
Referenzen
- Feststellen, welche Festplattensektoren eine Datei belegen
- Identifizierende Datei, die einem nicht lesbaren Festplattensektor zugeordnet ist
- Bad-Block-HOWTO für Smartmontools
- C5170 Vorlesungsskript – Interne Repräsentation von Dateien – Das Unix-Dateisystem
- Logische Blockadressierung
- Ext4-Festplattenlayout
Akzeptierte Antwort:
Weg tl;dr
Ihr Diagramm ist im Wesentlichen korrekt.
/dev/<device> Dateien
Ich denke, der einfachste Weg, um Ihre Frage zu beantworten, ist mit was /dev/<device> Dateien sind. Angenommen, Sie haben eine Festplatte. Diese Festplatte hat eine MBR-basierte Partitionstabelle, und sie hat zwei Partitionen, eine formatiert ext4 mit einigen Dateien darauf und die andere für LVM eingerichtet. Beachten Sie, dass diese Antwort über die Erstellung von Gerätedateien im laufenden Betrieb spricht, was impliziert, dass Sie einen Linux-Kernel verwenden. Bei anderen Unices ist das etwas anders.
Wenn Sie diese Festplatte anschließen (oder wenn das System sie beim Booten erkennt), wird eine Gerätedatei im Verzeichnis /dev erstellt Verzeichnis – im Allgemeinen entweder /dev/sd* genannt oder /dev/hd* (je nachdem, welcher Controller verwendet wird, um das Laufwerk anzuschließen) – das * ist ein Buchstabe. Bytes in der Gerätedatei werden im Wesentlichen linear auf Bytes auf der physischen Festplatte abgebildet:Wenn Sie ein Tool verwenden, um an den Anfang der Gerätedatei zu schreiben, werden diese Daten auch an den physischen Anfang der physischen Festplatte geschrieben.
Jetzt versteht das System auch Partitionstabellen wie MBRs und GPTs. Nachdem die anfängliche Gerätedatei erstellt wurde, wird sie gelesen, um festzustellen, ob sie eine Partitionstabelle hat. Wenn dies der Fall ist, werden Gerätedateien erstellt, die diese Partitionen darstellen. Angenommen, die ursprüngliche Gerätedatei hieß /dev/sda , eine Gerätedatei namens /dev/sda1 erstellt (die die erste, ext4-formatierte Partition darstellt), sowie ein /dev/sda2 Gerät (das die zweite LVM-Partition darstellt). Diese werden genauso wie das gesamte Laufwerk linear auf ihre jeweiligen Partitionen abgebildet – also wenn man mit einem Tool (zum Beispiel) an den Anfang von /dev/sda2 schreibt , werden die geschriebenen Daten physisch an den Anfang der zweiten Partition geschrieben, die eigentlich die Mitte ist der gesamten Festplatte, denn dort beginnt die zweite Partition.
Blöcke und Sektoren
Dies ist ein geeigneter Zeitpunkt, um über Blöcke und Sektoren zu sprechen:Dies sind nur Messungen des Speicherplatzes auf einer physischen Festplatte, nicht mehr (zumindest wenn ich das richtig verstehe). Ein Sektor ist ein physikalischer Bereich auf einer Festplatte; es sind normalerweise 512 Bytes – 4 KB auf neueren Festplatten. Ein Block ist auch eine Maßeinheit, es sind fast immer 8 KB. Wenn jemand über das Lesen und Schreiben von Blöcken spricht, bedeutet das nur, dass er nicht jedes Datenbyte einzeln liest, sondern Daten in Blöcken von 8 KB liest und schreibt.
Dateisysteme und Inodes
Als nächstes Dateisysteme und Inodes. Ein Dateisystem ist ein ziemlich einfaches Konzept:Am Anfang der Region, in der sich das Dateisystem befindet (diese Region ist normalerweise eine Partition), gibt es eine Reihe von Informationen über das Dateisystem. Dieser Header (auch als Superblock bezeichnet, glaube ich) wird zuerst verwendet, um zu bestimmen, welcher Dateisystemtreiber zum Lesen des Dateisystems verwendet werden soll, und dann wird er vom ausgewählten Dateisystemtreiber zum Lesen von Dateien verwendet. Dies ist natürlich eine Vereinfachung, aber es speichert im Wesentlichen zwei Dinge (die je nach fs-Typ als zwei unterschiedliche Datenstrukturen auf der Festplatte gespeichert werden können oder nicht):den Verzeichnisbaum und eine Liste von Inodes. Der Verzeichnisbaum ist das, was Sie sehen, wenn Sie ein ls ausführen oder ein tree . Der Verzeichnisbaum gibt an, welche Dateien und Verzeichnisse die Kinder welcher anderen Verzeichnisse sind. Die Datei/Verzeichnis-Eltern-Kind-Beziehung bildet den UNIX-Verzeichnisbaum, wie wir ihn kennen.
Aber der Verzeichnisbaum enthält nur Namen. Diese Namen sind zusätzlich mit Inode-Nummern verknüpft. Eine Inode-Nummer enthält Informationen darüber, wo die Teile einer Datei physisch auf der Festplatte gespeichert sind. Ein Inode an sich ist einfach „eine Datei“ ohne Namen; ein Inode wird über den Verzeichnisbaum einem Namen zugeordnet. Siehe auch Was ist ein Superblock, Inode, Dentry und eine Datei?
Bisher haben wir die folgende Erklärung:/dev/sd* Dateien werden Festplatten zugeordnet, /dev/sd*# Dateien werden der Partitionsnummer # zugeordnet auf /dev/sd* . Ein Dateisystem ist eine Datenstruktur auf einer Festplatte, die einen Verzeichnisbaum verfolgt; es wird im Allgemeinen in einer Partition (/dev/sd*# ). Ein Dateisystem enthält Inodes; Inodes sind Nummern, die Dateien darstellen, zusammen mit Daten, die diesen Dateien zugeordnet sind (mit Ausnahme ihres Namens und ihrer Position im Verzeichnisbaum).
Es ist erwähnenswert, dass Dateisysteme Daten im Allgemeinen in Blöcken verfolgen. Normalerweise werden der Verzeichnisbaum und die Inode-Liste in Blöcken gespeichert, nicht in Bytes, und Inodes zeigen auf Blöcke auf der Festplatte, nicht auf Bytes. (Dies kann Probleme verursachen, wenn Dateien normalerweise einen halben Block Speicherplatz verschwenden, weil das Dateisystem einen ganzen Block zugewiesen hat, aber diesen ganzen Block nicht für den letzten Teil der Datei verwenden musste.)
Der Geräte-Mapper
Das letzte Teil des Puzzles ist ein sehr wichtiges Modul im Linux-Kernel namens Device Mapper (mit modprobe dm laden ). Mit dem Device-Mapper können Sie grundsätzlich eine weitere Gerätedatei in /dev/mapper erstellen Verzeichnis. Diese Gerätedatei wird dann einer anderen Datenquelle zugeordnet und dabei möglicherweise transformiert. Das einfachste Beispiel ist das Lesen eines Teils einer Datei.
Angenommen, Sie haben ein vollständiges Festplatten-Image, komplett mit der Partitionstabelle. Sie müssen die Daten von einer der Partitionen im Image lesen, aber Sie können nicht nur diese Partition, da es sich um ein Image der gesamten Festplatte handelt und nicht um ein Image einer einzelnen Partition. Die Lösung besteht darin, herauszufinden, wo sich Ihre Partition im Image befindet, und dann eine neue Gerätedatei zu erstellen, die diesem Teil des Disk-Images zugeordnet ist. Hier ist ein Diagramm:
.-------------------.
| /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.
Man kann es sich auch wie eine Transformationspipeline vorstellen (dies ist die genauere Metapher für das, was intern im Kernel passiert). Stellen Sie sich ein Förderband vor. Eine Anfrage – ein Lesen, ein Schreiben usw. – beginnt an einem Ende des Förderbands auf einer Gerätedatei, die mit dem Geräte-Mapper erstellt wurde. Die Anforderung durchläuft dann die Device-Mapper-Umwandlung zur Quelldatei. Im obigen Beispiel ist diese Quelldatei eine normale Datei, diskimage.img . Hier ist das Diagramm:
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
Beachten Sie, wie im Diagramm die Transformationslogik, die mit dem Device Mapper verbunden wurde, über kleine Tools verfügt (+ s) um die Leseanforderung zu manipulieren, während sie sich auf dem Förderband bewegt.
Nun, ich habe keine besondere Lust, dieses Diagramm zu kopieren und für LVM zu modifizieren, aber im Grunde kann der Transformationsteil alles sein – nicht nur das Verschieben des Byte-Bereichs nach vorne. So funktioniert LVM:Ein LVM Physical Extent ist der Teil von LVM, der sich auf der Festplatte befindet und verfolgt, wo sich die Daten befinden. Stellen Sie es sich wie das Dateisystem von LVM vor. In der Förderband-Metapher ist ein physischer Extent eine der Quelldateien, und die Transformation ist LVM, das seine Sache erledigt, indem es eine Anforderung auf einem logischen Volumen (das ganz links auf dem Förderband ist) den physischen Daten auf der Festplatte zuordnet. Apropos…
Ich bin mit meinen LVM-Konzepten etwas eingerostet, aber IIRC, eine Volume Group, ist im Wesentlichen wie eine Festplatte in LVM. Auch hier werden IIRC, RAID-Level usw. pro Volume Group verwaltet. Ein logisches Volume ist also genau wie eine Partition, und logische Volumes haben tatsächlich Gerätedateien, die sie darstellen. Sie legen Dateisysteme und anderes Zeug auf Logical Volumes ab.
Das Coole am Device Mapper ist, dass die damit erstellte Logik beliebig in den Datenstapel eingefügt werden kann – Sie müssen lediglich den Gerätenamen ändern, den Sie gerade lesen. So funktionieren verschlüsselte Partitionen (nicht Verschlüsselungsschemata, die auf Dateiebene arbeiten – diese verwenden FUSE), und so funktioniert LVM. Mir fallen im Moment keine anderen Beispiele ein, aber glauben Sie mir, der Device Mapper ist ziemlich knallhart.
Logische Blockadressierung
Davon habe ich noch nie gehört, daher kann ich dazu keine Angaben machen. Hoffentlich kommt jemand vorbei und bearbeitet diese Antwort.