Op deze website gebruiken we cookies om content en advertenties te personaliseren, om functies voor social media te bieden en om ons websiteverkeer te analyseren. Ook delen we informatie over uw gebruik van onze site met onze partners voor social media, adverteren en analyse. Deze partners kunnen deze gegevens combineren met andere informatie die u aan ze heeft verstrekt of die ze hebben verzameld op basis van uw gebruik van hun services. Meer informatie.

Akkoord

Vraag & Antwoord

OS Linux

Suse 10.0 / Schijfdefragmentatie

danieldk
13 antwoorden
  • Is er een mogenlijkheid om met Linux 10.0 een schijfdefragmentatie uit te voeren??? Of denk ik nu veel te windows achtig… :-?
  • Sorry staat er 2 keer in…
  • Is met Linux idd niet nodig. Mooi he?
  • [quote:818e606110="MrLeeJohn"]Is met Linux idd niet nodig. Mooi he?[/quote:818e606110]
    Nou idd, zeker handig. Maar wat is dan eigenlijk de reden dat Windows er dan zo'n zootje van maakt?
  • Het filesystem van windows was altijd de basis voor een desktop-systeem. Bij unix-achtige systemen gaat men uit van servers. Ik denk dat dat de historische reden is.

    Verder is het idee bij unix; alles is een file. Dan moet je je filesystem ook goed overdenken. Bij windows is alles bij dos-fat16 begonnen.
  • Dat is een ontwerpfout in MS-DOS. Die krijgen alle Windows versies mee.
  • MrLeeJohn en Beun007,

    Bedankt voor de uitleg. Ik vraag me alleen af waarom ze dat bij windows niet oplossen. Geen tijd/geld voor (over)? [Waarschuw me ff als dit te ver off-topic gaat]
  • Geen tijd natuurlijk als je de marketing filosofie van Microshit een beetje kent: vlug, vlug… Daaruit is o.a. Windows Meer Ellende door ontstaan!
  • Oké, jammer eigenlijk dat ze onder andere ook daarvoor geen tijd maken. Dat zou de windowsversies een hoop te goede brengen. Ik kan nog wel een paar dingen opnoemen die ze makkelijk beter hadden kunnen doen.

    In ieder geval bedankt voor de info, ik weet genoeg ;).
  • MS filesystems zijn hier best wel OT, maar goed: DOS is gebaseerd op (uiteindelijk) de instructieset van Intel's 4004 microprocessor. De beperkingen van toen zijn door de verplichte 'backwards compatibility' tussen diverse generaties een steeds grotere hindernis. Daarom heeft MS een nieuw filesystem uitgewerkt, voor t eerst toegepast in… Win-NT: NTFS :P

    Voor de rest: als t over Win-OS gaat, vraag je dat in het Win-OS forum :P
  • En ook NTFS raakt gefragmenteerd. Ook daar is dus diezelfde slordigheid ingeslopen….
  • [quote:ef67d27c4f="Beun007"]Dat is een ontwerpfout in MS-DOS. Die krijgen alle Windows versies mee.[/quote:ef67d27c4f]

    Nou nee. In principe raken alle filesystems gefragmenteerd. Door een goed ontwerp is er alleen minder fragmentatie. Stel dat we drie files hebben: A,B,C. Alle drie bestanden nemen 1 blok in, dan hebben we in eerste instantie op de schijf:

    ABC

    Stel nu dat A groeit. Als alle blokken achterelkaar staan, dan kan er niet sequentieel een blok aan A geplakt worden, maar alleen op het volgende stuk lege ruimte. Dan gaat het er dus zo uit zien:

    ABCA

    Het probleem is nu dat als je bestand A wil lezen, dat niet sequentieel gelezen kan worden. De kop moet eerst het eerste blok lezen, een stuk overslaan, en kan dan pas het tweede blok lezen. De eerste truc die vaak toegepast wordt is flink lui zijn, en pas data weg te schrijven als dat nodig is. Stel, dat naar bestand D wordt geschreven, dan E, dan weer D. Als je de boel gelijk weggeschreven had, dan had er fragementatie op kunnen treden. Als het alleen in het geheugen opgeslagen is, dan kan tijdens de echte flush de twee blokken D achterelkaar geschreven worden. Bijvoorbeeld:

    DDE

    Een andere techniek is simpelweg de blokken groter te maken. Stel dat je blokken 8KB maakt in plaats van 1KB, dan heb je veel meer ruimte voor bestanden om te groeien, zonder dat je een extra blok hoeft te alloceren. Het nadeel is dat kleine bestanden veel ruimte innemen. Een bestand van 1 byte zal dus ook 8KB innemen, ipv. 1KB. Dit is gedeeltelijk opgelost in FFS (en later ook andere filesystems) door gedeelde bloks te maken. Dit is een blok die opgedeeld kan worden tussen kleine bestanden, of wat doorgroei van grotere bestanden. XFS gaat nog stukken verder, en kan prealloceren (efficient zorgen dat er alvast ruimte is voor bestanden die gaan groeien), enz.

    De 'bottom line' is dat vrijwel elk denkbaar bestandssysteem kan fragmenteren, en het zeker onder bepaalde omstandigheden gaat gebeuren. Zo worden de meeste bestandssystemen, inclusief ext2/3 e.d., extreem gefragmenteerd als je een filesystem voor meer dan 90% vult. Bovendien heb je altijd natuurlijke fragmentatie, oude bestanden, ergens in het midden van de filesystem die steeds groter worden, enz.

    Toch zijn wij er immuner voor, omdat de meeste mensen software op GNU/Linux tijdens de installatie erop zetten, en achteraf weinig er extra bij pleuren. Dus de meeste programmabestanden en libraries zullen behoorlijk goed op de schijf geordend zijn. Bovendien splitsen veel mensen hun systeem in meerdere filesystems, bijv. voor /home, /var, /, en /usr. Programma bestanden zullen dan op een bestandssysteem geinstalleerd zijn die verder weinig veranderd (behalve updates), en weinig last hebben van bestanden 'ergens in het midden' die veel groeien. Of anders gezegd, /home filesystems e.d. zullen veel fragmenteren, maar de meeste grote leesoperaties die een grote impact op performance hebben, ofterwijl die van programmabestanden en libraries, zullen op een geordende filesystem staan.
  • [quote:dde6f81f7c="danieldk"]
    Nou nee. In principe raken alle filesystems gefragmenteerd. Door een goed ontwerp is er alleen minder fragmentatie. Stel dat we drie files hebben: A,B,C. Alle drie bestanden nemen 1 blok in, dan hebben we in eerste instantie op de schijf:

    ABC
    [/quote:dde6f81f7c]
    Wat ik hierover geleerd heb is dat bovenstaande bij FAT gebeurt, terwijl Linux-bestandsystemen de bestanden als volgt op de schijf zetten:

    [code:1:dde6f81f7c]A B C [/code:1:dde6f81f7c]

    Als A dus groter wordt krijg je
    [code:1:dde6f81f7c]AA B C [/code:1:dde6f81f7c]

    Pas als A zoveel groter wordt dat er geen tussenliggende blokken meer zijn treed er fragmentatie op:
    [code:1:dde6f81f7c]AAAB C A[/code:1:dde6f81f7c]
    Voor zover ik weet lost de kernel dit op door het bestand op een gegeven moment op een andere positie te zetten:
    [code:1:dde6f81f7c] B C AAAA[/code:1:dde6f81f7c]

    Op het moment dat het schijfgebruik meer dan 90% is komt linux in de problemen omdat er dan onvoldoende ruimte over is om tussen de bestanden blokken vrij te laten, of onvoldoende ruimte om bestanden naar een ruimer gebied te verhuizen..

Beantwoord deze vraag

Dit is een gearchiveerde pagina. Antwoorden is niet meer mogelijk.