ich wollte noch mal was zum Vergleich mit BeFS sagen. An sich liegt der Vergleich des Ansatzes von ReIFS mit dem BeFS sicher nahe, aber nachdem, was sich anhand der Beschreibung über ReIFS sagen läßt, wird dort doch ein anderer Ansatz verfolgt. ReIFS kann man demnach eher mit dem geplanten WinFS im neuen Windows ("Longhorn") vergleichen: als Basis dient ein "normales" File-System (egal, ob NTFS oder ReiserFS oder sonst irgendwas), das dann noch zusätzlich mit einem kleinen (relationalen) DB-Server im Hintergrund angereichert wird. Das heißt, bei sämtlichen Tranksaktionen auf dem File-System, die auch die Datenbank betreffen, muß neben dem reinen FS-Update auch parallel der Inhalt der Datenbank geprüft und ggfs. angepaßt werden.
Demgegenüber ist das BeFS kein "normales" File-System mit einem DBMS dabei, BeFS *ist* die Datenbank. Es kann folglich zu keinen Inkonsistenzen zwischen der eigentlichen Datei und den Metainformationen kommen, da diese auf einem BeFS-Volume direkt an der Datei dranhängen bzw. dazugehören.
Meiner Meinung nach ist der BeFS-Ansatz eindeutig der praktikablere. Für wohl locker 95% der Anwendungen von ReIFS (oder auch WinFS) ist BeFS ebenso geeignet, und die restlichen 5% lohnen in keinster Weise den Aufwand. Ich bin auch mal gespannt, wie sich ReIFS (und WinFS) in der Praxis so zeigen. MS hat offenbar erhebliche Probleme mit WinFS, weshalb wohl zur Diskussion steht, es doch nicht in "Longhorn" einzubauen, sondern erst später nachzureichen. Soweit ich mich jetzt entsinnen kann, liegen die Probleme in erster Linie in auftauchenden Inkonsistenzen zwischen eigentlichen FS und Metadaten in der DB begründet, und genau da sehe ich auch das Problem mit dem ReIFS-/WinFS-Ansatz. Für mich ist das File-System eine möglichst kompakte Einheit mit so wenig OVerhead wie möglich, um die Systemkonsistenz nicht zu gefährden. Und da dann einen Datenbank-Server reinzupacken, finde ich etwas daneben. Man muß ja daran denken, daß bei jedem cp, mv, rm, tar usw auf einem ReIFS-Volume auch Inserts/Updates/Deletes in der Datenbank durchgeführt werden müssen, und zwar transaktionskonsistent, d.h. falls aus irgendeinem Grund die Transaktion auf dem reinen File-System fehlschlägt, dann darf auch die Änderung in der Datenbank nicht festgeschrieben werden. Umgekehrt gilt das dann natürlich ebenso.
So ganz verstehe ich das auch nicht. Mit dem an BeFS angelehnten File-System von OpenBeOS existiert eine Open-Source-Implementierung unter BSD-(artiger)-Lizenz. Weshalb greift man nicht darauf zurück und ergänzt sich dort mit den OpenBeOS-/Haiku-Entwicklern ? Warum muß da (mal wieder) was parallel entwickelt werden ? Hat die Open-Source-Gemeinde etwa zuviele Entwickler, die sich langweilen ? Von einer Zusammenarbeit würde sowohl Linux als auch OpenBeOS/Haiku profitieren.
ich wollte noch mal was zum Vergleich mit BeFS sagen. An sich liegt der Vergleich des Ansatzes von ReIFS mit dem BeFS sicher nahe, aber nachdem, was sich anhand der Beschreibung über ReIFS sagen läßt, wird dort doch ein anderer Ansatz verfolgt. ReIFS kann man demnach eher mit dem geplanten WinFS im neuen Windows ("Longhorn") vergleichen: als Basis dient ein "normales" File-System (egal, ob NTFS oder ReiserFS oder sonst irgendwas), das dann noch zusätzlich mit einem kleinen (relationalen) DB-Server im Hintergrund angereichert wird. Das heißt, bei sämtlichen Tranksaktionen auf dem File-System, die auch die Datenbank betreffen, muß neben dem reinen FS-Update auch parallel der Inhalt der Datenbank geprüft und ggfs. angepaßt werden.
Demgegenüber ist das BeFS kein "normales" File-System mit einem DBMS dabei, BeFS *ist* die Datenbank. Es kann folglich zu keinen Inkonsistenzen zwischen der eigentlichen Datei und den Metainformationen kommen, da diese auf einem BeFS-Volume direkt an der Datei dranhängen bzw. dazugehören.
Meiner Meinung nach ist der BeFS-Ansatz eindeutig der praktikablere. Für wohl locker 95% der Anwendungen von ReIFS (oder auch WinFS) ist BeFS ebenso geeignet, und die restlichen 5% lohnen in keinster Weise den Aufwand. Ich bin auch mal gespannt, wie sich ReIFS (und WinFS) in der Praxis so zeigen. MS hat offenbar erhebliche Probleme mit WinFS, weshalb wohl zur Diskussion steht, es doch nicht in "Longhorn" einzubauen, sondern erst später nachzureichen. Soweit ich mich jetzt entsinnen kann, liegen die Probleme in erster Linie in auftauchenden Inkonsistenzen zwischen eigentlichen FS und Metadaten in der DB begründet, und genau da sehe ich auch das Problem mit dem ReIFS-/WinFS-Ansatz. Für mich ist das File-System eine möglichst kompakte Einheit mit so wenig OVerhead wie möglich, um die Systemkonsistenz nicht zu gefährden. Und da dann einen Datenbank-Server reinzupacken, finde ich etwas daneben. Man muß ja daran denken, daß bei jedem cp, mv, rm, tar usw auf einem ReIFS-Volume auch Inserts/Updates/Deletes in der Datenbank durchgeführt werden müssen, und zwar transaktionskonsistent, d.h. falls aus irgendeinem Grund die Transaktion auf dem reinen File-System fehlschlägt, dann darf auch die Änderung in der Datenbank nicht festgeschrieben werden. Umgekehrt gilt das dann natürlich ebenso.
So ganz verstehe ich das auch nicht. Mit dem an BeFS angelehnten File-System von OpenBeOS existiert eine Open-Source-Implementierung unter BSD-(artiger)-Lizenz. Weshalb greift man nicht darauf zurück und ergänzt sich dort mit den OpenBeOS-/Haiku-Entwicklern ? Warum muß da (mal wieder) was parallel entwickelt werden ? Hat die Open-Source-Gemeinde etwa zuviele Entwickler, die sich langweilen ? Von einer Zusammenarbeit würde sowohl Linux als auch OpenBeOS/Haiku profitieren.
Tschö,
Carsten