28.2 Dateisysteme

Ausfallsicherheit

Im Master Boot Record einer Festplatte ist bekanntermaßen definiert, wie eine Festplatte partitioniert ist und welcher Typ den 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. Dies bedeutet, dass Veränderungen am Dateisystem protokolliert werden und dass so im Falle eines Systemabsturzes 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 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 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 ihnen 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 es in den Stable-Zweigen wichtiger Linux-Distributionen enthalten und weitet somit einige Beschränkungen 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. Es unterstützt Speichermedien mit bis zu 2⁶⁴ Bit, beinhaltet integrierte RAID-Unterstützung, Unterstützung für effiziente Backups und Kompression. Des Weiteren kann es mehrere Wurzelverzeichnisse verwalten. Die maximale Dateigröße beträgt 16 Exbibyte.

Subvolumes

In btrfs gibt es sogenannte Subvolumes, die als Wurzelverzeichnisse innerhalb eines btrfs-Dateisystems betrachtet werden können und sich in einem Pool befinden. 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 FUSE) für ZFS unter Linux. Native Linux-Unterstützung für ZFS ist in Arbeit. Bei ZFS handelt es sich um ein 128-Bit-Dateisystem, das von Sun Microsystems entwickelt wurde. Mit ZFS können mehrere physische 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 dabei um ein Kernelmodul, das ein virtuelles 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 auch. Im Hintergrund werden diese Zugriffe allerdings umgeleitet, so dass 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.

Listing 28.1 wikipediafs verwenden

# 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

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 [Fn. 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. [Fn. 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. Es wird von FreeBSD und von NetBSD unterstützt. OpenBSD kann UFS2 seit Version 4.3 handhaben. Mit Solaris 7 wurde UFS auch Journaling-fähig gemacht. [Fn. 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. [Fn. Siehe http://de.wikipedia.org/wiki/Softupdates] Am besten funktionieren SoftUpdates, wenn der Schreib-Cache abgestellt ist, was bei IDE-Festplatten durchaus spürbare Performanceeinbußen bewirken kann, bei SCSI-Platten jedoch relativ problemlos funktioniert.

Da im Falle eines Absturzes trotzdem Fehler in Form von Blöcken, die frei, 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, 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.

Listing 28.2 Eine CD unter Linux mounten

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

Listing 28.3 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)

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.

Listing 28.4 Erzeugen der Raw-Datei

# 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

Dateisystem erzeugen

Auf dieser Datei wird anschließend ein Dateisystem – in unserem Fall vom Typ ext2 – erzeugt. Dabei werden 1024 Bytes pro Inode (-i) bei einer Blockgröße von 1024 Bytes pro Block verwaltet. Ein Inode entspricht nun also genau einem Block, was vor allem bei kleineren Dateisystemen sinnvoll ist. Zudem entscheiden wir uns, drei Prozent [Fn. 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.

Listing 28.5 Dateisystem erzeugen

# 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.

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:

Listing 28.6 losetup und mount

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

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

Listing 28.7 Eine Datei direkt mounten

# 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

Und das Ganze mit dem RAM

Ein Dateisystem können Sie auch im Hauptspeicher anlegen, zum Beispiel, um für zeitkritische Anwendungen Performanceverluste aufgrund langer Plattenzugriffe zu vermeiden. Das Ganze nennt sich dann Ramdisk und läuft über die Datei /dev/ram:

Listing 28.8 RAM-Device

# 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/sda1        3.7G 1.5G  2.1G  30 % /
/dev/ram0        7.4M  13k  6.9M   1 % /mnt/ramdisk

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. In ihm 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 [Fn. Der Begriff des Coredumps wird in Abschnitt Coredump näher erläutert.] 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 gegebenenfalls erst dann 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 wird, 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 der Auslagerungsspeicher, der später 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.

Listing 28.9 Anlegen einer leeren Datei (8 MByte)

# 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

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.

Listing 28.10 Erstellen einer Swap-Area

# 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

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.

Listing 28.11 Swap aktivieren und anzeigen

# swapon /swapfile
# cat /proc/swaps
Filename     Type  Size      Used Priority
/swapfile    file  8188   0    –2

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 ein Swapfile nach dessen 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 besteht in der Geschwindigkeitseinbuße.

Zur Verschlüsselung der Swap-Partition setzen Sie unter Linux in der Datei /etc/fstab die Option encrypted, so dass beim nächsten Mounten eine verschlüsselte Swap-Partition verwendet wird.

Listing 28.12 Linux-Swap-Encryption

# cat /etc/fstab | grep encrypted
/dev/sda4  swap  swap  encrypted  0  0

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

Listing 28.13 OpenBSD-Swap-Encryption

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

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:

Listing 28.14 Swap-Verschlüsselung unter FreeBSD

/dev/ad0s1c.bde  none  swap sw 0 0

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 Prozessdateisystem

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. Hierzu 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 Sun Microsystems, der wir bereits Abschnitt abschnittNFS gewidmet haben. Es 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 ggf. entsprechend anpassen:

Listing 28.15 Konfigurationsvariable des Kernels: EcryptFS als Modul kompilieren

CONFIG_ECRYPT_FS=m

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.

Listing 28.16 Mounten eines ecryptfs-Verzeichnisses

$ 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

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 Millennium.
• 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.

Ihr Kommentar

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