Topic       : FreeMiNT für absolute Anfänger
Author      : Draco (draco@atari.org)
Version     : mint.stg (9/1/2001)
Subject     : MiNT
Nodes       : 73
Index Size  : 2258
HCP-Version : 3
Compiled on : Atari
@charset    : atarist
@lang       : 
@default    : 
@help       : 
@options    : -i -s +zz -t4 -d10
@width      : 75
View Ref-FileSpeicherfragmentierung

Wenn man den Befehl 'free' in einer Textshell benutzt, bekommt man eine
Ausgabe ähnlich der folgenden zu sehen:

6365184 bytes (6216K) in 11 blocks free, largest free block 4227072 (4128K)

Fragmentierung ist ein Phänomen, das wir von Datenträgern kennen.
Grundsätzlich passiert folgendes: wenn wir 1 MB freien Plattenspeicher
haben, und dort eine Datei mit einer Länge von 256k speichern, wird
die Menge an freiem Platz um diese 256k verringert. Anschließend
sichern wir eine zweite Datei, die 100k lang ist, und der freie Platz
schwindet um weitere 100k. Wenn wir die erste Datei mit 256k löschen,
wächst der freie Speicherplatz auf der Platte wieder um 256k, aber die
100k der anderen Datei teilt diesen Platz in zwei Blöcke ('Fragmente')
von 256k und 668k Größe. Die Platte ist 'fragmentiert'.

Es gibt ein sehr ähnliches Problem mit dem RAM-Speicher, das in jedem
Multitasking-System auftreten kann. Wenn wir, ähnlich wie in der oben
beschriebenen Situation, 1 MB freien Arbeitsspeicher haben, ein
Programm laden, das 256k groß ist, und danach eines mit 100k, dann
schließlich das erste beenden, so hinterläßt das beendete Programm ein
'Loch' im Speicher, so daß der vorher kontinuierliche Block von 1 MB
in zwei Blöcke von 256 und 668k aufgeteilt wird. Der Speicher ist
fragmentiert worden.

Und das ist viel schlimmer als bei Plattenplatz, denn während Daten
auf eine Festplatte geschrieben werden, kann die Datei effizient auf
die freien Speicherblöcke verteilt werden, auch wenn diese keinen
kontinuierlichen Bereich belegen, der groß genug für die Datei ist.
Tatsächlich reicht es, daß insgesamt genügend freie Cluster übrig sind,
unabhängig von ihrer Position. Im Gegensatz dazu müssen Programme im
Arbeitsspeicher unbedingt in einen zusammenhängenden freien
Speicherbereich der geforderten Größe geladen werden, und wenn diese
Programme beim System um mehr Speicheressourcen anfragen, wird ebenso
erwartet, daß diese Blöcke kontinuierlich sind, also aus einem Stück
bestehen.

Im Gegensatz zu Massenspeicher, wo man die Gesamtmenge an freien
Clustern betrachten muß, während man Daten speichert, ist also der
wichtigste Parameter beim Anfordern von Speicherressourcen (also z.B.
beim Laden eines Programmes) nicht die Gesamtmenge an freiem RAM,
sondern das momentane Ausmaß des größten freien Blocks, der als
kontinuierlicher Bereich alloziert werden kann. Wir werden
grundsätzlich nicht in der Lage sein, ein 256k-Programm in einen
freien Speicher von 1 MB zu laden, falls der größte freie Block darin
kleiner als 256k ist. Und Speicher kann natürlich nicht auf Verlangen
defragmentiert werden, wie das bei Speichermedien der Fall ist.

Die Lösung dafür könnte virtueller Speicher sein, aber FreeMiNT
arbeitet im physikalischen Speicher, da es für den Betrieb auf
Rechnern mit dem normalen 68000-Prozessor entwickelt wird, und
virtuellen Speicher überhaupt nicht einsetzt. Daher, auch wenn es so
aussieht, als würde dieses Problem in (naher) Zukunft gelöst werden,
kann das System zur Zeit ernsthaft durch Speicherfragmentierung
betroffen sein, ähnlich wie in anderen Betriebssystemen, welche
Speicher auf gleiche Weise wie FreeMiNT benutzen. Im Grunde wird, je
länger das System läuft, die Speicherfragmentierung stärker und
stärker, bis zu dem (traurigen) Moment, in dem es notwendig wird, neu
zu booten (weil der größte Block nicht mehr groß genug ist, um irgend
etwas aufzunehmen).

Glücklicherweise ist die Zeitspanne, die nötig ist, um den Speicher
völlig zu fragmentieren, recht lang - im Durchschnitt etliche Tage
oder eine Woche ohne neu zu booten. Die dynamische Speicherverwaltung,
welche kurzfristig die Fragmentierung erhöhen kann, dient auch dazu,
diese wieder zu verringern, so daß nach längeren Zeiträumen mit
geringer Systemaktivität eine Anzahl von kleinen Speicherblöcken sich
'automagisch' zu einem größeren Bereich verbinden, was offensichtlich
die effektive Lebenszeit des Systems erhöhen kann.

Und, selbst ohne diese Speicherverwaltung ist nicht gesagt, daß nicht
auch der Benutzer (Sie) etwas tun könnte, um die Fragmentierung zu
vermindern und so dem System zu ermöglichen, über längere Zeiträume
erfolgreich zu laufen. Es gibt etliche Regeln, die es wert sind,
beachtet zu werden:

1) Benutzen Sie keine Binäre, die mit Programmen wie ICE!, Sentry
   Packer usw. gepackt sind, welche die Datei nach dem Ladevorgang
   automatisch entpacken. Die Routine, die in ein so gepacktes Binär
   eingeschlossen ist, entpackt die Datei in einen anderen
   Speicherbereich als den, wo sie geladen worden ist. Kurz, dies
   erhöht die Speicherfragmentierung. Falls Sie solche gepackten
   Programme haben, entpacken Sie sie mit den jeweiligen Entpackern
   oder benutzen Sie NewDepack von Sinister Developments.

2) Versuchen Sie, Programme in der umgekehrten Reienfolge ihres Ladens
   zu terminieren.

3) Versuchen Sie, niemals daemon-Prozesse oder praktisch residente
   Anwendungen zu terminieren, wie den Desktop, das Kontrollfeld,
   eine Taskleiste (falls Sie eine benutzen). Lassen Sie diese bis zum
   Zeitpunkt des Systemshutdown laufen.

4) Merken Sie sich, daß das GEM eine Systemkomponente ist, die die
   Speicherfragmentierung stark erhöht, weil es dynamisch die
   Allozierung einer großen Anzahl relativ kleiner Speicherblöcke für
   die Aufnahme von Bildschirmobjekten (wie zum Beispiel Fenstern)
   verwalten muß.