Speicherpool / Volumen nicht änderbar (verkleinern)

  • Ziel: Festplatte mit Smartfehlern auszutauschen.

    - Fehlerhafte HDD gezogen, neue Ironwolf eingesetzt:

    Im GUI wird noch die alte Platte angezeigt!

    Scheint die Anzeige fehlerhaft zu sein?

    Neuste Firmware 5.01….

  • Es kann doch irgendwie nicht sein, dass der bug Thick volumes nicht reduzieren zu können auch ein Jahr später in QTS 5.1.2.2533 immer noch nicht gelöst ist.

    Auch hier Thick Volume auf Speicherpool. Insgesamt 5,33 TB groß, ca. 2,44 TB frei und der Assistent für Volumengröße ändern behauptet Minimum und Maximum für Data wäre auf MAX des Speicherpools.


    Hat hier jemand mal den QNAP support kontaktiert und eine Ticket nummer auf welche man sich referenzieren kann? Sonnst bin ich wieder angeblich der Einzelfall!

  • Hallo,


    Du hättest besser ein neues Thema eröffnet.


    Die Funktion wird selten genutzt, Du solltest ein eigenes Ticket beim QNAP-Support erstellen. :qnap:


    Hinweis:

    Wenn das Volumen von Thick in Thin umgewandelt wird, sollte es funktionieren. Bei Thin-Volumen gibt es scheinbar keine Probleme. ;)

  • Hi,

    Ja danke, den Hinweis auf Umwandlung in Thin und zurück habe ich gelesen. Ist aber auch nur ein Workaround.


    Habe ein eigenes Ticket bei QNAP aufgemacht: Q-202311-12730, falls noch jemand drauf referenzierem möchte.


    Gleiches Problem findet man auch im Netz wenn man nach "shrink thick volume qnap" sucht. Fremdlinks sind hier vermutlich nicht erlaubt. So selten scheint das also nicht zu sein. Aus meiner Erfahrung heraus reagiert der QNAP support auf gemeldete Fehler eigentlich ziemlich zuverlässig, wenn man hartnäckig bleibt habe ich bisher jeden bug auf QNAP Seite korrigiert bekommen. Umso unverständlicher für mich, dass der bekannte Fehler nach einem Jahr immer noch besteht. Hat das etwa bisher niemand gemeldet, kann ich mir fast nicht vorstellen?!


    PS: Dachte immer thematische identische Bezüge in einem Forum gehören in den gleichen Thread, ist ja orginal das gleiche Problem wie der TE und soll ja nur verdeutlichen, dass das Problem unverständlicherweise immer noch besteht.

    Ich gebe ein Update was bei rausgekommen ist (wenn ich es nicht vergesse 8o )

  • So,

    Es gibt ein vorerst "finales" Feedback zu dem Thema: Behandelt wurde dies wie bereits erwähnt im QNAP support Ticket Q-202311-12730.


    Long story short: QNAP berechnet das Minimum im "resize volume wizard" falsch!


    Momentan wird die mögliche Minimumgröße des Volumens mit der Formel: "lv_size - pool free size" (Größe des Volumens - Freier Pool Speicher) berechnet, was natürlich Quatsch ist.


    Jetzt der Wermutstropfen, das ganze ist am Ende in einem "Feature Request" gemündet:

    I have created a feature request so the dev team can work on it,

    its a global feature so it needs a fix in a futre FW update.

    Mal sehen, wann (und ob) etwas kommt.

  • Hi,

    bin seit dieser Woche ein "stolzer" Besitzer eines TS-253E-8 + 64GB RAM + 2x2TB SSD + 2x12TB HDD - und spiele mich derzeit mit dem System herum bevor ich es produktiv einsetze.


    Bin eben auf dieses Problem gestossen dass ein Thick Volume, welches eigentlich nicht belegt ist ( kaum Daten ) - nicht wieder verklienert werden kann, Besteht dieses Problem also anscheinend immer noch - ist das richtig?


    Firmware ist QTS 5.2.0.2860

  • Eine bessere Lösung gibt es aber nicht. ;)


    Oder Du wartest auf den QNAP-Support (Der hat aber vermutlich auch nur diese Lösung :/ ).

  • Nein, brauche keinen Support - es war nur eine Feststellung.


    Ich habe das System erst neu und spiele mich damit herum bevor ich es einsetze. Es ist mir halt aufgefallen und habe nur nach dem Problem gegoogelt und wollte mich vergewissern ob es immer noch so ist oder ich vielleicht etwas falsch mache.


    scheint aber so, dass es nicht an mir liegt :D


    Aber je mehr ich mich damit Beschäftige und auch Artikel von "tiermutter" lese desto weniger möchte ich die qnap eigene software einsetzen :D

  • desto weniger möchte ich die qnap eigene software einsetzen :D

    Was willst du sonst verwenden?


    Außerdem steht bei der Erstellung eines Volumes bei Thick, dass es einfach zu erweitern ist. Erweitern heißt aber leider nicht reduzieren. Bei Thin steht jedoch, dass die Speicherplatzverwaltung flexible ist.

    pasted-from-clipboard.png


    Wieso sollte es also ein Problem / Bug sein?

  • Weil ein Thick genauso problemlos verkleinert werden können muss wie ein Thin.

    Das hat auch mal funktioniert soweit ich weiß, außerdem hat QNAP ja bestätigt, dass hier eine Berechnung falsch ist und es daher nicht funktioniert.

  • Weil ein Thick genauso problemlos verkleinert werden können muss wie ein Thin.

    Ok, aber wenn wir mal ehrlich sind und auf die Erstellungsbeschreibung achten, dann steht da ganz klar, dass es nur erweitert werden kann.

    Aus diesem Grund verwende ich nur die Thin Variante.

  • Das ist einfach nur blöd beschrieben oder übersetzt.

    Thin oder Thick prov. ist keine Erfindung von QNAP und standardmäßig gibt es bzgl der Verkleinerung keinen Unterschied.

    Hier steht, wie auch sonstwo, auch nichts von einer derartigen Einschränkung:

    Thick-, Thin- und statische Volumes

  • Weil bei Thin jeden Tag der nicht genutzte Platz an den Speicherpool zurück gegeben wird. Ebenso nach einem Neustart.


    Bei einem Thick erfolgt das nur bei einer Größenänderung.

    Das hat bis QTS 5 funktioniert, dann hat sich hier ein Käfer eingeschlichen.

    Aber Thin ist halt nicht so Leistungsfähig wie Thick, da der Speicher erst direkt vor der Verwendung noch mal mit 0 beschrieben wird, also mehr random IOs und damit weniger Durchsatz.

  • Aber Thin ist halt nicht so Leistungsfähig wie Thick, da der Speicher erst direkt vor der Verwendung noch mal mit 0 beschrieben wird, also mehr random IOs und damit weniger Durchsatz.

    Kannst du das an einem Beispiel etwas genauer erklären?

  • Damit ist gemeint, dass wenn bei einem Thin Volume neue Daten geschrieben werden und somit dem Volume die erforderliche Kapa bereitgestellt wird, die neu zugewiesenen Blöcke erst mit Nullen beschrieben werden, bevor die neuen Daten dahin geschrieben werden. Es könnte ja schließlich sein, dass sich in den Blöcken bereits alte / gelöschte Daten befinden.

    Siehe allgemein auch "Lazy Zeroed" und "Eager Zeroed" Thick Volume... ein Thin Volume verhält sich hier zwangsläufig wie ein Lazy Zeroed Thick Volume.


    Das würde bzgl. Leistung hier übrigens bedeuten, dass ein Thick Volume bei QNAP Eager Zeroed ist und die Erstellung eines Thick Volumes deutlich länger dauert als die Erstellung eines Thin Volumes... hier habe ich aber keine Erfahrungen, weil ich noch nie Thick verwendet habe.

    Einmal editiert, zuletzt von tiermutter () aus folgendem Grund: Ein Beitrag von tiermutter mit diesem Beitrag zusammengefügt.

  • warum steht dann "nur" bei Thin, dass es an den übergeordneten Speicherpool zurückgegeben werden kann?


    Und genau das finde ich irreführend - Bei Thick steht ausdrücklich "geändert" - Geändert schließt verkleinern nicht aus!

    Wenn man in der spalte daneben des "statische Volume" anschaut - welches du als Vergleich leider nicht am Bild hast - hier steht ausdrücklich "erweitert".


    Was willst du sonst verwenden?


    Für meine Zwecke benötige ich die Automatismen, die mitgeliefert werden nicht unbedingt - natürlich, für die Grundfunktionalität eines NAS erwarte ich dass die QNAP Software zuverlässig funktioniert - es geht eher um alles was darüberhinaus geht. QSYNC, HBS3,...


    Spiele mich aber trotzdem gerade mit HBS3.


    Mir ist wichtig, dass zB das Backup zuverlässig auf der externen HDD landet.


    Ich spiele auch gerade etwas selbst mit eigener Datenintegritätsprüfung wenn ich meine PCs auf das NAS sichere - hier muss jede Datei für die checksum natürlich neu Über das Natzwerk geladen werden - das dauert sehr lange. Ich schreibe mir ein Script, welches es über ssh auf dem Zielhost ausführt. So spare ich mir die Datenübertragung.

    Einmal editiert, zuletzt von chetigol () aus folgendem Grund: Ein Beitrag von chetigol mit diesem Beitrag zusammengefügt.