Fragen zu HDMI, VDR Neustart und Dateisystem

MLD-5.x > General

(1/3) > >>

dkj:
Hallo Leute,

zuerst einmal: ich bin hier ganz neu. Ich habe lange Erfahrung mit Linux, und betreibe meinen VCR seit Jahren mit diversen VDR-Distributionen. MLD gefällt mir vor allem, weil sie sehr klein ist, sehr aktuell und sehr funktional. Die exzellente Konfiguration über das Webinterface stellt eine ganze Menge Software, nicht nur andere VDR-Distris in den Schatten. Ich habe definitiv vor, MLD auf Dauer zu benutzen.

Nun habe ich hier ein paar Fragen. Ich habe das Forum daraufhin durchsucht, bin aber nicht fündig geworden (evtl übersehen). Vielleicht kann mir hier ja einer da weiter helfen :)

Hier die Fragen/Vorschläge:

1. Mein Mainboard schaltet den HDMI-Ausgang nicht ein, wenn beim Booten kein Monitor oder Fernseher eingeschaltet ist. Startet mein VDR also über Timer, so habe ich, wenn ich danach den Fernseher einschalte, kein Bild. Nun kann ich zwar über das Webinterface xorg einfach neu starten, aber ich habe das mit einer kleinen shell-watchdog automatisiert, das ist einfach komfortabler. Gibt es dazu Gedanken?

2. Mein VDR startet schon immer aus irgendeinem Grunde immer erst beim zweiten Start korrekt. Versuche wie die Module manuell laden etc waren bisher erfolglos. Das Problem wird auf diversen Foren wiederholt berichtet. Ich habe in das Startskript ein "runvdr -r" eingefüht, seitdem geht es. Gibt es da eine elegantere Lösung bzw eine eigene Konfigurationseinstellung?

3. Bei dem verwendeten XFS-Dateisystem kenne ich eine Reihe Probleme, die ich in der Praxis nur durch einen Unterbau aus LVM, Raid oder SAN-LUN umgehen kann. So schaltet xfs auf irreversiblen read-only, wenn es hardware Fehler erkennt (eigene Erfahrung). Ein Grund weshalb ich xfs nicht auf einer Systempartition betreiben würde. BTRFS kann theoretisch mehr, mir fehlen aber Erfahrungen mit Festplatten-Defekten. Ext4 ist das einzige FS, dass ich selbst bewußt kaum kaputt kriege und das sich selbst von Hardwarefehlern kaum aus der Ruhe bringen läßt. Gibt es zu diesem Problem hier Erfahrung?

Wäre toll, wenn jemand zu den drei Punkten etwas sagen könnte :)

dkj

clausmuus:
Hi,

Willkommen an Bord!

1) Du kannst im Setup "Bildschirm merken" aktivieren. Dann werden beim xorg Start die Parameter Deines Bildschirmes aus einer edid Datei geladen. Das hilft bei fast allen Usern. Trotzdem wäre ich an Deinem watchdog Script interessiert.
2) Das Problem hatte vor Dir nur ein einziger User berichtet. Die Ursache des Fehlers konnten wir aber nicht ergründen. Falls Du da mehr weißt würde mich das interessieren. Da dies Problem aber so selten auftritt wollte ich da nichts fest einbauen.
3) Ich habe in den letzten 15 Jahren noch von keinem User gehört, das es Probleme mit dem xfs Dateisystem gab. Auf defekte Hardware haben bei mir bisher alle Dateisysteme gleichermaßen allergisch und unreparierbar reagiert. xfs hat den Vorteil, dass es bei großen Laufwerken und großen Dateien am performantesten ist. ext4 braucht regelmäßige Dateisystem checks, die meines Wissens im ausgehängtem Zustand (also beim booten) durchgeführt werden müssen. Obendrein kann dies bei großen Laufwerken durchaus Stunden dauern, was für ein Mediacenter unakzeptabel ist. xfs führt diese checks und nötige Reparaturen ständig im Hintergrund durch.

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

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

--- End code ---

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

MLD-Tux:
Moin, moin

und willkommen hier im Forum (wir hatten ja schon das Vergnügen ;D).
Zu eins kannst du auch gerne hier (https://www.minidvblinux.de/forum/index.php/topic,9446.msg74073.html#new)mal mitlesen. Da haben wir exakt dein Problem zwischen.
Wäre interessant deine Hardware Kombi zu kennen (vielleicht sehe ich die Sig wegen dem Smartphone aber auch nicht).
Zu dem FS und XFS kann ich Claus nur beipflichten.
Ich habe das lange Zeit auf meinem Desktoprechner erfolgreich eingesetzt und kann nicht wirklich beantworten, warum jetzt nicht mehr.
Auf jeden Fall kann ich nur positives dazu sagen, aber die Stärken liegen m.M.n. Bei großen Files.
Ich hatte das früher bei meinem ersten VDR, der mit eTobi Paketen zusammengebaut war, auch als FS für die Datenpartition genutzt. Alles super.

Viel Spaß noch!

clausmuus:
Hi dkj,
Danke für die Ausführliche Beschreibung zu den Dateisystemen. Da meine ausgibigen Recherchen zu dem Thema schon einige Jahre alt sind, schaue ich mir das ext4 noch mal genauer an. Kann sein, dass es damals ext4 noch gar nicht gab, und ext3 ist wirklich nicht der Hit im Vergleich zu xfs.
btrfs hat in den letzten Jahren einen ordentlichen Performance Schub, besonders bei großen Dateien erhalten und ist inzwischen sogar schneller als xfs. Allerdings ist xfs insgesamt ausgereifter und zuverlässiger. Deshalb nehmen wir btrfs nicht für die Daten. Und die besonderen btrfs Features brauchen wir auf dem Datenlaufwerk ja auch nicht.

Navigation

[0] Message Index

[#] Next page

Go to full version