Entscheidung zwischen UFS und ZFS

C

christian83

Well-Known Member
Hallo, ich muss mal wieder Fragen :)

Ich habe jetzt einige Zeit im Netz nach Informationen zu UFS und ZFS gesucht, leider aber nicht viel zum Thema gefunden um mir die Entscheidung leichter zu machen.

Durch OpenSolaris bin ich nun schon vor einiger Zeit mit ZFS in Kontakt gekommen und war doch recht positiv davon überrascht. Ein Solaris mit ZFS fühlt sich doch etwas flotter an als mit einem UFS Dateisystem. Nur ob das wirklich so ist weiß ich nicht.

Meine Frage an euch ist nun ob es sich lohnt für einen Desktopsystem ZFS zu nutzen. Sind die Unterschiede in der Geschwindigkeit wirklich so groß das sich ein wechsel lohnt? Einsetzen würde ich das ganze auf einem 64 bit System. Leider konnte ich auch nicht zu viel zum Thema Datensicherheit unter ZFS finden.

Ich bedanke mich schon einmal
 
Also ich denke für ein Desktop-System dürfte der RAM-Verbrauch von ZFS etwas zu hoch sein, oder nicht?
 
Mhh, wenn man 64 bit fährt und nicht gerade Ram-Mangel hat, spricht meines Erachtens nichts gegen ZFS.
Ein heutiger Mittelklasse Desktop hat doch eh min. 4GB Speicher
 
mrtonik schrieb:
Mhh, wenn man 64 bit fährt und nicht gerade Ram-Mangel hat, spricht meines Erachtens nichts gegen ZFS.
Ein heutiger Mittelklasse Desktop hat doch eh min. 4GB Speicher
Zum Vergrößern anklicken....

Weil er den Speicher braucht. Mit zfs braucht man nicht einfach 4GB Speicher, sondern man braucht 4GB _mehr_ Speicher.
Hier sind dann viele Mainboards die Spassbremse, weil sie nur mit 8GB umgehen können.
 
Ich würde sagen, es kommt drauf an, was du machen willst. Für normalen Desktopeinsatz ist UFS2 eigentlich das optimale Dateisystem. Es ist sehr schnell, in vielen praktischen Szenarien auch schneller als ZFS. Es ist außerdem robust, zuverlässig und seit >25 Jahren erprobter Code. Die hauptsächlichen Nachteile sind einmal der Zwang zum fsck(8) nach Abstürzen oder Stromausfällen, zumindest solange mal kein -CURRENT nutzen möchte und dann, dass 7% Speicherplatz verpuffen. Die Snapshots sind auch nicht so wahnsinnig toll...

ZFS hat die großen Vorteile, dass es wirklich geniale Snapshots hat, eingebautes Volumenmanagement und das es intern die Daten auf Konsistenz prüfen kann. Ein fsck(8) ist nicht mehr nötig, das Dateisystem ist immer atomar Konsistent. Der Preis sind vergleichsweise großer Ressourcenverbrauch und auf Einzelplatten (kein RAID) nur mittelprächtige Performance. ZFS ist daher eher für große Fileserver geeignet, sowie für Workstations, die von seinen Funktionen profitieren können. Meine Entwicklerkiste hat z.B. ZFS, da ich damit mein FreeBSD munter hin und her upgraden kann und jederzeit einfach auf spätere Snapshots zurück.
 
Und nein, ZFS "braucht" keine 4GB. ZFS puffert allerdings sehr aggressiv, was bei entsprechend großen ZPools durchaus zu sehr großen Caches im RAM führen kann. Eine Kiste, die ZFS nutzen soll, sollte daher schon 4GB haben. Aber ZFS krallt sich diese nicht generell weg.
 
Danke Yamagi, du hast meine Frage beantwortet :) Ich werde dann bei UFS bleiben. Es war eben nur etwas blöd das man unheimlich schwer bei Google Yamagi's Aussage findet weil einen direkten Vergleich zwischen UFS und ZFS gibt es nach meinem Wissen nicht.

Und die paar Vorteile die ZFS jetzt hat sind dam im verhältniss zu den größeren Anforderungen für mich kein wirklicher Vorteil mehr.

Grüße
 
Yamagi schrieb:
Ich würde sagen, es kommt drauf an, was du machen willst. Für normalen Desktopeinsatz ist UFS2 eigentlich das optimale Dateisystem. Es ist sehr schnell, in vielen praktischen Szenarien auch schneller als ZFS. Es ist außerdem robust, zuverlässig und seit >25 Jahren erprobter Code. Die hauptsächlichen Nachteile sind einmal der Zwang zum fsck(8) nach Abstürzen oder Stromausfällen, zumindest solange mal kein -CURRENT nutzen möchte und dann, dass 7% Speicherplatz verpuffen. Die Snapshots sind auch nicht so wahnsinnig toll...

ZFS hat die großen Vorteile, dass es wirklich geniale Snapshots hat, eingebautes Volumenmanagement und das es intern die Daten auf Konsistenz prüfen kann. Ein fsck(8) ist nicht mehr nötig, das Dateisystem ist immer atomar Konsistent. Der Preis sind vergleichsweise großer Ressourcenverbrauch und auf Einzelplatten (kein RAID) nur mittelprächtige Performance. ZFS ist daher eher für große Fileserver geeignet, sowie für Workstations, die von seinen Funktionen profitieren können. Meine Entwicklerkiste hat z.B. ZFS, da ich damit mein FreeBSD munter hin und her upgraden kann und jederzeit einfach auf spätere Snapshots zurück.
Zum Vergrößern anklicken....

Man merkt sehr wohl einen immensen zeitlichen Unterschied, wenn man Kernel und Welt bzw. Ports baut. Darüber hinaus jongliert man heute auch im Heimbereich mit TB-Größen und das gar in vielfacher Ausführung. Ich archiviere beispielsweise Bildmaterial privat als auch prof. in hohen Auflösungen, ZFS ist da klar im Vorteil, die Performance von UFS untragbar.
 
Dem muss ich klar widersprechen. Ich habe auf meiner Hauptworkstation ausschließlich UFS, auf fünf Platten mit insgesamt ca. 3TB Speicherplatz. ZFS nutze ich nach wie vor nur auf der Testkiste und liefere es an Kunden nur auf Fileservern aus. Es gibt durchaus Szenarien, in denen ZFS große Vorteile hat. Dazu gehören vor allem große Mengen kleiner Dateien. Aber ZFS hat durch seinen Copy on Write Ansatz auch prinzipbedingt ein sehr großes Problem, wenn der Pool zu sehr gefüllt ist. Kann ich hier an einer Platte mit diversen VBox-Images drauf sehr gut beobachten. Wie der Pool noch fast leer war, kopierte ich mit 100 MB/s auf ihn, jetzt bei einem Füllstand von 85% (ca. 70 Gigabyte frei) sind es nur noch 65 MB/s und der Schreibkopf der Platte rasselt wie nichts Gutes hin und her. Gleiches kann man auch dann beobachten, wenn vorhandene Dateien geändert werden sollen. Allerdings profitiert ZFS entsprechend auch sehr von NCQ, anders als UFS. Seitdem ich ATACAM mit ahci(4) nutze, hat ZFS einen deutlichen Geschwindigkeitsprung gemacht. Wenn man mehrere Platten im Pool hat oder sogar eine SSD relativiert sich das alles noch weitaus mehr.

Verstehe mich nicht falsch. Ich mag ZFS sehr, denn es macht das Leben viel einfacher und hat ganz klar große Vorteile gegenüber UFS2. Ich bin mir sogar sicher, dass ZFS in einigen Jahren UFS2 auf Servern und Desktops weitgehend verdrängt haben wird. Da helfen auch Dinge wie Journaled Softupdates nicht mehr, da UFS2 in seinem Kern einfach zu alt ist. Aber dennoch, ZFS ist im Moment irgendwie seiner Zeit voraus. Wirklich Spaß macht es in meinen Augen nur auf vielen Medien parallel oder auf Medien mit unabhängig von der Position der Daten gleichbleibender Zugriffszeit. Dazu kommt, dass UFS2 an seinen extrem konservativen Voreinstellungen scheitert, gerade Dirhashes und das Read Forward des VFS massiv hochzusetzen kann da wahre Wunder wirken... Die Standardeinstellungen sind noch immer für Platten im einstelligen Gigabytebereich, was tausende unnütze Zugriffe nach sich zieht.
 
Yamagi schrieb:
Dazu kommt, dass UFS2 an seinen extrem konservativen Voreinstellungen scheitert, gerade Dirhashes und das Read Forward des VFS massiv hochzusetzen kann da wahre Wunder wirken... Die Standardeinstellungen sind noch immer für Platten im einstelligen Gigabytebereich, was tausende unnütze Zugriffe nach sich zieht.
Zum Vergrößern anklicken....

Kann mir da mal jemand auf die Sprünge helfen?
Was kann man denn noch an UFS2 schrauben?
 
Vor allem zwei Sachen. Einmal "vfs.read_max=32". Damit liest er bei jedem Zugriff immer 32 Blöcke ein. Das ist daher sehr sinnvoll, da ein Zugriff fast immer von einem weiteren Zugriff nur wenige Blöcke weiter gefolgt wird. Diesen zweiten kann man sich mit dieser Einstellung zum Preis von wenigen Kilobytes RAM sparen. Hiervon profitieren alle Dateisysteme, UFS aber ganz besonders, da seine Intelligenz eher gering ist. Bringt allerdings kaum Vorteile, wenn sequentiell gelesen wird.

"vfs.ufs.dirhash_maxmem=134217728". Wesentlich mehr Speicher für Dirhashes. Dirhashes machen Zugriffe auf die Datenstrukturen auf der Platte wesentlich schneller, da sie die linearen Strukturen auf Baumstrukturen im RAM abbilden. Die Standardeinstellung von 2 Megabyte ist viel zu niedrig, gerade bei modernen >1TB Dateisystemen. Dieser Wert von 128 MB kann wahre Wunder wirken, RAM kostet er kaum. Bei Bedarf wird der Mist in den Müll geworfen, der RAM anders genutzt und später wieder neu aufgebaut.
 
