Filserver: När är diskarna fulla?

När min lagringsenhet når ~70% så börjar jag spåna på uppgradering av diskar.
Vid 80-85% anser jag att det är dax att handla på riktigt.
Beroende på filsystem så kan det vara illa om utrymmet tar slut helt.
Både diskar och filsystem brukar ju vilja ha en del utrymme att röra sig på, försvinner det så riskerar du data.

Det är upp till filsystemet och graden av fragmentering som avgör när det kan bli jobbigt. Tumregeln för NTFS är en fyllnadsgrad på 75% per partition.

Diskarna är fulla när problem uppstår, eller när du beräknat att du får slut på utrymme innan du kan expandera. När detta händer är alltid olika beroende på användning, maskin, OS, filsystem osv.

I mitt fall är majoriteten av mina diskar 2-4TB och de flesta har oftast 10-20GB ledigt. Så har jag haft det de senaste 4-6 åren. Aldrig har jag haft problem med något jag använder lagringen till och fragmentering är inget större problem då det är långtidslagring av olika typer. Ser inte varför jag ska slösa 400GB på en 4TB disk bara för "att".

Finns säkert många bra anledningar att ha ledigt utrymme på diskarna, men frågan är om det gör någon större skillnad för enklare hemmaanvändning. Jag har allafall inte hittat någon anledning att göra det dom senaste åren. Eventuellt om jag körde ZFS som ändrar från prestanda optimering till utrymmes optimering där runt 10%. Vilket gör en ganska stor skillnad i prestanda.
på NTFS får man ofta problem med MFT fragmentering när man närmar sig
80-85% användning. Beror ifs på vad exakt man lagrar på enheten samt om det gör någon större skillnad i prestanda för just det du använder den till.

På mina SSD'er brukar jag sikta på runt 15% ledigt eller mer, kan dock inte säga att jag märkt någon större skillnad i prestanda även när dom börjar närma sig sprick punkten.

Det har ju rätt olika konsekvenser om ex. en 200GB systemvolym är 95% full eller en inte så hårt lastad filshare som används mest till läsning på 18TB är 95% full. Tumregeln är väl att ju oftare den accessas (läsning/skrivning, varierande storlek och antal på filer) desto mindre proppfull bör den vara, annars får man minska nyttjandegraden tills prestandan blir bra.

Känns som att det här är beroende på filsystem, hur volymerna är uppsatta och på vilken hårdvara, och framförallt hur applikationer använder volymen, jag kan inte ge ett exakt svar.

Arkiveringsdiskar kan ju fyllas till sista byten utan att du i praktiken märker något faktiskt problem.

Jag skulle inte fylla en lagringsfilsystem till max mer än 95%, och du är redan över 98% - och behöver faktiskt ta bort filer igen.

OBS man räknar inte i antal GByte ledigt - man räknar i antal % i diskkapacitet ledigt då när filsystemen växer så ökar också behovet av armbågsutrymme i samma grad.

För prestanda så skall man inte ens ha så mycket utan bör ligga under 90% fyllnad (och mindre duktiga filsystem som NTFS under 75% för att inte börja risker att lagra bulk-data i $MFT som extension - som ett filsystem i filsystemet - för då går det inte fort längre)

Situationer där systemet behöver armbågsutrymme på filsystem är när systemen plötligt gått ned pga. strömavbrott etc. när det vid uppstart senare körs fsck/recover via journal etc.

Hos mig som tex. nu har åskan dundrat som fasen med redan 3 st sekundlånga strömbortfall och har man inte UPS eller kör fristående på reservkraft (som jag gör just nu) så hade datorer mm. startat om...

...man kan man hamna i besvärlig situation som man inte tänkt sig - tex. 80TB med data låter lite hårt om man skulle tappa alltihop plötligt pga. en åsk-smäll - har du inte off-line backup så är det dags att fundera på det nu - vart fall på det som är svårersättligt och/eller besvärligt att återställa om det förloras.

Det mesta har ju redan sagts men kan lägga till lite info om ssd'er.
Och ja det handlar om filserver men ssd kan finnas i dessa som systemdisk/chachedisk så inte helt offtopic med andra ord.
SSD har ju samma problem som en hd där filsystem spelar in när prestanda börjar förloras men inte lika allvarligt tapp som för snurrande hd.

