Uno 4k Festplattenzugriff nicht stabil

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Uno 4k Festplattenzugriff nicht stabil

      Hallo,
      bin neu hier im Forum und hab Probleme mit meiner Uno4k, die ich mir vor ca. einem halben Jahr gekauft habe.

      Die Kommunikation mit der USB Festplatte (WD My Passport, 1TB) bricht immer wieder ab. Wenn ich die Box neu starte, wird die HDD erkannt und erscheint im Standardeinhängepunkt. Dann kann ich auf die vorhandenen Aufnahmen zugreifen und neue Timeraufnahmen programmieren. Wenn ich am nächsten Tag auf die Festplatte zugreifen möchte, wird die Platte nicht angezeigt. Erst nach dem Neustart der Box funktioniert es wieder.

      Habe aktuell VTI 13.0.2 installiert. Das Problem war im Herbst (ca. November) mit dem upgrade auf VTI 13 besser. Da waren die Abrisse nur ca. 1 Mal pro Woche. Jetzt im Januar auf V13.0.2 upgedated und die Abrisse werden wieder häufiger (nahezu täglich). Hatte die Box zunächst über die Box auf EXT4 formatiert und an der rückseitigen Schnittstelle angeschlossen. Zwischenzeitlich habe ich sie an die seitliche Schnittstelle angeschlossen und auf NTFS formatiert. Das Problem besteht weiterhin.

      Was mache ich falsch, bzw. ist die Box nur falsch parametriert oder macht das VTI Image Ärger?
    • Uno 4k Festplattenzugriff nicht stabil

      Hallo, mit meinem gefahrlichem halbwissen empfehle ich erstmal ext3 als format.
      hatte auch vorher 4 und dann nochmal nachgelesen nachdem ich probleme hatte auf 3 formatiert. 4 ist glaub ich ein altes Format welches bei älteren vti Versionen unterstützt wurde. ntfs wurde mir hier abgeraten.

      lg Sven
    • EXT4 ist auf alle Fälle das System der Wahl. Schreibt insbesondere optimiert große Dateien. Noch besser, wenn man EXT4 im data=writeback betreibt.

      Wenn die WD nicht sauber im längeren Betrieb läuft, würde ich auf einen Plattendefekt tippen. Bei Preisen von 50 Euro für eine nagelneue WD Elements 1 TB USB3 Platte, würde ich mich da nicht lange mit rum ärgern.
    • Da Du das Problem ja schon immer hattest, halt nicht so häufig, hat die Platte scheinbar irgendeinen hau. Auch ich würde Dir ext 4 empfehlen. Die Vu+ Boxen sind sehr wählerisch bei Speichermedien. Es kann durchaus sein, dass die Platte an anderen Geräten (PC, TV etc.) ohne Probleme läuft, nur eben nicht einwandfrei mit Deiner Box, da ggf. irgendwelche Kleinigkeiten nicht miteinander harmonieren. Evtl ist es ja der Energiesparmodus. Da kannst Du mal googeln, das kann ab und an auch zu stress führen, diesen kann man aber bei fast allen Platten deaktivieren.
    • senderlisteffm schrieb:

      EXT4 ist auf alle Fälle das System der Wahl. Schreibt insbesondere optimiert große Dateien. Noch besser, wenn man EXT4 im data=writeback betreibt
      Betreibst du deine HDDs mit data=writeback in der Box? Normalerweise wird ja überall in den Boxen data=ordered gemacht, zumindest ist das mein Wissenstand

      Hast du Vorteile bei den Enigmaboxen festgestellt, wenn man writeback nutzt?

      Theoretisch ist mir klar, was der Vorteil ist, aber ob sich das hier auswirkt, ist die Frage
    • Auf jeden Fall. Die Platte macht weniger Kopfbewegungen. Die Prozessorlast ist geringer und die Festplattentemperatur beim Schreiben von Timeshift ist bei mir um 2 Grad gesunken.

      Es gibt bei den Boxen keinen Grund nicht writeback zu nutzen. Und wenn tatsächlich mal Stromausfall ist, so what. Da das Journal in der Standardeinstellung maximal 5 Sekunden alt ist, fehlen halt diese 5 Sekunden im schlimmsten Fall.
    • danke für die Info

      meine HDDs habe ich mit BIG_ALLOC und 256K Clustern laufen, da sind die Kopfbewegungen eh deutlich weniger als bei 4K Cluster. Bei den großen Dateien sind 4K Cluster aus meiner Sicht unnötig und durch 256K wird der Verwaltungsoverhead deutlich reduziert. Der Verschnitt bei den kleinen Zusatzdateien stört da nicht wirklich.
      Ich hatte mal writeback dann noch probiert, aber keinen Unterschied bemerkt. Kann aber an den großen Clustern liegen
    • Den Verwaltungsaufwand minimiert doch gerade EXT4 durch die Anwendung von Extents. Durch die Option writeback gibt man dem System zusätzlich noch genug Zeit, möglichst große zusammenhängende Blöcke zu schreiben und Fragmentierung bereits beim Schreibprozess effektiv zu vermeiden.

      Im Gegenzug macht EXT3 bei den großen Dateigrößen und Partitionen richtig Verwaltungsaufwand. Im Idealfall muss bei EXT4 plus writeback nur alle 5 Sekunden das Dateiende im Extent angepasst werden, bis die 128 MB voll sind.

      Gerade in einem Streaminggerät spielt EXT4, mit kontinuierlich wachsenden und großen Dateien, seine Vorteile ideal aus.
    • Klar, Extents verbessern das Verwalten der Blöcke bei großen Dateien schon gut, es gibt aber durch bigalloc noch mehr Einsparungen bei der Verwaltungen der Block Bitmaps und anderen Strukturen, die dann einfach der CPU das Leben erleichtern und auch weniger RAM dafür brauche.
    • Ja, das stimmt,

      Das Problem ist genau, dass df im Laufe der Zeit den Speicher nicht mehr korrekt ausgibt, der frei ist. Auf der HDD ist alles ok, Ein umount und mount löst das dann wieder..

      Mit nodelalloc beim Mount ist das Thema erstmal umschifft
      Ich mache bei mir kein delalloc, ich habe durch viele Messungen keinen Unterschied zwischen delalloc und nodelalloc gemessen.

      Das Problem ist hier in Arbeit
      151491 – free space lossage on busy system with bigalloc enabled and 128KB cluster

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von anudanan ()

    • Du hast ja auch die Uno4kSE.

      Hast du mal versucht, viele Aufnahmen parallel zu machen, dann parallel mit CutListEditor und MovieCut Filme zu schneiden und dann parallel auch noch Filme über das Netzwerk auf ein NAS zu schieben?

      Bei mir hat das mit dem Kernel 4.1.20 mit allen möglichen Images (openPLI, openATV, vuplus, VTI) und mit verschiedenen internen und externen HDDs nicht geklappt. Dauernd Aussetzer in den Aufnahmen. Die Box war nicht mehr gut bedienbar. Meine Frau, die sowas dauernd macht, war ziemlich gefrustet, hatte ich ihr doch eine bessere Box versprochen als vorher.

      Erst eine Änderung des I/O scheduler von CFG auf DEADLINE hat das Problem nachhaltig gelöst. Die Box ist seit der Umstellung total unauffällig. Mit CFG haben die Schneider und Verschiebevorgänge die Aufnahmen so verdrängt beim Schreiben, dass die keine Chance mehr hatten.

      Es kann sein, dass nur Kernel 4.1.20 betroffen ist, weil eine ältere ET8200 von mit konnte das, die habe ich aber nicht mehr, da die Ethernetproblem in der Hardware hat.

      Im Rahmen dieser Analyse hatte ich das auch mit dem NODELALLOC ausgetestet.

      Ich werde meine mount jetzt doch nochmal mit writeback einstellen, mal sehen, ob ich etwas bemerke. Danke nochmal für den Tipp

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von anudanan ()

    • anudanan schrieb:

      Es kann sein, dass nur Kernel 4.1.20 betroffen ist.
      Ich wundere und frage mich eh, warum bei allen Boxen mit 13.x.x der Kernel immer gleich bleibt, und nicht ein einheitlicher aktueller Kernel für alle Boxen bei einem "großen" Update kompiliert wird. Selbst der 4.1.x der Uno 4K SE ist schon fast drei Jahre alt. Muss ja nicht gleich der Linux 4.16-rc1 sein. :D

      Und zur Frage mit der Bearbeitung. Nein, machte ich noch nie und wahrscheinlich bleibt das auch. Ich nutze die Boxen für zeitversetztes Fernsehen. Da brauche ich nur vor, zurück, Pause und löschen. 8) Zwei Sendungen HD aufnehmen, eine dritte per Timeshift zeitversetzt gucken hat funktioniert.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von senderlisteffm ()

    • Soweit ich mal die Äußerungen zur Linuxkernel Version von den Imagebauern verstanden habe, kommen ja die Treiber und damit die Board Support Packages vom Hersteller der Boxen und die passen nicht unbedingt für älterer Boxen die Treiber an neue Kernel an. Z.B. als die Uno4kse und Zero 4k rauskamen, haben die das auf 4.1.20 gemacht, das ist bei allen Images der Kernel. Die älteren haben sie aber einfach auf den Kernel gelassen, wo sie waren.

      Die Image Bauer haben die Sourcen dazu nicht und können das oft nicht.

      Verstehen kann ich das aber auch nicht, warum die Hersteller das nicht machen

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von anudanan ()