Platten 'landen' nicht im ZFS-Pool, was kann ich machen?

[maze-m]

Hallo zusammen!

Da ich von einem Arbeitskollegen einen Fujitsu Primergy RX300 S8 mit vielen "oldschoo" HDDs geschenkt bekommen habe,
habe ich mir auf diesen HDDs einen ZFS-Pool 'Datengrab' eingerichtet.

Nun hab ich festgestellt, dass anscheinende nicht alle 8 Festplatten in dem Pool sind (sda + sdb ist meine gemirrorte Proxmox-Installation):

root@pve:~# lsblk -e230 -o+FSTYPE,LABEL,MODEL
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS FSTYPE     LABEL     MODEL
sda      8:0    0 186.3G  0 disk                                  X446_1625200MCSG
├─sda1   8:1    0  1007K  0 part
├─sda2   8:2    0     1G  0 part             vfat
└─sda3   8:3    0 185.3G  0 part             zfs_member rpool
sdb      8:16   0 186.3G  0 disk                                  SS162512 CLAR200
├─sdb1   8:17   0  1007K  0 part
├─sdb2   8:18   0     1G  0 part             vfat
└─sdb3   8:19   0 185.3G  0 part             zfs_member rpool
sdc      8:32   0 279.4G  0 disk                                  MBF2300RC
sdd      8:48   0 838.4G  0 disk                                  ST9900805SS
├─sdd1   8:49   0 838.4G  0 part             zfs_member Datengrab
└─sdd9   8:57   0     8M  0 part
sde      8:64   0 838.4G  0 disk                                  ST9900805SS
├─sde1   8:65   0 838.4G  0 part             zfs_member Datengrab
└─sde9   8:73   0     8M  0 part
sdf      8:80   0     0B  0 disk                                  DKR5E-J1R2SS
sdg      8:96   0     0B  0 disk                                  DKR5E-J1R2SS
sdh      8:112  0 838.4G  0 disk                                  ST9900805SS
├─sdh1   8:113  0 838.4G  0 part             zfs_member Datengrab
└─sdh9   8:121  0     8M  0 part
sdi      8:128  0     0B  0 disk                                  DKR5E-J1R2SS
sdj      8:144  0 838.4G  0 disk                                  ST9900805SS
├─sdj1   8:145  0 838.4G  0 part             zfs_member Datengrab
└─sdj9   8:153  0     8M  0 part
sr0     11:0    1  1024M  0 rom                                   TSSTcorp CDDVDW SN-208AB

root@pve:~# zpool status -vLP
  pool: Datengrab
 state: ONLINE
  scan: scrub in progress since Sun Feb  8 00:24:01 2026
    1.97T / 1.97T scanned, 352G / 1.97T issued at 522M/s
    0B repaired, 17.45% done, 00:54:24 to go
config:

    NAME           STATE     READ WRITE CKSUM
    Datengrab      ONLINE       0     0     0
      raidz1-0     ONLINE       0     0     0
        /dev/sdd1  ONLINE       0     0     0
        /dev/sde1  ONLINE       0     0     0
        /dev/sdh1  ONLINE       0     0     0
        /dev/sdj1  ONLINE       0     0     0

errors: No known data errors

  pool: rpool
 state: ONLINE
  scan: scrub repaired 0B in 00:00:32 with 0 errors on Sun Feb  8 00:24:37 2026
config:

    NAME           STATE     READ WRITE CKSUM
    rpool          ONLINE       0     0     0
      mirror-0     ONLINE       0     0     0
        /dev/sda3  ONLINE       0     0     0
        /dev/sdb3  ONLINE       0     0     0

errors: No known data errors

In der Web-GUI sieht das dann so aus:


Kann ich die Platten 'sdc', 'sdf' und 'sdg' noch zum Pool hinzufügen, oder zumindest herausfinden, was mit diesen ist?

Ich danke euch für eure Rückmeldung

 

[news]

Moin, das ist ja alles sehr inkonsistent vielleicht werden die Platten nicht gefunden und sie haben null Byte. Damit passen sie nicht zum ZFS Raid.

 

[beisser]

sofern es um die disks vom typ DKR5E-J1R2SS geht, so sind das im original 520 byte sektor drives und können so nicht verwendet werden.

du müsstest sie erst mithilfe von sg3-utils umformatieren.

siehe dazu z.b. https://forum.level1techs.com/t/how-to-reformat-520-byte-drives-to-512-bytes-usually/133021/1

trotz 520 byte formatierung sollten die allerdings mit ihrer normalen kapazität angezeigt werden.

an was für einem controller hängen die denn dran?

 

[maze-m]

Moin, das ist ja alles sehr inkonsistent vielleicht werden die Platten nicht gefunden und sie haben null Byte. Damit passen sie nicht zum ZFS Raid.

Moinsen!
Danke dir für die Rückmeldung!
Inwiefern meinst du, dass es "sehr inkonsistent ist"?
Ich verstehe zudem nicht, wie die Platten null Byte haben können.

 

[news]

Hallo, vielleicht dies, dass die ZFS Datenträger als ZDEV alle die selben größen haben müssen.

sdc      8:32   0 279.4G  0 disk                                  MBF2300RC

Wird mit 279.4G angezeigt und da sehe ich keinen weiteren Datenträger, die als ein ZDEV-n als weiteres Stripeset zum ZFS Pool hinzugefügt werden können.
Vielleicht sind da weitere Datenträger, die nach vielen Jahren der Nutzung, nun defekt sind?

 

[maze-m]

Hallo, vielleicht dies, dass die ZFS Datenträger als ZDEV alle die selben größen haben müssen.

Okay, das heißt als ZDEV kann ich auch nicht "einfach" dem Pool eine größere Festplatte (> 900GB) hinzufügen?

Vielleicht sind da weitere Datenträger, die nach vielen Jahren der Nutzung, nun defekt sind?

Okay, das kann zugegebenermaßen schon der Fall sein.
Wie kann ich denn herausfinden, um welche Platte(n) es sich in meiner Backplane handelt, die ggf. defekt sind und getauscht werden müssen?

 

[news]

Nun ich würde mal das Ausschlussprinzip anwenden,
mit mit smartctl alle Seriennummern holen.
Dazu ein Script schreiben, dass über alle realen Festplatten, mit dem Ergebnis aus ls -la /dev/disk/by-id/, läuft.
Das könnte in etwas so etwas sein:

#!/bin/bash
set -e
#
BASE_PATH="/dev/disk/by-id"
DISK_NAME=".." # bitte mit Namen füllen!#
echo "# -------"
for id in ${DISK_NAME}; do
  echo "Disk: ${BASE_PATH}/$id"
  sudo smartctl -a ${BASE_PATH}/$id | grep -i "serial"
  echo "# -------"
done

 

[maze-m]

trotz 520 byte formatierung sollten die allerdings mit ihrer normalen kapazität angezeigt werden.

an was für einem controller hängen die denn dran?

Ich hab den die Platten an einem umgeflashtend HBA hängen:

02:00.0 SCSI storage controller: Broadcom / LSI SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] (rev 03)

Dazu ein Script schreiben, dass über alle realen Festplatten, mit dem Ergebnis aus ls -la /dev/disk/by-id/, läuft.
Das könnte in etwas so etwas sein:

#!/bin/bash
set -e
#
BASE_PATH="/dev/disk/by-id"
DISK_NAME=".." # bitte mit Namen füllen!#
echo "# -------"
for id in ${DISK_NAME}; do
  echo "Disk: ${BASE_PATH}/$id"
  sudo smartctl -a ${BASE_PATH}/$id | grep -i "serial"
  echo "# -------"
done

Okay, vielen lieben Dank dir für das Script !

Ich hab das mal ausgeführt und vorher mit dem Name befüllt:

root@pve:~# ./bin/get_hdds.sh
# -------
Disk: /dev/disk/by-id/scsi-350000393b8334d40
Serial number:        EB07PBC037GN
# -------
Disk: /dev/disk/by-id/scsi-35000cca0727ae5f8
Serial number:        L0J5L8SK
# -------
Disk: /dev/disk/by-id/scsi-35000cca0727ae5f8
Serial number:        L0J5L8SK
# -------
root@pve:~#

Jetzt muss ich vermutlich Festplatte für Festplatte rausziehen aus der Backplane und nachgucken, welche Disk welche Seriennummer hat, oder?

Bzw. gibt's auch eine Möglichkeit, sich die drei "defekten" Disks im laufenden Betrieb anzeigen zu lassen?

 

[maze-m]

sofern es um die disks vom typ DKR5E-J1R2SS geht, so sind das im original 520 byte sektor drives und können so nicht verwendet werden.

du müsstest sie erst mithilfe von sg3-utils umformatieren.

siehe dazu z.b. https://forum.level1techs.com/t/how-to-reformat-520-byte-drives-to-512-bytes-usually/133021/1

'sg_format /dev/sdX' liefert mir das zurück:

root@pve:~# sg_format /dev/sdf
    HITACHI   DKR5E-J1R2SS      G7G7   peripheral_type: disk [0x0]
      << supports protection information>>
      Unit serial number: L0J61B6J
      LU name: 5000cca0727bb960
Mode Sense (block descriptor) data, prior to changes:
  Number of blocks=2344225968 [0x8bba0cb0]
  Block size=520 [0x208]
Read Capacity (10) results:
   Number of logical blocks=2344225968
   Logical block size=520 bytes
No changes made. To format use '--format'. To resize use '--resize'
root@pve:~# sg_format /dev/sdg
    HITACHI   DKR5E-J1R2SS      G7G7   peripheral_type: disk [0x0]
      << supports protection information>>
      Unit serial number: L0J5L8SK
      LU name: 5000cca0727ae5f8
Mode Sense (block descriptor) data, prior to changes:
  Number of blocks=2344225968 [0x8bba0cb0]
  Block size=520 [0x208]
Read Capacity (10) results:
   Number of logical blocks=2344225968
   Logical block size=520 bytes
No changes made. To format use '--format'. To resize use '--resize'
root@pve:~#

Im Output sehe ich ja, dass die beiden HDDs ja eine Blocksize von 520 Byte haben ( Logical block size=520 bytes).

Wie kann ich die denn jetzt umformatieren? Der

sg_format -v --format --size=512 /dev/sf

funktioniert z.B. nicht, da das Device nicht erkannt wird:

root@pve:~# sg_format -v --format --size=512 /dev/sf
error opening device file: /dev/sf: No such file or directory
root@pve:~#

 

[Neobin]

Wie kann ich die denn jetzt umformatieren? Der

sg_format -v --format --size=512 /dev/sf

funktioniert z.B. nicht, da das Device nicht erkannt wird:

root@pve:~# sg_format -v --format --size=512 /dev/sf
error opening device file: /dev/sf: No such file or directory
root@pve:~#

/dev/sf -> /dev/sdf

 

[maze-m]

/dev/sf -> /dev/sdf

Okay, vielen Dank dir!
Wer lesen kann, ist klar im Vorteil

Das scheint aber zu dauern :

root@pve:~# sg_format -v --format --size=512 /dev/sdf
    HITACHI   DKR5E-J1R2SS      G7G7   peripheral_type: disk [0x0]
      PROTECT=1
      << supports protection information>>
      Unit serial number: L0J61B6J
      LU name: 5000cca0727bb960
    mode sense(10) cdb: [5a 00 01 00 00 00 00 00 fc 00]
Mode Sense (block descriptor) data, prior to changes:
  Number of blocks=2344225968 [0x8bba0cb0]
  Block size=520 [0x208]
    mode select(10) cdb: [55 11 00 00 00 00 00 00 1c 00]

A FORMAT UNIT command will commence in 15 seconds
    ALL data on /dev/sdf will be DESTROYED
        Press control-C to abort

A FORMAT UNIT command will commence in 10 seconds
    ALL data on /dev/sdf will be DESTROYED
        Press control-C to abort

A FORMAT UNIT command will commence in 5 seconds
    ALL data on /dev/sdf will be DESTROYED
        Press control-C to abort
    Format unit cdb: [04 18 00 00 00 00]
Format unit command launched without error

Format unit has started
Format unit in progress, 0.99% done
Format unit in progress, 1.99% done
Format unit in progress, 2.99% done
Format unit in progress, 3.99% done
Format unit in progress, 4.99% done
Format unit in progress, 5.99% done
Format unit in progress, 6.99% done
Format unit in progress, 7.99% done
Format unit in progress, 8.99% done
Format unit in progress, 9.99% done

 

[beisser]

jupp dauert, da er die platte low-level-formatiert.
hat nix mit dem betriebssystem zu tun, sondern mit der internen organisation des laufwerks.

freut mich aber, dass meine vermutung richtig war.

die hitachi platten stammen aus einem proprietären storage und die haben in der regel 520 oder 528 byte sektoren, mit denen andere betriebssysteme nicht umgehen können.
das selbe trifft auf platten aus netapp, dell, cisco und anderen proprietären storages zu.
nur platten aus hyperconverged systemen sind in der regel schon mit 512 bytes oder 4k sektorgrösse formatiert und laufen auf anhieb.

mit sg_format sagst du der platte einfach nur, dass sie sich intern umorganisieren soll und dann kann auch linux was mit dem teil anfangen.

 

[maze-m]

die hitachi platten stammen aus einem proprietären storage und die haben in der regel 520 oder 528 byte sektoren, mit denen andere betriebssysteme nicht umgehen können.
das selbe trifft auf platten aus netapp, dell, cisco und anderen proprietären storages zu.
nur platten aus hyperconverged systemen sind in der regel schon mit 512 bytes oder 4k sektorgrösse formatiert und laufen auf anhieb.

mit sg_format sagst du der platte einfach nur, dass sie sich intern umorganisieren soll und dann kann auch linux was mit dem teil anfangen.

Vielen Dank dir für die wirklich ausführliche Erklärung!

Meine '/dev/sdf' hab ich gestern noch umformatiert und das ist auch soweit durchgelaufen. Wie kann ich die Platte denn jetzt meinem 'Datengrab' Pool hinzufügen?

oot@pve:~# zpool status -vLP
  pool: Datengrab
 state: ONLINE
  scan: scrub repaired 0B in 6 days 00:22:58 with 0 errors on Sat Feb 14 00:46:59 2026
config:

    NAME           STATE     READ WRITE CKSUM
    Datengrab      ONLINE       0     0     0
      raidz1-0     ONLINE       0     0     0
        /dev/sdd1  ONLINE       0     0     0
        /dev/sde1  ONLINE       0     0     0
        /dev/sdh1  ONLINE       0     0     0
        /dev/sdj1  ONLINE       0     0     0

errors: No known data errors

  pool: rpool
 state: ONLINE
  scan: scrub repaired 0B in 00:00:32 with 0 errors on Sun Feb  8 00:24:37 2026
config:

    NAME           STATE     READ WRITE CKSUM
    rpool          ONLINE       0     0     0
      mirror-0     ONLINE       0     0     0
        /dev/sda3  ONLINE       0     0     0
        /dev/sdb3  ONLINE       0     0     0

 

[beisser]

gibt mehrere möglichkeiten.

dazu empfehle ich jetzt mal https://www.diskinternals.com/raid-recovery/zfs-raid-different-size-drives/ als lesestoff

mein persönlicher favorit, wenn es um maximale kapazität geht und nicht um performance, wäre den pool datengrab freizuschaufeln, zu zerstören und ihn mit den zusätzlichen drives als raidz1 oder raidz2 neu anzulegen (ich bevorzuge raidz2). damit verlierst du zwar effektiv von den neuen drives 300gb an kapazität, aber der pool funzt einfach.

vorteil: raidz2 kann 2 platten verlieren und es ist egal, welche 2
Nachteil: IOPS sind kacke. effektiv die von nur einem laufwerk. bei einem datengrab aber normalerweise eher zweitrangig.

alternativ kannst du aus den neuen laufwerken auch ein neues vdev für den existierenden pool bauen und dann über die zwei vdevs stripen.

vorteil: etwas bessere performance, da zwei vdevs anstelle von nur einem.
nachteil: jedes vdev hat seine eigene (einfache) redundanz. wenn die falschen zwei platten ausfallen ist finito.

 

[maze-m]

mein persönlicher favorit, wenn es um maximale kapazität geht und nicht um performance, wäre den pool datengrab freizuschaufeln, zu zerstören und ihn mit den zusätzlichen drives als raidz1 oder raidz2 neu anzulegen (ich bevorzuge raidz2). damit verlierst du zwar effektiv von den neuen drives 300gb an kapazität, aber der pool funzt einfach.

vorteil: raidz2 kann 2 platten verlieren und es ist egal, welche 2
Nachteil: IOPS sind kacke. effektiv die von nur einem laufwerk. bei einem datengrab aber normalerweise eher zweitrangig.

Vielen Dank dir für den Tipp mit dem neu erstellen !
Ich würde allerdings gerne erstmal "zum Rumspielen" einfach nur eine Platte dem Pool hinzufügen wollen? Geht das auch "so einfach"?
Dann müsste danach vermutlich ein Scrub über alle Platten laufen, oder?

Ich hatte halt überlegt, peut a peut alle Platten vom Pool "Datengrab" durch größere 2 TB Platten zu ersetzen, sodass ich den Pool dann Stück für Stück erweitere.
Aber so wie sich es bei dir anhört, ist das auf die Weise nicht so schön gelöst, oder?

 

[Johannes S]

Doch das geht schon (zumindestens ab ZFS 2.3.3, das ist ab ProxmoxVE 9 dabei), siehe: https://pve.proxmox.com/wiki/ZFS_on_Linux#_zfs_administration ->Extend RAIDZ-N

This feature only works starting with Proxmox VE 9 (ZFS 2.3.3).
Assuming you have an existing <pool> with a RAIDZ-N <raidzN-M> vdev, you can add a new physical disk <device> using the following syntax:

zpool attach <pool> <raidzN-M> <device>
You can verify general success by running zpool status <pool> and get verbose output for all attached disks by running zpool list <pool> -v. To inspect the new capacity of your pool run zfs list <pool>

In deinen Fall müste also (nicht getestet) zpool attach datengrab raidz1-0 /dev/sdf funktionieren und das dann mit zfs list datengrab kontrollieren. Ich würde aber auch dazu empfehlen den Pool neu anzulegen und mit IDs statt den sd-Dateien zu arbeiten. Hintergrund: Die sd*-Dateien könnten unter Umständen mal nach einen reboot nach einen Update neu durchnummeriert werden was dann das ganze durcheinander bringen könnte.
Das vermeidet man, in dem man mit IDs arbeitet, welche das sind findet man mit ls -l /dev/by-id heraus, bei mir sieht das aktuell wie folgt aus:

root@pve-node1:~# ls -l /dev/disk/by-id/|grep sd
lrwxrwxrwx 1 root root  9 Jan 30 06:13 ata-SAMSUNG_MZ7LH960HAJR-00005_S45NNA0MA79039 -> ../../sda
lrwxrwxrwx 1 root root 10 Jan 30 06:13 ata-SAMSUNG_MZ7LH960HAJR-00005_S45NNA0MA79039-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 Jan 30 06:13 ata-SAMSUNG_MZ7LH960HAJR-00005_S45NNA0MA79039-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 Jan 30 06:13 ata-SAMSUNG_MZ7LH960HAJR-00005_S45NNA0MA79039-part3 -> ../../sda3
lrwxrwxrwx 1 root root  9 Jan 30 06:13 wwn-0x5002538e19a4d011 -> ../../sda
lrwxrwxrwx 1 root root 10 Jan 30 06:13 wwn-0x5002538e19a4d011-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 Jan 30 06:13 wwn-0x5002538e19a4d011-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 Jan 30 06:13 wwn-0x5002538e19a4d011-part3 -> ../../sda3
root@pve-node1:~# zpool status
  pool: rpool
 state: ONLINE
status: Some supported and requested features are not enabled on the pool.
        The pool can still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
        the pool may no longer be accessible by software that does not support
        the features. See zpool-features(7) for details.
  scan: scrub repaired 0B in 00:19:44 with 0 errors on Sun Feb  8 00:43:46 2026
config:

        NAME                                                                                                                           STATE     READ WRITE CKSUM
        rpool                                                                                                                          ONLINE       0     0     0
          mirror-0                                                                                                                     ONLINE       0     0     0
            nvme-nvme.126f-333231383332343036313930343636-5353445f4d2e325f50434965335f3154425f496e6e6f766174696f6e4954-00000001-part3  ONLINE       0     0     0
            ata-SAMSUNG_MZ7LH960HAJR-00005_S45NNA0MA79039-part3                                                                        ONLINE       0     0     0

errors: No known data errors
root@pve-node1:~#

Was du dir außerdem klar machen musst ist wie von beisser erwähnt, dass raidz generell lausige IOPS hat und sich darum NICHT dafür eignet als Basis für VM-Images (also Betriebssystem und Anwendungen) zu dienen, siehe auch https://forum.proxmox.com/threads/fabu-can-i-use-zfs-raidz-for-my-vms.159923/
Ist bei einen Datengrab nicht unbedingt schlimm, will man das aber auch als Basis für einen ProxmoxBackupServer oder für Datenbanken nehmen, könnte das doch relevant werden. Da sind dann mirrors bzw. striped mirrors (entsprechen RAID1 bzw RAID10 bei HW Raids) deutlich besser, aber die brauchen auch deutlich mehr Kapazität. Mirrors kann man auch jederzeit eine Disk hinzufügen, das müsste (kann das gerade nicht testen) mit zpool attach rpool /dev/sdf gehen. Auf die Weise kann man auch mirrors vergrößern, nehmen wir an wir haben einen mirror rpool mit den beiden Platten diskA und diskB, beide haben eine Kapazität von 2 GB, der Pool also auch eine Kapzität vo n2GB. Nun haben wir uns zwei neue Platten gekauft, mit 4GB, die heißen diskc und disk d. Den Pool vergrößern wir nun:

zpool replace diskA diskC
zpool replace diskB diskD

Sobald beide Prozesse abgeschloßen sind, hat der Pool 4GB Kapazität, wir können den Rechner nun ausschalten und die alten Platten ausbauen. Oder den Rechner nicht ausschalten und die alten Platten für was anders verwenden

 

[maze-m]

@Johannes S : Zunächst einmal vielen lieben Dank dir für die wirklich sehr ausführliche Erklärung!

In deinen Fall müste also (nicht getestet) zpool attach datengrab raidz1-0 /dev/sdf funktionieren und das dann mitzfs list datengrab kontrollieren.

Ah, das hat soweit geklappt, allerings habe ich nun wirklich '/dev/sdf' bei mir stehen ...
Kann ich das noch irgendwie ändern?

root@pve:~# zpool status
  pool: Datengrab
 state: ONLINE
  scan: scrub repaired 0B in 6 days 00:22:58 with 0 errors on Sat Feb 14 00:46:59 2026
expand: expansion of raidz1-0 in progress since Thu Feb 19 22:11:16 2026
    1.10T / 2.12T copied at 239M/s, 52.19% done, 01:13:53 to go
config:

    NAME                        STATE     READ WRITE CKSUM
    Datengrab                   ONLINE       0     0     0
      raidz1-0                  ONLINE       0     0     0
        scsi-35000c5006b366a6f  ONLINE       0     0     0
        scsi-35000c500742eac17  ONLINE       0     0     0
        scsi-35000c5004843be53  ONLINE       0     0     0
        scsi-35000c50048437067  ONLINE       0     0     0
        sdf                     ONLINE       0     0     0

errors: No known data errors

  pool: rpool
 state: ONLINE
  scan: scrub repaired 0B in 00:00:32 with 0 errors on Sun Feb  8 00:24:37 2026
config:

    NAME                              STATE     READ WRITE CKSUM
    rpool                             ONLINE       0     0     0
      mirror-0                        ONLINE       0     0     0
        scsi-35002538453406f90-part3  ONLINE       0     0     0
        scsi-35002538454978810-part3  ONLINE       0     0     0

errors: No known data errors

ch würde aber auch dazu empfehlen den Pool neu anzulegen und mit IDs statt den sd-Dateien zu arbeiten. Hintergrund: Die sd*-Dateien könnten unter Umständen mal nach einen reboot nach einen Update neu durchnummeriert werden was dann das ganze durcheinander bringen könnte.

Davor graußt es mir schon ein wenig. Wie kann ich denn langfristig auf IDs umstellen, sodass ich quasi immer "sorglos" rebooten kann?
Die IDs sind dann doch wirklich eindeutig, oder sehe ich das falsch?

Was du dir außerdem klar machen musst ist wie von beisser erwähnt, dass raidz generell lausige IOPS hat und sich darum NICHT dafür eignet als Basis für VM-Images (also Betriebssystem und Anwendungen) zu dienen, siehe auch https://forum.proxmox.com/threads/fabu-can-i-use-zfs-raidz-for-my-vms.159923/
Ist bei einen Datengrab nicht unbedingt schlimm, will man das aber auch als Basis für einen ProxmoxBackupServer oder für Datenbanken nehmen, könnte das doch relevant werden. Da sind dann mirrors bzw. striped mirrors (entsprechen RAID1 bzw RAID10 bei HW Raids) deutlich besser, aber die brauchen auch deutlich mehr Kapazität.

Ich habe halt überlegt, meine ProxmoxVE-Installation dahingehend so abzuändern:
- 2 x 200 GB Enterprise SSD gemirrored (RAID-1) mit der ProxmoxVE-Installation (läuft jetzt schon so)
- 2 x 800 GB Enterprise SSD (eventl. auch gemirrored um eine zusätzliche 'Datensicherheit' zu haben? / oder gestriped sodass ich 1,6TB nutzen kann) für Root-HDDs der VMs / LXC-Container
- 8 x 2 TB bzw. gibt glaub ich auch 2,4 TB SAS-HDDs in 2,5 Zoll um da das Datengrab darauf einzurichten....

Im HardwareLUXX Forum (ich hoffe, dass es okay ist, dass ich den Beitrag hier verlinke) wurde mir auch schon eine 'Asus Hyper M.2 Karte' empfohlen, auf welcher ich dann M.2 Platinen verbauen könnte, wo ich das (2 x 200 GB für ProxmoxVE-Installation + 2 x 800 GB für Root-HDDs der VMs / LXC-Container) ja auch realisieren könnte.
Ich weiß nur nicht, ob ich so einen Adapter bei mir im Server verbauen kann.
Wenn ja, dann hätte ich ja prinzipiell 12 x 2,5 Zoll Schächte für das Datengrab frei .....

Ich danke euch für eure Ansätze

 

[Johannes S]

Davor graußt es mir schon ein wenig. Wie kann ich denn langfristig auf IDs umstellen, sodass ich quasi immer "sorglos" rebooten kann?
Die IDs sind dann doch wirklich eindeutig, oder sehe ich das falsch?

Ja sind sie, leider lässt sich bei einen RAIDZ (anders als beim Mirror) eine Platte nach dem Hinzufügen nicht wieder entfernen. Da geht dann nur der Austausch einer Platte mit replace oder komplettes Zerstören des Pools und neu-machen. Das Neumachen würde das dann über die Proxmox-GUI erledigen, die sollte das dann gleich richtig machen.
Alternativ (replace) könntest du dir irgendwo eine weitere Platte organisieren (muss ja nicht für immer im Pool bleiben, dafür würe es sogar eine USB-Platte tun (NICHT empfohlen für Produktion) und dann mit zpool-replace poolname altesDevice tmpDevice ersetzen. Danach dann mit zpool replace poolname tmpDevice /dev/altesDevice /dev/disk/by-id/id-deiner-sdf ersetzen. Die ID müsstest du mit den Skript von news oben bestimmen können.

Ich habe halt überlegt, meine ProxmoxVE-Installation dahingehend so abzuändern:
- 2 x 200 GB Enterprise SSD gemirrored (RAID-1) mit der ProxmoxVE-Installation (läuft jetzt schon so)

Kann man so machen, mit ZFS kann man ja den nicht fürs System genutzten Platz ja auch als Storage für VMs nutzen. Mirror ist eine gute Idee, falls mal eine Platte abraucht, kann die andere noch weitermachen, bis Ersatz da ist. Enterprise-SSD ist gut, da die bei den ständigen Schreiben von Metrik- und Loggingdaten länger halten werden.

- 2 x 800 GB Enterprise SSD (eventl. auch gemirrored um eine zusätzliche 'Datensicherheit' zu haben? / oder gestriped sodass ich 1,6TB nutzen kann) für Root-HDDs der VMs / LXC-Container

Auch hier würde ich klar zu einen mirror raten, man kann ja die jeweiligen "Systemlaufwerke" sehr klein anlegen, so dass mehr drauf passt. Die Rohdaten willst du ja eh aufs datengrab packen Und ZFS hat ein Feature für Dateisystemkompression, damit kriegt man auch mehr unter. Im Bedarfsfall könntest du ja außerdem später noch den Mirror mit größeren gebrauchten Enterprise-SSDs vergrößern.

- 8 x 2 TB bzw. gibt glaub ich auch 2,4 TB SAS-HDDs in 2,5 Zoll um da das Datengrab darauf einzurichten....

Kann man so machen, wie man die dann formatiert hängt halt davon ab, wie man Redundanz, Ausfallsicherheit und Performance gegeneinander abwägt. Plus die höhere Flexibiltiät bei "Umbauarbeiten" am Pool (siehe oben)

Im HardwareLUXX Forum (ich hoffe, dass es okay ist, dass ich den Beitrag hier verlinke) wurde mir auch schon eine 'Asus Hyper M.2 Karte' empfohlen, auf welcher ich dann M.2 Platinen verbauen könnte, wo ich das (2 x 200 GB für ProxmoxVE-Installation + 2 x 800 GB für Root-HDDs der VMs / LXC-Container) ja auch realisieren könnte.

Kann man machen, die meisten M2-SSDs haben aber keine Powerloss-Protection (und die mit neu schweineteuer und kaum gebraucht zu kriegen) und werden darum nicht so lange halten, eine Proxmox-Installation schreibt ständig Logging- und Metrixdaten auf die Systemlaufwerke. Ich würde mir darum das Geld sparen Wenn du dagegen damit fein bist deine Systemlaufwerke öfter auszutauschen: Feel free