Utöver det så börjar ssd tappa prestanda när dom blir fulla på andra sätt och som är betydligt mer märkbara.
Vilket är att trim/garbagecollection/skrivningar tar betydligt längre tid att köras.

För filsystem med prestanda så skall man helst vara under 70% (speciellt om det är NTFS) - över 80% bör överväga utökning, över 90% bör genomföra den övervägda utökningen, och man bör oavsett inte fylla över 95% om man är rädd om sina data.

95% av 74.7 är inte 55 TB - det är ungefär 70.1 TB - och det slacket på typ 4 TB tycker jag att man får kosta på sig på en lagrings-array, men att gå till över 98% fyllning är att utmana ödet...

Och kostnadsmässigt - var kostar det dig i tid och ansträngningar om du måste ladda om hela din RAID för att filsystemet kraschat/låst sig på ett icke räddningsbart sätt pga. platsbrist - de som har gjort en sådan resa brukar inte tycka att det var värt att nyttja de sista 5% i snålhetens tecken...

---

För inte så himla länge sedan med köpeNAS i den lägre prisklassen så körde man huvudet tvärstopp så fort man vid skrivning kom förbi dryga 80 % av filsystemet - och med tvärstopp så menas att det kunde ta över en timme för en fil på enstaka GB i storlek skrivet, försökte man med ytterligare en fil så så tog det 2 timmar - bokstavligen dubbel tid för varje fil man försökte ladda in och NAS:en låst under hela den tiden - gick knappt att logga in sig via SSH ens i det läget, den här väggen kom väldigt kvickt dessutom, även om man kanske såg att skrivningar av småfiler gick långsammare än brukligt en tid innan vid ca 80%.

Det här problemet affekterade alla köpe-NAS med ARM oavsett tillverkare, och det var nästan roande att se på de olika användarforum där användare som rasade över detta - somliga i affekt returnerade produkten för att senare upptäcka att de körde i huvudet på exakt samma sätt på den andra fabrikatet också... och först så vägrade samtliga NAS-tillverkare att låtsas om problemet i typ 1 år trots massor av rapporter - och visade väldigt tydligt på ingen av dem har intern kompetens på i att hacka och felsöka i linux-kerneln utan de var bara 'förpackare' och alla satt och hoppades på att någon annan löste problemet åt dem.

Så småningom dök det upp olika 'fix' där man twekade olika bufferstorlekar och annat då problemet visade sig vara ext4:ans journalhantering och det blev stall när disken var för full trots till synes nära 20% ledigt utrymme kvar. Det spelade ingen roll om arrayen var 2, 4 eller 8 TB stor - 'väggen' var vid samma punkt procentiellt och inte under en viss antal GB ledigt..

För oss som vågade hacka i SSH så var lösningen att degradera filsystemet till ext3-drivsar och stänga av journalen - och filsystem var betydligt rappare än vad ext4 med journal någonsin har känts efter det.

Det tog över 2 år från de första rapporterna till detta var acceptabelt fixat och alla märken nära ungefär exakt samtidigt då alla använde samma linux-kärna...

---

Nu vet jag inte vad du har för filsystem i din 80TB Array (btrfs/ZFS ? ) - men det finns inget som säger att det sköter sig snyggt när du kör filsystemet stum-full - det kanske klarar sig så länge du inte startar om eller får en ofrivillig strömavbrott, men efter en ofrivillg omstart så kanske den är förlorad - med Btrfs så kan man lösa dyliga dödläge genom att koppla in en disk till temporärt för att få lite armbågsrum att lösa problemet (även USB-sticka om så) ...och kanske reda ut det - ZFS vet jag inte.

För dom här lägena med helt fullstoppade filsystem är ärligt sagt inget som FS-utvecklare kollar överdrivet noga i sin utveckling, framförallt inte med 80TB disk-set, av anledningen att testcyklerna blir väldigt långa då det tar tid att fylla upp så stora system - framkalla ett fel, analysera och sedan börja från början igen...

utvecklare av tex. BTRFS har haft sin beskärda andel med kracher pga. full filsystem utan att kunna rädda dessa - vilket ha gjort att de stoppa in ett antal skydd och metoder för att klara sig ur situationen - men som allt (inklusive ZFS) så skall man inte förutsätta att det är idiot-säkert, för då kan man bli besviken....

Vad gör du med lagringen, jag skriver enbart utan att någonsin radera något och då funkar det bra att fylla fullt men börjar man radera filer i stället för att bara fylla upp så blir det ju helt andra förutsättningar.

Jag har cirka 14 TB ledigt av min array på 62 TB, alltså ett genomsnitt på drygt 20% ledigt. De "fulla" diskarna har omkring 12-17% ledigt. Låter det helst inte bli mer fyllt än så på en disk.
1 TB på 8 TB diskar
500 GB på 4 TB diskar

Men det är jag det

När jag är på 8 TB ledigt så är det ungefär 13% kvar på varje disk så då är det ju dags att utöka, men gör det gärna innan det händer.
Men när man fyllt 7/8 av disken anser jag det är dags att köpa nytt.

Finns det andra sorters FS-utvecklare menar du?

Om det är backup i en företagsmiljö är det ju verkligen inte läge att snåla på diskarna för att fylla upp dem maximalt. Kostnaden för att ens ta risken att det börjar strula och tiden du får lägga på det då är ju mycket större än kostnaden för några diskar till.

Intressant tråd. Pratar man procent blir det ju terrabyte i många stor arrayer. Använder man då arrayen som ett arkiv känns det ju som lite slöseri

Finns ju tex mördare (ReiserFs) dvs en tysk som är dömd för mord (har för mig det var en kvinna som blev mördad) i tyskland vilket är varför ReiserFs slutade utvecklas.

Btrfs är liknande zfs dvs skapar checksumor av det som skrivs och förhindrar därmed bitrot kallas även butterfs.
Man behöver dock köra någon typ av raid 1/5/6 (kanske nån mer med) för att kunna åtgärda bitroten, utan raid kan btrfs hittas men ej åtgärdas.

Det problematiska med raid 5/6 (tror raid1 funkar ok dock men inte 100% säker) är att btrfs har haft enorma mängder med buggar/problem när det körs i raid5/6 och dom har nyligen för 1-2 mån sedan kommt fram till att hela raid 5/6 koden bör kastas och göras om från början för den är så dålig helt enkelt.
Så inget man kan räkna med att ens kunna tänka på att snabb testa på många år än med andra ord.

ZFS är extremt väl utvecklat i jämförelse med btrfs.

Tror säkert det är helt lugnt att så länge man har 100-150 GB ledigt så är de helt lugnt med.

BTRFS

"buggar/problem när det körs i raid5/6 och dom har nyligen för 1-2 mån sedan kommt fram till att hela raid 5/6 koden bör kastas och göras om från början för den är så dålig helt enkelt"

Är gammalt - har varit så i flera år och lite har det trots allt hänt sedan dess - tex. finns det support för scrub idag, vilket var den stora problemet innan om man fick problem med sin RAID5/6...

Write-hole risken är fortfarande ett problem - men händelsfönstret där det kan bli problem verka litet och oftast klarar sig ändå - och mdadm är heller inte fläckfritt i funktion om man skulle terrorisera den den med plötsligt olika avbrott mitt under olika skriv-aktiviteter.

Den filsystemet som borde ha döskalle och förbud att användas över huvud taget så är det NTFS om någon frågar mig - är det någon filsystem jag förlorat seriösa mängder med filer på (4TB!) trots försök med diskräddningsprogram efter så är det just NTFS - mer än någon förlust med både FAT och VFAT då det på sin tid fanns rätt bra recovery-vertyg för att rädda fram dem (Norton-tools mfl.). Varken ext -> ext4 har orsakat förluster - ej heller BTRFS

---

Jag har använt BTRFS tillräckligt mycket för att inte ta farhågorna på så stort allvar, tyvärr lider det litet av syndromet att de som inte alls har provat är som som skriker värst om farorna och själv glatt använder NTFS på sina datorer utan att inse att de kastar sten i glashus.

- det är större risk att jag råkar på en trasig disk än att filsystemet gå sönder och då har jag misshandlat den ordentligt med både plötsliga strömavbrott under skrivning - glappa USB-sladdar under skrivning - både avsiktliga och senare oavsiktliga i sådan grad att jag var nära säker på att ha förlorat filsystemet - men nej - plockat ur diskar under drift, skrivit en del och sedan lagt tillbaka (för raid5/6) både online och offline och ännu inte tappat någon data ofrivilligt - seriös körningar med olika defrag och dedupliceringsprogram mitt under skrivande och läsande och sedan gjort binär-compare med rsync efteråt mot en master-filstruktur utan en bit fel och det visat sig 'good enough' för min del.

OK, det stämmer att det inte finns automatik som detekterar och upptäcker att en disk är ej uppdaterad eller krasslig på annat sätt i RAID5/6 och man måste själv starta en scrub eller balance för att hitta eventuella latenta fel (och det gör man ändå med cron eller manuellt startad) - men scrub fungerar idag på RAID5/6 till skillnad från tidigare vilket är mycket viktigt steg i att börja våga använda RAID5/6 för mindre viktig användning - att det kan finnas visa exotiska state den inte kan reda ut - ja det kan jag köpa då backup finns - men detta gäller alla olika RAID-lösningar att det finns något läge de inte kan reda ut och allt handlar om i hur stor risk man kan råka på dem som vanlig användare i verklig drift.

Trots allt skall man ha ofta uppdaterade backupper ändå när man har RAID - RAID är enbart till för tillgänglighet även vid diskfel och ibland för prestanda (striping - många diskar matande parallellt => snabbare) - inte att skydda datat - för skydd av data gör man bara med oberoende backupper och i tillräckligt många i antal.

BTRFS är numera filsystemet på alla mina backupper dels för att det har överlevt ganska rejäl misshandel inledningsvis och av anledningen att med snapshot så kan man göra ny directory-speglande backup med rsync utan att skriva sönder den förra om det skulle bli problem med den senaste (tex alla filer visade sig vara ransomware-angripna) - snapshot kan också göras till RO om man vill (ok med btrfs-commandon kan man ta bort det ändå - men inte med standard-kommandon som överskrivning av filen och delete)

---

OK att BTRFS inte är lika tryggt som ZFS (dock kan zfs också ha seriösa situationer/problem och man måste göra saker i precis rätt ordning för att inte förlora hela RAID:en) men använder man NTFS utan att ifrågasätta denna grovt så har man ingen rätt att peka finger på varken BRFS eller ZFS i avseende om frågor om filsystemens stabilitet...

eller som någon på ett forum skrev om RAID i allmänhet:

"
I've seen SCSI RAID cards die with all their buffer unwritten. Good luck recovering the array when 512 MB of pending writes are in the battery backed cache, but the card is dead!

I've seen redundant power supply boards blow up their capacitors: so much for redundancy!

I've seen the UPS fail! And the techs had both redundant plugs in the same UPS!

Or the motherboard VRM fails and boom, all pending writes are lost.

"I've seen things you people wouldn't believe. Attack ships on fire off the shoulder of Orion. I watched C-beams glitter in the dark near the Tannhäuser Gate. All those moments will be lost in time, like tears in rain. Time to die."

"

Och för att fylla på detta som hände mig i måndags när jag körde på min UPS när jag drog ur sladden för att tors hammare plötslig tjongade alldeles för nära

12 minuter kvar, 9 minuter (wtf...) , 3 minuter (reste mig ur stolen och börja sträcka efter ON/OFF...) och så slocknade allt plötligt sekunderna efter - inge kontrollerad avstängning hanns med där inte - 3 datorer på en gång varav två NAS med raid-set...

Orsak avsmälta blyledare inne i batteri av höga strömmen för att de har korroderat för mycket över tiden - ingen auto-test hade märkt av problemet då man hade behövt köra över 1 minut i reservkraft med belastningen innan felläget uppkom. batteriet efter händelsen har närmast helt avbrott - den kan mata en lite glödlampa men det är också allt...

Oj det var en trött kommentar

Har exakt motsatta upplevelsen.
Har sedan ntfs kom som standard i windows förlorat 3-4gig och det var för att en disk var nära o dö och under ca 2veckor så gick ett par filer alteftersom ej att läsa (smart data sade ingenting) och efter den byttes ut så provade jag med ext3 i linux bara för o se om det var ntfs problem heller hårdvara.
Och efter att jag fyllt dom 320gb till 70-80% och började läsa så var det stora problem med att läsa visa filer igen smart sade fortfarande inget och efter nån timme så dog den helt.
Dvs troligen inget direkt ntfs kan beskyllas för!

Btrfs däremot har jag provat i min unraid burk tre gånger och två gånger på två andra unraid burkar jag byggde åt kompisar.
Första gången var när unraid införde btrfs som alternativ enbart för testande men avrådde starkt från att använda det normalt.
Den gången funkade allt bra i 3mån sen började filer att ej gå att ta bort men gick o läsa sen efter nån vecka så giock dom ej att läsa.
Detta var på en äldre disk som smart började krypa uppåt lite på (dock fortfarande inget allvarliga varningar) så tänkte att jag kör ReiserFs på de ett tag för o se hur den funkar och den funkade i 1-1,5 år utan problem och byttes ut enbart för storleken och bror körde den i usb chassi (tror ntfs) i ett par år efter det.
Troligen nåt som btrfs kan beskyllas för!

Andra btrfs testet var efter denna förra disken byttes ut och fortfarande under "unraids btrfs test" gick 3-4 veckor innan samma sak hände efter det tror jag att det vart xfs då det var rek från unraid då reiserfs började bli gammalt.
Och disken funkar fortfarande utan fel år senare.
Troligen nåt btrfs kan beskyllas för!

Dom två första testerna var på chache disken där dom flesta då på unraiods forum rekomenderade btrfs på chache disken.

Tredje/fjärde/femte gången var på samma gång och var efter att jag hade läst om att btrfs på enskild disk är rätt onödigt och jag bytte ut en hel del diskar till betydligt större så vafan varför inte prova btrfs på hela arrayen utom chache disken.
Och det var samtidigt som unriad hade börjat med btrfs som standard format när man skapade en ny disk och en hel del skrivits (i unriads forum) om hur mycket det hade förbättrats.
Och det var då mitt tredje fösök och inom samma vecka byggde jag tva system åt kompisar och dom hade även läst om btrfs o hur bra det skulle vara så ville ha det.

Efter 2,5 mån så var alla tre systemen omgjorda med xfs istället då alla tre fick samma problem inom en mån av varandra mitt var först.
Och när det hände på mitt frågade jag dom andra om jag skulle göra om till xfs innan nåt hände och dom fölorade data men näe btrfs är ju bra så det ska ju inte hända.
Men dom förlorade en jävla massa.

Och med samma problem så var det igen börjadfe med några få filer som ej gick att radera och efter ett tag gick dom ej att läsa och med radera/läsa så menar jag både från nätverk och över ssh i tex putty.
Lade dagar på att köra btrfs egna scan/fix program (under alla mina tre btrfs tester) men dessa hitta visserligen felen (tusentals) men kunde aldrig fixa ett enda fel.
Enda fixet var att kopiera dom filer som fortfaranmde gick att läsa och formatera om disken.

Vilken tids-span är detta - Jag började med btrfs med de första 8TB-diskarna kom, vilket är väl typ 4 år sedan och känner inte igen alls de du skriver. Men så har jag kört uteslutande i Jbod eller RAID1 (RAID1 på främst metadatat) då raid5/6 var trasig på riktigt - det är först nu som RAID5/6 verka nå en användbar nivå men är fortfarande under utvärdering med förlorbar data för min del och bästa sättet att testa är 'heavy use' som cratchpad och mindre viktiga och förlorbara backupareor för olika program.

I stort sett alla köpenas i den lägre prishalvan (synologi, qsnap, netgear mfl.) med mer än 2 diskar kör idag på BTRFS - förvisso i en JBOD/RAID0 på en mdadm-RAID i botten då native raid-delen för RAID5/6 är fortfarande inget man vågar sig på ännu.

Men samtidigt skall man ha klart för sig att BTRFS har haft en rätt törne-kantad stig (främst för att utvecklingen har varit underfinansierad) och det har varit problem på många kanter

- därav en ganska omfattade provning i början för min del då jag definitivt inte vill råka ut för NTFS-haveri igen (tips - nyp inte av de första 4 kByten i $MFT och $MFT_mirr samtidigt i NTFS - det blir så fruktansvärt svårt att får fram valida filer ur disken då - det visade sig att de flesta diskräddningsprogram inklusive kommersiella är mycket tungt beroende av att hitta en fungerande $MFT- utan den så är det ofta bara data-scraping kvar och kvaliten på filerna som extraheras extremt låg och ofta inte ens har filnamn)...

