ZFS / block size

Andy_m4

Well-Known Member
Hallo Forenelite :-)

ich stehe gerade etwas auf dem Schlauch. Ich hatte gerade eine Platte in einem raidz getauscht. Soweit auch alles in Ordnung.
Das "Problem" ist, ein zpool status sagt mir:
Code:
  pool: softraid
 state: ONLINE
status: One or more devices are configured to use a non-native block size.
        Expect reduced performance.
action: Replace affected devices with devices that support the
        configured block size, or migrate data to a properly configured
        pool.
  scan: resilvered 458G in 0 days 06:07:52 with 0 errors on Wed Mar 24 23:18:55 2021
config:

        NAME        STATE     READ WRITE CKSUM
        softraid    ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            ada0    ONLINE       0     0     0
            ada2p1  ONLINE       0     0     0  block size: 512B configured, 4096B native
            ada3    ONLINE       0     0     0
        logs
          ada4p1    ONLINE       0     0     0
        cache
          ada4p2    ONLINE       0     0     0

errors: No known data errors

Der Punkt ist:
block size: 512B configured, 4096B native

Jetzt meine Frage:
Wo wird/ist denn die "block size" konfiguriert?

Mit besten Grüßen
andy_m4
 
Das ist der ashift Parameter von zpool create. ashift=12 = 4096B, ashift 9 ist 512Byte. Je nach Workload sollte es aber keine großen Probleme machen.
 
Ah. Ok. Ist also eine Konfiguration des Pools und nicht der Platte ?!

Je nach Workload sollte es aber keine großen Probleme machen.
Ich hatte die Erstellung der Partition extra mit 1m Alignment gemacht, um etwaige (Geschwindigkeits-)Probleme zu umschiffen.
Von daher sollte mir also nix drohen.
 
Ok. Wenn ich die Ausgabe zdb -C richtig interpretiere, ist die block size (ashift) eine Eigenschaft des Pools. Macht auch irgendwo Sinn, denn auf der unteren Ebene sind ja Pools in Blöcken organisiert. Und insbesondere bei RAIDZ ist es ja dann notwendig, das alle beteiligten Drives die gleiche Blockgröße verwenden.

Der Pool ist ein Bestandspool dessen alte Festplatten auch 512 Byte Blockgröße hatten und dementsprechend die Konfiguration auch korrekt ist/war.
Wenn ich jetzt alle Platten durch 4K-blocksize-Platten ersetze wäre es natürlich schön, wenn ich den Pool umstellen könnte. Ich gehe aber davon aus, das das nicht so ohne Weiteres geht (bzw. darauf hinausläuft, das man die Daten sichert und den Pool völlig neu anlegt).

Welche Implikationen hat es, wenn man es auf 512 Byte Blockgröße lässt?
Weil ich kann mir grad nicht vorstellen, das das gar keine Auswirkungen hat. Nehmen wir mal an ZFS will ein 512-Block schreiben, dann muss das Laufwerk aber 4096 Byte schreiben. Und ZFS wird auch keine Optimierungsversuche machen (oder macht es die doch, weil er ja erkennt das das Drive 4K hat?).
 
Ist also eine Konfiguration des Pools und nicht der Platte ?!
Nicht ganz, im Idealfall sind beide gleich. Hast du Platten mit 512Byte/Sektor native, konfigurierst nichts weiter und erstellst einen pool, wird ashift=9 genommen. Das ist bei deinem Pool der Fall, nachträglich ashift ändern geht nicht. Probleme macht das nicht, nur eben 'reduced performance'.

Hast du wie jetzt einen Mischmasch aus Platten 512Byte und 4096Byte, dann umschifft man das bei allen Platten so: gpart add -a 4k -t freebsd-zfs ada0 und kann damit ashift=12 einsetzen.
Über je weniger Sektoren ZFS nachdenken muss, umso schneller wird es in der Regel. Hat dann auch alles weniger overhead und dir sowie ZFS kann es egal sein, wie die Platte damit klarkommt, sie muss so oder so. ;)

recordsize von 1m nimmt dann für gewöhnlich beim dataset, wirkt sich hier auch wieder positiv aus mit Blick auf die Kompression und geringere Anzahl checksums. Aber Achtung, ich weiß nicht, ob man mittlerweile booten kann, wenn größer als 128k...jedenfalls war das was.

