Sensei21
Commander
- Registriert
- März 2002
- Beiträge
- 2.680
Reiser4 / reiserfs (v3.6) thread
In diesem thread sollen nach und nach Infos und Tipps zu den Dateisystemen
reiser4 und reiserfs erscheinen, um die Leistung zu erhöhen und mehr
generelle und spezielle Infos zu Reiser4:
* Reiser4 wikipedia (english)
* Reiser4 wikipedia (deutsch)
* Trees in the Reiser4 Filesystem, Part I (english)
* Reiser4, Part II: Designing Trees that Cache Well (english)
* IV. Symphonie von Reiser (deutsch)
* Beschränktes Schreiben - Schreibbarrieren (Linux Magazin)
Reiser4 beinhaltet "Features", die bis vor kurzem in anderen Dateisystemen noch nicht Einzug gefunden hatten:
- eine "Plugin"-Architektur, die es Programmierern ermöglicht, das Dateisystem (später) um Features zu erweitern, die noch nicht inkludiert sind bzw. es den Benutzern zu ermöglichen im Grunde unterschiedliche Dateisysteme mit ähnlichen Funktionen zusammengefasst unter einem zu nutzen
Lange Zeit gab es heftige Diskussionen zu diesem Charakteristikum von Reiser4: es stelle ein Sicherheitsproblem dar, Reiser4 würde für sich beanspruchen DAS einzige (in den Augen der Kritiker: über andere "herrschende") Dateisystem zu werden:
In der Tat: es war ursprünglich geplant Reiser4 so aufzubauen, dass die anderen Dateisysteme als "Plugin" in der durch Reiser4 zur Verfügung gestellten VFS-Struktur (neben dem bereits existenten VFS - ein weiterer Kritikpunkt) genutzt werden können.
Anzumerken ist jedoch, dass diese aufgeworfenen Kritikpunkte (daneben noch Codingstyle und fehlende Abwärtskompatibilität) mittlerweile hinfällig sind, da einerseits das VFS-ähnliche System entfernt wurde, die eine (niedrig-hierarchische) Plugin-Architektur auch bei XFS zu finden ist [es beinhaltet ein proprietäres Interface], der Code wurde in der letzten Zeit in seiner Lesbarkeit verbessert; andererseits wurde z.B. Btrfs in den Hauptkernel aufgenommen wurde, das ebenfalls eine Art eigenes VFS (mit Raid-Funktionalität, etc.) beinhaltet.
Weiters sollte es möglich sein das Dateisystem als eine Art Datenbank nutzen zu können, in dem die existenten Daten (z.B. Dokumente, mp3s, PDFs) mit Attributen versehen werden - im Grunde also so eine Art erweitertes ACL (access control list system) das nicht die Zugriffsrechte sondern Beschreibungen der Dateien beinhaltet. Ziel sollte sein, dass die "Datenbank" transparent im Dateisystem verschwindet. Wie das ganze aussieht bzw. aussehen könnte zeigt das (EU ?)-Projekt des ontology desktop OSCAF/NEPOMUK Ontologies - the Social Semantic Desktop und das sich zur Zeit in Entwicklung befindliche "KDE Software Compilation 4".
[FIXME: add site, info, source]
- "Dancing trees": Dancing trees (en.wikipedia.org) [FIXME: add more info]
- transparente Dateisystem-Kompression (wahlweise gzip (gzip1) oder lzo (lzo1)); mit "transparent" ist gemeint, dass man das Dateisystem normal nutzen kann, es selbst (also automatisch im Hintergrund) die Daten komprimiert und dadurch zusätzlich (die Reiser-Dateisysteme sind ja für ein effizientes Speichermanagement bekannt) noch Platz sparen bzw. sogar gewinnen kann. [FIXME: more info available ?]
dieses Feature (cryptcompress) wurde - soviel ich weiß - von Edward Shiskin entwickelt, der noch einer der wenigen ist, der Reiser4 weiterentwickelt
*) zusätzlich kann gewählt werden, ob die Dateien immer komprimiert werden sollen (force);
*) die Kompression für die Datei(en) deaktiviert werden sollen, wenn der Kompressionsmanager etwas nicht komprimierbares vorfindet (ultim);
*) die Dateien auf einem lernfähigen Algorithmus basierend komprimiert werden soll (lattice);
*) oder standardmäßig anhand der ersten 64K des ersten Clusters darüber entscheidet, ob die Datei komprimierbar ist oder in ein extent umgewandelt werden soll und bis zum Ende seiner Existenz als normale Datei behandelt wird über das unix-file plugin (conv);
*) man dennoch die Vorteile von cryptcompress nutzen möchte ohne Kompression (none)
Ein beeindruckendes Beispiel von BTRFS (DEM aufstrebendem Dateisystem für Linux, das zur Zeit sehr stark entwickelt wird) was die Kompression bringt, findet man in folgendem Thema: Re: worse than expected compression ratios with -o compress
dort sieht man schön, dass die Zeit, um Daten zu kopieren von:
real 57m6.983s
user 0m0.807s
sys 1m28.494s
auf:
real 14m45.742s
user 0m0.547s
sys 1m30.551s
hinunterging. Hierbei wird also der Flaschenhals Festplatte mit Hilfe des Kraftprotzes CPU umgangen. (der eingesetzte Algorithmus entspräche:
)
- weiters war Reiser4 + cryptcompress das einzige Dateisystem unter GNU/Linux, das Prüfsummen (checksumming) für sämtliche Cluster von sich aus unterstützt und somit eine höhere Datensicherheit gewährleistet [Quelle benötigt] (das zur Zeit in Entwicklung befindende btrfs unterstützt ebenfalls [gzip]-Kompression, Prüfsummen [für Transaktionen] und mehr)
- Fibration was soviel wie Anordnung der Dateien nach einem bestimmten Schema bedeutet: möglich sind
*) alphabetisch (lexic_fibre);
*) die Bibliotheken / Libraries werden näher zusammengepackt, damit das System schneller bootet oder das Kompilieren schneller von statten geht (dot_o_fibre);
*) die Dateien werden nach dem 1. Buchstaben der Dateisystemendung angeordnet bzw. zusammengepackt (ext_1_fibre);
*) das gleiche jedoch mit Rücksicht auf 3 Buchstaben der Dateiendung (ext_3_fibre)
- Tail-Packing (Block suballocation), dieses Feature hat schon mit reiserfs v3.X Einzug gehalten. In Reiser4 hat man jedoch ein größere Auswahl zwischen
*) Tail-Packing für alle Dateien (tails) (effizient vor allem für viele kleine Dateien);
*) kein Tail-Packing (extents) (eher effizient für große Dateien);
*) oder man überlässt die Entscheidung einem Algorithmus (smart), der entscheidet, ob das leistungs"zehrende" Tail-Packing sich für die betreffende(n) Datei(en) lohnt
[FIXME: more info about fragmentation ?]
es gibt sicher einen Haken hierfür - oder? Gewiss!, der ist heutzutage mit den immer mehr vor Leistung (vor allem der CPU) strotzenden Rechnern jedoch eher ein Ding der Vergangenheit bzw. für Leistungsfetischisten: der Leistungsverlust beträgt etwa 3-5% bei deutlichen Vorteilen: weniger Fragmentierung, mehr Speicherplatz, etc.
- Atomic Transactions
weiters wurde/wird Reiser4 als DAS Dateisystem mit "atomaren Transaktionen" (dass jetzt keine Behörde auf dumme Gedanken kommt
) beworben: Das heißt, dass die (neuen) Daten bei Entfernen der Stromzufuhr entweder ganz auf der Platte landen oder gar nicht es sollten also solche Probleme wie (alte existente wie neue) Dateien, die nach einem Crash aus 0-byte bestehen und einem Datenverlust entsprechen - wie bei XFS (gewollt aus Sicherheitsgründen) oder ext4 (vermutlich ein Designproblem) - somit der Vergangenheit angehören
- Delayed Allocation
Delayed Allocations sind [FIXME:]
Delayed Allocations stehen im Zusammenhang mit Atomic Transactions und dem Problem, dass Daten entweder auf der Platte landen oder eben nicht. Einerseits erlauben Delayed Allocations es einen höheren Durchsatz an Daten zu erreichen (Leistung/Performance) andererseits steigt selbstverständlich auch das Risiko an Datenverlust - ein Problem, das viele - wenn nicht alle modernen Hochleistungsdateisysteme heute haben (XFS, Ext4, Reiser4, Btrfs (?)). Das Problem kann minimiert werden, indem man dem Dateisystem mitteilt, dass es - statt alle 10 Minuten - alle 30 Sekunden oder 5 Sekunden (Standard bei Ext3) die Daten auf die Platte schreibt:
oder
bei reiserfs v3.6 wird dies über commit= gemacht z.B.
oder
- Barriers
Barriers sind [FIXME: ].
Barriers werden von Reiser4 (im Gegensatz zu reiserfs v3.6) standardmäßig aktiviert bzw. unterstützt. Wenn Reiser4 feststellt, dass das zugrundeliegende Gerät keine Barriers unterstützt, wird auf einen synchronen (etwas langsameren) Schreibmodus umgeschaltet, der weiterhin die Sicherheit der Daten gewährleistet.
weitere Features von Reiser4 sind:
- die Wahl zwischen Kompression (mit Prüfsummen) und Nicht-Kompression (unix-file plugin oder cryptcompress-plugin) - über
*) mkfs.reiser4 -o create=ccreg40 [cryptcompress Dateisystemformat] oder
*) mkfs.reiser4 -o create=reg40 [normales Dateisystemformat]
-- welcher Kompressionsalgorithmus gewählt werden soll (gzip, lzo) -
*) über mkfs.reiser4 -o create=ccreg40,compress=lzo1 oder
*) mkfs.reiser4 -o create=ccreg40,compress=gzip1 [beachte die 1 hinter dem Kompressionsalgorithmus !]
-- welche Kompressionsstrategie gewählt wird (conv, ultim, latt, force, none) - z.B. über mkfs.reiser4 -o create=ccreg40,compressMode=conv
- die Wahl der Cluster-Größe ("4K", "8K", "16K", "32K", "64K") - mit der Option cluster= ; z.B. cluster=8K anzugeben: mkfs.reiser4 -o cluster=8K
- [FIXME]
oben genannte Features lassen sich beim Erstellen des Dateisystems fest vorgegeben - d.h. man kann diese ohne das Dateisystem ein weiteres zu formatieren und die Daten zu verlieren (vermutlich) nicht mehr ändern:
mkfs.reiser4 -o
- create=
- compress=
- compressMode=
- cluster=
- fibration=
- formatting=
ein paar Beispiele, wie so eine Einrichtung bzw. Formatierung einer Reiser4-Partition aussehen könnte:
Im Folgenden werden die Mount-Optionen aufgeführt (die Optionen, die man jederzeit nach dem Unmounten des Dateisystems verändern kann); diese müssen NICHT eingegeben; Reiser4 wählt für gewöhnlich ein (semi)optimales Set von Optionen aus, die gut laufen:
- tmgr.atom_max_size=N
- tmgr.atom_max_age=N
- tmgr.atom_max_flushers=N
- tree.cbk_cache.nr_slots=N
- flush.relocate_threshold=N
- flush.relocate_distance=N
- flush.scan_maxnodes=N
- optimal_io_size=N
- bsdgroups
- 32bittimes
- mtflush
- nopseudo
- dont_load_bitmap
Beschreibung der Mount-Optionen:
[WORK IN PROGRESS !]
- tree.cbk_cache.nr_slots=N hiermit wird die Größe des Lookaside Caches festgelegt, in dem laut Nikita Danilov's Blog bzw. diary eine Anzahl der letzten Blätter (Objekte), die eingelesen wurden, zwischengespeichert werden - dies kann u.a. bei Datenbankenoperationen von Vorteil sein. Der Standardwert wird über folgenden Algorithmus festgelegt: "Default is nr_free_pagecache_pages() / 2 at mount time."
- optimal_io_size=N damit wird die optimale Datelese- und schreibgröße festgelegt, standardmäßig ist 64 kiB (65536) vorgegeben, das jedoch für heutige Verhältnisse eine eher konservative Durchsatzrate erreicht - daher sind eher 512 oder sogar 2048 zu empfehlen (512 * 1024; 2048 * 1024)
- dont_load_bitmap Hiermit wird festgelegt, dass beim Mounten nicht die Bitmap geladen bzw. eingelesen wird. In allen Bitmap Blöcken zusammen ist festgehalten, wo sich freier Speicherplatz auf dem Laufwerk befindet und wo nicht. Diese Mount-Option kann in der heutigen Zeit besonders sinnvoll sein mit Partitionen, die recht groß sind (ca. ab 20 GiB) oder bei Platformen mit wenig Arbeitsspeicher, bei denen jedes MiB freier Speicher zählt. Dadurch kann das Mounten beträchtlich beschleunigt werden.
generelle und spezielle Infos zu reiserfs:
* http://en.wikipedia.org/wiki/ReiserFS
* The structure of the Reiser file system (by Florian Buchholz)
* Beschränktes Schreiben - Schreibbarrieren (Linux Magazin)
* reiser4: 1. internal tree - a very occasional diary. (von Nikita Danilov, einem der Entwickler von reiser4)
(FIXME: needs more information, optimally from the developers at former namesys.com, postings of Hans Reiser, etc.)
Tuning-Sektion:
- um unnötige Leistungseinbußen zu vermeiden, sollten beide Dateisysteme mit noatime,nodiratime gemountet werden (info: http://en.tldp.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3/chap6sec73.html
Tuning/Tweaks speziell für Reiser4:
WORK IN PROGRESS !
bis ich Zeit finde, das vollständig auszuführen, verweise ich zunächst auf englischsprachige Resourcen:
Reiser4 Gentoo FAQ (forums.gentoo.org)
ReiserFS tuning thread, the mother of all "ricer" threads (forums.gentoo.org)
Wer Probleme mit dem Datendurchsatz (vor allem beim Schreiben) hat, sollte sich folgende Option einmal zu Gemüte führen:
optimal_io_size=N
nach persönlichen Erfahrungen ist der voreingestellte Wert viel zu klein für heutige Verhältnisse und bremst reiser4 nur unnötig aus, darum sollte reiser4 probeweise mit folgenden Werten gemountet werden:
oder
Tuning/Tweaks speziell für reiserfs:
- mounte das dateisystem mit commit=600 (das sind dann 10 minuten)
- falls es mal etwas schneller gehen soll (z.B. ein großes Backup auf eine Backup-Platte zu spielen; hierbei sollte aber die Stromversorgung gewährleistet sein), kann man auch data=writeback hinzufügen
- alternativ gibt es noch: data=ordered (standard), data=journal (am sichersten) (nachzulesen auf: (Linux-Magazin 2004/11))
- data=notail hierbei wird auf das Tail-packing verzichtet (bei neueren kerneln gibt man einfach notail an, z.B. -o notail)
mehr spezielles folgt später
In diesem thread sollen nach und nach Infos und Tipps zu den Dateisystemen
reiser4 und reiserfs erscheinen, um die Leistung zu erhöhen und mehr
generelle und spezielle Infos zu Reiser4:
* Reiser4 wikipedia (english)
* Reiser4 wikipedia (deutsch)
* Trees in the Reiser4 Filesystem, Part I (english)
* Reiser4, Part II: Designing Trees that Cache Well (english)
* IV. Symphonie von Reiser (deutsch)
* Beschränktes Schreiben - Schreibbarrieren (Linux Magazin)
Reiser4 beinhaltet "Features", die bis vor kurzem in anderen Dateisystemen noch nicht Einzug gefunden hatten:
- eine "Plugin"-Architektur, die es Programmierern ermöglicht, das Dateisystem (später) um Features zu erweitern, die noch nicht inkludiert sind bzw. es den Benutzern zu ermöglichen im Grunde unterschiedliche Dateisysteme mit ähnlichen Funktionen zusammengefasst unter einem zu nutzen
Lange Zeit gab es heftige Diskussionen zu diesem Charakteristikum von Reiser4: es stelle ein Sicherheitsproblem dar, Reiser4 würde für sich beanspruchen DAS einzige (in den Augen der Kritiker: über andere "herrschende") Dateisystem zu werden:
In der Tat: es war ursprünglich geplant Reiser4 so aufzubauen, dass die anderen Dateisysteme als "Plugin" in der durch Reiser4 zur Verfügung gestellten VFS-Struktur (neben dem bereits existenten VFS - ein weiterer Kritikpunkt) genutzt werden können.
Anzumerken ist jedoch, dass diese aufgeworfenen Kritikpunkte (daneben noch Codingstyle und fehlende Abwärtskompatibilität) mittlerweile hinfällig sind, da einerseits das VFS-ähnliche System entfernt wurde, die eine (niedrig-hierarchische) Plugin-Architektur auch bei XFS zu finden ist [es beinhaltet ein proprietäres Interface], der Code wurde in der letzten Zeit in seiner Lesbarkeit verbessert; andererseits wurde z.B. Btrfs in den Hauptkernel aufgenommen wurde, das ebenfalls eine Art eigenes VFS (mit Raid-Funktionalität, etc.) beinhaltet.
Weiters sollte es möglich sein das Dateisystem als eine Art Datenbank nutzen zu können, in dem die existenten Daten (z.B. Dokumente, mp3s, PDFs) mit Attributen versehen werden - im Grunde also so eine Art erweitertes ACL (access control list system) das nicht die Zugriffsrechte sondern Beschreibungen der Dateien beinhaltet. Ziel sollte sein, dass die "Datenbank" transparent im Dateisystem verschwindet. Wie das ganze aussieht bzw. aussehen könnte zeigt das (EU ?)-Projekt des ontology desktop OSCAF/NEPOMUK Ontologies - the Social Semantic Desktop und das sich zur Zeit in Entwicklung befindliche "KDE Software Compilation 4".
[FIXME: add site, info, source]
- "Dancing trees": Dancing trees (en.wikipedia.org) [FIXME: add more info]
- transparente Dateisystem-Kompression (wahlweise gzip (gzip1) oder lzo (lzo1)); mit "transparent" ist gemeint, dass man das Dateisystem normal nutzen kann, es selbst (also automatisch im Hintergrund) die Daten komprimiert und dadurch zusätzlich (die Reiser-Dateisysteme sind ja für ein effizientes Speichermanagement bekannt) noch Platz sparen bzw. sogar gewinnen kann. [FIXME: more info available ?]
dieses Feature (cryptcompress) wurde - soviel ich weiß - von Edward Shiskin entwickelt, der noch einer der wenigen ist, der Reiser4 weiterentwickelt
*) zusätzlich kann gewählt werden, ob die Dateien immer komprimiert werden sollen (force);
*) die Kompression für die Datei(en) deaktiviert werden sollen, wenn der Kompressionsmanager etwas nicht komprimierbares vorfindet (ultim);
*) die Dateien auf einem lernfähigen Algorithmus basierend komprimiert werden soll (lattice);
*) oder standardmäßig anhand der ersten 64K des ersten Clusters darüber entscheidet, ob die Datei komprimierbar ist oder in ein extent umgewandelt werden soll und bis zum Ende seiner Existenz als normale Datei behandelt wird über das unix-file plugin (conv);
*) man dennoch die Vorteile von cryptcompress nutzen möchte ohne Kompression (none)
Ein beeindruckendes Beispiel von BTRFS (DEM aufstrebendem Dateisystem für Linux, das zur Zeit sehr stark entwickelt wird) was die Kompression bringt, findet man in folgendem Thema: Re: worse than expected compression ratios with -o compress
dort sieht man schön, dass die Zeit, um Daten zu kopieren von:
real 57m6.983s
user 0m0.807s
sys 1m28.494s
auf:
real 14m45.742s
user 0m0.547s
sys 1m30.551s
hinunterging. Hierbei wird also der Flaschenhals Festplatte mit Hilfe des Kraftprotzes CPU umgangen. (der eingesetzte Algorithmus entspräche:
Code:
mkfs.reiser4 -o create=ccreg40,compress=gzip1,compressMode=force- weiters war Reiser4 + cryptcompress das einzige Dateisystem unter GNU/Linux, das Prüfsummen (checksumming) für sämtliche Cluster von sich aus unterstützt und somit eine höhere Datensicherheit gewährleistet [Quelle benötigt] (das zur Zeit in Entwicklung befindende btrfs unterstützt ebenfalls [gzip]-Kompression, Prüfsummen [für Transaktionen] und mehr)
- Fibration was soviel wie Anordnung der Dateien nach einem bestimmten Schema bedeutet: möglich sind
*) alphabetisch (lexic_fibre);
*) die Bibliotheken / Libraries werden näher zusammengepackt, damit das System schneller bootet oder das Kompilieren schneller von statten geht (dot_o_fibre);
*) die Dateien werden nach dem 1. Buchstaben der Dateisystemendung angeordnet bzw. zusammengepackt (ext_1_fibre);
*) das gleiche jedoch mit Rücksicht auf 3 Buchstaben der Dateiendung (ext_3_fibre)
- Tail-Packing (Block suballocation), dieses Feature hat schon mit reiserfs v3.X Einzug gehalten. In Reiser4 hat man jedoch ein größere Auswahl zwischen
*) Tail-Packing für alle Dateien (tails) (effizient vor allem für viele kleine Dateien);
*) kein Tail-Packing (extents) (eher effizient für große Dateien);
*) oder man überlässt die Entscheidung einem Algorithmus (smart), der entscheidet, ob das leistungs"zehrende" Tail-Packing sich für die betreffende(n) Datei(en) lohnt
[FIXME: more info about fragmentation ?]
es gibt sicher einen Haken hierfür - oder? Gewiss!, der ist heutzutage mit den immer mehr vor Leistung (vor allem der CPU) strotzenden Rechnern jedoch eher ein Ding der Vergangenheit bzw. für Leistungsfetischisten: der Leistungsverlust beträgt etwa 3-5% bei deutlichen Vorteilen: weniger Fragmentierung, mehr Speicherplatz, etc.
- Atomic Transactions
weiters wurde/wird Reiser4 als DAS Dateisystem mit "atomaren Transaktionen" (dass jetzt keine Behörde auf dumme Gedanken kommt
) beworben: Das heißt, dass die (neuen) Daten bei Entfernen der Stromzufuhr entweder ganz auf der Platte landen oder gar nicht es sollten also solche Probleme wie (alte existente wie neue) Dateien, die nach einem Crash aus 0-byte bestehen und einem Datenverlust entsprechen - wie bei XFS (gewollt aus Sicherheitsgründen) oder ext4 (vermutlich ein Designproblem) - somit der Vergangenheit angehören- Delayed Allocation
Delayed Allocations sind [FIXME:]
Delayed Allocations stehen im Zusammenhang mit Atomic Transactions und dem Problem, dass Daten entweder auf der Platte landen oder eben nicht. Einerseits erlauben Delayed Allocations es einen höheren Durchsatz an Daten zu erreichen (Leistung/Performance) andererseits steigt selbstverständlich auch das Risiko an Datenverlust - ein Problem, das viele - wenn nicht alle modernen Hochleistungsdateisysteme heute haben (XFS, Ext4, Reiser4, Btrfs (?)). Das Problem kann minimiert werden, indem man dem Dateisystem mitteilt, dass es - statt alle 10 Minuten - alle 30 Sekunden oder 5 Sekunden (Standard bei Ext3) die Daten auf die Platte schreibt:
Code:
mount -o tmgr.atom_max_age=30oder
Code:
mount -o tmgr.atom_max_age=5bei reiserfs v3.6 wird dies über commit= gemacht z.B.
Code:
mount -o commit=30oder
Code:
mount -o commit=5- Barriers
Barriers sind [FIXME: ].
Barriers werden von Reiser4 (im Gegensatz zu reiserfs v3.6) standardmäßig aktiviert bzw. unterstützt. Wenn Reiser4 feststellt, dass das zugrundeliegende Gerät keine Barriers unterstützt, wird auf einen synchronen (etwas langsameren) Schreibmodus umgeschaltet, der weiterhin die Sicherheit der Daten gewährleistet.
weitere Features von Reiser4 sind:
- die Wahl zwischen Kompression (mit Prüfsummen) und Nicht-Kompression (unix-file plugin oder cryptcompress-plugin) - über
*) mkfs.reiser4 -o create=ccreg40 [cryptcompress Dateisystemformat] oder
*) mkfs.reiser4 -o create=reg40 [normales Dateisystemformat]
-- welcher Kompressionsalgorithmus gewählt werden soll (gzip, lzo) -
*) über mkfs.reiser4 -o create=ccreg40,compress=lzo1 oder
*) mkfs.reiser4 -o create=ccreg40,compress=gzip1 [beachte die 1 hinter dem Kompressionsalgorithmus !]
-- welche Kompressionsstrategie gewählt wird (conv, ultim, latt, force, none) - z.B. über mkfs.reiser4 -o create=ccreg40,compressMode=conv
- die Wahl der Cluster-Größe ("4K", "8K", "16K", "32K", "64K") - mit der Option cluster= ; z.B. cluster=8K anzugeben: mkfs.reiser4 -o cluster=8K
- [FIXME]
oben genannte Features lassen sich beim Erstellen des Dateisystems fest vorgegeben - d.h. man kann diese ohne das Dateisystem ein weiteres zu formatieren und die Daten zu verlieren (vermutlich) nicht mehr ändern:
mkfs.reiser4 -o
- create=
- compress=
- compressMode=
- cluster=
- fibration=
- formatting=
ein paar Beispiele, wie so eine Einrichtung bzw. Formatierung einer Reiser4-Partition aussehen könnte:
Code:
mkfs.reiser4 -o create=ccreg40,compress=gzip1,compressMode=ultim,cluster=8K,fibration=dot_o_fibre,formatting=smart /dev/foo
mkfs.reiser4 -o create=ccreg40,compress=gzip1,compressMode=conv,cluster=8K,fibration=ext_3_fibre,formatting=extents /dev/foo
mkfs.reiser4 -o create=ccreg40,compress=gzip1,compressMode=force,cluster=64K,fibration=lexic_fibre,formatting=tails /dev/foo
mkfs.reiser4 -o create=ccreg40,compress=lzo1,cluster=8K,fibration=ext_1_fibre,formatting=tails /dev/fooIm Folgenden werden die Mount-Optionen aufgeführt (die Optionen, die man jederzeit nach dem Unmounten des Dateisystems verändern kann); diese müssen NICHT eingegeben; Reiser4 wählt für gewöhnlich ein (semi)optimales Set von Optionen aus, die gut laufen:
- tmgr.atom_max_size=N
- tmgr.atom_max_age=N
- tmgr.atom_max_flushers=N
- tree.cbk_cache.nr_slots=N
- flush.relocate_threshold=N
- flush.relocate_distance=N
- flush.scan_maxnodes=N
- optimal_io_size=N
- bsdgroups
- 32bittimes
- mtflush
- nopseudo
- dont_load_bitmap
Beschreibung der Mount-Optionen:
[WORK IN PROGRESS !]
- tree.cbk_cache.nr_slots=N hiermit wird die Größe des Lookaside Caches festgelegt, in dem laut Nikita Danilov's Blog bzw. diary eine Anzahl der letzten Blätter (Objekte), die eingelesen wurden, zwischengespeichert werden - dies kann u.a. bei Datenbankenoperationen von Vorteil sein. Der Standardwert wird über folgenden Algorithmus festgelegt: "Default is nr_free_pagecache_pages() / 2 at mount time."
- optimal_io_size=N damit wird die optimale Datelese- und schreibgröße festgelegt, standardmäßig ist 64 kiB (65536) vorgegeben, das jedoch für heutige Verhältnisse eine eher konservative Durchsatzrate erreicht - daher sind eher 512 oder sogar 2048 zu empfehlen (512 * 1024; 2048 * 1024)
- dont_load_bitmap Hiermit wird festgelegt, dass beim Mounten nicht die Bitmap geladen bzw. eingelesen wird. In allen Bitmap Blöcken zusammen ist festgehalten, wo sich freier Speicherplatz auf dem Laufwerk befindet und wo nicht. Diese Mount-Option kann in der heutigen Zeit besonders sinnvoll sein mit Partitionen, die recht groß sind (ca. ab 20 GiB) oder bei Platformen mit wenig Arbeitsspeicher, bei denen jedes MiB freier Speicher zählt. Dadurch kann das Mounten beträchtlich beschleunigt werden.
generelle und spezielle Infos zu reiserfs:
* http://en.wikipedia.org/wiki/ReiserFS
* The structure of the Reiser file system (by Florian Buchholz)
* Beschränktes Schreiben - Schreibbarrieren (Linux Magazin)
* reiser4: 1. internal tree - a very occasional diary. (von Nikita Danilov, einem der Entwickler von reiser4)
(FIXME: needs more information, optimally from the developers at former namesys.com, postings of Hans Reiser, etc.)
Tuning-Sektion:
- um unnötige Leistungseinbußen zu vermeiden, sollten beide Dateisysteme mit noatime,nodiratime gemountet werden (info: http://en.tldp.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3/chap6sec73.html
- oder auf neueren kerneln relatime (http://lwn.net/Articles/244829/, http://www.lesswatts.org/tips/disks.php )
Tuning/Tweaks speziell für Reiser4:
WORK IN PROGRESS !
bis ich Zeit finde, das vollständig auszuführen, verweise ich zunächst auf englischsprachige Resourcen:
Reiser4 Gentoo FAQ (forums.gentoo.org)
ReiserFS tuning thread, the mother of all "ricer" threads
(forums.gentoo.org)Wer Probleme mit dem Datendurchsatz (vor allem beim Schreiben) hat, sollte sich folgende Option einmal zu Gemüte führen:
optimal_io_size=N
nach persönlichen Erfahrungen ist der voreingestellte Wert viel zu klein für heutige Verhältnisse und bremst reiser4 nur unnötig aus, darum sollte reiser4 probeweise mit folgenden Werten gemountet werden:
(512 kiB * 1024)
oder
(2048 kiB * 1024)
Tuning/Tweaks speziell für reiserfs:
- mounte das dateisystem mit commit=600 (das sind dann 10 minuten)
das ist besonders hilfreich im Laptop-Betrieb, wenn die platte in den standby-modus schaltet und nicht so oft anlaufen soll, dies beschreibt, wie oft auf die platte geschrieben werden soll
- falls es mal etwas schneller gehen soll (z.B. ein großes Backup auf eine Backup-Platte zu spielen; hierbei sollte aber die Stromversorgung gewährleistet sein), kann man auch data=writeback hinzufügen
(Quelle: Linux-Magazin 2004/11)
- alternativ gibt es noch: data=ordered (standard), data=journal (am sichersten) (nachzulesen auf: (Linux-Magazin 2004/11))
- data=notail hierbei wird auf das Tail-packing verzichtet (bei neueren kerneln gibt man einfach notail an, z.B. -o notail)
(Quelle: Linux-Magazin 2004/11)
mehr spezielles folgt später
Zuletzt bearbeitet:
