[SOLVED] ZFS Fault.. Imme wieder bei einem System

[OsvaldoP]

Hallo NG

Ich muss euch mal um Rat bei einem Server bitten welcher immer wieder ZFS Fault fehler bringt

Es handelt sich um ein Supermicro System mit Epic CPU

Anbei Daten zum PVE:

proxmox-ve: 6.2-1 (running kernel: 5.4.34-1-pve)
pve-manager: 6.2-4 (running version: 6.2-4/9824574a)
pve-kernel-5.4: 6.2-1 pve-kernel-helper: 6.2-1
pve-kernel-5.4.34-1-pve: 5.4.34-2


Im System sind folgende Disks verbaut

* 2x nvme
** zfs - pve

* 4x SSD SAMSUNG_MZ7KH1T9
** zfs1 - Daten

* 3x HDD WD HGST Ultrastar - 0F27352
** zfs1 - Archiv Daten

Beim befüllen des ZFS mit den 3 HDD wurde ein ZFS Fault gemeldet
Meldung siehe Error1 unten
Darauf hin haben wir die defekte Disk getauscht und ein resilver durchgeführt.
System war ok

Ca 1 Woche später erhielten wir ein ZFS Fault error am ZFS1 (4x SSD)
Siehe Error 2

Smart sieht recht ok aus, daher meine Frage woran kann es liegen, dass die Disks in diesem System immer wieder auf degraded fallen?


ERROR1 (HDD)

ZFS device fault for pool 0xF5CC5A39AE06E521 on xxx

The number of checksum errors associated with a ZFS device

exceeded acceptable levels. ZFS has marked the device as

degraded.

impact: Fault tolerance of the pool may be compromised.
eid: 50
class: statechange
state: DEGRADED
host:
time: 2020-12-13 00:52:40+0100
vpath: /dev/sde1
vphys: pci-0000:43:00.0-sas-phy5-lun-0
vguid: 0x22FFF8E8F8376C8B
devid: scsi-35000cca2a204e710-part1
pool: 0xF5CC5A39AE06E521

Resilvering von Error1

ZFS has finished a resilver:

eid: 57
class: resilver_finish
host:
time: 2020-12-14 18:00:30+0100
pool: zfs02
state: DEGRADED
scan: resilvered 644G in 0 days 07:07:54 with 0 errors on Mon Dec 14 18:00:30 2020
config:

NAME STATE READ WRITE CKSUM
zfs02 DEGRADED 0 0 0
raidz1-0 DEGRADED 0 0 0
replacing-0 DEGRADED 0 0 0
2522007995831250059 FAULTED 0 0 0 was /dev/sde1
sdg ONLINE 0 0 0
wwn-0x5000cca27ee11dc8 ONLINE 0 0 0
wwn-0x5000cca2a20524b8 ONLINE 0 0 0

errors: No known data errors

ERROR2 (SSD)

ZFS device fault for pool 0xD83FC66CF5393C2A on slpvep01

The number of I/O errors associated with a ZFS device exceeded
acceptable levels. ZFS has marked the device as faulted.

impact: Fault tolerance of the pool may be compromised.
eid: 85
class: statechange
state: FAULTED
host:
time: 2020-12-29 21:07:24+0100
vpath: /dev/disk/by-id/wwn-0x5002538e10342220-part1
vphys: pci-0000:43:00.0-sas-phy0-lun-0
vguid: 0x07B660D8E068CBC9
devid: scsi-35002538e10342220-part1
pool: 0xD83FC66CF5393C2A

Resilvering Error2

ZFS has finished a resilver:

eid: 93
class: resilver_finish
host: slpvep01
time: 2020-12-30 09:37:06+0100
pool: zfs01
state: ONLINE
scan: resilvered 2.28G in 0 days 00:00:08 with 0 errors on Wed Dec 30 09:37:06 2020
config:

NAME STATE READ WRITE CKSUM
zfs01 ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
scsi-35002538e10342222 ONLINE 0 0 0
wwn-0x5002538e10342213 ONLINE 0 0 0
wwn-0x5002538e10342220 ONLINE 0 0 0
wwn-0x5002538e1034221f ONLINE 0 0 0

errors: No known data errors

Meine Frage>:
Sind hier wirklich immer die Disks defekt oder könnte es ein Softwareproblem sein?


Vielen Dank und schöne Grüße
Roland

 

[aaron]

Wie sind die Festplatten genau angebunden?

Es könnte ein Kabel oder ein eventueller HBA Controller defekt sein.

 

[OsvaldoP]

Hallo Aaron!

Im Server ist ein onboard Controller mit Backplane für die Disks verbaut auf welchen die beiden betroffenen Disks hängen.-
Was ich weiters rauslesen kann ist, dass die nvme DIsks ein eigenen Controller haben

Somit könnte die Backplane oder der onboard Controller defekt sein?

Vermutlich können wir ein Softwarefehler ausschließen?



Die beiden Disks

lrwxrwxrwx 1 root root 10 Dec 14 10:47 pci-0000:43:00.0-sas-phy0-lun-0-part1 -> ../../sdd1
lrwxrwxrwx 1 root root 10 Dec 14 10:52 pci-0000:43:00.0-sas-phy5-lun-0-part9 -> ../../sdg9

Alle Disks

lrwxrwxrwx 1 root root 9 Dec 29 21:07 pci-0000:43:00.0-sas-phy0-lun-0 -> ../../sdd
lrwxrwxrwx 1 root root 10 Dec 14 10:52 pci-0000:43:00.0-sas-phy5-lun-0-part1 -> ../../sdg1
lrwxrwxrwx 1 root root 10 Dec 14 10:52 pci-0000:43:00.0-sas-phy5-lun-0-part9 -> ../../sdg9
lrwxrwxrwx 1 root root 9 Dec 14 10:52 pci-0000:43:00.0-sas-phy5-lun-0 -> ../../sdg
lrwxrwxrwx 1 root root 10 Dec 14 10:47 pci-0000:43:00.0-sas-phy7-lun-0-part9 -> ../../sdf9
lrwxrwxrwx 1 root root 10 Dec 14 10:47 pci-0000:43:00.0-sas-phy6-lun-0-part9 -> ../../sde9
lrwxrwxrwx 1 root root 10 Dec 14 10:47 pci-0000:43:00.0-sas-phy6-lun-0-part1 -> ../../sde1
lrwxrwxrwx 1 root root 10 Dec 14 10:47 pci-0000:43:00.0-sas-phy7-lun-0-part1 -> ../../sdf1
lrwxrwxrwx 1 root root 9 Dec 14 10:47 pci-0000:43:00.0-sas-phy6-lun-0 -> ../../sde
lrwxrwxrwx 1 root root 9 Dec 14 10:47 pci-0000:43:00.0-sas-phy7-lun-0 -> ../../sdf
lrwxrwxrwx 1 root root 10 Dec 14 10:47 pci-0000:43:00.0-sas-phy0-lun-0-part1 -> ../../sdd1
lrwxrwxrwx 1 root root 10 Dec 14 10:47 pci-0000:43:00.0-sas-phy0-lun-0-part9 -> ../../sdd9
lrwxrwxrwx 1 root root 10 Dec 14 10:47 pci-0000:43:00.0-sas-phy3-lun-0-part1 -> ../../sdc1
lrwxrwxrwx 1 root root 10 Dec 14 10:47 pci-0000:43:00.0-sas-phy3-lun-0-part9 -> ../../sdc9
lrwxrwxrwx 1 root root 10 Dec 14 10:47 pci-0000:43:00.0-sas-phy1-lun-0-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 Dec 14 10:47 pci-0000:43:00.0-sas-phy1-lun-0-part9 -> ../../sdb9
lrwxrwxrwx 1 root root 10 Dec 14 10:47 pci-0000:43:00.0-sas-phy2-lun-0-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 Dec 14 10:47 pci-0000:43:00.0-sas-phy2-lun-0-part9 -> ../../sda9
lrwxrwxrwx 1 root root 9 Dec 14 10:47 pci-0000:43:00.0-sas-phy3-lun-0 -> ../../sdc
lrwxrwxrwx 1 root root 9 Dec 14 10:47 pci-0000:43:00.0-sas-phy1-lun-0 -> ../../sdb
lrwxrwxrwx 1 root root 9 Dec 14 10:47 pci-0000:43:00.0-sas-phy2-lun-0 -> ../../sda
lrwxrwxrwx 1 root root 15 Dec 14 10:47 pci-0000:41:00.0-nvme-1-part3 -> ../../nvme0n1p3
lrwxrwxrwx 1 root root 15 Dec 14 10:47 pci-0000:42:00.0-nvme-1-part2 -> ../../nvme1n1p2
lrwxrwxrwx 1 root root 15 Dec 14 10:47 pci-0000:41:00.0-nvme-1-part2 -> ../../nvme0n1p2
lrwxrwxrwx 1 root root 15 Dec 14 10:47 pci-0000:42:00.0-nvme-1-part3 -> ../../nvme1n1p3
lrwxrwxrwx 1 root root 15 Dec 14 10:47 pci-0000:41:00.0-nvme-1-part1 -> ../../nvme0n1p1
lrwxrwxrwx 1 root root 15 Dec 14 10:47 pci-0000:42:00.0-nvme-1-part1 -> ../../nvme1n1p1
lrwxrwxrwx 1 root root 13 Dec 14 10:47 pci-0000:41:00.0-nvme-1 -> ../../nvme0n1
lrwxrwxrwx 1 root root 13 Dec 14 10:47 pci-0000:42:00.0-nvme-1 -> ../../nvme1n1

Danke & sg
Roland

 

[OsvaldoP]

Hallo

folgendes konnte ich noch im syslog finden, deutet wohl auf Schreibfehler hin

Dec 29 21:07:08 xxxxxx kernel: [1333142.819219] sd 19:0:1:0: attempting task abort!scmd(0x00000000233deb7c), outstanding for 31192 ms & timeout 30000 ms
Dec 29 21:07:08 xxxxxx kernel: [1333142.819962] sd 19:0:1:0: [sdd] tag#9097 CDB: Read(10) 28 00 0f 23 5a d0 00 00 08 00
Dec 29 21:07:08 xxxxxx kernel: [1333142.820516] scsi target19:0:1: handle(0x0009), sas_address(0x4433221100000000), phy(0)
Dec 29 21:07:08 xxxxxx kernel: [1333142.820883] scsi target19:0:1: enclosure logical id(0x500605b00fd8f1a0), slot(3)
Dec 29 21:07:08 xxxxxx kernel: [1333142.821250] scsi target19:0:1: enclosure level(0x0000), connector name( )
Dec 29 21:07:08 xxxxxx kernel: [1333142.866201] sd 19:0:1:0: [sdd] tag#9068 FAILED Result: hostbyte=DID_SOFT_ERROR driverbyte=DRIVER_OK
Dec 29 21:07:08 xxxxxx kernel: [1333142.866252] sd 19:0:1:0: task abort: SUCCESS scmd(0x00000000233deb7c)
Dec 29 21:07:08 xxxxxx kernel: [1333142.867067] sd 19:0:1:0: [sdd] tag#9068 CDB: Write(10) 2a 00 55 09 c4 d0 00 00 58 00
Dec 29 21:07:08 xxxxxx kernel: [1333142.867783] sd 19:0:1:0: [sdd] tag#9097 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK
Dec 29 21:07:08 xxxxxx kernel: [1333142.867785] sd 19:0:1:0: [sdd] tag#9097 CDB: Read(10) 28 00 0f 23 5a d0 00 00 08 00
Dec 29 21:07:08 xxxxxx kernel: [1333142.868400] blk_update_request: I/O error, dev sdd, sector 1426703568 op 0x1WRITE) flags 0x700 phys_seg 11 prio class 0
Dec 29 21:07:08 xxxxxx kernel: [1333142.869015] blk_update_request: I/O error, dev sdd, sector 253975248 op 0x0READ) flags 0x700 phys_seg 1 prio class 0
Dec 29 21:07:08 xxxxxx kernel: [1333142.869630] zio pool=zfs01 vdev=/dev/disk/by-id/wwn-0x5002538e10342220-part1 error=5 type=2 offset=730471178240 size=45056 flags=180880
Dec 29 21:07:08 xxxxxx kernel: [1333142.870262] zio pool=zfs01 vdev=/dev/disk/by-id/wwn-0x5002538e10342220-part1 error=5 type=1 offset=130034278400 size=4096 flags=180880
Dec 29 21:07:08 xxxxxx kernel: [1333142.873208] sd 19:0:1:0: attempting task abort!scmd(0x00000000c8a07b85), outstanding for 31244 ms & timeout 30000 ms
Dec 29 21:07:08 xxxxxx kernel: [1333142.873769] sd 19:0:1:0: [sdd] tag#9095 CDB: Read(10) 28 00 0f 23 5a c8 00 00 08 00
Dec 29 21:07:08 xxxxxx kernel: [1333142.874323] scsi target19:0:1: handle(0x0009), sas_address(0x4433221100000000), phy(0)
Dec 29 21:07:08 xxxxxx kernel: [1333142.874892] scsi target19:0:1: enclosure logical id(0x500605b00fd8f1a0), slot(3)
Dec 29 21:07:08 xxxxxx kernel: [1333142.875486] scsi target19:0:1: enclosure level(0x0000), connector name( )
Dec 29 21:07:08 xxxxxx kernel: [1333142.876045] sd 19:0:1:0: No reference found at driver, assuming scmd(0x00000000c8a07b85) might have completed
Dec 29 21:07:08 xxxxxx kernel: [1333142.876639] sd 19:0:1:0: task abort: SUCCESS scmd(0x00000000c8a07b85)
Dec 29 21:07:08 xxxxxx kernel: [1333142.877225] sd 19:0:1:0: [sdd] tag#9095 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK
Dec 29 21:07:08 xxxxxx kernel: [1333142.877833] sd 19:0:1:0: [sdd] tag#9095 CDB: Read(10) 28 00 0f 23 5a c8 00 00 08 00
Dec 29 21:07:08 xxxxxx kernel: [1333142.878433] blk_update_request: I/O error, dev sdd, sector 253975240 op 0x0READ) flags 0x700 phys_seg 1 prio class 0
Dec 29 21:07:08 xxxxxx kernel: [1333142.879054] zio pool=zfs01 vdev=/dev/disk/by-id/wwn-0x5002538e10342220-part1 error=5 type=1 offset=130034274304 size=4096 flags=180880
Dec 29 21:07:08 xxxxxx kernel: [1333142.880393] sd 19:0:1:0: attempting task abort!scmd(0x0000000013c06c90), outstanding for 31252 ms & timeout 30000 ms
Dec 29 21:07:08 xxxxxx kernel: [1333142.881072] sd 19:0:1:0: [sdd] tag#9003 CDB: Read(10) 28 00 0f 23 5a c0 00 00 08 00
Dec 29 21:07:08 xxxxxx kernel: [1333142.881771] scsi target19:0:1: handle(0x0009), sas_address(0x4433221100000000), phy(0)
Dec 29 21:07:08 xxxxxx kernel: [1333142.882515] scsi target19:0:1: enclosure logical id(0x500605b00fd8f1a0), slot(3)
Dec 29 21:07:08 xxxxxx kernel: [1333142.883218] scsi target19:0:1: enclosure level(0x0000), connector name( )
Dec 29 21:07:08 xxxxxx kernel: [1333142.883913] sd 19:0:1:0: No reference found at driver, assuming scmd(0x0000000013c06c90) might have completed
Dec 29 21:07:08 xxxxxx kernel: [1333142.884647] sd 19:0:1:0: task abort: SUCCESS scmd(0x0000000013c06c90)
Dec 29 21:07:08 xxxxxx kernel: [1333142.885410] sd 19:0:1:0: [sdd] tag#9003 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK
Dec 29 21:07:08 xxxxxx kernel: [1333142.886131] sd 19:0:1:0: [sdd] tag#9003 CDB: Read(10) 28 00 0f 23 5a c0 00 00 08 00
Dec 29 21:07:08 xxxxxx kernel: [1333142.886859] blk_update_request: I/O error, dev sdd, sector 253975232 op 0x0READ) flags 0x700 phys_seg 1 prio class 0
Dec 29 21:07:08 xxxxxx kernel: [1333142.887629] zio pool=zfs01 vdev=/dev/disk/by-id/wwn-0x5002538e10342220-part1 error=5 type=1 offset=130034270208 size=4096 flags=180880
Dec 29 21:07:08 xxxxxx kernel: [1333142.889115] sd 19:0:1:0: attempting task abort!scmd(0x0000000048b7518b), outstanding for 31260 ms & timeout 30000 ms
Dec 29 21:07:08 xxxxxx kernel: [1333142.889872] sd 19:0:1:0: [sdd] tag#9001 CDB: Read(10) 28 00 0f 23 5a b8 00 00 08 00
Dec 29 21:07:08 xxxxxx kernel: [1333142.890638] scsi target19:0:1: handle(0x0009), sas_address(0x4433221100000000), phy(0)
Dec 29 21:07:08 xxxxxx kernel: [1333142.891457] scsi target19:0:1: enclosure logical id(0x500605b00fd8f1a0), slot(3)
Dec 29 21:07:08 xxxxxx kernel: [1333142.892270] scsi target19:0:1: enclosure level(0x0000), connector name( )
Dec 29 21:07:08 xxxxxx kernel: [1333142.893083] sd 19:0:1:0: No reference found at driver, assuming scmd(0x0000000048b7518b) might have completed
Dec 29 21:07:08 xxxxxx kernel: [1333142.893940] sd 19:0:1:0: task abort: SUCCESS scmd(0x0000000048b7518b)
Dec 29 21:07:08 xxxxxx kernel: [1333142.894803] sd 19:0:1:0: [sdd] tag#9001 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK
Dec 29 21:07:08 xxxxxx kernel: [1333142.895618] sd 19:0:1:0: [sdd] tag#9001 CDB: Read(10) 28 00 0f 23 5a b8 00 00 08 00
Dec 29 21:07:08 xxxxxx kernel: [1333142.896438] blk_update_request: I/O error, dev sdd, sector 253975224 op 0x0READ) flags 0x700 phys_seg 1 prio class 0
Dec 29 21:07:08 xxxxxx kernel: [1333142.897281] zio pool=zfs01 vdev=/dev/disk/by-id/wwn-0x5002538e10342220-part1 error=5 type=1 offset=130034266112 size=4096 flags=180880
Dec 29 21:07:08 xxxxxx kernel: [1333142.898940] sd 19:0:1:0: attempting task abort!scmd(0x0000000053a84335), outstanding for 31268 ms & timeout 30000 ms
Dec 29 21:07:08 xxxxxx kernel: [1333142.899187] sd 19:0:1:0: Power-on or device reset occurred
Dec 29 21:07:08 xxxxxx kernel: [1333142.899819] sd 19:0:1:0: [sdd] tag#8999 CDB: Read(10) 28 00 0f 23 5a b0 00 00 08 00
Dec 29 21:07:08 xxxxxx kernel: [1333142.902449] scsi target19:0:1: handle(0x0009), sas_address(0x4433221100000000), phy(0)
Dec 29 21:07:08 xxxxxx kernel: [1333142.903811] scsi target19:0:1: enclosure logical id(0x500605b00fd8f1a0), slot(3)
Dec 29 21:07:08 xxxxxx kernel: [1333142.904861] scsi target19:0:1: enclosure level(0x0000), connector name( )

 

[aaron]

NVMEs haben einen eigenen Controller da diese direkt am PCI Bus hängen.

Die Festplatten sind keine shingled (SMR) Platten, das hätte evtl. auch eine Erklärung sein können.

Eventuell mal BIOS/Firmware aktualisieren?

Was für ein Motherboard ist es denn? So rein interessehalber.

Ansonsten wie schon erwähnt, versuchen Hardware zu wechseln wo möglich und schauen ob die Probleme weiterhin auftreten. Vielleicht kann man testweise auch einen anderen Controller stecken.

 

[OsvaldoP]

Hy Aaron!

Anbei das Datenblatt zum Board.
Supermicro ServerBoard H11SSL-NC (SP3) // 8 SAS3 ports + 2 NVMe (RAID 0,1,10)

Ich werde mal mit dem Hersteller reden welche Ideen dieser hat.

Danke inzwischen

sg
Roland

 

[OsvaldoP]

Hy

Der Hersteller meinte er hatte schon mal solche in Fehler in Verbindung mit PVE und ZFS, der Kunde konnte das Problem softwareseitig mit einer Änderung am ZFS lösen.
Sobald ich weitere Info erhalte melde ich mich.

 

[Dunuin]

Würde mich auch interessieren. Habe hier auch gelegendlich ZFS IO Fehler am älteren Supermicro Board und Kabel bereits getauscht und die HDDs/SSDs hängen am Onboard-Controller.

 

[OsvaldoP]

Guten Morgen!

Werde die Info gleich nach erhalt posten und nach einer Analyse gleich am prod System testen.

sg

 

[OsvaldoP]

Hallo

Ich habe nun Antwort vom Hersteller erhalten.
Er meinte ein anderer Kunde hatte genau das selbe Problem, immer wieder traten Read Errors auf und irgendeine Disk wird als defekt deklariert.
Als Lösung wurde das SMART Monitoring im PVE abgeschalten. Wie genau konnte ich nicht erfragen, denke jedoch es wurde wie hier beschrieben deaktiviert. PVE SMART Monitoring

Natürlich möchte ich ungern SMART abschalten, interessant wäre ob man hier Schwellwerte anpassen kann

sg
Roland

PS Es ist diese Woche erneut eine Disk "ausgefallen"

 

[aaron]

Hmm, wenn ich die Kernel Logs von oben hernehme: ... blk_update_request: I/O error, dev sdd, ... verstehe ich jetzt nicht wie SMART das regelmäßige Auslesen der SMART Werte einen Einfluss darauf haben soll.

Ansonsten wie schon erwähnt: Firmware/BIOS aktualisieren. Kabel austauschen, anderen Controller/HBA ausprobieren.

 

[OsvaldoP]

Hy

stimmt das habe ich übersehen.
Ich werde mal Bios Updaten und halte euch am laufenden

sg

 

[OsvaldoP]

Hallo

Erst mal sorry, dass ich mich so spät melde. Der Fehler trat dann sehr selten auf und zeitlich war es etwas knapp.

Derzeit schaut es danach aus, dass die Disk's zu lange brauchen um vom Standby aufzuwachen. ZFS geht in einem Timeout und meldet Readfehler.



Anbei ein Artikel der das selbe Fehlerverhalten schildert : https://github.com/openzfs/zfs/issues/4713 (Sucht nach "SAS3008 of my Supermicro X11SSL-CF")

Im Artikel wird beschrieben, dass die aktuelle Firmware des HBA helfen sollte ich werde diese so rasch wie möglich updaten.
Sollte jemand Erfahrung mit HBA Updates haben, bin ich gerne für Tips offen

Info zu meinem Controller.
Firmware Version 5 ist installiert

 ./sas3ircu 1 DISPLAY
Avago Technologies SAS3 IR Configuration Utility.
Version 17.00.00.00 (2018.04.02)
Copyright (c) 2009-2018 Avago Technologies. All rights reserved.

Read configuration has been initiated for controller 1
------------------------------------------------------------------------
Controller information
------------------------------------------------------------------------
  Controller type                         : SAS3008
  BIOS version                            : 8.11.00.00
  Firmware version                        : 5.00.00.00
  Channel description                     : 1 Serial Attached SCSI
  Initiator ID                            : 0
  Maximum physical devices                : 1023
  Concurrent commands supported           : 10240
  Slot                                    : 3
  Segment                                 : 0
  Bus                                     : 67
  Device                                  : 0
  Function                                : 0
  RAID Support                            : No
------------------------------------------------------------------------

Im Anhang ein Ausschnitt aus dem syslog
Nochmals kurz erwähnt, Infos zum Update von HBA sind gern gesehen

sg
Roland

 

[t-np]

hi, ich hatte aktuell auf einem Host ein ähnliches Problem.
Asrock x399 mit Threadripper und Samsung NVME 970 Evo 2TB als single disk in ZFS Pool zum rumspielen.
Auf dem Host läuft mein win10 gast mit gpu passthrough und passthrough von weiteren pcie devices und meiner bootdisk. Seit ein paar Monaten bekam ich nur noch mit Mühe und Not den win10 Gast zum Starten ohne das der Host eingefroren ist. Parallel habe ich festgestellt das die Samsung 970EVO bei jedem Scrub die SMART Data Integrity Errors: 31+ Error Information Log Entries: 48 hochzählt und ich die selben Fehler wie @ciRoland im log sah. Ich bin aber erst heute auf die Spur gekommen dass genau dieses Problem auch für die Host lockups beim Gaststart verantwortlich war. Obwohl die Disk in keinster weise mit dem Gast in Verbindung stand, war diese für die lockups beim guest boot (meist erster Windows Screen mit dem rotierenden kreis, seltener zweiter Bootscreen mit "applying configuration", seltener wenn Desktop hochgefahren war, ganz selten stunden, tage oder eine Woche später). Ganz schlimm war das ganze, wenn der Host rebootet wurde. Dauerte meist zig host reboots bis irgendwann der guest wieder lief. Nachdem ich die NVME auf verdacht ausgebaut hatte, da ich während eines lockups den blk_update_request error in der Konsole eingeblendet bekam, läuft alles einwandfrei.
Ich würde in meinem Fall eine inkompatibilität der Samsung 970EVO mit dem ZFS Dateisystem vermuten. Der Sektor ist bei jedem Scrub immer ein anderer. Ich hab auch kein I/O error sondern critical medium error bei der op (READ). Was sich mit dem ZFS status deckt da immer lesefehler beim scrub protokolliert wurden.

Nov 8 00:26:18 xxx kernel: [306450.056380] zio pool=zfs vdev=/dev/disk/by-id/nvme-eui.0025385b81b21500-part1 error=61 type=1 offset=88327696896 size=131072 flags=1808b0
Nov 8 00:26:18 xxx kernel: [306450.056343] blk_update_request: critical medium error, dev nvme0n1, sector 172517081 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0    
Nov 8 00:26:18 xxx kernel: [306450.056380] zio pool=zfs vdev=/dev/disk/by-id/nvme-eui.0025385b81b21500-part1 error=61 type=1 offset=88327696896 size=131072 flags=1808b0
Nov 8 00:26:18 xxx zed: eid=54 class=io pool_guid=0xFD58158A8A98C87E vdev_path=/dev/disk/by-id/nvme-eui.0025385b81b21500-part1
Nov 8 00:26:47 xxx kernel: [306479.686640] zio pool=zfs vdev=/dev/disk/by-id/nvme-eui.0025385b81b21500-part1 error=61 type=1 offset=153830233600 size=131072 flags=40080cb0
Nov 8 00:26:47 xxx kernel: [306479.686602] blk_update_request: critical medium error, dev nvme0n1, sector 300451723 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Nov 8 00:26:47 xxx kernel: [306479.686640] zio pool=zfs vdev=/dev/disk/by-id/nvme-eui.0025385b81b21500-part1 error=61 type=1 offset=153830233600 size=131072 flags=40080cb0

Ich werde die NVME mal aus Interesse in ein neueres TX40 board bauen und dort den scrub probieren um eine potentielle Hardwareproblematik auszuschließen. Ich gehe davon aus das die Disk in einem "normalen" Client ohne ZFS kein Problem machen wird.

Es ist sehr beunruhigend und war sehr verwirrend bei der Fehlersuche. Eine NVME Disk locked den Host, nur weil ein Guest, der eigentlich gar nicht auf die Disk zugreift, hochgefahren wird.

 

[OsvaldoP]

Hy

Das Verhalten deiner VM klingt interessant.
Ich hatte vor 2 Wochen ein ähnliches verhalten auf einem ESXi 6.7
Ein Windows Server 2016 von 4 Servern startete nach dem ESXI Boot nicht mehr.
Eine Wiederherstellung der VM blieb ebenfalls beim booten hängen (beim Ring)

Wäre interessant woran das liegen kann, vor allem da es verschiedene Hypervisor betreffen kann.



Zur Info bez dem ZFS Fehler

Seit 18 ist der Fehler nicht mehr aufgetreten, vermutlich war das HBA Update die Lösung
( Klopf auf Holz ;-) )

sg
Roland

 

[flove]

Hallo Zusammen,
ich habe ein ähnliches Problem (konnte allerdings noch keine I/O Errors im Syslog finden).
Alle paar Tage oder manchmal auch erst nach 1-2 Wochen meldet der Pool Fehler:

sudo zpool status -v rpool 1
  pool: rpool
 state: ONLINE
status: One or more devices has experienced an error resulting in data
    corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
    entire pool from backup.
   see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-8A
  scan: scrub in progress since Sun Jan  8 11:54:30 2023
    63.7G scanned at 9.09G/s, 828K issued at 118K/s, 259G total
    0B repaired, 0.00% done, no estimated completion time
config:

    NAME         STATE     READ WRITE CKSUM
    rpool        ONLINE       0     0     0
      nvme0n1p3  ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:

        <0x1a2>:<0x0>

Manchmal wird statt <meistens Random>:<0x0> auch <rpool/datasetA@snapshot:<0x0> oder ähnlich angezeigt.

Nach zwei scrub Durchläufen ist der Fehler wieder weg.

• Hardware:
  • Intel NUC8i7BEH mit 64 GB RAM (vorher mal 32GB mit selbem Fehler)
  • 1x Samsung 970 EVO 1TB als rpool mit Containern auf encrypted dataset unter rpool/encrptd/subvol-101-disk-0

Ich habe jetzt die SSD getauscht (Clonezilla, sector by sector mode) gegen eine Toshiba XG5 (KXG50ZNV1T02).
Nach nur einem Tag erhalte ich wieder die selben Fehler > 2x Scrub > weg. Mal abwarten wie lange es jetzt hält.
Ich hatte kurzzeitig die neue SSD in ein HP Elitebook 840 G5 und Proxmox + ZFS liefen für ein paar Tage ohne Probleme.

Ähnliche ....:<0x0> Fehler hatte ich schonmal auf einem anderen System nachdem ein ZFS Pool von Ubuntu 20.04 (fs-0.8.3-1ubuntu12.14) zu Proxmox 7.2 (zfs-2.1.6-pve1) migriert wurde:

• I/O error on mounting encrypt fs after upgrading · Issue #13709 · openzfs/zfs
• Permanent errors have been detected in the following files with clean scrub and no other errors · Issue #13859 · openzfs/zfs

Fix: Hack fix script for volumes suffering ZFS encryption bug


Habt ihr ne Idee?