Swap-fil på vidda

[Kjetil Lura]

Simen1: Takker simen, lærer noe nytt i dag også, har letet litt selv men fant ikke noe av interesse.

 

lindp: Nyttig lese stoff, takker

 

ATWindsor: Jaja, hadde feil i dette. Men nå vet du det, me to. hehe

[BolleKalle]

Jeg vet ikke hva som er best for swap av store eller små clustere eller FAT32 eller NTFS, men jeg tror ikke det er store forskjellen.

There is less overhead when using larger clusters--doing a sequential read of a 10 MB file on a volume that uses 32 kiB clusters means 319 "next cluster" lookups in the FAT. Reading this entire file on a volume with 2 kiB clusters increases this to 5,119 lookups. Another issue is that since every cluster is a contiguous block on the disk, having a larger cluster size means a greater percentage of the file is in continuous blocks--less fragmentation. This means better performance for long sequential accesses. Frequent defragmentation of a disk with smaller clusters will mitigate this effect, but using larger clusters is easier.

 

Kanskje....

[Simen1]

Åssen funker det med felre plater da? La oss si jeg har en 15 gb HD med to plater a 7.5 gb, jeg lager en windows partisjon på 10 gig, vil da den første delen av partisjonen ligge på plate 1, og de resterende 2.5 gb ligge på plate 2, eller vil den skrive annenhver cluster (evt en større enhet) på annenhver plata slik at det blir 5gb på hver (man har en lesearm per plate ikke sant, så dette burde gå raskere, om jeg ikke har misforstått noe).

 

AtW

Jeg er ikke helt sikker på hvordan dataene organiseres bortsett fra at de ikke organiseres ved 7,5GB på den første plata og 2,5GB på den andre når man har en 10GB partisjon på en 15GB disk med to plater. Grunnen er at man ser på HDtach og andre programmer at ytelsen faller hele veien fra starten til slutten på disken uansett om den har 1, 2, 3 eller flere plater. Hadde det vært som dette forslaget ville man sett en reduksjon i hastigheten fra starten til midten og deretter et stort hopp opp til startverdien fra midt på plata og deretter samme fallende kurve ned mot slutten av plata.

 

Jeg vet ikke sikkert om clustere lagres på annenhver plate eller om det lagres et helt spor (hele veien rundt disken) før dataene fortsetter på neste diskplate i det sporet som ligger rett under. (Det som kalles for å være på samme "sylinder").

 

Jeg tror i hvertfall sterkt på den siste teorien. Grunnen er at hvis man skulle lese fra annenhver disk for hver eneste cluster så vil lesehodet måtte fininnstille seg på det riktige sporet for hver gang det bytter å lese på de to platene og det tar faktisk litt tid. (~1ms på 7200rpm disker) Dette ville altså gått drastisk ut over leseytelsen med ~1ms for hver cluster. Hvis diskenes fysiske design (altså ikke det filsystemet ser) har f.eks 32kiB clustere betyr det at disken sinkes med ~1ms for hver 32kiByte den leser. Lesehastigheten på en disk er normalt rundt 50 MByte/s, altså rundt 32kiByte per 0,67ms. Det ville vært ganske bortkastet om disken måtte vente i 1ms for å finne sporet på den andre plata for hver 0,67 sekunder den leser. Det ville altså mer enn halvert ytelsen om de brukte denne løsningen.

[Simen1]

Jeg vet ikke hva som er best for swap av store eller små clustere eller FAT32 eller NTFS, men jeg tror ikke det er store forskjellen.

There is less overhead when using larger clusters--doing a sequential read of a 10 MB file on a volume that uses 32 kiB clusters means 319 "next cluster" lookups in the FAT. Reading this entire file on a volume with 2 kiB clusters increases this to 5,119 lookups. Another issue is that since every cluster is a contiguous block on the disk, having a larger cluster size means a greater percentage of the file is in continuous blocks--less fragmentation. This means better performance for long sequential accesses. Frequent defragmentation of a disk with smaller clusters will mitigate this effect, but using larger clusters is easier.

Kanskje....

Takk HerbBie. Som sagt jeg var usikker på den delen der, men nå har jeg lært noe om det i alle fall.

 

Kan forresten også tilføye at det ikke er like enkelt som det forklares her på alle typer filer. Det kommer av at filsystemet også har clustere. Disse kan kun fylles opp av en fil og dersom filen er mindre enn clusteren så vil siste del av clusteren være tom. Ved større filer som ikke er et helt antall clustere. (f.eks en fil på 50kiB på en partisjon med 32KiB clustere så vil denne filen ta opp 64KiB. Altså en hel cluster + 18 kiB av den neste 32kiB clusteren.) Siden lesearmen ikke kan "hoppe over" den tomme delen av clusteren før den fortsetter å lese neste fil/cluster så vil man få en del dødtid der disken ikke leser noe.

 

Eks: Hvis en rekke små filer som alle er 33kiB ligger kontinuerlig langs et spor og disse skal leses så vil leseytelsen være nesten halvert (33/64) i forhold til om alle filene lå på rekke og inneholdt akkurat 32kiB hver.

 

Eks: Dersom alle clusterene var 4kiB og inneholdt de samme 33kiB filene som i eksempelet over så ville leseytelsen vært bare bittelitt redusert (33/36).

 

Foreøbig konklusjon:

* Dersom filene er veldig store eller de er akkurat eller like under clusterstørrelsen så lønner det seg med store clustere.

* Swap, Mp3, Filmer etc. lønner seg altså å ha på partisjoner med store clustere

 

* Dersom filene er veldig små (langt mindre enn clusterstørrelse) eller fyller akkurat litt mer enn en hel cluster så vil man tjene stort på å redusere clusterstørrelsen.

* OS, programmer, databaser, web-sider og annet smått lønner seg å ha på partisjoner med små clustere.

[BolleKalle]

word