Schlechte ZFS-Performance, Inkonsistente Block-Größe?

J

jbredereck

Member
Hallo,

ich habe vor einigen Wochen ein FreeBSD 10.0 mit ZFS (RAIDZ1) aufgesetzt. Direkt nach der Installation ist mir schon aufgefellen, dass mir ein "zpool status" bei der 3. Festplatte (/dev/ada2) das folgende anzeigt:

ada2p3 ONLINE 0 0 0 block size: 512B configured, 4096B native

D.h. hier scheint die Blockgrösse nicht zu stimmen. Die Platte arbeitet wohl mit 4 KB grossen blöcken, während ZFS die Platte mit 512 Byte grossen blöcken anspricht?

Jedenfalls habe ich mich nichts weiter dabei gedacht. Allerdings ist heute die zweite Festplatte (/dev/ada1) ausgefallen. Ich habe diese Platte dann gegen eine neue getauscht, aber jetzt wird mir auch hier angezeigt:

ada1p3 ONLINE 0 0 0 block size: 512B configured, 4096B native

Die erste Platte ist hingegen anscheinend in Ordnung:

ada0p3 ONLINE 0 0 0

Die unterschiedlichen Blockgrössen scheinen sich allerdings auch negativ auf die Performance auszuwirken, denn das Resilvering kriecht gerademal mit etwas mehr als 3 Mbyte/S:

Code: 
root@backup2:~ # zpool status
  pool: tank
state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
    continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Mon Mar 31 13:03:35 2014
        73.2G scanned out of 2.37T at 3.26M/s, 205h12m to go
        23.9G resilvered, 3.02% done
config:

    NAME                      STATE    READ WRITE CKSUM
    tank                      DEGRADED    0    0    0
      raidz1-0                DEGRADED    0    0    0
        ada0p3                ONLINE      0    0    0
        replacing-1            REMOVED      0    0    0
          2754293658493175068  REMOVED      0    0    0  was /dev/ada1p3/old
          ada1p3              ONLINE      0    0    0  block size: 512B configured, 4096B native  (resilvering)
        ada2p3                ONLINE      0    0    0  block size: 512B configured, 4096B native

errors: No known data errors

root@backup2:~ # gpart show /dev/ada0

=>        34  2930277101  ada0  GPT  (1.4T)

          34         128     1  freebsd-boot  (64K)

        162    16777216     2  freebsd-swap  (8.0G)

    16777378  2913499757     3  freebsd-zfs  (1.4T)



root@backup2:~ # gpart show /dev/ada1

=>        34  2930277101  ada1  GPT  (1.4T)

          34         128     1  freebsd-boot  (64K)

        162           6        - free -  (3.0K)

        168     4194304     2  freebsd-swap  (2.0G)

    4194472  2926082656     3  freebsd-zfs  (1.4T)

  2930277128           7        - free -  (3.5K)



root@backup2:~ # gpart show /dev/ada2

=>        34  2930277101  ada2  GPT  (1.4T)

          34           6        - free -  (3.0K)

          40         128     1  freebsd-boot  (64K)

        168    16777216     2  freebsd-swap  (8.0G)

    16777384  2913499744     3  freebsd-zfs  (1.4T)

  2930277128           7        - free -  (3.5K)

Leider habe ich zu den unterschiedlichen Blockgrössen keine Lösungen bei Google finden können. Daher wende ich mich vertrauensvoll an euch: Was kann ich tun, um die Performance auf normales Niveau zu bringen? Wie kann ich die Blockgrössen richtig einstellen? Was ist zu tun? Bin für jeden Tipp dankbar!

Gruß,
Jörn
 
Hello Jörn,

das Problem ist bekannt und manche Festplatten "lügen" bezüglich ihrer Sektorgröße.
Wie Du richtig erkannt hast, liegt die eher mäßige Performance wohl an der falsch zugewiesenen Größe.
Ich würde jeder Festplatte 4K als Sektorgröße mit auf den Weg geben.
Um dies zu lösen kannst Du gnop verwenden [1] & [2].
Auch ich habe mal mit dem richtigen anlegen eines Pools gekämpft [3].
Dies sollte ein bisschen weiterhelfen.

[1] http://www.freebsd.org/cgi/man.cgi?...FreeBSD+10.0-RELEASE&arch=default&format=html
[2] http://wiki.bsdforen.de/zfs_ashift
[3] http://www.bsdforen.de/threads/zpool-zerstört-label.28907/

Beste Grüße,
laenger
 
Hallo laenger,

danke für den Tipp mit "gnop".

Das sollte mein Problem grundsätzlich lösen, wenn da nicht folgende Einschränkung wäre:

Vorsicht ist geboten, wenn man Pools mit ashift=12 als Rootdateisystem verwenden will. Der Bootloader gptzfsboot ist nicht in der Lage von Pools mit ashift!=9 zu lesen. Als Workaround bietet es sich an einen (kleinen) Pool extra für den Kernel zu erstellen.
Zum Vergrößern anklicken....

Weisst du, ob diese Einschränkung noch aktuell ist? Kommen neuere Bootloader evtl. auch schon mit ashift=12 zurecht? Leider liegt auf diesem Pool nämlich auch mein Kernel...
 
Ok, danke für die Info. Allerdings gibts wohl keine Möglichkeit den kompletten Pool umzustellen, ohne alle Daten aus dem Backup wieder einzuspielen.

Ich habe daher jetzt einfach mal das Resilvering gestoppt, die neue Platte mit gnop auf 512 Byte umgestellt und danach das nop-device in den Pool eingebunden. Und siehe da, das Resilvering "rennt" jetzt mit 40 MByte/S anstatt mit 3.2 MByte/S:

Code: 
root@backup2:/usr/local/etc/istgt # zpool status
  pool: tank
state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
    continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Mon Mar 31 21:01:32 2014
        80.5G scanned out of 2.38T at 40.5M/s, 16h32m to go
        26.8G resilvered, 3.31% done
config:

    NAME                      STATE    READ WRITE CKSUM
    tank                      DEGRADED    0    0    0
      raidz1-0                DEGRADED    0    0    0
        ada0p3                ONLINE      0    0    0
        replacing-1            REMOVED      0    0    0
          2754293658493175068  REMOVED      0    0    0  was /dev/ada1p3
          ada1.nopp3          ONLINE      0    0    0  (resilvering)
        ada2p3                ONLINE      0    0    0  block size: 512B configured, 4096B native

errors: No known data errors

Sobald die ada1 fertig ist mit dem Resilvering werde ich auch mal die ada2 auf 512Byte umstellen. Damit laufen dann zumindest mal alle Platte im Pool konsequent mit 512Byte-Sektoren.
 
Unabhängig vom ashift sei angemerkt, dass ein Resilver nicht linear abläuft. Wenn der Pool fragmentiert ist oder viele kleine Dateien hat, kann ein scrub/resilver von der Geschwindigkeit her stark schwanken.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben