Root » Servers » » Harde schijf » » Onderverdeling » » Defrag
Defragmentatie
Alles weer keurig bij elkaar
Defrag
Deze tekst is geschreven naar aanleiding van de vraag waarom er geen defragmentatieprogramma's bestaan onder Linux (Ubuntu).

De meest gebruikte bestandsorganisaties zijn FAT, NTFS en EXT.

-

-

FAT

FAT ontstond in de jaren '80. Het was de tijd van de microcomputer, één gebruiker, één programma. Multitasking bestond toen niet. Bestanden werden keurig achter elkaar geschreven (in het begin van de File Allocation Table wordt bijgehouden waar de eerste vrije plaats op de schijf zit). Gewiste bestanden laten "gaten" over in deze struktuur, maar deze gaten worden in het begin niet opgevuld.

Als de vrije ruimte-pointer het einde van de disk bereikt heeft, wordt hij terug op nul gezet. Nu wordt het moeilijker om vrije plaatsen te vinden. De FAT wordt overlopen en het bestand wordt op de vrije plaatsen geschreven. Als de vrije zone te klein is om het volledig bestand te bevatten, worden opeenvolgende vrije zones gebruikt en raakt het bestand gefragmenteerd. Er is geen voorziening om een voldoende grote ruimte te vinden.

Ook als een bestand groter wordt, worden de bijkomende stukken geschreven daar waar er plaats is.

Het FAT filesysteem was ideaal in het DOS tijdperk: eenvoudig bestandsorganisatie (weinig overhead), FAT is ideaal als er weinig bestandsaktiviteit (schrijven en muteren) moet gebeuren. Tot windows '98 voldeed FAT prima.

NTFS

Toen windows met de NT server afkwam was het FAT filesysteem niet goed genoeg meer. Een NT server kan toegang verlenen tot verschillende gebruikers en verschillende bestanden kunnen simultaan in gebruik zijn. Het NTFS (New Technology File System) is grotendeels gebaseerd op het FAT filesysteem (daardoor duurt het converteren van een volume van FAT naar NTFS ook maar een paar minuten), met één groot verschil: NTFS houdt de vrije ruimtes bij in een linked list. Als een bestand geschreven moet worden, dan kan een ruimte gevonden worden, die groot genoeg is om het bestand in zijn geheel op te slaan. Het is mogelijk vooraf aan te geven hoe groot het bestand uiteindelijk zal worden en windows reserveert de nodige ruimte op voorhand (extends) zodat het bestand nooit gefragmenteerd kan geraken. Maar als een bestand moet aangroeien moeten de bijkomende stukken toch vaak elders geschreven worden.

De situatie is nog veel erger geworden met Vista en Windows 7 die constant logfiles en andere zever neerpennen, maar ook de gebruiker treft schuld, namelijk de torrent downloads. Bij een torrent download haal je een groot bestand binnen (doorgaans een film van meerdere gigabytes) via verschillende feeds. Iedere feed stuurt een deel van het bestand. Bij het downloaden zijn er dus een groot aantal bestanden in gebruik die allemaal aangroeien: in dit geval is fragmentatie onvermijdelijk omdat de "slimme" technologie van windows machteloos is: vooraf kan windows niet weten hoe groot het bestand zal worden. Alle download bestanden bestaan vaak uit duizenden fragmenten. Als achteraf de film wordt samengesteld aan de hand van de fragmenten, zit de schijf met talrijke kleine gaten die de volgende schrijfoperaties in de war zullen sturen. Er is wel voldoende vrije ruimte op de harde schijf, maar het zijn allemaal kleine stukjes. Defragmentatie is nodig, en vooral consolidatie van de vrije ruimte.

Voorbeeld gefragmenteerde volume

Rechts is de fragmentatie goed te zien: de registry file bestaat uit meer dan duizend stukken! (eerste report) Niet verwonderlijk dat windows zo traag werkt. NTFS is niet ge-optimaliseerd voor bestanden die constant aangroeien (en de user.dat en system.dat (de registry files) hebben de gewoonte zo maar te groeien, nog erger dan onkruid).

