ZFS oder UFS für single disk?

jmt

Well-Known Member
Hallo,

wenn ich über ZFS lese, dann verwenden die Schreiber meist mehrere Platten in einem Pool. Mein Setup besteht aber aus verschieden einzelnen Platten, die ich eigentlich aus diversen Gründen nicht zu einem Raid zusammenschließen will. Sollte man nun für die Platten UFS nutzen, oder kann man auch ZFS dafür verwenden? Und wenn man UFS für die einzelnen Platten verwendet, kann man dann trotzdem im System ein ZFS Raid benutzen oder vertragen sich die beiden FS nicht?

Gruß Markus
 
Mit einer Platte hast Du keine großartige Möglichkeit die Selbstheilung von ZFS zu benutzen. Dennoch werden Fehler mit Hilfe von Prüfsummen erkannt.

Das wichtigste an einem Dateisystem ist die Integrität der Daten. ZFS kann das am besten machen und Probleme erkennen.

ZFS sollte nicht auf einem RAID-Verbund installiert werden. ZFS ist bereits selbst der RAID-Verbund und kann es besser verwalten jeder noch so teure RAID-Controller. Für ZFS sollte man etwa gleich große Partitionen auf verschiedenen Platten für den Pool konfigurieren. Du kannst sie dann zu einem Mirror, ZRaid oder sonst einem sog. vdev zusammenfassen.

Ich habe auch auf einem Server UFS und ZFS, weil der dortige Adaptec RAID-Controller, den ich benutzen einfach zu dumm programmiert ist, um Platten einzeln ansteuern zu können. So habe ich GPT mit /boot auf geom_mirror und darin UFS, Swap und ZFS-Pool auf der großen Partition (alles pro Platte einmal). Das geht alles FreeBSD ist mit GEOM einfach genial flexibel und ZFS ist das Sahnehäubchen oben drauf. :)
 
Die Frage ist nicht so einfach zu beantworten. Die generelle Antwort ist natürlich: Ja. Nichts hindert dich daran, ein ZFS auf nur einer Platte oder einer SSD zu nutzen. Das mache ich auf meinem Desktop auch. Du kannst dabei auch alle Funktionen von ZFS nutzen, wie z.B. das dynamische Volumenmanagement. Nur wie Nakal sagt, verliert man ohne Redundanz ZFS Selbstheilung. Wenn Fehler in Daten auftreten, sagt er dir nur "Please restore the file from backup" und erklärt sie für verloren. (*) Was allerdings keinesfalls schlecht ist. Denn bei UFS würdest du gar nicht bemerken, dass die Datei beschädigt wurde, es sei denn die sie nutzende Anwendung kann es erkennen.

Zu beachten ist aber ZFS nicht unerheblicher Ressourcenverbrauch. Die CPU ist weitgehend egal, ohne sehr große RAID-Verbünde erreicht man auf jedem halbwegs aktuellen System eigentlich keine nennenswerte CPU-Last durch ZFS. Wesentlich entscheidender ist RAM. ZFS cached extrem aggressiv, wird sich unbegrenzt (eine Begrenzung ist einfach zu setzen) eher früher als später alles an RAM einverleiben, was deine Kiste hat. Er gibt zwar generell RAM frei, wenn jemand anders ihn benötigt, aber der Mechanismus ist recht träge. Gerade wenn auf einem Schlag sehr große Mengen Speicher benötigt werden (da z.B. eine VM gestartet wird), drückt ZFS das System schon mal in die Swap. ZFS sollte man über den Daumen idealerweise schon 8GB gönnen, eine niedrigere Begrenzung ist möglich, aber nicht unbedingt sinnvoll...

Früher hätte ich gesagt, dass wer nur Daten speichern will UFS nehmen sollte. Inzwischen ist ZFS aber sehr ausgereift und moderne Maschinen sind in Sachen RAM meist mit 16GB und mehr bestückt. Daher habe ich meine Meinung geändert: Wenn du ausreichend RAM hast (>=8GB, wenn du viel mit RAM-Fressern hantierst besser 16GB), greife zu ZFS. Den Weg zu UFS versperrst du dir nicht, gab es am Anfang Probleme können nun schon seit einigen Jahren ZFS und UFS wunderbar koexistieren.

