Skip to content

Home Server Teil 4: Storage Pool

17. Februar 2009
tags: ,

Da nun alles wie gewünscht läuft, habe ich nach dem ZFSQuickStartGuide und ZFSTuningGuide für FreeBSD ZFS startklar gemacht.

Dann den raidz Pool aus den drei 1TB Platten gemacht:

# zpool create tank raidz ad6 ad8 ad12

Jetzt werden die Daten auf zwei von den drei Platten abgelegt, und die Paritätsdaten für das RAID auf der dritten Platte. Somit bleiben von den insgesamt 2,72TB effektiv 1,8TB übrig.

Die Filesystems:

# zfs create tank/backup
# zfs create tank/backup/timecapsule
# zfs set reservation=500GB tank/backup/timecapsule
# zfs set atime=off tank

Durch die Reservierung von 500GB auf dem Dateisystem „timecapsule“ bleiben dem Elterndateisystem „tank“ noch 1,3TB zugesicherter Speicherplatz übrig. Dies bedeutet, dass im „df -h“ „tank“ mit 1,3TB verfügbarem Platz angezeigt wird, als auch für dessen Kinder, und für „timecapsule“ 1,8TB. Das Property „atime“ habe ich erstmal für den gesamten pool abgeschaltet, da es nach ZFS Admin Guide unnötige Schreibzyklen verhindert und somit zu, wenn auch minimalen, Performanceverbessungen kommen kann.

Ja wie man an der Länge dieses Beitrags sieht, ist der Administrationsaufwand für einen ZFS pool nicht sonderlich hoch.

Bei einem ersten schnellem Test, habe ich per scp Dateien auf den pool kopiert. Bei einem 1GBit Netzwerk hatte ich mit ca. 60MB/sec gerechnet. Raus kam aber 10-20 MB/sec. Die erste Ernüchterung. Über NFS ging es auch nicht sonderlich schneller (zwischen 10 und 30 MB/sec). Im Netzwerkbenchmark mit iperf kam ich auf 740Mbit/1000Mbit und einer theoretischen Übertragungsrate von 89MB/sec. Da ich hier im Netzwerk eigentlich nur Macs habe habe ich mich entschieden es dann noch mit AFP zu versuchen. Doch dazu mehr im nächsten Beitrag.

Den aktuellen Netzwerktraffic kann man sich unter FreeBSD übrigens mit

# systat -ifstat 1

anzeigen lassen.

Links:

Advertisements
4 Kommentare leave one →
  1. 17. Februar 2009 21:46

    Hi Sascha,

    tja – die Erkenntnis kam bei Dir früh. Früher als bei mir.

    Nachdem ich den Großteil des Samstages damit verbracht hatte einige Leitungen im Hausnetzwerk neu zu legen um die gewohnten 1GBit/s auch nach Umzug des Servers ins Rack des Kellers beizubehalten, führte ich heute einige Tests mit NFS durch. Da ich es nicht direkt auf die Reihe kam, die ZFS Partition anzusprechen, gab ich mein Home-Verzeichnis frei. Zu meiner großen Freude „donnerten“ die Daten mit ca. 80MByte/s durch die Leitung.

    Kurz darauf (und nach meinem Blogeintrag von heute morgen), hatte ich dann die Verzeichnisse soweit präpariert, dass ich auch auf die ZFS Platten zugreifen konnte.

    Knapp 30MByte/s mit NFS, 30-40MByte/s mit AFP und nur noch 30MByte/s mit Samba war eine klare Ansage. Ich habe das ganze dann mit einem Befehl auf dem FreeBSD Server getestet, der sehr zuverlässig die Übertragungsgeschwindigkeit der Festplatten anzeigt:

    date && dd if=/dev/zero of=deleteme.now count=1000000 && rm deleteme.now && date

    Dieser Befehlt, ausgeführt auf dem zu testenden Pool bzw. Festplatte brachte schockierende Ergebnisse, die ich mir im Zusammenhang mit dem oben genannten Zahlen nicht erklären kann:

    Normale UFS formatierte Systemplatte: 107MByte/s (nicht schlecht!), Samsung SATA-II 200GB 8MB Cache, 7200upm

    25MByte/s (sehr schlecht!), ZFS RAIDz1 SATA-II aus 3x 1TB WD Green Platten, 8MB Cache, ca. 7200upm

    Ich habe noch 2 Seagate Platten in dem Server, die ebenfalls im RAIDz1 laufen. Ergebnis: 19MByte/s.

    Heftig, beängstigend langsam und etwas ärgerlich, wenn ich den verbrachten Samstag in Erinnerung habe. Dennoch: ZFS und RAIDz1 hat natürlich einen immensen Aufwand für die Checksum&Hash Berechnung bei jedem Zugriff zu bewältigen, dafür ist das System „Rock-solid“.

    Sicher, auch wenn es etwas unbefriedigend ist: Es ist sicher. Sehr sicher.

    Alternativen? Nunja.. Ich seh da keine. Einen teuren RAID-Controller mit RAID5 für einige hundert Euro von 3ware, der dann FreeBSD unterstützt? Nunja, mir zu teuer und außerdem wäre das ein Rückschritt. Nein, ich seh das anders, wenn ich „schnell“ was sichern muss, z.B. wenn ich dringend weg muss (was selten der Fall ist, Home Office sei Dank), könnte ich in mein Home Verzeichnis sichern und später dann rüberkopieren. Was effektiv aber langsamer ist.

    Fazit: Damit leben, oder etwas unsicheres in Kauf nehmen. Dann brauch ich aber keinen Server – dann langt mir auch eine 100 Euro eSATA Platte, die ich dank Upgrade Kit in meinem Mac Pro wunderbar hieran betreiben könnte. Aber – das ist nicht Sinn der Sache 😉

    Ciao
    Dennis

  2. Sascha permalink
    17. Februar 2009 22:50

    Hallo Dennis,
    wow, Danke für Deinen ausführlichen Kommentar. Ich habe gerade mal meinen pool mit strapaziert und komme auf 35MB/sec Schreibrate. Wirklich nicht die Welt aber stimmt ja fast mit Deinen Werten überein.
    Aber Du hast schon Recht, lieber etwas langsamer aber dafür sicherer. Ich habe gerade AFP installiert und der Server kündigt sich jetzt selbst im Netzwerk über Bonjour an. Sehr schick. Ich schreibe gerade an dem Beitrag.

    Grüße,
    Sascha

  3. ralph permalink
    19. Februar 2009 16:52

    Hallo Dennis, wie ist denn der Durchsatz wenn du dd direkt auf dem Server ausführst ohne den Flaschenhals Netzwerk?

    ralph

  4. 21. Februar 2009 11:11

    Hi Ralph,

    die dd’s waren direkt per console auf dem Server ausgeführt. Ich denke nicht, dass ssh hier viel am Durchsatz beeinflussen kann.

    Ciao
    Dennis

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: