vdr zerdengelt Filesystem? (xfs)

  • Hallo


    meine Video partition habe ich mit XFS formatiert, da es beim VDR ja hauptsächlich um sehr grosse Daeien geht
    und ext3 "minutenlang" nach dem Löschen von Aufnahmen das System blockierte.


    Nun stelle ich fest, das es immer wieder zu Fehlern im Dateisystem kommt.
    Dies äussert sich z.B. darin das beim Löschen einer Aufnahme nur deren Zeitangabe verschwindet, der Eintrage im Menu aber bestehen bleibt
    oder das im Menu alle Aufnahmen (immer!)doppelt gezählt werden, aber nur einmal angezeigt werden.
    (Sind in einem Verzeichnis 3 ungesehene Aufnahmen, so wird "(6)" angezeigt. Wurde eine angesehen, so wird "(4)" angezeigt etc.)


    Benutzt VDR irgendwelche Sonderfunktionen(Attribute?) von ext, so das es mit XFS nicht funktioniert,
    prüft aber nicht noch ob das gewünschte tatsächlich erfolgt ist, wie z.B. "löschen"?
    Oder ist XFS derart sensible und/oder instabil/unzuverlässig das es eigentlich für einen Produktiv einsatz ohne Batterie-Pufferung ungeignet ist
    und vor seiner Verwendung auf systemen die abschaltet werden oder keine USV+BBU haben DRINGEND gewarnt werden müsste?
    Wird eigentlich auch bei XFS beim booten ein filesystem check gemacht oder muss ich das extra konfigurieren?
    Dieses "nicht löschen können" habe ich über mehrere Boot vorgänge hinweg beobachten können (ich dachte das hinge mit dem Undelete-Plugin zusammen)


    yaVDR0.5, vdr1.7.33, 2TB platte






  • Moin

    Zitat

    Nun stelle ich fest, das es immer wieder zu Fehlern im Dateisystem kommt.
    Dies äussert sich z.B. darin das beim Löschen einer Aufnahme nur deren Zeiangabe verschwindet, der Eintrage im Mneu aber bestehen bleibt
    oder das im Menu alle Aufnahmen doppelt gezählt werden, aber nur einmal angezeigt werden.
    (Sind in einem verzeichnis 3 ungesehene aufnahmen, so wird "(6)" angezeigt. Wurde eine angesehen, so wird "(4)" angezeigt)


    Wie kommst du denn drauf dass das was mit dem Dateisystem zu tun hat?
    Also ich kenne das Verhalten auch und ich nutze ext3 oder ext4,allerdings über NFS. Ich denke das hat eher was mit dem unstable-repo zu tun.
    Haste du mal ein update gemacht? Ich meine ich habe das schon lange nicht mehr bemerkt und bin aufd dem aktuellen stand.


    [size=10]nOpacity: Icons
    [size=10]skindesigner: tryoutsglassy

  • Moin


    Wie kommst du denn drauf dass das was mit dem Dateisystem zu tun hat?
    Also ich kenne das Verhalten auch und ich nutze ext3 oder ext4,allerdings über NFS. Ich denke das hat eher was mit dem unstable-repo zu tun.
    Haste du mal ein update gemacht? Ich meine ich habe das schon lange nicht mehr bemerkt und bin aufd dem aktuellen stand.


    Upate mache ich regelmässig wenn Du per aptitude meinst.
    Da habe ich aber lange nix mehr von VDR gesehen,
    Den VDR selbst übersetzen klappt irgendwo nicht.
    Das Problem ist aber eigentlich unkritsch, da lösbar:


    Löschen kann ich nur in dem ich die Datei zweimal lösche.
    Also
    edit,delete,ok Das Verzeichnis wird nach ".del" umbenannt,ist nicht leer, index gibt es noch.
    Ich flieg aus dem Verzeichnis, wenn es die letzet Datei war, obwohl deiese nicht leer ist.
    Es wird also kein Fehlerstaus ausgewertet.
    und noch mal
    zurück ins verzeichnis (Das jetzt aber .del heisst! Hat sich da was den Handle gemerkt?)
    es ist nicht leer
    edit. delete,ok


    nun ist das Verzeichnis leer, existiert aber noch (allerdings war mein pwd der path, es wurde aber kein Fehler geloggt)



    Versuche ich nach dem ersten "löschen" anzuspielen, blockiert VDR ein paar Sekunden



    Ich habe da den Verdacht das das Handling von .del und .rec lustig durch einander get. Es lebe C++... :)


    Oben wird wohl nur gefragt, ob es eine ndex gibt, nicht aber, ob es überhaupt das Verzeichnis gibt.
    Sowas führt natürlich zu einem kirren verhalten der Software.




    Dsa ist aber bur ein Schönheits fehler, denn heute früh waren wieder schäden im Dateisystem zu beklagen!
    Ich hatte gestern den Write cache abgeschaltet. Aber hat wohl keine dauerhafte wirkung.


    Ich habe ebend wieder eine Aufnahme gehelöscht. Ergebnis: Schäden am Dateisystem!


    xfs_check gibt seiten weise:

    Code
    block 28/5571453 expected type unknown got data
    block 28/5571454 expected type unknown got data
    block 28/5571455 expected type unknown got data
    block 28/5571456 expected type unknown got data


    Ich habe dann mal den 2. löschschritt von der Kommandozeile gemacht:
    Keine Defekte sind entstanden


    Dengelt da irgendwas im Speicher rum?

  • meine Video partition habe ich mit XFS formatiert, da es beim VDR ja hauptsächlich um sehr grosse Daeien geht
    und ext3 "minutenlang" nach dem Löschen von Aufnahmen das System blockierte.

    Ich habe seit einigen Jahren genau aus diesem Grund meine Video-Partition auch mit XFS formatiert und bin absolut zufrieden damit und hatte bisher noch keinerlei Probleme. Die von Dir beschriebenen Fehler habe ich noch nicht gehabt. Ich vermute eher, dass Du irgendwann mal einfach Power OFF gemacht hast, ohne den VDR richtig runterzufahren und dadurch ist die Partition fehlerhaft.


    Falls Du Deine wichtigsten Daten sichern kannst, dann empfehle ich Dir mit einer Live-CD (z. B. PartedMagic) zu booten und bei nicht gemounteter Partition ein:

    Code
    xfs_repair /dev/sda3

    auszuführen um die Partition zu reparieren. Es kann sein, dass Du das Repair 2 oder auch 3x ausführen musst, damit alle Fehler repariert werden. Eine Erklärung zum xfs_repair findest Du hier!
    Aber wie gesagt, ein Backup der wichtigsten Daten vor dem Reparieren wäre da schon vorteilhaft. 8)


    Paulaner



  • Danke gut zuhören.
    Ich habe nur die video partition mit xfs.
    xfs_repair hab ich schon gemacht (Hab die partition umounted). Der check war danach zufrieden.


    Ich habe gestern abend das FS repariert und der Rechner hat sich dann selbst runtergefahren.
    Heute morgen war dann, nach einer aufnahmen in der Nacht, wieder was kaputt.
    VDR kann noch nichts gelöscht haben müsssen, noch sind 220GB frei.

  • Hallo zochi..
    bei mir war/ist das exakt das gleiche Verhalten. Auch die logs stimmen teilweise überein.
    Nur kann ich mir nicht vorstellen, dass mein FS kaputt ist, aber ich werde das gleich mal überprüfen.
    Außerdem werde ich, allerdings erst heute abend mal schauen ob ich das Problem immer noch habe.


    Bisdahin
    BooStar


    [size=10]nOpacity: Icons
    [size=10]skindesigner: tryoutsglassy

  • Gab es nicht auch einen Thread das yaVDR0.5 eine externe NFS Platte geschrottet hat?



    Ich gehe davon aus, dsa die Hardware OK ist. Es ist ja auch die Systemplatte. Wenn es da Probleme mit der Hardware gäbe...


  • Benutzt VDR irgendwelche Sonderfunktionen(Attribute?) von ext, so das es mit XFS nicht funktioniert,
    prüft aber nicht noch ob das gewünschte tatsächlich erfolgt ist, wie z.B. "löschen"?


    VDR benutzt lediglich die Funktionen remove() bzw. unlink(). Das sollte vom verwendeten Filesystem völlig unabhängig sein.
    Insbesondere macht VDR keinerlei Gebrauch von irgendwelchen speziellen Filesystem-Eigenschaften.


    Klaus

  • Fehler meinerseits, kann ignoriert werden

  • Zitat

    Gab es nicht auch einen Thread das yaVDR0.5 eine externe NFS Platte geschrottet hat?


    Ja und? Das hat doch nix mit dem "komischen" Verhalten in den Recordings zu tun, oder gehts hier nicht darum?
    Welchen Skin nutzt du?


    [size=10]nOpacity: Icons
    [size=10]skindesigner: tryoutsglassy

  • zochi
    Du schreibst leider nicht, welche Kernelversion Du einsetzt.


    Ich habe mir seit 3.5 einige virtuelle Images auf einem XFS Dateisystem zerstoert. Allerdings war das Filesystem nach aussen clean, aber die Images corrupt.
    Nachdem ich das Filesystem als Schuldigen ausgemacht hatte war mir weiteres Ausprobieren zu aufwendig (habe vorher einiges gedreht, das FS liegt z.B. auf einer EVA (mein erster Verdacht), KVM Parameter gibt's ja auch nicht gerade wenig). Ich habe jetzt ext4 druntergelegt und seither ist Ruhe.


    Fazit: da hat m.E. jemand in XFS einen ordentlichen Bock geschossen. Ich meine mich zu erinnern, dass es seither dort noch Aenderungen gab, aber das ueberlasse ich jetzt anderen.


    uwe

    server: yavdr trusty testing, 2 * L5420, 32GB, 64TB RAID6 an OctopusNet (DVBS2- 8 ) + minisatip@dsi400 (DVBS2- 4 )
    frontends: kodi und xine

  • Insbesondere macht VDR keinerlei Gebrauch von irgendwelchen speziellen Filesystem-Eigenschaften.

    Wie bereits von mir gesagt, ich benutze seit einigen Jahren das XFS-Filesystem für meine Videopartitionen, weil mir das Löschen von großen Dateien (z.B. mehr als 13GB bei langen HDTV-Aufnahmen) mit ext3/4 viel zu lange gedauert hat. Jetzt mit XFS dauert das Löschen einer Aufnahme nur eine oder sehr wenige Sekunden.


    Ich hatte bisher nur einmal Probleme, weil ich den PC "hart" ausgeschaltet habe, weil einfach nichts mehr ging. Die Probleme konnte ich mit "xfs_repair" beheben.
    Aber wenn man eine Festplatte einfach abschaltet, dann haben praktisch die meisten Filesysteme ein Problem.


    paulaner

  • Steht schon in einem anderen Thread ... das Aufnahmen von der Anzahl her doppelt angezeigt werden und sie "2x" löschen muss, liegt am xvdr-Plugin (bei mir aus seahawk's ppa). Das hat nichts mit dem Filesystem zu tun. Auch ich benutze schon seit Jahren XFS für die Video-Partition.
    Deaktiviere mal das xvdr-Plugin in der order.conf und ich denke, Dein Problem mit den doppelt angezeigten Aufnahmen ist verschwunden. Ich setze seitdem vnsi-server ein.


    Gruss
    Markus

  • Hm..
    ich meine bei mir wurde letztens irgendwas an xbmc upgedate..seit dem ist es das "Problem" weg..
    //edit: Aber vielen dank für den Hinweis


    [size=10]nOpacity: Icons
    [size=10]skindesigner: tryoutsglassy

  • Hab's nach den letzten Updates nicht mehr mit xvdr probiert. Fahre mit dem vnsi sehr gut.


  • VDR benutzt lediglich die Funktionen remove() bzw. unlink(). Das sollte vom verwendeten Filesystem völlig unabhängig sein.
    Insbesondere macht VDR keinerlei Gebrauch von irgendwelchen speziellen Filesystem-Eigenschaften.


    Klaus


    Ja, danke.
    Es gibt auch nirgends so was wie "getstatus" oder vorallen "setstatus"? Also um z.B. die Uhrzeit oder die existenz/grösse
    einer Datei herauszubekommen oder mit dem Filepointer zu jonglieren?


    Möglicherweise in einem Plugin...


    Ist schon seltsam das das löschen einer Datei via VDR-Menu unschöne Spuren im FS hinterlässt, das löschen von der Komandozeile aber nicht.

  • zochi
    Du schreibst leider nicht, welche Kernelversion Du einsetzt.


    Code
    root@vdr4:~# uname -a
    Linux vdr4 3.2.0-35-generic #55-Ubuntu SMP Wed Dec 5 17:42:16 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux


    Zitat


    Ich habe mir seit 3.5 einige virtuelle Images auf einem XFS Dateisystem zerstoert. Allerdings war das Filesystem nach aussen clean, aber die Images corrupt.


    Hm... mir ist bei ein paaar alten Aufnahmen (2008) "unvermittelte Klötzchen bildung" aufgefallen.
    Also mitten in einer ruhigen Szene pixelt es für einen kleinen Moment.


    Zitat


    Fazit: da hat m.E. jemand in XFS einen ordentlichen Bock geschossen. Ich meine mich zu erinnern, dass es seither dort noch Aenderungen gab, aber das ueberlasse ich jetzt anderen.
    uwe


    Oje...wenn das stimmt, ich sehe mich schon mit 1,5TB "umziehen"...

  • Moin


    Wie kommst du denn drauf dass das was mit dem Dateisystem zu tun hat?


    Weil kaputte Meta daten sich so auswirken könnten.


    Zitat


    Also ich kenne das Verhalten auch und ich nutze ext3 oder ext4,allerdings über NFS. Ich denke das hat eher was mit dem unstable-repo zu tun.
    Haste du mal ein update gemacht? Ich meine ich habe das schon lange nicht mehr bemerkt und bin aufd dem aktuellen stand.


  • Ja und? Das hat doch nix mit dem "komischen" Verhalten in den Recordings zu tun, oder gehts hier nicht darum?
    Welchen Skin nutzt du?



    Ja und? Das hat doch nix mit dem "komischen" Verhalten in den Recordings zu tun, oder gehts hier nicht darum?
    Welchen Skin nutzt du?


    Das sind wohl 2 Effekte die wohl eher nichts mitander zu tun haben
    a) Doppelte Anzeige, doppeltes Löschen in der Playliste.
    b) Fehler im XFS


    Und "b" könnte was damit zu haben .



    Skin ist ST TNG. Die echt schicken neuen kann auf auf meinen 19"er aus 2m Entfernung nicht wirklich gut lesen.
    Da muss wohl mal was grössere her...:-)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!