# Gutgemeinte Warnung vor Reiser4

## Lore

Hallo, hatte nun 2,5 Monate auf meinem Notebook Reiser4 laufen.

Heute hab ich es wieder durch ein Reiser3 ersetzt.

Der X-Server ist eingefroren und da ich es eilig hatte, habe ich das Notebook einfach ausgeschaltet. Das hat genüg um das Dateisystem so nachhaltig zu stören, das das Notebook selbst nach einer Dateisystem-Reperatur nicht mal mehr init richtig starten konnte.

Das ist mir nun zum zweiten Mal in kurzer Zeit passiert (beim ersten Mal hat die Reperatur allerdings geholfen).

Gut dass ich so was geahnt hatte und regelmäßige Backups angelegt habe...

Zu gute halten muss man Reiser4, dass es wirklich merklich schneller ist als Reiser3 und ich freu mich schon, wenn es wirklich stabil ist.

Aber seid vorsichtig damit und glaub den Spruch von der "Military Grade Security" (noch) nicht.

----------

## Lenz

Also ich hab vor einer Woche alle meine 3.6er auf 4er Partitionen umgerüstet, und hatte bislang keine Probleme (der Rechner hat sich "dank" eines nun gelösten Lüfterproblems sogar mehrmals ohne Runterfahren ausgeschaltet).

Das einzigste was mir negativ aufgefallen ist, und für was ich nur die Lösung gesehen habe zu Reiser 3.6 zurückzugehen war die /net Partition, auf die wenn ich was runterlade ständig mit 20 kb/sec - 120 kb/sec geschrieben wird. Dann fängt die Platte auf einmal richtig das arbeiten an; weiß eigentlich nicht wieso; er schreibt dann einfach ständig statt wie bei 3.6 alle 10 sec mal (an async liegt's glaub ich nicht, das hatte ich in den Optionen extra nochmal mit angegeben).

Auf der / Partition sehe ich aber nur Vorteile: emerge --sync ist wesentlich schneller, da ist der Unterschied extrem find ich.

Trotzdem fühle ich mich mit meinem Komplettbackup sicherer.  :Wink:  Also ich würde gar nicht mal mehr so von Reiser4 abraten, aber ich würde zu Komplettbackup (z.B. mit 'dar', funktioniert super) raten.

Ich hab mir nämlich schonmal eine ext3 und Reiser 3.6 Partition zerschossen, auch durch Absturz (damals irgendein blöder Konflikt mit TV-Karte, der auch gelöst ist mittlerweile). Also passieren kann einem sowas glaub ich mit jedem Dateisystem. Wobei's mir seit ich Komplettbackups mache nicht mehr passiert ist (scheint so eine Art Gesetz zu sein  :Wink: ).

-- Lenz

----------

## andix

Ich hab jetzt seit 4 Monaten Reiser4 auf meinem Notebook und habe noch keine Probleme gehabt. Mir ist sicher schon so an die 20x der Strom ausgegangen und nie ist etwas passiert. Danach repariert sich das Dateisystem sehr schnell (in ein paar Sekunden) und funktioniert wieder tadellos.

Also aus meiner Sicht ist Reiser4 TOP  :Smile: 

----------

## MarMor

Ich hab meine /root-Partition heut auf Reiser4 umkopiert und auch gleich als Antwort bekommen, dass ich die alte Partition besser erst mal aufheben sollte...

Ist insgesamt sehr gespalten, was man so liest. Werd die alte Partition also erstmal behalten  :Confused: 

Backups werd ich von der /root-Partition aber nicht machen - wär zwar im Fall des Falles dann ärgerlich, aber die wirklich wichtigen Sachen sind eh auf der /home-Partition... (da fällt mir ein, _das_ könnt ich mal wieder sichern  :Wink: )

----------

## Lore

Hm, ich hab als reiser4 Kernel den nitro3-2.6.9 benutzt. Da ist es z.B. auch eine belegte Tatsache, das bei zuvielen Schreib/Lesezugriffen (z.B. emerge sync) das System einfriert, wenn man Hyper Threading aktiviert hat.

Das ist ein echtes Problem, mit dem ich auch zu kämpfen hatte. Und so ein Problem sollte definitiv nicht in einer als stabil geltenden Version von reiser4 auftreten.

----------

## Deever

 *Lore wrote:*   

> Und so ein Problem sollte definitiv nicht in einer als stabil geltenden Version von reiser4 auftreten.

 Sorry, wenn ich schon wieder rumlästere, aber Reiser* galt IMHO noch nie als stabil. Das Gejammere von Reiser-Usern ist je länger je mehr einfach nur noch langweilig. Klar: Auf vielen Rechnern wird es mit Erfolg eingesetzt. Vermutlich nicht umsonst ist es mindestens bei SuSE das Standard-Dateisystem. Sicher: Auch andere Dateisysteme haben Crashes mit Datenverlust. Trotzdem: Wenn IIRC mindestens über 85% aller geschrottetten Dateisysteme Reiser* sind und auch bei ein paar Prozent allgemeiner Probleme plötzlich herauskommt, daß es dann an Reiser* lag, ist das Grund genug, es lieber sein zu lassen. Ein Kumpel von mir setzt das ein und hat keinerlei Probleme damit. Aber mir kommt das sicher nie auf die Platte.

Gruß,

/dev

----------

## Lenz

 *Lore wrote:*   

> Hm, ich hab als reiser4 Kernel den nitro3-2.6.9 benutzt. Da ist es z.B. auch eine belegte Tatsache, das bei zuvielen Schreib/Lesezugriffen (z.B. emerge sync) das System einfriert, wenn man Hyper Threading aktiviert hat.
> 
> Das ist ein echtes Problem, mit dem ich auch zu kämpfen hatte. Und so ein Problem sollte definitiv nicht in einer als stabil geltenden Version von reiser4 auftreten.

 

Das Problem hatte ich komischerweise mit den gentoo-dev-sourcen (ohne Hyper Threading) und seit ich die nitro-sourcen verwende nicht mehr!

 *Deever wrote:*   

> Klar: Auf vielen Rechnern wird es mit Erfolg eingesetzt. Vermutlich nicht umsonst ist es mindestens bei SuSE das Standard-Dateisystem. 

 

Ich gehöre wohl auch zu denen, die es seit (beinahe) jeher einsetzen und gut damit fahren. Mit ext3 hatte ich eherlich gesagt mehr Probleme (2x FS geschrottet), also sowas ist immer sehr subjektiv.

 *Deever wrote:*   

> Trotzdem: Wenn IIRC mindestens über 85% aller geschrottetten Dateisysteme Reiser* sind[...]

 

Quelle?

 *Deever wrote:*   

> Aber mir kommt das sicher nie auf die Platte.

 

Das ist dein gutes Recht.

Ich muss sehen, wie sich die Sache mit Reiser4 bei mir entwickelt. Mit ReiserFS 3.6 bin ich auf jedenfall gut gefahren, und zur Not hab ich ein Komplettbackup mit dem das System in 15 Minuten wieder voll funktionstüchtig ist. Da nehm ich das "Risiko" in Kauf und experimentiere ein bisschen. Bis jetzt bin ich von Reiser4 positiv überrascht, vor allem beim emerge --sync. Vielleicht sollte man sich, wenn man auf extX o.a. setzt sich eine Reiser4 Partition für den Portagetree gönnen.

----------

## stahlsau

Ich benutz auch kein reiser* mehr. Ich hatte zwar keine Probleme mit der stabilität, aber dafür war´s grottenlangsam. Ich hab reiser4 immer mal wieder getestet seit die ersten betas rauskamen und natürlich auch die stable jetzt kürzlich, weil alle immer schrieben es sei so schnell; bei mir war es immer wesentlich langsamer als ext2/XFS/JFS. Ich hab sogar mal nen ganzen Tag lang minibenchmarks laufen lassen (tar/untar, kernel entpacken und compilen etc) =>reiser4 ~ ext3, eher langsamer.

Installiert hab ich das FS nach aktuellen howtos, mal mit, mal ohne zusätzliche parameter...keine Änderung.

----------

## c07

 *Lenz wrote:*   

> Vielleicht sollte man sich, wenn man auf extX o.a. setzt sich eine Reiser4 Partition für den Portagetree gönnen.

 

Gerade für diesen Zweck würd ich erwarten, dass von den üblichen Dateisystemen ext2 mit Abstand das Schnellste ist. Insbesondere kann man sich das Journal wirklich sparen, wenn man schon eine eigene Partition für den Portagetree nimmt (im Schadensfall kann man hier einfach neu formatieren).

Wobei zumindest langfristig für die Performance entscheidend sein dürfte, wie gut benachbarte Dateien beieinandergehalten werden. Aus diesem Grund könnte eine eigene Partition immer rentabel sein. Ebenso wird der Wechsel auf ein anderes Dateisystem allein deshalb vorteilhaft sein, weil es dann erstmal frisch ist.

----------

## Lore

Noch ein Punkt den ich an Reiser4 sehr angenehm fand:

Beim booten dauerte der Filesystem-Check ein paar Sekunden weniger als z.B. bei reiser3, da kein Journal "replayed" werden musste (bedingt durch die Geschichte mit dem atomaren Schreiben, nehm ich mal an).

Klingt jetzt vielleicht blöd, aber mir gefiehl es, wenn die Boot-Meldungen ohne längere Unterbrechungen über den Bildschirm rauschten  :Rolling Eyes: 

Übrigens: Zus seligen Dos-Zeiten hatte ich auch noch nie einen Datenverlust bei meiner FAT16 Platte. Scandisk hat halt hin und wieder ein paar Stündchen gebraucht, aber solche Total-Ausfälle wie jetzt mit Reiser4 sind mir vorher noch nie passiert.

Die Ideen hinter Reiser4 lesen sich so elegant und durchdacht. Mir gefällts einfach. Und deshalb schieb ich das Versagen mal auf den Frickel-Nitro-Kernel und nicht auf Reiser4...  :Very Happy: 

----------

## daemonb

Seit ich linux nutze ..... (1997)

Habe ich schon einige dateisysteme ausprobiert und muss zugeben, auch schon so einige geschrottet zu haben... Mein erstes war glaube ich ein ext2, dann ein reiser, den schlimmsten absturz hatte ich mit xfs, als auf einmal 60 GB weg waren.

Meisten kommt sowas aber wirklich vom kernelgefrickel oder DAU verhalten.... Schwester macht rechner einfach aus....

Ich finde die Diskussion dieses Dateisystem besser dieses schlechter total unnötig.

Man kann jedes Dateisystem auf irgendeine weise in die Knie zwingen und das muss nicht immer gezwungenermaßen am Dateisystem selbst liegen.

Habe inzwischen reiser4 auf einigen meiner System am laufen und muss sagen das ich äusserst zufrieden bin.....

Man sollte es halt wenn man ein stabiles system will nicht mit den kernelpatches übertreiben.

Mache vorallem bei neuen Dateisystem immer Vanillakernel + Dateisystempatches.

Alles ein für und wieder ....

bis denne

DaemonB

----------

## Turrican

Ehrlich gesagt: Ich nutze reiserfs, seit es SuSE unterstützt und hatte, bis auf Kleinigkeiten durch Stromausfälle oder Abstürze, niemals irgendwelche Datenverluste. Bis auf die paar Kinderkrankheiten war es bei mir wesentlich zuverlässiger und v.a. viel schneller wieder gefixed als ext2.

----------

## gentop

Also ich benutze aus Prinzip nur ext3 - da man so viel schlechtes über reiser hört... *gg*

----------

## boris64

 *gentop wrote:*   

> Also ich benutze aus Prinzip nur ext3 - da man so viel schlechtes über reiser hört... *gg*

 

dito *g*

unter rasierfs 3.6 waren nach jedem stromausfall/systemabsturz immer jede menge einstellungsdateien futsch

(~/.mozilla, ~/.licq, also einstellungsdateien von zur laufzeit geöffneten programmen)

und diesen frust möchte ich mir nicht wirklich noch mal antun.

seit einem ext3-only system sind diese probleme geschichte, wer also

seine daten gerne in sicherheit weiss, dem kann ich ext3 nur empfehlen.

----------

## malachay

 *borisdigital wrote:*   

> 
> 
> [...]seine daten gerne in sicherheit weiss, dem kann ich ext3 nur empfehlen.

 

Auch hier wieder eine andere Meinung. Ich hatte 2 FS-Crashs mit ext3, alles weg, nach einem "harmlosen" Stromausfall. MIt Reiser3 hatte ich nie Probleme. Nutze zur Zeit XFS womit ich auch sehr zufrieden bin. Hab eine Zeit lang Reiser4 auf meine / Partition betrieben muss aber sagen das die Geschwinidigkeit nicht sooo doll war. Ausser im Portage-Tree, da rast reiser4. 

Musste dann noch ein paar mal das Reiser4 reparieren lassen was auch recht lange dauert, und bin deswegen wieder zu xfs geswitched, das musste ich bis jetzt noch nie reparieren lassen, das läuft und läuft und läuft....

----------

## DarKRaveR

Mal einige GEdanken dazu:

ext2 schön und gut, aber bei einem absturz/crash sind dei Daten doch erheblich gefährdet, ext3 journaling, schön und gut, aber da es strukturell ein ext2 ist, sehe ich folgende Probleme:

Zu viele Beschränkungen in Punkto Dateigröße, Dateisystemgröße und Anzahl der Einträge in einem Verzeichnis. Dazu kommt, es performed ziemlich schlecht.

Ein Verzeichnis ist bei ext2 letztendlich eine Datei, wenn ich eine Datei xyz stat-e, oder öffne, muß die liste linear durchsucht werden, andere FSes, ala xfs organisieren das Verzeichnis in einem BTREE, bei vielen stat calls etc., sofern nicht alles im cache liegt, weil viel ram und wenige IO operationen, ist der perfomanceunterschied trotz journaling erheblich.

xfs/jfs (bei reiser weiß ich es nicht) skalieren generell einfach erheblich besser. Die ports mögen noch nicht so alt sein, fakt ist aber, daß jfs und xfs schon einige jahrzente mehr in produktionssystemen, entwicklung und technik auf dem buckel haben, als z.B. reiser ....

Jedes der FSes hat so einige features, xfs (klar weil sgi) hat zum beispiel die Möglichkeit einer realtime section, die anders behandelt wird, für streaming apps etc.

Was mir da noch einfällt: ext2/3 streut die inode listen zu statisch, bei den anderen journaling FSes können diese reorganisiert und verlagert werden, um bessere performance zu bekommen, je nachdem ob viele kleine/große files vorhanden sind usw. man kann also ohne weiteres ein File erzeugen, welches 80% des FS einnimt, oder das es durch inode tables zerklüftet wird.

JEmand meinte, es gäbe kein journal replay bei reiser4 - Das muß ich doch stark bezweifeln, journaling wäre witzlos, wenn das journal nicht replayed werden müßte - Es hängt im wesentlichen davon ab:

Wieviele Files waren geöffnet, für welche operationen, wieviele operationen fanden gleichzeitig auf dem file statt (auch schreiben, man bedenke region locks).

NAch einem crash müssen: Neu angelegte files, die nicht fertig geschrieben wurden (nicht geschlossen wurden) entfernt werden - geht ganz schnell, files die gelesen wurden dürften im normal fall unerheblich sein, aber dateien die existierten und partiell beschrieben wurden etc. erfordern doch einige arbeit, denn muß muß ein vollständiges rollback stattfinden.

Hier kommts drauf an, wie es implementiert wurde, soll die datei schnell zum schreiben verfügbar sein, so wird man, den überschriebenen teil getrennt ablegen und danach durch fixen einiger inodes einkleben ... solange die transaktion nicht vollständig ist, kann man also die veränderung wegwerfen, schnelles replay, starke fragmentierung.

Alternative: Man legt die update getrennt ab, merged die updates und die originalteile der datei in einen groß genuges freies segment im fs, danach werden ursprungsdatei+updates 'verworfen' - auch hier ist ein rollback recht schnell zu erledigen, problem: lange wartezeit nach dem schließen der datei, bis sie konsistent im dateisystem vorhanden ist - sprich nach dem close runterfahren bedeutet langes warten bis alles konsistent udn gesanced ist (falls im cache).

Letzte Altrnative:

BEim öffnen der Datei wird auf einem freien platz eine vollständige kopie angelegt, danach die updates auf der kopie durchgeführt, sowie diese abgeschlossen sind kann die originaldatei verworfen werden - Problem, mitunter lange wartezeit beim öffnen der datei zum schreiben ....

Problem der beiden letzten verfahren allgemein: Es muß immernoch genug platz im fs als reserve sein, damit gemerged werden kann, bzw. die kopie angelegt werden kann.

Letztere Methode wird übrigens bei ntfs verwendet, der schöne wegfallende systembereich (größer, je größer die hdd) beherbergt unter anderem diese Reserve - Außerdem schön zu merken, eine open mti schreibrechten auf eine mehrere GB große datei dauert eien ganze weile und die hdd läuft wegen dem kopiervorgang amok ....

So, das wars erstmal    :Very Happy: 

----------

## c07

 *DarKRaveR wrote:*   

> Zu viele Beschränkungen in Punkto Dateigröße, Dateisystemgröße und Anzahl der Einträge in einem Verzeichnis. Dazu kommt, es performed ziemlich schlecht.

 

Für normale Anwendungen sind die Beschränkungen bei 4 KB Blockgröße heute noch kein Problem: 16 TB Dateisystemgröße, 2 TB Dateigröße, nahezu unbeschränkt viele Dateien pro Ordner (die Liste muss halt in 2 TB passen; davon allerdings nur 32768 Unterordner). Praktisch wird es nur zu langsam, wenn die Verzeichnisse zu groß werden und man keine B-Bäume verwendet. Die kann ext2/3 optional aber auch (mit tune2fs -Odir_index ). Sie sind tendenziell langsamer und skalieren nur besser.

Generell hängt die Performance immer von der konkreten Verwendung ab und von dem, was man überhaupt als "Performance" bezeichnet (insbesondere Durchsatz oder Reaktionsschnelligkeit), wobei auch noch der gewählte IO-Scheduler ziemlichen Einfluss hat. In mancher Beziehung ist ext2 wesentlich schneller als die neueren Dateisystemem, insbesondere wenn man auch noch eine Verwendung für die gesparte CPU-Last hat.

 *DarKRaveR wrote:*   

> ext2/3 streut die inode listen zu statisch, bei den anderen journaling FSes können diese reorganisiert und verlagert werden, um bessere performance zu bekommen

 

Die statischen Inodes sind nur schlecht für die Flexibilität bzw. brauchen viel Platz. Sie sind aber in der Regel schneller als dynamisch angelegte Inodes, weil sie nicht gesucht werden müssen und nicht fragmentieren können. Die Grundfragmentation, die sie erzeugen, ist praktisch irrelevant.

----------

## DarKRaveR

 *c07 wrote:*   

>  *DarKRaveR wrote:*   Zu viele Beschränkungen in Punkto Dateigröße, Dateisystemgröße und Anzahl der Einträge in einem Verzeichnis. Dazu kommt, es performed ziemlich schlecht. 
> 
> Für normale Anwendungen sind die Beschränkungen bei 4 KB Blockgröße heute noch kein Problem: 16 TB Dateisystemgröße, 2 TB Dateigröße, nahezu unbeschränkt viele Dateien pro Ordner (die Liste muss halt in 2 TB passen; davon allerdings nur 32768 Unterordner). Praktisch wird es nur zu langsam, wenn die Verzeichnisse zu groß werden und man keine B-Bäume verwendet. Die kann ext2/3 optional aber auch (mit tune2fs -Odir_index ). Sie sind tendenziell langsamer und skalieren nur besser.
> 
> 

 

Das PRoblem bei einer Blocksize ist der interne Verschnitt, bei einer 4K Blocksize, kommst Du auf 2K Verschnitt je Datei, rechne das mal hoch bei 1 Mio Files, das sind dann läppische 2 GB im Mittel ... 

Ein B Baum ist tendenziell langsamer, okay, uhm, linear suche, gegen log_b - Ich stimme Dir eindeutig zu. Natürlich bringen B*-Trees bei kleinen verzeichnissen nicht sonderlich viel, wegen dr Verwaltung. daher wird es in der regel so gemacht: Hat die liste weniger als z.B. 512 Einträge, lineare Suche, sonst b-tree.

 *Quote:*   

> 
> 
> Generell hängt die Performance immer von der konkreten Verwendung ab und von dem, was man überhaupt als "Performance" bezeichnet (insbesondere Durchsatz oder Reaktionsschnelligkeit), wobei auch noch der gewählte IO-Scheduler ziemlichen Einfluss hat. In mancher Beziehung ist ext2 wesentlich schneller als die neueren Dateisystemem, insbesondere wenn man auch noch eine Verwendung für die gesparte CPU-Last hat.
> 
> 

 

Nunja, am Beispiel von xfs sei dir gesagt: Dank Allocation Groups sind mehrere IO Prozesse parallelisierbar, bottleneck ist da definitiv die Disk oder das RAID, ext 2/3 muß die IOs sequentiell absetzen - dazu kommt, das ext2/3 beim syncen massiv last erzeugt, xfs hingegen z.B. nicht, weil die IOs wohl anders gescheduled werden ...

Davon ab ist ein direkter IO Transfer von der Disk in den Userspace eine nette sache, wenn man derartige Features brauchen sollte ...

 *Quote:*   

> 
> 
>  *DarKRaveR wrote:*   ext2/3 streut die inode listen zu statisch, bei den anderen journaling FSes können diese reorganisiert und verlagert werden, um bessere performance zu bekommen 
> 
> Die statischen Inodes sind nur schlecht für die Flexibilität bzw. brauchen viel Platz. Sie sind aber in der Regel schneller als dynamisch angelegte Inodes, weil sie nicht gesucht werden müssen und nicht fragmentieren können. Die Grundfragmentation, die sie erzeugen, ist praktisch irrelevant.

 

Stimmt so auch nicht ganz. Triple Extension zum auffinden der einzelnen Datenblöcke ist auch nicht grade Resourcenschonend. Natürlich wird durch die statischen Inodes gewährleistet, daß eine Datei nicht klassisch fragmentiert, man weiß ja dank der Inode, wo der nächste Block ist, nur der kann sonsto liegen, genauso wie die extent blöcke. Das bedeutet massive seeks quer über die platte - moderne JFSes sorgen dafür daß die datei linear liegt, das heißt du hast im wesentlichen sector/track seeks, weil die datenblöcke linear hintereinander liegen - Und das macht schon einen erheblichen Unterschied.

----------

## c07

 *DarKRaveR wrote:*   

> Das PRoblem bei einer Blocksize ist der interne Verschnitt, bei einer 4K Blocksize, kommst Du auf 2K Verschnitt je Datei, rechne das mal hoch bei 1 Mio Files, das sind dann läppische 2 GB im Mittel ...

 

Die 4 KB Blockgröße ist auch bei den anderen Dateisystemen üblich. Reiser hat daneben optional noch eine feinere Unterteilung, was aber je nach den konkreten Umständen Performance kosten kann.

 *DarKRaveR wrote:*   

> Nunja, am Beispiel von xfs sei dir gesagt: Dank Allocation Groups sind mehrere IO Prozesse parallelisierbar, bottleneck ist da definitiv die Disk oder das RAID, ext 2/3 muß die IOs sequentiell absetzen - dazu kommt, das ext2/3 beim syncen massiv last erzeugt, xfs hingegen z.B. nicht, weil die IOs wohl anders gescheduled werden ...

 

Allocation Groups hat ext2 auch, sie heißen nur nicht so. Parallelisierbarkeit kommt ohnehin nur im RAID zur Geltung, sonst muss sowieso alles sequenziell auf die Platte, und dafür ist der IO-Scheduler und nicht das Dateisystem zuständig, sofern es sich um unterschiedliche Prozesse handelt.

Die CPU-Last ist normalerweise besonders bei Reiser und XFS eine Schwäche, während ext2 von der primitiven Verwaltung profitiert. Würd mich sehr wundern, wenn das ausgerechnet beim Syncen anders sein sollte.

 *DarKRaveR wrote:*   

> Triple Extension zum auffinden der einzelnen Datenblöcke ist auch nicht grade Resourcenschonend.

 

Ja, für lauter große Dateien, die womöglich auch noch sequenziell geschrieben oder gelesen werden, ist ext2/3 auch wenig geeignet. Wobei dreifach indirekte Blöcke erst bei Dateien ab 4 GB gebraucht werden; bis 4 MB reicht bei 4-KB-Blöcken einfach indirekt.

 *DarKRaveR wrote:*   

> Natürlich wird durch die statischen Inodes gewährleistet, daß eine Datei nicht klassisch fragmentiert

 

Mit der dateiinternen Fragmentierung haben die Inodes gar nichts zu tun. Extents können hier einer Bitmap zwar wirklich überlegen sein, aber der Preis ist ein höherer Aufwand bei der Suche nach Blocks und u.U. eine schlechtere Lage gegenüber dem Verzeichnis.

 *DarKRaveR wrote:*   

> Das bedeutet massive seeks quer über die platte

 

Eher umgekehrt. ext2/3 suchen streng aufsteigend nach freien Blöcken und fangen erst am Partitionsende wieder vorn an. Wenn es Löcher gibt und die Partition nicht sehr voll ist, sind sie zumindest klein. Wenn dagegen primär nach größenmäßig passenden Extents gesucht wird, können wesentlich größere Sprünge auftreten, sobald sie unvermeidbar sind. Wobei die Algorithmen natürlich versuchen, einen möglichst günstigen Kompromiss zu finden, und der hängt halt wieder von der konkreten Nutzung ab.

----------

## DarKRaveR

@c07:

Stimmt kleine bloksize bedeutet performanceverlust, ist halt schwer gegensätzliche Minimierungsanforderungen zu optimieren   :Wink:  .

Humm, man könnte bei ext2 jeden inode block als allocation group ansehen, das habe ich in der Tat übersehen. Was Die paralellisierbarkeit anbelangt: wenn du lese/schreibprozesse in verschiedenen AllocGroups hast, kannst Du die IO Prozesse interleaven, insofern parallelisieren, da du sehr leicht interleaven kannst und ein IO Prozess den anderen nicht aufhält zumal HDDs ja auch einen cache haben und command queing unterstüzten ... innerhalb einer AllocGroup gestaltet sich das schon schwieriger ....

Ich zitiere das mal:

 *Quote:*   

> Because each allocation group is effectively its own independent entity, the kernel can interact with multiple allocation groups simultaneously.

 

Scheint so, daß sonst, innerhalb einer AllocGroup bei komplizierten IO Operationen serialisiert werden muß ....

Was die sync performance anbelangt, anscheinend versuchen Reiser als auch xfs und andere IO Operationen stärker zu cachen und zurückzuhalten als ext2, sprich datei wird kreiert, es wird der platz reserviert, aber nicht physikalisch allokiert, falls sich raustellt es ändert sich zwischenzeitlich noch was, oder es wird wieder freigegeben. Einfaches Beispiel wäre ein append, so kannst du dafür sorgen, daß möglichst lange lineare chunks entstehen.....

Was extents anbelangt: wenn du auf einen block zeigst, der sonstwo liegen kann ist das einfach ein unnötiger overhead, je mehr ebenen und je mehr dieser zwischenblöcke, die weit verstreut sein können, umso heftiger wird das ganze. Auf der anderen seite, wenn du die extents in b-trees verwaltest und für große lineare chunks sorgst, kannst du mit weniger einträgen (im idealfall einem) das komplette file auffinden, da du nur startadresse+anzahl blöcke brauchst ... Das ist definitiv eine Abwägungssache ... Andereseits wenn die Inodes in einem btree liegen, kannst du auch sehr viel schneller die inode auf der platte auffinden, sagen wir, du willst inode nummer xyz finden, der baum ist nicht so tief, das auffinden bei statischen inode tables erordert (wenn sie denn auch sortiert sind) eine lineare suche, sprich, ich schaue nach, in welchem inode block liegt die inode, dort suche ich dann wieder linear, je nachdem wie groß die sind, dauert das ganze - sind die einzelnenn inode cluster/blöcke klein udn in vielen ebenen hast du im prinzip einen baum, nur daß du in einer inode tabelle, wo du fast keine brauchst die unnötigen nicht wegwerfen kannst,  oder, wenn sie so liegt, daß Du ein file in chunks teilen mußt, sie nicht zur seite schafen kannst ... Auf der anderen Seite macht die Pflege der Tres arbeit und ist nicht trivial   :Wink:  .

Beim Fragmentieren haben wir uns wohl mißverstanden, klassisch war es ja mal so: Mn nimtm den größten chunk, egal wo er ist, füllt den, dann den nächsten passenden und verweist au diesen, ich muß also den chunk durchwandern, um zu reaslisieren, wo es weitergeht, das spare ich mir bei statischen inodes ganz klar, daür wie gesagt, können die chunks wild und wüst über die HDD verteilt sein ....

Zum streng aufsteigenden suchen:

wenn am anfang extrem viele kleine extents sind wird die datei extrem zerklüftet, was halt ungemein problematisch ist in punkto seeking. Andererseits, wenn die extenliste in btrees ist, einmal mit größe als schlüssel und dann mit physikalischer adresse als shlüssel, kannst du extrem schnell ein passends extent, oder eine kleine gruppe von extents finden .....

Beide Techniken scheinen generell Ihre Vor und nachteile zu haben, aber wenn man mal verschiedene sachen auf den unterschiedlichen filesystems testet, wie nen kernel source entpacken, portage syncen etc., unterliegt ext2/3 leider doch recht häufig ....

Ein bedeutender Vorteil von ext2/3 mag sein: Einfache Verwaltung, daher ist die chance für bugs geringer und es war natürlich schnell implementierbar und verfügbar ....

Andereits haben diverse JFSes nativ support für EAs,ACLs und DMAPI an board (gehabt).

Und jetzt noch für die Allgemeinheit: Jedes Dateisystem ist kaputtbar, selbst wenn man annehmen könnte, der Code sei fehlerfrei, isnofern snehmt Euch dasjenige, welche für Eure zwecke die nötigen Features und die best Performance aufweist ... Wir haben ja schließlich die 'Wahl'   :Very Happy: 

----------

## reptile

scotty, you lost me :)

----------

## DarKRaveR

 *reptile wrote:*   

> scotty, you lost me 

 

 :Laughing:  - Ja, wir sind wohl etwas abgedrifted - Hat eigentlih schon einer mal testweise nen Heißenberg Compensator in eine HDD eingebaut ?   :Shocked:   (Unsinn muß manchmal auh sein)

----------

## c07

 *DarKRaveR wrote:*   

> Was Die paralellisierbarkeit anbelangt: wenn du lese/schreibprozesse in verschiedenen AllocGroups hast, kannst Du die IO Prozesse interleaven, insofern parallelisieren

 

Wobei doch eigentlich im Gegenteil eine Entflechtung sinnvoll wär, damit der Plattenkopf nicht dauernd zwischen den Gruppen hin und her hüpfen muss. Der Plattencache kann da nicht sehr viel auffangen. Im Prinzip macht das auch der standardmäßige IO-Scheduler: Von der momentanen Position weit entfernte Zugriffe werden möglichst lang blockiert, außerdem Schreibzugriffe, solang wer lesen will und umgekehrt (das ist zwar schnell, fühlt sich aber langsam an, weshalb der CFQ-Scheduler für Desktops besser ist).

 *DarKRaveR wrote:*   

> Was die sync performance anbelangt, anscheinend versuchen Reiser als auch xfs und andere IO Operationen stärker zu cachen und zurückzuhalten als ext2

 

Ja, das ist ihre wirkliche Stärke, weil dadurch oft IO vermieden oder zumindest vereinfacht werden kann. Aber es bedeutet auch zusätzlichen Verwaltungsaufwand, den sich zumindest ein Dateisystem ohne Journal sparen kann.

 *DarKRaveR wrote:*   

> das auffinden bei statischen inode tables erordert (wenn sie denn auch sortiert sind) eine lineare suche

 

Nein, der Block lässt sich fast direkt aus der Inodenummer berechnen: Einfach modulo Inodes/Gruppe nehmen, ergibt Gruppe und Offset, dazu noch der Offset vom Inodeblock aus dem Gruppendeskriptor, fertig.

 *DarKRaveR wrote:*   

> Zum streng aufsteigenden suchen:
> 
> wenn am anfang extrem viele kleine extents sind wird die datei extrem zerklüftet, was halt ungemein problematisch ist in punkto seeking.

 

ext2 ist nicht gerade für übermäßige Fragmentation berüchtigt. Der erstbeste freie Block wird nur dann genommen, wenn er an der Idealposition liegt (z.B. am bisherigen Dateiende). Sonst werden mindestens 8 Blocks am Stück verlangt, solang das innerhalb der Gruppe möglich ist (in der Bitmap mit den belegten Blocks wird nach ganzen Bytes gesucht, die null sind, was auch noch relativ schnell ist). Die Methode wird allerdings wesentlich schlechter, wenn die Partition sehr voll ist.

----------

## DarKRaveR

@c07: Stimmt, ich vergaß, daß bei ext2 die inode blocks etc. absolut symmetrisch gestreut sind, gleiche größe haben etc. - logisch daß es sich dann größtenteils aritmethisch berechnen lässt.

Ich glaube ich muß mir wohl mal die Implementation anschauen   :Confused:   :Shocked: 

----------

## Gentoo Server

Prinzipell gibt es keinen 100% Schutz gegen FS Fehler.

Auch wenn der code an sich 100% Fehlerfrei ist haben wir doch immer das Problem von dem "Random Reboot" welcher in einem "unsafe time range" passieren kann und dann gibts halt FS Fehler

----------