*: ZFS kann auch die Daten mehrfach auf einer Platte speichern und damit Redundanz schaffen. Aber das ist lahm und wenig zielführend. Wenn die Platte im Eimer ist, nützen auch 10 Kopien auf ihre nicht.
 
*: ZFS kann auch die Daten mehrfach auf einer Platte speichern und damit Redundanz schaffen. Aber das ist lahm und wenig zielführend. Wenn die Platte im Eimer ist, nützen auch 10 Kopien auf ihre nicht.

Naja, wenn Platten von jetzt auf gleich komplett ausfallen, trifft das wohl zu. Aber meistens hat man entweder einen Lesefehler, wo sie nicht mehr drüberkommt, wo der Rest aber noch zu retten ist oder man hat bitrot. Gegen beides helfen mehrere Kopien auf einer Platte.
 
Der Vorschlag mehrere Partitionen auf einer Platte zu einem Pool zusammen zu fassen, um Redundanz zu bekommen gehört sicherlich in die Abteilung "bad practice". Es ist nicht nur der totale Ausfall, der hier bedrohlich ist. Man sollte im Falle des Falles eine kränkelnde Festplatte nicht zusätzlich noch "herausfordern" indem man sie übermäßig belastet und das wird dann passieren, wenn man die Daten von dieser am Ende auf eine neue retten möchte. Der Kopf wird hin- und her springen und alles noch viel näher an den Rand des Datenverlustes bringen.
 
Keiner hat etwas von mehreren Partitionen gesagt. Yamagi sprach vermutlich vom ZFS "copies" Feature. Du musst ja nicht von jeder Datei mehrfache Kopien anfertigen.
Im übrigen werden bei vielen modernen Dateisystemen die Daten nicht zwangsläufig an einer Schnur geschrieben. Für ZFS gibt es nicht einmal ein defrag Tool. Ein "Springen" des Lesekopfs ist auch mit einer Partition sehr wahrscheinlich, sollte diese vorher auch im Alltag genutzt worden sein.
 
Erst einmal Danke für die zahlreichen Informationen. Auf 2 Platten befinden sich ausschließlich Videos (4-10GB pro Datei). Eignet sich hierfür auch ZFS oder sollten diese Filesysteme lieber UFS bleiben. Es ist mir eigentlich wichtiger, die Datei mit ein paar Bit-Fehlern zu behalten, als sie dadurch zu verlieren. Ein Raid ist mir hier definitiv zu teuer, da somit 2 Parity-Platten bräuchte. Hilft hier vielleicht ZFS ohne Checksum?
 
Vorteil von ZFS ist, dass du nicht die ganze HD in einen POOL hinzufügen musst (Mache ich persönlich nie!) sondern es geht auch mit Partitionen! Beispiel: Du hast 3 HD's mit 500GB, 750GB, und 1TB. Auf alle drei HD erstellst du mit "gpart" ein GPT Layout. (Die Ausgabe ist nicht ganz korrekt sollte aber den Sinn zeigen!)
Code:
root@vh6 ~ # gpart show -lp ada0
=>      34  41942973    ada0  GPT  (500G)
        34         6          - free -  (3.0k)
        40  XXXXX  ada0p1  VB56bf9321-p1-zfs  (500G)
  YYYYYYYY         7          - free -  (3.5k)

Code:
root@vh6 ~ # gpart show -lp ada1
=>      34  41942973    ada1  GPT  (750G)
        34         6          - free -  (3.0k)
        40  XXXXX  ada1p1  VB56bf9322-p1-zfs  (500G)
  YYYYYYYY         7          - free -  (250G)

Code:
root@vh6 ~ # gpart show -lp ada2
=>      34  41942973    ada2  GPT  (1T)
        34         6          - free -  (3.0k)
        40  XXXXX  ada2p1  VB56bf9323-p1-zfs  (500G)
  YYYYYYYY         7          - free -  (500G)
Wie du siehst, sind auf der zweiten und dritten HD noch X GB frei. Diese kannst du noch für andere Sachen verwenden.