Lesenswert, auch wenn man noch kein OpenZFS einsetzt: https://openzfs.github.io/openzfs-docs/Performance and Tuning/Workload Tuning.html

Mal ein Vergleich: https://www.ateamsystems.com/tech-blog/freebsd-partition-alignment-raid-ssd-4k-drive/
Und nochmal, weiter unten: https://calomel.org/zfs_raid_speed_capacity.html
 
Mal sehen. Vielleicht baue ich ja den Pool neu auf, wenn alle 4k-Platten drin sind. Da von dem betroffenen Pool nicht gebootet werden muss sehe ich da erst mal keine größeren Stolpersteine.

So als grobe Vorgehensweise würde ich wie folgt machen:

Erstmal den Pool serialisieren: zfs send mypool -R > /path/to/backupfile
Dann zerstören via zfs destroy -f mypool
Danach mit halt neu bauen inkl. zpool create mypool raidz ....
Nachprüfen, ob die Blocksize des Pools mit denen der Platten übereinstimmt. :-)
Und dann halt das Backup wieder zurückspielen: zfs receive mypool < /path/to/backupfile

Ist das so im Großen und Ganzen korrekt oder hab ich was übersehen (zum Beispiel sowas wie zpool export ... / zpool import ...) ?
 
wenn alle 4k-Platten drin sind
So lange würde ich gar nicht warten, denn wenn die 512B-Platten noch ordentlich zu erwartende Lebenszeit haben, wäre es ja schade drum und bis dahin fährst du mit reduced performance. Diese ist im jetzigen Zustand schlimmer (schlimm klingt schlimmer als es ist :) ), als einfach alle mit 4k zu alignen.

Einfach alle mit 4k zu alignen, habe ich mir sowieso angewöhnt und dann muss ich mich um die Frage des Modells 4kn oder Emulation oder ob die Platte rumlügt und intern doch anders ablegt, nicht kümmern. Es ist außerdem zukunftsträchtig und so lange wirksam, bis die ersten 8kn Platten kommen. ;)


Ist das so im Großen und Ganzen korrekt
Ja.
Etwas sauberer, aber eig. nicht nötig oder er meckert dann schon von selber:
-Geschmackssache, aber ich schubber bei Umbauten aus Gewohnheit auf einen anderen Pool bestehend aus einer einzelnen Platte.
Code:
zpool export
zfs destroy -f mypool
zpool labelclear -f /dev/ada0
gpart destroy -F ada0
gpart add -a 4k -t freebsd-zfs ada0  #1m kann man sich hier sparen. Bringt was, wenn eine Austauschplatte weniger Sektoren insgesamt hat, man das zukunftsträchtig umschiffen mag und nicht direkt zu größerer Kapazität greift.
zpool create -o ashift=12 mypool raidz

An der Stelle noch der Hinweis, dass man bei steigender Plattenkapazität über den Einsatz von raidz2 nachdenken sollte, wenn man eh gerade schon am Fummeln ist und einen Neukauf plant. Mit Risikoblick auf einen langen möglichen resilver-Lauf und die obendrein damit einhergehenden Leistungseinbußen.
 
mit FreeBSD 13 habe ich noch keinen neuen Pool aufgesetzt und habe es nun gerade nicht zur Hand, um damit zu spielen.
In der Vergangenheit habe ich gesehen, dass fast immer die "guten" Einstellungen schon per Default gesetzt wurden, also die ashift passend und Kompression und so weiter. Das führt natürlich dazu, dass man immer weniger nachdenkt. Erst, als ich vor einiger Zeit mal einen Pool in einem FreeBSD 7 neu aufsetzen musste, wurden mir die Unterschiede mal wieder sehr bewusst, also wie stark die verschiedenen ZFS-Versionen doch voneinander abweichen.
Deshalb, aber nicht nur deshalb, verwende ich in einem Pool immer nur (wenn möglich) gleiche Platten oder SSDs.

Zu dem Umzug der Daten: du sicherst natürlich einen aktuellen Snap deines mypool und wenn du dann mehrere Pools benutzt, achte darauf, dass die auch eindeutige und unterschiedliche Namen haben. Wieso auch immer, irgendwie neigt man doch zu "tank" oder "raid" oder sowas. Wenn man dann gleiche Namen benutzt, kann der zpool import durchaus in die Hose gehen.
 
als einfach alle mit 4k zu alignen.
Nur so um mögliche Missverständnisse (auch für andere Leser) zu vermeiden:
Das Alignment (also die Ausrichtung an der Blockgrenze) ist ja nicht mein Problem, sondern die Blockgröße (block size).

Geschmackssache, aber ich schubber bei Umbauten aus Gewohnheit auf einen anderen Pool bestehend aus einer einzelnen Platte.
Könnte ich machen. Hab aber gerade kein (freien) Pool herumliegen. :-)

dass man bei steigender Plattenkapazität über den Einsatz von raidz2 nachdenken sollte
Ja. Wobei der Pool hier aus 3 Platten besteht. Damit dann ein RAID-Z2 konfigurieren zu wollen ist .... ambitioniert. :-)

Deshalb, aber nicht nur deshalb, verwende ich in einem Pool immer nur (wenn möglich) gleiche Platten oder SSDs.
Ja. Versuche ich auch. Kappt aber nur, wenn nicht historisch gewachsen. :-)
 
Zum Alignment sind auch die beiden alten Threads interessant, da es nicht nur um die Ausrichtung geht, sondern auch quasi die unterliegende Blockgröße egal werden lässt (bin mir nicht sicher, ob wir in diesem Punkt schon aneinander vorbeigeredet hatten ;) ):

aus 3 Platten besteht. Damit dann ein RAID-Z2 konfigurieren zu wollen
Ok, dachte nur, ich hätte Kaufambitionen herausgehört. :D
 
Ok, dachte nur, ich hätte Kaufambitionen herausgehört.
Ja. Das ist korrekt. Aber mehr in dem Sinne die alten Platten durch neue (Größere) zu ersetzen. Also wenn ich eh eine Platte wechseln muss weil sie Ausfallerscheinungen hat, dann hab ich mir gesagt: Hol ich mir gleich eine Größere.
Wenn ich jetzt noch die anderen Platten aus dem Pool durch Größere ersetze, kann ich den ganzen Pool via
zpool online -e softraid ada0p1 usw.

bin mir nicht sicher, ob wir in diesem Punkt schon aneinander vorbeigeredet hatten
Gut möglich. Oder auch nicht.
Ich weiß es gerade nicht. :-)
Jedenfalls war das Alignment korrekt aber die Blockgröße falsch (also der zpool hat 512 Bytes aka ashift=9 genutzt während die neue Platte 4096 Byte Sektoren hat und auch alle weiteren Platten werden dann logischweise 4k-Sektor-Platten sein). Daher die Idee dann nach dem Austausch aller Platten den Pool zu "konvertieren". bzw. sogar noch vor dem Neueinbau ein Pool-Dump zu machen und denn Pool gleich neu mit ashift=12 anzulegen.
 
Ok, wir haben da ein wenig aneinander vorbeigeredet. :D

Wie gesagt, du kannst 512b-Platten problemlos -a 4k verbraten und dann den pool mit -o ashift=12 erstellen. Es ist dann egal, ob die reale darunterliegende Platte wirklich 512er oder 4096er Sektoren hat. ZFS lüppt dann aber optimal und meckert nicht.

 
Es ist dann egal, ob die reale darunterliegende Platte wirklich 512er oder 4096er Sektoren hat.
Das war ja meine Befürchtung. Das das trotz Alignment ungünstig ist. Also nicht so richtig wirklich ungünstig mit derben Geschwindigkeitsverlusten. Und auch nicht wirklich problembehaftet. Aber eben nicht optimal.
Wegen eben dieser angesprochenen Geschichten wie was passiert, wenn ZFS einen 512-Byte Block schreiben muss aber die darunter liegende Platte eine 4k-Platte ist und deshalb immer 4k auf einmal schreiben kann. Wenn ZFS das bewusst ist, das es selbst nur 512 Byte Blockgröße hat aber das darunter liegende Device 4K-Blöcke verwendet, fasst es möglicherweise mehrere 512 Byte Blöcke bei einem Schreibvorgang zusammen. Aber das weiß ich halt nicht wie sich das alles im Detail verhält.

