Hi clausmuus,
vielen Dank für die schnelle Antwort.
1. meine watchdog ist extrem primitiv. Weil in /sys inotify nicht funktioniert muß man pollen. Ich teste in /sys den Status des HDMI-Ports, ändert sich der Zustand, wird xorg einfach durchgestartet. Das ist extrem primitiv, funktioniert aber soweit. Das Ding hab ich in 5 Minuten hingeschlampt, aber es zeigt vielleicht einen Ansatz wie es gehen könnte. Mir gefällt das Pollen nicht, aber auf die Schnelle kenne ich keine bessere Lösung. Der Fernseher (genauer AV Receiver) hängt am HDMI-2:
#!/bin/sh
function restart_X {
/etc/init.d/xorg restart
}
function check_HDMI {
if [ -f /tmp/constat ]; then
old=$(cat /tmp/constat|head -n 1)
current=$(cat /sys/class/drm/card0-HDMI-A-2/status)
if [ "$current" != "$old" ]; then
restart_X &
fi
fi
}
while [ 1 ]; do
current=$(cat /sys/class/drm/card0-HDMI-A-2/status)
case $current in
connected)
check_HDMI
;;
disconnected)
check_HDMI
;;
esac
sleep 10
echo $current >/tmp/constat
done
Das ganze starte ich im Hintergrund. Also nicht wirklich was Vorzeigbares
2. Nein, bisher habe ich den Grund nicht identifizieren können. Die Änderung ist eine Zeile, wenn das Problem sonst nicht auftritt, macht es keinen Sinn dafür Aufwand zu treiben.
3. Also, die regelmäßigen ext fs checks gehören eigtl der Vergangenheit an und sind per default deaktiviert. Was die xfs Problematik angeht muß ich ein wenig ausholen: wegen der höheren Performance und weil Cloud-Infrastrukturen wie OpenStack darauf setzen, wird aktuell xfs gerne bevorzugt. Mit SSD spielt das Problem Hardwarefehler faktisch keine Rolle, die sterben meist sofort total. Spindeln dagegen sterben meist langsam, und man hat z.T. Wochen zeit für die Reperatur. Ext4 versucht eine defekte Platte am Leben zu erhalten, was die Performance u.U. ins Bodenlose senkt, aber gewöhnlich bleibt es am Leben. XFS stirbt sofort bei Erkennen eines Hardwaredefektes. Ich arbeite beruflich mit Linux, hier nur eine Erfahrung aus einer Reihe als Beispiel: zwei 2TB Platten im LVM linear mit xfs. Eine Platte bekommt Sektorfehler. XFS geht auf read-only. Der Hardwarefehler hat aber bereits die Datenstrukturen betroffen, ein Kopieren der Dateien daher nicht mehr möglich. xfs_repair verweigert jeden Reparaturversuch mit Hinweis auf den Hardwarefehler. Lösung: neue Platte rein, mit vgextend in den LVM, mit pvmove die erhaltenen Daten auf die neue Platte, durchbooten, und xfs sortiert sich automatisch. Deshalb mein Tipp: xfs nur mit raid oder LVM-Unterbau, direkt auf der Hardware hat es keinerlei Toleranz bei Hardwarefehlern. Ich vermute, dass Redhat das Problem angehen wird, sie wollen xfs ja zu einem zweiten btrfs machen
Ich hatte im letzten Jahr mehrere defekte Festplatten (Spindeln) bei Kunden und Freunden. Eindeutige Erfahrung: ext4 bleibt am Leben, man kann die noch erhaltenen Daten retten und in Ruhe reparieren, XFS sperrt den User beim ersten Hardwarefehler aus, mit dem Risiko das bei defekten Dateisystemstrukturen kein Backup mehr möglich ist.
Apropos Performance: ich spiele seit Monaten mit btrfs. Bei einem einfachen, initialen Test ohne Optimierungen auf NAND SSD haben xfs und ext4 in Basiskonfiguration 500MB/s - 1GB/s geringere Schreibrate. Mal sehen was passiert, wenn meine erste SSD stirbt
Die konkreten Daten: M.2 NAND SSD, Samsung EVO, technisch 3,3GB/s Schreibrate. XFS und ext4 liegen mit bonnie nahe beieinander bei Spitzenwerden von ca 2,5GB/s Schreibrate. BTRFS kommt auf ca 3GB/s mit einem Device, die man durch zusätzliche Devices auf 3,5GB/s steigern kann (gemessen auf einem Dell Precision Notebook).
Das also nur als Anregung. Ein MLD ist bei defekter HW schnell wieder aufgebaut, allerdings hat mir der LVM-Trick im letzten Jahr ca 3TB TV-Aufnahmen gerettet, die ohne LVM schlicht verloren gewesen wären, weil ich natürlich keine Backups von Fernseh-Aufnahmen mache ...
dkj
Users Online