26.2 Dateisysteme 

Ausfallsicherheit

Im Master-Boot-Record einer Festplatte ist nun bekanntermaßen definiert, wie eine Festplatte partitioniert ist und welcher Typ diesen Partitionen zugeordnet ist. Der Partitionstyp erlaubt nun Rückschlüsse auf das verwendete Dateisystem – und welche Dateisysteme nun unter Linux und BSD populär sind, wollen wir im Folgenden klären.

Einige der Linux-Dateisysteme sind journaling-fähig. Das bedeutet, dass Veränderungen am Dateisystem protokolliert werden und dass so im Falle eines Crashs auf jeden Fall wieder ein konsistenter Zustand des Dateisystems wiederhergestellt werden kann – auch wenn natürlich eventuell Daten verloren gegangen sind.

26.2.1 ext2, ext3 und reiserfs 

Die Standarddateisysteme

Das second extended filesystem ext2 war viele Jahre das Standarddateisystem unter Linux. Es wurde allerdings durch das journaling-fähige third extended filesystem ext3 abgelöst. Der Nachfolger ist gegenüber seinem Vorgänger zu hundert Prozent abwärtskompatibel, was auch anders herum für die Aufwärtskompatibilität gilt. Sie können beide Dateisysteme problemlos ineinander konvertieren und mit den gleichen Tools konfigurieren.

Von ext3 werden drei verschiedene Modi unterstützt, um Journaling durchzuführen: journal, writeback und ordered. Diese Modi unterscheiden sich darin, wie sie die Metadaten des Dateisystems und die eigentlichen Dateiinhalte auf die Platte schreiben und Veränderungen an diesen protokollieren.

• journal

• Im journal-Modus werden alle Veränderungen an Metadaten und normalen Daten protokolliert.

• writeback

• Der writeback-Modus protokolliert hingegen nur die Veränderungen an Metadaten. Alle anderen Daten werden auf die übliche Weise auf das Speichermedium geschrieben. Das bedeutet, dass diese Daten nicht zu jedem Zeitpunkt auf dem Medium mit den Informationen der Metadaten übereinstimmen müssen.

• ordered

• Um dies zu verhindern, gibt es noch den ordered-Modus bei dem die Veränderungen an Metadaten protokolliert werden und alle Dateien, die von diesen Veränderungen betroffen sind, unmittelbar mit ihren Veränderungen auch auf das Speichermedium geschrieben werden.

ReiserFS, jfs, xfs

Das ReiserFS ist ebenfalls journaling-fähig und gilt als äußerst performant. Dies liegt daran, dass die Dateiverwaltung mittels Binärbäumen realisiert wird. Weitere Journaling-Dateisysteme sind jfs von IBM und xfs von SGI.

26.2.2 FFS und UFS/UFS2 

Bei UFS und UFS2 handelt es sich um die zwei typischen Dateisysteme, die auf BSD-Systemen und SunOS/Solaris <SunOS baute auf BSD auf. Solaris als SVR4-orientierter Nachfolger von SunOS übernahm das Dateisystem.> verwendet werden. FFS, das Fast Filesystem , löste dabei vor vielen Jahren mit 4.2BSD das alte Unix-Filesystem von Bell ab und brachte neue Features wie längere Dateinamen, File-Locking, symbolische Links und Quotas mit sich, von denen auch spätere Unix-Systeme profitierten. <Weitere Informationen finden Sie in [MarKuJoy84A].> An dieser Stelle zeigt sich wieder einmal sehr deutlich, dass sich Systeme wie Linux alle möglichen Features anderer Systeme aneignen.

Dabei ist lediglich UFS2 auf allen Systemen, die es unterstützten, jornaling-fähig. UFS2 wird derzeit allerdings nur von FreeBSD seit Version 5 und NetBSD unterstützt. Seit Solaris 7 wurde auch UFS journaling-fähig gemacht. <Mehr hierzu erfahren Sie in [HenMrks00A].>

SoftUpdates

Unter BSD gibt es allerdings neben dem Journaling noch eine andere Technik, die sich um die Konsistenz der Daten kümmert:

SoftUpdates. SoftUpdates werden derzeit von OpenBSD, FreeBSD und NetBSD unterstützt und funktionieren, indem ganze Blöcke von Metadaten im RAM gehalten und in einer bestimmten Reihenfolge sortiert auf die Festplatte geschrieben werden. <Quelle: Wikipedia> Am besten funktionieren SoftUpdates, wenn der Schreibcache abgestellt ist, was bei IDE-Festplatten durchaus spürbare Performance-Einbußen bringen kann, bei SCSI-Platten jedoch relativ problemlos funktioniert.

Da im Falle eines Absturzes trotzdem Fehler in der Form von Blöcken, die frei sind, jedoch noch als belegt markiert sind, auftreten können, muss beim Start des Systems das Dateisystem geprüft werden. Dies wird mit dem Tool fsck realisiert. Diese Prüfung kann den Startvorgang leider erheblich verlängern, was sich nur auf FreeBSD-Systemen unterbinden lässt, da es dort möglich ist, fsck im Hintergrund laufen zu lassen.

26.2.3 ISO 9660 

Das iso9660-Dateisystem, unter BSD auch als cd9660 bezeichnet, stellt wie bereits erwähnt das Dateisystem für CD-ROMs und DVDs dar. Alle gängigen Betriebssysteme sind in der Lage, mit diesem Dateisystem völlig problemlos umzugehen.

linux# mount -t iso9660 /dev/cdrom /mnt/cdrom

Listing 26.1    Eine CD unter Linux mounten

openbsd# mount_cd9660 /dev/cd0a /mnt/cdrom 
openbsd# mount | grep cd0a 
/dev/cd0a on /mnt/cdrom type cd9660 (local, read-only)

Listing 26.2    Eine CD unter OpenBSD mounten

26.2.4 Loop Device und Ramdisk 

Dateien als Geräte mounten

Ein Loop Device bezeichnet eine spezielle Gerätedatei /dev/loop*, die das Mounten von als Dateien vorliegenden Dateisystemen erlaubt. Das ist notwendig, da mount nur auf Gerätedateien operieren kann.

Sinnvoll wird das Ganze bei aus dem Netz geladenen CD-Images, die man zum Beispiel vor dem Brennen kontrollieren möchte.

Man kann aber auch alle möglichen anderen Dateien über so ein Loop Device mounten.

Doch wie erstellt man selbst eine solche Datei? Im Prinzip ist dies relativ einfach: Zuerst erstellen wir mit dem dd-Programm eine Datei beliebiger Größe. Diese Größe muss natürlich der der fertigen Dateipartition entsprechen.

Im folgenden Beispiel entscheiden wir uns für eine 30-MB-Datei. Als Eingabequelle wird /dev/zero verwendet, um unser Image mit binären Nullen zu füllen – irgendeinen initialen Inhalt brauchen wir schließlich.

# dd if=/dev/zero of=filefs.img bs=1M count=30 
30+0 records in 
30+0 records out 
# ls -l filefs.img 
-rw-r--r-- 1 root wh 31457280 Jan 9 16:28 filefs.img

Listing 26.3    Erzeugen der Raw-Datei

Dateisystem erzeugen

Auf dieser Datei wird anschließend ein Dateisystem – in unserem Fall ext2 – erzeugt. Dabei werden 1024 Bytes pro Inode (-i) bei einer Blockgröße von 1024 Bytes pro Block verwaltet. Eine Inode entspricht nun also genau einem Block, was vor allem bei kleineren Dateisystemen Sinn macht. Zudem entscheiden wir uns, drei Prozent <Der Standardwert sind fünf Prozent.> der Partitionsgröße als für root reservierten Speicher zu verwenden (-m). Die Frage, ob das Dateisystem erstellt werden soll, obwohl es sich nicht um ein dafür vorgesehenes Gerät handelt, kann in unserem Fall mit »y« (yes) beantwortet bzw. mit dem -F-Parameter unterdrückt werden.

# mke2fs -i 1024 -b 1024 -m 3 -v filefs.img 
mke2fs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09 
filefs.img is not a block special device. 
Proceed anyway? (y,n) y 
Filesystem label= 
OS type: Linux 
Block size=1024 (log=0) 
Fragment size=1024 (log=0) 
30720 inodes, 30720 blocks 
921 blocks (3.00%) reserved for super user 
First data block=1 
4 block groups 
8192 blocks per group, 8192 fragments per group 
7680 inodex per group 
Superblock backups stored on blocks: 
        8193, 24577 
 