Een tweede volume wordt enkel gebruikt voor back-ups (bestanden die eenmaal geschreven worden). Het betreft vooral foto's die nooit gewijzigd worden. (tweede report) En toch is hier ook fragmentatie te zien, maar van de directories. Bij het opslaan van de bestanden groeit ook de directory aan. Terwijl de individuele foto's in één stuk geschreven kunnen worden bestaat de directory uit vele stukjes: iedere keer dat de directory te klein is, wordt er een stukje bijgeplaatst... want er is vooraf geen ruimte voorzien voor de aangroei van de directory!

De informatie over bestanden (de directories bij FAT) wordt bij NTFS in één groot bestand opgeslagen (dat verwerkt wordt zoals de registry, die ook bestaat uit een aantal bestanden op de volume). Deze database van bestanden heet Master File Table en kan gefragmenteerd geraken zoals ieder bestand (derde printscreen). Het is echter niet mogelijk de Master File Table te defragmenteren, aangezien het bestand constant in gebruik is. Een fragmentatie in een paar stukken zal geen verschil uitmaken, wel als de MFT uit duizenden stukken bestaat. Dit kan gebeuren als de schijf sterk gefragmenteerd is met slechts kleine vrije ruimtes.

Praktisch gezien is er geen verschil wat fragmentatie betreft tussen FAT en NTFS (wat den bill ook mag beweren), en ik heb al duizenden computers nagezien! Zelfs op een computer met 72% vrije ruimte raakt de harde schijf hopeloos gefragmenteerd (vierde printscreen).

EXT

EXT, het filesysteem van de Unix computers is van in het begin geschreven voor multi-tasking (verschillende gebruikers, verschillende toepassingen). Op een Linux systeem draait een "server" die "clients" bedient. Dat die client(s) op de lokale PC ingelogd zijn of niet speelt geen rol. In de PC wereld is "multitasking" in zijn oorspronkelijke betekenis nooit van toepassing geweest, maar het operating system laat wel talrijke simultane toepassingen toe: mails binnenhalen, surfen, foto's bewerken, en zelfs torrents binnenhalen.

Een EXT volume bestaat uit stripes (je zou het kunnen vergelijken met kleine partities binnen de volume). Iedere keer dat er een bestand geschreven moet worden, wordt het in een stripe geschreven, zo ver mogelijk van de andere bestanden. Op het eerste zicht is dit een belachelijke manier van doen, de bestanden zitten immers zo ver van elkaar dat de leeskop van de schijf constant van de ene plaats naar de andere plaats moet gaan om opeenvolgende bestanden binnen te halen.

Maar als een bestand aangroeit is dit geen probleem: er is nog voldoende ruimte achter het bestand. Daarom kan het EXT filesysteem zo goed overweg met bijvoorbeeld multiple torrent downloads: ieder bestand krijgt voldoende ruimte om aan te groeien. Zoals NTFS houdt EXT een lijst bij van de vrije blokken: als de schijf vol begint te raken moet er karig omgesprongen worden met de vrije blokken. Het EXT systeem zal een ruimte toewijzen aan nieuwe bestanden zodat het bestand er keurig in kan passen, met voldoende speling mocht het bestand aangroeien.

Het EXT-file systeem is gestandardiseerd, maar bevat verschillen hoe de bestanden geplaatst worden op de schijf (er worden verschillende soorten "hash funkties" toegepast). Deze verschillende EXT-uitvoeringen blijven met elkaar compatibel, want uiteindelijk wordt de lokatie van het bestand in de directory (of om een juistere benaming te gebruiken: inode) geplaatst. De verschillende implementaties verschillen enkel in het gebruikte algoritme om een plaats voor het bestand te voorzien. Sommige versies zijn bijvoorbeeld geoptimaliseerd voor web-toepassingen (veel reads van relatief kleine bestanden), anderen voor database (een beperkt aantal grote bestanden), enz. Er bestaat dus niet één EXT-3 filesystem!

