Freigaben Platz stimmt mit Update 5.0.0.1986 nicht mehr überein

Sehr stranges Verhalten auf einer TS-1680U-R2.

Gestern Abend das Online Firmware Upgrade von der angestaubten 5.0.0.1891 build 20211221 auf die aktuelle 5.0.0.1986 build 20220324 durchgeführt. Soweit so gut.

Alles lief laut Logs erfolgreich ab - es gab keine Auffälligkeiten, Warnungen oder Fehler im Log.

Abgeschlossen wurde es laut Log mit:

Informationen	2022-04-09	18:52:11	admin	127.0.0.1	Firmware Update	Firmware Update	[Firmwareaktualisierung] System von Version 5.0.0.1891(20211221) auf 5.0.0.1986(20220324) aktualisiert.

Seit dem Neustart danach stimmen aber die Freigabegrößen nicht mehr via SMB - über NFS werden die korrekten Größen angezeigt und die Shares scheinen normal zu funktionieren... Und damit es noch "besser" wird, so gilt dies anscheinend nicht für alle Shared Folder. Gemeinsamkeiten lassen sich keine finden - so sind manche betroffenen Shares verschlüsselt, andere wieder nicht. Bei manchen ist das Volume verschlüsselt, bei anderen wieder nicht.

z.B. ist ein 25 TB Share über NFS korrekt 25 TB groß, während der gleiche Share auf dem gleichen Rechner nur 6.68 TB groß ist und als propenvoll ausgewiesen wird (während in Wahrheit rund 3 TB frei sind).

Hat jemand schon einmal derartige Merkwürdigkeiten mit dieser (oder einer anderen) Firmware erlebt?

Update: Nachdem um Mitternacht die tägliche Speicher Rückgewinnung gestartet ist - welche nach 8 Stunden Laufzeit mit einem Fehler abgebrochen ist, war das Volume plötzlich "leer" - sprich sind keine Dateien mehr sichtbar gewesen. Im Speicher Manager ist der berüchtigte Fehler "Volume Entladen" zu sehen gewesen.

Nach einem Rechtsklick auf das Volume hat das QTS automatisch eine Prüfung angeboten, welche dann auch rund 4 Tage gelaufen ist, den gesamten RAM aufgefüllt hat (rund 31 GB) das Storage insgesamt damit so gut wie unbrauchbar gewesen ist. Darüber hinaus ist die Prüfung ergebnislos automatisch gekillt worden.

Gelaufen ist diese über die WebGUI initierte Prüfung als /bin/e2fsck_64 -C 0 -fy -N /dev/mapper/ce_cachedev1 /dev/mapper/ce_cachedev1

Grundsätzlich sind die Daten ohnehin online redundant verfügbar gewesen und ich wollte das Volume schon löschen, da habe ich noch einen Versuch über die Bash gestartet. Mit e2fsck_64 -pfv -C 0 /dev/mapper/ce_cachedev1. Da die Daten eine redundante Kopie gewesen sind, war das Risiko überschaubar.

Das lief sehr viel schneller ab (rund 3 Stunden) und am Ende meinte er viele Dinge bereinigt zu haben (u.a. "corrupt group Descriptor" und die berüchtigten "Inode XXX has INDEX_FL flag set on filesystem without htree support.). Ersichtlich war aber zuerst natürlich noch keine Änderung, erst nach einem Neustart konnte das Volume wieder normal entsperrt werden und der darin enthaltene Freigabe Ordner ist sichtbar gewesen.

FAZIT: Anscheinend hat die entweder die "alte" 5.0.0.1891(20211221) einen mehr als heftigen Bug in Bezug auf verschlüsselte Volumes (die auch noch größer sind), oder aber aus irgendeinem nicht ermittelbaren anderen Grund ist das Volume seit Erstellung (ca. 8 Monate vor dem Incident) bereits korrupt gewesen und der Fehler ist nun mit der neuen Firmware kulminiert.

Auf jeden Fall sollte man anscheinend von größeren Volumes und der built-in Verschlüsselung die Finger lassen!