Writing inode tables: done 
Writing superblocks and filesystem accounting 
information: done 
 
This filesystem will be automatically checked 
every 22 mounts or 180 days, whichever comes 
first. Use tune2fs -c or -i to override.

Listing 26.4    Dateisystem erzeugen

Fertig! Nun können Sie probieren, das Dateisystem zu mounten. Man könnte nun die Datei mittels losetup an ein Loop Device binden und dieses dann mounten:

# mkdir /loop 
# losetup /dev/loop0 filefs.img 
# mount -t ext2 /dev/loop0 /loop

Listing 26.5    losetup und mount

Alternativ kann man auch mount die Arbeit mit losetup überlassen, wenn man die loop-Option nicht vergisst:

# mount -t ext2 filefs.img /loop -o loop 
# cat /dev/zero > /loop/file 
^C 
# df -h 
Filesystem       Size Used Avail Use% Mounted on 
/dev/hda1        3.7G 1.5G  2.1G  30% / 
/root/filefs.img  26M  13M   13M  48% /loop

Listing 26.6    Eine Datei direkt mounten

Und das Ganze mit dem RAM

Ein Dateisystem können Sie auch im Hauptspeicher anlegen, zum Beispiel, um für zeitkritische Anwendungen Perfomanceverluste wegen langen Plattenzugriffen zu vermeiden. Das Ganze nennt sich dann »Ramdisk« und läuft über /dev/ram*:

# mke2fs /dev/ram0 
mke2fs 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09 
Filesystem label= 
OS type: Linux 
Block size=1024 (log=0) 
Fragment size=1024 (log=0) 
1944 inodes, 7777 blocks 
…{} 
…{} 
# mount /dev/ram0 /mnt/ramdisk 
# df -h 
Filesystem       Size Used Avail Use% Mounted on 
/dev/hda1        3.7G 1.5G  2.1G  30% / 
/dev/ram0        7.4M  13k  6.9M   1% /mnt/ramdisk

Listing 26.7    RAM-Device

26.2.5 Swap 

Auslagerungs- speicher

Das Swap-Dateisystem wird entweder als einzelne Datei in einem anderen Dateisystem oder als komplettes Dateisystem auf einer Partition einer Festplatte abgelegt. Im Swap-Dateisystem werden temporäre Hauptspeicherdaten ausgelagert, für die im eigentlichen Hauptspeicher kein Platz mehr ist. Dadurch kann ein System, das mit weniger RAM versorgt ist, als es für seine Aufgaben benötigt, mit zusätzlichem virtuellen RAM versorgt werden. Der Nachteil des Swap-Dateisystems ist, dass es im Vergleich zum eigentlichen RAM deutlich langsamer ist. Außerdem (aber das ist heutzutage oftmals unwichtig) verbraucht es durchaus einige hundert Megabyte der Festplattenkapazität. Swap-Dateisysteme werden auch verwendet, um System-Coredumps zu sichern.

Heutzutage installieren viele Anwender ihre Systeme ohne Swap-Speicher, da man fast immer genügend RAM zur Verfügung haben wird. Bei den heutigen Festplattenkapazitäten kann es jedoch kaum schaden, eine Swap-Partition mit beispielsweise 512 Megabyte anzulegen. Diese sollte dann in 95% der Fälle ausreichen. Die andere Möglichkeit besteht darin, keine Swap-Datei anzulegen und erst dann eine einzurichten, wenn man merkt, dass man doch eine benötigt.

Swap-Verschlüsselung

Verschlüsselung

Unter einigen Betriebssystemen ist es möglich, die Swap-Partition zu verschlüsseln, was einen erheblichen Vorteil bezüglich der Systemsicherheit mit sich bringt. Der Nachteil dieser Anwendung besteht in der Geschwindigkeitseinbuße.

Unter Linux wird dazu in der Datei /etc/fstab die Option encrypted gesetzt, sodass beim nächsten Mounten eine verschlüsselte Swap-Partition verwendet wird.

# cat /etc/fstab 
… 
/dev/hda4  swap  swap  encrypted  0  0 
…

Listing 26.8    Linux-Swap-Encryption

