Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Vorwort
1 Einleitung
TEIL I: Einstieg in Linux
2 Die Installation
3 Erste Schritte
4 Linux als Workstation für Einsteiger
TEIL II: Grundlagen
5 Kernel
6 Grundlagen aus Anwendersicht
TEIL III: Die Shell
7 Die Shell
8 Reguläre Ausdrücke
9 Konsolentools
10 Die Editoren
11 Shellskriptprogrammierung mit der bash
12 Die C-Shell
TEIL IV: System- & Netzwerkadministration
13 Benutzerverwaltung
14 Grundlegende Verwaltungsaufgaben
15 Netzwerkgrundlagen
16 Anwendersoftware für das Netzwerk
17 Netzwerkdienste
18 Mailserver unter Linux
19 LAMP & Co.
20 DNS-Server
21 Secure Shell
TEIL V: Die grafische Oberfläche
22 Die grafische Oberfläche
23 Window-Manager und Desktops
24 X11-Programme
25 Multimedia und Spiele
TEIL VI: Systeminterna
26 Prozesse und IPC
27 Bootstrap und Shutdown
28 Dateisysteme
29 Virtualisierung und Emulatoren
TEIL VII: Programmierung und Sicherheit
30 Softwareentwicklung
31 Crashkurs in C und Perl
32 Einführung in Computersicherheit
33 Netzwerksicherheit überwachen
TEIL VIII: Anhang
A Lösungen zu den einzelnen Aufgaben
B Kommandoreferenz
C X11-InputDevices
D MBR
E Buch-DVDs
F Glossar
G Literatur
Stichwort
Ihre Meinung?

Spacer
Linux von Johannes Plötner, Steffen Wendzel
Das umfassende Handbuch
Buch: Linux

Linux
Rheinwerk Computing
1282 S., 5., aktualisierte Auflage 2012, geb., mit 2 DVDs
49,90 Euro, ISBN 978-3-8362-1822-1
Pfeil 28 Dateisysteme
Pfeil 28.1 Aufbau von Speichermedien
Pfeil 28.1.1 Physische Struktur
Pfeil 28.1.2 Logische Struktur
Pfeil 28.1.3 Integration ins VFS
Pfeil 28.2 Dateisysteme
Pfeil 28.2.1 ext2, ext3, ext4 und reiserfs
Pfeil 28.2.2 btrfs und ZFS
Pfeil 28.2.3 FUSE – Filesystem in Userspace
Pfeil 28.2.4 FFS und UFS/UFS2
Pfeil 28.2.5 ISO 9660
Pfeil 28.2.6 Loop-Device und Ramdisk
Pfeil 28.2.7 Swap
Pfeil 28.2.8 DevFS und udev
Pfeil 28.2.9 ProcFS
Pfeil 28.2.10 NFS
Pfeil 28.2.11 Ecryptfs
Pfeil 28.2.12 Weitere Dateisysteme
Pfeil 28.3 Dateitypen
Pfeil 28.3.1 Reguläre Dateien
Pfeil 28.3.2 Verzeichnisse
Pfeil 28.3.3 Links
Pfeil 28.3.4 Sockets
Pfeil 28.3.5 Named Pipes
Pfeil 28.3.6 Gerätedateien
Pfeil 28.4 Inodes
Pfeil 28.4.1 Metadaten
Pfeil 28.4.2 Alternative Konzepte
Pfeil 28.5 Administration
Pfeil 28.5.1 QtParted und GParted
Pfeil 28.5.2 palimpsest
Pfeil 28.5.3 disklabel
Pfeil 28.5.4 hdparm
Pfeil 28.5.5 fdisk und cfdisk
Pfeil 28.5.6 cfdisk
Pfeil 28.5.7 mkfs
Pfeil 28.5.8 tune2fs
Pfeil 28.5.9 fsck
Pfeil 28.6 Neue Festplatten integrieren
Pfeil 28.6.1 Formatieren
Pfeil 28.6.2 Mountpoint festlegen
Pfeil 28.7 USB-Sticks und -Platten, Digitalkameras und Co.
Pfeil 28.8 Zusammenfassung
Pfeil 28.9 Aufgaben

Rheinwerk Computing - Zum Seitenanfang

28.3 DateitypenZur nächsten Überschrift

Alles ist Datei

Unter Unix gibt es bezüglich Dateisystemen die Philosophie, dass eigentlich alles als »Datei« bezeichnet wird, was sich im Dateisystem befindet. [Fn. Das ist nicht selbstverständlich. Beispielsweise befindet sich unter Windows das Verzeichnis C:\ auch im Dateisystem, ist aber keine Datei.] Unix-Anwender, die von Windows kommen, denken oft, dass nur reguläre Dateien (also ausführbare Programme, Text-Dateien etc.) »richtige« Dateien seien. Dies ist aber unter Unix nicht der Fall. Unter Unix sind beispielsweise auch Sockets, FIFOs, Verzeichnisse und Devices Dateien. [Fn. Unter Solaris kennt man auch Doors als Dateitypen.] Auch wenn Sie mit einigen Begriffen nach der Lektüre der früheren Kapitel schon einiges anfangen können, geben wir Ihnen im Folgenden eine zusammenfassende Übersicht.


Rheinwerk Computing - Zum Seitenanfang

28.3.1 Reguläre DateienZur nächsten ÜberschriftZur vorigen Überschrift

In die Kategorie der regulären Dateien gehören alle Text- und Binärdateien – also zum Beispiel ausführbare Programme, Shellskripte, Konfigurationsdateien, Save- games (gespeicherte Spielstände aus Computerspielen) oder Library-Dateien. Ein unbedarfter Betrachter würde vielleicht im semantischen Unterschied dieser Dateien unterschiedliche Dateitypen ausmachen wollen. Jedoch kennt das Betriebssystem diese Unterschiede nicht, da im Zugriff auf diese Dateien abstrahiert und die Interpretation des Inhalts einem Benutzerprogramm überlassen wird.

Im Besonderen definiert sich ein Dateityp also nicht nur durch den Unterschied zwischen z. B. Text- oder Musikdateien, sondern aus Sicht des Betriebssystems.


Rheinwerk Computing - Zum Seitenanfang

28.3.2 VerzeichnisseZur nächsten ÜberschriftZur vorigen Überschrift

Verzeichnisse (engl. directories) stellen einen ganz eigenen Dateityp dar. Ein Verzeichnis beinhaltet die sogenannten Inode-Nummern der in diesem Verzeichnis befindlichen Dateinamen. Diese stellen Verweise auf die eigentlichen Dateien dar. Außerdem ist im Verzeichnis jeder darin enthaltenen Inode-Nummer mindestens ein Dateiname zugeordnet.

Dateien befinden sich demzufolge also nicht in einem Verzeichnis – das gaukelt Ihnen das System nur vor --, sondern an einem x-beliebigen Ort auf dem Speichermedium. Im Prinzip kann eine Datei also in mehreren Verzeichnissen gleichzeitig unter verschiedenen Namen existieren. Das Verzeichnis »weiß« nur, dass es einen Dateinamen »x« gibt, der auf einen Inode-Eintrag mit der Nummer »y« verweist.

Kopieren versus Verschieben

Wird also eine Datei innerhalb eines Dateisystems von einem Verzeichnis A in ein Verzeichnis B verschoben, so werden nur die Inode-Einträge der Verzeichnisse angepasst – die Daten selbst müssen nicht kopiert werden. Daher dauert ein Kopiervorgang mittels cp auch wesentlich länger als ein Verschiebungsvorgang mit dem Kommando mv, da beim Kopieren die Daten Byte für Byte kopiert werden müssen.

Wie Sie wissen, ist die Verzeichnisstruktur in Unix hierarchisch aufgebaut. Ein Verzeichnis kann Dateien jeglichen Typs und somit natürlich auch Unterverzeichnisse enthalten. In diesen können wiederum viele weitere Verzeichnisse, Unterverzeichnisse sowie reguläre Dateien liegen.

Abbildung

Abbildung 28.1 Hierarchie der Verzeichnisse

Ausgangspunkt der Hierarchie ist das bereits bekannte Wurzelverzeichnis. Im Verzeichnisbaum werden dabei auch alle anderen Dateisysteme, etwa das eines CD- Laufwerks oder ein NFS-Dateisystem, gemountet.

[»]Die Hierarchie eines Unix-Dateisystems ist im Filesystem Hierarchy Standard genau festgelegt. Diesen Standard finden Sie in Kapitel 6 zusammengefasst oder ausführlich unter www.pathname.com/fhs.

Rheinwerk Computing - Zum Seitenanfang

28.3.3 LinksZur nächsten ÜberschriftZur vorigen Überschrift

Auf Dateien verweisen

Links sind Verweise auf andere Dateien oder sie stellen eine (weitere) Instanz für eine Datei dar. Links werden grundsätzlich in zwei Typen unterteilt: Hardlinks und Softlinks. Letztere werden oft auch als symbolische Links bezeichnet.

Ein symbolischer Link /cdrom wäre eine spezielle Datei mit /mnt/cdrom oder einem anderen Ziel als Inhalt. Greift ein Benutzer nun auf /cdrom zu, so merkt das Betriebssystem, dass es sich bei diesem Verzeichnis um einen Link handelt, und leitet den Benutzer entsprechend zum Ziel weiter.

Bei einem Hardlink handelt es sich dagegen nur um einen weiteren Dateinamen für eine bereits vorhandene Datei. Dieser Dateiname verweist auf den gleichen Inode-Eintrag des Dateisystems wie die Orginaldatei. Da jede reguläre Datei, etwa eine Textdatei, ein Verweis auf einen Inode-Eintrag ist, ist sie immer auch ein Hardlink.

ln

Links werden mit dem Tool ln erzeugt. Es können sowohl Soft- als auch Hardlinks erzeugt werden. Übergibt man als Parameter nur den Namen der Originaldatei und den Namen des neuen Links, so wird ein Hardlink erstellt. Fügt man hingegen die Option -s hinzu, wird ein Softlink erstellt.

Listing 28.17 Einen symbolischen Link erzeugen

$ echo "ABC" > datei
$ ln datei symlink_datei
$ cat symlink_datei
ABC
$ cd /etc
$ ls
X11
adduser.conf
adduser.message
afs
amd
astrocam.conf
...
$ ln -s /etc /tmp/symlink_etc
$ ls /tmp/symlink_etc
X11
adduser.conf
adduser.message
afs
amd
astrocam.conf
...
$ ln /etc /tmp/symlink_etc2
ln: /etc: is a directory

Softlinks (symbolische Links) können auf Dateien verweisen, die nicht mehr existieren. Sie können zudem auf Verzeichnisse verweisen, was mit Hardlinks nicht möglich ist.

Link-Count

Im Inode-Eintrag einer jeden Datei ist ein sogenannter Link-Count enthalten. Er gibt an, wie viele Dateinamen (Hardlinks) im Dateisystem auf den Inode-Eintrag verweisen. Damit kann das Betriebssystem zu jeder Zeit in Erfahrung bringen, ob überhaupt noch ein Dateiname in irgendeinem Verzeichnis auf diesen Inode-Eintrag verweist. Ist das nicht der Fall, können der Eintrag sowie die Datenbereiche, auf die er verweist, gelöscht werden. Somit steht der verwendete Speicherplatz wieder zur Nutzung durch andere Dateien zur Verfügung.

Wird eine Datei im Dateisystem erstellt, so erhält der entsprechende Link-Count den Wert »1«. Wird daraufhin noch ein zusätzlicher Hardlink auf diesen Inode-Eintrag erstellt, so erhöht der Dateisystem-Code im Kernel den Link-Count auf »2«. Löscht man nun einen dieser Hardlinks, sinkt der Wert wieder auf »1«. Löscht man den letzten Hardlink ebenfalls, so sinkt der Wert auf »0« und die Datei kann physisch gelöscht werden (z. B. durch Überschreiben mit neuen Daten).

Nehmen wir einmal die Datei /tmp/file als Beispiel. Sie hat einen Link-Count von »1«, da nur ein Dateiname auf diese Datei verweist. Erstellt man nun einen Hardlink auf diese Datei, zeigt ls den jetzt inkrementierten Wert des Link-Counts an.

Listing 28.18 Link-Count (Zweite Spalte der ls-Ausgabe)

$ touch file
$ ls -l file
-rw------- 1 cdp_xe wheel 0 May 1 19:10 file
$ ln file fileb
$ ls -l file
-rw------- 2 cdp_xe wheel 0 May 1 19:10 file

Rheinwerk Computing - Zum Seitenanfang

28.3.4 SocketsZur nächsten ÜberschriftZur vorigen Überschrift

Sockets sind nicht zwangsläufig im Dateisystem abgelegt – dies ist durch den Typ des Sockets bedingt. TCP/IP-Sockets liegen beispielsweise nicht im Dateisystem. Ausschließlich Unix-Domain-Sockets sind als Datei im Dateisystem zu finden. Programme können dann in diesen Socket schreiben (also senden) und aus ihm lesen (also empfangen). Dabei kann vom Programmierer je nach Wunsch eine Stream- oder eine Datagrammverbindung verwendet werden.

Dabei werden, wie Sie aus Kapitel 26, »Prozesse und IPC«, bereits wissen, die üblichen Socket-Syscalls genutzt, die auch bei TCP-Stream-Sockets und UDP-Datagramm-Sockets verwendet werden.


Rheinwerk Computing - Zum Seitenanfang

28.3.5 Named PipesZur nächsten ÜberschriftZur vorigen Überschrift

Pipes kennen Sie bereits aus den Kapiteln zur Shell und zur Interprozess-Kommunikation. Named Pipes werden im Gegensatz zu einfachen Pipes als Datei im Dateisystem abgelegt. Pipes bieten dabei eine Kommunikationsmöglichkeit innerhalb einer Prozesshierarchie (unterhalb eines Session-Leader-Prozesses wie der Shell oder eines Dämonprozesses).


Rheinwerk Computing - Zum Seitenanfang

28.3.6 GerätedateienZur vorigen Überschrift

Gerätedateien (engl. device files) sind im Dateisystem unterhalb von /dev untergebrachte Dateien, die eine Hardwarekomponente repräsentieren. Eine solche Hardwarekomponente kann entweder real existieren oder nur virtueller Natur sein. Letzteres bezeichnet man als Pseudo-Device. Ein Pseudo-Device wäre beispielsweise /dev/null.



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.

>> Zum Feedback-Formular
<< zurück
 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Linux Handbuch






 Linux Handbuch


Zum Katalog: Linux Server






 Linux Server


Zum Katalog: Raspberry Pi






 Raspberry Pi


Zum Katalog: Ubuntu 14.04 LTS






 Ubuntu 14.04 LTS


Zum Katalog: Roboter bauen mit Arduino






 Roboter bauen
 mit Arduino


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Rheinwerk Verlag GmbH 2012
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


Nutzungsbestimmungen | Datenschutz | Impressum

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de