Optimal klusterstorlek

Vad är det du vill veta? Slösar du med utrymmet, dvs mycket slack eller stora cluser, så får du bättre prestanda på filsystemet.
Om du vill ha maximalt med lagringsplats, så belastar du MFT hårdare.
Jag kör 16 kb på lagringsdiskar och standard på OS disken. För SSD har det nog ingen betydelse alls. Fast man skulle nog kanske tjäna på att öka till större klusterstorlekar. Det har du rätt i. Hmm.

Ganska onödigt. Du kan enkelt beräkna det själv. Bara att ta antal filer, samt storleken på clustret. Sedan kan du räkna med att 50% är förlusten. Så har du 100 filer på disken. Samt att du har en clusterstorlek på 16KB så har du en medelförlust på 8 KB. Dvs 8 KB * 100. Det är förlusten.

Som jag skrev, frågan är vad du vill förbättra. Maximalt utrymme eller maximal prestanda.

Beror ju på vad du sparar och använder diskarna som.
Sitter du på din vanliga dator kan du ju enkelt kolla egenskaperna på filen genom ett enkelt högerklick.
har du en fil på 10,5Kb och en kluster storlek på 4Kb kommer platsen på disk ta upp tre kluster på 4096bytes, DVS 12288bytes/ 12Kb.
detta kan worst case resultera i tre olika läs operationer på disken, slöare dator alltså (gäller även för SSD men då dom är snabbare märks det inte i samma utsträckning), därför körde man förr i tiden defrag för att samla ihop filerna.
Nu för tiden, i den virtuella världen, är det viktigare att filsystemet är alignat. DVS att hela kedjan från disk->filsystem->virtuell disk->filsystem i virtuella disken->filer matchar varandra så inte hel korthuset rasar, ett fel alignat system kan generera dubbelt så många IO mot disksystemet än ett rätt uppsatt. men som sagt det bygger på att man har hela konceptet med filsystem klart för sig och då tycker jag ändå du är rätt ute att lära dig detta "nörderi", skall du jobba inom storage/virtualisering i framtiden är det ett måste om du inte skall köpa bra mycket kraftfullare prylar än du behöver...

// bC

(lite info till alla läsare)
Nja, vad det är för typ av filer har ingen betydelse alls. Det enda som är av vikt är hur många filer det är.
Varför då? Jo, för formeln är som följer Storlek på cluster * Antal filer / 2. Varför är det så?
Jo, sannolikslära säger oss att om vi slår en tärning 10 000 miljoner gånger så är sannolikheten ganska stor att vi kommer att ha nästan precis lika många 1 or som 2 or osv. Dvs alla sidor har vi fått lika mycket.
Därför kommer filerna du sparar att dels ge lite spill eller inget alls och dels ge mycket spill. Genomsnitt blir det 50% spill.
Så bara att räkna storleken på ditt cluster och antal filer. Detta säger oss också att om vi ska lagra få filer på disken . Dvs de är stora. Då kan vi välja stora cluster. För även om storleken på ditt cluster är stor. så är antalet filer litet. Och det motverkar bra mängden spill.

Man kan tydligen köra dir c:\ /s /a /w vid en prompt. Det kommer lista alla filer på disken. Sedan får du kolla vilken clusterstorlek du har i filsystemet.

Hmm, en SSD kan väl inte bli defragmenterad?

Eftersom mina inlägg oftast skrivs här då jag sitter med i telefonkonferenser eller har tid över får jag komplettera här nu, när jag har tid över och hade lite dåligt samvete över mitt dåligt formulerade och att jag faktiskt inte svarade på din fråga.
Anledningen att jag skrev ett svar första gången var för att ovanstående svar är fel (sorry "lolight" och "celebmir")...

Din outnyttjade yta kommer INTE bli 50% av filstorleken, den kommer bli "´klusterstorlek´-(´filstorlek´ mod(´klusterstorlek´))" och inget annat (vet inte hur mycket matte du läst men modulo är nåt du även bör kunna för krypto...).
För att jag inte vill ge dig svaret på "42" skriver jag bara ett fulhack här i det antika språket VB-script format så du får forska vidare själv (den funkar bara på småfiler som den är skriven så även där får du söka hjälp via lämplig sökmotor).

Starta notepad -> klistra in innehåller mellan "<-klipp->" -> spara som "blablabla.vbs" -> kör...

<-klipp->

Dim Waste, ClusterZise, Folder

Folder = "C:\whatever\"
ClusterZise = "4096"

Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objFolder = objFSO.GetFolder(Folder)
Set colFiles = objFolder.Files

For Each objFile in colFiles
waste = cint(ClusterZise)-(cint(objfile.size) Mod cint(clusterzise))
Wscript.Echo ("namn: " &objfile.name & vbcrlf & "verklig storlek: "& objFile.Size & vbcrlf & "outnyttjad diskyta: " & waste)
Next

<-klipp->

innan du kör modda "Folder" och "ClusterZise" variablerna till något som passar dig,
och se resultatet med olika kluster storlekar, skrev in det som en variabel så du slipper formatera om hårdisken för att testa
(annars är det bara fyra rader extra kod för att läsa ut det och använda istället för ClusterZise med automagi...).
Jämförelse program finns inte (av förklarliga skäl, då en disk inte går att göra om identisk med olika kluster storlekar rakt av),
prestanda skillnaden går förmodligen att härleda till alignment fel och fragments (och även här är det enkel "jämnt delbar med"-matte alternativt antal läsoperationer-per-segement eller worst-case både och...).

// bC

@lolight:

Vilken typ av fil (hur ofta den används) är en indikator på om det är värt att göra något åt "problemet" eller inte...
Ang filstorlek är din matte fel, sannolikhetsläran är dock sann.
vad gäller "dir" funkar det, men jag hade hellre kört "contig" från system internals.
SSD diskar har "samma" minnes/access struktur som magnetisk lagring, man kan därför defragmentera dom, då dom blir fragmenterade
fördelen med SSD är att access tiden är "0" därför skiter man i att dom blir fragmenterade. never the less, dom blir det med tiden.

Nej det skrev jag väl inte? Det kommer blir hälften av storleken på clusersize gånger antal filer.
"Divide the allocation unit size obtained in Step 3 in half, then multiply the result by the number of files obtained in Step 4. For example, if your allocation unit size is 4096 bytes, and you have 30,000 files on your hard drive, your result would be 2,048 x 30,000 = 61,440,000. This is the approximate number of bytes on the hard drive that are wasted due to file slack.

Read more : http://www.ehow.com/how_5965463_calculate-file-slack.html"

Hur alignment fel funkar, man fixar eller kollar har jag ingen aning om. Jag har säker massor av sådana fel. Vore kul att kunna laga eller förstå. Så känner någon sig manad, skriv och berätta

Sorry, min powerreading som ställer till det som vanligt...
När jag läser nu ser jag ju att ni refererar till klusterstorleken och inte filstorleken.
Så ni har givetvis rätt.

du kan ju alltid börja smått...
starta msinfo32, gå till Components ->Storage->disks, leta upp partition starting offset och kolla att den är jämnt delbar med 4096 (sen får du kolla alla andra partitioner med...). Alternativt tar du och laddar ner något benchmark verktyg, då dom brukar kolla detta innan dom kör igång.
Har du installerat din dator själv med windows installationen är du så gott som alltid safe, har du däremot migrerat via migreringsverktyg från mekanisk till SSD är det eventuellt inte fallet (HDD offset brukar vara 63 block och SSD 64 block), detta gör att du får läsa mer mot disken för att få ut samma sak, dvs två kluster istället för ett. generellt är detta inga större problem på klient datorer där jag bara rycker på axlarna åt det, och på min privata dator är det irriterande och jag åtgärdar det om jag har tid och lust, men på större SAN börjar det snabbt märkas och man måste ta itu med det.

Netapp kör på 4kb block, om dessa ligger misalinged mot operativsystemet tar varje operation så gott som dubbelt så lång tid att läsa/skriva då sanet måste läsa två block för varje block den virtuella maskinen vi ha, tänk dig sen en SQL-server med massa update-frågor, kommer inte ta många minuter innan användarna klagar på dålig prestanda, och du sitter med en server med en "disk queue length" graf där du inte hittar linjen först då den ligger fastsmetad i toppen i grafen i din perfmon...
Jag har varit med om att storage vmotion har gett mig "slöare" servrar efter att dom blivit migrerade till på pappret bättre hårdvara, då sanet inte varit korrekt uppsatt alternativt att olika tillverkare har valt olika blockstorlekar, VMware och VMFS5 kör 8kb sub allocation blocks, och på SAN har man dessutom I/O block och Storage block, där storage block kan ligga på upp till runt 2Mb.
Och sen på det har du iSCSI jumboframes (som i teorin skall rymma två "standard" I/O block), kan man inte köra över I/O blocken effektivt utan måste använda standard Ethernet paket kan det också slöa ner. så listan på felkällor kan göras lång i större miljöer, men allt kokar ner i att man vill ha så få I/O som möjligt. Så man förstår att det kan vara lockande att lägga ut driften i molnet, alternativt köpa det fetaste som finns för att slippa bry sig, men verkligheten kommer alltid ikapp...