Gesucht: Einstieg in ZFS

berni51

berni51

Open-Net-FreeBSD user
Also ich hab keine Ahnung von ZFS. Hab mich auch nie darum gekümmert und bisher alles dem OS selbst überlassen, z.B. FreeBSD. Waren auch immer einfache Systeme mit nur einem Datenträger (SSD).
Jetzt aber mus ich mal ran! Hab ein Openindiana vor mir, auch nur mit einer SSD. Da muss aber eine zweite SSD rein, die das /opt-Verzeichnis aufnehmen soll.
Herkömmlich natürlich kein Problem: SSD vorbereiten mit fdisk, disklabel, newfs., dann Daten drauf und mounten. Easy.

Aber wie mach ich das mit zfs?
Muss die Platte ebenfalls vorbereitet werden, bevor ich einen zweiten zpool einrichte?
Wird die fstab/vfstab überhaupt noch benötigt oder mach das alles zfs?
Und macht es z.b. Sinn, die Platte einfach in den Pool zu bringen und überhaupt nicht zu mounten?
Ist Kompression sinnvoll oder verlangsamt das System dadurch?
Nur Fragen!

Klar, ich muss mich einlesen, aber ich finde, das ist nicht so einfach. Gute Beschreibungen wie die von Oracle verweisen ständig auf weitere Dokumente und sind damit fast so schön zu lesen wie eine DIN-Norm. Und etliche andere kopieren nur Teile aus den man-pages zusammen. Jedenfalls hab ich den richtigen Einstieg noch immer nicht gefunden.
Vielleicht kennt ja einer von euch die Anleitung für Dummies.

Grüsse
Berni
 
berni51 schrieb:
Muss die Platte ebenfalls vorbereitet werden, bevor ich einen zweiten zpool einrichte?
Zum Vergrößern anklicken....
Es empfiehlt sich, eine GPT-Partition draufzupacken, zu labeln und (wichtig!) unabhängig davon was das Gerät von sich behauptet, das alignment auf 4k ( readme ) zu setzen.

Beispiel:
Code: 
gpart create -s GPT da1
gpart add -a 4k -t freebsd-zfs -l WD-SERIAL123 da1

Dann pool erstellen, Beispiel einmal Singleplatte:
zpool create singletank da1 oder für zweizpool create spiegeltank mirror da1 da2

berni51 schrieb:
Wird die fstab/vfstab überhaupt noch benötigt oder mach das alles zfs?
Zum Vergrößern anklicken....
Automagisch (ist sinnig, außer man will das nicht, lässt sich auch deaktivieren), spiegeltank wird als /spiegeltank gemountet. Oder eben als /opt, wenn gewünscht. (Die Unterteilung nochmals auf datasets sollte man dennoch machen, auf den pool direkt schreibt man normalerweise nicht)

berni51 schrieb:
Und macht es z.b. Sinn, die Platte einfach in den Pool zu bringen und überhaupt nicht zu mounten?
Zum Vergrößern anklicken....
Also es kommt darauf an...oder ich verstehe die Frage falsch. Eine einzelne Platte als pool ist wegen der mangelnden Ausfallsicherheit/Redundanz recht witzlos und ZFS kann seine Vorteile nicht voll ausspielen. Mit einem mirror bekommst du aber auch nicht mehr Speicherkapazität (interpretiere ich mal so, wenn es für /opt sein soll?).

berni51 schrieb:
Ist Kompression sinnvoll oder verlangsamt das System dadurch?
Zum Vergrößern anklicken....
Im Gegenteil, es wird sogar schneller. (Wenn man nicht gerade eine 20 Jahre alte CPU hat)
Kompression will man bis auf Randbedingungen immer. Langsamer wird es nur, wenn man von Standard-Settings abweicht.
zstd-3 (neuer Standard) oder lz4 (alter Standard) sind so flott, dass man sich keinen Kopp drum machen muss.
 
Super, Danke dafür. Aber noch eines:
Ein pool besteht ja bereits (rpool). Werde ich den erweitern oder einen neuen erstellen und den alten löschen?
 
Ich sag mal das geht nicht, so wie du dir das vielleicht vorstellst. Wie würdest du denn erweitern wollen?

Du kannst mit einer weiteren Platte aus einem singlepool (singleplatte->singlevdev=singlepool) einen mirrorpool (eigentlich mirrorvdev!) machen. Das gibt dir Redundanz, aber nicht weiteren Speicherplatz.
Du kannst nicht einfach zwei Platten hintereinander dranflanschen (innerhalb eines vdevs) und mehr Kapazität haben. (ich hoffe, ich sag jetzt nix falsches in Bezug auf openzfs und von openindiana weiß ich quasi garnix).
Du kannst ein weiteres vdev (bestehend aus der zweiten Platte) hinzufügen, das gibt mehr Speicherplatz, fährt dir aber doppeltes Risiko ein. Ein pool besteht aus vdevs, sobald ein vdev wegfällt, ist der ganze Pool platt. Dh. für sicheren Betrieb hat man innerhalb eines/mehreren vdevs die Redundanz zu gewährleisten.

Gut erklärt und gut bebildert:
arstechnica.com

ZFS 101—Understanding ZFS storage and performance

Learn to get the most out of your ZFS filesystem in our new series on storage fundamentals.
arstechnica.com arstechnica.com
 
mr44er schrieb:
Es empfiehlt sich, eine GPT-Partition draufzupacken, zu labeln und (wichtig!) unabhängig davon was das Gerät von sich behauptet, das alignment auf 4k ( readme ) zu setzen.

Beispiel:
Code: 
gpart create -s GPT da1
gpart add -a 4k -t freebsd-zfs -l WD-SERIAL123 da1

Dann pool erstellen, Beispiel einmal Singleplatte:
zpool create singletank da1 oder für zweizpool create spiegeltank mirror da1 da2


Automagisch (ist sinnig, außer man will das nicht, lässt sich auch deaktivieren), spiegeltank wird als /spiegeltank gemountet. Oder eben als /opt, wenn gewünscht. (Die Unterteilung nochmals auf datasets sollte man dennoch machen, auf den pool direkt schreibt man normalerweise nicht)


Also es kommt darauf an...oder ich verstehe die Frage falsch. Eine einzelne Platte als pool ist wegen der mangelnden Ausfallsicherheit/Redundanz recht witzlos und ZFS kann seine Vorteile nicht voll ausspielen. Mit einem mirror bekommst du aber auch nicht mehr Speicherkapazität (interpretiere ich mal so, wenn es für /opt sein soll?).


Im Gegenteil, es wird sogar schneller. (Wenn man nicht gerade eine 20 Jahre alte CPU hat)
Kompression will man bis auf Randbedingungen immer. Langsamer wird es nur, wenn man von Standard-Settings abweicht.
zstd-3 (neuer Standard) oder lz4 (alter Standard) sind so flott, dass man sich keinen Kopp drum machen muss.
Zum Vergrößern anklicken....
Wobei Dir die Kompression böse auf die Füße fallen kann. Von wegen Backup und Medienplanung. :-)
oder wie es mir passiert ist, der Snapshot Transfer zwischen zwei Kisten. Nen Kollege hatte auf der Quelle die Kompression aktiviert, es aber nicht dokumentiert. Ich wollte die Zone umziehen und sah zu wie das Ziel, war etwas knapp bemessen, immer weiter zulief. :-)
 
berni51 schrieb:
Aber wie mach ich das mit zfs?
Zum Vergrößern anklicken....
willst du den bestehenden rpool mit der zweiten Platte erweitern oder damit einen eigenen Pool für /opt (Annahme: das bislang existierende /opt bei dir ist jetzt noch leer?) aufmachen?

berni51 schrieb:
Muss die Platte ebenfalls vorbereitet werden, bevor ich einen zweiten zpool einrichte?
Zum Vergrößern anklicken....
eigentlich nicht, ein "zpool create <poolname> <device>" erledigt alles (das würde einen neuen Pool einrichten)
Wenn du es gleich unter /opt mounten willst, dann noch ein "-o mountpoint=/opt" nach dem "create" dazu (ich meine das war die korrekte Syntax für OI)

berni51 schrieb:
Wird die fstab/vfstab überhaupt noch benötigt oder mach das alles zfs?
Zum Vergrößern anklicken....
ZFS existiert ausserhalb der fstab;
Du könntest z.B. auch ne ZFS Platte von nem anderen System einbauen und nach einem darauf etwaig vorhandenen Pool mittels "zpool import" suchen lassen, ganz ohne je eine fstab bemühen zu müssen;

