404 lines
21 KiB
TeX
404 lines
21 KiB
TeX
% <#>---------------------------------------------------------------------------<#>
|
|
\section{Dateisysteme}%
|
|
\label{sec:dateisysteme}
|
|
|
|
Je nach Kernel werden unterschiedliche Dateisysteme unterstützt. Bekannt von
|
|
Windows ist Ihnen bestimmt das \acrfull{acr:ntfs}. Linux unterstützt im
|
|
Gegensatz zum Windows NT Kernel nicht nur ein oder zwei Dateisysteme sondern
|
|
eine große Vielzahl, beispielsweise \acrshort{acr:ext3}, \acrshort{acr:ext4},
|
|
\acrshort{acr:btrfs}, \acrshort{acr:eCryptfs}, \acrshort{acr:reiser} oder XFS.
|
|
|
|
Jedes Dateisystem hat Stärken und Schwächen. Aus diesem Grund werden nicht alle
|
|
Dateisysteme detailiert betrachtet, sondern ausschließlich \acrshort{acr:btrfs},
|
|
welches für Fedora 33 als Standard Dateisystem angekündigt
|
|
ist\footcite{fedora33-btrfs-default} als auch kleinere Dateisysteme, welche
|
|
nicht direkt eine physische oder virtuelle Festplatte vorraussetzen.
|
|
|
|
% #>-------------------------------------------------------------------------<#
|
|
\subsection{BtrFS}%
|
|
\label{sec:dateisysteme.btrfs}
|
|
|
|
Das \acrshort{acr:btrfs} Dateisystem ist ein \acrlong{acr:cow} Dateisystem.
|
|
\acrshort{acr:cow} bedeutet, dass für Dateien, welche kopiert werden, nicht der
|
|
selbe Speicherplatz anfällt. Sie werden stattdessen nur referenziert. Dies hat
|
|
den Vorteil, das Speicherplatz eingespart werden kann. Im Umfeld von
|
|
systemorierntierten Programmiersprachen wie C, Rust oder Go, kann dies mit dem
|
|
Konzept von Pointern verglichen werden. Wobei statt Speicheradressen die
|
|
Dateisystemblöcke referenziert werden, welche die Datei im Dateisystem abbilden.
|
|
|
|
\acrshort{acr:btrfs} bietet mehrere Funktionen an, welche in dem Umfang kein
|
|
anderes Dateisystem anbietet. Hier einige Informationen über \acrshort{acr:btrfs}:
|
|
|
|
\begin{itemize}[itemsep=0pt]
|
|
\item Dynamisch wachsende Inodes
|
|
\item Verwaltung von Subvolumes
|
|
\item Erstellung von Snapshots pro Subvolume
|
|
\item Datenkompression auf Dateisystemebene
|
|
\item Dateisystemcheck und Defragmentierung während des Betriebs
|
|
\item Prüfsummenbasiert
|
|
\item Integrierte \acrshort{acr:raid} option, wobei nur \acrshort{acr:raid} 0
|
|
und 1 als stabil zu betrachten sind
|
|
\end{itemize}
|
|
|
|
% >---------------------------------------------------------------------------<
|
|
\subsubsection{Was ist genau BtrFS}%
|
|
\label{sec:dateisysteme.btrfs.erklaerung}
|
|
|
|
Eine \acrshort{acr:btrfs}-Partition stellt eine Volume dar, welches in mehrere
|
|
Subvolume unterteilt werden kann. Subvolumes stehen in ihrer Eigenschaft
|
|
zwischen Partitionen und Verzeichnissen. Partitionen haben eine feste Größe,
|
|
Subvolumes nicht, außer sie werden durch Quotas limitiert. Daher verhalten sich
|
|
Subvolumes ähnlich wie Verzeichnisse.
|
|
|
|
Im Verzeichnisbaum des Systems werden Subvolumes automatisch als Ordner
|
|
eingehängt. In Ubuntu-Derivaten und OpenSUSE hat es sich eingebürgert
|
|
Top-Level-Subvolumen mit einem vorangestellten \textit{@} zu benennen. Dies ist
|
|
eine reine Konvention unter den Nutzern dieser Linux-Derivate und formell nicht
|
|
nötig. Subvolumen bedürfen keiner speziellen Nomenklatur. Es ist sogar
|
|
hinderlich, da jedes Subvolumen welches anders heißt als wie vom System erwartet
|
|
explizit eingehängt werden muss.\footcite{was-ist-btrfs}
|
|
|
|
\acrshort{acr:btrfs} erlaubt zudem das Erstellen von Snapshots. Snapshots
|
|
representieren eine Momentaufnahme eines Subvolumes. Snapshots müssen auf der
|
|
selben \acrshort{acr:btrfs} Partition gespeichert werden wie das Subvolume.
|
|
Enthält ein Subvolume einen Snapshot, enthält der Snapshot nicht rekursiv alle
|
|
Snapshots, welche zum Zeitpunkt der Erstellung vorhanden waren. Da Snapshots
|
|
Momentaufnahmen sind, können diese sehr leicht zurück gespielt werden. Hier ist
|
|
allerdings zu beachten, dass ein Snapshot kein Backup im eigentlichen Sinne ist.
|
|
Backups werden auf physisch getrennte Geräte gespeichert, was bei Snapshots
|
|
nicht der Fall ist.
|
|
|
|
Dateien und Verzeichnisse, welche durch einen Snapshot kopiert werden, belegen
|
|
nicht zusätzlichen Speicherplatz. Sie werden nur von ein oder mehreren Quellen
|
|
referenziert. Folgende Abbildung beschreibt den Prozess und die Referenzierung:
|
|
|
|
\begin{figure}[H]
|
|
\centering
|
|
\includegraphics[width=1\textwidth]{img/btrfs-cow.png}
|
|
\caption{Referenzierung von Speicherblöcken}%
|
|
\label{fig:dateisysteme.btrfs.referenzierung-von-speicherbloecken}
|
|
\end{figure}
|
|
|
|
Erst wenn alle Referenzen gelöscht sind können die Dateisystemblöcke
|
|
überschrieben werden.
|
|
|
|
% >---------------------------------------------------------------------------<
|
|
\subsubsection{Step-By-Step}%
|
|
\label{sec:dateisysteme.btrfs.step-by-step}
|
|
|
|
Mit dem Befehl \textit{mkfs.btrfs} kann eine \acrshort{acr:btrfs} Dateisystem
|
|
auf einer leeren Partition erstellt werden. Mit dem Befehl \textit{parted} oder
|
|
\textit{fdisk} lassen sich Partitionen einer Festplatte bearbeiten,
|
|
beispielsweise um neue zu erstellen, zu löschen oder deren Größe anzupassen.
|
|
|
|
Bei der Erstellung eines \acrshort{acr:btrfs} Dateisystems wird zwischen Daten
|
|
und Metadaten unterschieden. Bei Daten handelt es um die Daten welche auf der
|
|
Festplatte gespeichert werden. Metadaten enthalten dagegen Informationen, welche
|
|
Datei durch welches Subvolume oder Snapshot referenziert wird. Für beide
|
|
Informationsträgertypen kann zwischen mehreren Profilen unterschieden werden. Es
|
|
können Beispielsweise die Daten auf einem \acrshort{acr:raid}-0 und die
|
|
Metadaten auf einem \acrshort{acr:raid}-1 gespeichert werden. Je nach
|
|
Einsatzszenario kann ein vordefiniertes Profil bei der Erstellung verwendet
|
|
werden. Das verwendete Profil lässt sich nachträglich nicht mehr ändern.
|
|
|
|
Neben den Profilen lassen sich auch weitere Informationen für die
|
|
\acrshort{acr:btrfs} Partition definieren. Beispielsweise das Label oder die
|
|
UUID.
|
|
|
|
\begin{itemize}[label={},itemsep=0pt]
|
|
\item \textbf{Aufgabe 1a:} Binden Sie über ihren HyperVisor (HyperV,
|
|
\acrshort{acr:kvm} oder Virtual Box) zwei neue virtuelle Festplatten an ihre
|
|
VM. Beide virtuelle Festplatten sollen eine Größe von 5GB besitzen. Starten
|
|
Sie, nachdem Sie die virtuellen Festplatten der VM zugewiesen haben, die
|
|
Virtuelle Maschine und überprüfen Sie mit \textit{lsblk} (list block devices),
|
|
ob beide virtuelle Festplatten durch ihre VM erkannt wurden.
|
|
\item \textbf{Aufgabe 1b:} Welche unterschiedlichen Profile werden von dem
|
|
\acrshort{acr:btrfs} Dateisystem unterstützt?
|
|
\item \textbf{Aufgabe 1c:} Erstellen Sie eine neue Partition mit dem
|
|
Partitionsschema \textit{msdos}. Nutzen Sie zur Partitionierung entweder
|
|
\textit{parted} oder \textit{fdisk}.
|
|
\item \textbf{Aufgabe 1d:} Richten Sie ein neues \acrshort{acr:btrfs}
|
|
Dateisystem ein. Verwenden Sie dazu die beiden virtuellen Festplatten. Die
|
|
Daten als auch Metadaten sollen als \acrshort{acr:raid}-1 vor einem
|
|
Festplattenausfall geschützt werden. Verwenden Sie als Label
|
|
\textit{btrfs-raid-1}.
|
|
\end{itemize}
|
|
|
|
Physische als auch virtuelle Geräte können an unterschiedlichen Stellen im
|
|
Verzeichnisbaum eingebunden werden. Zum Einbinden eines Gerätes in den
|
|
Verzeichnisbaum wird der Befehl \textit{mount} verwendet. Die allgemeine Syntax
|
|
lautet:
|
|
|
|
\begin{bashcode}
|
|
$ mount [-t <typ>, -o <option>] <dev> <mountpoint>
|
|
|
|
# Beispiel, um die Partition vdb1 der virtuellen Festplatte /dev/vdb nach /mnt/vbd1 zu "mounten".
|
|
$ mount /dev/vdb1 /mnt/vdb1
|
|
\end{bashcode}
|
|
|
|
Weitere Informationen zum Einbinden von Geräten finden Sie in der Dokumentation:
|
|
\textit{man mount}.
|
|
|
|
\begin{itemize}[label={},itemsep=0pt]
|
|
\item \textbf{Aufgabe 2a:} Erstellen Sie das Verzeichnis \textit{/mnt/btrfs}.
|
|
\item \textbf{Aufgabe 2b:} Ermitteln Sie, was die Optionen \textit{rw},
|
|
\textit{noatime}, \textit{compress}, \textit{ssd}, \textit{space\_cache} und
|
|
\textit{subvol} bedeutet, welche beim Einbinden eines \acrshort{acr:btrfs}
|
|
Dateisystems verwendet werden können.
|
|
\item \textbf{Aufgabe 2c:} Binden Sie das \acrshort{acr:btrfs}
|
|
\acrshort{acr:raid} Dateisystem unter \textit{/mnt/btrfs} ein. Entscheiden Sie
|
|
selbst, welche Optionen für Sie relevant sind.
|
|
\end{itemize}
|
|
|
|
Nach einem Neustart des Systems ist das \acrshort{acr:btrfs} Dateisystem nicht
|
|
mehr eingebunden. Sie müssen das Einbinden des Dateisystems per \textit{mount}
|
|
wiederholen oder einen Eintrag in die Datei \textit{/etc/fstab} vornehmen. Dazu
|
|
ermitteln Sie am besten per \textit{blkid} die UUID ihrer btrfs-raid Partition
|
|
und verweden diese in der \textit{fstab}, um die Partition automatisch nach
|
|
einem Neustart einzubinden. Weitere Informationen finden Sie unter folgendem
|
|
\href{https://wiki.archlinux.de/title/Fstab}{Link}.
|
|
|
|
Wie bereits in Kapitel \ref{sec:dateisysteme.btrfs.erklaerung} beschrieben
|
|
untersützt das \acrshort{acr:btrfs} Dateisystem Subvolumes. Auf dem kürzlich
|
|
erstellten \acrshort{acr:btrfs} \acrshort{acr:raid} Dateisystem sollen zukünftig
|
|
Bilder, Musiktitel, Podcasts und Videos gespeichert werden.
|
|
|
|
\begin{itemize}[label={},itemsep=0pt]
|
|
\item \textbf{Aufgabe 3a:} Erstellen Sie für die Bilder, Musiktitel, Podcasts
|
|
und Videos ein Subvolume auf dem neuen \acrshort{acr:btrfs}
|
|
\acrshort{acr:raid} Dateisystem.
|
|
\item \textbf{Aufgabe 3b}: Überprüfen Sie, ob die Subvolumes erkannt wurden.
|
|
\item \textbf{Aufgabe 3c:} Löschen Sie das Subvolume Podcasts.
|
|
\item \textbf{Aufgabe 3d:} Erstellen Sie unterhalb der verbleibenden
|
|
Subvolumes das Verzeichnis \textit{.snapshots}.
|
|
\end{itemize}
|
|
|
|
Nachdem Sie nun die drei Subvolumes mit dem Unterverzeichnis \textit{.snapshots}
|
|
erstellt haben kommen wir an den Punkt Snapshots zu erstellen. Snapshots sind
|
|
Grundsätzlich nichts anderes als Subvolumes. Sie referenzieren auf die gleichen
|
|
Dateien, welches sich zum Zeitpunkt des Snapshots im Subvolume befanden. Die
|
|
Dateien innerhalb eines Snapshots lassen sich bearbeiten und modifizieren ohne
|
|
dabei die Dateien innerhalb des Subvolumes zu beeinträchtigen. Dies ist jedoch
|
|
nicht immer gewünscht, da dadurch ein Snapshot nicht mehr der Momentaufnahme
|
|
entspricht. Aus diesem Grund kann das nachträgliche Editieren von Dateien
|
|
innerhalb eines Snapshots unterbunden werden.
|
|
|
|
\begin{itemize}[label={},itemsep=0pt]
|
|
\item \textbf{Aufgabe 4a:} Erstellen Sie einen \textit{read-only} Snapshot von
|
|
jedem Subvolume, um ein nachträgliches Editieren von Dateien in den Snapshots
|
|
zu unterbinden. Speichern Sie den Snapshot in das Verzeichnis
|
|
\textit{.snapshots} des jeweiligen Subvolumes mit dem Namensschema
|
|
\textit{$<nameSubvolume>.<jahr><monat><tag>T<stunde><minute>$} ab.
|
|
\item \textbf{Aufgabe 4b:} Überprüfen Sie, ob die Snapshots als Subvolumes
|
|
erkannt wurden.
|
|
\item \textbf{Aufgabe 4c:} Löschen Sie das Subvolume von dem Sie einen
|
|
Snapshot erstellt haben.
|
|
\item \textbf{Aufgabe 4d:} Stellen Sie mithilfe des Snapshots das Subvolume
|
|
wieder her.
|
|
\end{itemize}
|
|
|
|
Nun, ein Snapshot ist kein Backup. Ein Backup ist die Sicherung eines Zustands
|
|
auf einem anderen physischen Gerät, beispielsweise einer zweiten angeschlossenen
|
|
Festplatte oder einem entfernten System. Um ein Backup zu erstellen enthält das
|
|
Programm \textit{btrfs} den Unterbefehl \textit{send}. Damit kann ein Snapshot
|
|
in eine Datei exportiert werden. Neben dem Unterkommando \textit{send} enthält
|
|
es unter anderem auch das Unterkommando \textit{receive}, um Snapshots aus einer
|
|
Datei zu importieren.
|
|
|
|
\begin{itemize}[label={},itemsep=0pt]
|
|
\item \textbf{Aufgabe 5a:} Exportieren Sie einen kürzlich erstellten Snapshot
|
|
per \textit{btrfs send} in eine Datei.
|
|
\item \textbf{Aufgabe 5b:} Löschen Sie den Snapshot.
|
|
\item \textbf{Aufgabe 5c:} Stellen Sie den gesicherten Snapshot aus der Datei
|
|
wieder her.
|
|
\item \textbf{Aufgabe 5d:} Kopieren Sie per \textit{scp} von dem SSH-Server
|
|
der Hochschule die Datei
|
|
\textit{/dozenten/peschm/linux\_ws2021/videos.20201027T223646.snapshot} in
|
|
ihre VM. Spielen Sie den Snapshot unter dem Subvolume \textit{videos} wieder
|
|
ein. Schauen Sie sich das darin enthaltene Video an ;) Eventuell muss das
|
|
Video auf ein anderes System kopiert werden, da ihre VM keinen Mediaplayer
|
|
besitzt.
|
|
\end{itemize}
|
|
|
|
Die Snapshots können nun durch ein Skript erstellt und gelöscht werden, als auch
|
|
das letzte Backup auf ein entferntes System oder eine zweite Festplatte
|
|
exportiert werden. Doch warum sollte man sich die Arbeit machen solch ein Skript
|
|
zu erstellen, wenn andere bereits ein Program daraus gemacht haben.
|
|
|
|
Mit dem Programm \textit{btrbk} können Snapshots und Backups je nach Szenario
|
|
verwaltet werden. Der Quellcode des Programms ist auf
|
|
\href{https://github.com/digint/btrbk}{github.com} verfügbar, dort sind neben
|
|
den Konfigurationsoptionen auch mögliche Szenarien, welche das Programm abdeckt,
|
|
beschrieben.
|
|
|
|
\begin{itemize}[label={},itemsep=0pt]
|
|
\item \textbf{Aufgabe 6a:} Installieren Sie das Programm \textit{btrbk} mit
|
|
\textit{yum}.
|
|
\item \textbf{Aufgabe 6b:} Informieren Sie sich über die \textit{README.md}
|
|
Datei, welche möglichen Szenarien durch \textit{btrbk} abgedeckt werden.
|
|
\item \textbf{Aufgabe 6c:} Konfigurieren Sie \textit{btrbk}, dass von den
|
|
Subvolumes Bilder, Musiktitel und Videos stündlich ein Snapshot in das
|
|
jeweilige \textit{.snapshots} Verzeichnis erstellt wird. Eine
|
|
Beispielkonfiguration liegt unter \textit{/etc/btrbk}. Weitere Informationen
|
|
finden Sie in der ausführlich dokumentierten
|
|
\href{https://digint.ch/btrbk/doc/archive/}{Dokumentation}.
|
|
\item \textbf{Aufgabe 6d:} Passen Sie die Konfiguration so an, dass die
|
|
Snapshots der folgenden Ausbewahrungsrichtlinie entspricht. Die letzen 24
|
|
stündliche, 14 tägliche, 4 wöchentliche, 12 monatliche und jährliche Snapshots
|
|
sollen behalten werden, um dem Großvater-Vater-Kind Prinzip zu entsprechen.
|
|
\item \textbf{Aufgabe 6e:} Passen Sie ggfl. das Namensschema der Snapshots an,
|
|
sodass es dem Namensschema von Aufgabe 4a entspricht.
|
|
\item \textbf{Aufgabe 6f:} Starten Sie \textit{btrbk} per \textit{btrbk run -c
|
|
/etc/btrbk/btrbk.conf run} und überprüfen Sie in der Ausgabe als auch im
|
|
Dateisystem, ob die Snapshots erstellt wurden.
|
|
\end{itemize}
|
|
|
|
% #>-------------------------------------------------------------------------<#
|
|
\subsection{overlayfs}%
|
|
\label{sec:dateisysteme.overlayfs}
|
|
|
|
Overlayfs ermöglicht die Überlagerung eines Verzeichnisbaums mit einem anderen
|
|
Verzeichnisbaum. Alle Änderungen gehen in die höhere beschreibbare Ebene.
|
|
Dadurch können mehrere Verzeichnisbäume basieren auf unterschiedlichen und
|
|
wiederverwendbaren Ebenen abgebildet werden. Diese Art von Mechanismus wird
|
|
vorwiegend für Container Applikationen verwendet. Es gibt jedoch auch eine
|
|
Vielzahl anderer Verwendungsmöglichkeiten.
|
|
|
|
Um overlayfs anhand eines Beispiels einfacher zu erklären betrachten wir den
|
|
Entwicklungsprozess einer Applikation mit allen notwendigen Dateien. Notwendig
|
|
für die Ausführung der Applikation ist die Binärdatei (das eigentliche
|
|
Programm), die Konfigurationsdateien, das Logverzeichnis und die systemd unit
|
|
Dateien, welche beschreiben wie das Programm unter einem systemd basierenden
|
|
System gestartet werden soll. Optional können noch Plugins bereitgestellt
|
|
werden.
|
|
|
|
Alle Dateien bzw. Plugins werden im Entwicklungsprozess in einem eigenen
|
|
Verzeichnisbaum gespeichert. Jeder Verzeichnisbaum wird durch eine Ebene
|
|
repräsentiert. Dies entspricht einem modularem Aufbau, da die Verzeichnisbäume
|
|
individuell wiederverwendet oder ausgetauscht werden können.
|
|
|
|
Die folgende Abbildung beschreibt den modularen Aufbau der Applikation mit allen
|
|
notwendigen Ebenen. Jede Ebene (layer) wird lesend über die vorherige Ebene
|
|
überlagert. Links befindet sich die Applikation ohne Plugins, rechts mit
|
|
Plugins, welche zusätzlich als seperate Ebene abgebildet sind und nicht
|
|
verändert werden können. Die horizontale Linie markiert den Punkt, ab wann
|
|
unterschiedliche Ebenen verwendet werden. Die oberste Ebene (workspace) ist
|
|
beschreibbar, um Konfigurationsdateien anzupassen oder damit das Programm
|
|
Logeinträge in die Logdateien schreiben kann.
|
|
|
|
\begin{figure}[H]
|
|
\centering
|
|
\includegraphics[width=0.55\textwidth]{img/overlayfs.png}
|
|
\caption{Aufbau eines OverlayFS mit mehreren wiederverwendeten Ebenen}%
|
|
\label{fig:dateisysteme.overlayfs.aufbau-mit-mehreren-ebenen}
|
|
\end{figure}
|
|
|
|
\begin{itemize}[label={},itemsep=0pt]
|
|
\item \textbf{Aufgabe 7a:} Erstellen Sie folgendes Arbeitsverzeichnis und
|
|
wechseln die dort hinein: \textit{/root/workspace/overlayfs}.
|
|
\item \textbf{Aufgabe 7b:} Erstellen Sie folgende Dateien und Verzeichnisse
|
|
unterhalb ihres Arbeitsverzeichnisses:
|
|
|
|
\begin{itemize}[label={},itemsep=0pt]
|
|
\item \textbf{Aufgabe 7b$_1$:} Die \glqq{}Binärdatei\grqq{}:\\
|
|
\textit{./lower\_0/usr/bin/mybin}.
|
|
\item \textbf{Aufgabe 7b$_2$:} Die globale Konfigurationsdatei:\\
|
|
\textit{./lower\_1/etc/mybin/config.json}.
|
|
\item \textbf{Aufgabe 7b$_3$:} Die Logdatei:\\
|
|
\textit{./lower\_2/var/log/mybin/info.log}
|
|
\item \textbf{Aufgabe 7b$_4$:} Die systemd unit Dateien:\\
|
|
\textit{./lower\_3/usr/lib/systemd/system/mybin.service}
|
|
\item \textbf{Aufgabe 7b$_5$:} Die Konfigurationsdatei für das sqlite Plugin:\\
|
|
\textit{./lower\_4/etc/mybin/conf.d/sqlite.config}
|
|
\item \textbf{Aufgabe 7b$_6$:} Die Konfigurationsdatei für das postgresql
|
|
Plugin:\\
|
|
\textit{./lower\_5/etc/mybin/conf.d/postgresql.config}
|
|
\end{itemize}
|
|
\end{itemize}
|
|
|
|
Um mehrere Verzeichnisbäume überlagernd einzubinden ist folgende allgemeine
|
|
Syntax notwendig:
|
|
|
|
\begin{bashcode}
|
|
$ mount -t overlay -o lowerdir=<path_lowerdir1>:<path_lowerdir2>:... ,upperdir=<path>,workdir=<path> overlayfs <path>
|
|
\end{bashcode}
|
|
|
|
Das Flag \textit{-t} gibt den Typ an. Mit dem Flag \textit{-o} werden Optionen
|
|
definiert. Der Option lowerdir kann eine Liste von Pfaden übergeben werden,
|
|
gerennt durch einen Doppelpunkt, um zu defineren welche Verzeichnisbäume
|
|
überlagert werden sollen. Dabei ist die Reihenfolge zu beachten. Upperdir
|
|
entspricht dem workspace der Abbildung, sprich das spätere beschreibbare
|
|
Verzeichnis. Als workdir muss der Pfad zu einem leeren Verzeichnis angegeben
|
|
werden, indem der Prozess für den Überlagerungsvorgang Dateien zwischenspeichern
|
|
kann. Das zweite Argument entspricht dem Pfad im Dateisystem, andem der
|
|
überlagerte Verzeichnisbaum eingebunden werden soll.
|
|
|
|
\begin{itemize}[label={},itemsep=0pt]
|
|
\item \textbf{Aufgabe 7c:} Binden Sie mithilfe des \textit{mount} Befehls das
|
|
OverlayFS Dateisystem bestehend aus allen notwendigen Ebenen unter
|
|
\textit{./application} und \textit{./application\_plugins} ein, um einmal den
|
|
notwendigen Verzeichnisbaum für die Applikation mit und ohne Plugin ab zu
|
|
bilden. Vergewissern Sie sich, dass alle notwendigen Verzeichnisse vorhanden
|
|
sind. Verwenden Sie die unterschiedlichen Verzeichnisbäume bzw. Ebenen wieder.
|
|
\item \textbf{Aufgabe 7d:} Erstellen Sie unter \textit{./application} das
|
|
Verzeichnis \textit{hello-world}. Überprüfen Sie, ob das Verzeichnis in einer
|
|
der Ebenen, welche als lesende Verzeichnisbäume eingebunden wurden, erstellt
|
|
wurde.
|
|
\item \textbf{Aufgabe 7e:} Löschen Sie unter \textit{./application\_plugins}
|
|
die plugin Konfigurationsdateien. Überprüfen Sie anschließend ob in der
|
|
entsprechenden Ebene ebenfalls die Konfigurationsdatei gelöscht wurde. Diese
|
|
dürfte nach dem Konzept nicht gelöscht worden sein.
|
|
\end{itemize}
|
|
|
|
Dateisysteme von Container Applikationen sind genau nach diesem Konzept
|
|
aufgebaut. Die Stärke liegt jedoch nicht nur in dem modularen Dateisystemaufbau
|
|
oder der Isolierung von Ressourcen - sprich CPU, \acrshort{acr:ram}, Storage,
|
|
ect., sondern auch darin, dass die Ebenen sich leicht von einem System auf ein
|
|
anderes übertragen lassen. Man spricht bei diesem Abschnitt in der Entwicklung
|
|
einer Applikation von Deployment. Dabei gilt, dass die beste Software die
|
|
schlechteste sein kann, wenn der Anwender nicht in der Lage ist, sie ohne große
|
|
Umstände installieren oder ausführen zu können.
|
|
|
|
Container Runtimes wie containerd, crio oder runc bemächtigen sich der Funktion
|
|
Subvolumes des darunter liegenden BtrFS Dateisystems zu importieren bzw.
|
|
exportieren, da dadurch Verzeichnisbäume einfach von einem System auf ein
|
|
anderes kopiert werden können. Ebenen bzw. Layer werden dann als eigenständiges
|
|
Subvolume betrachtet.
|
|
|
|
Finden Container Runtimes auf dem System kein BtrFS Dateisystem vor, werden die
|
|
Verzeichnisbäume unterhalb eines Verzeichnisses im Dateisystem gespeichert.
|
|
Ähnlich wie es bei der Übung veranschaulicht wurde. Dies hat jedoch den
|
|
Nachteil, dass identische Dateien, welche in mehreren Ebenen bzw. Layern
|
|
wiederverwendet werden zusätzlichen Speicherplatz auf der Festplatte
|
|
verbrauchen.
|
|
|
|
% #>-------------------------------------------------------------------------<#
|
|
\subsection{tmpfs}%
|
|
\label{sec:dateisysteme.tmpfs}
|
|
|
|
\textit{tmpfs} ist ein Dateisystem im \acrshort{acr:ram}. Es wird gerne
|
|
verwendet, wenn große IO Operationen stattfinden oder das Dateisystem nur
|
|
während der Laufzeit des Systems benötigt wird.
|
|
|
|
Da dieses Dateisystem sich im \acrshort{acr:ram} befindet, sind sehr schnelle
|
|
Zugriffszeiten keine Seltenheit mehr. Bei einfachen Rechnern mit DDR4 kann man
|
|
schon mit 10GiB/Sekunde rechnen. Typischer Anwendungsfall ist, wenn ein Programm
|
|
durch einen Kompiler kompiliert wird und der Vorgang hohe I/O Operationen auf der
|
|
Festplatte verursacht. Hinsichtlich der verbauten Festplatte wird gerade dadurch
|
|
die Lebenszeit erheblich erhöht.
|
|
|
|
Mit dem folgenden Befehl wird ein neues Dateisystem mit einer Größe von 512MB im
|
|
\acrshort{acr:ram} erstellt. Dieses wird anschließend nach \textit{/mnt/tmpfs}
|
|
eingebunden. Mit dem Befehl \textit{findmnt} können die Optionen des
|
|
\textit{tmpfs} Dateisystems überprüft werden.
|
|
|
|
\begin{bashcode}
|
|
$ mkdir --parent /mnt/tmpfs
|
|
$ mount -t tmpfs -o rw,relatime,size=512M tmpfs /mnt/tmpfs
|
|
$ findmnt /mnt/tmpfs
|
|
TARGET SOURCE FSTYPE OPTIONS
|
|
/mnt/tmpfs tmpfs tmpfs rw,relatime,seclabel,size=524288k
|
|
\end{bashcode}
|
|
|
|
Dateien und Verzeichnisse, welche sich in einem tmpfs Dateisystem befinden sind
|
|
nach einem Neustart des Systems verloren. Sie sind nicht wiederherstellbar. |