Was mich an Btrfs noch so richtig stört ist dass es 10% des verfügbaren Speicherplatzes fest für Metadaten reserviert. Das bedeutet man kann seinen Datenträger nur bis zu 90% befüllen. Ich mal hoffe das wird irgendwann noch gefixt.
ZFS gilt als stabil und ist sogar OpenSource, kann aber lizenzbedingt nicht in den Kernel aufgenommen werden. Außerdem soll btrfs als jüngeres FS (laut Entwickler) noch besser werden.
Hmmm, ja, ZFS wird wohl auch weiterentwickelt, aber Oracle wird den Teufel tun und anfangen ihr als verlässlich geltendes FS gravierend umzumodellieren. Im Allgemeinen vertrauen die Leute ihre Daten nicht irgendwelchen Alpha-Versionen von Dateisystemen an, wie es bei btrfs noch der Fall ist.
Mein Posting kam zwar etwas neg. rüber, war aber nicht so gemeint. Ich wollte nur zum Ausdruck bringen, dass die Entwicklung weitergeht, neue Features kommen hinzu, Portierungen folgen. Zum Glück wurde ZFS nicht von irgendeiner Softwarebude entwickelt sondern von SUN. Darüber hinaus wird das auch schon produktiv eingesetzt. Sowas wichtiges wie ein Dateisystem wird nicht stabil nach 1 a oder durch dessen Deklaration.
sorry aber sun ist zwar groß, aber eben auch nur von menschen gemacht. wenn du z.b. eine platte falsch zu einem zpool zuordnest kann die platte nicht wieder entfernt werden - aussage von sun: wird noch nicht unterstützt. folge war komplettbackup, zpool komplett aufbrechen, neu machen und restore - am wochenende. glücklicherweise haben wir keinen 24/7 betrieb :) ich könnte noch weitere geschichten erzählen wie 2 wochen reaktionszeit (silver support), defekt gelieferte ersatzteile und einfach *AUS*gehende server...
also sun und jetzt nach der übernahme oracle nicht über den klee loben - oracle ist auch voller spezialexperten ( aka softwarebug gefunden, kommentar von oracle "der bug ist bekannt, case closed" )
Auch wenn man 10% an Platz frei lässt, so kann man die Platte doch immer noch mit mehr Daten befüllen, wenn das Dateisystem z.B. nur 5% des Platzes für Metadaten benötigen würde.
10% für Metadaten sind schon viel. Gerade bei heutigen Terrabyte-Platten sind das etliche Gigabytes. Ob sich das inzwischen geändert hat, kann ich aber auch nicht sagen.
Ich weiß zwar nix / nichts / nada über btrfs, aber ist es nicht doch wahrscheinlich, dass es eine Option beim Formatieren geben wird, mit der der reservierte Speicherplatz bestimmt werden kann? Bei Ext3 werden ja auch standardmäßig 5 % für root reserviert, aber der Wert kann per Parameter geändert werden.
(Kann aber auch sein, dass die 10 % aus irgendeinem konzeptuellen Grund fest sind.)
An sich liegt das eher an der Lizenz unter der ZFS liegt. Die Konditionen unter denen ein Einbau in den Kernel möglich sind waren schon lange vor der Entwicklung von ZFS bekannt.
Nur in Ubuntu, weil es da auf maximale Performance getrimmt wurde (und wird), andere Distributionen haben für Desktopuser Optionen gewählt, die auch den Betrieb ohne USV erlauben.
Delayed Allocation nennt man sowas und dies nutzt jedes moderne Dateisystem.
z.B. ist XFS dafür bekannt das es die Daten sehr lange im Speicher (RAM) hält bis es auf die Platte geschrieben wird. Was bei einem Stromausfall zu Datenverlusst führen kann.
Und Canoncial hat wie üblich ohne zu denken 120 Sek Timeout übernommen und schwups sind die Daten weg wenn was passiert.
nein, nicht jedes. Und nach Jahren, in denen sich Anwender darüber aufregten, daß XFS Daten vernichtet, bei crash, hätte jedem klar sein müssen, daß es eine blöde Idee ist. Aber extX war noch nie für Datensicherheit ausgelegt, sondern nur gute benchmark Ergebnisse.
Ein Dateisystem, daß nicht mit sicheren defaults arbeitet, ist Schrott.
Aber extX war noch nie für Datensicherheit ausgelegt
Quelle / Beleg?
Mir sind unter ext2 und ext3 noch [b]nie[/b] Daten abhanden gekommen. Und ich habe schon diverse Abstürze provoziert. Ok, eine Schwalbe macht noch keinen Sommer und meine Erfahrungen müssen nicht allgemein sein, also bin ich für Begründungen Deiner These natürlich offen ...
Du hast nicht ganz unrecht mit der Datensicherheit. UNIX-Dateisysteme wie ext4, aber auch xfs sind auf Robustheit und Geschwindigkeit ausgelegt. Es gibt eine Garantie, dass Daten, die auf die Platte geschrieben wurden, dort sicher sind. Vom Schreiben aus Sicht des Programmes bis zum tatsächlichen Schreiben auf die Platte kann allerdings eine gewisse Zeit vergehen, für die gibt es keine Garantie, was teilweise schon wegen der Hardware nicht anders möglich ist. Im schlimmsten Fall gehen bei einem Stromausfall die Änderungen von ein paar Sekunden verloren, meist nur ein paar unwichtige Logeinträge.
Die Dateisysteme stellen nur die Konsistenz nach einem Neustart sicher, dafür gibt es Tools wie fsck, die halt inkonsistente Daten entfernen. Echte Datensicherheit gibt es nur mit Backups.
Ich habe es nur selten erlebt, dass ein Linux-Dateisystem Daten vernichtet hätte. In all diesen Fälle war entweder die Hardware kaputt oder der Administrator (also ich selber) überschrieb durch eigene Fehler einen Teil des Dateisystems. Mit anderen Worten, deine Schlussfolgerungen sind absoluter Bullshit.
HAMMER ist nicht unter Linux einsetzbar, hat nur einen Entwickler, wurde hauptsächlich für große Cluster entwickelt und kann einige Features von BTRFS (Writeable Snapshots, Pooling) nicht. Also keine Alternative.
Sicherung der Datenintegrität, Kompression im Dateisystem, schreibbare Schnappschüsse des Dateisystems, hohe Leistung bei kleinen Dateien, eingebaute Defragmentierung und Speicher-Pools.
Ich bin nicht so vertraut mit jffs2 ... kann das das obige alles?
Find ich gut, denn dann wird Btrfs ordentlich getestet (von den Usern dann) und ist dann schneller stabil für uns Fedora User.
Welches Fedora? Fedora 17?
MeeGo ist wohl eher noch nicht so schnell fertig.
Naja. Immerhin gab es vor geraumr Zeit schon einen Release. Denke also dass das schon mit der naechsten Generation an Nokia Handys ausgeliefert wird.
Was mich an Btrfs noch so richtig stört ist dass es 10% des verfügbaren Speicherplatzes fest für Metadaten reserviert. Das bedeutet man kann seinen Datenträger nur bis zu 90% befüllen. Ich mal hoffe das wird irgendwann noch gefixt.
Gibte da nen kleinen workaround: 10% groessere festplatte kaufen .
Falsch, 11,1periodisch% größer muss sie sein (wenn ich mich nicht irre, und ich bin nicht Prinz Humperdinck).
*daumen hoch*
weiß jemand wie der Konkurrenz ist (z.B. ZFS)?
ich meinte:
weiß jemand wie das bei der Konkurrenz ist(z.B. ZFS)?
ich meinte:
weiß jemand wie das bei der Konkurrenz ist(z.B. ZFS)?
btrfs, ZFS = oracle
mfg
kann ja wohl trotzdem technische Konkurrenz sein.... trotzdem danke
AFAIK:
ZFS gilt als stabil und ist sogar OpenSource, kann aber lizenzbedingt nicht in den Kernel aufgenommen werden. Außerdem soll btrfs als jüngeres FS (laut Entwickler) noch besser werden.
Wohingegen die Qualität von ZFS immer gleichbleibt.
Hmmm, ja, ZFS wird wohl auch weiterentwickelt, aber Oracle wird den Teufel tun und anfangen ihr als verlässlich geltendes FS gravierend umzumodellieren. Im Allgemeinen vertrauen die Leute ihre Daten nicht irgendwelchen Alpha-Versionen von Dateisystemen an, wie es bei btrfs noch der Fall ist.
Mein Posting kam zwar etwas neg. rüber, war aber nicht so gemeint.
Ich wollte nur zum Ausdruck bringen, dass die Entwicklung weitergeht, neue Features kommen hinzu, Portierungen folgen.
Zum Glück wurde ZFS nicht von irgendeiner Softwarebude entwickelt sondern von SUN. Darüber hinaus wird das auch schon produktiv eingesetzt. Sowas wichtiges wie ein Dateisystem wird nicht stabil nach 1 a oder durch dessen Deklaration.
sorry aber sun ist zwar groß, aber eben auch nur von menschen gemacht.
wenn du z.b. eine platte falsch zu einem zpool zuordnest kann die platte nicht wieder entfernt werden - aussage von sun: wird noch nicht unterstützt.
folge war komplettbackup, zpool komplett aufbrechen, neu machen und restore - am wochenende. glücklicherweise haben wir keinen 24/7 betrieb :)
ich könnte noch weitere geschichten erzählen wie 2 wochen reaktionszeit (silver support), defekt gelieferte ersatzteile und einfach *AUS*gehende server...
also sun und jetzt nach der übernahme oracle nicht über den klee loben - oracle ist auch voller spezialexperten ( aka softwarebug gefunden, kommentar von oracle "der bug ist bekannt, case closed" )
Bei den meisten Dateisystemen ist es sowieso nicht ratsam die Platte/Partition über 90% zu füllen.
So ganz unrecht hat er aber nicht.
Auch wenn man 10% an Platz frei lässt, so kann man die Platte doch immer noch mit mehr Daten befüllen, wenn das Dateisystem z.B. nur 5% des Platzes für Metadaten benötigen würde.
10% für Metadaten sind schon viel. Gerade bei heutigen Terrabyte-Platten sind das etliche Gigabytes. Ob sich das inzwischen geändert hat, kann ich aber auch nicht sagen.
Ich weiß zwar nix / nichts / nada über btrfs, aber ist es nicht doch wahrscheinlich, dass es eine Option beim Formatieren geben wird, mit der der reservierte Speicherplatz bestimmt werden kann? Bei Ext3 werden ja auch standardmäßig 5 % für root reserviert, aber der Wert kann per Parameter geändert werden.
(Kann aber auch sein, dass die 10 % aus irgendeinem konzeptuellen Grund fest sind.)
Ist doch schon deutlich weiter als Btrfs
Dann müsste man ja mit fuse arbeiten.
Das liegt dann aber eher an Linux
An sich liegt das eher an der Lizenz unter der ZFS liegt. Die Konditionen unter denen ein Einbau in den Kernel möglich sind waren schon lange vor der Entwicklung von ZFS bekannt.
Er spricht von Hammer FS (DragonFly BSD) und nicht von ZFS oO
weil HAMMER ungeeigneter Müll ist?
Aber das einige auf ext4 zeigen, daß einfach so für stabil erklärt wurde und dann erstmal Daten fraß, ist schon dreist.
Nur in Ubuntu, weil es da auf maximale Performance getrimmt wurde (und wird), andere Distributionen haben für Desktopuser Optionen gewählt, die auch den Betrieb ohne USV erlauben.
Was eigentlich kein Bug ist aber auch egal...
Delayed Allocation nennt man sowas und dies nutzt jedes moderne Dateisystem.
z.B. ist XFS dafür bekannt das es die Daten sehr lange im Speicher (RAM) hält bis es auf die Platte geschrieben wird. Was bei einem Stromausfall zu Datenverlusst führen kann.
Und Canoncial hat wie üblich ohne zu denken 120 Sek Timeout übernommen und schwups sind die Daten weg wenn was passiert.
nein, nicht jedes. Und nach Jahren, in denen sich Anwender darüber aufregten, daß XFS Daten vernichtet, bei crash, hätte jedem klar sein müssen, daß es eine blöde Idee ist.
Aber extX war noch nie für Datensicherheit ausgelegt, sondern nur gute benchmark Ergebnisse.
Ein Dateisystem, daß nicht mit sicheren defaults arbeitet, ist Schrott.
Aber extX war noch nie für Datensicherheit ausgelegt
Quelle / Beleg?
Mir sind unter ext2 und ext3 noch [b]nie[/b] Daten abhanden gekommen. Und ich habe schon diverse Abstürze provoziert. Ok, eine Schwalbe macht noch keinen Sommer und meine Erfahrungen müssen nicht allgemein sein, also bin ich für Begründungen Deiner These natürlich offen ...
Du hast nicht ganz unrecht mit der Datensicherheit. UNIX-Dateisysteme wie ext4, aber auch xfs sind auf Robustheit und Geschwindigkeit ausgelegt. Es gibt eine Garantie, dass Daten, die auf die Platte geschrieben wurden, dort sicher sind. Vom Schreiben aus Sicht des Programmes bis zum tatsächlichen Schreiben auf die Platte kann allerdings eine gewisse Zeit vergehen, für die gibt es keine Garantie, was teilweise schon wegen der Hardware nicht anders möglich ist. Im schlimmsten Fall gehen bei einem Stromausfall die Änderungen von ein paar Sekunden verloren, meist nur ein paar unwichtige Logeinträge.
Die Dateisysteme stellen nur die Konsistenz nach einem Neustart sicher, dafür gibt es Tools wie fsck, die halt inkonsistente Daten entfernen. Echte Datensicherheit gibt es nur mit Backups.
Ich habe es nur selten erlebt, dass ein Linux-Dateisystem Daten vernichtet hätte. In all diesen Fälle war entweder die Hardware kaputt oder der Administrator (also ich selber) überschrieb durch eigene Fehler einen Teil des Dateisystems. Mit anderen Worten, deine Schlussfolgerungen sind absoluter Bullshit.
Wenn man von den Bugs mal absieht, gibt es immer noch Probleme bei den Portierungen auf den anderen BSDs, von Linux ganz zu schweigen.
Abgesehen davon, ist nicht Tux3 von den Eigenschaften recht ähnlich und das gibt's doch für Linux.
Ja, Tux3 ist recht "ähnlich". Allerdings ist das Projekt anscheinend mehr oder minder tot...
HAMMER ist nicht unter Linux einsetzbar, hat nur einen Entwickler, wurde hauptsächlich für große Cluster entwickelt und kann einige Features von BTRFS (Writeable Snapshots, Pooling) nicht. Also keine Alternative.
Btrfs by default in Maverick?
Und dann auch noch Flashbasiert?
IMO ist das so ziemlich quatsch.
JFFS2 würde noch sehr sehr lange für kleine Handhelds und Smartphones genügen.
Die Hauptgründe aus dem Artikel:
Sicherung der Datenintegrität, Kompression im Dateisystem, schreibbare Schnappschüsse des Dateisystems, hohe Leistung bei kleinen Dateien, eingebaute Defragmentierung und Speicher-Pools.
Ich bin nicht so vertraut mit jffs2 ... kann das das obige alles?
JFFS2 kann wenigstens Wear Leveling.
Siehe WP