Klusterstorlek på hårddiskar, alltså HDD inte SSD.

Permalänk
Hjälpsam

Klusterstorlek på hårddiskar, alltså HDD inte SSD.

Förr var det enklare, jag valde största möjliga 64 kB, nu kan man välja större än så ända upp till 2 MB.
Men det känns onödigt stort, vad tycker ni?

Permalänk
Medlem

Gissar att det är NTFS du avser och att ens behöva fundera på sådana saker är ett ytterligare bevis på att filsystemet är gammalt och det knakar i fogarna och borde ersättas med något modernare - något som är mer genomtänkt än fiaskot ReFS i avseende att hitta en ersättare för systemfilsystem...

Personligen tror jag inte MS kommer att göra någon ny utan man plåstrar vidare på NTFS så länge det går, sedan vid något tillfälle så kommer man att börja använda filsystem som idag används av Linux - först på lagring och förmodligen via virtuella filsystem och så småningom så vågar man sig på systemdisken med annan filsystem än NTFS då att ett OS-familj är helt låst mot en specifik filsystem (NTFS) och inte är portabelt pga. man i OS använder funktioner som bara finns i NTFS (som tex. att varje filnamn finns i 2 versioner - en 8+3-version och en för dagens filnamnsstorlek och båda måste existera samtidigt (något man försöker få bort idag)) och inte allätare som Linux - börjar också vara en belastning även för MS.

---

När man kör så stora kluster (i NTFS) så kommer det att kosta mycket i slack för filer som inte fyller upp dessa mer eller mindre fullt, och är det bara en byte mer än 2097152 så kommer det ta upp ytterligare 2 MB på disken exempelvis.

'straffet' med stora kluster är inte så stor du bara lagrar stora mediafiler i en lagring, men har du 1.5-3 miljoner småfiler i storlek i enstaka kByte styck så kommer det att svida (en del filsystem kan spara småfiler typiskt under 300 Byte styck i sin metadata, men så fort det är större än så allokeras det direkt kluster ute på disken...)

Många andra filsystem idag är synkade mot x86 och dess minneshantering vilket är med x86 i 4K-block (ARM-plattformen kan ha andra storlekar) och kan på bekvämt sett minnesappar delar av filerna mot motsvarande RAM-adress område och man cachar bara in de 4k-sektorer som körs av exe-filen till RAM och inte hela filen då 90% av en körbar fil har kod som aldrig körs eller bara körs en enda gång, med andra klusterstorlekar så blir det mer beräkningsarbete då det ändå skall brytas ned till 4-kblock.

så... det beror på hur du skall använda lagringen - för små filer eller bara tänkt för stora filer

Permalänk
Medlem
Skrivet av Ratatosk:

Förr var det enklare, jag valde största möjliga 64 kB, nu kan man välja större än så ända upp till 2 MB.
Men det känns onödigt stort, vad tycker ni?

