Intern: Sonnenuntergang auf dem grünen Planeten
- Ersteller Nero24
- Erstellt am
PuckPoltergeist
Grand Admiral Special
Doch das kann ich. Ich vergleiche hier Dateisysteme, nicht ihre Features. Ext2 besitzt auch kein Journaling, und ich habe es gegen den Rest antreten lassen. Reiser, XFS und JFS arbeiten mit dynamischer Inode-Allokation, und ich habe sie gegen ext2/3 laufen lassen. Wenn ZFS mit einem Feature wie Checksummen kommt, wird das auch mit getestet.
Es sind Tests, an Hand derer der normale Nutzer entscheiden kann, welches Dateisystem er auf seinem Rechner nutzt. Ich habe jetzt lediglich mal ZFS für einen Vergleich hergenommen. Lies endlich den entsprechenden Thread! Ansonst sind deine Aussagen hier weit weniger wert als meine Messungen.
Und noch etwas. Ich habe nicht vor, die maximale Leistungsfähigkeit bzgl. Performance der einzelnen Dateisysteme zu ermitteln. Da würden eh alle gegen Reiser4 verlieren.
Uff...nimm nem Formel 1 Boliden und nen Audi A3, beide fahren 1km auf ner Temp 100 strecke und dürfen nur 100 fahren. wer kommt eher an? Der Formel 1 Wagen natürlich....trotzdem ist der Test Scheiße weil er zwar gleiche Bedingungen aber sonst nichts berücksichtigt. Laß beiden freien Lauf und die Unterschiede werden auch für Dich ersichtlich. wenn Du Dir das nicht leisten kannst laß es einfach. Du sollst es nicht gleich machen, Du sollst es richtig machen. Was ist daran so schwer zu verstehen.
Setzt nen Host auf und häng zwei externe Platten dran, dort benchst Du. Alles andere ist Kokolores und Quatsch. Keines der Dateisysteme kann seine Muskeln spielen lassen wenn es auf der selben Platte läuft und dann bestenfalls noch an die natürliche Grenze der Übertragungsrate kommt.
Allerdings sehe ich leider das Du das scheinbar weder verstehen kannst noch willst. Vielleicht hilft das Beispiel mit dem autotest ja...wer weiß.
Du redest von normalen Nutzer mit nem aldi PC, willst SUN Nebelkerzen "auflösen" die auf völlig anderen Systemen durchgefahren werden...entscheide dich bitte mal.
Super. auf deinem Singelhost mit einer Platte. Wie anspruchsvoll und vor allen wie umsetzbar auf einem normalen Host der Anwendungsdaten auf einzelnen Platten hat.
Zuletzt bearbeitet:
PuckPoltergeist
Grand Admiral Special
Du regst sich über Unverstand auf? Du bist ja nichtmal in der Lage die Informationen vor deiner Nase zur Kenntnis zu nehmen. Iozone ist ein synthetischer Benchmark, der mit der Realität kaum was zu tun hat. Hab ich auch im Thread zu den Tests geschrieben. Das kopieren großer Mengen kleiner Dateien liefert deutlich andere Resultate als iozone oder bonnie. Und jetzt rate mal, was der User mehr machen wird. Selbst das auspacken eines tars ist realistischer als iozone.
.
EDIT :
.
Klar, und die externen Platten binde ich über FC an? Jedes Dateisystem muss in dem Bereich seine Muskeln spielen lassen, in denen es eingesetzt wird. Und wenn ZFS für das genannte Szenario nicht geeignet ist, muss im Zweifel ein anderes FS her. Das bestätigt mich dann nur in meiner Kritik an der Vermischung von Volume Manager und FS.
Nein, ihr versteht nicht. Ihr bastelt euch eure Situation, worauf ZFS optimiert ist. Wenn dann jemand kommt, und es in einer anderen Situation prüft, ist das nicht weniger als Ketzerei. Aber bitte, wenn ihr meint. Dann lebt von mir aus in dem Glauben, den heiligen Gral gefunden zu haben.
PS: Und am weitesten entwickelte Dateisystem auf dem Markt ist auch verdammt anmaßend. Ich wage sehr zu bezweifeln, dass du sämtliche Dateisysteme am Markt kennst. Wie man sich da so ein Urteil bilden kann, ist mir schleierhaft.
Zuletzt bearbeitet:
falsch....
richtig....
falsch..du sollst alle auf zwei externen/unabhängigen SATA Platten testen.
Amen und raus. Viel Spaß beim testen...
Du biegst es dir auch so zurecht wie es passt...und das mit dem schleierhaft, OK, da steht es 2:1 die dein Vorhaben so finden. Warum sollte ich sämtliche Dateisysteme kennen und würde mich das zu einem besseren Menschen machen? Die Tests auf ner Singleplatte sind scheiße, du aber siehst ausschließlich "SUN und ZFS" das es um die Testbefdingung für alle geht ist Dir tatsächlich auch nicht so bewußt - Hauptsache man kann es wiederlegen.
Im übrigen. Auf Seite 1 fandest Du die Tests doof, obwohl die Admins AFAIk keine Optimierungen vorgenommen haben....hier sprichst Du Dich dagegen aus, willst aber auch kein normales System mit extra angebundenen Platten akzeptieren bestehst aber weiterhin auf "out of the box".
Denk mal über deine eigenen Worte nach. Du machst ne Hexenjagd auf ZFS weil es dir nicht in den Kram passt.
Zuletzt bearbeitet:
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Naja, und Du bastelst ne Situation, auf die ZFS nicht optimiert ist ...
Ist doch wohl klar, dass man ZFS kaum als Handy FS und FAT16 nicht als Server FS nimmt.
Klar es würde wohl irgendwie laufen aber .... hmmm da gibts ein *paar* Nachteile ^^
Also teste jetzt das ZFS, und stell fest, dass es auf 1 Platte keinen Vorteil bietet. Die hauptberuflichen Admins interessiert das eh nicht, und solange Du kein Pauschalurteil ala "Auf 1 Platte is ZFS mieß, das gilt sicherlich auch für 10 Platten" fällst, wird sich der ein oder andre wohl nur über den Sinn & Zweck des Tests wundern.
Mir leuchtet er auch nicht ein, oder würdest Du mit nem Ozeandampfer ne lauschige Kanutour planen ?
ciao
Alex
Tom24
Grand Admiral Special
- Mitglied seit
- 14.01.2001
- Beiträge
- 5.401
- Renomée
- 7
Hallo Leute,
nach langer Abwesenheit, moecht ich auch mal wieder meinen Senf dazu geben. Weil's soviel Spass macht.
Naja gut, ich muss nun los.
nach langer Abwesenheit, moecht ich auch mal wieder meinen Senf dazu geben. Weil's soviel Spass macht.
Das auspacken von Tarballs ist wirklich kein Benchmark, den man irgendjemandem zeigen moechte. Ich erinnere mich an ein bsdtar update, welches libarchive 2.0.25 benutzt und nach dem bsdtar ploetzlich schneller war als GNUtar.
Details gibt's auf der current@freebsd.org Eintrag dazu
Details gibt's auf der current@freebsd.org Eintrag dazu
Was die Features angeht, bin ich schon der Meinung, man sollte die Features benutzen, die das FS per default mitbringt. Puck liegt gar nicht so daneben, wenn er sagt, dass bei FS Benchmarks ext2 trotz fehlendem Journal mitverglichen wird, obwohl es natuerlich einen Vorteil hat. Jedoch weiss doch jeder, dass man diese Zahlen unter bestimmten Gesichtspunkten zu betrachten hat und wenn ich kein Journal will, dann benutze ich halt ext2. Wenn ich ich nun die ZFS Checksummen moechte, dann nehm ich auch den Performancenachteil in Kauf. Gerade in die Optimierung von ZFS und damit es mit dem Checksummen nicht heftig in's Hintertreffen geraet, wurde bei SUN soviel Zeit investiert.
Die Sache mit der einzelnen Festplatte halte ich persoenlich fuer falsch, jedoch erwarte ich da keine realitaetsverzerrenden Veraenderungen. Aber ich koennte falsch liegen und denke, das sollte wenn auch nur kurz ueberprueft werden und wenn moeglich auch ausgeschlossen.
Ich denke, wenn man behauptet, ZFS wuerde skalieren, dann sollte das auch fuer Performance mit einer Festplatte gelten. Hier koennten sich Vor- oder Nachteile des FS' zeigen, die sich durch eine Skalierfaehigkeit im einem grossen Array nicht bemerkbar machen -- moeglicherweise weil andere FS' nicht gut skalieren.
Was die Heirat von Volume Manager und Dateisystem angeht, bin ich noch nicht so richtig ueberzeugt, welche Loesung besser ist. Beide haben Vor- und Nachteile.
Naja gut, ich muss nun los.
Naja ... es geht hier auch noch um ein paar andere Punte:
1. Zwei nicht vergleichbare Filesysteme miteinander vergleichen. Wenn das eine Filesystem Checksummen erreichnet, das andere nicht, erscheint es sinnvoll beide auf den selben Stand zu heben. Entweder man Validiert die datenkorrektheit auf Linux mit anderen Methoden oder man schaltet die Checksummen schlicht ab.
2. Wenn das eine Filesystem per default den WriteCache einschaltet, das andere Filesystem es auf einer einzelnen Partition nicht tut, dann mach es Sinn entweder write cache auf beiden Filesystem ein oder ausgeschaltet zu lassen.
Interessanterweise schaltet ZFS uebrigens nicht wegen sich selbst den Writecache nicht an, wenn es nur eine Partition benutzt, sondern wegen der anderen Filesysteme die gegebenfalls auch noch auf der Platte sind, und denen man professionellerweise eigentlich keinen Writecache auf der Platte geben darf (UFS,ext2,ext3 uswusf). Nutzt es die ganze Platte weiss das System, das die entsprechenden Sicherungmechanismen in ZFS ueberall greifen koennen, der writecache also ungefaehrlich ist ...
Gruesse
Joerg
.
EDIT :
.
Einige Dinge, die ZFS macht, gehen nur mit der Kombination:
- Das Konzept gemeinsam genutzer Datenpools
- Ausschliessliches Resilvering belegter Bereiche bei neuen Mirrorplatten
- writeholeloses RAIDZ haengt eng damit zusammen.
- automatisierte Optimierung, Hot Spot Relocation und die Angleichung der Plattennutzung bei neuen Platten gehen auch nur vernuenftig, wenn FS und "Volumemanager" eine Einheit darstellen.
Es ist halt ein neues Konzept ... damit muessen viele Leute erstmal warm werden ...
Tom24
Grand Admiral Special
- Mitglied seit
- 14.01.2001
- Beiträge
- 5.401
- Renomée
- 7
Ist alles mit entsprechenden Schnittstellen zwischen FS und Volume Manager loesbar. Fuer ein Einheit besteht keine Notwendigkeit, sie lag nur fuer SUN auf der Hand, weil die Leute kein Oekosystem bauen wollten sondern eine integrierte Loesung.
Die Verheiratung Beider ist eine Design-Entscheidung gewesen, keine Notwendigkeit.
mj
Technische Administration, Dinosaurier, ,
Puck: Wie hier bereits gesagt wurde macht es ungefähr so viel Sinn ZFS auf einer einzelnen, kleinen Partition einzusetzen, wie einen Lastwagen gegen einen Ferrari antreten zu lassen. Jeder hat seinen ganz eigenen Einsatzzweck, der Privatanwender wird niemals auch nur annähernd in Versuchung kommen, ZFS auf seinem Privatrechner zu verwenden.
Wenn du wirklich wissen willst, zu was ZFS fähig ist, dann brauchst du - wie hier schon mehrfach geschrieben - mindestens zwei, besser noch mehr Platten (sagen wir zum Beispiel zwei 40GB Platten im Stripe und das ganze Stripe dann auf eine 80er Platte gespiegelt - oder einfach zwei 40er Platten im Spiegel, oder, oder, oder). Nur dann kann das ZFS sich voll entfalten und zeigen, was es kann. ZFS auf einer einzelnen Platte in einer Partition einzusetzen ist in etwa so sinnvoll, wie mit dem 40-Tonner Sonntag früh zum Semmeln kaufen zu fahren.
Deine Ergebnisse besitzen also leider Null Aussagekraft. Weder, wenn es um den Einsatz in Desktopsystemen geht, noch, wenn es um den Einsatz in Serversystemen geht. Denn für beide Szenarien ist die von dir nachgestellte Situation so wahrscheinlich, wie ein 6er im Lotto
Wenn du wirklich wissen willst, zu was ZFS fähig ist, dann brauchst du - wie hier schon mehrfach geschrieben - mindestens zwei, besser noch mehr Platten (sagen wir zum Beispiel zwei 40GB Platten im Stripe und das ganze Stripe dann auf eine 80er Platte gespiegelt - oder einfach zwei 40er Platten im Spiegel, oder, oder, oder). Nur dann kann das ZFS sich voll entfalten und zeigen, was es kann. ZFS auf einer einzelnen Platte in einer Partition einzusetzen ist in etwa so sinnvoll, wie mit dem 40-Tonner Sonntag früh zum Semmeln kaufen zu fahren.
Deine Ergebnisse besitzen also leider Null Aussagekraft. Weder, wenn es um den Einsatz in Desktopsystemen geht, noch, wenn es um den Einsatz in Serversystemen geht. Denn für beide Szenarien ist die von dir nachgestellte Situation so wahrscheinlich, wie ein 6er im Lotto
PuckPoltergeist
Grand Admiral Special
Ich habe ja nicht Dateisysteme miteinander verglichen, sondern Dateisysteme in einer bestimmten Situation. Der Test ist eigentlich auch garnicht für ZFS gedacht, das habe ich nur mal als zusätzliche Referenz hinzugezogen. Bitte lies doch endlich mal den Thread, damit du überhaupt weißt, worum es geht. Ich beschränke mich explizit nur auf den Heim- bzw. SoHo-Bereich.
Das ist natürlich richtig, und würde ich auch noch nachprüfen. Es wäre fein, wenn du mich dafür auf den richtigen Befehl lenken könntest, damit ich nicht erst ewig suchen muss.
Wieso denn das? UFS kenne ich nicht gut genug, kann ich nicht beurteilen. Wieso sollte der Cache für ext aber gefährlich sein?
Naja, ich werde mit diesem Konzept wohl so warm werden, wie mit nem http-Server oder der GUI im Kernel. Wie ich schonmal schrieb, die Verheiratung von VM mit FS erhebt entweder den Anspruch auf das ultimative Dateisystem oder bedingt früher oder später Codeduplikationen, wenn andere Dateisysteme auch einen VM brauchen.
.
EDIT :
.
Deine Ergebnisse besitzen also leider Null Aussagekraft. Weder, wenn es um den Einsatz in Desktopsystemen geht, noch, wenn es um den Einsatz in Serversystemen geht. Denn für beide Szenarien ist die von dir nachgestellte Situation so wahrscheinlich, wie ein 6er im Lotto
Also ich als unbedarfte Anwender, der statt Linux mal Solaris nehmen will, hätte da durchaus meine Daten auf eine extra Partition gepackt. Und da ja ZFS neu und innovativ ist, wäre wohl die Wahl zuerst darauf gefallen. Wenn ich also das Linux-Szenario auf Solaris übertrage ist das garnicht mal mehr so unwahrscheinlich.
mj
Technische Administration, Dinosaurier, ,
Du, als unbedarfter Anwender, installierst dir Solaris statt Linux. Schön und gut. Schade nur, dass du während der Installation von Solaris die ZFS Partitionen gar nicht anlegst, sondern erst danach. Und der normale, unbedarfte Anwender partitioniert seine Festplatte nun mal bei der Installation und nicht erst im Anschluss. Der unbedarfte Anwender wird also mit ZFS gar nicht erst in Berührung kommen.
Der bedarfte Anwender hingegen informiert sich über die Möglichkeiten und wird ganz schnell feststellen, dass ZFS auf einer einzelnen Partition völlig sinnfrei ist. Er wird weiterhin feststellen, dass UFS deutlich mehr Sinn macht und auch auf einer einzelnen Partition auf einer einzelnen Platte wahrscheinlich performanter sein wird (Achtung! Vermutung, ich kann diese Aussage nicht mit Zahlen bestätigen). Und hat er mehrere Platten zur Verfügung, zum Beispiel eine Platte für das System und zwei oder mehr Platten für die Daten, wird er sich durchaus mit ZFS anfreunden können. Aber eben nur dann. Ich wiederhole mich gerne und ich wiederhole auch c0t0d0s0 - ZFS auf einer einzelnen Partition auf einer einzelnen Platte ist bar jeden Sinnes.
So, wie deine Ergebnisse da stehen, triffst du lediglich folgende Aussage: Auf einer einzelnen Partition auf einer einzelnen Festplatte macht es keinen Sinn, ZFS einzusetzen. Dass dem so ist, hätten dir allerdings auch schon vorher mehrere Leute hier sagen können
PuckPoltergeist
Grand Admiral Special
Also für so unwahrscheinlich halte ich das nicht. Nach dem Hype, der um ZFS gemacht wurde, welchem ich auch teilweise aufgesessen bin, halte ich es für durchaus realistisch, dass sich der Nutzer schlau macht, wie er da ran kommt. Und Anleitungen dazu gibt es hinreichend.
Naja, also wie oben schon gesagt, Anleitung zur Inbetriebnahme von ZFS gibt es reichlich. Die Aussage, dass es auf einzelnen Partitionen, zusammen mit anderen Dateisystemen sinnfrei ist, habe ich noch nicht gefunden. Ich weiß es nun. Aber wie viele andere wissen es nicht?Der bedarfte Anwender hingegen informiert sich über die Möglichkeiten und wird ganz schnell feststellen, dass ZFS auf einer einzelnen Partition völlig sinnfrei ist. Er wird weiterhin feststellen, dass UFS deutlich mehr Sinn macht und auch auf einer einzelnen Partition auf einer einzelnen Platte wahrscheinlich performanter sein wird (Achtung! Vermutung, ich kann diese Aussage nicht mit Zahlen bestätigen). Und hat er mehrere Platten zur Verfügung, zum Beispiel eine Platte für das System und zwei oder mehr Platten für die Daten, wird er sich durchaus mit ZFS anfreunden können. Aber eben nur dann. Ich wiederhole mich gerne und ich wiederhole auch c0t0d0s0 - ZFS auf einer einzelnen Partition auf einer einzelnen Platte ist bar jeden Sinnes.
So, wie deine Ergebnisse da stehen, triffst du lediglich folgende Aussage: Auf einer einzelnen Partition auf einer einzelnen Festplatte macht es keinen Sinn, ZFS einzusetzen. Dass dem so ist, hätten dir allerdings auch schon vorher mehrere Leute hier sagen können
Es ist nicht sinnfrei, das ist falsch. man muss nur ein paar kleinigkeit beachten, damit es die volle Leistung bringt. Writecache einschalten beispielsweise. Man verwendet es auf einer einzelnen Partition nicht um Spitzenleistungen zu erreichen, sondern um die ganzen anderen Features aus ZFS
Ausserdem kann es durchaus trotzdem Sinn machen: Beispielsweise die Filesystemsnapshots. Ich setze es auf meiner Archivpartition auf meinem Notebook selber genau dafuer ein. Alle drei Stunden legt das System einen Snapshot an um diese nach 2 Wochen wieder zu loeschen.Da es dort meine Ziele extreme sicherheit, moeglichst viel platz und erst nachrangig geschwindwigkeit sind , habe ich sowohl compression als auch checksums eingeschaltet.
Die Fileserverplatten auf der mein DVB-T receiver aufzeichnet hat beides nicht ... da kommt es mir auf geschwindigkeit an beim umbauen der CRID-Files auf MPEG-4. Da schalte ich checksummen und compression aus. Dafür will ich aber die extrem einfache erweiterung der Plattenkapazität ohne Filesystem growen zu muessen
Es ist halt wie bei jedem Unix ... man sollte wissen was man da treibt ...
.
EDIT :
.
Für die interessierte Leserschaft: ZFS Bootsupport
http://www.c0t0d0s0.org/archives/2947-Putback-of-ZFS-boot-support.html
PuckPoltergeist
Grand Admiral Special
Ok, sinnfrei ist falsch formuliert. Es bringt dann möglicherweise nicht die Leistung, die man erwartet.
Und wenn du mir jetzt noch einen Hinweis gibst, wie ich den Cache aktiviere, würde ich das nachher auch noch testen.
Über welchen Cache reden wir hier eigentlich? Den der Platte oder das Äquivalent zum Page-Cache von Linux? Und nochmal die Frage, wieso ist dieser Cache für ext gefährlich?
Natürlich sollte man das, nicht nur bei Unix, sondern bei Computern allgemein. Für nen Fileserver mit gutem Durchsatz würde ich wahrscheinlich auch nicht das System 0815 aufziehen, sondern an den notwendigen Stellen tunen und z.B. Realtime-Volumes von XFS einsetzen. Aber darum ging es in dem Test auch garnicht. Es ging schlicht nur darum, mit welcher Alternative der einfache User normalerweise am besten fährt.
Es dreht sich um den Cache auf den Festplatten
Aktivieren: set ata:ata_write_cache = 1 (in die /etc/system eintragen und rebooten)
Das Problem entsteht dadurch das der Cache an der Festplatte nicht durch Batterien gesichert ist, und Änderungsgruppen am Filesystem nicht transaktional sind. Das kann bei eingeschaltetem Writecache zu aeusserst unschoenen Effekten führen. Das ist der Grund, warum grosse Storagearrays ueber Batterien zum Stützen des Caches verfügen.
ZFS kennt dieses Problem nicht, da sehr vereinfacht gesagt Änderungsgruppen am Filesystem immer ganz oder garnicht ausgeführt werden, also in einem Transaktionskontext stehen.
Der einfache User nutzt kein ZFS, geschweige denn Solaris. Der einfache User verwendet nicht mal Linux .... Es hat durchaus Gründe warum Windows und zunehmend Mac OS X so beliebt sind.
PuckPoltergeist
Grand Admiral Special
Ach so, das meinst du. Wird unter Linux mittels write barriers umgangen. Wie ein transaktionsorientiertes Konzept das löst, erschließt sich mir aber noch nicht.
Da wäre ich mir an deiner Stelle nicht so sicher. Oder wir reden hier nur von unterschiedlichen Benutzergruppen, wenn wir von einfachen Usern reden. Die Nachfrage, welches FS mit welcher Aufteilung etc. kommt durchaus häufig. Einfacher User heißt ja nicht, dass er sich nicht mit was anderem als Windows auseinandersetzt. Ihm fehlt bis dato nur das Wissen. Und wenn er dann erstmal mit einer Fülle neuer Konzepte und Möglichkeiten (also auch Dateisysteme) erschlagen wird, ist das nicht sonderlich hilfreich.
Write Barriers klappen aber nur, wenn die gesamte Kette bis zum rotierenden Metall das alles unterstützt. Beispielsweise sind genuegend platten bekannt, bei denen beispielsweise das CacheFlush nicht sauber funktioniert. Write-barriers sind in dem Zusammenhang eigentlich eh nur ein Hack.Symptombekämpfung.
Ein transaktionbasiertes Filesystem mit copy-on-write umgeht das vollstaendig.
Deswegen wird er anfangs auch kein ZFS einsetzen .... er nimmt das was per default auf die platte gekippt wird ... mit der argumentation könntest du uebrigens jede Weiterentwicklung in Frage stellen. Ausserdem: ZFS ist durch einfache User wesentlich einfacher zu handhaben als andere Filesystem+Volumemanager-Komplexe ...
Das mag sein, doch welche Nachteile erfährt der User durch ZFS oder eben durch ext3 oder was auch immer wenn er in der Testphase ist? Der prozentuale Anteil an völligen OS-Noobs die sofort auf Solaris setzen dürfte unter 1% liegen und davon nochmal 50% abziehen die keine Ahnung haben ob und warum man ZFS einsetzen sollte.
Sei es wie es sei, ich bin der Meinung das ein Filesystem welches nichts taugt oder im allgemeinen nicht dem enstpricht was das Marketing verspricht nicht gerade große Chancen hat z.B. auf Apple zu laufen oder auf andere Systeme portiert zu werden. Das würde auch bedeuten das weltweit nur Noobs sitzen die dem Marketing vertrauen und weder etwas nachprüfen noch nachmessen und jedes Geblubber einfach annehmen. Du solltest Deine Studie dann schon mit etwas mehr füttern als Du es derrzeit tust - denn auch Deine Meinung kann bei den Noobs Gehör finden und wird weitergetrascht obwohl sie unter fragwürdigen Umständen gemessen wurde.
MFG
Sei es wie es sei, ich bin der Meinung das ein Filesystem welches nichts taugt oder im allgemeinen nicht dem enstpricht was das Marketing verspricht nicht gerade große Chancen hat z.B. auf Apple zu laufen oder auf andere Systeme portiert zu werden. Das würde auch bedeuten das weltweit nur Noobs sitzen die dem Marketing vertrauen und weder etwas nachprüfen noch nachmessen und jedes Geblubber einfach annehmen. Du solltest Deine Studie dann schon mit etwas mehr füttern als Du es derrzeit tust - denn auch Deine Meinung kann bei den Noobs Gehör finden und wird weitergetrascht obwohl sie unter fragwürdigen Umständen gemessen wurde.
MFG
PuckPoltergeist
Grand Admiral Special
Natürlich muss die Hardware das mitmachen. Wenn die das nicht unterstützt, geht es nicht.
Verrätst du mir auch, wie das geht? Transaktionen hin, CoW her, das FS muss dafür doch auch wissen, wann die Daten wirklich auf der Platte sind. Andernfalls riskiert man immer Datensalat.
Jein, möchte ich bestreiten. Ich übertrage das jetzt einfach mal aus meinem Linux-Alltag. Der unerfahrene User kommt zu Solaris, hat gehört und gelesen, wie Klasse das doch ist. Er weiß auch von ZFS. Bei der ersten Installation mag er es noch nicht einsetzen, weil es ihm garnicht angeboten wird. Das wird ihn aber nicht hindern, weil dumm ist er ja nicht. Also kurz nachgeforscht, herausgefunden, wie man in den Genuß kommt, und schon hat er es zusätzlich auf der Platte. Die Leute sind vielleicht unerfahren, aber nicht doof. Und nach meiner Erfahrung haben sie einen enormen Spiel- und Experimentiertrieb. Das ZFS in dieser Konstellation eher suboptimal ist, bekommt unser neuer Nutzer (erstmal) garnicht mit. Der wundert sich nur, wo die versprochene Performance bleibt. Ist das gleiche, als wenn er sich unter Linux JFS oder XFS auf die Platte bügelt, weil die auf dem Papier ja so gut aussehen, und dann genauso in die Röhre schaut.
Und dass ZFS so viel einfacher zu handhaben ist als EVMS sehe ich auch noch nicht so recht. Aber dieses Urteil will ich noch nicht fällen, da ich dazu ZFS viel zu wenig kenne.
Nein, eben nicht. Das FS muss es nicht wissen. Mit einfachen Worten: wenn aus dem ZIL eine Änderung in den aktiven Datenbestand uebernommen werden soll, dann werden daten niemals ueberschrieben, sondern via copy-on-write neu auf der platte verteilt (so funktioniert uebrigens auch die hot spot relocation, es wird durch den block allocator die niedigst ausgelastete platte geommen). danach wird die baumstruktur angepasst, mit der die daten verlinkt werden. auch in neuen bloecken. als allerletzter schritt der transaktion wird der ueberblock geaendert. Bricht die Transaktion vor dem Ende ab, so ist der alte zustand aktiv, da der ueberblock noch auf die alte struktur verweisst. laeuft die transaktion vollstaendig durch, ist sie nacher aktiv, da der ueberblock auf die neue struktur verweist. . sollte durch einen seltsamen zufall der ueberblock korrumpiert werden, so stimmt die checksumme nicht mehr (auch wenn man checksummen abschaltet, die in den metadaten bleiben aktiv), es wird auf den letzten ueberblock mit korrekter checksumme mit der hoechsten transaktionsnummer gesetzt. Es gibt kein Fenster der Inkonsistenz. dank copy on write ist auch dieser zustand immer consistent. durch die transaktionsnummer weis man auch immer, welche aenderungen gegebenfalls noch unbearbeitet im ZIL stehen.
Das WAFL von NetApp geht ähnlich weit, um ein "unkaputtbares" Filesystem bereit zustellen (funktioniert etwas anders). ZFS hat da noch den vorteil, das die Checksummen nie bei den Daten stehen, die sie schuetzen. Warum das besser ist ? Stell dir einen "misdirected" write durch einen Fehler in der Plattenfirmware vor. Steht die Checksumme beim Block, kannst du nicht erkennen, das der Block defekt ist, da die Checksumme stimmt. Mit dem validierenden Baum kannst du problemlos diesen Fall erkennen, und gegebenfalls reparieren.
Nahezu alle weiteren Filesysteme sind diesen Effekten nahezu schutzlos ausgeliefert. Und wie wir seit den Studien von Google zur Plattenverfügbarkeit wissen: Man darf rotierendem Rost nicht trauen ...
PuckPoltergeist
Grand Admiral Special
Und woher weißt du, wann die Daten wirklich auf der Platte sind? So lange du das nicht weißt, darfst du die Transaktion nicht abschließen und die alten Daten nicht löschen. Tust du es doch, riskierst du beim plötzlichen Ausfall gerade die Datenkorruption. So lange auf deinem Pfad ein Bereich existiert, den du weder einsehen, noch gar kontrollieren kannst, nützt dir das beste Konzept nicht. Du musst eindeutig wissen, wann die Daten wirklich geschrieben sind.
PS: Du gehst in deinem Szenario von einem sequentiellen Ablauf aus. Dann würde das funktionieren. Nur dummerweise darfst du diese Annahme nicht machen, die die Platte intern die Schreibrequest umsortieren kann. Und dadurch können auch trotz Transaktion und CoW Inkonsistenzen entstehen.
Zuletzt bearbeitet:
Was die einfachkeit angeht machen wir mal eine probe auf exempel:
Aufgabe: zwei platten spiegeln, drei filesysteme einrichten, zweiten spiegel dazuhaengen, und danach jeweils die Filesystem vergroessern, das die den speicher nutzen. Alle Filesysteme sollen davon etwas haben.
zpool create datapool mirror disk1 disk2
zfs create datapool/marketing
zfs create datapool/forschung
zfs create datapool/forschung
zpool add datapool mirror disk3 disk4
Fertig.
Und nun kommst du mit EVMS
Aufgabe: zwei platten spiegeln, drei filesysteme einrichten, zweiten spiegel dazuhaengen, und danach jeweils die Filesystem vergroessern, das die den speicher nutzen. Alle Filesysteme sollen davon etwas haben.
zpool create datapool mirror disk1 disk2
zfs create datapool/marketing
zfs create datapool/forschung
zfs create datapool/forschung
zpool add datapool mirror disk3 disk4
Fertig.
Und nun kommst du mit EVMS
PuckPoltergeist
Grand Admiral Special
Was die einfachkeit angeht machen wir mal eine probe auf exempel:
Aufgabe: zwei platten spiegeln, drei filesysteme einrichten, zweiten spiegel dazuhaengen, und danach jeweils die Filesystem vergroessern, das die den speicher nutzen. Alle Filesysteme sollen davon etwas haben.
zpool create datapool mirror disk1 disk2
zfs create datapool/marketing
zfs create datapool/forschung
zfs create datapool/forschung
zpool add datapool mirror disk3 disk4
Fertig.
Und nun kommst du mit EVMS
Da sämtliche Linux-Dateisysteme ihre vollständige Größe von Anfang an wissen wollen, kommt natürlich die Unbequemlichkeit dazu, dass man die vorher für sie bestimmen muss. Insofern ist ZFS da einfacher zu handhaben, was ich allerdings nicht gerade als Vorteil ansehe. Mit EVMS muss ich die Bereiche für die einzelnen Dateisysteme separat anlegen. Dafür habe ich aber auch die Garantie, dass mir der Speicher wirklich zur Verfügung steht, was ich in deinem Beispiel nicht sehe.
Mit separaten Volume Manager und FS sind es ein paar mehr Schritte, als du da oben angegeben hast. Dafür habe ich aber auch eine größere Kontrolle darüber.
Naja, okay ...
zfs set reservation=10g datapool/forschung
zfs set reservation=10g datapool/marketing
Und weil die aus Forschung2 Saeue sind, die jeden Speicher aufbrauchen, limitiere ich die mal auf 5 Gig
zfs set quota=5g datapool/forschung2
Und wo ich gerade dabei bin ...
Angenommenermassen ich brauche ein Filesystem herkoemmlicher Bauart, von dem ich weiss, das es mal 10 TB gross wird, aber dem ich am Anfang erstmal nur 1 TB zur verfügung stellen moechte. Das ganze via iSCSI.
zfs create -s -V 10t datapool/reallybigvolume
zfs set shareiscsi=on datapool/reallybigvolume
Das via iSCSI auf einer beliebigen mit ISCSI Initator ausgeruesteten Maschine bereitstellen und als Blockdevice für das Filesystem der Wahl verwenden
Wie geht das noch mal so auf die Schnelle mit Linux Und dann mit zpool add im Betrieb ohne Linux oder Windows etwas sagen zu muessen, den Speicher bereitstellen muessen. Denn beide Glauben schon die ganze Zeit an ein 10TB Volume
Noch Fragen ?
Danke für Eure ausführlichen Darlegungen.
Hoffendlich haben Eure Frauen auch dafür Verständnis und legen nicht die Beziehung aufs "Trockendock"....
Meine Frau hat für diese ( ihr Wortlaut ) technische " Spielereien" wenig Verständnis und findet andere Sachen wesendlich wichtiger...... ( Schuhe kaufen u.a.)
Hoffendlich haben Eure Frauen auch dafür Verständnis und legen nicht die Beziehung aufs "Trockendock"....
Meine Frau hat für diese ( ihr Wortlaut ) technische " Spielereien" wenig Verständnis und findet andere Sachen wesendlich wichtiger...... ( Schuhe kaufen u.a.)
Ähnliche Themen
