[Sammelthread] ZFS Stammtisch

@BazzT Bitte denke noch dran, falls es nicht bewusst es, dass ein Slog kein Cache ist. Es dient nur bei synchronen Writes (also NFS z.B. oder falls man es bewusst im Dataset/Volume aktiviert) , um diese max. auf die Geschwindigkeit der async-Writes zu bringen und trotzdem die Datenkonsistenz abzusichern.
Ein reguläres Fileshare, z.B. über Samba, geht nicht über sync writes (sofern man es eben nicht am Dataset erzwingt).

Falls dennoch Slog benutzt werden soll: Intel Optane 900P/905P/P48xx sind da die SSDs der Wahl. Mit großem Abstand. Prio2 wäre sowas wie eine DC P37xx. Keinesfalls eine Consumer-SSD, die geht Dir schnell ein und bricht leistungsmässig schnell ein. Die Optanes haben konstante und niedrigste Zugriffszeiten (Latenzen), sind mit kurzen Warteschlangen annähernd sofort mit voller Geschwindigkeit unterwegs und brauchen auch sowas wie Trim nicht.

L2ARC als Lesecache sollte erst genutzt werden, wenn man den Ram nicht mehr aufrüsten kann (technisch oder finanziell). Für sequentielle große Zugriffe (Streaming eines Mediafiles daheim z.B.) wird L2Arc nichts bringen.
Ausnahme: es gibt ab bestimmten Implementierungen von ZFS nun persistenten L2Arc, wo der Inhalt also Reboots "überlebt".
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Wenn das System (Controller + Wechselplatteneinschub) hotplugfähig ist und Slots frei sind.
-neue 8TB Platte "hot" einstecken, kurz warten und Disk > Replace starten
wenn fertig alte 4TB Platte einfach "hot"ziehen
usw. (Es können auch mehrere Replace gleichzeitig laufen, machts aber kaum schneller)

Da der alte Mirror beim Replace immer online bleibt, gibt es keine verringerte Redundanz.
Resilver liest alle Daten um zu entscheiden ob die wiederhergestellt werden müssen.
Zeit ist also abhängig von der Belegung. Ein aktuelles OmniOS kann sorted Resilver (viel schneller als alte ZFS Versionen)

Ohne Hotplug, System vor Plattenwechsel herunterfahren
Während des Replace kann man weiterarbeiten. Performance leidet etwas.
 
Danke für die Informationen,

Ich werde erstmal das HDD und ein SSD Array aufsetzen und probieren was für mich passt.
Eine Frage habe ich noch:
073ffa64-8f60-4b29-be94-cac841baa1ea.jpg
Wie verhält sich das mit den geschriebenen Datenblöcken?
Die wd30ezrx haben 4k Blöcke.
Im raidz2 mit 5 disks wären es also 12k Blöcke und mit Parity werden 20k belegt.
Wenn kein LZ4 eingesetzt wird:
- Braucht eine Datei mit 4k den vollen 12k Block?
- Braucht eine Datei mit 16k den zwei 12k Blöcke?
Wenn LZ4 eingesetzt wird:
- ist das nicht alles egal?
Wenn alternativ ein Striped mirror angelegt würde 2x2, ist dann die Blocksize 4k im Mirror und 8k im Stripe?
Wenn erweitert würde wäre man doch auch wieder bei 12k oder hab ich das mal wieder nicht verstanden?

Was würdet Ihr bei den vorliegenden Dateiengrößen als Layout wählen?


MfG Basti
 
Wenn das System (Controller + Wechselplatteneinschub) hotplugfähig ist und Slots frei sind.
-neue 8TB Platte "hot" einstecken, kurz warten und Disk > Replace starten
wenn fertig alte 4TB Platte einfach "hot"ziehen
usw. (Es können auch mehrere Replace gleichzeitig laufen, machts aber kaum schneller)

Da der alte Mirror beim Replace immer online bleibt, gibt es keine verringerte Redundanz.
Resilver liest alle Daten um zu entscheiden ob die wiederhergestellt werden müssen.
Zeit ist also abhängig von der Belegung. Ein aktuelles OmniOS kann sorted Resilver (viel schneller als alte ZFS Versionen)

Ohne Hotplug, System vor Plattenwechsel herunterfahren
Während des Replace kann man weiterarbeiten. Performance leidet etwas.
Sodele, HDD wechsel vollzogen.
Hab alles im laufenden Betrieb gemacht. SSD pool für die VMs lief problemlos weiter - endlich hatte der Xeon mal was zu tun. :-)
zpool status
pool: pool_aio
state: ONLINE
scan: resilvered 528K in 0h0m with 0 errors on Fri Aug 6 15:43:01 2021
config:

NAME STATE READ WRITE CKSUM CAP Product /napp-it IOstat mess SN/LUN
pool_aio ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
c3t5000CCA0C2C3FF52d0 ONLINE 0 0 0 8 TB WDC WD80EFBX-68A S:0 H:1 T:60 VRG8TLNK
c3t5000CCA0C2C24B89d0 ONLINE 0 0 0 8 TB WDC WD80EFBX-68A S:0 H:2 T:109 VRG51HXK
c3t5000CCA0C2C416FAd0 ONLINE 0 0 0 8 TB WDC WD80EFBX-68A S:0 H:0 T:0 VRG8ZX0K

errors: No known data errors

pool: pool_ssd
state: ONLINE
scan: none requested
config:

NAME STATE READ WRITE CKSUM CAP Product /napp-it IOstat mess SN/LUN
pool_ssd ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
c3t5002538E001984E2d0 ONLINE 0 0 0 960.2 GB SAMSUNG MZ7KH960 S:0 H:1 T:1 S47NNE0M501861
c3t5002538E0019850Ad0 ONLINE 0 0 0 960.2 GB SAMSUNG MZ7KH960 S:0 H:1 T:1 S47NNE0M501876

errors: No known data errors

pool: rpool
state: ONLINE
scan: scrub repaired 0 in 0h5m with 0 errors on Sun Aug 1 06:05:05 2021
config:

NAME STATE READ WRITE CKSUM CAP Product /napp-it IOstat mess SN/LUN
rpool ONLINE 0 0 0
c1t0d0s0 ONLINE 0 0 0 32.2 GB Virtual disk S:0 H:0 T:0 6000C29E1E2E77A

errors: No known data errors
Was mir jetzt noch Gedanken macht, sind die error-Werte S:0 H:2 T:109 - denn ich hab keine Ahnung was Die aussagen.
Kann mich da jemand bitte erleuchten, was diese Werte bedeuten?

Ferner ist mir aufgefallen, dass ich beim SSD-pool keinen wiederkehrenden Scrub mache.
Hab ich das nur vergessen bei Jobs anzulegen oder braucht es bei SSDs keinen Scrub bzw. sollte er nicht gemacht werden, um die SSD nicht vorzeitig sterben zu lassen?
 
Scrubs ist lesend, also gerne auch bei SSD laufen lassen. Geht natürlich auch viel schneller als bei HDD.
 
Was mir jetzt noch Gedanken macht, sind die error-Werte S:0 H:2 T:109 - denn ich hab keine Ahnung was Die aussagen.
Kann mich da jemand bitte erleuchten, was diese Werte bedeuten?

Ferner ist mir aufgefallen, dass ich beim SSD-pool keinen wiederkehrenden Scrub mache.
Hab ich das nur vergessen bei Jobs anzulegen oder braucht es bei SSDs keinen Scrub bzw. sollte er nicht gemacht werden, um die SSD nicht vorzeitig sterben zu lassen?

soft errors are like CRC corrected errors.
hard errors can't be corrected and are very bad.
transport errors are a communication issue on the SCSI bus.

Diese "errors" sind eher als Hinweis auf künftige Probleme zu sehen oder suboptimale Zustände. Haupteffekt ist verringerte Perfromance da meist nochmal gelesen wirs. Echte Fehler führen dazu dass ZFS die Platte rauswirft oder offline setzt.


Scrub sucht/repariert korrupte Dateien (Prüfsummenfehler) und keine defekten Platten.
Ein scub ist daher auch bei SSD Pools angeraten.
 
Zuletzt bearbeitet:
Mal was Kniffliges. Überreste vom letzten Test, ob eine kleine DC3700 und/oder eine PM981 als Log oder Meta für meine bescheidenen Zwecke taugt. Vermutlich habe ich mit folgender Config runtergefahren, kann das wegen parallel offener SSH-Zugänge aber nicht definitiv sagen:
Code:
  445  sudo format
  446  sudo zpool add gi meta c0t55CD2E404B405950d0p1
  447  sudo zpool add gi log c0t55CD2E404B405950d0p0
  448  sudo zpool add -f gi log c0t55CD2E404B405950d0p0
  449  sudo zpool status gi
[chown-kram nach datentransfer]
  461  exit

Nun importiert er das gar nicht mehr. In napp-it (die 19er noch) stands noch gecacht, nach einem Reboot dann final weg. Da müsste doch irgendwie gelistet sein, wie das Metadevice heißen soll, nicht?

Code:
sudo zpool import
  pool: gi
    id: 8597002655059253587
 state: UNAVAIL
status: The pool metadata is corrupted.
action: The pool cannot be imported due to unavailable devices or data.
   see: http://support.oracle.com/msg/ZFS-8000-72
config:

        gi                      UNAVAIL  corrupted data
          raidz2-0                  ONLINE
            c20t5000C500840779B5d0  ONLINE
            c11t5000C50083EEEE2Dd0  ONLINE
            c22t5000C500834BAAF1d0  ONLINE
            c21t5000C500834B8A41d0  ONLINE
            c24t5000C50083F9F0B1d0  ONLINE
            c28t5000C50083F9C7F1d0  ONLINE
            c9t5000C50083F9C809d0   ONLINE
            c12t5000C50083D370FDd0  ONLINE
            c8t5000C50084075FC9d0   ONLINE
            c25t5000C50084077DC1d0  ONLINE
        meta
        logs
          c0t55CD2E404B405950d0p0   ONLINE

device details:

Partitionen (c29 ist die PM981 mit wahrscheinlich gelöschten Partitionen, daher die Fehlermeldung, c0t55 ist die DC mit den zwei Partitionen für Log und/oder Meta)
Code:
sudo parted --list     
Model: Generic Ide (ide)
Disk /dev/dsk/c0t55CD2E404B405950d0p0: 100GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name  Flags
 1      131kB   50,0GB  50,0GB
 2      50,0GB  100GB   50,0GB
 9      100GB   100GB   8389kB

[...]
Error: The primary GPT table is corrupt, but the backup appears OK, so that will
be used.
OK/Cancel? O                                                              
O
Model: Generic Ide (ide)
Disk /dev/dsk/c29t1d0p0: 256GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start  End    Size    File system  Name  Flags
 1      131kB  128GB  128GB
 2      128GB  256GB  128GB
 9      256GB  256GB  8389kB

zdb von normaler Platte:
Code:
sudo zdb -l /dev/rdsk/c21t5000C500834B8A41d0s0
--------------------------------------------------
LABEL 0
--------------------------------------------------
    timestamp: 1628438323 UTC: Sun Aug  8 15:58:43 2021
    version: 44
    name: 'gi'
    state: 1
    txg: 105105
    pool_guid: 8597002655059253587
    hostid: 4312066
    hostname: 'bzzz'
    top_guid: 2950676166840845936
    guid: 5909265249227721097
    vdev_children: 4
    vdev_tree:
        guid: 2950676166840845936
        id: 0
        type: 'raidz'
        nparity: 2
        metaslab_array: 29
        metaslab_shift: 38
        ashift: 12
        asize: 29961691856896
        is_log: 0
        is_meta: 0
        create_txg: 4
        children[0]:
            guid: 8297107736150169115
            id: 0
            type: 'disk'
            path: '/dev/dsk/c20t5000C500840779B5d0s0'
            devid: 'id1,sd@n5000c500840779b7/a'
            phys_path: '/pci@0,0/pci8086,3c08@3/pci1028,1f1c@0/iport@40/disk@w5000c500840779b5,0:a'
            whole_disk: 1
            DTL: 393
            create_txg: 4
        children[1]:
            guid: 2720699282843914734
            id: 1
            type: 'disk'
            path: '/dev/dsk/c11t5000C50083EEEE2Dd0s0'
            devid: 'id1,sd@n5000c50083eeee2f/a'
            phys_path: '/pci@0,0/pci8086,3c04@2/pci1028,1f1c@0/iport@2/disk@w5000c50083eeee2d,0:a'
            whole_disk: 1
            DTL: 336
            create_txg: 4
        children[2]:
            guid: 15718561606073658343
            id: 2
            type: 'disk'
            path: '/dev/dsk/c22t5000C500834BAAF1d0s0'
            devid: 'id1,sd@n5000c500834baaf3/a'
            phys_path: '/pci@0,0/pci8086,3c08@3/pci1028,1f1c@0/iport@10/disk@w5000c500834baaf1,0:a'
            whole_disk: 1
            DTL: 335
            create_txg: 4
        children[3]:
            guid: 5909265249227721097
            id: 3
            type: 'disk'
            path: '/dev/dsk/c21t5000C500834B8A41d0s0'
            devid: 'id1,sd@n5000c500834b8a43/a'
            phys_path: '/pci@0,0/pci8086,3c08@3/pci1028,1f1c@0/iport@80/disk@w5000c500834b8a41,0:a'
            whole_disk: 1
            DTL: 324
            create_txg: 4
        children[4]:
            guid: 1755638584235848091
            id: 4
            type: 'disk'
            path: '/dev/dsk/c24t5000C50083F9F0B1d0s0'
            devid: 'id1,sd@n5000c50083f9f0b3/a'
            phys_path: '/pci@0,0/pci8086,3c08@3/pci1028,1f1c@0/iport@1/disk@w5000c50083f9f0b1,0:a'
            whole_disk: 1
            DTL: 322
            create_txg: 4
        children[5]:
            guid: 9221677362138274331
            id: 5
            type: 'disk'
            path: '/dev/dsk/c28t5000C50083F9C7F1d0s0'
            devid: 'id1,sd@n5000c50083f9c7f3/a'
            phys_path: '/pci@0,0/pci8086,3c08@3/pci1028,1f1c@0/iport@20/disk@w5000c50083f9c7f1,0:a'
            whole_disk: 1
            DTL: 320
            create_txg: 4
        children[6]:
            guid: 4160591088155128014
            id: 6
            type: 'disk'
            path: '/dev/dsk/c9t5000C50083F9C809d0s0'
            devid: 'id1,sd@n5000c50083f9c80b/a'
            phys_path: '/pci@0,0/pci8086,3c04@2/pci1028,1f1c@0/iport@8/disk@w5000c50083f9c809,0:a'
            whole_disk: 1
            DTL: 319
            create_txg: 4
        children[7]:
            guid: 5721309956896390963
            id: 7
            type: 'disk'
            path: '/dev/dsk/c12t5000C50083D370FDd0s0'
            devid: 'id1,sd@n5000c50083d370ff/a'
            phys_path: '/pci@0,0/pci8086,3c04@2/pci1028,1f1c@0/iport@4/disk@w5000c50083d370fd,0:a'
            whole_disk: 1
            DTL: 302
            create_txg: 4
        children[8]:
            guid: 8402750212068742207
            id: 8
            type: 'disk'
            path: '/dev/dsk/c8t5000C50084075FC9d0s0'
            devid: 'id1,sd@n5000c50084075fcb/a'
            phys_path: '/pci@0,0/pci8086,3c04@2/pci1028,1f1c@0/iport@1/disk@w5000c50084075fc9,0:a'
            whole_disk: 1
            DTL: 298
            create_txg: 4
        children[9]:
            guid: 16426974791769872454
            id: 9
            type: 'disk'
            path: '/dev/dsk/c25t5000C50084077DC1d0s0'
            devid: 'id1,sd@n5000c50084077dc3/a'
            phys_path: '/pci@0,0/pci8086,3c08@3/pci1028,1f1c@0/iport@8/disk@w5000c50084077dc1,0:a'
            whole_disk: 1
            DTL: 264
            create_txg: 4
--------------------------------------------------
LABEL 1 - CONFIG MATCHES LABEL 0
--------------------------------------------------
--------------------------------------------------
LABEL 2 - CONFIG MATCHES LABEL 0
--------------------------------------------------
--------------------------------------------------
LABEL 3 - CONFIG MATCHES LABEL 0
--------------------------------------------------
zdb Logdevice (p0)
Code:
sudo zdb -l /dev/rdsk/c0t55CD2E404B405950d0p0
--------------------------------------------------
LABEL 0
--------------------------------------------------
failed to unpack label 0
--------------------------------------------------
LABEL 1
--------------------------------------------------
    timestamp: 1628438323 UTC: Sun Aug  8 15:58:43 2021
    version: 44
    name: 'gi'
    state: 1
    txg: 105105
    pool_guid: 8597002655059253587
    hostid: 4312066
    hostname: 'bzzz'
    top_guid: 14118070282534071270
    guid: 14118070282534071270
    is_log: 1
    vdev_children: 4
    vdev_tree:
        guid: 14118070282534071270
        id: 3
        type: 'disk'
        path: '/dev/dsk/c0t55CD2E404B405950d0p0'
        devid: 'id1,sd@n55cd2e404b405950/q'
        phys_path: '/scsi_vhci/disk@g55cd2e404b405950:q'
        whole_disk: 0
        metaslab_array: 823
        metaslab_shift: 29
        ashift: 12
        asize: 99857989632
        is_log: 1
        is_meta: 0
        DTL: 488
        create_txg: 100584
--------------------------------------------------
LABEL 2 - CONFIG MATCHES LABEL 1
--------------------------------------------------
--------------------------------------------------
LABEL 3 - CONFIG MATCHES LABEL 1
--------------------------------------------------
zdb Metadevice (eigentlich p1, wenn die history korrekt ist)
Code:
sudo zdb -l /dev/rdsk/c0t55CD2E404B405950d0s1
--------------------------------------------------
LABEL 0
--------------------------------------------------
failed to unpack label 0
--------------------------------------------------
LABEL 1 - CONFIG MATCHES LABEL 0
--------------------------------------------------
failed to unpack label 1
--------------------------------------------------
LABEL 2
--------------------------------------------------
    timestamp: 1624194904 UTC: Sun Jun 20 13:15:04 2021
    version: 44
    name: 'gi'
    state: 0
    txg: 0
    pool_guid: 8597002655059253587
    hostid: 4312066
    hostname: 'bzzz'
    top_guid: 14452099611626819232
    guid: 14635706990919288512
    vdev_children: 4
    vdev_tree:
        guid: 14452099611626819232
        id: 2
        type: 'replacing'
        whole_disk: 0
        removing: 1
        metaslab_array: 515
        metaslab_shift: 29
        ashift: 9
        asize: 99857989632
        is_log: 0
        is_meta: 1
        create_txg: 100343
        children[0]:
            guid: 14635706990919288512
            id: 0
            type: 'disk'
            path: '/dev/dsk/c0t55CD2E404B405950d0s0'
            devid: 'id1,sd@n55cd2e404b405950/a'
            phys_path: '/scsi_vhci/disk@g55cd2e404b405950:a'
            whole_disk: 1
            removing: 1
            DTL: 591
        children[1]:
            guid: 11811790790989656280
            id: 1
            type: 'pseudo'
            path: '$VDEV-D98738DF6D911413'
            phys_path: 'gi/$VDEV-D98738DF6D911413'
            removing: 1
            DTL: 609
            create_txg: 100343
    create_txg: 0
--------------------------------------------------
LABEL 3 - CONFIG MATCHES LABEL 2
--------------------------------------------------

Wie erzähle ich denn Solaris nun, dass das auf p1 erwartete Logdevice da nicht mehr auffindbar ist, aber auf s1 etwas brauchbares ist, das aber irgendwie auch auf s0 linkt? Oder gibt es einen -m für Metas statt Logdevices beim zpool import? Die Pool-GUID ist ja überall da. Was sagt type: 'replacing' / removing: 1 aus?

Ein bisschen bin ich versucht, die p0 zu löschen und mit -m zu importieren, in der Hoffnung, dass dann die zweite Partition entdeckt wird.
 
Prinzipiell gilt ein Pool als verloren wenn ein vdev fehlt.
Mit sudo zpool add gi meta c0t55CD2E404B405950d0p1 wurde ein spezial vdev hinzugefügt das jetzt fehlt.

ps
special vdevs immer als Mirror hinzufügen
 
Prinzipiell gilt ein Pool als verloren wenn ein vdev fehlt.
Mit sudo zpool add gi meta c0t55CD2E404B405950d0p1 wurde ein spezial vdev hinzugefügt das jetzt fehlt.
Genau - ein log oder cache lässt sich entfernen (mit der Gefahr unter illumos, dass dann TRIM nicht mehr geht), ein meta device [grds.] nicht.

Hast Du (@Bzzz ) da evtl "meta" = special vdev und log verwechselt?
 
Mindestens einer von uns ist da nicht auf dem aktuellen Stand (Solaris!), denn ich hab da ja wie gesagt mit Log, Meta und Log+Meta in allen Kombinationen über die beiden SSDs gespielt und da gebenchmarkt. Log kann man entfernen, Meta kann man entfernen. man sagt, dass es kein mirrored meta braucht, da alle Daten auch eh auf dem restlichen Pool liegen, aber wegen rotierendem Rost halt auch einfach langsamer im Zugriff sind.

Code:
history
   99  sudo zpool add gi meta c0t55CD2E404B405950d0p0
  100  sudo zpool add -f gi log c0t55CD2E404B405950d0p0
  101  sudo zpool add -f gi meta c0t55CD2E404B405950d0p1
  102  sudo zpool status gi
  103  sudo zpool remove gi c0t55CD2E404B405950d0
  104  sudo zpool remove gi c0t55CD2E404B405950d0p0
  105  sudo zpool remove gi c0t55CD2E404B405950d0p1
  106  sudo format
  107  sudo zpool add gi log c29t1d0
  108  sudo zpool remove gi c29t1d0
  109  sudo zpool add gi log c29t1d0p0
  110  sudo zpool add -f gi log c29t1d0p0
  111  sudo zpool add -f gi meta c29t1d0p1
  112  sudo zpool status gi
  113  sudo zpool remove gi c29t1d0p0
  114  sudo zpool remove gi c29t1d0p1
  115  sudo zpool add gi log c29t1d0p0
  116  sudo zpool add gi log c29t1d0
  117  sudo zpool add gi meta c0t55CD2E404B405950d0
  118  sudo zpool remove gi c29t1d0
  119  sudo zpool remove gi c0t55CD2E404B405950d0
  120  sudo zpool add gi meta c29t1d0
  121  sudo zpool add gi log c0t55CD2E404B405950d0
  122  sudo zpool status gi
  123  sudo zpool status gi
  124  exit
  126  sudo zpool status gi
  127  sudo zpool remove gi c29t1d0
  128  sudo zpool status gi
  129  sudo zpool remove gi c0t55CD2E404B405950d0
  130  sudo zpool status gi
  131  sudo zpool add gi meta c0t55CD2E404B405950d0
  132  sudo zpool status gi
  133  sudo zpool add gi log c29t1d0
  134  sudo zpool status gi
  135  sudo zpool remove gi c0t55CD2E404B405950d0
  136  sudo zpool status gi
  138  sudo zpool remove gi c29t1d0
  139  sudo zpool add gi meta c29t1d0
  140  sudo zpool status gi
  141  sudo zpool remove gi c29t1d0
  142  sudo format
  143  sudo zpool add -f  gi log c29t1d0p0
  144  sudo zpool add -f  gi meta c29t1d0p1
  145  sudo zpool status gi
  146  sudo zpool remove gi c29t1d0p0
  147  sudo zpool remove gi c29t1d0p1
  148  sudo format
  149  sudo zpool add gi meta c0t55CD2E404B405950d0p1
  150  sudo zpool add gi log c0t55CD2E404B405950d0p0
  151  sudo zpool add -f gi log c0t55CD2E404B405950d0p0
  152  sudo zpool status gi

Das in napp-it empfohlene zdb-Kommando mit noch mehr Buchstaben dran bringt:

Code:
--------------------------------------------------
LABEL 3 - INVALID
--------------------------------------------------
    timestamp: 1624194904 UTC: Sun Jun 20 13:15:04 2021
    version: 44
    name: 'gi'
    state: 0
    txg: 0
    pool_guid: 8597002655059253587
    hostid: 4312066
    hostname: 'bzzz'
    top_guid: 14452099611626819232
    guid: 14635706990919288512
    vdev_children: 4
    vdev_tree:
        guid: 14452099611626819232
        id: 2
        type: 'replacing'
        whole_disk: 0
        removing: 1
        metaslab_array: 515
        metaslab_shift: 29
        ashift: 9
        asize: 99857989632
        is_log: 0
        is_meta: 1
        create_txg: 100343
        children[0]:
            guid: 14635706990919288512
            id: 0
            type: 'disk'
            path: '/dev/dsk/c0t55CD2E404B405950d0s0'
            devid: 'id1,sd@n55cd2e404b405950/a'
            phys_path: '/scsi_vhci/disk@g55cd2e404b405950:a'
            whole_disk: 1
            removing: 1
            DTL: 591
        children[1]:
            guid: 11811790790989656280
            id: 1
            type: 'pseudo'
            path: '$VDEV-D98738DF6D911413'
            phys_path: 'gi/$VDEV-D98738DF6D911413'
            removing: 1
            DTL: 609
            create_txg: 100343
    create_txg: 0
Uberblock[0] - INVALID
        magic = 0x0000000000bab10c
        version = 44
        txg = 0
        guid_sum = 7315845153359852804
        pool_guid = 8597002655059253587
        hostid = 0x41cc02
        scnt = 0
        slot = 0
        timestamp = 1624194904 date = Sun Jun 20 15:15:04 CEST 2021
        rootbp = DVA[0]=<0:c8003f94000:6000:RZM:6> [L0 DMU objset] fletcher4 lzjb LE unique unencrypted size=800L/200P birth=100387L/100387P fill=791 contiguous 6-copy cksum=1022afe5a0:6621748b901:148d747fe80af:2cdf4fc39a4768
        expected checksum = 0xa5c40edff7febb0a:0x12b25a4127f93201:0x38d536962dc48084:0x5c76e40a70b46e7d
        computed checksum = 0x18292d4296266fd9:0xd7494f3ba7780b6f:0xe830b8a454a3b162:0x3e5fb93dea14ce75

(fürs andere Label ebenso) - kanns sein, dass der die Partition wegen einem invalid Label nicht mehr als Meta anerkennen will?
 
Log und L2Arc lassen sich aus einem Pool entfernen. Ein plötzlicher Verlust ist unkritisch. Beim L2Arc gibt es dann halt nur noch den RAM Lesecache Arc. Beim Slog wird lediglich auf das langsamere onpool Logging gewechselt.

Bei special vdev ist das anders. Die kann man zwar auch nachtröglich aus dem Pool entfernen, es gibt aber zwei Besonderheiten:
Das special vdev benötigt den gleichen ashift wie die Pool vdevs, sonst klappt Entfernen nicht
Geht das special vdev plötzlich verloren, ist der Pool verloren - es sei denn man kann das Device wiederbeleben. Die Daten auf dem special Device werden ja nicht zusätzlich darauf gespeichert wie es beim L2Arc der Fall ist, sondern ausschließlich- man will ja Top Performance.
 
Hab hier noch einen ML10 v2 stehen den ich gerne bisschen "updaten" würde. Als CPU ist ein Xeon 4x3,1Ghz verbaut. Natürlich soll OmniOS und Nappit später drauf laufen. Ein "Problem" ist aktuell nur von was ich boote. Es gibt zwa 4 PCIe Plätze, welche ich aktuell nicht in Benutzung habe, allerdings kann er von NVMe nicht direkt booten da das noch nicht unterstützt wird. Was ich aber eigentlich am liebsten machen würde, so könnte ich den langsamsten PCIe Slot dafür "missbrauchen". Der Plan war halt die 6 Sata onboard Ports freizuhalten.

Alternativen so wie ich das sehe: Ich kaufe mir eine dieser PCIe Steckkarten welche direkt eine 2,5Zoll Sata SSD aufnehmen können. Davon sollte er afaik booten können. Wobei solche Dinger bisschen "Exoten" sind. Weiß nicht ob OmniOS den Controller dann mögen wird. Teilweise wird sich auch komplett ausgeschwiegen dazu was überhaupt für einer verbaut ist. "Irgendwie" über einen PCIe Slot zu booten fände ich aber praktisch, weil ich die ansonsten nicht brauche. Grade die langsammen nicht.
Frage ist nur ob sich das lohnt oder man nicht doch besser einen 8Port HBA kauft, die Datenplatten dann direkt daran anschließt und den onboard Sata Controller dann für die Bootplatte nimmt. Der onboard Sata Controller hat ohnehin nur Sata3 auf Port 1 und 2. 3 bis 6 sind nur Sata 2. Wobei das für Festplatten halt in meinen Augen erstmal egal wäre.
Frage am Rande: Wie sieht eigentlich so die "Zukunft" aus von Sata? Denkt ihr es wird dafür auch noch weiterhin einen Bedarf geben zB wenn QLC SSDs irgendwann mal im Preis deutlich sinken als Alternative zur HDD dann. Soweit ich weiß hat die 4TB QVO von Samsung immer noch 160MB/s schreibend wenn der Cache erschöpft ist, was zB bei einer 1Gbit Anbindung sowieso mehr als ausreichend wäre. Bandbreiten von über 1GB/s einer SSD brauch man bei vielen Sachen ja nicht. Oder ist davon auszugehen dass Sata auch mit den Festplatten "sterben" wird?

Booten von USB geht natürlich, wenngleich ich das auch unschön finde. Vorallem da es keinen internen Port gibt und ein Stick dann entweder hinten oder vorne rausschauen würde.
Mit HBAs kenne ich mich aber nicht aus. Wieviel hat man so auszugeben für einen gescheiten. Soll nicht viel Kosten da der Server auch nicht mehr der neueste ist und sich ansonsten schon die Frage stellt ob man nicht komplett was neues kauft.

Hab hier auch noch eine 16GB Optane M.2 rumliegen, die ich mittels PCIe Adapter mal reingebaut habe. OmniOS lässt sich durchaus drauf installieren, nur booten davon geht nicht. Vermutlich wegen fehlender NVMe Unterstützung im Bios.
 
Zuletzt bearbeitet:
Ich würde in der Bucht nach einem LSI HBA suchen: "HBA IT mode" (ab ca 50 Euro)
Sollte neben der IT Firmware (IR Firmware ist auch ok, auf keinen Fall Raid5 Firmware ) einen 6G LSI Chip 2008. 2307 oder 12G LSI 3008 haben.
 
Mit der serienmäßigen Raid5 Firmware sicher nicht. Ich vermute mal dass da auch kein LSI Chip drauf ist. Dann gibt es keine Crossflash Option und die besonders ausgereiften Treiber für LSI IT mode oder IR mode HBA gehen auch nicht.

OK? - eher nein. Goldstandard für ZFS sind LSI HBAs oder OEM von Dell, IBM, HP etc mit 2008, 2307 oder 3008 Chip und IT Firmware. IR Firmware ist auch noch ok. Um alles andere würde ich einen Bogen machen.
 
Zuletzt bearbeitet:
Sata/AHCI ist auch "HBA Mode".
Man braucht dafür dennoch einen anderen Treiber als für einen LSI Controller und selbst da einen anderen für HBA mit IT Firmware oder IR Firmware.

Da LSI Controller in fast jedem ZFS Filer (seit Sun 2005 ZFS erfand) verbaut sind, sind deren Treiber besonders ausgereift. "Man nimmt einfach nichts anderes für Unix und ZFS" wenn man mehr braucht als onboard Sata
 
Zuletzt bearbeitet:
Hat der schon USB3?
Dann einfach eine USB3 SSD als Bootlaufwerk....
(selbst USB2 würde i.d.R. für ein schlankes OS wie OmniOS, TrueNAS oder XigmaNAS ausreichen - Läuft im Betrieb eh fast ausschließlich im RAM)
 
Ja er hat USB2 und USB3. Habe auch eine µSSD USB Stick mit USB3. Aber im USB3 Mode zickt er rum beim booten. Ich weiß nicht was das Problem ist. Stellt man allerdings alle Ports auf USB2 funktioniert es.
Hatte ihn so auch schonmal betrieben, wobei dann der doch recht lange Stick vorne herausgeschaut hat. Aber da könnte man ja einen 90grad Winkel benutzen. Ich meine aber das Webinterface von Nappit wenn man drin navigiert reagierte da schon deutlich träger als wenn das ganze auf einer SATA SSD untergebracht war.
Problem im USB2 Mode ist nur dann mal ne externe USB Platte anzuschließen für ein Backup oder ähnliches ist dann nicht mehr, aufgrund der lahmen Geschwindigkeit.
Finde bei ebay viele LSI Controller aus China zum auf den ersten Blick guten Preis. Ist davon abzuraten, sind die "Fake" oder sowas?
 
Hast Du auf dem Board intern evtl noch einen Header frei? Falls Dich ein externer USB-Stick stört, kannst Du einfach sowas nehmen und den Stick dadrauf stecken - hatte ich auch länger mal so:

 
Ich würde USB vermeiden. Nicht so problemlos wie Sata, nicht so langlebig wie SSD und auch langsamer in der GUI da die alle Platten und Dateisysteme einliest und das bei USB erheblich langsamer ist.
 
Moin zusammen,
ich hatte bei meinem Server eine "kleine" Havarie. Sicherung war geflogen und als ich die Sicherung wieder rein gemacht habe und den Netzteilstecker vom Server eingesteckt habe, hat's im Netzteil laut Patsch gemacht. :-( Also neues Netzteil besorgt und gespannt beobachtet, ob die Maschine wieder anläuft. Ud siehe da, Server startet, bootet problemfrei ESXi. Als erstes von der heruntergefahrenen Napp-It VM eine Kopie gezogen (man weiß ja nie) und die VM gestartet. Startet auch erst einmal, also frohen Mutes die Napp-It Admin Seite angesteuert - Timeout. Na sowas. Ein Blick auf die Konsole der VM zeigt, dass scheinbar Dienste nicht gestartet werden können.
Hier ein Screenshot, offenbar
Bildschirmfoto 2021-08-14 um 08.39.22.png


svcs -xv bringt mich nicht wirklich weiter auch das referenzierte Log ist für mich wenig aussagekräftig:

Code:
[ Aug. 13 22:40:10 Enabled. ]
[ Aug. 13 22:40:22 Executing start method ("/sbin/rc2 start"). ]
Executing legacy init script "/etc/rc2.d/S05vmware-tools".
Starting VMware Tools services in the virtual machine:
Switching to guest configuration:[ Aug. 13 23:10:23 Method or service exit timed out.  Killing contract 73. ]

Hat jemand Hinweise, wie ich mich der Ursache nähern kann, um die VM wieder ans Laufen zu bekommen?

Danke und Gruß:
 
Es sieht so aus wie wenn Systemdateien durch den Crash beschädigt wurden. Da die Boot-VM auf einem ESXi Dateisystem liegt hat man da keine Copy on Write Absicherung wie bei ZFS. Ein Absturz beim Schreiben kann im Gegensatz zu Daten auf ZFS zu Datenkorruption führen.

Solaris/OmniOS legt bei jedem System bzw. napp-it Update ein "Bootenvironment" an. Das ist ein bootfähiger Snapshot des Betriebssystems vor dem Update. Bei Problemen würde ich immer als Erstes in einen früheren OS Stand booten. Das kann man beim OmniOS Start anwählen. Vermutlich wird das reichen.

Worst case wenn man alle Bootenvironments gelöscht haben sollte oder Bootenvironments auch nicht gehen oder die ESXi Bootplatte defekt ist.
- (ESXI neu installieren), napp-it VM neu bereitstellen, ZFS Pool importieren, NFS aktivieren, NFS in ESXi neu anmelden und VMs importieren (ESXi Dateibrowser, Maus Rechtsklick auf .vmx Datei).

Wenn man nicht lange überlegen muss und eine neue Bootplatte und ESXi Installer und napp-it VM bereit hat, dauert Komplett Recovery bei ESXi AiO von einem Totalausfall der System Platte weniger als 30 Minuten bis alles wieder läuft.
 
Zuletzt bearbeitet:
Ich würde USB vermeiden. Nicht so problemlos wie Sata, nicht so langlebig wie SSD und auch langsamer in der GUI da die alle Platten und Dateisysteme einliest und das bei USB erheblich langsamer ist.
Wieso sollte eine SSD, die via USB angeschlossen ist nicht so langlebig sein, wie die via SATA Angeschlossene?
 
USB Sticks sind mir in den letzten Jahren echt inzwischen einige als „ESXi System-Disk“ gestorben. Von jetzt auf gleich und sowohl billige (Intenso & Co.) wie bessere (Lexar, SanDisk). Bin aus Faulheit jetzt doch bei den meisten Systemen auf kleine SSDs umgestiegen.
 
Im Thread gings um USB Sticks
Bei USB Sticks gibt es aber auch enorme Unterschiede. Teilweise sind es SSDs mit nem USB Konverter dran. Ergo haben auch den ganzen Kram wie Wear Leveling mit an Board.
Ich denke da an sowas wie einen Sandisk Extreme Pro. Hatte selber den Vorgänger mit 16GB. Der machte eigentlich nie Probleme. Hatte aber auch mal USB Sticks die man so als "Werbegeschenk" erhält. Klar dass da nur das billigste vom billigsten verbaut ist.
Ich denke zum Teil lässt sich dieses "Vorurteil" von schnell sterbenden USB Sticks wohl damit begründen dass manche einfach den letzten Schrott für sowas einsetzen, was grad irgendwo im Angebot ist oder was sie noch irgendwo rumfliegen haben.
"HighEnd" USB Sticks sind wirklich SSDs mit einem USB Controller davor geschaltet.

Von jetzt auf gleich und sowohl billige (Intenso & Co.) wie bessere (Lexar, SanDisk).
Naja SanDisk hat ne große Palette an USB Sticks für die unterschiedlichsten Usecases und Zielgruppen. Intenso klar, die kaufen stumpf das billigste am Markt ein. Bei SanDisk muss man aber bisschen differenzieren von was man da genau redet. Wenn du das billigste Zeug von einem Weltmarkführer kaufst (der auch hochwertige Sachen im Angebot hat) ist es nicht umbedingt besser nur weil sein Logo drauf steht.

Beim Sandisk Extreme Pro kann ich sagen dass ich den lange Zeit lang als Stick für OmniOS mal im Einsatz hatte. Erst im Microserver G7, später dann in einem ML10 v2. Hatte aber nie ein größeres Problem was ich auf diesen Stick zurückführen konnte. Andere billig sticks sind mir aber nach paar Monaten auch schon verreckt. Natürlich ist USB für das OS nicht perfekt. Es macht aber dennoch nen großen Unterschied was du eben einsetzt.

Was ich nicht verstehe wieso gibt es sowenig Mainboards mit M.2 Schnittstelle für die Bootplatte die aber nur mit x1 oder x2 angebunden sind. Grade für ein Server würde x1 doch völlig ausreichend für das OS oder nicht? Da könnte man doch besser 2 M.2 Schnittstellen mit jeweils x1 machen wegen Redundanz statt die M.2 Schnittstellen jedesmal mit x4 anzubinden.
 
Zuletzt bearbeitet:
Ich würde USB vermeiden. Nicht so problemlos wie Sata, nicht so langlebig wie SSD und auch langsamer in der GUI da die alle Platten und Dateisysteme einliest und das bei USB erheblich langsamer ist.
Sollte man wenn denn nur mit so Teilen machen wie in der sig ;)
 
Es sieht so aus wie wenn Systemdateien durch den Crash beschädigt wurden. Da die Boot-VM auf einem ESXi Dateisystem liegt hat man da keine Copy on Write Absicherung wie bei ZFS. Ein Absturz beim Schreiben kann im Gegensatz zu Daten auf ZFS zu Datenkorruption führen.

Solaris/OmniOS legt bei jedem System bzw. napp-it Update ein "Bootenvironment" an. Das ist ein bootfähiger Snapshot des Betriebssystems vor dem Update. Bei Problemen würde ich immer als Erstes in einen früheren OS Stand booten. Das kann man beim OmniOS Start anwählen. Vermutlich wird das reichen.

Worst case wenn man alle Bootenvironments gelöscht haben sollte oder Bootenvironments auch nicht gehen oder die ESXi Bootplatte defekt ist.
- (ESXI neu installieren), napp-it VM neu bereitstellen, ZFS Pool importieren, NFS aktivieren, NFS in ESXi neu anmelden und VMs importieren (ESXi Dateibrowser, Maus Rechtsklick auf .vmx Datei).

Wenn man nicht lange überlegen muss und eine neue Bootplatte und ESXi Installer und napp-it VM bereit hat, dauert Komplett Recovery bei ESXi AiO von einem Totalausfall der System Platte weniger als 30 Minuten bis alles wieder läuft.
Wollte nur nochmal schnell ein Dankeschön da lassen - der Hinweis mit dem Bootenvironment war der Schlüssel. Konnte das BE wechseln und nun läuft die Kiste wieder. Danke! (y)
 
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