TrueNAS mit IcyBox: Nur eine Festplatte in der GUI

berni51

Open-Net-FreeBSD user
Hallo,
ich hab hier mehrere IcyBoxen, alle für 2 HDs und auch so bestückt. Die Boxen hab ich via USB3.0 an einen Intel NUC mit 16 GB RAM angeschlossen und ein TrueNAS installiert. Ist ja eigentlich ein FreebSD :o.
Logge ich mich per ssh auf dem NUC ein, werden alle angeschlossenen HDs in den IcsBoxen erkannt. Ich kann die partionieren, löschen, geht alles.
In der Web-GUI allerdings bekomme ich aus jeder IcyBox nur eine Platte angezeigt, und zwar immer die zweite.
Sehe ich also am prompt die Platten da0, da1, da2, da3 und da4, so zeigt mit die GUI nur da0 (system-SD), da2 und da4 an.
Kann ich mir gerade überhaupt nicht erklären. Vielleicht gibt es ja hier den entscheidenden Hinweis.

Berni
 

mr44er

moderater Moderator
Teammitglied
Passender verschoben ;)

Zum Thema: Kann das sein, dass man Platten vorher einmal für die GUI 'mounten'/abnicken muss, so als Pseudosicherheitsextraschritt, bevor man wirklich was damit machen kann? Etwas doofe Frage, wenn du jeweils nur eine Platte siehst. :p
Was ist das für eine Icybox? Machen die Dinger in sich schon raid1 oder reichen die Platten 1:1 durch?

Trivia: TrueNAS wollte oder will immer noch(?) auf Debian umsatteln.
 

berni51

Open-Net-FreeBSD user
Danke fürs Verschieben.
Die Icybox, zumindest diese hier, macht mit den Platten gar nichts. Die reicht tatsächlich nur durch: 2 x mSata auf USB. Alle gerade erreichbaren OSse erkennen auch beide Platten (Open/Net/FreeBSD, Devuan, Slackware), nur TrueNAS nicht. Womöglich kommt TrueNAS mit dem (etwas älteren) JMicron-Controller nicht zurecht.
Habs gestern und heute versucht, bin aber gescheitert. Also TrueNAS aufgegeben und ein kleines FreeBSD auf eine SD-Card gezogen. Dann beide Icyboxen angehängt, jeweils einen Mirror-Pool erstellt, den NFS-Server gestartet und schon hab ich ein funktionfähiges NAS mit 4 TB und schön gespiegelt.
Jetzt noch den nginx webdav-fähig machen und der Punkt ist auch abgehakt.

Berni
 

mr44er

moderater Moderator
Teammitglied
Wenn du noch Kontingent an Bastellaune hast, gibts noch XigmaNAS (ex-nas4free).
In meiner zartpinkfluffigen Vorstellung hast du für die Systeminstallation noch einen freien USB-Port sowie Stick und kannst deinen pool direkt importieren. ;)
 

berni51

Open-Net-FreeBSD user
Ja, die fluffige Vorstellung trügt nicht, ist beides noch vorhanden. Ich schau jetzt mal nach XigmaNAS .....
 

turrican

Well-Known Member
@berni51 - Ich könnte mir vorstellen, dass der Teil welcher die Konfig in die GUI einliest, ganz lapidar bei der ersten gefundenen Platte aufhört.
An der Konsole per ssh fanden sich ja alle Platten wie du oben schriebst, also würde ich davon ausgehen, dass das OS die Platten an sich erkennt?

Du könntest mal das neue - bekanntlich auf Linux basierende - TrueNAS SCALE probieren, die letzte RC2 ist vom 22.12.21 und läuft bereits hinreichend gut. Außer du möchtest explizit ein BSD einsetzen, dann fällt diese Möglichkeit natürlich weg.
 

berni51

Open-Net-FreeBSD user
Ich hatte jetzt eher den Eindruck, dass die GUI sehr stark vom darunterliegenden OS abgekapselt ist, also quasi wie ein chroot. Hatte beispielsweise die 4 Platten aus 2 Icyboxen auf OS-Ebene zu zwei gespiegelten Pools verbunden - auch diese Pools hat die GUI nicht angezeigt. Und beim nächsten Booten waren die Pools überhaupt nicht mehr vorhanden.
Es gibt bei TrueNAS ja auch ein rudimentäres kommandozeilen-Menü. Aber auch dessen Einstellungen überdauern kein Reboot.
Da wird auch explizit drauf hingewiesen.
So richtig symphatisch ist mir dieses TrueNAS-Konzept eigentlich nicht.
Nachher schaue ich mir mal das XigmaNAS and und danach TrueNAS-SCALE. Obwohl ich tatsächlich lieber was auf BSD-Basis hätte.

Jetzt laufen aber erst einmal (seit gestern Abend) die Backups auf in die IcyBoxen - ganz trivial mit einem abgespeckten FreeBSD. Und einfach über NFS-mounts gepaxt.

Apropos: Kann es sein, dass das ZFS-Mirroring merkliche Kunstpausen beim Backup erzeugt? Die Datenblöcke kommen sehr schnell am Zielort an, aber dann gibt es Päuschen, in denen die beiden Mirror-Platten sich miteinander beschäftigen. Sehr schön zuu sehen an den Activity-LEDs in der IcyBox.
 
Zuletzt bearbeitet:

mr44er

moderater Moderator
Teammitglied
Kann es sein, dass das ZFS-Mirroring merkliche Kunstpausen beim Backup erzeugt? Die Datenblöcke kommen sehr schnell am Zielort an, aber dann gibt es Päuschen, in denen die beiden Mirrir-Platten sich miteinander beschäftigen.
Das passiert gerne bei winzigen Dateien oder wenn die Platten ihren Cache wegschreiben müssen, dürfte weniger an ZFS liegen. Mit genug RAM (16G sind genug) sollte das fliegen. Ohne Gebenche der Platten und genaue Inspektion der Flaschenhälse kann man da wenig sagen. Spezielle Firmware von NAS-Platten vollzieht auch gerne mal selber einfach Selbstchecks.
 

berni51

Open-Net-FreeBSD user
Ja, es passiert bei winzigen Dateien, aber auch bei besonders grossen. Die kommen wohl Blockweise rüber. Der Rechner steckt das alles ohne Mucken und mit wenig Last weg, der Speicher (16G) ist nicht mal zur Hälfte genutzt.
Das Netzwerk hat überall 1G-Adapter - da bleibt als Flaschenhals ja fast nur noch der Trichter der IcyBoxen mSata=>USB.
 

berni51

Open-Net-FreeBSD user
Ihr habt Recht, die Kunstpausen hatten nix mit zfs zu tun! Die sind nur aufgetreten, als einmal, quasi versehentlich, ein fat-Laufwerk im Spiel war. Auf ordentlichen Dateisystemen läuft das sehr schnell und glatt.
 

turrican

