Unterschied NFS / SMB für Aufnahmen auf NAS

GaborDenes · 6. Mai 2023, 11:25

Hmm, ich denke, das Problem ist zu komplex, um es über ein Forum zu klären, dazu muss man mMn vor Ort sein.
Da der Workaround mit SMB offenbar gut funktioniert, würde ich es dabei belassen., auch wenn das sehr unbefriedigend ist.

Dieter59 · 6. Mai 2023, 17:29

Ich habe meine Synology auch per NFS an meine Uno4kSE angebunden und habe bei Aufnahmen, die ich direkt dorthin mache, immer reproduzierbare Aussetzer bei der Wiedergabe. Ich nehme jetzt auf meine interne SSD auf und verschiebe dann per Automove Plugin auf das NAS.Da gibt es -fast- keine Probleme mehr. Ich werde direkt nach meinem Urlaub mal die Anbindung auf SMB umstellen.

@GaborDenes wieso ist für Dich SMB ein Workaround? Wenn es zw. VU und NAS funktioniert, ist SMB nicht schlechter oder besser als NFS. Oder sehe ich da was falsch?

RickX · 6. Mai 2023, 17:57

Sehe ich genau so. Wenn SMB funktioniert, gibt es keinen Grund, auf NFS umzustellen.

GaborDenes · 6. Mai 2023, 20:54

Dieter59 schrieb:

wieso ist für Dich SMB ein Workaround?

Der TE möchte aufs NAS aufnehmen über NFS, das produziert Fehler, somit ist CIFS der Workaround
Grundsätzlich spricht nichts gegen die Verwendung von CIFS, außer persönlichen Vorlieben. Ich habe in meinem LAN auch soweit es geht nur NFS im Einsatz, insbesondere dort, wo unixoide Betriebssysteme in Verwendung sind, denn dort ist NFS die natürliche Umgebung

wi-tom · 7. Mai 2023, 00:24

Guten Abend zusammen, ich habe neue Testergebnisse...
Nach tagelanger Untersuchung in meinem Netzwerk ohne nennenswerte Erkenntnisse habe ich mich nun doch noch dazu entschlossen sowohl die VU+ Box(en) als auch die Software als "Fehlerquelle" nicht mehr generell auszuschließen. Schließlich habe ich auch nur in dieser Verbindung Probleme mit Aufnahmen.

Bevor ich mein nächstes Testergebnis berichte möchte ich klarstellen, dass ich zum VTI-Image stehe, dessen "Usability" mehr als schätze und auch nicht tauschen möchte.
Dennoch komme ich nicht darum herum, dass ich in 2 Tests mit 2 "anderen" (nicht VTI) Images in gleichem Setup keine Probleme bei den Aufnahmen habe...

Natürlich habe ich als nächstes versucht herauszufinden "warum" das so ist, und habe zunächst überprüft mich welchen NFS-Mechaniken das VTI-Image und die anderen Images den "mount" durchführen. Soviel vorweg - alle Images verwenden "Busybox". Aber hier unterscheiden sich leider auch die Images voneinander:
Beide anderen Images verwendeten bei Buxybox die Version 1.35.0, wogegen das "aktuellste" (VTi_15-0-02_vusolose_202212231314_usb.zip) VTI-Image lediglich v1.23.2 verwendet. Ob das einen relevanten Unterschied macht kann ich nicht sagen. Meine Testergebnisse sagen aber, dass ich - in meinem Setup - das VU+ Image nicht mehr ausschließen möchte.

Aus diesem Grund möchte ich - auch wenn es nicht gern gesehen wird - ein Direktzitat nutzen:

hgdo schrieb:

Ich habe eben Das Erste HD per CIFS und ZDF HD per NFS mehrere Minuten lang gleichzeitig von meiner Duo 4K SE (LAN mit 1GBit/s) direkt auf meinem Qnap aufgenommen. Bei Kontrolle der Aufnahmen konnte ich keinerlei Fehler feststellen. Ein Problem mit VTi bei NFS schließe ich daher aus.

Nun, ich kann dir an dieser Stelle nach meinen Testergebnissen berichten, dass in einfachen Setups, und auch bei Direktverbindungen keine Probleme auftreten und VTI damit kein Problem hat - in etwas anderen Setups aber scheinbar schon. Wäre es zu viel verlangt hier doch noch mal Blickwinkel zu erweitern? Ich weiß nicht ob ich Recht habe mit meiner Annahme - aber wäre es denn keinen Versuch Wert die Busybox Version im VTI-Image zu erhöhen?

PS: Und wenn es keine Umstände macht, wäre ein Update am OpenSSH auch nicht schlecht (ssh outdated -> Update Request)

Sledge · 7. Mai 2023, 12:20

Hallo @wi-tom,

schön, dass Du das Thema noch ein wenig weiter vorantreibst.

Ich hatte vor ca. 3-4 Jahren mal die Situation die Aufnahmen aus Platzgründen direkt aufs NFS-Share eines Synology NAS (keine SMR Platten) vorzunehmen. Die meisten Aufnahmen waren dabei nicht 100% intakt. Das ließ sich im Nachgang am schnellsten mit TS-Doctor o.ä. Tools prüfen, alternativ natürlich beim Anschauen mit Pixelgewitter und kompletten Aussetzern. Genauso wie Du es beschreibst, muss da schon während der Aufnahme ein Problem bestanden haben. Aufnahmen auf die lokale Platte waren nicht betroffen. Es handelte sich um eine VU+ Duo2 und ein CI+ Modul war während der Aufnahme aktiv. Danach habe ich das nicht mehr näher untersucht, weil in der Konstellation nicht gebraucht.
Klingt für mich so, als ob wir diesen Effekt über mehrere Generationen von Hardware u. Images mitschleifen.

Busybox kann ich mir noch nicht so recht als Ursache vorstellen, aber wer weiß - muss man ausprobieren. Aus meiner Sicht sind das Aufgaben des Kernels bzw. Kernelmodule den NFS mount mit Daten zu beliefern und die Verbindung aufrecht zu halten. Die Busybox ruft das ganze nur initial aus dem user space auf. Sollte danach natürlich ein Handle, Thread offen bleiben... :huh:

anudanan · 7. Mai 2023, 12:49

Ich habe mal in die changelogs von busybox geschaut und kann da bei der suche nach NFS oder mount nicht wirklich Kommentare finde, die irgendwie danach klingen, dass die mit dem Thema zusammenhängen.

Sind denn die Mountparameter beim vti und dem anderen Image bei den NFS Mounts gleich, also die Puffer usw.?

GaborDenes · 7. Mai 2023, 13:08

wi-tom schrieb:

Wäre es zu viel verlangt hier doch noch mal Blickwinkel zu erweitern

Ich denke, die wenigsten Heim-Anwender haben ein auch nur annähernd komplexes Setup im LAN, die meisten werden einen Router (evtl. plus Switch) und eine Handvoll Kabel haben und damit glücklich sein. Da zähle ich mich dazu.
Als IT-Administrator in einem großen, produzierenden Werk, weiß ich wie schnell die Komplexität im LAN kaum vorhersehbare Schwierigkeiten verursachen, trotz Planung und Tests im Vorfeld.

Sledge · 7. Mai 2023, 13:53

@GaborDenes,

ich verstehe worauf Du hinauswillst. Momentan sehe ich aber bei den Meldungen (waren auch in anderen Threads Hinweise darauf) die sich mit dem gleichen Problemen herumschlagen bzw. herumgeschlagen haben, nicht das komplexere Netzwerkkonstrukt bei wi-tom als Ursache. Im meinem konkreten Fall gab es auch nur VU+ -> unmanaged Switch -> FRITZ!Box -> NAS.

Nach aktuellem Kenntnisstand konnte er das Auftreten sogar auf das VTi-Image einschränken.

@wi-tom,

in den anderen (nicht VTi) Images, welche Kernel-Version ist dort im Einsatz? Ist dort auch autofs installiert und automount als Prozess dauerhaft aktiv?

anudanan · 7. Mai 2023, 14:03

Ich meine mich zu erinnern, dass die Kernelversionen bei allen Images bezogen auf eine bestimme VU Box immer dieselbe ist, weil das BSP von VU einen bestimmten Kernel mitbringt bzw. voraussetzt. Ich hatte das mal gesehen, als ich meine uno4kse mit vti, openpli und openatv ausprobiert habe. Die Imagebauer können nicht selber so einfach den Kernel bei einem BSP austauschen, ist zumindest mein Kenntnissstand

VU modernisiert die Kernelversionen auch nie wirklich. Als .z.B. die uno4k rausgekommen ist, wurde dort ein bestimmter Kernel verwendet. Als dann etwas später die uno4kse rauskam, die ja ziemlich verwandt ist von der Architektur, bekam diese einen neueren Kernel, aber die uno4k ist meiner Info nach immer auf ihren Anfangskernel geblieben, obwohl eine Modernisierung sicherlich recht einfach gegangen wäre.

Wie die anderen Boxen-Hersteller das machen, kann ich nicht sagen.

GaborDenes · 7. Mai 2023, 17:27

Sledge schrieb:

Nach aktuellem Kenntnisstand konnte er das Auftreten sogar auf das VTi-Image einschränken.

Eingeschränkt hat er das Auftreten schon auf viele Ursachen, aber jedesmal wieder verworfen

was sicher der Komplexität seines LAN geschuldet ist. Meine Berufserfahrung zeigt, das solche Fehler gerne plötzlich auftreten und kaum anaIysierbar sind.
Aktuelles Beispiel aus unserem Werk ist ein Druckservice, der Daten aus der Mainframe-Umgebung über Windows-Printserver druckt und mehrfach am Tag stehenbleibt. Da sind unsere Entwickler und der Hersteller schon seit Wochen beschäftigt, die Ursache zu finden und zu beheben. Es gibt fast wöchentlich neue Treiber und Module, die im Testsystem funktionieren und im Livebetrieb dann nicht mehr.
Aktueller Workaround ist es den Server, auf dem der Dienst läuft, bei Bedarf neu zu starten

Die NFS-Unterstützung kommt m.W. aus dem Kernel und nicht von enigma, da würde es mich wundern, wenn unterschiedliche Images mit dem gleichen Kernel zu unterschiedlichen Ergebnissen führen.
Wie gesagt, ich würde es bei der nicht befriedigenden Lösung belassen und CIFS verwenden, für wochenlange AnaIyse fehlte mir die Zeit und die Motivation, zum Zeitverschwenden habe ich viele andere Projekte und Möglichkeiten... Aber das macht jeder, wie er es für richtig hält, ich kann den Ehrgeiz, von @wi-tom verstehen, das Problem zu lösen, mir wäre das nicht genug Problem

wi-tom · 7. Mai 2023, 22:51

Hallo zusammen,

zunächst einmal war meine Begründung "Busybox" in Verdacht zu bringen rein spekulativer Natur. Das war nun mal das erste was ich in meiner "Testergebnis-A n a l y s e" feststellen konnte. Wenn "Busybox" ausgeschlossen werden kann hab ich damit kein Problem. Die Antwort auf die Frage mit den NFS Parametern (Puffer-Größen, etc.) kann ich auch noch nachreichen, kein Problem.

Was den Kernel betrifft - ist dieser (zumindest laut Version) in allen Images identisch (3.13.5 mips GNU/Linux). Soweit ich weiß kann nur der Hersteller und v.a. wg. der entsprechenden Treiber auf einen neuen Kernel wechseln - das haben die "Image-Bauer" nicht in der Hand.

Was mein Netzwerk-Setup betrifft, hab ich bereits erwähnt, dass ich hier in der Ausbaustufe ein komplexeres Netz habe. Aber zu dieser A n a l y s e und zu meinen "Testszenarien" habe ich alles in ein und das selbe Netz (und auch ohne VLAN-spezifischen "Tags", etc.) gesteckt. Somit müsste dieses Test-Beispiel einem "normalem" Netzwerk entsprechen - allerdings mit mehreren Servern und damit auch mehreren Services (NAS, Domain Controller, TVHeadend Server, Plex Server, Software PBX, etc. - natürlich zeitgemäß virtuell auf ESXI Basis.

@GaborDenes, auch ich habe meine beruflichen Kompetenz in der IT - und das ebenfalls in einem größeren Konzern mit mehr als 10.000 Beschäftigten. Meine Erfahrung mit IT-Netzwerken (inkl. LAN/VLAN, Rechenzentren, virt. Server, etc. sowie Diplom-Studium und jahrzehntelanger Softwareentwicklung) - Mittlerweile beschäftige ich mich aber nicht mehr so sehr mit Netzwerken, Betriebssystemen, etc. sondern eher in Richtung "industrielle" Digitalisierung. - an dieser Stelle sind wir aber ebenfalls wieder sehr weit OT.

Um zum Topic zurückzukommen:
Ja, entweder mein Netzwerk-Setup oder vielmehr die Komponenten (Server, etc.) innerhalb des Netzwerks "verursachen" die Störung, die VU+ selbst bei der Aufnahme - oder eine Kombination aus Beidem.
Meine ergänzenden Tests mit "nicht-VTI" Images haben mich allerdings dazu gebracht den Fehler nicht mehr allein auf mein Netzwerk/Server, etc. zu beschränken - sondern eben auch die VU+ und damit auch - so ungern ich es sagen mag - auch dem VTI Image hinzuzuziehen.
Eine Einschränkung auf das "VTI-Image" ist das aber definitiv nicht. Auf der anderen Seite kann ich unter diesen Gegebenheiten nicht mehr sagen das VTI-Image "ist es nicht" - zumindest ist es an dieser Situation beteiligt.

Wie auch immer, sofern alle Images den gleichen Kernel verwenden, Busybox keine Rolle spielt - was kann sonst noch eine Ursache für die Aufnahmefehler sein? Evtl. liegt es auch gar nicht am "Netzwerk" selbst, sondern in der Art wie der Datenstrom verarbeitet wird und dann per NFS auf dem Server landet?

@GaborDenes bzgl. meines Ehrgeizes - ich finde es falsch wenn man sich ständig nur mit "Workarounds" beschäftigt, das kenne ich genug aus meiner Arbeitswelt, hier wird ständig mit Workarounds gearbeitet - und auch mit aus meiner Sicht sinnlosen Hotfixes die die Wurzel des Übels nicht entfernen sondern nur Symptome bekämpfen. Was mich betrifft - ja ich hätte einen Workaround und jeden erdenklichen Grund an dieser Stelle zu sagen "warum noch weiter suchen"... (CIFS/SMB verwenden - oder gleich auf anderes Image schwenken)
...ich denke nur das hier ist ein Forum, in dem sich die Mitglieder - und auch Entwickler austauschen können und auch Probleme lösen (wollen) - wieso sollte man dann ansonst überhaupt in diesem Forum mitwirken?

wi-tom · 9. Mai 2023, 00:04

So, habe nun die zuvor ausgewählten 3 verschiedenen Images + ein weiteres Image auf die Box geladen und jeweils sowohl Kernel-, Busybox-Infos sowie NFS Mount-Parameter geprüft. Ebenfalls habe ich bei jedem Image erneut eine Aufnahme unter "Initial-Setup" Bedingungen + NAS-Anbindung per NFS gestartet.
Hier das Ergebnis...

Image 1 (VTI):
Bildschirmfoto 2023-05-08 um 23.23.49.png
Aufnahme: fehlerhaft

Image 2 (nicht-VTI):
Bildschirmfoto 2023-05-08 um 21.05.47.png
Aufnahme: ohne Fehler

Image 3 (nicht-VTI):
Bildschirmfoto 2023-05-08 um 21.44.17.png
Aufnahme: ohne Fehler

Image 4 (nicht-VTI):
Bildschirmfoto 2023-05-08 um 22.09.09.png
Aufnahme: ohne Fehler

Ich habe nun die NFS-Parameter im Mount des VTI-Images angepasst wie folgt und eine neue Aufnahme gestartet (läuft aktuell noch...):
rw,nolock,tcp,rsize=8192,wsize=8192,soft,timeo=14,retrans=2

Ergebnis lasse ich euch mitteilen wenn ich neue Ergebnisse habe...

wi-tom · 9. Mai 2023, 12:35

Ergebnis der Aufnahme mit geänderten NFS-Parametern: Aufnahme immer noch fehlerhaft.

anudanan · 9. Mai 2023, 12:45

Vielleicht sorgen die Puffer von 8Kbyte für eine gleichmäßigere Datenübertragung zum NAS als die 1Mbyte Puffer. 1Mbyte Puffer würde ja ungefahr bedeuten, dass immer nur einmal pro Sekunde bei einer HD Aufnahme ein 1Mbyte Block an einem Stück weggeschrieben wird. Vielleicht ist das zu burstartig.

Wenn es daran liegt, müsste es auch reichen, nur den Schreibpuffer zu verkleinern.

wi-tom · 9. Mai 2023, 13:35

Ich habe nun einen weiteren Kandidaten "unter Verdacht". Eine kurze Probeaufnahme scheint ohne Fehler gelaufen zu sein... Der nächste Test ist eine längere Aufnahme...

Was hab ich getan?
Wieder alles auf "Anfang":
1. Image neu aufgespielt
2. Basiseinstellungen vorgenommen
3. nfs-utils-client installiert (neu, hatte ich bisher nicht - ob das einen Unterschied macht weiß ich nicht)
4. NFS als Laufwerk angebunden (autofs)
5. Aufnahme gestartet -> Ergebnis: Fehlerhafte Aufnahme
6. NFS Laufwerk entfernt und neu angebunden (dieses mal "klassisch")
7. Aufnahme gestartet -> Ergebnis: Aufnahme ohne Fehler

anudanan · 9. Mai 2023, 13:40

Sind die Mount Parameter beim autofs und klassisch unterschiedlich?

wi-tom · 9. Mai 2023, 14:31

Ja, es gibt Unterschiede in rsize und wsize:Bildschirmfoto 2023-05-09 um 14.29.53.png
...allerdings hatte ich diese im vorherigen Test ja auch bei autofs auf diese Werte gesetzt und trotzdem Fehler in den Aufnahmen erhalten

So, leider hat sich mein "neuer Verdacht" nicht bestätigt. Hab lediglich "weniger" Aufnahmefehler in einer Aufnahme bei gleicher Länge (1h Aufnahme). Einzige Erkenntnis wäre in diesem Fall, dass bei geringerer rsize/wsize die Fehler "weniger oft" auftreten - trotzdem aber noch vorhanden sind.

anudanan · 9. Mai 2023, 14:34

Ah, das hatte ich nicht mehr gesehen, sorry

Sledge · 9. Mai 2023, 21:22

@wi-tom

ich kann die Probleme hier bei Aufnahmen mit NFS auch nachvollziehen. Mit autofs die Aufnahmen gehen bei mir aktuell in die Hose. Vorhin hatte ich 3 Aufnahmen gezielt mit anderen Parametern + klassisch gemacht, die waren fehlerfrei. Das ist leider noch kein Hinweis darauf, dass es die Ursache ist. Aktuell laufen weitere Aufnahmen. Wenn wir auf Kernel-Ebene und Unterschiede der Images Richtung Puffer oder ähnliches weiterforschen wollen, sollten wir uns auch mal die Ausgaben von "sysctl -a" vornehmen.

Für den Fall Du willst die gleichen NFS Einstellungen probieren:

klassisch
rw,tcp,nolock,nocto,actimeo=600,timeo=600