Sind das fertige externe Platten oder hast du Gehäuse und HDD jeweils getrennt gekauft? Bei fertigen kann es sein, dass der Controller im Gehäuse deinen Wunsch einfach übersteuert oder missinterpretiert.
OMV VM - I/O error
- Thread starter duschkopf
- Start date
Jop fertige Platten. Meh, ob die Platte jetzt Schuld ist oder nicht weiß man ja noch nicht, aber ich merke, dass die HDD von Haus aus schon "limitiert" ist. Hmm Moment, es gibt ja noch hdparm....
das stimmt mich jetzt nicht zuversichtlich...
Meine uralt Platte führt den Befehl aus und geht ind en standby.
Code:
root@openmediavault:~# hdparm -y /dev/sdb1
/dev/sdb1:
issuing standby command
SG_IO: bad/missing sense data, sb[]: 70 00 01 00 00 00 00 0a 00 00 00 00 00 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00das stimmt mich jetzt nicht zuversichtlich...
Meine uralt Platte führt den Befehl aus und geht ind en standby.
Last edited:
Interessant, jetzt wo ich unter Last wieder den Fehler reproduzieren kann, dachte ich mir ich probiere mal ein paar schnelle Dinge aus.
Ich hab den SCSI Controller von VirtIO SCSI SIngle auf VirtIO SCSI umgestellt. Aber das hat doch nur was mit dem VM image zu tun dachte ich?
Auf jeden Fall gibts beim start eine kleine Warnung:
Noch kein shutdown von der VM, allerdings kam 1x der Fehler aus dem 1. Post in der Konsole wieder auf, die shell hing kurz, wurde neu geladen und weiter gings, die VM blieb an.
update: und beim zweiten Fehler diesmal wieder ein crash, zu früh gefreut
Standby/Sleep ist daher schonmal raus als Ursache, da es unter Last grad beim Kopieren gekracht hat.
Ich hab den SCSI Controller von VirtIO SCSI SIngle auf VirtIO SCSI umgestellt. Aber das hat doch nur was mit dem VM image zu tun dachte ich?
Auf jeden Fall gibts beim start eine kleine Warnung:
Code:
()
WARN: iothread is only valid with virtio disk or virtio-scsi-single controller, ignoringNoch kein shutdown von der VM, allerdings kam 1x der Fehler aus dem 1. Post in der Konsole wieder auf, die shell hing kurz, wurde neu geladen und weiter gings, die VM blieb an.
update: und beim zweiten Fehler diesmal wieder ein crash, zu früh gefreut
Standby/Sleep ist daher schonmal raus als Ursache, da es unter Last grad beim Kopieren gekracht hat.
Last edited:
Ja richtig, auf was willst du noch hinaus?
Einfach das flag entfernen, dann kommt das auch nicht mehr.
Das wird wahrscheinlich nur Zufall gewesen sein.
So, ich glaube jetzt nähere ich mich wirklich der Sache.
Last auf dem System (CPU, GPU) und die resultierende Temperatur spielen keine Rolle.
Wenn file transfers auf BEIDEN USB Platten laufen, dann schmiert die kleinere alte Platte der beiden ab. Also die mit den SMART Fehlern. Es ist nicht die 6TB Platte, also macht der ursprüngliche Fehler wieder Sinn. Vergessen wir mal warum ich es andersrum interpretieren wollte...
Ich konnte ein paar weitere Logs rausholen:
der Host spuckt kurz vorher folgendes raus:
Die gleiche Meldung hab ich parallel auch in der OMV VM gesehen, die habe ich aber iregdnwie nicht mehr gefunden.
/dev/sdc ist die alte Platte mit den SMART Fehlern. Ich denke den Teil in der mitte wo "sdb" erwähnt wird kann man ignoerein, aber da war das system schon im einem kaputten Zustand.
Jetzt stellt sich mir die Frage: Kann ich das alles NUR auf die alte Platte schieben? Wieso tritt der Fehler nur auf wenn zwei Festplatten über zwei Ports Daten übertragen? Wenn ja wäre es ja super, Platte in Rente schicken und gut ist.
Aber, das komplette System stürzt ab.
Ich hab grad komplett das Vertrauen in OMV und an die ganze Virtualisierung überhaupt verloren. Erinnert mich an Windows 95 Zeiten wo das System abstürzt wenn es einen Lesefehler auf eienr CD gibt.... Sollte genau sowas nicht vermieden werden?
Last auf dem System (CPU, GPU) und die resultierende Temperatur spielen keine Rolle.
Wenn file transfers auf BEIDEN USB Platten laufen, dann schmiert die kleinere alte Platte der beiden ab. Also die mit den SMART Fehlern. Es ist nicht die 6TB Platte, also macht der ursprüngliche Fehler wieder Sinn. Vergessen wir mal warum ich es andersrum interpretieren wollte...
Ich konnte ein paar weitere Logs rausholen:
Code:
[Nov23 20:08] usb 3-2: reset SuperSpeed USB device number 3 using xhci_hcd
[ +0,024885] sd 4:0:0:0: [sdc] tag#0 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK cmd_age=0s
[ +0,000009] sd 4:0:0:0: [sdc] tag#0 CDB: Read(10) 28 00 7f 24 74 00 00 08 00 00
[ +0,000003] I/O error, dev sdc, sector 2133095424 op 0x0:(READ) flags 0x80700 phys_seg 114 prio class 2
[Nov23 20:08] usb 3-2: reset SuperSpeed USB device number 3 using xhci_hcd
[ +0,024885] sd 4:0:0:0: [sdc] tag#0 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK cmd_age=0s
[ +0,000009] sd 4:0:0:0: [sdc] tag#0 CDB: Read(10) 28 00 7f 24 74 00 00 08 00 00
[ +0,000003] I/O error, dev sdc, sector 2133095424 op 0x0:(READ) flags 0x80700 phys_seg 114 prio class 2
[ +32,166591] sd 3:0:0:0: [sdb] tag#29 uas_eh_abort_handler 0 uas-tag 13 inflight: CMD IN
[ +0,000011] sd 3:0:0:0: [sdb] tag#29 CDB: Read(10) 28 00 3c 41 a1 e7 00 00 80 00
## blabla wiederholt sich...
[ +0,000583] sd 3:0:0:0: [sdb] tag#0 uas_eh_abort_handler 0 uas-tag 15 inflight: CMD IN
[ +0,000005] sd 3:0:0:0: [sdb] tag#0 CDB: Read(10) 28 00 3c 41 a2 e7 00 00 80 00
[ +0,012294] scsi host3: uas_eh_device_reset_handler startder Host spuckt kurz vorher folgendes raus:
Code:
usb 2-2: reset SuperSpeed USB device number 4 using xhci_hcdDie gleiche Meldung hab ich parallel auch in der OMV VM gesehen, die habe ich aber iregdnwie nicht mehr gefunden.
/dev/sdc ist die alte Platte mit den SMART Fehlern. Ich denke den Teil in der mitte wo "sdb" erwähnt wird kann man ignoerein, aber da war das system schon im einem kaputten Zustand.
Jetzt stellt sich mir die Frage: Kann ich das alles NUR auf die alte Platte schieben? Wieso tritt der Fehler nur auf wenn zwei Festplatten über zwei Ports Daten übertragen? Wenn ja wäre es ja super, Platte in Rente schicken und gut ist.
Aber, das komplette System stürzt ab.
Ich hab grad komplett das Vertrauen in OMV und an die ganze Virtualisierung überhaupt verloren. Erinnert mich an Windows 95 Zeiten wo das System abstürzt wenn es einen Lesefehler auf eienr CD gibt.... Sollte genau sowas nicht vermieden werden?
Last edited:
Du solltest eher das Vertrauen in die Platte verlieren. Wenn die aussteigt, kann die Software einfach nicht mehr reagieren.
Ja die Platte ist abgehakt, rette gerade noch ein paar Daten. Habe sie in meine alte OMV Installation am RPI gehängt temporär, da meckert das Systeem nicht. Läuft aber auch nativ und nicht eingebunden als USB device in einer VM. Mal gucken ob ich noch ein gutes Angebot für eine neue Platte finde.
