Proxmox machte einfach Neustart
- Thread starter Fantasenf
- Start date
Das hat nicht zum Absturz geführt, aber das wäre ein Configfehler und ich nehme mal an, dass du von
root@pve.spitney.deübers google-relay rausschicken wolltest. Da ist irgendwo ein Logikfehler drin. Direkt funktioniert es mit dynamischer IP sowieso nicht, das vorweg.Der Absturz kommt möglicherweise davon, dass /dev/sda defekt ist und wenn die Warnmail nie durchkam, hattest du davon auch keine Kenntnis.
Also meist ist SMART korrekt, aber ich hatte schon wenige Fälle, wo SMART versagte. Bzw. alles "passed" meldete, obwohl die disk schon scheintot war, aber auch der umgekehrte Weg...SMART sagt disk ist kurz vorm Sterben, aber sie lief noch munter weiter ohne dass man was bemerkte.
Mehr als Problem mit /dev/sda gibt das log aber auch nicht her.
Wennsd mogst, kannst du noch die Ausgabe von
Wennsd mogst2, kannst du einen ausführlichen Selbsttest der disk anschmeißen
Das beeinträchtigt nicht den Betrieb (wenn sie nicht defekt ist) und währenddessen kannst du beliebig oft erneut mit
)
Wenns mogst3, wäre die Ausgabe vor/nach dem Test vielleicht aufschlußreich, ob da was verbogen ist.
smartctl -x -q noserial /dev/sdain eine .txt-Datei anhängen, dann kann man mal drüberschauen.Wennsd mogst2, kannst du einen ausführlichen Selbsttest der disk anschmeißen
smartctl -t long /dev/sdaDas beeinträchtigt nicht den Betrieb (wenn sie nicht defekt ist) und währenddessen kannst du beliebig oft erneut mit
smartctl -x -q noserial /dev/sda nach dem Fortschritt schauen (irgendwo läuft dann da eine %-Zahl und nein, auch das stört den Betrieb nicht oder bricht den Test ab )Wenns mogst3, wäre die Ausgabe vor/nach dem Test vielleicht aufschlußreich, ob da was verbogen ist.
Code:
4 Start_Stop_Count -O--C- 092 092 000 - 35103
12 Power_Cycle_Count -O--CK 092 092 000 - 34998
192 Power-Off_Retract_Count -O--CK 071 071 000 - 35130
193 Load_Cycle_Count -O--C- 071 071 000 - 35130Die sind verdächtig hoch und ähnlich, passen allerdings nicht zu einer Laufzeit von 4522 Stunden. Manche HGSTs fangen nach unterschiedlicher Laufzeit (55000 oder 65000) wieder bei 0 an und das ist hier auch erfolgt, lese ich von
0x01 0x018 6 22849624912 --- Logical Sectors Written ab.Das heißt so für sich zunächst mal nichts, jedoch sind diese Kopfparkvorgänge auch begrenzt und sind Verschleiß. Muss man dann mal gucken, wie stark das in der Zeit ansteigt bis zum anderen log.
Code:
# 1 Extended offline Aborted by host 90% 4522 -Ansonsten:
Power_Cycle_Count Differenz nach ~13h: 85
Load_Cycle_Count Differenz nach ~13h: auch 85
Das ist brutal viel und geht aufs Material. HGST SAS sagen oft, dass sie 50.000x Power_Cycle_Count wegstecken können "sollen" und bei der Load_Cycle_Count 600.000, je nachdem was zuerst kommt.
Es sagt auch, dass eine Proxmox-Systemplatte nie nicht genutzt wird...vielleicht war das der Absturzgrund, dieses dauernde sleep/wieder anfahren, das geht lange gut, aber geht aufs Material und du hast nichts davon.
Wenn irgendwie möglich, würde ich da den sleep einfach deaktivieren und hoffen, dass die Platte dann noch ein Weilchen durchhält.
Danke für die einschätzung
Och weißt du... Das ding ist erst 10 Monate alt.
Wenn das jetzt schon so probleme macht, schick ich das ding zurück und hol mir was besseres
Hab da auch schon was schönes rausgesucht
Das wird nicht an der Platte liegen, ich habe mehrheitlich HGST im Einsatz, die sind top (auch wenn ich noch keine habe, die bereits unter der WD-Flagge segelt). Oft macht das auch einfach der USB-Controller oder wie das angebunden ist, weil der Hersteller davon ausgeht, dass der Benutzer das nur als externen Speicher an einem Windows nutzt und da ist aggressives spindown/sleep unproblematisch.
Das steht natürlich nie in den specs, also möglicherweise stehst du bei Tausch vor dem gleichen Problem.
Das steht natürlich nie in den specs, also möglicherweise stehst du bei Tausch vor dem gleichen Problem.
Ich würd halt auf so externe HDD Gehäuse gehen und eine NAS HDD reinklatschen. Wenn das Gehäuse da versagt, isses nicht ganz so schlimm...
Wir reden da aneinander vorbei glaube ich.
Der Controller im Gehäuse (egal welche Bauart), setzt bei den Festplatten (egal welche du reinpappst) dieses spindown/sleep flag (wenn er es setzt).Es macht nicht jeder Controller, aber du kannst nicht danach suchen und das vorm Kauf rausfiltern, das ist ja das blöde.
Am besten wäre es, wenn man Gehäuse von drei verschiedenen Herstellen besorgt und dann schaut, ob die das flag (APM) setzen oder nicht. Die, die es machen dann zurückschicken.
On top kommt noch dazu, dass nicht jede Fesplatte das APM dauerhaft abspeichert (das ist dann in der firmware nicht zugelassen und resettet sich bei Kaltstart)
...
Also man kämpft da eigentlich gegen zwei Probleme.
Stell dir vor, du schließt eine neue Festplatte direkt mit SATA/AHCI an deinem Board an. Im eher ungünstigen Fall hat die Firmware der Platte APM von 128. Das heißt Kopfparken, aber zumindest kein spindown/deep sleep. Mit
hdparm lässt sich das umstellen (APM254 heißt dauerhaft laufen und das will man im Serverbetrieb) und mit Glück auch abspeichern. Man testet das nun mittels Kaltstart und wenn das danach immer noch auf APM254 steht, hast du gewonnen und die Firmware erlaubt das Speichern.Nichtsahnend baust du nun die korrekt eingestelle Festplatte in irgendein externes Gehäuse, weißt aber nicht, dass der Controller da drin ungefragt und ausschließlich APM64 oder gar noch aggressiver setzt...und das sind Dinge, die kann man dann nicht abdrehen.
Last edited:
Ich hab mir mal dieses Gehäuse bestellt und werde dann mal schauen wie die APM dabei ist
https://amzn.eu/d/9zAfHxc
https://amzn.eu/d/9zAfHxc