Wenn Cache voll, dann kaputt.

  • Mir ist es jetzt zwei mal passiert. Ich kopiere Inhalte auf den Unraid und der Cache läuft voll. Eigentlich sollte Unraid dies ja selbstständig erkennen und dann direkt in die Shares schreiben. Macht er aber bei mir nicht (und bei einem Kollgen von mir wohl auch nicht). Das hat dazu geführt, dass meine Docker und VM's nicht mehr richtig arbeiten konnten und sich so komplett aufgehangen haben. Mein VM's konnte ich nicht mehr retten, da waren die Image kaputt. Auch alle Docker musste ich neu aufsetzen.

    Habt ihr mal bei Euch getestet, was passiert wenn der Share vollläuft? Ob dann die Umschaltung auf den Share korrekt funktioniert?

  • Bei mir werden unter 6.7.0 die Inhalte automatisch vom Mover aus dem Cache auf die disks in die richtigen Shares gepackt.
    Die Cache-Disk (256 GB) ist aber auch noch nicht komplett voll gelaufen . Taucht das Problem bei Dir nur dann auf, wenn die Disk mehr speichern muss, als die Kapazität hergibt oder werden Daten generell nicht automatisch vom Cache auf die Disks verlagert?

  • aucht das Problem bei Dir nur dann auf, wenn die Disk mehr speichern muss, als die Kapazität hergibt

    Genau. Dann gibt es einen Crash. Normalerweise sollte das so sein, dass erkannt wird das der Cache voll ist und dann direkt (natürlich langsamer wegen der Parity) auf den Share geschrieben wird. Tut es aber nicht.


    Der Mover läuft ja nur periodisch der ist also keine Lösung für das Problem.

    Exakt. Das ist ziemlicher Mist!


    Ich hab den Monat auf stündlich umgestellt aus den Grund.

    Hätte bei mir nicht geholfen. Wenn ich ein zwei Staffeln einer Serie auf den unraid schreiben will, würde das Ding so oder so volllaufen. Bedeutet, ich muss den Mover nach ein paar Folgen händisch anwerfen bevor ich weiter kopiere.


    Schön ist das gerade wirklich nicht.

  • Hätte bei mir nicht geholfen. Wenn ich ein zwei Staffeln einer Serie auf den unraid schreiben will, würde das Ding so oder so volllaufen. Bedeutet, ich muss den Mover nach ein paar Folgen händisch anwerfen bevor ich weiter kopiere.

    Ich denke, das hat was mit der Einstellung 'minimum free space' auf dem Cachedrive zu tun. Ich habe den Wert relativ hoch angesetzt (50GB). Wenn weniger als 50GB frei sind, wird wohl jede noch so kleine Datei direkt auf die Platten geschrieben. Dein Problem tritt auf, wenn Du z.B. den min. Space auf 10GB stehen hast, aber eine Datei mit 15GB schreiben willst. Dann läuft der Cache voll. So meine ich, das mal irgendwo gelesen zu haben. Der min. free Space muss größer als die größte zu kopierende Datei sein.

    Ich sitze gerade nicht vor dem NAS, schaue heute abend noch mal nach.

    Aus dem Wiki:

    Zitat

    What should I set Min. free space to?

    • This should be set larger than the largest amount of data you expect to transfer to a share before the next scheduled invocation of the mover.
    • At least, it should be set higher than the largest single file you may transfer to the share.
    • If you are using the cache disk for other purposes, you may need to take those purposes into consideration and set it even higher.

    AZi (DEV): Nexus auf LibreElec | Asrock J4205 | 4 GB RAM | 128 GB Sandisk| Rii mini
    DEV: PC Ubuntu 20.04 | Matrix
    AZi: Tanix TX3 | Android/CoreElec Dualboot (EMMC), Nexus
    WoZi: Nexus auf LibreElec | Asrock J4205 | 4GB RAM | 128 GB Sandisk SSD | Atric IR | URC7960
    NAS: unRaid, 3x6TB, 2x12TB | TV-Server: Futro S550 mit Hauppauge QuadHD DVB-C
    PayPal: paypal.me/pvdbj1

  • Ich denke, das hat was mit der Einstellung 'minimum free space' auf dem Cachedrive zu tun.

    Guter Einwand! Hat bei der Recherche geholfen.
    Diese Einstellung habe ich auf meinem Cache gar nicht. Ich habe aber gerade gelesen, dass wenn ein Cachepool mit unterschiedlichen Platten verwendet wird, die LeftSpace Berechnung nicht korrekt funktioniert. Das sollte ich also erst mal ändern

Jetzt mitmachen!

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