Vielleicht liegt es an den 2 Shnapshots ?
Wie lautet die QTS-Version ?
Dein Speicherpool ist voll, deaktiviere dort den Schwellwert und verkleinere das Volume etwas, damit immer Platz im Pool übrig ist...
Ah, der Schwellwert ist schon raus... Hatten wir sowas letztens nicht erst?
Einen Snapshot löschen..und dann das Volumen verkleinern, damit mehr Platz auf dem Pool ist
Sind die Snapshot überhaupt in Verwendung? Ansonsten Snapshots deaktivieren. Snapshots werden nicht auf dem Volumen gespeichert / angelegt - welches in Deinem Fall noch genügend Speicher hat, sondern im Speicherpool. Und der ist bei Dir am Anschlag.
Lösung:
Wie die Kollegen schon geschrieben haben, Snapshot löschen - gegeben Falls sogar beide - bis der Speicherpool wieder aus dem Alarmmodus kommt und Volume verkleinern.
Bei Dir wäre - da nur 6 von 8 Festplatten-Slots belegt - auch der Einbau einer zusätzlichen Festplatte eine Lösung und den Speicherpool / RAID damit erweitern. Aber bitte dann nicht gleich wieder den ganzen Speicher dem Volumen zuweisen, denn dann bist Du gleich weit wie jetzt. 
Bei mir war Ähnliches:
2x HDD - RAID 1
Problem waren auch die Divergenzen in den Anzeigen.
Bei Thick konnte ich nichts mehr ändern.
Lösung:
Auf Thin umgestellt, RAID Test / Rebuild durchgeführt. Danach waren die Probleme weg.
Auf Thin umgestellt, RAID Test / Rebuild durchgeführt. Danach waren die Probleme weg.
Das ist das schöne an Thins... da ist (fast) immer Kapa im Pool übrig, auch wenn man keine Kapa für Snapshots reserviert hat. 
Ich warte dann auf den Thread, wenn das NAS still steht, weil man die physische Kapazität erreicht hat. 
Gruss
So kritisch ist es ja gar nicht, wie ich erfahren habe. Letztlich passiert einem bei Thicks ja uU das gleiche, wie wir in diesem Thread sehen.
Hier ist das Volume auch auf Lesen/Löschen weil der Pool durch Snapshots an die Grenze kommt.
Unterm Strich verlagert man mit Thins das Problem in die Zukunft auf den Tag, an dem die Thins sämtliche Kapa weglutschen. Praktisch wird es aber nicht dazu kommen, da der Pool sicherlich schon vorher erweitert wird. Bei Thicks denkst Du noch gar nicht an eine Erweiterung, ist ja genug Platz im Volume, doch das Problem kann einen trotzdem schon ereilen.
I 
Thin Volumes
"Fehlbedienung" bleibt was es ist, egal ob Thick- oder Thin-Volumen.
Wo sollte bitte die Fehlbedienung sein?
Sorry - in den drei Screenshots im Eingangsthread erkenne ich keine Fehlbedienung.
Ich vermute eher ein Problem beim Update von QTS.
Dazu müsste man mal mehr Details wissen... Also wie ist der Pool wirklich belegt, sprich wie groß die Volumes, welche Art, wie viel ist Snapshot reserviert und wie viel ist einfach so frei. Dann die Frage, woher die Snapshots kommen. Auch möglich, dass HBS einen Snapshot anlegen wollte und daher der Pool vollgelaufen ist.
Der Bedienfehler bzw Konfigurationsfehler kann entsprechend schon ewig zurück liegen und beginnt bei der Aufteilung des Pools und endet beim späteren Umgang mit Snapshots, HBS eingeschlossen. Der Pool kann also schon seit Ewigkeiten vollgekracht sein und alles geht gut, bis HBS zu einem unglücklichen Zeitpunkt auch einen Snapshot erstellt und schon hat man den Salat und es scheint als würde das Problem aus dem Nichts auftauchen.
Ja klar aber der blaue Strich markiert die Speichergrenze. Da ist sieht es nach korrekter Aufteilung aus.
Die Snapshot sollten doch von QTS einkalkuliert sein und wenig Speicher benötigen. Vielleicht die zu leerenden Papierkörbe?
Weil kein Einzelfall vielleicht eher ein doch Speicherorganisationsproblem von QTS.
Der blaue Strich zeigt aber nur den Füllstand des Volumes... Hier bei Dir ist der Pool voll gewesen! Da kann das Volume im Zweifel sogar leer sein!
Wenn der Pool voll ist, dann kannst Du nix mehr speichern. Und alle Volumes werden zur Sicherheit in "nur Lesemoduse" gestellt, bis der Pool wieder freie Kapazität hat.
Ah verstehe! Der volle grüne Balken!
Das Problem hatte ich auch schonmal. Erinnere mich nicht mehr wie ich es hingefummmelt hatte.
Snapshots verwende ich nicht mehr, weil auf dem Produktivsystem läuft TimeMachine.
Japp, genau der grüne Balken. 
Jeder Snapshot verbraucht Speicherplatz im Pool. Da Du ein Thick-Volume hast, ist dieser Teil aus dem Pool fest dem Volume zugeordnet. Und jeder Snapshot braucht nun mehr vom Pool. Bis der Pool kein Byte mehr hat, und dann geht der Pool mit seinen Volumes in Read-only.
Daher ja auch hier (etwas weiter oben) als Anmerkung, dass das bei einem Thin-Volume nicht passiert wäre. Ein Thin-Volume reserviert/blockiert keine Kapazität im Pool, es nimmt immer nur soviel vom Pool wie es braucht oder bis zur maximal konfigurierten Größer oder bei Over-provisioning bis der Pool voll ist (das kennst Du ja).
Warum wird der durch Snapshots verbrauchte Speicherplatz nicht ausgewiesen?
Hätte den Thread erspart
QTS erklärt es über Umwege - so verstehe ich es zumindest.
Auf dem Screenshot unten sieht man, dass der grüne Balken bei einem Speicherpool Daten bzw. zugewiesen ist (hier im Fall 325.37 GB oder 37.31%).
Und dieser "zugewiesene" Datenbereich (grüner Balken) setzt sich aus verschiedenen Dingen unter anderem den Snapshots zusammen.
Zugegeben es ist nicht prominent erklärt. Der Screenshot ist aus der "Verwaltung des Pool".
Um Speicherplatzkollisionen im Pool mit den Snapshots zu vermeiden, gibt es den "Garantierten Snapshot-Speicherplatz". Hier kann man Snapshots Speicherplatz im Pool zuweisen, der nur den Snapshots zur Verfügung steht. Dies ist aber nur die Mindestgröße. Die Snapshots können sich auch mehr genehmigen. Bei Speichermangel im Pools können Snapshots bis auf den grantierten Anteil gelöscht werden, der garantierte jedoch nicht.
Sowohl beim Volumen als auch beim Speicherpool immer ausreichend freien Speicherplatz vorsehen. Das wäre dann ansonsten eine "Fehlbedienung".
