Achtung: Dies ist ein Artikel für technisch Interessierte, die bereits mit der Linux-Shell umgehen können und wissen was sie tun.
Alle anderen sollten lieber eines der Standard-Dateisysteme wie ext3, xfs oder ReiserFS verwenden, die bereits im Linux-Kernel enthalten sind.
Nilfs2 ist ein log-structured file system. Das heißt, dass Daten bei bearbeitung nicht überschrieben werden, sondern an eine andere Stelle geschrieben werden, sodass das Original erhalten bleibt.
Ähnlich wie bei
Journalling Dateisystemen führt dies dazu, dass im Falle eines Ausfalls keine Daten nur halb geschrieben sind. Aber auch nach der Schreiboperation bleibt der alte Zustand erhalten, und kann zum Beispiel genutzt werden um gelöschte Dateien wiederherzustellen.
Dazu nutzt Nilfs2
Checkpoints und
Snapshots. Bearbeitet man Dateien, erstellt Nilfs2 ca. alle 30 Sekunden einen Checkpoint, welcher in der Standardeinstellung nach einer Stunde gelöscht wird. Möchte man einen Checkpoint dauerhaft behalten, kann man ihn in einen Snapshot umwandeln, welcher nicht automatisch gelöscht wird.
Installation
Zur Installation lädt man den
Quelltext des Kernel-Moduls und der nötigen Programme herunter und kompiliert diese. Für das Modul muss der Kernel selber nicht gepatcht werden, die Kernel-Header Dateien müssen jedoch beim kompilieren vorhanden sein. Danach muss das Modul geladen werden, und schon ist Nilfs2 einsatzbereit.
Einführung
Zunächst erstellen wir ein Testimage:
# dd if=/dev/zero of=nilfs2.image bs=1M count=200 #200MiB Datei erstellen
200+0 Datensätze ein
200+0 Datensätze aus
209715200 Bytes (210 MB) kopiert, 4,8456 Sekunden, 43,3 MB/s
# losetup /dev/loop0 nilfs2.image
# mkfs.nilfs2 /dev/loop0
mkfs.nilfs2 ver 2.0
Start writing file system initial data to the device
Blocksize:4096 Device:/dev/loop0 Device Size:209715200
File system initialization succeeded !!
Und hängen es ein:
# mount -t nilfs2 /dev/loop0 /media/loop
# cd /media/loop
# ls -a
. .. .nilfs .sketch
Die Checkpoints zeigt "lscp" an:
# lscp
CNO DATE TIME MODE SKT NBLKINC ICNT
1 2008-03-24 21:43:46 cp - 11 3
# touch test
# ls -a
. .. .nilfs .sketch test
# lscp
CNO DATE TIME MODE SKT NBLKINC ICNT
1 2008-03-24 21:43:46 cp - 11 3
2 2008-03-24 21:45:58 cp - 11 4
Wenn man möchte, kann man alte Checkpoints mit
rmcp entfernen:
# rmcp 1
# lscp
CNO DATE TIME MODE SKT NBLKINC ICNT
2 2008-03-24 21:45:58 cp - 11 4
möchte man einen Stand dauerhaft behalten, hilft "mkcp -s" einen neuen Snapshot zu erstellen.
# echo "test1" >test
# mkcp -s
# lscp
CNO DATE TIME MODE SKT NBLKINC ICNT
2 2008-03-24 21:45:58 cp - 11 4
3 2008-03-24 21:47:04 cp - 7 4
4 2008-03-24 21:47:59 ss - 11 4
# echo "test2" >test
# lscp
CNO DATE TIME MODE SKT NBLKINC ICNT
2 2008-03-24 21:45:58 cp - 11 4
3 2008-03-24 21:47:04 cp - 7 4
4 2008-03-24 21:47:59 ss - 11 4
5 2008-03-24 21:48:04 cp - 8 4
6 2008-03-24 21:48:11 cp - 11 4
Stattdessen hätte man auch mit "
chcp ss #num" einen existierenden Checkpoint in einen Snapshot umwandeln können.
Snapshot 4 sollte also in der Datei test den Text "test1" enthalten, wohingegen die Datei momentan "test2" enthält.
Probieren wir es aus, indem wir Checkpoint 4 in einen neuen Ordner mounten:
# mount -t nilfs2 -o ro,cp=4 /dev/loop0 /media/loop2
# cd /media/loop2/
# cat test
test1
Tatsächlich, unter "/media/loop2" kann man nun im nur-lesen Modus den alten Snapshot benutzen. Möchte man den Snapshot wieder entfernen, muss man ihn zunächst mit "chcp cp #num" wieder in einen Checkpoint umwandeln:
# lscp |grep "^[ ]*4" #das grep filtert auf Checkpoints die mit 4 anfangen
4 2008-03-24 21:47:59 ss - 11 4
# chcp cp 4
# lscp |grep "^[ ]*4"
4 2008-03-24 21:47:59 cp - 11 4
Nun wird der Snapshot entweder automatisch gelöscht werden, oder man kann ihn wie jeden anderen Checkpoint mit
rmcp entfernen.
Checkpoints löschen
Nilfs2 nutzt einen Daemon, der via /etc/nilfs_cleanerd.conf konfiguriert wird um alte Checkpoints zu löschen. In der Datei kann man einstellen, wie lange Checkpoints aufgehoben werden(1 Stunde als Default), und wieviele Chunks in welchem Zeitabstand wieder freigegeben werden sollen.
Vorteile
Nilfs2 spielt seine Vorteile vor allem im Backupbereich aus. So kann zum Beispiel
rsync-Backup mit Nilfs2 ohne Hardlinks realisiert werden, wodurch das Löschen von alten Backups beschleunigt wird. Liegt nicht nur das Backup auf dem Nilfs2, sondern die ganzen Daten, können ausversehen gelöscht Dateien aus einem Checkpoint wiederhergestellt werden, und es sind höchstens die Änderungen der letzten 30 Sekunden verloren.
Eine komplette Datensicherung wäre mit einer Kombination von
RAID-1(Sicherheit gegen Festplattenausfall) und Nilfs2(Sicherheit gegen versehentliches Löschen) denkbar.
Nachteile
Nilfs2 ist nicht im offziellem Kernel, was garantieren würde, dass es auch in Zukunft noch verfügbar ist.[UPDATE Seit Linux 2.6.30 ist Nilfs2 Bestandteil des offiziellen Kernels] Außerdem
fehlen noch einige Dateisystemfunktionen. Weiterhin ist die Stabilität und Performance noch nicht so gut untersucht wie bei den verbreiteten Dateisystemen. Nilfs 2.0.0 kann noch kein NFS, was in 2.0.1 jedoch inzwischen möglich ist.
Außerdem ergibt sich ein Problem, wenn man das Dateisystem komplett füllt, dass selbst nach dem Löschen der Datei der Platz nicht freigegeben wird, da die Datei noch in diversen Checkpoints weiterexistiert. Auch wenn diese Checkpoints gelöscht werden wird der Platz erst freigegeben, wenn die protection_period aus der Konfiguration erreicht wird. Das führt unter Umständen schoneinmal dazu, dass man ca. 1 Stunde keine neuen Datei mehr erstellen kann.
Workaround: kurze protection_period (dann aber snapshots für jeden Stand den man noch braucht!) oder darauf achten, dass das Dateisystem nie komplett gefüllt wird.
Sicheres Löschen mit Tools wie
shred funktioniert aufgrund der Wirkungsweise eines log-structured FS leider nicht. Umgekehrt werden gelöschte Daten, sobald sie in keinem Checkpoint mehr enthalten sind vermutlich recht häufig durch das anlegen neuer Checkpoints überschrieben, wenn das FS aktiv genutzt wird.
Vorsicht bei 2.0.1
Nilfs2 2.0.1 erkennt Dateisysteme von 2.0.0 nicht. Dies liegt wohl nicht an einer Disk-Layout Änderungen, sondern ist ein
Fehler. 2.0.1 Images laufen mit 2.0.1 jedoch problemlos.
Fazit
Momentan teste ich Nilfs2 2.0.0, und warte auf den Bugfix für 2.0.1, damit es mein Dateisystem wieder erkennt. Die Performance ist bisher super, und während des Betriebs von 2.0.0 hatte ich keinerlei Probleme, außer dass NFS noch nicht implementiert war. Es bleibt zu hoffen, dass Regressionen wie bei 2.0.1 eine Ausnahme bleiben.
[UPDATE] Inzwischen ist nilfs2 bei 2.0.4 (utils 2.0.5) angekommen, und der 2.0.1 Bug ist beseitigt, NFS wurde nachgerüstet und im 2.0.4 Release wurde ein von mir gemeldeter Bug beim löschen von Dateien die mehrere Gigabyte groß sind beseitigt. Auf der Backup-Partition ist nilfs2 jetzt schon länger ohne Probleme im Einsatz. Mit Rsync werden die Dateien auf den aktuellen Stand gebracht, und dann wird ein Snapshot erstellt, welcher den Stand dauerhaft sichert.
Der EEE-PC 