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

maze-m · Friday at 23:25

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):

Bash:

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

Bash:

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 · Saturday at 01:40

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 · Saturday at 09:31

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 · Saturday at 13:29

news said:
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 · Saturday at 13:46

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

Code:

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 · Saturday at 14:42

news said:
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?

news said:
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 · Saturday at 16:06

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:

Code:

#!/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 · Sunday at 00:43

beisser said:
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:

Bash:

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

news said:
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:

Code:

#!/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:

Bash:

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 · Sunday at 01:20

beisser said:
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:

Bash:

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

Bash:

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

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

Bash:

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

Neobin · Sunday at 01:57

maze-m said:
Wie kann ich die denn jetzt umformatieren? Der

Bash:

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

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

Bash:

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 · Sunday at 02:10

Neobin said:
/dev/sf -> /dev/sdf

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

Das scheint aber zu dauern

:

Bash:

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 · Sunday at 10:31

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 · Sunday at 22:57

beisser said:
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?

Bash:

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 · 2026-02-16T10:57:22+0100

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.

Search

Search

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

maze-m

Member

news

Famous Member

beisser

Well-Known Member

maze-m

Member

news

Famous Member

maze-m

Member

news

Famous Member

maze-m

Member

maze-m

Member

Neobin

Distinguished Member

maze-m

Member

beisser

Well-Known Member

maze-m

Member

beisser

Well-Known Member

We value your privacy