På hårddiskar har jag inte provat på länge. (Typ före Windows XP) Har inte märkt någon speciell skillnad. På mina 10TB diskar så blåser det i 200 - 255 MB / sekund vid en filkopiering mellan diskar (400 från SSD / M.2 (antagligen cache som hjälper till här).

Kör man RAID 0 så får man 800 - 1 200 MB sekund konstant mellan M.2 och HDD.

Har inte tänkt på om jag kan välja annan storlek på kluster faktiskt i Ext4 eller BTRFS, vilket man antagligen kan om man formaterar med kommandorad.

Har inte sett något val i GUI programmen Diskar eller GParted.

Onödigt stora kluster ger onödigt med "wasted space" som det heter, vilket är känt från FAT och NTFS, vad det innebär med dagens storlekar och i Ext4 och BTRFS vet jag dock inte.

Hittar ingen anledning för min del att försöka optimera för någon bättre hastighet. Allt som tar över tio sekunder tar ändå för lång tid.

Permalänk
Medlem
Skrivet av Ratatosk:

Förr var det enklare, jag valde största möjliga 64 kB, nu kan man välja större än så ända upp till 2 MB.
Men det känns onödigt stort, vad tycker ni?

Hm, varför så stort som 64kB? Vad för reell fördel finns det?

Själv skulle jag nog välja "standard" 4kB iallafall som system/allmän disk till en PC, helt enkelt för att det lätt blir ett sånt jäkla svinn med utrymme annars. Diverse temp-mappar och dylikt samt väbbläsar-cache tenderar att gå upp i många tusentals ofta rätt små filer, blir ju stolligt mycket spillutrymme ifall man skulle ha 2MB kluster...

Har man en HDD med shingled recording vill man nog inte ha större kluster än nödvändigt heller skulle jag tro, av prestandaskäl och kanske även gällande livslängd, då iallafall vissa modeller verkar ha begränsat antal omskrivningar av sektorer likt flash har.

Permalänk
Medlem

Ökad klustersorlek har ingen fördel utan en nödvändighet för att gamla filsystem designade på slutet av 80-talet och 1GB-diskar var bortom drömmar i storlek, att kunna skriva 2-siffriga TB filer och med logiska volymer ännu större tresiffriga TB stora lagringsvolymer.

- kort sagt det är plåster för att filsystemen internt i sin struktur begränsas av 16, 32, 48-bits (och 64-bit) datafält när de adresserar sektorer, kluster och det är inget enkelt som kan fixas i efterhand och det som är minst jobbiga i 'renoveringen' mot större lagringsvolym är att öka just klusterstorlek.

Även SCSI/ATA hade länge en begränsning på 32-bit LBA-adressering och man fick resultatet att det slog i taket vid 2 TB - sedan ökade man upp till 48 bitar, men krasst sett börja man komma närmare även den begränsningen i avseende LBA-nummer mot stora lagringsarryer med ett tak på 128 PiB med 512-bytes sektorer.

På externa diskar så räknade man om 512-bytes sektorer till 4k-sektorer när diskarna passerade 2TB och då kunde man med MBR-systemet adressera upp till 16 TB med 2^32 variabler, annars rymdes bara 2TB med 512-bytes sektorer. Med modernare GPT-partitioner så gjorde man sig av med 32-bitars begränsningen

ext4 i Linux har också den är typen av begränsning och man går upp i storlekar med större logiska enheter (i NTFS-världen 'klusterstorlek) när lagringsvolymerna växer.

och 1.5 skärmsida ned i:
https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout

så ser man datafältens storleks olika inverkan av både om OS är av 32 eller 64 bit-typ, klusterstorlekar etc.

Och liknande har man för NTFS och det är alltid någon datafält på typisk 32 bitar som i slutändan bestämmer hur stor tex. en enskild fil kan bli med en viss klusterstorlek.

Med 4K-kluster ligger på volymstorleken för NTFS på max 256TiB och filstorleken max 16TiB samt den kan ha max 2^32 filer (4294967296) dvs. har man mer än 4295 miljoner filer så blir det problem, och antalet möjliga filer ökar inte även om man ökar klusterstorleken - med 2MiB-sektorer som nyligen infördes och med windows drivrutin för NTFS kan man nå max 8PiB både volym och filstorlek - detta är helt klart en lappning i efterhand för att hantera lagringsvolymer över 256 TB - inget man riskerar att råka på som privatperson, men lagringsserver och enorma iSCSI-enheter mot en SAN så är det annan femma i företagssammanhang då man sedan länge ligger på PiB-storlekar för vissa verksamheter.

---

Moderna filsystem som BTRFS och ZFS så är det mesta 64-bits datafält (ZFS har faktiskt 128 bit på delar av det) i strukturerna och har betydande armbågsrum i överskådlig tid framöver även med 4k-sektorer (ingen modern OS arbetar med 512-bytes sektorer utan dessa hanteras alltid i kedja av 8 sektorer för 4K-block i närmast nivå mot disken/lagringen) - men även med moderna filsystem har begränsningar...

Slutsatsen med detta - finns ingen anledning att köra med vare sig 64k eller 2MB-sektorer i NTFS med dom diskstorlekarna man har i hemmiljö, utan kör vidare med 4K-sektorer som annars tidigare.

Permalänk
Hjälpsam

@xxargs
@OldComputer
@LennyV
Tack allihop för era svar!
Min idé var att ökad klusterstorlek skulle minska fragmentisering och antal IO anrop.
Men ni verkar vara ganska samstämmiga, man nog böra hålla sig till default.

Jag formaterar inte om mina befintliga diskar, men vid sådan fall, låter jag de formateras med default, storlek.