Gibt es Bestrebungen die Werte per Default auf einen heutzutage sinnvollen Wert einzustellen? Manuelle Eingriffe mache ich einfach ungerne, weil man ständig dokumentieren muss, was wo warum verstellt wurde. Dann ändert sich bei einem Update im System etwas, die Einstellungen gehen ins Leere und man schleift Jahrelang mist mit sich rum... (als Beispiel).

Gruß :)
 
Yamagi schrieb:
Vor allem zwei Sachen. Einmal "vfs.read_max=32". Damit liest er bei jedem Zugriff immer 32 Blöcke ein. Das ist daher sehr sinnvoll, da ein Zugriff fast immer von einem weiteren Zugriff nur wenige Blöcke weiter gefolgt wird.
Zum Vergrößern anklicken....

Hm, das versteh ich grad nicht ganz. Default steht das auf 256, wobei ja mehr gecacht werden müsste?
 
Moment... Da haben sie den Standardwert geändert. Früher war es immer "8". Hmpf, das war irgendwie an mir vorübergegangen. Danke für den Hinweis... :)
 
Hier ist es auch 8.

Ist eine FreeBSD 8.0 Installation, die auf 8.1 aktualisiert wurde. 64bit
 
Mag das controllerabhägig sein? Da muss ich im Code lesen, das mache ich aber nicht mehr heute.
 
Also ich hab meine Platten an keinem Controller direkt. Nur am Mainboard (MSI 785GM-E51) per AHCI. Die Systemplatte hängt per USB dran, leider. :D
 
Also ich habe mir die Seite jetzt mal angesehen. Ich kann aber irgendwie nicht glauben das UFS so extrem langsam sein soll. Ich verstehe auch nicht warum noch Btrfs getestet wurde, nach meinem Wissen ist das nicht einmal andeutungsweise so ausgereift das man es wirklich nutzen kann. Das ein halbfertiges Dateisystem nantürlich sehr viel schneller sein kann ist klar :)

Lassen sich Dateisysteme überhaupt Systemübergreifent vergleichen?

Grüße
 
Yamagi schrieb:
Moment... Da haben sie den Standardwert geändert. Früher war es immer "8". Hmpf, das war irgendwie an mir vorübergegangen. Danke für den Hinweis... :)
Zum Vergrößern anklicken....

Bei meinem RELENG_8 von März isses noch 8, wäre schon gut wenn es irgendwo eine überischt der evolution der sysctl-defaults gäbe…
 
christian83 schrieb:
Lassen sich Dateisysteme überhaupt Systemübergreifent vergleichen?
Zum Vergrößern anklicken....
Nein, lassen sie sich nicht. Das wurde auch schon öfter mal als Reaktion auf ältere Phoronixbenchmarks auf den FreeBSD-Listen diskutiert und umgekehrt auch bei den Linuxern. Es geht damit los, dass jedes Betriebssystem und auch jedes Dateisystem anders cached. Sprich, man steht erst einmal vor der undankbaren Aufgabe es zu schaffen nicht den Cache zu messen. Wenn man das hinbekommt, sind da die Schreibstrategien. Linux schreibt sehr aggressiv auf die Platte, FreeBSD eher gemächlich. Dazu verschiedene Ausrichtungen. Linux ist sehr auf parallele Zugriffe optimiert, FreeBSD eher auf sequentielle. Und dann ist da noch der alte Spruch "Wer misst, misst Mist!". Synthetische Benchmarks sind immer reichlich nichtssagend.

Grundsätzlich hat Phoronix schon recht. Linux schlägt seit Urzeiten FreeBSD in fast jedem Dateisystembenchmark, es wäre seltsam, wenn es plötzlich anders wäre. Aber die Unterschiede sind dennoch zu groß. Meine Vermutung: Fast alle Benchmarks dort nutzen sehr stark parallele Zugriffe. Die waren aber noch nie FreeBSDs Stärke, im Gegenteil. Hier im Forum finden sich genügend Threads aus der Zeit von 6.x und 7.x das parallele Zugriffe quälend lahm und sogar gegenseitig blockierend sind. Mit FreeBSD 8 gibt es da keinen Grund zur Beschwerde mehr, in der Praxis. In der Therorie ist FreeBSD dabei trotzdem deutlich langsamer als Linux oder auch Windows.

Am Ende kann ich nur einen Tipp geben: Nehmt ne Linux-CD, Ubuntu hat z.B. ne schöne, startet von der und probiert mal selbst ein wenig rum. Linux-Kernel entpacken, Dateien von / in eine RAM-Disk kopieren und sowas. Das Ergebnis wird sein, dass sich in der Praxis Linux, FreeBSD und auch praktisch jedes andere System nichts groß nehmen. Unterschiede mag es nur in wenigen, ausgesuchten Workloads geben.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben