[Sammelthread] ZFS Stammtisch

Hallo,

nach dem Einbau von 2 weiteren Mirror vdevs (aus Seagate Exos X16 16TB HDDs) bekomme ich während des Scrubs nach ~ 3,3 gescannten TB einen reproduzierbaren Kernel Panic unter FreeNAS 11.3-U5.

Code: 
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address    = 0x4b0
fault code        = supervisor write data, page not present
instruction pointer    = 0x20:0xffffffff80412116
stack pointer            = 0x28:0xfffffe2faebdd5f0
frame pointer            = 0x28:0xfffffe2faebdd670
code segment        = base 0x0, limit 0xfffff, type 0x1b
            = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags    = interrupt enabled, resume, IOPL = 0
current process        = 15 (txg_thread_enter)
trap number        = 12
panic: page fault
cpuid = 1
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe2faebdd2a0
vpanic() at vpanic+0x17e/frame 0xfffffe2faebdd300
panic() at panic+0x43/frame 0xfffffe2faebdd360
trap_fatal() at trap_fatal+0x369/frame 0xfffffe2faebdd3b0
trap_pfault() at trap_pfault+0x49/frame 0xfffffe2faebdd410
trap() at trap+0x29d/frame 0xfffffe2faebdd520
calltrap() at calltrap+0x8/frame 0xfffffe2faebdd520
--- trap 0xc, rip = 0xffffffff80412116, rsp = 0xfffffe2faebdd5f0, rbp = 0xfffffe2faebdd670 ---
dsl_scan_scrub_cb() at dsl_scan_scrub_cb+0x316/frame 0xfffffe2faebdd670
dsl_scan_visitbp() at dsl_scan_visitbp+0x329/frame 0xfffffe2faebdd720
dsl_scan_visitbp() at dsl_scan_visitbp+0x5a1/frame 0xfffffe2faebdd7d0
dsl_scan_visitbp() at dsl_scan_visitbp+0x291/frame 0xfffffe2faebdd880
dsl_scan_visitbp() at dsl_scan_visitbp+0x291/frame 0xfffffe2faebdd930
dsl_scan_visitbp() at dsl_scan_visitbp+0x291/frame 0xfffffe2faebdd9e0
dsl_scan_visitbp() at dsl_scan_visitbp+0x291/frame 0xfffffe2faebdda90
dsl_scan_visitbp() at dsl_scan_visitbp+0x291/frame 0xfffffe2faebddb40
dsl_scan_visitbp() at dsl_scan_visitbp+0x3ed/frame 0xfffffe2faebddbf0
dsl_scan_visit_rootbp() at dsl_scan_visit_rootbp+0x134/frame 0xfffffe2faebddc40
dsl_scan_visitds() at dsl_scan_visitds+0xfe/frame 0xfffffe2faebdddf0
dsl_scan_sync() at dsl_scan_sync+0xfcb/frame 0xfffffe2faebddff0
spa_sync() at spa_sync+0xb67/frame 0xfffffe2faebde220
txg_sync_thread() at txg_sync_thread+0x238/frame 0xfffffe2faebde2f0
fork_exit() at fork_exit+0x83/frame 0xfffffe2faebde330
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe2faebde330
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic

Hat jemand eine Idee bzw. kann aus dem Dump rauslesen, woran das liegen könnte? Ich habe die neuen Platten zuvor in einem anderen Filer mit badblocks getestet, lief einwandfrei. /var/log/messages gibt keine Infos her. Specs zum Server:

SM X11SPM-TPF
Xeon Silber 4110
Broadcom 9400-16i HBA
SuperChassis 836BA-R920LPB
192GB RAM
Optane SSD DC P4800X 375GB PCIe
8x Seagate Exos X16 16TB (4 mirror vdevs)


Zpool:

Code: 
pool: Spinning
state: ONLINE
  scan: scrub in progress since Tue Oct 27 21:37:29 2020
        3.29T scanned at 2.81G/s, 2.37M issued at 4.90K/s, 12.7T total
        0 repaired, 0.00% done, no estimated completion time
config:

        NAME                                                STATE     READ WRITE CKSUM
        Spinning                                            ONLINE       0     0     0
          mirror-0                                          ONLINE       0     0     0
            gptid/f2401efa-839e-11ea-b711-ac1f6bbcc2e8.eli  ONLINE       0     0     0
            gptid/142f1a04-83dd-11ea-b711-ac1f6bbcc2e8.eli  ONLINE       0     0     0
          mirror-1                                          ONLINE       0     0     0
            gptid/6629e212-8461-11ea-b711-ac1f6bbcc2e8.eli  ONLINE       0     0     0
            gptid/fee155dc-849a-11ea-b711-ac1f6bbcc2e8.eli  ONLINE       0     0     0
          mirror-3                                          ONLINE       0     0     0
            gptid/2af5eb56-150d-11eb-b48b-ac1f6bbcc2e8.eli  ONLINE       0     0     0
            gptid/2c62ca51-150d-11eb-b48b-ac1f6bbcc2e8.eli  ONLINE       0     0     0
          mirror-4                                          ONLINE       0     0     0
            gptid/2a4fe28c-150d-11eb-b48b-ac1f6bbcc2e8.eli  ONLINE       0     0     0
            gptid/2b8f21ea-150d-11eb-b48b-ac1f6bbcc2e8.eli  ONLINE       0     0     0
        logs
          gptid/de03a5ad-a9b5-11ea-8d05-ac1f6bbcc2e8.eli    ONLINE       0     0     0

Was ich schon probiert habe:

- Freenas Update von 11.3-U4.1 auf U5
- Update der HBA Firmware auf die letzte Version - da lief noch eine ur-alt-Version (v4 -> v16); HBA BIOS hab ich so gelassen.

Was ich als nächstes probieren würde:

- Festplatten Slots der 4 neuen HDDs tauschen.
-- Wenn das nicht hilft, würde ich die beiden neuen mirror vdevs mittels "zpool remove Spinning mirror-X" auflösen. (nach meinem Verständnis sollte dies möglich sein, ohne den Pool zu verlieren; wäre kein Drama, Backup ist vorhanden ... dennoch)

Wäre toll, wenn jemand einen Input hätte. Besten Dank!
alex.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
@Digi-Quick

ja. M393A4K40CB2-CTD
Ich werde mal memtest laufen lassen.

oups:

1604087673952.png
 
Zuletzt bearbeitet:
Bei "Chipset" und "Memory Type" steht "Unknown". Teste mal, ob der Fehler "mitwandert" oder ob immer dieselben Bereiche betroffen sind. Falls ja, macht Memtest den Fehler. Unabhängig davon würde ich Memtest nur bedingt trauen, weil die Testmuster seltenst der Realität entsprechen. Nimm halt auch noch etwas, womit HW-Bastler ihre Systeme unter anderem auf Stabilität testen. Was den GPU-Testern ihr FurMark, ist den CPU-Testern ihr Prime95 und wenn du beides in einem haben willst, könnte "CPU-ID PowerMax" dir weiterhelfen. Das ist nur eine kleine Auswahl, weil den einen Test gibt es nicht. Da zumindest einige Treiber direkt auf FurMark & Co anspringen, hilft meist ein einfaches Umbenennen der Dateien weiter.
 
Ich wurstel mich gerade mal wieder in napp-it rein. Testweise erstmal mit 2x 3TB im Mirror.
Das Volume habe ich per NFS an esxi bereitgestellt.
Controller ist ein 2308 LSI in einer Z840 Workstation von HP. Der Controller ist onboard. Interessanterweise reicht er alle Platten einzeln an, wenn keine RAID Config gemacht wurde.
Die VMs im esxi liegen auf einer nvme 500GB Samsung 980 pro. Ich denke da lasse ich die auch.
Auf das ZFS würden die Plex Medien und Backup der Clients und sonstige Ablage (Images, ISOs, gesammelte Programme und so'n Zeug) kommen.
Was würde in so einem Fall ein l2arc Cache mit 2 1TB SSDs bringen (Samsung 860 evo)?
 
Zuletzt bearbeitet:
gea schrieb:
Das Durchreichen von NVMe kann gerne mal Probleme machen. Die kleinen Optane (bringen auch wenig Performance) gehen meist nicht, eine Optane 900 meist sehr gut. Aufgrund der brachialen Performance der besseren Optane ist aber neben Durchreichen auch die Nutzung als Datastore und das Bereitstellen von Partitionen per vdisk eine gängige Option.

Ich würde für die VMs eine gute NVMe nehmen, dabei auf powerloss protection wertlegen und die max Schreibmenge im Auge behalten. Die Datacenter Samsung haben zwar nicht die Klasse einer Optane, sind aber sicher eine gute Wahl - dann ohne Slog, einfach sync aktivieren. Die Samsung PM sind aber eher Leseorientiert, mit 50k Write iops sind sie eher auf dem Niveau besserer Sata SSDs. (zum Vergleich eine Optane 900 hat 500k write iops)
Zum Vergrößern anklicken....

Also, wie äussern sich denn die Probleme beim durchreichen? Geht nicht wegen fehlender Lanes, oder kann später noch Probleme machen, obwohl durchreichen erfolgreich war? Wenn Du Ersteres meinst, würde ich das erst mit einer Consumer SSD vom Kumpel testen. Geht das, würde ich dann zur Samsung greifen.

Was meinst Du mit vDisk? Normal als VMFS napp-it anhängen? In dem Fall könnte/sollte ich die ja nicht als ZFS/NFS Storage für napp-it nutzen?
 
Zuletzt bearbeitet:
fard dwalling schrieb:
Controller ist ein 2308 LSI in einer Z840 Workstation von HP. Der Controller ist onboard. Interessanterweise reicht er alle Platten einzeln an, wenn keine RAID Config gemacht wurde.
Zum Vergrößern anklicken....

SAS Controller reichen einzelne Platten problemlos als raw disks an VMs weiter. Das ist interessant wenn man Platten des HBAs an verschiedene VMs durchreichen will. Ansonst ist HBA pass-through einfacher weil man nur ein Teil durchreichen muss.

fard dwalling schrieb:
Die VMs im esxi liegen auf einer nvme 500GB Samsung 980 pro. Ich denke da lasse ich die auch.

Auf das ZFS würden die Plex Medien und Backup der Clients und sonstige Ablage (Images, ISOs, gesammelte Programme und so'n Zeug) kommen.
Was würde in so einem Fall ein l2arc Cache mit 2 1TB SSDs bringen (Samsung 860 evo)?
Zum Vergrößern anklicken....

Hängt vom RAM ab. Mit ausreichend RAM bringt ein L2Arc sehr wenig, allenfalls etwas wenn man read ahead aktiviert. Der Arc und L2Arc cacht ansonst nur random io nach einem read last/read most Schema. Komplette Files werden nie gecacht (da wäre der Cache auch sofort voll und unwirksam).

Da L2Arc auch RAM zur Verwaltung braucht, sollte er nicht größer sein als ca 5x RAM. Obergrenze sollte ca 10x RAM sein. 1 TB L2Arc ist nutzlose Verschwendung. Eher die evo als Pool nutzen, allenfalls wäre ein special vdev Mirror eine Option um darauf Metadaten und performancesensitive Dateisysteme abzulegen.
Beitrag automatisch zusammengeführt:

AliManali schrieb:
Also, wie äussern sich denn die Probleme beim durchreichen? Geht nicht wegen fehlender Lanes, oder kann später noch Probleme machen, obwohl durchreichen erfolgreich war? Wenn Du Ersteres meinst, würde ich das erst mit einer Consumer SSD vom Kumpel testen. Geht das, würde ich dann zur Samsung greifen.

Was meinst Du mit vDisk? Normal als VMFS napp-it anhängen? In dem Fall könnte/sollte ich die ja nicht als ZFS/NFS Storage für napp-it nutzen?
Zum Vergrößern anklicken....

Probleme sind meist: geht einfach nicht, System hängt oder es gibt massiv iostat Fehler.

Vdisk ist ein ESXi Datastore auf dem man virtuelle Platten anlegt (vdisk) und die an einer VM zuweist.
Ist vor allem interessant wenn man z.B. eine schnelle Optane für verschiedene Zwecke als Ergänzung eines oder mehrerer großen Plattenpools nutzen möchte. Ein großer Storage Pools aus virtuelle Platten ist ungünstig ("Storage virtualisiert man nicht")
 
Zuletzt bearbeitet:
@gea Danke für deine ausführliche Antwort.
Hatte jetzt testweise Mal eine als Log und eine als Arc lesecache. Hat aber an sich nix an der Performance geändert. Werde dann wohl tatsächlich einfach einen 1TB SSD Mirror machen.
Mit dem durchreichen am HBA meinte ich eher, das wenn kein RAID konfiguriert ist, jede Platte einzeln sichtbar ist, also als JBOD. War mir so nicht bewusst, ich dachte man müsse den zwangsläufig in IT Mode umschalten oder jede Disk als RAID 0 anlegen wenn das umflashen nicht geht.
Ich habe schon den ganzen Controller per Pass-Throught an napp-it durchgereicht.
 
@Stangensellerie & @Digi-Quick

danke euch für den Input. Nachdem ich aktuell nur Remote auf die Kiste draufkomm & die .img von Memtest86 sich afaik nicht per IPMI mounten lässt, lass gerade ich gerade stressapptest unter der Linux Mint Live ISO läufen. 10 Minuten Test war ok, lass nun mal länger laufen. Memtest86 dann am Montag.
 
Mal rein interessehalber, ich hätte momentan die Chance sehr günstig an zwei Intel DC S3500 zu kommen.
Derzeit habe ich folgenden Pool am laufen:
Bash: 
  pool: hdd_vm_mirror
state: ONLINE
  scan: scrub repaired 0B in 0 days 02:00:59 with 0 errors on Sun Oct 25 01:01:01 2020
config:

        NAME                                          STATE     READ WRITE CKSUM
        hdd_vm_mirror                                 ONLINE       0     0     0
          mirror-0                                    ONLINE       0     0     0
            ata-WDC_WD20EACS-11BHUB0_WD-WCAZA3124223  ONLINE       0     0     0
            ata-WDC_WD20EZRX-00D8PB0_WD-WMC4M1682516  ONLINE       0     0     0
          mirror-1                                    ONLINE       0     0     0
            ata-WDC_WD30EZRX-00DC0B0_WD-WMC1T3979908  ONLINE       0     0     0
            ata-TOSHIBA_DT01ACA300_83M2DRAKS          ONLINE       0     0     0

errors: No known data errors
Bash: 
NAME             SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
hdd_data_raidz  21.8T  13.3T  8.49T        -         -     0%    61%  1.00x    ONLINE  -
hdd_vm_mirror   4.53T   583G  3.96T        -         -     4%    12%  1.00x    ONLINE  -
ssd_vm_mirror    222G   124G  97.6G        -         -    30%    56%  1.00x    ONLINE  -

Darauf laufen 3x Windows VM, 2x Linux DB Hosts und etliche Linux VMs. Im Normalbetrieb läuft das ordentlich, aber wenn alle gut IO machen wirds langsam.
Würden mich die beiden SSDs da weiterbringen als "special allocation class" oder "slog"?

Gruß
mg
 
Das sind langsame WD 5400rpm Platten. Ich würde mal davon ausgehen dass ein Raid-10 damit ohne sync ca 200-250MB/s sequentiell schreibend kann. Da man bei VM Storage immer sync aktivieren sollte, wird man gern mal unter 10MB/s landen.

Die DC3500 ist eine Datacenter SSD die vor allem lesend gut ist. Als Slog ist sie nicht so prickelnd. Eine DC 3700 oder WD SS530 oder gar eine Optane wäre erheblich besser. Auf 30-50 MB/s schreibend wird man wohl kommen wenn man sync aktiviert und die als Slog einsetzt. Ein Special Vdev daraus macht Sinn aber nur wenn man einzelne Dateisysteme darauf zwingen möchte.

Alternativ einen kleinen schnellen VM Pool damit machen.
 
Zuletzt bearbeitet:
Moin, danke für die ausführliche Antwort, dann halte ich mal Ausschau nach ner DC3700.

Was für eine Größe sollte ich wählen? Einen reinen SSD-VM-Pool kann ich leider nicht machen da noch ein paar große VMs mit drauf sollen.
mg
 
Zuletzt bearbeitet:
Grade mal ein paar Test durchlaufen lassen. Wichtigste Umstellung waren mehr RAM, jetzt 8GB, und separate NIC über einen virtuellen Switch mit Jumbo Frames.
Folgende Daten erhalte ich da mit Crystal Disk Mark von einer Server 2019 VM. Die VM liegt auf einem NVMe Datastore direkt im ESXi.

Sequentiell 1GiB Q8 T1
HDD Pool lesen: 1807 MB/s
HDD Pool schreiben: 198 MB/s
mit sync: 16 MB/s

SSD Pool lesen: 1795 MB/s
SSD Pool schreiben: 536 MB/s
mit sync: 163 MB/s

Random 4k 1GiB Q32 T16
HDD Pool lesen: 141 MB/s
HDD Pool schreiben: 6 MB/s
mit sync: 1 MB/s

SSD Pool lesen: 141 MB/s
SSD Pool schreiben: 14 MB/s
mit sync: 7 MB/s

Mit sync aktiv ist ja schon ernüchternd... :-(

Zum Vergleich auf den NVMe Datastore:

Sequentiell 1GiB Q8 T1
SSD Pool lesen: 1140 MB/s
SSD Pool schreiben: 1459 MB/s

Random 4k 1GiB Q32 T16
SSD Pool lesen: 48 MB/s (Warum ist der wohl so niedrig)
SSD Pool schreiben: 130 MB/s
 
quotengrote schrieb:
Moin, danke für die ausführliche Antwort, dann halte ich mal Ausschau nach ner DC3700.
Was für eine Größe sollte ich wählen?
mg
Zum Vergrößern anklicken....

Ausreichend sind ca 10GB für ein Slog.

So kleine Hochleistungsplatten gibts leider kaum (gängig war früher z.B. eine drambasierte 8GB ZeusRAM). Bei SSD kommt dazu dass die kleineren Exemplare z.B. 100GB deutlich langsamer sind als größere. Performance kann man zudem erhöhen indem man nur einen kleinen Teil einer neuen oder sicher gelöschten SSD benutzt (Overprovisioning, Host protected Area HPA)
 
Optane DC 4801 ist der Königsweg.
Keine andere NVMe ist vergleichbar gut als Slog geeignet.

Gibts als M.2 oder U.2
 
Hallo Jungs,

ich komme nun doch auf ZFS / Napp IT zurück da ich einfach keine Lust mehr auf rumprobieren habe , deshalb brauche ich Hilfe beim Neuaufbau meines Homeservers:

Es soll ein Datengrab plus VM Storage aufgebaut werden

folgende Bauteile stehen zu Verfügung

TR4 mit 128GB ECC Speicher
am Broadcom 9305-24i
12 Stück 12TB Western Digital 12TB Ultrastar DC HC520 SATA HDD - 7200 RPM Class, SATA 6 Gb/s, 256MB Cache
4 Stück SATA SSD 1TB Crucial MX500
4 Stück SATA SSD 480GB Crucial MX500
per PCIe:
2 Stück Optane P900 280GB
per NVME
2x Samsung 970 EVO 500GB

Ich hatte folgendes vorgesehen:
1x Pool mit HDD und / oder Special VDEV / Optane Slog etc
1x Pool mit SSD für VM

autarker Backupserver (Unraid vorhanden)

Was ist eine solide Aufteilung der Datenspeicher im Pool ? (Ich möchte maximal 2 oder 3 Pools haben, da diese noch gesichert werden sollen und der Server nicht dauerhaft läuft)
 
Zuletzt bearbeitet:
quotengrote schrieb:
Wäre das die hier? Ich bin etwas verwirrt weil dort U.2 steht als Anschlussart.
Zum Vergrößern anklicken....

U.2 und M.2 sind die einzigen Optionen
www.intel.de

Intel® Optane™ DC SSD Reihe – Produktinformationen, Dokumente,...

Produkte der Intel® Optane™ DC SSD Reihe anzeigen. Hier finden Sie Produktspezifikationen, technische Dokumentation, Downloads und Support und mehr von Intel.
www.intel.de www.intel.de

Per Anschlußkabel kann man die U.2 Variante aber an M.2 Mainboards oder an eine PCI-e Adapterkarte anschließen.
Beitrag automatisch zusammengeführt:

Peli67 schrieb:
Hallo Jungs,

ich komme nun doch auf ZFS / Napp IT zurück da ich einfach keine Lust mehr auf rumprobieren habe , deshalb brauche ich Hilfe beim Neuaufbau meines Homeservers:

Es soll ein Datengrab plus VM Storage aufgebaut werden

folgende Bauteile stehen zu Verfügung

TR4 mit 128GB ECC Speicher
am Broadcom 9305-24i
12 Stück 12TB Western Digital 12TB Ultrastar DC HC520 SATA HDD - 7200 RPM Class, SATA 6 Gb/s, 256MB Cache
4 Stück SATA SSD 1TB Crucial MX500
4 Stück SATA SSD 480GB Crucial MX500
per PCIe:
2 Stück Optane P900 280GB
per NVME
2x Samsung 970 EVO 500GB

Ich hatte folgendes vorgesehen:
1x Pool mit HDD und / oder Special VDEV / Optane Slog etc
1x Pool mit SSD für VM

autarker Backupserver (Unraid vorhanden)

Was ist eine solide Aufteilung der Datenspeicher im Pool ? (Ich möchte maximal 2 oder 3 Pools haben, da diese noch gesichert werden sollen und der Server nicht dauerhaft läuft)
Zum Vergrößern anklicken....

ZFS läßt 1001 Varianten und Optimierungen zu.

Die Hauptoption:
- Plattenpool für Filer und Backup (ohne sync, Slog und L2Arc)
- High Performance Pool für VMs (Optane Mirror) mit sync=always
- Medium Performance Pool aus den anderen SSDs/ NVMe
entweder als Multi-Raid-10 (flexibler) oder Raid-Zn mit oder ohne sync je nach Dateisystem/ Anwendung

Ohne eine spezielle Optimierungsabsicht würde ich L2Arc, Slog oder special vdev Optionen ignorieren. Die EVO sind ansonst sehr gute Platten für einen Desktop/ Laptop. Vielleicht sind sie da besser aufgehoben.
 
Zuletzt bearbeitet:
gea schrieb:
U.2 und M.2 sind die einzigen Optionen
www.intel.de

Intel® Optane™ DC SSD Reihe – Produktinformationen, Dokumente,...

Produkte der Intel® Optane™ DC SSD Reihe anzeigen. Hier finden Sie Produktspezifikationen, technische Dokumentation, Downloads und Support und mehr von Intel.
www.intel.de www.intel.de

Per Anschlußkabel kann man die U.2 Variante aber an M.2 Mainboards oder an eine PCI-e Adapterkarte anschließen.
Beitrag automatisch zusammengeführt:
Zum Vergrößern anklicken....
Also würde ich so einen Adapter dazunehmen... https://www.alternate.de/DeLOCK/PCI...ver-Adapter/html/product/1495065?event=search
 
Sync=always erzwingt sync für alle Schreibvorgänge.
Die Voreinstellung sync=default überläßt das dem schreibenden Prozess.

Der SMB Filer schreibt dann z.B. ohne sync, ESXi +NFS nutzt dann sync
 
Zuletzt bearbeitet:
Ich hätte gedacht um die Optane richtig auszunutzen zwinge ich einfach den ganzen IO darüber, oder denke ich da falsch.
 
OmniOS stable 151036 ist da
github.com

omnios-build/doc/ReleaseNotes.md at r151036 · omniosorg/omnios-build

Build system for OmniOS. Contribute to omniosorg/omnios-build development by creating an account on GitHub.
github.com github.com

Einige Verbesserungen:

SMB 3.1.1 (ZFS/kernelbased SMB server)
Improvements on Linux/LX zones
Improvements on Bhyve virtualiser
ZFS can use hardware acceleration for Raid-Z
Improved support for Mellanox ConnectX-4/5/6 , i40e and bge nic devices
gcc10 is now default compiler
 
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