Well-Known Member
Es gibt bei TrueNAS ja auch ein rudimentäres kommandozeilen-Menü. Aber auch dessen Einstellungen überdauern kein Reboot.
Die Konfig ist bei TrueNAS in ner sqlite-db gespeichert, Änderungen von der Kommandozeile werden dahin nicht committed (ich wüsste auch von keinem "commit" Kommando für die CLI - nur das GUI triggert bei Änderungen die commits.
Änderungen an ZFS welche direkt vom CLI aus gemacht wurden werden jedoch direkt erkannt und überstehen auch einen Reboot, also gehe ich davon aus, dass der "ZFS-Status" von der Platte direkt zur Laufzeit eingelesen wird.

Die sqlite Datei liegt im Verzeichnis /data, es ist die "freenas-v1.db"; ganz Harte ändern ändern da angeblich direkt drin :D

Wenn man die auch dort liegende "factory-v1.db" in "freenas-v1.db" umbenennt, dann hat man nen Werksreset gemacht, ohne Neuinstallation.
So kann man z.B. auch per ssh die Konfig sichern - einfach die freenas-v1.db wegsichern.

So richtig symphatisch ist mir dieses TrueNAS-Konzept eigentlich nicht.
Siehe oben - TrueNAS folgt dem Appliance-Konzept, alle Einstellungen sind komfortabel in einer (Datenbank-)Datei, es muss nicht in irgendwelchen /etc bzw /usr/local/etc rumkonfiguriert werden.
Dies sehen manche als Vorteil, manche als Nachteil.
 

berni51

Open-Net-FreeBSD user
Siehe oben - TrueNAS folgt dem Appliance-Konzept, alle Einstellungen sind komfortabel in einer (Datenbank-)Datei, es muss nicht in irgendwelchen /etc bzw /usr/local/etc rumkonfiguriert werden.
Dies sehen manche als Vorteil, manche als Nachteil.
Da sagst Du was! Schätze, ich bin doch mehr Typ für conf-Dateien.

Ach ja: Mein zpool create ....., eingegeben aus der Shell der cli, hat den Bootvorgang nicht überdauert.
 

turrican

Well-Known Member
Ach ja: Mein zpool create ....., eingegeben aus der Shell der cli, hat den Bootvorgang nicht überdauert.
Ich war mir sicher, das das funktionierte - weil ich mich eben hernach wunderte, dass er das eben doch mitgenommen hatte; allerdings hatte ich keinen zpool erstellt, sondern neue Datasets in nem bestehenden Pool.
Es würde ja auch Sinn machen, da die zfs Konfig ja direkt auf Platte geschrieben wird - außer, die CLI finge das jetzt auch ab; aber es gibt wie gesagt m.W. eben kein "commit" Kommando für Änderungen aus der CLI.

EDIT:
Du kannst dir in der Config anschauen, was auf deiner Hardware erkannt wurde - is ja ein sqlite-db-File:

Code:
sqlite3 /data/freenas-v1.db "select * from storage_disk;"
 

pit234a

Well-Known Member
Jetzt laufen aber erst einmal (seit gestern Abend) die Backups auf in die IcyBoxen - ganz trivial mit einem abgespeckten FreeBSD.
aus dem Grund hatte ich vor gefühlten dutzend Jahren meinen NAS schließlich auch mit einem FreeBSD selbst gebaut und das bis heute nicht bereut.
Es hatte sich mir nicht wirklich erschlossen, welchen Vorteil ich davon habe, alles über eine merkwürdige GUI regeln zu können, was auch über ssh geht.

Ein weiterer (theoretischer) Grund war damals, dass ich damit flexibler bleibe.
Will ich SAMBA, installiere ich es, brauche ich das nicht, lasse ich es.
Brauche ich FTP, richte ich es ein, brauche ich einen Router, einen Proxie, eine Firewall, egal was, dann bitte.
Nehme ich ein whatever-NAS-BSD, bekomme ich genau das, was die Entwickler dort sich für mich ausgedacht hatten. Die hatten damals immer andere Gedanken, als ich selbst.
Für mich ist das WICHTIGE in einem NAS die RAID-Funktionallität, sprich eine Redundanz. Die hat ZFS bereits eingebaut.

Gerade habe ich wieder eine Platte in meinem NAS ausgetauscht und natürlich nicht gewusst, was ich machen muss.
Na gut, lese ich halt kurz die Doku und fünf Minuten später war alles klar.
Ich weiß nicht, ob ich das mit einer GUI überhaupt gefunden hätte, die ja jemand nach seiner eigenen Empfindlichkeit aufgesetzt hat und was es mir dann für einen Vorteil gebracht hätte.

Bitte nicht falsch verstehen: ich möchte gar nicht eine Grundsatzdiskussion ins OT führen, sondern nur die Vorlage nutzen und das bereits mehrfach vorgeführte Bastler-Herz von @berni51 ansprechen.
 

crotchmaster

happy BSD user
aus dem Grund hatte ich vor gefühlten dutzend Jahren meinen NAS schließlich auch mit einem FreeBSD selbst gebaut und das bis heute nicht bereut.
Es hatte sich mir nicht wirklich erschlossen, welchen Vorteil ich davon habe, alles über eine merkwürdige GUI regeln zu können, was auch über ssh geht.
Ich glaube, Du bist nicht die Zielgruppe von TrueNAS. Das sind eher Leute, die ein NAS brauchen oder wollen, aber keine Zeit, keine Lust oder nicht das Wissen haben, ein NAS im Eigenbau hochzuziehen. Und Du musst zugeben, für solche Leute ist eine GUI doch etwas zugänglicher als die Konsole.
 

berni51

Open-Net-FreeBSD user
Mein NAS für Arme ist jetzt fertig, und sieht wie folgt aus:
  • 3 IcyBoxen, jede mit 2 x 2TB als mirrors
  • Ein headless NUC mit 16GB RAM hat auf einer SD card mit 32 GB ein Mini-FreeBSD 13.0.
  • Mit nginx und proftp sind Zugriffe via nfs, ftp, webdav und https möglich.

Dann alle verstreuten Backups gesammelt und aufs NAS geschaufelt. Läuft gut und die User freuen sich.

Jetzt ist nach ein paar Tagen notwendig, eine der HDDs auszutauschen. Die ist nicht defekt, aber macht fiese Geräusche - obwohl alle Platten nagelneu sind.
Meine Frage:
Kann ich die entsprechende Icybox abschalten, die lärmende Platte durch eine neue ersetzen, wieder einschalten und mittels
"zpool replace poolname alte_hdd neue_hdd" wieder einen intakten mirror herstellen?
Nach meinem Verständnis müsste zfs nach meinem replace anfangen, zu resilvern, und nach einiger Zeit wieder online gehen?

Liege ich da richtig?
 

turrican

Well-Known Member
Wie ist die zpool Konfig - bilden alle 3 Icyboxen zusammen einen Pool - oder ist jede Icybox für sich je ein (mirror)Pool?
Wenn ersteres, dann schaltest du ja mit der Icybox einen Teil des (einzigen) Pools ab - das wäre dann eher nicht gut.

Das mit dem zpool replace Befehl ist prinzipiell ok, und ja, der Pool resilvert dann selbständig nach Absetzen des Befehls.
 

berni51

Open-Net-FreeBSD user
Ja klar, hätte ich erwähnen sollen: Jede Icybox ist ein eigener mirror-pool. Hab also neben dem zpool noch die pools nfs1, nfs2 und nfs3.
 
Oben