Unter OpenBSD wird mittels sysctl entweder manuell oder bei jedem Start automatisch in der sysctl.conf die Swap-Encryption mit dem Wert »1« eingestellt.

# cat /etc/sysctl.conf 
… 
vm.swapencrypt.enable=1 # 1 = Encrypt pages that go 
                        #     to swap 
…

Listing 26.9    OpenBSD-Swap-Encryption

NetBSD

Unter NetBSD muss zur Verschlüsselung der Swap-Partition der cgd (cryptographic disk driver) verwendet werden. Eine Anleitung dazu finden Sie unter www.netbsd.org/Documentation/misc/#cgd-swap.

Unter FreeBSD trägt man zur Swap-Verschlüsselung in die /etc/fstab an das Ende der Partitionsbezeichnung entweder das Kürzel .bde ein. Eine Mount-Zeile könnte somit folgendermaßen aussehen:

/dev/ad0s1c.bde  none  swap sw 0 0

Listing 26.10    Swap-Verschlüsselung unter FreeBSD

Bei einem Aufruf von swapinfo sollte dann ebenfalls die Endung .bde auftauchen.

26.2.6 DevFS 

Ältere Linux-Versionen verwendeten, wie Sie bereits aus Kapitel 1, »Der Kernel«, wissen, die standardmäßig im Verzeichnis /dev platzierten Gerätedateien, um die Hardwarekomponenten und Pseudo-Devices des Systems anzusprechen. Jede Hardwarekomponente erhielt dabei eine Major-Number, und deren weitere Instanzen jeweils eine Minor-Number. Um sich nicht mehr länger mit Hunderten von größtenteils unbenötigten Dateien herumschlagen zu müssen, die irgendwann einmal von MAKEDEV erzeugt wurden, führte man unter Linux das DevFS ein – ein echtes Pseudodateisystem.

Ein Pseudodateisystem ist kein »echtes« Dateisystem, da es keinem Datenträger zugrunde liegt. Stattdessen bietet der Kernel Zugriff auf bestimmte Features – wie eben Gerätetreiber – über das normale VFS-Interface an.

26.2.7 ProcFS 

Das Prozess- dateisystem

Das Prozessdateisystem ProcFS ist ein weiteres Pseudodateisystem und bildet während der Laufzeit ein Datei-Interface für alle laufenden Prozesse. Dieses Dateisystem wird in Normalfall unter /proc gemountet.

Das ProcFS stellt also dem Administrator und den Anwendungsprogrammen wichtige Informationen über das System bereit.

Dazu zählen viele wichtige Kernel-Parameter (diese lassen sich unter OpenBSD und NetBSD in der Regel mit sysctl, unter Solaris teilweise mit ndd konfigurieren und abfragen) und ganz besonders detaillierte Prozessinformationen.

Zu diesen Prozessinformationen zählen etwa die Programmdatei, der Zugriff auf den Programmspeicher und die Kommandozeile, mit der das Programm gestartet wurde. Viele Programme, wie etwa ps, greifen auf diese Informationen zu, um Ihnen Prozessinformationen liefern zu können.

26.2.8 NFS 

Das Network Filesystem, NFS, ist eine Entwicklung von SUNSoft, der wir bereits Kapitel 12.5 gewidmet haben.

Das Dateisystem ist unter allen gängigen Unix-Systemen verfügbar – meist sowohl als Kernelspace- als auch als Userspace-Implementierung. NFS macht ein zugrunde liegendes lokales Dateisystem – etwa UFS – im Netzwerk verfügbar. Dabei fungiert das System, auf dem die freigegebenen Daten lokal verfügbar sind, als NFS-Server. Die NFS-Clients greifen schließlich über das mittels RPC implementierte NFS-Protokoll auf den NFS-Server zu und können dank eines NFS-Treibers dieses entfernte Dateisystem lokal mounten.

26.2.9 Ecryptfs 

Mit der Veröffentlichung von Kernel 2.6.19 wurde ein neues Krypto-Dateisystem, das Ecryptfs, vorgestellt. Es stellt allerdings kein vollständiges Dateisystem zur Verfügung, da es auf anderen Dateisystemen aufbaut. Ecryptfs kümmert sich dabei einzeln um jede Datei. So können einzelne Dateien verschlüsselt werden, und andere können (beispielsweise aus Gründen der Performance oder des nicht notwendigen kryptographischen Schutzes) unverschlüsselt bleiben.