Tot een vullingsgraad van 80% is de kans op fragmentatie beperkt. Vaak zijn bestanden in twee stukken gefragmenteerd omdat de eerste vrije zone te krap bleek te zijn, maar dit is niet vergelijkbaar met de duizenden stukken zoals bij NTFS. Vanaf 80% "werkt" het algoritme niet meer en moet je dringend op zoek naar een grotere harde schijf. Je hebt een plotse terugval van de prestaties van het systeem.

Overigens kan je wel nazien hoe het gesteld is met de fragmentatie van de volume: doe een fsck van uit de terminal (de dos prompt voor de mensen die nog uit deze wereld afstammen). In dit voorbeeld zijn 2% van de bestanden niet aangrenzend (dus gefragmenteerd). Dat is heel weinig voor een schijf die contant wordt gebruikt als temp-schijf (opslag van tijdelijke bestanden).

Daarom zit er bij de Unix varianten geen defragmenter aan boord. Niet nodig. Indien je vaak met FAT of NTFS volumes zou werken bestaan er defragmentatieprogramma's, maar je kan de volume in een windows systeem monteren en die daar laten defragmenteren. Daar is microsoft goed in! Overigens moet je FAT volumes op geheugenkaartjes niet defragmenteren: omdat er geen leesarm is speelt het geen rol dat een bestand uit één stuk of duizenden stukken bestaat. In tegendeel, het constant verplaatsen van bestanden om die bij elkaar te krijgen doet de kaart sneller verslijten.

Het EXT file system kan je defragmenteren door een back-up te nemen en die dan terugzetten. FSArchiver werkt op fileniveau en bij het terugzetten zal het alle files keurig in één stuk terugschrijven. Je hebt in feite een volledig nieuw filesystem. Maar FSA heeft nog meer voordelen!

Latency

Het feit dat de bestanden bij EXT zo ver uit elkaar zitten wordt gemitigeerd (wat een mooi woord: zoek maar op wat het wilt zeggen) door het feit dat vaak niet de access time van belang is (de tijd nodig om de kop naar de juiste spoort te brengen), maar wel de latency time (de tijd die nodig is totdat de juiste blok zich onder kop bevindt).

Een klassieke harde schijf heeft een gemiddelde access tijd van 8ms (1/3 stroke) en een gemiddelde latency van 5.5 ms. De gemiddelde latency tijd is de halve tijd voor een omwenteling: soms kan het systeem de juiste data direct lezen, soms moet men bijna een volledige omwenteling wachten. Van zodra een bestand uit meer dan 3 stukken bestaat is de tijdswinst die behaald wordt door het bestand dicht bij zijn directory te plaatsen (korte access tijd) teniet gedaan door de latency (die van toepassing is op de meeste stukken van het bestand). Ter informatie: de track-to-track access time is ongeveer 1ms, veel minder dan de latency tijd.

    Voorbeeld:
  • NTFS één directory + 2 bestanden lezen, totaal 20 stukken, dichtbij elkaar gelegen (zodat de track-to-track access time van toepassing is): 20 × 1ms (access time) + 20 × 5.5ms (rotational latency), totaal 130ms.
  • EXT-3 weer één directory en twee bestanden, verspreid over de schijf, totaal 6 stukken (met de extends bij het bestand): 3 × 8ms (gemiddelde access tijd) + 3 × 1ms (lezen van de extend) + 6 × 5.5ms (latency), totaal 60ms
Bij een klassieke harde schijf is het dus beter van minder fragmenten te hebben, al moet je daarvoor de bestanden over de hele partitie verspreiden.

Links to relevant pages - Liens vers d'autres pages au contenu similaire - Links naar gelijkaardige pagina's