Det er ikke ligegyldigt hvordan man konfigurerer og bruger NTFS (NT File System) partitioner. Det skyldes, at alle partitioner ikke oprettes ens. Faktisk kan to helt nyoprettede, men forskelligt konfigurerede partitioner, have stor indflydelse på et systems ydelse.
Det giver sig udslag i stadig dårligere svartider, og så selvom der defragmenteres ofte. Med lidt baggrundsviden om de faktorer som har indflydelse på NTFS partitioner, kan man få et mere effektivt system fra starten.
NTFS partititonen:
En partition SKAL oprettes som NTFS fra starten, og IKKE konverteres fra FAT. Det skyldes, at man på en direkte oprettet NTFS partition får lagt Master File Table (MFT) ind i starten af disken, og cirka 12,5 procent af diskens plads reserveres til MFT.
Hvis man derimod konverterer en eksisterende FAT-partition til NTFS (med convert.exe), placeres MFT hvor der nu er ledig plads. Det vil næsten altid medføre fragmenteringsproblemer, specielt på systemer som bruger meget diskadgang - for eksempel fil-servere, database-servere med flere.
Samtidig bør man undgå store partitioner. På store partitioner tager det længere tid at foretage backup og gendannelse, da general diskadgang bliver langsommere (det tager længere tid at finde, læse og skrive til disken).
Størrelsen er naturligvis en opvejning af funktionalitet og brug, da et system som skal bruge en fem gigabyte database, naturligvis skal have den fornødne plads. Kodeordet i den forbindelse er: Lav ikke dine partitioner større end nødvendigt.
Det er samtidig også en god idé at have specialiserede partitioner, så som: System, Applikation, Data, Temp og så videre. Det gør, at bestemte diskaktiviteter afgrænses til specifikke områder på disken - og dermed begrænser muligheden for fragmentering.
Endnu et argument for NTFS er, at dette filsystem har indbygget "selvrettende muligheder", ud over det indlysende med sikkerhed.
Definering af Cluster størrelsen:
Når en NTFS partition oprettes, foreslår Windows selv en standard størrelse på de områder i filsystemet som bruges til fysisk lagring af data: Clusters. Her benytter mange den standard angive størrelse, men det er et levn fra "gamle dage".
Flere forskellige test, foretaget af mange forskellige organisationer og private har vist, at en cluster størrelse på 4096 bytes er den mest optimale på snit. Denne størrelse gør, at man mindsker muligheden for fragmentering af både filer og MFT.
En mindre værdi medfører fragmentering og en større kan give problemer, hvis man ønsker at benytte sig af NTFS''s indbyggede komprimmering. Har man et defragmenteringsprogram som Diskeeper installeret, vil man også kunne få problemer med værdier større end 4096 bytes.
Men, under alle omstændigheder, bør man IKKE bruge værdier mindre end 1024 bytes.
Mapper og fil-strukturen:
I mange tilfælde vil man udnytte den fleksible mulighed for, at oprette dybe træ-strukture i filsystemet. Hovedmapper med mange undermapper og under-undermapper, gør det fleksibelt at gemme data i en struktureret facon.
Den dårlige nyhed i den forbindelse er, at dybe træ-strukture virkelig kan sløve ens system ned, da "lookup" i MFT og på selve disken tager længere tid. Det er milisekunder der tales om, men over en hel dag kan dette blive til adskillige minutter.
Den gode nyhed er, at det er ret nemt at rette op på de dybe træ-strukturer, så de ikke sinker systemet i udbredt grad.
Teknisk info om Mapper:
Under NTFS er hver mappe i filsystemet blot en fil som alle andre, men med en speciel intern struktur kaldet et "B+ Tree". Det er en yderst avanceret, men skræddersyet struktur til filsystemets mappenstyring - dog med et par svagheder. En af disse er, at det ikke er det bedste til at håndtere ændringer.
Da filer listes i alfabetisk rækkefølge, kan en tilføjelse af en ny fil eller mappe resultere i, at der foretages ændringer i midten af træ-strukturen. Mange ændringer kan gøre den interne struktur ret kompleks, hvilket igen betyder lavere ydelse når man vil have fat i en fil.
Det skyldes, at lokaliseringen af en fil foregår ved hjælp af en "søgning" i mapperne. Findes den i 10''ende niveau i mappe-strukturen, skal man med andre ord igennem 10 mapper før man når til den som peger på den ønskede fil.
Det er indlysende, at det tager en del længere tid end skulle man kun søge igennem tre mapper. Har der samtidig været foretaget mange ændringer, vil den interne træ-struktur være blevet mere kompleks - hvilket også nedsætter søgehastigheden.
En anden faktor er, at mapper har det med at vokse - i stedet for at blive mindre.
Når man opretter en ny fil eller mappe, forsøges den placeret i et frit område som er efterladt af en slettet fil. I de fleste tilfælde allokeres der dog ny plads i filsystemet, hvilket øger den interne kompleksitet og samtidig fragmenterer filsystemet. Det nedsætter også ydelsen.
Optimering af intern kaos:
Hvor et defragmenteringsprogram, som Diskeeper, kan rydde op i fragmenterede filer og mapper i den fysiske filstruktur, kan det ikke gøre noget ved den interne kompleksitet. Men et simpelt lille trick kan rydde op i dette kaos, og gendanne mappen til næsten perfekt tilstand.
Alt man behøver at gøre er, at kopiere mappen til en ny mappe med et nyt navn i samme niveau som den oprindelige. Herefter sletter man den originale mappe som blev kopieret, og omdøber den nye mappe til den nyligt slettede mappes oprindelige navn.
Den interne struktur bliver hermed "defragmenteret" og ydelsen højnes. Dette bør gøres periodisk, hvis man ofte opretter og sletter filer på systemet. Det er også en god idé at gøre det, hvis man sletter et stort antal filer i en enkelt mappe.
Man kan eventuelt oprette et batch-script som foretager handlingen på hele disken på en gang.
Har man Diskeeper installeret på sit system, er det nu man bør køre en "Boot-time defragmention", som for alvor rydder op i de fragmenterede mapper.
Lange filnavne:
Brugen af lange filnavne (Long File Names, LFN) er, set fra brugerens side, en yderst brugbar funktion som er tilføjet Windows. Det giver et bedre overblik af de pågældende mapper og filer - det øger med andre ord brugen af operativsystemet.
Men, lange filnavne har det også med at fragmentere MFT. Det skyldes den måde filnavne gemmes på, hvilket kræver, at hvert tegn benytter to bytes. Jo længere navn, des mere plads kræves der til selve navnet - og des flere tegn skal der søges på.
Her er det gamle 8-dot-3 DOS format faktisk optimalt set med systemets øjne, men ikke set med brugerens øjne. Kompromisset er i den forbindelse, at holde fil- og mappenavne nede på 20 til 30 tegn. Maksimalt 30 tegn giver en god ballance mellem funktionalitet og hastighed.
|