Die Entwickler von Ecryptfs sagen, es kombiniere die Flexibilität von GnuPG mit der Transparenz der Kernel-Quellen und sei durch seine einfache Handhabung massentauglich.

Um Ecryptfs zu benutzen, muss man die Kernel-Konfiguration entsprechend anpassen. Da zum Zeitpunkt des Schreibens der neue 2.6.19er-Kernel grad erst erschienen und ECRYPT_FS noch als »EXPERIMENTAL« markiert war, kompilierten wir es vorsichtshalber nur als Kernel-Modul. Mittlerweile kann es jedoch ohne Bedenken direkt in den Kernel kompiliert werden.

CONFIG_ECRYPT_FS=m

Listing 26.11    Konfigurationsvariable des Kernels

Nachdem man sich einen neuen Kernel gebaut hat, benötigt man nur noch die Tools des Ecryptfs, die von ecryptfs.sourceforge.net bezogen werden können. Falls sie noch nicht vorhanden sind, werden auch die keyutils benötigt, die man von people.redhat.com/~dhowells/keyutils/ bekommt.

Installiert wird auf die übliche Weise:

$ tar -xjvf keyutils-1.2.tar.bz2 
$ cd keyutils-1.2 
$ make 
... 
$ make install 
... 
$ tar -xjvf ecryptfs-utils-7.tar.bz2 
... 
$ cd ecryptfs-utils-7 
$ ./configure --prefix=/usr 
... 
$ make 
... 
$ make install

Listing 26.12    Ecryptfs Userspace-Tools installieren

Jetzt fängt der Spaß an: Da Ecryptfs kein vollständiges Dateisystem darstellt, müssen Sie auch keine Partition anlegen, sondern einfach ein Verzeichnis und dieses anschließend mounten. Zunächst sollte man aber noch einmal prüfen, ob das entsprechende Modul geladen ist.

$ lsmod | grep ecrypt 
ecryptfs               65488  0 
$ mkdir crypt 
$ sudo mount -t ecryptfs /home/swendzel/crypt \ 
/mnt/crypt 
Passphrase: 
Verify Passphrase: 
Cipher 
1) AES-128 
2) AES-192 
3) AES-256 
4) Blowfish 
5) CAST5 
6) CAST6 
7) Triple-DES 
8) Twofish 
Selection [AES-128]: 4 
Enable plaintext passthrough (y/n): n 
Attempting to mount with the following options: 
  ecryptfs_cipher=blowfish 
  ecryptfs_key_bytes=16 
  ecryptfs_sig=40c8cc3222813b8c 
Mounted ecryptfs 
$ mount | grep crypt 
/home/swendzel/crypt on /mnt/crypt type ecryptfs 
(rw,ecryptfs_sig=40c8cc3222813b8c,ecryptfs_key_ 
bytes=16,ecryptfs_cipher=blowfish,) 
$ cd /mnt/crypt 
$ echo "test" > test.txt

Listing 26.13    Mounten eines ecryptfs-Verzeichnisses

Nun versuchen Sie spaßeshalber einmal, /mnt/crypt zu unmounten und die Testdatei via Editor oder ähnlichem Tool auf dem Bildschirm anzuzeigen, um zu verifizieren, dass die Datei auch tatsächlich verschlüsselt worden ist.

26.2.10 Weitere Dateisysteme 

Der Vollständigkeit halber seien noch einige weitere wichtige Dateisysteme genannt:

• FAT16 und FAT32

• FAT16 und FAT32 sind die Standarddateisysteme älterer Windows-Versionen (NT ausgeschlossen) bis Windows 98/Windows Millenium.

• NTFS

• Das NTFS ist das Standarddateisystem von Windows NT, 2000, XP und 2003. Es verfügt im Gegensatz zu FAT32 unter anderem über die Möglichkeit, benutzerspezifische Zugriffsrechte zu setzen, außerdem wird Journaling genutzt.

• SMB/CIFS

• Das Netzwerkdateisystem aus der Windows-Welt. Unter Linux kann man mittels Samba darauf zugreifen.

Ihr Kommentar