Den ZPOOL erstellst du jetzt mit den GPT Partitionen "/dev/gpt/VB56bf9321-p1-zfs", "/dev/gpt/VB56bf9322-p1-zfs" und "/dev/gpt/VB56bf9323-p1-zfs".
Code:
zpool create data raidz /dev/gpt/VB56bf9321-p1-zfs /dev/gpt/VB56bf9322-p1-zfs /dev/gpt/VB56bf9323-p1-zfs
Darum immer ein Partition Layout auf der HD erstellen und nie direkt die komplette HD in den ZPOOL hängen.
 
Du hast einige Missverständnisse gezeigt.

1) Wenn es einen defekten Sektor gibt, gibt es in 90% der Fälle gleich 4 oder sogar mehr. Es handelt sich da nicht um Bits, sondern um Kilobyte, die verloren gehen. Mein letzter Plattenausfall vor 2 Wochen hat 100 MB an Daten mit Hilfe von ZRaid retten können. UFS hätte hier ohne RAID mehrere Dateien beschädigt. Für UFS braucht man hier auf jeden Fall mindestens geom_mirror unter dem UFS und dazu auf jeden Fall immer korrekt konfiguriertes S.M.A.R.T.
2) Eine Checksumme im Mirror (1 Parity) warnt Dich schon zuvor, dass eine Platte am kaputt gehen ist. Ein RAID-5 (1 Parity nötig, 1 Platte kann Totalausfall haben) ist genauso. Es warnt und lässt alles bitgenau retten.
3) RAID sollte nur so teuer sein, wie wichtig Deine Daten darauf sind. Lieber teurer als zu billig.
4) Du willst offensichtlich Integrität der Daten (das Werkzeug dafür sind Checksummen) und Schutz vor Ausfall (das Werkzeug ist hier RAID), aber willst beide Werkzeuge nicht. Eine seltsame Aussage.
 
Wenns um Videos geht würde ich (UFS), exFAT oder ext2 nehmen. Mit letzteren beiden kann man die Platten auch mit anderen Geräten lesen, z.B. zur not auch mir der Plastik Media Box am Fernsehen im USB Case.

Performance spielt auch keine Rolle weil sehr große Dateien am ehesten der Best-Case ist.

Und wenns futsch ist, läd man es halt neu runter (Hust).
 
Du hast einige Missverständnisse gezeigt.

1) Wenn es einen defekten Sektor gibt, gibt es in 90% der Fälle gleich 4 oder sogar mehr. Es handelt sich da nicht um Bits, sondern um Kilobyte, die verloren gehen. Mein letzter Plattenausfall vor 2 Wochen hat 100 MB an Daten mit Hilfe von ZRaid retten können. UFS hätte hier ohne RAID mehrere Dateien beschädigt. Für UFS braucht man hier auf jeden Fall mindestens geom_mirror unter dem UFS und dazu auf jeden Fall immer korrekt konfiguriertes S.M.A.R.T.
2) Eine Checksumme im Mirror (1 Parity) warnt Dich schon zuvor, dass eine Platte am kaputt gehen ist. Ein RAID-5 (1 Parity nötig, 1 Platte kann Totalausfall haben) ist genauso. Es warnt und lässt alles bitgenau retten.
3) RAID sollte nur so teuer sein, wie wichtig Deine Daten darauf sind. Lieber teurer als zu billig.
4) Du willst offensichtlich Integrität der Daten (das Werkzeug dafür sind Checksummen) und Schutz vor Ausfall (das Werkzeug ist hier RAID), aber willst beide Werkzeuge nicht. Eine seltsame Aussage.
Sorry, aber ich verstehe Deine Aussagen nicht. Was meinst Du?
 
Und wenns futsch ist, läd man es halt neu runter (Hust).
Ich müsste Sie dann neu im Fernsehen aufnehmen ;-) Deshalb sind Sie mir auch nicht so wichtig wie andere Daten. Dazu kommt noch, dass man ab 1G Platten-Größe ja kein RAID5 sonder mindestens ein RAID6 nehmen sollte. Und letztendlich ist MPEG ja eh ein verlustbehaftetes Format. Darum kann man meist auch ein paar Fehler in der Datei ignorieren.
 