Om jag gissar efter att ha rotat igenom unraids release notes så var första försöket 2014 aug/sep då jag provade 1-2 mån efter dom la in det.

Andra försöket nog vintern 14-15 nångång.
Tredje var nog tidig vår 16.

NTFS är gammalt, ineffektivt och gjort för diskar på <200GB. Var inte länge sedan hela filsystemets meta-data bit reserverade 10% av disken till detta, just för att prestandan skulle hållas bra.

Problemet är att detta filsystem äter upp sig själv. Du tar aldrig bort data från meta delen, utan det skrivs bara över när ny data skrivs. Vilket gör att söktider och fragmentering av denna, är permanent. Aka... tills du totalt tar bort partitionen och formatera om helt.

Det finns vissa 3:e part som kan rensa och skriva om journaler och liknande, men helt 100% kan de inte få det ändå. Och för att de ska ha en bra chans, behöver man få ner ledig nivån på runt 75-85% iaf.

Så.. om vi syftar på prestanda, är 75% vad du kan använda, effektivt. Oavsett 100GB eller 100TB partition. Om vi syftar på ren lagring, och man accepterar lite degradering/underhåller det, kan 85-90% fungera. Men 90-95%+ är bara glömma om du inte planerar defragmentera och tömma hela partitioner med jämna mellanrum, för det riskerar påverka journaler och annan metadatas placering.

Alla filer <4k storlek, läggs direkt i filstrukturen, vilket gör att du får med stora NTFS diskar, en enorm sådan, som måste läsas och uppdateras. Detta leder till hemsk prestanda med tiden. Blir denna sedan fragmenterad, pga platsbrist, sjunker prestandan permanent på hela partitionen, även om du tar bort filerna eller frigör plats igen.

Mao, du är redan nu på nivån där enda sättet att få tillbaka prestandan, är att rensa och börja om hela partitionen, eller en sjuhelvetes defrag-jobb som lär ta dagar och riskerar slita disken hårt. Ev kan vissa 3:e part göra den viktigare biten, men frågan är om de kan göra det bra utan mer utrymme.

Liten notis:
SSDers interna system följer också denna princip, med <75% full. 90%+ ökar deras slitage exponentiellt med flera 100% (har sett så illa som 800% snabbare slitage). Detta är oavsett filsystem btw...

Och NTFS på en sådan, har samma problem som ovan, med ett filsystem som blir segare. Där kan man dock få lite bättre chans till att rädda det, eftersom söktiden i början på disken är samma som slutet på disken, så bara man defragmenterar filsystemets metadata, så återställs prestandan.

Därför bör man inte använda NTFS som arkiv filsystem. Det är på många sätt idag föråldrat om man ser till effektivitet.

Stödet för fungerande scrub (och automatisk rättning/reparation) på RAID5/6 infördes på hösten 2017 och innan dess så kan man nog säga att RAID5/&-delen delen var ofärdig och rena testkörningar i utvecklingsfasen av just anledningen att när de börja få problem så fanns det ingen mjukvara som kunde rätta till det igen utan problemen snarare ökade exponentiellt...

nu säger jag inte att BTRFS är perfekt - den har en bit kvar - men för klenare maskiner med mindre minne så är det bättre alternativ än zfs i många fall. skall man ha zfs som filserver så måste man redan från början tänka lite större, mer minne, bättre proppar, fler diskar etc.

zfs anses som ett tryggt filsystem - men den har sin pris både i storlek av infrastruktur och snabbhet och ibland är det värt det - ibland inte.

Jo, och därför (på bl.a. samsung 960 evo) så ska man inte partitionera upp hela SSD:n utan lämna 10-20% opartitionerat på slutet. Då kan SSD:n använda den arean för att jämna ut slitaget.

I annat fall blir det: Man vill skriva data i block X, men det har redan nått slitagevarningsnivå, så vi måste mappa om det till Y, men om Y redan är upptaget så måste vi läsa in Y och skriva ut nån annan stans, är det fullt överallt så måste vi skriva det på X och hoppas att datat som var i Y inte kommer ändras snart.

Labbade lite med såna program för ett par år sen, och kan bekräfta detta, ha hyfsat gott om utrymme ledigt för processen, det tar en rejäl stund även under goda förutsättningar vill jag lova. (på en disk med tiotusentals filer i varierande storlek)