28.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. |
28.2.1 ext2, ext3, ext4 und reiserfs 

Die Standard- dateisysteme
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 diese Inkonsistenz 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.
ext4
Als Nachfolger des ext3-Dateisystems wurde ext4 entwickelt. Seit 2009 ist ext4 in den Stable-Zweigen wichtiger Linux-Distributionen enthalten und erweitert somit einige Grenzen des Vorgänger-Dateisystems. ext4 unterstützt Dateisysteme bis zu einer Größe von einem Exabyte sowie Nanosekunden genaue Timestamps für Dateien. Außerdem sind mit ext4 eine größere Anzahl an Unterverzeichnissen pro Verzeichnis möglich. Vorhandene ext3-Dateisysteme können direkt in ext4-Dateisysteme umgewandelt 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.
28.2.2 btrfs und ZFS 

Seit 2007 wird das Dateisystem btrfs (engl. binary tree file system) von Oracle entwickelt, das möglicherweise einmal das Standarddateisystem für Linux werden könnte. btrfs unterstützt Speichermedien mit bis zu 264 Bit, beinhaltet integrierte RAID-Unterstützung, Unterstützung für effiziente Backups und Kompression. Des Weiteren kann btrfs mehrere Wurzelverzeichnisse verwalten. Die maximale Dateigröße beträgt 16 Exbibyte.
Subvolumes
In btrfs gibt es sogenannte Subvolumes, diese können als Wurzelverzeichnisse innerhalb eines btrfs-Dateisystems betrachtet werden und befinden sich in einem Pool. In der Dokumentation von btrfs wird ein Subvolume mit einem kompletten ext4-Dateisystem gleichgesetzt. Jedes Subvolume in btrfs verhält sich entsprechend wie ein eigenes Dateisystem.
zfs
Da wir uns in diesem Buch am Rande auch mit BSD auseinandersetzen, sollen noch einige Worte zum Solaris-ZFS-Dateisystem gesagt werden, das es auch unter FreeBSD gibt. ZFS wird nicht direkt vom Linuxkernel unterstützt, allerdings gibt es mittlerweile einen FUSE-basierten Ansatz (mehr dazu in Abschnitt 28.2.3) für ZFS unter Linux. Native Linux-Unterstützung für ZFS ist allerdings in Arbeit. Bei ZFS handelt es sich um ein 128-Bit-Dateisystem, das von SUN Microsystems entwickelt wurde. Für ZFS können mehrere physikalische Speicher zu virtuellen Pools (dahinter steckt das sogenannte pooled storage model) zusammengesetzt werden. Ein Pool kann, wie bei btrfs, mehrere Dateisysteme enthalten und deren Größe kann dynamisch verändert werden.
28.2.3 FUSE – Filesystem in Userspace 

