Har du startat om NAS:en ??
På annan NAS-tillverkare jag har så krävdes omstart innan en expansion kunde påbörjas och har förmodligen med att man vill ha filsystemet offline som i början vid uppstart då partitioner skall skapas om för de större volymer och sedan monteras filsystemet och därefter utökas ext4-filsystemet för att fylla ut partitioner.
Under alla fina GUI-skal som användare använder så är det i slutändan mdadm som gör grovjobbet för RAID-delen, sedan ext4 olika hjälpprogram för att expandera själva filsystemet. - med andra ord bakom klick-knapparna i GUI så är det scriptar som körs och anropar mdadm, ext4-verktyg mm. med rätt parametrar och händelseordning
Att tänka på är att ext4 kan bara expanderas till 4 ggr dess initiala ursprungliga storlek när det formaterades (var det 4TB så kan det bli max 16 TB, var det 8TB så kan det bli 32 TB max etc.) och är det en NAS med 32-bitars OS så är det inte rekommendabelt att ha större logiska volymer än 16 TB då det har varit problem med detta tidigare. Vart fall bör man hålla sig med nyuppdaterad backup hela tiden om volymerna är större än 16 TB tills det har bevisat sig vara stabilt. En lämplig övning är att fylla hela NAS:en med olika filer tills det tar stopp och sedan radera igen och se att det sköter sig utan att filsystemet kraschar eller överdriven slöhet[1] innan man börja köra in skarpa filer
Någon kanske reagerar på detta men det är i princip ingen OS - vare sig kommersiellt eller open source som rekommenderar lagring över 16 TB logisk volym på 32-bits plattformar - en del tom. har sagt att man skall inte ligga över 8TB (dvs risk för 'signed' på 32-bits variabel) och det beror på rädslan av ej upptäckta buggar i libbar i det som hanterar filsystemen[2], att man har för kort ordlängd (32-bitar) någonstans som tex. hanterar adressering av LBA i filsystem och det blir rollover och det börja skriva över början av filsystemet när man skriver förbi 16 TB gränsen och det trashar hela filsystemet till oräddningsbar nivå. - när ni råkat på detta för att OS upptäcker det så småningom (det går fortare med checksummande filsystem som BTRFS) och gått i read-only mode på filsystem - stäng inte av NAS:en eller gör omboot innan ni har gjort backup på det som går att göra backup - för då räddar man med det som är kvar i RAM när det gäller filsystemsstruktur - men nästa omstart så är allt bortglömt då filsystemet inte ens hittar sig själv för att början av denna har skrivits över med data som lades över 16 TB-nivån.
Denna typ av katastrof-fel är förmodligen och förhoppningsvis hittat idag men jag har råkat på det för ett antal år sedan och man skall komma ihåg att nästan alla dagens NAS-tillverkare kör samma Linux-version/distribution så är det sådan fel som ovan skrivet i sin KöpeNAS med ARM-propp så är det med stor sannolikhet lika på alla de andra också samtidigt.
Det finns dock inget i Linux som hindrar/varnar att skapa större volym än 16 TB även om OS 'bara' är 32-bitars - men det kan ge plötsliga problem och risk för förlorad data. Är OS baserad på 64-bis OS så är det inte några kända problem och många ARM-versioner klara faktiskt 64-bitar-stöd i sig men hos NAS-tillverkare med NAS med ARM-processorer (de billigare modellerna) är det fortfarande 32-bitar OS...
Det är ju bara sista halvåret 64-bitas stöd har kommit för tex. Rasberry PI och det lär släpa minst 1 år innan NAS-tillverkarnas ARM-versioner börja stöda 64 Bit i sina OS.
Intel-versionerna av produkterna har dock nästa alltid körts i 64-bits mode då det har varit standard på OS-sidan länge i Intel-världen.
[1] en känd effekt i många köpeNAS för +5 år sedan att när man fyllde en bit över 80% så kunde det bli oerhör slött och det kunde ta minuter per ny fil med med exponentiell ökad tid för varje ny fil och hade att göra med ext4 journal-hantering - tog flera år innan det löstes då NAS-tillverkarna tittade på varandra och hoppades att någon annan skulle göra jobbet - och när det till slut väl löstes efter flera år så hade alla NAS-tillverkar fixat problemen nästan dagen när samtidigt...
[2] det som är oerhört svårt att testa över ~80% av koden som aldrig används, mer än just vid fel - alltså felhanteringen, det är där de glömda variablerna med kort ordlängd (32-bitar istället för 64 bitar) gömmer sig och signed variabel fast det skulle vara unsigned... och skulle någon av dom anropas för att ta ett sällan förekommande felläge (tex att en disk tar lite för lång tid på sig att svara) så kan de åtgärder de gör totalt haverera hela filsystemet... kodarna har gjort vad de kan för att rensa upp det, men är det inte fel i koden så kanske det är någon använd libb istället och i princip måste det skita sig (och tillräckligt mycket loggar igång samtidigt) för att ha en chans att hitta dessa och det är ett evighetsarbete med mer och mer sällan inträffade händelse...
