[Sammelthread] ZFS Stammtisch

Betriebssystemtechnisch wäre ich da glaube ich flexibel.
Unter Linux würde ich jetzt nämlich auch Staggered erwarten. Hat da wer Erfahrungswerte? Dann müsste ich in der Hinsicht zumindest mein aktuelles Datengrab nicht umstellen, falls ich da tatsächlich mal ein ZFS umsetze.
Wäre im Moment wohl schwierig aufgrund verschiedener Kapazitäten in meinem Datengrab (1x 6TB, 5x 4TB, 3x 3TB, 2x 2TB, 1x 1.5TB, dazu eine 6TB als Parität für snapraid und eine 500GB SSD als bcache), also ohne größere Investition erstmal nicht machbar. Aber man kann ja mal "rumspinnen" :d
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Sagt mal, wenn ich mir ein ZFS mit ein paar Platten aufbaue und die Platten gehen in den Spindown:
Was passiert bei einem Zugriff? Fahren die Platten sequentiell oder alle auf einmal hoch? Ich finde da irgendwie widersprüchliche Aussagen.
Ich betreibe seit einiger Zeit erfolgreich ein OmniOS mit spindown von 8xHDDs im RAIDZ2-Verbund. Diese fahren bei Zugriff definitiv staggered hoch! Kann man hören und weil es echt einige Zeit dauert, bis alle hochgedreht haben und dann auch Daten fließen, was aber in meinem Fall nur das aktuelle Kodi 19.x (bis Kodi 18 war das auch kein Problem) wegen timeouts übel nimmt und daher manchmal ein Medienfile (per NFS geshared) erneut gestartet werden muss. SMB hat hier noch nie Probleme (wegen timeouts) gemacht.
 
Ich habs gestern mal abseits ZFS getestet. Ich hab mal einen snapraid sync gestartet. Erst gingen zwei Platten nacheinander an und danach gingen 5 LEDs am Backplane auf einmal an, die nächsten wieder nacheinander. Da sind also 5 Platten auf einmal angesprungen. Also theoretisch ist Linux scheinbar in der Lage mehrere Platten auf einmal hochzufahren. Aber wovon das abhängt weiß der Geier.
 
ich seh das so.

Alle meine SuperMicro oder Chenbro "Produktivsysteme" mit OmniOS haben kein Problem wenn alle Platten nach dem Einschalten gleichzeitig hochfahren, nichtmal mit bis zu 50 Platten. Ich käme aber nie auf die Idee da Spindown zu aktivieren.

Bei Homesystemen sieht es anders aus. Nur da ist Spindown ein Thema und da sind die Netzteile oft zu schwach damit alle Platten gleichzeitig anlaufen können. Da kann man dann bis zu 20 Watt pro Platte rechnen statt 7W im Betrieb. Ansonst würde ich auch da bevorzugen wenn alle Platten sofort hochfahren damit das System schneller bereit ist.
 
Also in der Zeit, die meine Supermicro oder AsrockRack Mainboards brauchen, um ihre ganzen Checks (vor der eigentlichen Boot-Phase) zu fahren, ließen sich parallel locker zig Platten hintereinander andrehen…
 
ich seh das so.

Alle meine SuperMicro oder Chenbro "Produktivsysteme" mit OmniOS haben kein Problem wenn alle Platten nach dem Einschalten gleichzeitig hochfahren, nichtmal mit bis zu 50 Platten. Ich käme aber nie auf die Idee da Spindown zu aktivieren.
absolutely agreed!

Bei Homesystemen sieht es anders aus. Nur da ist Spindown ein Thema ...
Und genau in diesem use case spare ich mir mal schnell gute 50W an ~20h/d
 
Hallo,
habe ein Problem mit meinem TrueNAS 12.
Es ist eine SSD und eine HDD verbaut, 2 Pools. TrueNAS ist auf der SSD.
Nach einem Stromausfall fährt TrueNAS hoch, in der GUI ist der SSD Pool aber offline. HDD soweit ok.
zpool status zeigt mit den HDD Pool an und einen freenas-boot, aber keinen SSD Pool (der Pool heißt auch SSD und HDD).
Ne Idee was man anstellen kann? In der GUI den Pool zu löschen habe ich mich noch nicht getraut.
Backup der SSD ist vorhanden, aber neuinstallieren wollte ich wenn es geht vermeiden.
Soll ich dafür lieber einen eigenen Thread erstellen oder kann man das kurz hier behandeln?
 
Mir ist gerade in meiner napp-it Installation aufgefallen das SMB (was anderes nutz ich nicht für externe Zugriffe) nur im napp-it Subnetz funktioniert, genauso nur im eigenen Subnetz die Verwaltung mittels Windows Computerverwaltung. Das ist jetzt kein Beinbruch für mich, aber neugierig was das ist bin ich schon.
Das napp-it Webinterface funktioniert aus allen meinen Subnetzen, Firewall Modul nutze ich nicht.
Ich meine das ging schon mal, bin mir aber nicht 100%ig sicher.
Der Zugriff auf SMB ist mir ganz recht, die Administration wäre aber schön
 
Hallo,
habe ein Problem mit meinem TrueNAS 12.
Es ist eine SSD und eine HDD verbaut, 2 Pools. TrueNAS ist auf der SSD.
Nach einem Stromausfall fährt TrueNAS hoch, in der GUI ist der SSD Pool aber offline. HDD soweit ok.
zpool status zeigt mit den HDD Pool an und einen freenas-boot, aber keinen SSD Pool (der Pool heißt auch SSD und HDD).
Ne Idee was man anstellen kann? In der GUI den Pool zu löschen habe ich mich noch nicht getraut.
Backup der SSD ist vorhanden, aber neuinstallieren wollte ich wenn es geht vermeiden.
Soll ich dafür lieber einen eigenen Thread erstellen oder kann man das kurz hier behandeln?
Storage -> Disks -> Schauen, ob die SSD vorhanden sind. Wenn ja gut, wenn nein, schlecht. Dann prüfen, ob die SSD überhaupt noch lebendig sind.

Wenn ja Storage -> Pools -> Add -> Import an existing Pool -> durchklicken

Dann müsste er wieder da sein.
 
Ja SSD ist vorhanden, scheint auch zu leben da dort das boot drauf sein soll.

Aber dort war halt auch noch ein Pool der sich SSD nannte der nun fehlt:

1635670605710.png


Beim Import findet er irgendwie nichts:
1635670872251.png


Und den alten SSD Pool löschen habe ich mich bisher nicht getraut:
1635670715522.png
 

Anhänge

  • 1635671044468.png
    1635671044468.png
    4,7 KB · Aufrufe: 56
Hätte jemand Bauchschmerzen, den folgenden Pool so zu betreiben, und die darunterstehenden Daten darauf los zu lassen?

raidz2-0 ONLINE 0 0 0 wwn-0x5000c5008488bxxx ONLINE 0 0 0 wwn-0x5000c50084114xxx ONLINE 0 0 0 wwn-0x5000c50084890xxx ONLINE 0 0 0 wwn-0x5000c50084714xxx ONLINE 0 0 0 wwn-0x5000c50084794xxx ONLINE 0 0 0 wwn-0x5000c500a664dxxx ONLINE 0 0 0 wwn-0x5000c5008410fxxx ONLINE 0 0 0 wwn-0x5000c500846ebxxx ONLINE 0 0 0 wwn-0x5000c5009465bxxx ONLINE 0 0 0 wwn-0x5000c50086472xxx ONLINE 0 0 0 special mirror-1 ONLINE 0 0 0 wwn-0x5000cca09b03bxxx ONLINE 0 0 0 wwn-0x5000cca09b040xxx ONLINE 0 0 0 cache wwn-0x5000cca09b02dxxx ONLINE 0 0 0

special und cache sind 200GB HGST HBCAC2DH6SUN200G mit phys/log Sektorgröße 4K, der Rost ist Constellation ES3 (momentan noch zwei neuere wegen Falschlieferung dabei, replace ich später)

recordsize 128K für normale ZFS und 1M wo praktisch nur großes Zeug draufliegt, VMs ausgenommen. special_small_blocks poolweit 64K, was nach grober Abschätzung unten aber für keine nennenswerte Belegung sorgt, aber die Sache ungemein beschleunigen sollte. Aktueller Status beim Kopieren:

description used avail read write read write read write cksum raidz2 349G 26.9T 1.84K 0 235M 0 0 0 0 mirror (special) 1.27G 185G 4.36K 0 21.6M 0 0 0 0

find . -type f -print0 | xargs -0 ls -l | awk '{ n=int(log($5)/log(2)); if (n<10) { n=10; } size[n]++ } END { for (i in size) printf("%d %d\n", 2^i, size) }' | sort -n | awk 'function human(x) { x[1]/=1024; if (x[1]>=1024) { x[2]++; human(x) } } { a[1]=$1; a[2]=0; human(a); printf("%3d%s: %6d\n", a[1],substr("kMGTEPYZ",a[2]+1,1),$2) }'


size group​
#​
size [GB]​
1K​
78501​
0,08​
2K​
25087​
0,05​
4K​
32343​
0,13​
8K​
30658​
0,24​
16K​
31994​
0,50​
32K​
32544​
1,02​
64K​
26230​
1,64​
128K​
17977​
2,25​
256K​
17831​
4,46​
512K​
21794​
10,90​
1M​
19532​
19,5​
2M​
27461​
54,9​
4M​
12447​
49,8​
8M​
3043​
24,3​
16M​
1890​
30,2​
32M​
1091​
34,9​
64M​
515​
33,0​
128M​
1329​
170,1​
256M​
1769​
452,9​
512M​
1203​
615,9​
1G​
376​
376​
2G​
138​
276​
4G​
102​
408​
8G​
88​
704​
16G​
22​
352​
32G​
13​
416​
64G​
5​
320​
128G​
3​
384​
256G​
2​
512​
 
Ja SSD ist vorhanden, scheint auch zu leben da dort das boot drauf sein soll.

Aber dort war halt auch noch ein Pool der sich SSD nannte der nun fehlt:


Beim Import findet er irgendwie nichts:


Und den alten SSD Pool löschen habe ich mich bisher nicht getraut:
Du hast eine SSD, die sowohl als Bootpartition für TrueNAS dient, als auch als Datenpartition? Und auf dieser war auch dein SSD Pool? Nicht unbedingt empfehlenswert, wenn dem so ist.

Den alten Pool löschen würde ich nicht, aber was du machen kannst:
- Aufs Zahnrad klicken
- Export / Disconnect
- Haken NUR bei "Confirm Export / Disconnect" setzen
Bloß nicht bei "Destroy Data in this Pool".

Damit löscht du also erstmal keinerei Daten, sondern Unmountest nur den Pool. Anschließend nochmal wie oben beschrieben das Einbinden versuchen. Denn wenn noch der alte Verweise im System auf den SSD Pool existiert, zeigt er diesen natürlich nicht mehr als nochmal importierbar an.

Also erstmal Export / Disconnect.
Und dann nochmal wie oben beschrieben, Import existing.
 

Anhänge

  • Pool Export Disconnect.JPG
    Pool Export Disconnect.JPG
    37,7 KB · Aufrufe: 64
Delete Configuration of shares habe ich auch den Haken entfernt. Der Pool ist nun weg. Importieren lässt er sich aber weiterhin nicht.
Zeigt keinen verfügbaren Pool an zum auswählen.
Wenn ich eine neue SSD nehme und TrueNAS neu installiere, kann ich dann die HDD übernehmen und incl. Daten dort importieren?
 
Zuletzt bearbeitet:
Wie hast du es denn geschafft, das Bootmedium von TrueNAS aufzuteilen?
Bei meiner letzten Installation von TruNAS hat sich der Installer den ganzen Datenträger gegriffen, ohne eine Möglichkeit dort eine weitere (Daten-)Partition einzurichten - vollkommen egal wie groß der Datenträger ist (mit 120 GB und 500 GB HDD getestet).

Bei XigmaNAs kann man die Bootplatte/-SSD partitionieren, wobei die Data-Partition nur UFS als Dateisystem bekommt.
 
Keine Ahnung, ist schon länger her und habe ich nicht mehr im Kopf. War damals auch noch mit FreeNAS
 
Hab ein Problem mit meinem Napp-IT.

Hab auf meinem Share folgenden Ordner liegen: \\ip\ZFSfs\Backups\03_G710_G710\UserData

Darin befinden sich zwei Datei, die als Typ "Systemdateien" von Windows erkannt werden:
ЃϵϳЅЂϿϽϯІχϯπρϴϱЄϱЃϵϳЅ
ЃϵϳЅЂϿϽϯІχϯπρЂϻϵЉЃϵϳЅ

Ich bekomme diese kryptischen Files übers Netzlaufwerk mit root nicht gelöscht, editiert, verschoben. Es erscheint die Fehlermeldung "Element wurde nicht gefunden Das Element befindet sich nicht mehr in...".

Napp-IT-Reboot bringt nix, es spielt auch keine Rolle ob ich die Dateien mit Ubuntu, Win7 oder Win10 löschen will.

Hat jemand ne Idee?

Ich weiß leider nicht ob die Datei damals so aus der Quelle kam oder ob das ein ZFS-Fehler ist.

1635795735361.png


Edit:

Napp-IT 21.06a2
OmniOS v11 r151036m



Edit 2:

MC hat geholfen die Files zu löschen. Das hat mir der MC angezeigt:

1635797909875.png
 
Zuletzt bearbeitet:
Wie hast du es denn geschafft, das Bootmedium von TrueNAS aufzuteilen?
Habe mich hier geirrt, zu lange her das ganze :) Und auch noch Rechner am Remote Standort wo man nicht schauen konnte.
Sind 2 SSDs (eine Boot, eine Daten) und eine HDD drin. Die eine Samsung SSD hat er nicht mehr erkannt, nach Shutdown, SSD ab und wieder dran, wurde diese nun angezeigt unter Disks und ich konnte Sie unter Pool auch wieder importieren. Vielen Dank allen!
 
hiho@all,

ich habe momentan auf einem A2SDi-4C-HLN4F mit 2x SATADOM-ML 3ME4 und 6x WDC WD10JFCX-68N beim Menü Disk einen Eintrag
error:
S:0 H:732 T:0
temp: 52 Grad Celsius und smart_overview2: ok.

Der kleine Server macht mom einen Benchmark-Test für den HDD-Pool. Ist das nur eine Info oder ist es bedenklich?

btw ist der Bench fertig mit:
NAMESIZEBonnieDate(y.m.d)FileSeq-Wr-Chr%CPUSeq-Write%CPUSeq-Rewr%CPUSeq-Rd-Chr%CPUSeq-Read%CPURnd Seeks%CPUFilesSeq-CreateRnd-Create
pool5.45Tstart2021.11.0264G193 MB/s91293 MB/s7596 MB/s40141 MB/s83159 MB/s31480.6/s31620564/s20540/s

Ziel ist einen Fileserver für ca 3 Windows-Client zu haben.

Es handelt sich hier um eine frische Erstinstallation mit OmniOS/nappit (aktuell) pur.
 
Zuletzt bearbeitet:
Upgradepfad für 151036 ist

1) 151036 -> 151038
2) 151038 -> 151040

BEACHTE: Zuerst müssen die "Repositories" mitgegeben werden. Details zum Prozess findest Du hier
 
Ich schätze mal, dass ich mit ner Standard-OmniOS-Install wie sie für Napp-IT üblich ist keine ipkg-Zonen habe und mir den Schitt mit zoneadm sparen kann? Zumindest schein ich nur global zu haben nachdem ich zoneadm list aufgerufen habe.

Vorgehen:

# beadm create r151038

# pkg set-publisher -r -O https://pkg.omnios.org/r151038/core omnios
# pkg set-publisher -r -O https://pkg.omnios.org/r151038/extra extra.omnios

# zfs snapshot -r rpool@r151036

# pkg update -f -r --be-name=r151038

# init 6

Das gleiche nochmal für r151040.

Edit: Scheint geklappt zu haben.

1635881444837.png
 
Zuletzt bearbeitet:
Ich schätze mal, dass ich mit ner Standard-OmniOS-Install wie sie für Napp-IT üblich ist keine ipkg-Zonen habe und mir den Schitt mit zoneadm sparen kann?
Korrekt.
# beadm create r151038
Jein - Du kreierst damit ein _backup_ Bootenvironment. Das läuft also noch unter r151036. Daher besser sowas wie:

# beadm create r151036-final

# zfs snapshot -r rpool@r151036
Das brauchst Du grds. nicht; dafür gibt es ja das backup bootenvironment. In der Anleitung bezieht sich der snapshot auf die "zone-root", nicht auf Deine global root (rpool).
 
Alles klar, danke. Dann spar ich mir das bei zukünftigen Versionen :-)
Beitrag automatisch zusammengeführt:

Merkwürdig an meiner Installation ist noch folgendes:

1635881727328.png


Den ersten ping auf heise.de hab ich abgebrochen weil ewig nix kam.
Der ersten ping auf quad8 hat nicht geklappt, der zweite ging dann.
Der zweite ping auf heise.de hat dann etwas delay gehabt, der dritte kam dann sofort zurück.

Woran liegt das? Ich hab zwei Netzwerkinterfaces. Eines hängt in meinem Management-Netz, das andere im Storage-Netz (um Routing von Speichertraffic für gewisse Hosts zu verhindern).

Kann das sein, dass omnios zuerst übers Storage-Interface versucht raus zu kommen (die FW blockt dort alles)?

Wenn ich ein Update übers Webinterface von Napp-IT antrigger dauert es zuweilen auch ewig bis der Updatecheck durch ist.
 
Zuletzt bearbeitet:
Midnight Commander
ist oft ein Segen, genau wie Putty oder WinSCP

iostat (zählt Probleme seit Bootup)
Soft error : A disk sector fails the CRC check and needs to be re-read
Hard error : Re-read fails several times for CRC check
Transport error : Errors reported by I/O bus
Total errors : Soft error + Hard error + Transport errors

Harderrors sind also immer problematisch, zumindest für die Performance, meist Hinweise auf sonstige Probleme. HD Temp <60° ist unkritisch.

Update 1
Das Besondere an OmniOS ist dass jede Version ein eigenes Repository hat. Ein pkg update gibt also nur den neuesten Stand der installierten Version. Für ein Update auf eine neuere Version muss man vorher auf ein neueres Repository wechseln. (Einer der Gründe für die Stabilität von OmniOS auch im Vergleich z.B. zu Solaris oder OpenIndiana). Man bekommt nicht "aus Versehen" völlig neue Features sondern nur Bug/Security Fixes.

Updates gehen zudem immer über die letzte long term stable (36 stable -> 38 long term stable -> 40 stable).

Update 2
Bei einem napp-it oder OmniOS Update wird automatisch ein Backup Bootenvironment angelegt. Muss man nicht selber machen.
Napp-it nutzt nur die Global Zone und umgeht damit die Probleme und Einschränkungen von Storagediensten in Zonen.

Bei mehreren Netzwerkkarten:
- alle auf static konfigurieren
- jedes in einem anderen Netzsegment (also nicht 192.168.1.1 und 192.168.1.2 mit einer Netmask wie 255.255.255.0 die beide abdeckt)
- nur ein Gateway (es sei denn man hat tatsächlich mehrere)
 
Zuletzt bearbeitet:

OmniOSce v11 r151040​

wurde released

Nach einer Neuinstllation von 151040, braucht napp-it die folgenden Links (oder den wget installer nochmal laufen lassen)

ln -s /lib/libssl.so /usr/lib/libssl.so.1.0.0
ln -s /lib/libcrypto.so /usr/lib/libcrypto.so.1.0.0
 
Zuletzt bearbeitet:
Nach einem Update auf 151040, braucht napp-it die folgenden Links (oder den wget installer nochmal laufen lassen)

ln -s /lib/libssl.so /usr/lib/libssl.so.1.0.0
ln -s /lib/libcrypto.so /usr/lib/libcrypto.so.1.0.0
Nach Update von 151038 auf 151040 waren die Links bei mir schon vorhanden...

EDIT: Allerdings sehe ich gerade auf libxx.so.1.1... verlinkt
 
Zuletzt bearbeitet:
Seit dem Update auf 151040 kann ich mich nicht mehr von omnios über ssh auf bestimmte Hosts ohne Passwort (exportierte id_rsa.pub) verbinden...

UPDATE:

ssh -v liefert Infos:

debug1: send_pubkey_test: no mutual signature algorithm

RSA wurde wohl wegen diverser Verwundbarkeiten deaktiviert und ist standardmässig nicht mehr benutzbar.
Da meine Zielhosts keine modernen Algorithmen wie z. B. ed25519 beherrschen, bleibt wohl nur das bisher genutzte RSA wieder zu aktivieren:

/etc/ssh_config:

PubkeyAcceptedKeyTypes +ssh-rsa
 
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh