Video Directory Scanner meldet Eingabe-/Ausgaberfehler für über NFS eingebundene Aufnahmen

Mittlerweile habe ich noch einen ganz anderen Verdacht: Kann es sein, dass der alte Server (Intel Pentium 4 541 3.20 GHz) für das Testsystem (Xeon E3-1226 v3 3.30 GHz) schlicht zu langsam liefert? Denn der Server wird nicht nur durch das Software-RAID belastet. Mehr Rechenleistung erfordert sicherlich mein selbstgeschriebenes vdrffs, das mittels FUSE die Partitionen des historischen verteilten VDR-Dateisystems zu einem zusammenfasst, das leicht per NFS exportiert werden kann. Für die RPi-2 MLD-Clients erfüllt vdrfffs seinen Zweck, aber die sind ja auch selbst hübsch langsam.

Quote from SurfaceCleanerZ

Du kennst das distributedvideodir Plugin?

Ja, das Plugin ist auf dem Server auch im Einsatz.

Im Unterschied zum distributesvideodir-Plugin ist vdrffs ein virtuelles Dateisystem. Damit kann ich ein in sich geschlosses Dateisytem exportieren, das die Partitionen des alten VDR-Dateisystems zusammenfasst. Es ist mir nämlich nie so recht gelungen, die einzelnen Partitionen so per NFS zu exportieren, dass die Links zwischen den Partitionen auf Client-Seite wieder funktioniert hätten. Außerdem erspart vdrffs die Rekonfiguration auf Server und Client, wenn eine Partition hinzukommt oder wegfällt. Und das distributedvideodir-Plugin gab es - zumindest damals - unter MLD nicht.

Wenn ich wüsste, wie ich die einzelnen Video-Partitionen des Servers exportieren und auf dem Testsystem so importieren kann, dass die Links funktioneren, könnte ich auf dem Testsystem das distributedvideodir-Plugin benutzen und müsste nicht das vdrffs-Dateisystem des Servers benutzen.

Quote from SHF

Es könnte durch das Setup sein, dass einfach zu viele Dateien auf einmal geöffnet sind.

Sehr gute Idee! In der Tat meldet nfsd auf dem Server den Fehler 24 ('Too many open files'), wenn auf dem Testsystem die Eingabe-/Ausgabefehler anfangen. Dass ich da nicht schon viel früher hingeschaut habe ...

Ich habe daraufhin testweise das Soft-Limit für den vdrffs-Prozess von 1024 auf 4096 erhöht:

root@spiro:~# prlimit --nofile --pid $(pidof /sbin/mount.vdrffs)
RESOURCE DESCRIPTION              SOFT HARD UNITS
NOFILE   max number of open files 1024 4096 files
root@spiro:~# prlimit --nofile=4096 --pid $(pidof /sbin/mount.vdrffs)
root@spiro:~# prlimit --nofile --pid $(pidof /sbin/mount.vdrffs)
RESOURCE DESCRIPTION              SOFT HARD UNITS
NOFILE   max number of open files 4096 4096 files

Und beim nächsten Start des Testsystem gab es keine Fehler mehr, hurra!

Leider weiß ich noch nicht, wie ich die Änderung am besten über den Neustart rette. Die von SHF verlinkte Anleitung und andere, die ich gefunden habe, beschreiben - soweit ich sie richtig verstanden habe -, wie man Begrenzungen für einen Benutzer oder einen Dienst dauerhaft ändern kann. Ich würde sie ja gerne für ein Programm ändern. Sicherlich könnte ich ein Skript schreiben, das nach mount läuft und letztlich obigen Befehl ausführt. Besser wäre wohl eine zusätzliche mount-Option, die das Limit mittels setrlimit(2) ändert. Aber vielleicht gibt es noch einen eleganteren Weg?

Ich habe vdrffs um eine zusätzliche Mount-Option nofile (in Anlehung an prlimit(1) bzw. prlimit(2)) ergänzt. Seit ich die auf 4096 (statt des Standwerts 1024) gesetzt habe, tritt der Fehler nicht mehr auf.

/sbin/mount.vdrffs ist ist ein Verweis auf das eigentliche Programm /bin/vdrffs. Diesen Eintrag benutzt mount, wenn /etc/fstab einen Eintrag enthält, der als Typ des Dateisystems vdrffs angibt.