Daher war dann meine Folgerung: Schöner wars also wenn Pool-Blockgrößendefinition und tatsächliche Blockgröße der Devices identisch wären.
Auch wegen dem von Dir im Posting #5 angesprochenen Fakt: Größere Blöcke bedeutet das die Gesamtzahl an Blöcken kleiner ist was dann die Verwaltung auch vereinfacht.

notes on converting a FreeBSD 10 zpool from 512 to 4K
Ja. Die machen es ja auch so wie von mir angedacht. Ganzen Pool via zfs send wegsichern, neumachen, zurücksichern (zfs receive). Und ich hab nicht mal den Stolperstein mit dem "bootable".
 
Das das trotz Alignment ungünstig ist. Also nicht so richtig wirklich ungünstig mit derben Geschwindigkeitsverlusten. Und auch nicht wirklich problembehaftet. Aber eben nicht optimal.
Das ungünstigste Szenario hast du jetzt.

Schöner wars also wenn Pool-Blockgrößendefinition und tatsächliche Blockgröße der Devices identisch wären.
Genau richtig. Das ist der optimalste Optimalfall. :)

Daher mein Rat den Mischmasch komplett jetzt unabhängig der realen Sektorgröße der Platte auf 4k zu setzen, damit du ashift=12 setzen kannst. Diese Optimierung (die sollte man dann auch wirklich fühlen können) könntest du jetzt machen, wäre auch zukunftsträchtig (wenn 512B-Platte kaputt, problemlos 4kn-Platte rein, Pool ist ja schon auf ashift=12) oder eben auf dann schieben, wenn du dann alle 4kn-Platten gekauft hast.
Selbst wenn ich nur 512B-Platten habe, mache ich das so. Der Geschwindigkeitszuwachs ist es allemal wert und der Verschnitt bei der Speicherkapazität wird durch LZ4 wieder locker wettgemacht. Selbst wenn du darauf dann eine recordsize=1M fährst und eine Textdatei mit ein paar Buchstabend speicherst, wird kein ganzes Megabyte verballert.
Ich kann es jedenfalls nur empfehlen. ;)
 
Daher mein Rat den Mischmasch komplett jetzt unabhängig der realen Sektorgröße der Platte auf 4k zu setzen
Ja. Das hattest Du ja erwähnt das Du das machst und generell für eine gute Idee hältst aus (auch für mich) nachvollziehbaren Gründen. Ich werd mal schaun, das ich über kurz oder lang den Pool umstelle.
Jedenfalls danke ich Dir und den Anderen für eure Tipps & Tricks.
 
eigentlich,,, eigentlich wollte ich nichts mehr dazu sagen.
Aber so ist das ja mit "eigentlich".

Wenn das richtig verstehe, ist das ja ein alter Pool und es ist offenbar ein kleiner Pool:
und für jeden Pool sollte man ja eh immer ein Backup haben. Also für alle Daten immer, aber wenn wir von ZFS und Pools sprechen, wird das nochmal präzisiert.

In dem Fall, den ich für mich selbst oben mal angesprochen hatte, wollte ich das alte FreeBSD behalten, weil neues FreeBSD kein AFPD mehr kann und ich immer noch zwei oder drei alte Macs im Haus habe, die das gerne nutzen.
Neue Eigenschaften eines Pools konnte ich deshalb gar nicht nutzen, wie sie seither in FreeBSD auch eingeflossen sind.
Das ist in Ordnung so und das meint dann auch ashift=9.
Und auch kein gängiges Allignement-Szenario, weil eben gpt damals noch nicht so gut oder gar nicht brauchbar umgesetzt war.
Ich will den alten Pool nutzen, obwohl ich neuere Platten habe und verzichte ganz bewusst auf einige neue Eigenschaften, die besser für Performance und Handhabung wären.
Nur: der Pool war ca 3.6T groß und ist mit neuen Platten auf etwa 12T gewachsen und das war mir auch wichtiger, als Performance-Optimierung.
Die 3.6T Daten konnte ich relativ einfach speichern, also einen Backup lagern, den ich dann auch den neuen Pool wieder zurück spielen konnte. Den 1T Pool, den ich derzeit nutze, könnte ich nicht so einfach auf ein Medium kopieren. Deshalb habe ich da mehrere Datasets angelegt und behandele die getrennt, je nach Wichtigkeit.