Die Argumentation dazu ist, dass man ab ca. 1TB (nicht GB) die restlichen alten Platten bei einem Rebuild so sehr belastet, dass mit hoher Wahrscheinlichkeit noch eine ausfällt. Ein Rebuild kann bei dieser Plattengröße locker mehr als 24h dauern. Ein Beispiel gibt es hier: https://calomel.org/zfs_raid_speed_capacity.html
 
Die Argumentation dazu ist, dass man ab ca. 1TB (nicht GB) die restlichen alten Platten bei einem Rebuild so sehr belastet, dass mit hoher Wahrscheinlichkeit noch eine ausfällt.
Also das habe ich ja noch nie gehört...

Ein Rebuild kann bei dieser Plattengröße locker mehr als 24h dauern.
Ich kann dir ein Beispiel von einem meiner FreeBSD Samba Server zeigen. 12x 2TB mit RAIDZ3 rebuild Zeit bei einer defekten HD: ca. 5 1/2 Stunden, am Tag bei einer Belastung von ca. 150 Clients.
 
Faszinierend! Ich habe das nun schon öfter gelesen und mich u.A. deshalb von dem Gedanken eines RAIDs bei großen Datenmengen verabschiedet. Ewas off-topic, aber kann man auch ein degraded RAID mit ZFS erstellen?
 
Große Datenmengen kann man ausschließlich nur mit einem RAID vernünftig gegen Datenverlust absichern. In einen Server kommt stets ein RAID (bei Arbeitsplätzen, die verzichtbar/ersetzbar sind und plausiblerweise sowieso gesichert werden müssen, kann man meistens auf RAID verzichten).

Bei ZFS kann man nur auf Umwegen degraded RAID erzeugen. Manche Leute haben es mit "mdconfig -t vnode ..." geschafft. Bei mir ging es nicht. Es gab einen Hänger beim Erstellen des Pools. Da man im Falle von degraded RAID sowieso (insbesondere wenn man es schon vorher weiß) ein Backup zwingend braucht, ist ein Betrieb von degraded RAID sinnlos, außer man hat tatsächlich einen regulären Notfall.
 
@nakal Ich meine hier Heimanwendungen. Es gibt neben dem professionellen Bereich, bei dem Du völlig Recht hast, auch noch einen unprofessionellen. Dort sind die Mittel begrenzt und man lebt mit diesen Einschränkungen. Nichtsdestotrotz sind auch hier Tips hilfreich.
 
Ich habe Dir schon oben eine einfache Daumenregel gegeben: "Sind Dir Deine Daten nichts wert, dann wirst Du sie auch nicht vermissen, wenn sie weg sind.". Dann bist Du plötzlich gekommen mit "Aber meine Video dürfen nicht verschwinden, die brauche ich!". Und jetzt wieder mit... es soll billig sein und es ist Dir nicht so wichtig, wenn man Mittel einspare.

Was denn nun?

Im Endeffekt willst Du also einen Luxussportwagen mit 300 PS, aber er soll nicht so teuer sein, weil Du den ja nur zum Fahren in die Arbeit gebrauchst.
 
Bei Videos reicht es doch vollkommen hier und da mal ein Backup zu machen. Ist ja nicht so, dass da jeden Tag 100 neue Dateien dazu kommen. Zumindest denke ich mir das so bei meiner Musik (die ich aber auch noch auf den CDs habe...) und meinen Fotos. Selbst wenn ich nur alle paar Wochen ein Backup mache, ist der Verlust sehr gering.
 
Dann setze es doch so um wie ich oben gesagt habe. Mach Partitionen auf deine Festplatten, von welchen du dann ein RAIDZ1 builden kannst und die anderen PArtitionen, welche auf den grossen HD's noch frei sind, kannst du für deine Videos ect. verwenden.
 
zuglufttier: Das ist richtig und vernünftig. Backup sollte man ja immer machen. (Z)RAID ist ja kein Backup. RAID verbessert die Verfügbarkeit und ZRAID zusätzlich die Datenkonsistenz. Backup schützt vor versehentlichem Löschen. Backup und RAID verhalten sich also komplett orthogonal zueinander.
 
Zurück
Oben