Die Abkürzung FUSE steht für Filesystem in Userspace, also zu deutsch etwa »Dateisystem im Userspace«. Es handelt sich bei FUSE um ein Kernelmodul, das ein virtuelles FUSE-Dateisystem für unprivilegierte Benutzer ermöglicht. Solche virtuellen FUSE-Dateisysteme sind zum einen nicht mit dem VFS zu verwechseln, das bisher besprochen wurde, da jenes VFS alle Dateisysteme enthält, und zweitens kümmert sich ein virtuelles FUSE-Dateisystem nicht direkt um die Datenspeicherung, da es auf einem anderen Dateisystem aufsetzt.
Ein FUSE-Dateisystem stellt vielmehr eine Abstraktionsebene dar: Ein Programm kann mit den normalen Syscalls (etwa read(), write(), close() oder open()) auf ein FUSE-Dateisystem zugreifen, wie auf jedes andere Dateisystem auch. Im Hintergrund werden diese Zugriffe allerdings umgeleitet, sodass andere Aktionen durchgeführt werden, von denen der Anwender und auch das zugreifende Programm nichts mitbekommen (die Zugriffe sind also transparent).
wikipediafs
Als Beispiel für ein FUSE-Dateisystem soll hier das wikipediafs genannt sein. Dieses Dateisystem können Sie (sofern die Unterstützung dafür installiert ist) lokal einhängen und über den Dateizugriff auf diesem Dateisystem Wikipedia-Dateien editieren (natürlich im Quellcode). Im Hintergrund laufen dabei transparent Netzwerkzugriffe auf die Wikipedia ab. Auch sehen Sie in Ihrem wikipediafs keine Dateien von Wikipedia-Artikeln, die Sie noch nicht geladen haben.
# mount.wikipediafs /media/wikipedia # cd /media/wikipedia # ls mblondel.org # mkdir wikipedia-de # ls wikipedia-de # cat wikipedia-de/Linux.wm ... # ls wikipedia-de Linux.wm
Listing 28.1 wikipediafs verwenden
28.2.4 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 noch 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ützen, journaling-fähig. UFS2 wird von FreeBSD und von NetBSD unterstützt. OpenBSD kann UFS2 seit Version 4.3 handhaben. 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. [Siehe http://de.wikipedia.org/wiki/Softupdates] Am besten funktionieren SoftUpdates, wenn der Schreib-Cache abgestellt ist, was bei IDE-Festplatten durchaus spürbare Performanceinbußen bewirken kann, bei SCSI-Platten jedoch relativ problemlos funktioniert.
Da im Falle eines Absturzes trotzdem Fehler auftreten können, und zwar in Form von Blöcken, die frei, jedoch noch als belegt markiert sind, 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, wo man fsck im Hintergrund laufen lassen kann.
28.2.5 ISO 9660 

Das iso9660-Dateisystem, unter BSD auch als cd9660 bezeichnet, stellt ein 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 [Eine CD unter OpenBSD mounten] openbsd# mount_cd9660 /dev/cd0a /mnt/cdrom openbsd# mount | grep cd0a /dev/cd0a on /mnt/cdrom type cd9660 (local, read-only)
Listing 28.2 Eine CD unter Linux mounten
28.2.6 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. Dies ist notwendig, da das Kommando 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 solch ein Loop-Device mounten.
Doch wie erstellt man selbst eine solche Gerätedatei? Im Prinzip ist dies relativ einfach: Zuerst erstellen wir mit dem dd-Programm eine Datei beliebiger Größe. Die gewählte Größe entspricht anschließend der Größe der fertigen Dateipartition. 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 – irgend- einen 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 28.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 sinnvoll ist. Zudem entscheiden wir uns, drei Prozent [Der Standardwert beträgt 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 oder mit dem Parameter -F 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 28.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 28.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 /root/filefs.img Filesystem Size Used Avail Use% Mounted on /root/filefs.img 26M 13M 13M 48% /loop
Listing 28.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 aufgrund langer Plattenzugriffe zu vermeiden. Das Ganze nennt sich dann Ramdisk und läuft über die Datei /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 28.7 RAM-Device
28.2.7 Swap 

Auslagerungsspeicher
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.
Heute 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, zunächst keine Swap-Datei anzulegen und erst dann gegebenenfalls eine einzurichten, wenn man merkt, dass man doch eine benötigt.
Anlegen einer Swap-Datei
Während für Swap-Dateisysteme eine ganze Partition herhalten muss, und diese meist per Mausklick bei der Installation angelegt werden, ist die Erstellung von Swap-Dateien – sofern das System zunächst einmal läuft – einfacher. Swap-Dateien können schnell bei Bedarf angelegt werden und es benötigt dazu nur wenige Befehle. Zunächst muss eine Datei erstellt werden, die so groß sein muss, wie später Auslagerungsspeicher zur Verfügung stehen soll. Die Minimalgröße für eine solche Datei beträgt meist 40 KByte. In unserem Beispiel legen wir mit dd eine 1024*8196 MByte (=8 MByte) große Datei /swapfile an und füllen Sie mit Nullwerten, die wir direkt aus /dev/zero lesen.
# dd if=/dev/zero of=/swapfile bs=1024 count=8196 8196+0 Datensätze ein 8196+0 Datensätze aus 8392704 Bytes (8,4 MB) kopiert, 0,0478992 s, 175 MB/s
Listing 28.8 Anlegen einer leeren Datei (8 MByte)
Nun muss in dieser Datei eine Swap-Area erstellt werden, was mit mkswap erledigt wird. mkswap kann sowohl in einzelnen Dateien als auch auf Partitionen eine Swap-Area erstellen.
# mkswap /swapfile mkswap: /swapfile: warning: don't erase bootbits sectors on whole disk. Use -f to force. Setting up swapspace version 1, size = 8192 KiB kein Label, UUID=6b75d027-9c5f-4bb8-bec6-f46dbd0dbe2f
Listing 28.9 Erstellen einer Swap-Area
Nach der Erstellung der Swap-Area muss die Swap-Partition noch in Betrieb genommen werden. Dazu verwenden Sie den Befehl swapon /swapfile. Anschließend sollte unter Linux ein entsprechender Eintrag in /proc/swaps zu finden sein.
# swapon /swapfile # cat /proc/swaps Filename Type Size Used Priority /swapfile file 8188 0 –2
Listing 28.10 Swap aktivieren und anzeigen
Natürlich kann für die Swap-Datei auch ein Eintrag in der /etc/fstab erzeugt werden, womit diese automatisch beim Systemstart aktiviert wird.
Unter OpenBSD und NetBSD aktivieren Sie die Swap-Datei nach ihrer Erstellung mit swapctl -a /swapfile. Überprüfen können Sie das Ergebnis mit swapctl -l. Um die Swap-Datei dauerhaft beim Start automatisch zu aktivieren, empfehlen wir Ihnen, einen Eintrag in der Datei /etc/fstab zu erstellen.
Unter FreeBSD muss für eine Swapfile nach deren Erstellung ein Eintrag in /etc/rc.conf der Form swapfile="/swapfile" erstellt werden. Die Aktivierung der Swap-Datei erfolgt nach einem Neustart.
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.
Zur Verschlüsselung der Swap-Partition setzen Sie unter Linux in der Datei /etc/fstab die Option encrypted, sodass beim nächsten Mounten eine verschlüsselte Swap-Partition verwendet wird.
# cat /etc/fstab | grep encrypted /dev/hda4 swap swap encrypted 0 0
Listing 28.11 Linux-Swap-Encryption
Unter OpenBSD stellen Sie mittels sysctl entweder manuell oder bei jedem Start automatisch in der sysctl.conf die Swap-Encryption mit dem Wert »1« ein.
# cat /etc/sysctl.conf ... vm.swapencrypt.enable=1 # 1 = Encrypt pages that go # to swap ...
Listing 28.12 OpenBSD-Swap-Encryption
NetBSD
Unter NetBSD muss zur Verschlüsselung der Swap-Partition der Treiber cgd (cryptographic disk driver) verwendet werden. Eine Anleitung dazu finden Sie hier: 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 das Kürzel .bde ein. Eine Mount-Zeile könnte somit folgendermaßen aussehen:
/dev/ad0s1c.bde none swap sw 0 0
Listing 28.13 Swap-Verschlüsselung unter FreeBSD
Bei einem Aufruf von swapinfo sollte dann ebenfalls die Endung .bde auftauchen.
28.2.8 DevFS und udev 

Ältere Linux-Versionen verwendeten, wie Sie bereits aus Kapitel 5, »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 Pseudo-Dateisystem.
Ein Pseudo-Dateisystem 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. |
Heute wird im Kernel statt DevFS das Programm udev eingesetzt.
28.2.9 ProcFS 

Das Prozess- dateisystem
Das Prozessdateisystem ProcFS ist ein weiteres Pseudo-Dateisystem und bildet während der Laufzeit ein Datei-Interface für alle laufenden Prozesse. Dieses Dateisystem wird im Normalfall unter /proc gemountet.
Das ProcFS stellt 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 vor allem detaillierte Prozessinformationen. Zu diesen Prozessinformationen zählen zum Beispiel die Programmdatei, der Zugriff auf den Programmspeicher und die Kommandozeile, mit der das Programm gestartet wurde. Viele Programme, wie zum Beispiel ps, greifen auf diese Informationen zu, um Ihnen Prozessinformationen liefern zu können.
28.2.10 NFS 

Das Network Filesystem (NFS) ist eine Entwicklung von SUNSoft, der wir bereits Abschnitt 17.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.
28.2.11 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 einzeln um jede Datei. So können einzelne Dateien verschlüsselt werden, und andere können (etwa aus Gründen der Performance oder des nicht notwendigen kryptografischen Schutzes) unverschlüsselt bleiben.
Den Aussagen seiner Entwickler zufolge kombiniert das Ecryptfs die Flexibilität von GnuPG mit der Transparenz der Kernel-Quellen und ist 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 gerade erst erschienen und ECRYPT_FS noch als EXPERIMENTAL markiert war, kompilierten wir es im Folgenden vorsichtshalber nur als Kernel-Modul. Mittlerweile kann es jedoch ohne Bedenken direkt in den Kernel kompiliert werden.
CONFIG_ECRYPT_FS=m
Listing 28.14 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 diese Tools noch nicht vorhanden sind, werden auch die keyutils benötigt, die man von people.redhat.com/dhowells/keyutils/ bekommt. Sie installieren diese Tools wie gewohnt:
$ 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 28.15 Ecryptfs Userspace-Tools installieren
Jetzt fängt der Spaß an: Da Ecryptfs kein vollständiges Dateisystem darstellt, müssen Sie auch keine Partition anlegen; Sie legen einfach ein Verzeichnis an und mounten dieses anschließend. Zunächst sollten Sie 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 28.16 Mounten eines ecryptfs-Verzeichnisses
Nun versuchen Sie spaßeshalber einmal, /mnt/crypt zu unmounten und die Testdatei via Editor oder mit einem ähnlichen Tool auf dem Bildschirm anzuzeigen, um zu verifizieren, dass die Datei auch tatsächlich verschlüsselt worden ist.
28.2.12 Weitere Dateisysteme 

Der Vollständigkeit halber führen wir noch einige weitere wichtige Dateisysteme auf:
- 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
SMP/CIFS ist das Netzwerkdateisystem aus der Windows-Welt. Unter Linux kann man mittels Samba darauf zugreifen.