berni51 schrieb:
Und macht es z.b. Sinn, die Platte einfach in den Pool zu bringen und überhaupt nicht zu mounten?
Zum Vergrößern anklicken....
Du meinst, den bestehenden "rpool" erweitern?

berni51 schrieb:
Ist Kompression sinnvoll oder verlangsamt das System dadurch?
Zum Vergrößern anklicken....
Kompression würd ich immer aktivieren (lz4 für den tägl. Gebrauch, das neue zstd für "cold storage"), es ist mit den CPUs seit 2010 eigentlich unmerklich.
 
es ist ja da schon alles notwendige gesagt worden.
Deshalb nur kurz: ohne Redundanz ist alles Mist!

Und vielleicht einen alternativen Ansatz:
Das System gleich komplett neu zu machen, also auf eine (oder zwei) neue SSDs zu übertragen. Der Hintergedanke ist, dass ja neue SSDs auch immer billiger werden und deshalb einfacher mehr Platz eingekauft werden kann. Dann könnte die neue SSD gleich mit allen benötigten Datasets, gewünschter Kompression, gewünschtes Allignement (ich gehe inzwischen sogar deutlich über 4K und nehme am liebsten volle 100M) eingerichtet werden und das System dann von alter SSD auf neue SSD übertragen werden ( evtl zfs send...). Anschließend könnte die alte SSD womöglich noch einen neuen Pool bekommen und etwa für ein benötigtes Dataset oder für interne Backups benutzt werden.
 
Puh, nach euren Kommentaren merk ich jetzt, dass ich gar nicht genau weiss, was ich will. OK, eigentlich möchte ich beides: Datensicherheit und mehr Speicherplatz.
Mein Szenario sieht wie folgt aus:
  • bisher eine SSD (m2sata, 240GB), darauf ein pool (name=rpool). Die Platte ist zu ca. 10% belegt.
  • Auslagern möchte ich /opt. Darin befinden sich etwa 18 GB Daten.
  • Dazu sollen zunächst eine weiter SSD (pcie-nvme, 240GB). Die wollte ich für /opt nehmen.
  • Ebefalls bereit liegt eine weitere SSD (pcie-nnvme, 500GB). Damit wollte ich einfach nur mehr Speicherplatz für die pools schaffen.

Ich merke jetzt selber, dass ich gedanklich immer noch im alten Dateisystem bin. Mir fehlt einfach noch die Fantasie, in den Möglichkeiten von zfs zu denken.

Die vorhandene Platte würde ich liebsten so belassen, wie sie ist, nur mit ausgelagertem /opt.

Wäre es ein sinnvolles Konzept, aus den drei Platten einen mirror-pool zu erstellen? Und muss ich mir eigentlich Gedanken über das Auslagern von /opt machen, oder kann ich das dem zfs überlassen, der den gesamten Platz der 3 SSD zur Verfügung hat?

Und wenn das so geht, wie gehe ich da vor? Kann ich meinen vorhandenen rpool online löschen und einen neuen erstellen? Oder ziehe ich mir damit selbst den Boden unter den Füßen weg und stehe ohne pool irgendwo im Nichts meiner SSD?
 
Die m2sata wird halt DEUTLICH langsamer als die nvme sein, weshalb ein mirror der sata+nvme vielleicht nicht die beste Idee ist. Du würdest halt die Performance der nvme verlieren. Bei nem mirror aus den beiden nvmes verlierst du logischerweiße Speicherplatz, du könntest einen teil der großen nvme aber vielleicht als Backupspeicher oder ähnliches verwenden.
Vorallem wenn du deinen rpool so belassen möchtest wäre das eine einfache Möglichkeit.

Aber was ich oft beim ZFS Thema merke: Redundanz durch ZFS erhöht per Definition in erster Line die Verfügbarkeit. Datensicherheit nur sehr bedingt und ersetzt aus diversen Gründen kein Backup. Wenn es dir also nicht um Verfügbarkeit geht, nimm nur eine Platte und kümmere dich lieber um ein gutes Backup.

Zur letzten Frage: Live kannst du den rpool nicht löschen, da müsstest du von einem alternativen Livesystem booten.
 
berni51 schrieb:
Ich merke jetzt selber, dass ich gedanklich immer noch im alten Dateisystem bin. Mir fehlt einfach noch die Fantasie, in den Möglichkeiten von zfs zu denken.
Zum Vergrößern anklicken....
Hast nicht nen alten Rechner und ein paar alte Platten zur Verfügung? Boote ein BSD oder Linux mit ner aktuellen OpenZFS und mach zpool create/destroy sowie zfs create/destroy/snapshot Sessions und schau, wie sich die Sache verhält.
berni51 schrieb:
Die vorhandene Platte würde ich liebsten so belassen, wie sie ist, nur mit ausgelagertem /opt.
Zum Vergrößern anklicken....

Das wäre ohne weitere Platte ein "zfs create rpool/opt -o mountpoint=/opt" auf der bestehenden Platte mit dem rpool; /opt ist ab da ne eigene Entität und nicht mehr nur Folder unter /.
Falls /opt schon Daten enthalten hat, müssteste diese vorher z.B nach /tmp oder dein Home kopieren und dann hernach ins "neue" /opt.
Ab da könnteste dann z.B. ein Quota für /opt vergeben ("zfs set quota=10g rpool/opt") und damit verhindern, dass deine rpool-Platte über /opt vollläuft.

Analog halt mit ner 2. Platte und /opt auf dieser, wie weiter oben beschrieben

berni51 schrieb:
Wäre es ein sinnvolles Konzept, aus den drei Platten einen mirror-pool zu erstellen? Und muss ich mir eigentlich Gedanken über das Auslagern von /opt machen, oder kann ich das dem zfs überlassen, der den gesamten Platz der 3 SSD zur Verfügung hat?
Zum Vergrößern anklicken....
Technisch wäre es mittels zfs möglich, aber wie medV2 schon schrieb, obs Sinn macht...
Mit zfs kannst du mehrere Platten auch als Mirror (analog zu einem Raid1) zusammenfügen, d.h. ein Mirror kann bei zfs durchaus aus mehr als 2 Platten bestehen.
Allerdings ist die nutzbare Größe des Mirrors dann die der kleinsten Platte, d.h. bei deinem Fall mit 2x 240GB und 1x 500GB würdest du max nur die 240GB erhalten, und Platz auf der 500GB verschenken.

Stripe wäre prinzipiell auch möglich, nur darf halt dann gar keine ausfallen.
berni51 schrieb:
Und wenn das so geht, wie gehe ich da vor? Kann ich meinen vorhandenen rpool online löschen und einen neuen erstellen? Oder ziehe ich mir damit selbst den Boden unter den Füßen weg und stehe ohne pool irgendwo im Nichts meiner SSD?
Zum Vergrößern anklicken....
Den laufenden rpool läßt dich zfs nicht anfassen; wie du schon richtig schriebst: "Boden unter den Füßen"
Wenn du das System noch als Spielsystem nutzen kannst - oder ein 2. altes System verfügbar hast: Boote mal wie oben gesagt ein Live-System und spiel am Besten mal mit zfs und den Optionen rum.

Im Endeffekt braucht man nur einen Teil der möglichen zfs-Befehle für den täglichen Bedarf:

zpool create/destroy/list/status/iostat
zfs create/destroy/list
zfs create [-r] snapshot
zfs list -t snapshot
zfs send/receive
 
turrican schrieb:
Hast nicht nen alten Rechner und ein paar alte Platten zur Verfügung? Boote ein BSD oder Linux mit ner aktuellen OpenZFS und mach zpool create/destroy sowie zfs create/destroy/snapshot Sessions und schau, wie sich die Sache verhält.
Zum Vergrößern anklicken....

Warum echte Hardware, wenn man mit einer VM auch Setups mit dutzenden von Platten ausprobieren kann...
 
berni51 schrieb:
Die vorhandene Platte würde ich liebsten so belassen, wie sie ist, nur mit ausgelagertem /opt.
Zum Vergrößern anklicken....
Warum würdest du auslagern wollen? Ich bin da jetzt mal gedanklich bei dem Fall, dass die Platte auf der /opt dann ausgelagert wäre, gerade stirbt. Fänd ich nicht so pralle. Man kann das machen, aber es könnte sich da eine schlechte Angewohnheit reinschleichen, die man hintenraus bereut je mehr man so verteilt...und vergisst oder genau dann was stirbt, wenn mans nicht gebrauchen kann.
Je nachdem kann man sich was ohne Neuinstallation hinbiegen, aber frisch aufsetzen sollte der einfachere Weg sein - auch mit Blick auf die Konstellation der vdevs, die man wählt.

berni51 schrieb:
Wäre es ein sinnvolles Konzept, aus den drei Platten einen mirror-pool zu erstellen?
Zum Vergrößern anklicken....
Kurzes Ja. Schöner wären halt drei gleiche Platten/SSDs, sonst gibts wie auch schon von medV2 angemerkt die Einbußen. Ich persönlich finde das aber dennoch besser als einzeln was zu verteilen. Diese drei Geräte in einem mirror-vdev bedeutet: Kapazität der kleinstens disk (2x240G, 1x500G = 1x 240G), Schreibgeschwindigkeit der langsamsten disk, aber im Gegenzug Lesegeschwindigkeit gemittelt addiert von allen drei disks.
-> https://constantin.glez.de/2010/06/04/a-closer-look-zfs-vdevs-and-performance/
Und natürlich dürfen zwei disks davon ausfallen, ohne den Betrieb zu stören. (Kaltbackup sollte man trotzdem gesondert machen, egal wieviel mirrors/raidz man drunterpackt!). Am flexibelsten bist du mit mirrors und nehmen wir jetzt mal den Bonbonfall an, dass die beiden 240G-disks kaputtgingen. Dann kaufst du 2x 500G Ersatz, machst ein resilver (zfs-sprech für resync) und anschließend erhältst du info, dass jetzt der pool auf 500G aufgepustet werden kann. Nach 'oben' mit größeren und schnelleren Platten geht dann immer. Weitere disks hinzufügen oder entfernen ist beim mirror auch unproblematisch. raidz ist dann nochmal eine andere Geschichte.

berni51 schrieb:
Und muss ich mir eigentlich Gedanken über das Auslagern von /opt machen, oder kann ich das dem zfs überlassen, der den gesamten Platz der 3 SSD zur Verfügung hat?
Zum Vergrößern anklicken....
Wahrscheinlich nicht, weiß es aber nicht. Kommt auch auf deinen workflow an. Man sollte es gedanklich vllt. so trennen, dass man nicht mehr primär auf einzelne Platten was ablegt und zunächst in vdev, pool, dataset denkt.

Von einem System stripe/raid0 würde ich ganz die Finger lassen, das multipliziert die Wahrscheinlichkeit Totalausfall mit jeder weiteren disk. Das ist ganz schön für "billig auf einen Schlag nen Haufen Platz", das wars aber auch schon.
 
Danke Leute, danke für eure fachkundigen & konstruktiven Beiträge! Dadurch hab ich mehr gelernt als durch das tagelangen Stöbern im Netz in den vergangenen Tagen.

Ich hab mich jetzt für folgendes Vorgehen entschieden:
- Mit Netzteil und einem vorhandenen Intelboard mit i5 sowie 5 ausgedienten TB-Platten (schöne alte Drehplatten) bau ich einen provisorischen Versuchs-ZFS-Rechner auf und beschäftige mich den heutigen Sonntag damit.

- Es wird ein Backup der OI SSD (240GB) gezogen.

- Hab gestern noch 2 weitere nvme 500GB Platten bestellt (die letzten für 35€/St. bei Mindfactory). Dann baue ich das OI System mit der 500er nvme aus dem Backup neu auf. 500 GB sind für das System mehr als genug. Damit hab ich dann hoffentlich ein stabiles und relativ ausfallsicheres System.

Grüße
Berni
 
turrican ging noch drauf ein, mir ging das beim Schreiben etwas durch die Lappen. Also ja klar, du kannst einfach eine blanke disk nehmen. Das dämpft aber den Durchsatz und man ärgert sich nachher darüber, wenn man es nicht direkt korrekt einheitlich macht. Ergibt sich aus dem bereits verlinkten Thread: https://www.bsdforen.de/threads/zfs-block-size.36085
Auch die Benennung/Zerwürfelung von den Bezeichnungen und Labels können dann passieren...tldr; mit Partition ist einfach optimal und schöner.
Dennoch kannst dus ja mal mit und ohne versuchen...Versuch macht kluch. Rumfummeln mit Testumgebung wo man nichts kaputtmachen kann, ist eh der beste Lehrmeister. ;)

berni51 schrieb:
sowie 5 ausgedienten TB-Platten
Zum Vergrößern anklicken....
Und damit könnte schon raidz2 oder raidz3 für dich interessant werden. raidz1 (entspricht raid5) kommt für mich nicht in Frage, da darf man nämlich nur eine Platte verlieren. Wenn das genau während der Belastung beim resilver/resync/rebuild passiert, dann ist 'game over'. ;)
 
vielleicht nur noch zur Ergänzung: du kannst zwar deinen System-Pool (den rpool) nicht im laufenden System löschen, aber du kannst einen Snapshot davon in ein neues Ziel senden und dann den nächsten Boot von dort machen. Dieses Ziel kann auch extern sein, zB auf einer USB-Disk. Das kann sehr praktisch sein. Mit solchen Methoden habe ich nun mein System schon mehrfach umgezogen. Von einem PC zu einem anderen, von HDs zu SSDs, zu neuen SSDs mit nunmehr EFI statt legacy und so weiter. Immer sehr beruhigend, nicht nur intern den System-Pool umzuziehen, sondern auch einen bootfähigen, externen Klon davon zur Hand zu haben.
Das geht so nach dem Motto: warum ein Live-System booten, wenn es mein eigenes doch auch von extern tut?

Und als generelle Anmerkung: Geschwindigkeit ist relativ.
Ja, nvme ist unschlagbar, aber ich habe zB zu Gunsten von Redundanz gerne darauf verzichtet. Den großen Unterschied sieht man halt in der Bootgeschwindigkeit und das bedeutet bei mir: eher nie, weil das System ja immer läuft. Und wenn ich etwa LibreOffice starte und bis zum stehenden Fenster vielleicht zwei mal geblinzelt habe, ist das für mich durchaus schnell genug. Die Anschließende Arbeit wird wenigstens hunderte und tausende von Blinzlern lang dauern, so what? Viel wichtiger ist doch, dass die Anwendung auch lange stabil steht und benutzt werden kann. Wie schnell sie startet, ist für mich nicht so wichtig.
Aber, wenn wir eben schon mal bei Geschwindigkeiten sind: sehr viel schneller und einfacher können Backups auf interne Medien gemacht werden. Das wird sehr oft übersehen, aber eine zusätzliche SSD mit einem Pool drauf kann eben als Ziel eines regelmäßigen Backups wichtiger Daten dienen und bei Bedarf auch ausgebaut und extern angeschlossen werden. Es ist im Betrieb nur sehr viel praktischer, die SSD intern zu haben, anstatt mit externen Steckern etc zu hantieren. Um das vorweg zu nehmen: es spricht auch nichts dagegen, einen solchen internen Backup-Pool selbst wieder redundant anzulegen und es spricht weiter auch nichts dagegen, gleichzeitig noch zusätzliche Backups nach Extern (etwa ins Netz) zu sichern. Man kann nie genug Backup haben.
Aber sehr viel bequemer, als erst ein Backup suchen und einspielen zu müssen, ist es doch, die vorhandene Redundanz erst mal nutzen zu können.

Vielleicht noch meinen Senf als unbedarfter Endnutzer zu Datasets und auslagern von /opt oder was auch immer.
Datasets sind ungemein praktisch und sehr viel besser, als Partitionen, die man dann bestimmten Verzeichnissen im Dateibaum zuordnet. Aber genau so, wie die letztere Methode, muss man das nicht unbedingt haben. Man kann sein System heute auf einer einzigen Partition anlegen. Die wichtigen Vorteile von vielen Partitionen sind (meiner Ansicht nach) fast alle obsolet. Und so kann man das vielleicht auch mit vielen Datasets sehen. Wenn man nicht viele unterschiedliche Eigenschaften braucht, braucht man auch nicht viele Datasets. Und auf unterschiedliche Platten/Partitionen zu verteilen, braucht man die auch nicht.
Ein evtler Vorteil von ZFS ist das Exportieren von Datasets als NFS-Share. Will man so etwas, macht es natürlich Sinn, sich vorher Gedanken zu machen.
Ansonsten geht es aber auch mit sehr wenigen bis gar keinen Datasets.
 
turrican schrieb:
Guter Punkt, aber is das bei OpenIndiana auch so?
Zum Vergrößern anklicken....
Das mit dem alignment an sich ist bei jedem Betriebssystem so. Im dummen Fall verbrutzelt man damit sinnlos IOPS ohne Gegenwert. Grafisch aufgemacht erklärt sichs besser -> https://www.ateamsystems.com/tech-blog/freebsd-partition-alignment-raid-ssd-4k-drive/

Man will dann hintenraus bei zfs auch ashift=12 fahren. Das geht schief, wenn eine Platte von den beteiligten lügt. Daher ist es besser (auch wenn alle drei Platten wirklich nur 512 Sektoren haben oder Mischmasch melden/vorlügen) 4k zu forcieren, um bei ZFS ashift=12 fahren zu können.

ZFS auf Linux/ ashift – Wikibooks, Sammlung freier Lehr-, Sach- und Fachbücher

de.wikibooks.org de.wikibooks.org

Optimizing Performance of SSDs and Advanced Format Drives - Lustre Wiki

wiki.lustre.org wiki.lustre.org
 
@mr44er - das ashift alignment hat was damit zu tun, ob ich die ganze Platte oder eine Partition dessen nehme? Wusste ich bislang gar nicht.
Hab immer "ganze Platten" zugeordnet, ohne Partitionierung (bei FreeBSD Install natürlich nicht, da hab ich den Installer machen lassen, und der legt ja bekanntlich auch ne swap an usw).
 
turrican schrieb:
das ashift alignment hat was damit zu tun, ob ich die ganze Platte oder eine Partition dessen nehme?
Zum Vergrößern anklicken....
Jein. Du kannst beim Erstellen des pools auch ashift forcieren (die ZFS-Automagie für ashift schlägt fehl, wenn eine Platte lügt). Wenn man vorher geli mit 4k erst drunterpackt, kann man das damit auch schon abschmatzen. Ich bin aber ein Freund von 'alles einheitlich'. Wenn was brennt, will ich anhand der Flammenfarbe deuten können, wo es herkommt/herkommen könnte. :p


bsdinstall-zfs-menu.png


"Force 4K Sectors" gibts da im Menü genau deswegen bereits. Wenn man dann in /var/log/bsdinstall_log spickt, kann man das hübsch verfolgen.

Code: 
...
DEBUG: zfs_create_boot: sysctl vfs.zfs.min_auto_ashift=12
vfs.zfs.min_auto_ashift: 9 -> 12
...
DEBUG: zfs_create_diskpart: gpart add -a 4k -i 4 -t freebsd-zfs "ada0s1"
...
 
Wie gesagt, beim Installer wär ich davon ausgegangen, dass der das schon irgendwie macht, bzw kann ich mich da nicht an Probleme erinnern, geschweige denn, da je was eingestellt zu haben; das installierte OS hab ich so gelassen wie es is. Das war eh ziemlich statisch nach Installation und Konfiguration.

Bei hinzufügen von Platten für die pools halt dann händisch die "-o ashift=12" fürs vdev (EDIT: ganze Platte, ohne extra ne Partition einzurichten) mitgegeben und eingestellt hernach maximal die Recordsize von den daraufliegenden Datasets, je nach Anwendungsfall - oder auch beim Default belassen.
 
Hab den Sonntag Nachmittag bis tief in die Nacht mit meinem Versuchsaufbau und einem Stapel Festplatten verbracht. Dabei eure Hinweise abgearbeitet und viel (für mich) Neues probiert: 2-way-morror, 3-way-mirror, stripe, raid1/2.
Zfs hat dabei alles überlebt - fast alles: Der Versuch, aus einem 2-way-mirror einen 3-way-mirror zu machen, verlief scheinbar erfolgreich. Nur hat das System danach keinen Bootblock mehr gefunden und konnte nicht mehr starten. Schätze aber, das lag eher an mir, hab wahrscheinlich einen Schritt vergessen (resilvering?).
Hab alle Versuche mit omnios gemacht, das ja wie OI auch auf Illumos basiert und in wenigen Minuten neu installiert ist.
Für mein OI hab ich eine einfache provisorische Lösung gefunden: Die 500GB ssd ist zu einem separaten zpool namens opt geworden und erweitert somit automatisch das System - zumindest solange, bis ich aus drei 500ern einen Mirror mache. Oder ich mache aus den beiden 250ern und 2 500ern zwei Mirrors Spricht irgendwas dagegen?

In diesem mittleren Chaos hatte ich einen erquicklichen halben Sonntag.
 

Anhänge

  • zfs-trials.webp
    zfs-trials.webp
    90,6 KB · Aufrufe: 308
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben