[Sammelthread] ZFS Stammtisch

Ja ich weiß, Nostalgie pur. Das hilft mir trotzdem sehr, es ist ein exotischer Anwendungsfall, läuft seit 7 Jahren 24/7 und wird Ende des Jahres in Ruhestand geschickt. Vielen Dank!

- - - Updated - - -

gea schrieb:
OpenSolaris, das ist ja jetzt ca 10 Jahre her und Nostalgie pur....

Ich habe aber 0.813 nochmal hochgeladen.
Ist denn der Server bereits 64 bit? Dann ginge auch ein aktuelles Solaris/Illumos mit verbessertem ZFS.
Zum Vergrößern anklicken....

Noch eine Frage: Kann die aktuelle Omniosce stable die alte zfs pool version 19 importieren?
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Mahlzeit,

um nochmal die Performancefrage von Bccc1 aufzugreifen - ich hab gerade nen neuen Prozessor drin, daher läuft die Kiste eh und ich könnte ein Ründchen benchen. Da kommen aber schon mit bloßem dd komische Ergebnisse raus. Funkt da das verzögerte Schreiben alle fünf Sekunden dazwischen, oder überseh ich irgendeine Abhängigkeit von der Blocksize?

Ramdisk aufgemacht:
Code: 
ramdiskadm -a idisk 8G (max 1/4 vom RAM!)
newfs /dev/ramdisk/idisk

mkdir /export/home/bzzz/ramdisk
mount /dev/ramdisk/idisk /export/home/bzzz/ramdisk


mount sagt dann
Code: 
/export/home/bzzz/ramdisk on /dev/ramdisk/idiskx read/write/setuid/devices/rstchown/intr/largefiles/logging/xattr/onerror=panic/dev=35c0001 on So. Jul  8 15:52:49 2018

4GB als 512B*8192K
Code: 
ime dd if=/dev/zero of=./fuu bs=512 count=8192k
8388608+0 records in
8388608+0 records out

real    0m25.579s
user    0m2.014s
sys     0m23.563s

4GB als 1K*4096K
Code: 
time dd if=/dev/zero of=./fuu bs=1024 count=4096k
4194304+0 records in
4194304+0 records out

real    0m18.005s
user    0m1.072s
sys     0m16.933s

4GB als 8K*4096
Code: 
time dd if=/dev/zero of=./fuu bs=8192 count=512k
524288+0 records in
524288+0 records out

real    0m7.385s
user    0m0.168s
sys     0m7.217s

4GB als 32K*128K
Code: 
time dd if=/dev/zero of=./fuu bs=32768 count=128k
131072+0 records in
131072+0 records out

real    0m7.998s
user    0m0.059s
sys     0m7.937s

4GB als 1M*4096
Code: 
time dd if=/dev/zero of=./fuu bs=1024k count=4096
4096+0 records in
4096+0 records out

real    0m7.030s
user    0m0.004s
sys     0m7.025s

4GB als 8M*512
Code: 
time dd if=/dev/zero of=./fuu bs=8192k count=512
512+0 records in
512+0 records out

real    0m15.147s
user    0m0.003s
sys     0m15.141s

4GB als 32M*128
Code: 
time dd if=/dev/zero of=./fuu bs=32768k count=128
128+0 records in
128+0 records out

real    0m7.649s
user    0m0.002s
sys     0m7.639s

4GB als 1G*4
Code: 
time dd if=/dev/zero of=./fuu bs=1048576k count=4
4+0 records in
4+0 records out

real    0m8.807s
user    0m0.001s
sys     0m8.572s

8M*512 dauert bei wiederholten Läufen 6-8s, die 15s sind nicht reproduzierbar. Lösch ich die Datei und schreibe erneut, sind sie wieder da. Bei anderen Sizes nicht, da gehts eher in Richtung 5-6s?!

Generell find ich aber 8s für 4GB = 500MB/s auf ne Ramdisk unterirdisch. top bewegt sich währenddessen kaum von 90% idle weg, kernel steigt halt auf die 10% hoch. Das sieht mir nicht aus, als würde der jetzt schwitzen. Oder läuft das auf nem einzelnen Kern (=1/8 = 12,5% der logischen Prozessorkerne) und der könnte x von den Operationen parallel wegschreiben, aber ein Nutzer kann eben nur dieses Scheibchen Performance abrufen? Während dd läuft sagt
Code: 
psrinfo -v
Status of virtual processor 0 as of: 07/08/2018 16:30:52  on-line since 07/08/2018 15:37:13.  The i386 processor operates at 1600 MHz,        and has an i387 compatible floating point processor.
Status of virtual processor 1 as of: 07/08/2018 16:30:52  on-line since 07/08/2018 15:37:17.  The i386 processor operates at 1600 MHz,        and has an i387 compatible floating point processor.
Status of virtual processor 2 as of: 07/08/2018 16:30:52  on-line since 07/08/2018 15:37:17.  The i386 processor operates at 3468 MHz,        and has an i387 compatible floating point processor.
Status of virtual processor 3 as of: 07/08/2018 16:30:52  on-line since 07/08/2018 15:37:17.  The i386 processor operates at 3468 MHz,        and has an i387 compatible floating point processor.
Status of virtual processor 4 as of: 07/08/2018 16:30:52  on-line since 07/08/2018 15:37:17.  The i386 processor operates at 1600 MHz,        and has an i387 compatible floating point processor.
Status of virtual processor 5 as of: 07/08/2018 16:30:52  on-line since 07/08/2018 15:37:17.  The i386 processor operates at 1600 MHz,        and has an i387 compatible floating point processor.
Status of virtual processor 6 as of: 07/08/2018 16:30:52  on-line since 07/08/2018 15:37:17.  The i386 processor operates at 1600 MHz,        and has an i387 compatible floating point processor.
Status of virtual processor 7 as of: 07/08/2018 16:30:52  on-line since 07/08/2018 15:37:17.  The i386 processor operates at 1600 MHz,        and has an i387 compatible floating point processor.

d.h. Kern 1 mit den logischen Kernen 2 und 3 taktet auf Standardfrequenz hoch (Turbo wären 3,73 GHz) und der Rest dreht Däumchen.

Nun der Knaller: Platten eingehängt und das gleiche auf Disk probiert. Dazu muss ich sagen, dass hier erstens ein Z2 aus 8 Platten im Einsatz ist (nicht optimal), dazu 3 verschiedene Fabrikate verwendet werden (nicht optimal), außerdem sind die Teile verschlüsselt (erst recht nicht optimal).

mount:
Code: 
read/write/setuid/devices/rstchown/nbmand/exec/xattr/noatime/dev=4d50019 on So. Jul  8 16:38:38 2018

lz4=on (global):

Code: 
time dd if=/dev/zero of=./fuu bs=8192k count=512
512+0 records in
512+0 records out

real    0m1.267s
user    0m0.002s
sys     0m0.967s

lz4=off (local):
Code: 
time dd if=/dev/zero of=./fu bs=8192k count=512
512+0 records in
512+0 records out

real    0m0.910s
user    0m0.001s
sys     0m0.906s

Ich schreibe also auf ne physische Disk 6x schneller als in ne Ramdisk? :wall:
 
Habe zur Zeit folgendes "Problem".
Ich nutze ESXi Snapshots mit Napp-IT auf OmniOS und bin am Testen von verschiedenen Wiederherstellungs-Szenarien im Homelab.
Dabei stößt mir aktuell auf, dass ich mit dem Snapshot anscheinend nur alle VMs gleichzeitig zurücksetzen kann und nicht nur eine geziehlt oder übersehe ich hier etwas?
 
Ich möchte gerne regelmäßig Snapshots meines Datenpools auf eine angeschlossene USB-Platte schieben (zfs send/receive). Die Platte soll im Rahmen eines Backup-Scripts über eine per USB schaltbare Steckdosenleiste eingeschaltet und im Anschluss wieder ausgeschaltet werden. Bisher hat ein cronjob auf einem Raspi die Platte ein- und ausgeschaltet. Das würde ich jetzt gerne von meiner Storage-VM (Napp-it) erledigen lassen. Damit müsste nur die Storage VM laufen und die Abhängigkeit zum Raspi entfiele. Mein Problem: ich kriege sispmctl unter OmniOS nicht installiert, welches die Steckdosenleiste per USB schaltet. Hat das schon mal jemand von Euch gemacht? Ein Paket scheint es nicht zu geben und beim Kopilieren aus dem Sourcecode wird beim ./configure eine fehlende libusb angemeckert. Woher bekomme ich die? Gibt's dafür ein Package? Oder hat jemand einen anderen Tipp, wie ich sispmctl installiert bekomme? @gea? ;)
 
XBashX schrieb:
Habe zur Zeit folgendes "Problem".
Ich nutze ESXi Snapshots mit Napp-IT auf OmniOS und bin am Testen von verschiedenen Wiederherstellungs-Szenarien im Homelab.
Dabei stößt mir aktuell auf, dass ich mit dem Snapshot anscheinend nur alle VMs gleichzeitig zurücksetzen kann und nicht nur eine geziehlt oder übersehe ich hier etwas?
Zum Vergrößern anklicken....

ZFS ist eine Werkzeugkiste aus der man sich frei bedienen kann.

Wenn man unter ESXi ein iSCSI Target einbindet so ist ein Snap der Stand eines Blockdevices, also einer Platte. Man kann keine einzelne Dateien/ VMs wiederherstellen sondern nur alles per ZFS clone oder rollback.

Wenn man NFS3 nimmt, so kann man neben rollback und restore auch einzelne Dateien/VMs wiederherstellen. Entweder indem man die direkt aus dem Dateisystem/.zfs/snapshot Verzeichnis holt oder indem man das NFS share zusätzlich per SMB freigibt und mit Windows "vorherige Version" eine Datei oder einen VM Ordner wiederherstellt.
 
Danke @martingo, da habe ich tatsächlich noch einen Hinweis gefunden, den ich bislang übersehen hatte, nämlich auf das OpenIndiana Hipster Repository. Das habe ich nun mit 'pkg set-publisher -P -g package repository openindiana.org' hinzugefügt und wollte dann libsusb installieren. Natürlich mit Fehlermeldung... :(

Code: 
# pkg install libusb
Creating Plan (Solver setup): /
pkg install: No matching version of system/library/usb/libusb can be installed:
  Reject:  pkg://openindiana.org/system/library/usb/libusb@0.5.11-2018.0.0.0
  Reason:  No version matching 'require' dependency SUNWcs@0.5.11-2018.0.0.17036 can be installed
    ----------------------------------------
    Reject:  pkg://openindiana.org/SUNWcs@0.5.11-2018.0.0.17174
               to
             pkg://openindiana.org/SUNWcs@0.5.11-2018.0.0.17417
    Reason:  This version is excluded by installed incorporation consolidation/osnet/osnet-incorporation@0.5.11-0.151024
    Reason:  Currently installed package 'SUNWcs' is from sticky publisher 'omnios'.

Was will er mir damit sagen, außer der Tatsache, dass er das Paket nicht installieren kann? Ich brauche da noch etwas Schützenhilfe... Danke! :)
 
Zuletzt bearbeitet:
Lies mal nicht nur die Hälfte. Ab da geht es los:
Then by fluke, a random Google search turned me on to an SRV4 package named SUNWlibusb. This package happened to be on the Solaris Nevada ISO and had zero dependencies. Perfect.
....
 
Ich habe mal eine Frage zu den ACLs... Das scheint ja ein kompliziertes Eisen zu sein. Bin ja bereits Kunde, habe also alle Addons verfügbar, u.a. dann auch das ACL-Addon.

Ich würde gerne einen Windows-Filer auf OmniOSCE mit napp-it umziehen. Wie setze ich am besten die Permissions für die einzelnen Ordner? "ACL on folder" enthält meiner Meinung nach die ganzen Windows-ACLs und "ACL on SMB shares" enthält was? Momentan jedenfalls ein "everyone@ full_set"...

Ich habe aber aktuell das Phänomen, dass ich aus einem via SMB verfügbaren Ordner Dateien löschen kann, ohne Fehlermeldung, und nach ein paar Sekunden ist die Datei wieder da. Sie wird augenscheinlich entfernt, aber scheinbar auf Grund von Rechten dann doch nicht. Ich bekomme aber keine Fehlermeldung etc.

Wer sollte denn auf nem napp-it filer Besitzer aller Dateien und Ordner sein? root? Unter Windows ist es ja "SERVERNAME\Administratoren"... Ich glaube, ich habe das mit den ACLs verkorkst und brauche jetzt mal Hilfe, dass das wieder funktioniert...
 
Zuletzt bearbeitet:
Ein echter Windowsserver arbeitet so

- Auf Dateien und Ordner kann man die für ein ntfs Dateisystem verfügbaren Rechte setzen
Da kann man für beliebige Benutzer und Gruppen sehr fein abgestimmte Rechte setzen. Gruppen können Gruppen enthalten und man kann nicht nur Rechte setzen sondern auch deren Vererbung bestimmen (z.B. nur dieser Ordner oder auch enthaltene Ordner und Dateien). Die Rechte beziehen sich auf einen Windows Security Identifier sid bei dem auch der Server Bestandteil der Kennung ist.

- Neben diesen Dateirechten kennt Windows Rechte auf eine Freigabe. Das dient meist dazu die Dateirechte zusätzlich einzuschränken. Um einen Zugriff zu haben müssen Dateirechte und Sharerechte den Zugriff erlauben.

- Prinzipiell hat ein Administrator keinen Zugriff wenn er nicht explizit bei den Rechten gesetzt wird. Er kann sich aber immer dieses Zugriffsrecht setzen.

- Eigentümer ist zunächst immer der User der etwas anlegt, Admin kann das aber immer übernehmen

- Bei ACL Regeln wird zuerst Deny beachtet, dann Allow


Solaris ist ein Unixserver und ZFS ist ein Unix-Dateisystem bei dem Rechte primär über user-id und group-id (eine einfache Zahl) sowie über klassische Unix/Linux Rechte owner, group und everyone gesetzt werden. Gruppen können hier im Gegensatz zu Windows auch keine Gruppen enthalten und es gibt keine Rechte-Vererbung.

- Der SMB Server von Solaris durchbricht diese Unix Beschränkungen indem er zusätzlich SMB-Gruppen verarbeitet, NFS4 ACL nutzt (arbeiten zumindest für allow Regeln wie ntfs Regeln und können Vererbung) und die Windows Rechte auf Windows sid abbildet (als erweiterte ZFS Eigenschaft). Auch kennt Solaris neben den Dateirechten auch Share-Rechte.

- Auch bei Unix ist der Eigentümer zunächst der Erzeuger der Datei. Root hat hier aber im Gegensatz zu Windows immer Vollzugriff. Man muss das nicht expliziz setzen. Per ZFS Eigenschaft kann man das aber ändern (Eigenschaft aclinherit), genau so wie die Frage ob die Vererbung Windows alike sein soll (aclinherit=passthrough) oder viel restriktiver.

- Bei Allow/Deny Regeln wird die tatsächliche Reihenfolge beachtet (wie bei einer Firewall)


Fazit:
Sofern man von ausserhalb, z.B. einem Windows Arbeitsplatz Regeln setzt, verhält sich Solaris paraktisch wie Windows (sofern man Deny Regeln vermeidet). Ein weitere Unterschied ist eventuell das readonly Attribut. Momentan verhindert readonly auch das Löschen, zumindest bei OmniOS/OI, nicht aber bei Windows

Wenn man Rechte komplett verstellt hat, so am Besten per napp-it "ACL reset" alle Rechte rekursiv entweder auf everyone@=modify setzen und dann Unterbereiche einschränken oder auf root only und das Nötige erlauben (man kann auch per Windows dem Admin rekursiv ownership geben und dann als Admin alles resetten)
 
Zuletzt bearbeitet:
OK, das ist als "Neustart" gar keine schlechte Idee, danke. Führe ich den Reset unter "ACL on folder" oder unter "ACL on SMB shares" durch?

€dit: Ich glaub jetzt hab ich's langsam begriffen :) "ACL on SMB shares" ist, wer die Freigabe überhaupt sehen kann und "ACL on folder" sind die eigentlichen Benutzerrechte, so wie man sie von NTFS kennt.
 
Zuletzt bearbeitet:
Die beiden Funktionen "Rechte auf Dateien/Ordner" und "Rechte auf die Freigabe" an sich kommt beides von Windows, wobei man zum Share Rechte setzen unter Windows die Computer-Verwaltung bemühen muss.

Normalerweise setzt man Zugriffsrechte nur auf Dateien/ Ordner. Die Share Rechte beläßt man auf full so dass nur die Dateirechte relevant sind. Setzt man jetzt die Share Rechte auf jeder=lesen so verhindert man dadurch global dass irgendjemand schreiben kann ohne die einzelnen Dateirechte anzufassen.

Wenn man die Rechte von Dateien zurücksetzen will, so geht das nur mit reset recursive "ACL on files and folders" z.B. auf modify (erlaubt Ändern + Löschen).


Nochmal zur Frage warum Dateien nicht per SMB gelöscht werden können:
Das kann daran liegen dass der Solaris SMB Server so wie Windows ausschließlich ACL beachtet, auf ZFS aber auch traditionelle Unix Rechte gelten. Setzt man daher Rechte z.B. auf Console per chmod 755 so hat jeder prinzipiell Schreib-Rechte. Unter traditionellen Unix Rechten beinhaltet dies das Löschen der Datei. Bei den ACL gibt es aber die zwei Rechte Schreiben und Löschen. Ein Schreibrecht allein gibt noch keine Löscherlaubnis. Auch wird durch sowas wie chmod 755 die Vererbung von ACL deaktiviert.

Daher mit dem Solaris SMB Server niemals traditionelle Rechte setzen sondern immer ACL benutzen

Anderes Problem wäre das readonly Attribut von Windows. Das muss man vor dem Löschen zurücksetzen

Alternative:
Per SSH mit WinSCP als root anmelden und damit löschen. Der löscht als root einfach alles.
 
Gut, das habe ich grundsätzlich soweit verstanden. Was ich noch nicht ganz verstanden habe ist, welche UNIX-Rechte ich auf meine vorhandenen 750.000 Dateien setzen muss, damit das wieder funktioniert?

Tut es ein
Code: 
find /zfs_pool/Pfad/zu/den/Dateien -type f -exec chmod 0 {} \;
damit die Samba ACLs (inkl. Vererbung) wieder funktionieren?
 
- Solaris und OmniOS/OI nutzen per default nicht SAMBA sondern den Solaris eigenen SMB Server.
Nur der hat diese Features

- Ein chmod auf trditionelle UNIX Rechte löscht alle Vererbungen
(traditionelle Unixrechte kennen sowas nicht)

- Daher bei Solarish IMMER ACL setzen und niemals per chmod nnn
falls man per donsole ACL setzen möchte, dann per /usr/bin/chmod (kann ACL)
Setting and Displaying ACLs on ZFS Files in Compact Format - Oracle Solaris ZFS Administration Guide

Mit Napp-it: Im Menü ZFS Dateisysteme in der Zeile eines Dateisystem auf Folder-ACL klicken
Es werden die ACL angezeigt. Darunter gibt es die Option "reset ACL"

Darauf klicken und reset recursiv auf everyone@=modify setzen (oder root only)
Das setzt alle 750000 Dateien zurück.
 
Ich hab's nun hinbekommen, inkl. Vererbung :) Vielen Dank für die Hilfe. War für mich schwieriger als erwartet und gehört vielleicht irgendwo noch besser dokumentiert ;-) Also nochmals VIELEN DANK für deine Geduld.
 
martingo schrieb:
Lies mal nicht nur die Hälfte. Ab da geht es los:
Then by fluke, a random Google search turned me on to an SRV4 package named SUNWlibusb. This package happened to be on the Solaris Nevada ISO and had zero dependencies. Perfect.
....
Zum Vergrößern anklicken....

Danke, hatte ich sogar gesehen, war aber mit dem ISO nicht weiter gekommen...

gea schrieb:
Das OpenIndiana Repository ist für OpenIndiana gedacht und nicht für OmniOS.

Die Alternative: pkgin, siehe napp-it // webbased ZFS NAS/SAN appliance for OmniOS, OpenIndiana, Solaris and Linux : Downloads
Index of /packages/SmartOS/2018Q2/i386/All/
Zum Vergrößern anklicken....

Ich habe jetzt diesen Weg weiter verfolgt und pkgin installiert. Damit bekomme ich auch drei verschiedene libusb Pakete angezeigt, zwei davon habe ich installiert:

Code: 
libusb1-1.0.21 =     USB Access Library (version 1)
libusb-0.1.12nb5 =   USB access library (version 0)
*libusb-compat-0.1.6rc2  USB access library version 0 compatibility layer on top of version 1

Das dritte hat einen Konflikt mit dem zweiten Paket...

Was mich nun wundert: ./configure bemängelt immer noch dass kein passendes libusb da sei:

Code: 
configure: error: Package requirements (libusb >= 0.1.11) were not met:

No package 'libusb' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables LIBUSB_CFLAGS
and LIBUSB_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

Dabei habe ich ja nun über pkgin libusb-0.1.12 installiert, aber trotzdem werden die Libs nicht gefunden... Das sind die Momente, an denen man sich ein gut gepflegtes Debian Repository wünscht, weil man sich dort mit solchen Problemen selten herumschlagen muss. Wenn mir bitte nochmal jemand unter die Arme greifen würde... ;)
 
Nunja, OmniOS CE ist bewußter Minimalismus.

Die beiden Firmen aus der Schweiz und UK die im Wesentlichen hinter OmniOS CE stehen nutzen das kommerziell intern als Storageplattform und unterstützen nur das nötigste um damit einen FC/iSCSI, NFS und SMB Storageserver aufzubauen (inkl. kommerzieller Supportoption). In deren Repo ist noch nichtmal Apache oder Samba enthalten. Dafür beste Stabilität, stable und long term stable Distributionen.

Pgkgin von SmartOS (wie OmniOS basiert das auch auf Illumos) ist ein sehr gut gepflegtes Repository das nicht nur Illumos sondern auch BSD, OSX und Linux unterstützt. Teil dieser Plattformunabhängigkeit ist es, dass alles in /opt installiert wird und daher das jeweilige System weitgehend unverändert läßt. Das ist auch nötig, da SmartOS primär eine VM/ Cloudplatform ist bei dem man alles systemunabhängig in Zonen laufen lassen möchte. Wird alles via pkgin installiert klappt auch meist das Zusammenspiel.

Wird zusätzlich selbst was kompiliert und etwas nicht gefunden, so liegt das meist daran dass es in /opt liegt.


PS
Man könnte auch einfach einen Steckdosentimer für ein paar Euro einsetzen und für 15 Minuten Strom auf die USB Platte geben und in dieser Zeit eine Replikation laufen lassen. Die braucht meist eh nur wenige Sekunden für inkrementellen Lauf. Das tut sicher, macht keinen Ärger und man muss sich nicht darum kümmern ob irgendein Fremdtreiber die Stabilität beeinträchtigt.

Ich würde das aber eh so vermeiden da ein Disaster (Blitzschlag, Diebstahl etc) auch das Backuplaufwerk betrifft (verbunden via USB). Ein Backup muss extern und separat sein. Daher also nach dem Backup wechselweise Laufwerke abstecken und davor anstecken.
 
@gea

Habe gerade mal einen 'zpool scrub' angestoßen und danach mal 'zpool status' ausgeführt. Ich bekomme einen Hinweis, dass meine beiden Pools, sprich, der des Systems und mein Storage-Pool, nicht alle Funktionen aktiviert hätten. ich könne ein 'zpool upgrade' machen usw.

Habe vermutlich verpasst, was als Neuerung dazu gekommen ist. Sollte man das Upgrade immer machen oder lieber noch warten? Dass andere Systeme darauf u.U. nicht mehr zugreifen können, wenn sich die ZFS-Versionen unterscheiden ist mir bewusst, aber was für Auswirkungen/Verbesserungen hat das sonst?
 
Es dreht sich besonders um neue Features wie vdev remove und globale system-snaps die man dann aktiviert oder aktivieren kann. Ob man das sofort haben will oder erst abwartet ob man sich damit vielleicht ein Problem einfängt (ohne Möglichkeit auf älteres OS zurückzugehen) muss jeder selbst entscheiden.
 
Ob mit den neuen Betas auch neue Treiber dabei sind? Mein 9305-24i lief jedenfalls mit der ersten (und glaube auch mit der zweiten) Beta nicht. Der Broadcom-Support schweigt sich auch aus, obwohl Solaris (ohne SPARC-Zusatz) als unterstütztes OS in Specs und Web gelistet ist.

Nervig sowas.
 
Juhuuuu. Lange drauf gewartet, aber nun funktioniert offensichtlich auch SMB/CIFS wieder :bigok:

@besterino: kann ich das irgendwie auf dem laufenden System nachsehen, ob ein passender Treiber drauf ist oder hast Du nur Karte reingesteckt und geschaut ob was geht? :)
 
Letzteres... geschaut und (fast) nix geht. :d
 
Moin!
Mittlerweile ist (unglaublich schnell) ein Ubuntu Server 18.04 mit ZFSoL aufgesetzt und eingerichtet. Die zahlreichen TB sind vom Hardware-Raid DellT630/PercH730 umgezogen auf RaidZ1-vdevs mit darunterliegender dmcrypt-Verschlüsselung. Alles gut und läuft tadellos.
Allerdings gehen die Platten nicht schlafen...:(
Die hdparm-Befehle sind alle positiv quittiert worden (242 = 1h), jedoch tut sich nix, die Platten laufen durchgehend.
Gibt's einen Tipp? Hier im Forum hatte ich nur bezüglich FreeNAS etc gesehen, aber diese Tools gibt es unter Ubuntu halt nicht.
Gruß
 
Ich gehe mal davon aus, dass Deine Systempartition(en) nicht auf den Laufwerken liegt, die schlafen gehen sollen?
Zugriffe auf Pfade/Dateien kannst Du unter Linux wunderbar mit iwatch und inotify, ggf. incron überwachen. Genutzt habe ich bisher nur die ersten beiden und iwatch ist das gefälligste. Eigentlich klinken die sich an den Kernel und dürften selbst den sleep nicht verhindern. Aber selbst wenn, kannst Du damit zumindest identifizieren, welcher Prozess wann welche Datei anfasst.
 
Natürlich reine Daten-RaidZ: System auf SSD/Ext4, dann 4x8TB RaidZ1 + 4x6TB RaidZ1 + 2x8TB Mirror alle mit ZFS.
Mit google findet man den Hinweis, es läge an der Hintergrundverschlüsselung cryptsetup/LUKS, mit der hdparm nicht zurecht kommt (fiktiver "Dauerzugriff"). Leider kann ist erst nächste Woche wieder daran werkeln, ich melde dann die Lösung, vermutlich mit hd-idle.
 
Anmelden, um zu antworten.

Ähnliche Themen

G
Wieviel ZFS steckt in Qnap ZFS ??
Antworten
5
Aufrufe
880
gea
G
Shihatsu
ZFS Pool "verschicken"
Antworten
9
Aufrufe
592
sandreas
S
thor17
Ceph Node auf bestehenden ZFS Pools
Antworten
3
Aufrufe
533
gea
G
G
[Übersicht] napp-it cs, Web-GUI für fast jeden ZFS Server oder Servergruppen
4 5 6
Antworten
158
Aufrufe
9K
gea
G
AliManali
*erledigt* Perc H310 flashen
Antworten
2
Aufrufe
309
AliManali
AliManali
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