Was soll all das dumme Gerede von meinem eigenen Pool?
Nunja, wenn ich deinen sehe und der nur ca 0.5T groß ist, dann hat man doch eine eine USB-Platte für 50€, auf die man alle Daten sichern kann, also, falls man nicht auf den ohnehin bereits vorhandenen Backup zugreifen kann/möchte?
Genau das, was @mr44er auch vorgeschlagen hat.
Und wenn du das eh neu machen möchtest, also auch alte HW ersetzen, dann ist das womöglich sogar noch einfacher, weil du deinen bisherigen Pool einfach über Netz in deine neue HW senden kannst und weil der neue Pool mit neuer HW und neuem System erstellt wird, hat er auch alle neuen Features, Kompression und so weiter und so fort.

Aber du siehst auch, dass viel Gestochere in meiner Antwort drin ist, weil nicht ganz klar ist, was du hast und was du möchtest.
Deine Frage ist einfach und klar.
Eine gute Antwort kann immer auch den Vorschlag zu einer neuen Alternative beinhalten. Doch dazu sollte man eben mehr wissen, als nur die technischen Details.
 
Aber so ist das ja mit "eigentlich".
:-)

Wenn das richtig verstehe, ist das ja ein alter Pool und es ist offenbar ein kleiner Pool
Klein ist relativ bzw. groß ist relativ. :-)
Aber ja. Es ist jetzt nicht der Mega-Pool.
Wobei der angegebene Wert jetzt weder mit der Größe noch mit dem belegten Speicher korrespondiert. Ich glaube, das ist einfach der Umfang der Daten der auf die neue Platte geschrieben werden musste. Dadurch, das die Daten auf alle Platten verteilt werden trägt ja jede Platte nur ein Teil der Nutzdaten.

Nunja, wenn ich deinen sehe und der nur ca 0.5T groß ist, dann hat man doch eine eine USB-Platte für 50€, auf die man alle Daten sichern kann, also, falls man nicht auf den ohnehin bereits vorhandenen Backup zugreifen kann/möchte?
Das sichern ist auch gar nicht das Problem.
Backup hab ich ja sowieso und auch noch den Platz den Pool als Ganzes nochmals zu serialisieren, um ihn dann ggf. bei eines Neuanlegen des Pools dann wiederherzustellen.

weil du deinen bisherigen Pool einfach über Netz in deine neue HW senden
Es gibt keine neue Hardware. Es gibt nur neue Platten (gut; ist auch Hardware; aber jetzt nicht neue Hardware im Sinne von neuen Rechner).

hat er auch alle neuen Features, Kompression und so weiter und so fort.
Die neuen Features hat auch der jetzige Pool schon (bzw. halt das was Stand Release 12.2 so hergibt; also noch kein OpenZFS oder so).
Auch das Alignment passt. Lediglich die Blockgröße weicht ab. Von daher ist es jetzt auch alles kein übergroßes Drama. Aber halt auch nicht wirklich schön.

Eine gute Antwort kann immer auch den Vorschlag zu einer neuen Alternative beinhalten. Doch dazu sollte man eben mehr wissen, als nur die technischen Details.
Die Alternative zu Save-Restore wie in Posting #6 beschrieben wäre ich interessiert. Ich fürchte nur, da gibts nicht soviel. :-)
 
du könntest eine Platte nach der anderen tauschen und jeweils resilvern und hoffen, dass nicht während dessen eine weitere Platte stirbt.
Ja. Das ist der Weg den ich jetzt gehe. Und das ist auch gar nicht das Problem.
Das Problem ist, das der Pool mit einer Blockgröße von 512-Byte angelegt ist. Die neuen Platen haben aber eine native Blockgröße von 4096 Byte.

Du kannst dem Pool jetzt auch nicht einfach sagen, das es ab sofort 512 Byte Blockgröße verwenden soll. Das ist ein Wert der sich nur beim anlegen des Pools definieren lässt. Zumindest ist mir kein Weg bekannt wie sich das im Nachhinein ändern lässt. Was ich ansich auch logisch finde. Denn ZFS organisiert damit seinen Speicherplatz auf recht fundamentaler Ebene. Das ist also nicht irgendwie wie ein Feature was man an und aus knipsen kann.
 
Zurück
Oben