<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<title>SDB: EXT2 - Fragmentierung</title>
</head>

<body bgcolor=#ffffff>
<a  href="http://www.suse.de"><IMG hspace=10 ALIGN=left SRC="../gifs/suse_150.gif"></a>
<H1>S.u.S.E. Support-Datenbank</H1>
<H2>Titel: EXT2 - Fragmentierung</H2><p><img alt="---" src="../gifs/gl.gif" height=2 width=100%><p>

<strong>
<a href=index.html>Übersicht</a>
<IMG ALT="---- " ALIGN=TOP SRC="../gifs/green2.gif">
<a href=key_form.html>Stichwortsuche</a>
<IMG ALT="---- " ALIGN=TOP SRC="../gifs/green2.gif">
<a href=history.html>History</a>
<IMG ALT="---- " ALIGN=TOP SRC="../gifs/green2.gif">
<a href=versionspage.html>Versionen</a>
<IMG ALT="---- " ALIGN=TOP SRC="../gifs/green2.gif">
<a href=katlist.html>Kategorien</a>
<IMG ALT="---- " ALIGN=TOP SRC="../gifs/green2.gif">
<a href=inhalt.html>Alle Artikel</a>
</strong>
<img alt="---" src="../gifs/gl.gif" height=2 width=100%>
<h2>EXT2 - Fragmentierung</h2>

<h3>Symptom:</h3>

Wie defragmentiert man das EXT2-Filesystem?

<h3>Ursache:</h3>

Beim Filesystemcheck werden x% "non-contiguous" angezeigt.

<h3>Lösung:</h3>

Die Info stammt von Kristian Koehntopp.<p>

Es bringt nix, denn nach der Fragmentierung wird das Dateisystem sehr
schnell wieder einen fuer die Nutzungsweise des Dateisystems
charakteristischen Fragmentierungslevel anstreben und dann dort
verweilen.<p>

Ausserdem spielt die Laenge der Fragmente eine Rolle. Linux verwendet
kernelintern ein Readahead von 16 Blocks. Das bedeutet: Wenn eine
Datei sequentiell durchgelesen wird (weit ueber 95% alle
Lesezugriffe!), liest Linux bis zu 16 Bloecks am Stueck voraus, um den
kernelinternen Cache vorzugluehen, in der Hoffnung, dass diese Bloecke
gleich von dem betreffenden Programm verlangt werden.<p>

Wenn die Fragmente also groesser als 16 Bloecke sind (die meisten sind
das, siehe unten), dann ist es letztendlich egal, ob die Datei
fragmentiert ist oder nicht, weil der Seek in den Readaheads
untergeht. Nur Fragmente, die kleiner sind als 16 Bloecke wirken sich
wirklich schaedlich auf die Leseperformance aus.<p>

Das ext2-Dateisystem schreibt Dateien nun auch mit einer Art
writeahead, aeh, mit Preallocation. Wenn Du in einem ext2-Dateisystem
einen Block schreibst, belegt das Dateisystem gleich bis zu 7 weitere
Bloecke in Folge fuer diese Datei. Zwei konkurrierende Schreibzugriffe
in einem Verzeichnis wuerden also nicht Bloecke der Form<p>

<PRE>
121212121212

anordnen, sondern eine Blockfolge

1ppppppp2qqqqqqq
</PRE>

erzeugen, wobei jeweils 1 und 2 geschriebene Bloecke der Dateien 1 und
2 sind und p und q fuer 1 bzw. 2 vorbestellte Bloecke sind. Werden 1
und 2 konkurrierend verlaengert, entsteht so<P>

<pre>
11111111222222221ppppppp2qqqqqqqq
</pre>

und so weiter. Auf diese Weise wird die schaedliche (kleine)
Fragmentierung weitestgehend vermieden. Das ganze Verfahren ist eine
Verallgemeinerung des Fragment/Block-Verfahrens des BSD Fast Filing
Systems.<P>

Ausserdem muss man als Anwender auf einem Multitaskingsystem auch noch
zwischen Performance und Durchsatz unterscheiden: Performance ist das,
was ein Anwender mit einem einzelnen Prozess maximal aus der Platte an
MB/sec rauslutschen kann. Durchsatz ist das, was die Platte ueber alle
Anwender und Prozesse gerechnet an MB/sec ausspuckt.<P>

In Multitasking-Systemen ist der Durchsatz oft sehr viel groesser als
die Performance. Linux hat Algorithmen, die den Durchsatz, nicht die
Performance des System erhoehen. Zum Beispiel werden Zugriffe auf die
Festplatte, die in der Wait Queue der Disk stehen, nach Blocknummern
aufsteigend sortiert.  Mit einem Saegezahn-Algorithmus klettert der
Kopf der Platte zu den hohen Blocknummern und serviced die Requests,
um dann in einem long seek nach unten zu zucken und die naechste Runde
zu drehen. (Nein, das ist nicht ganz der Fahrstuhl-Algorithmus: Mit
dem waren die Latenzen/Service Times zu hoch und der Algorithmus ist
nicht fair). Ausserdem werden aufeinanderfolgende Requests fuer
denselben Prozess von Linux zu einem Request groesserer Groesse
zusammengefasst (geclustert).<P>

Durch eine solche Sortierung erfolgen die Lesezugriffe nicht in der
Reihenfolge und mit der Groesse, die der Prozess ausgegeben hat,
sondern in der Reihenfolge und mit einer Groesse, die der Platte
genehm ist. Auf diese Weise werden die Effekte von grosser
Fragmentierung weitgehend ueberdeckt - nur kleine Fragmente wirken
sich schaedlich auf den Durchsatz auf.<P>

Und zum Schluss liegt ueber all diesem auch noch der Buffer Cache des
Betriebssystems, d.h. beim zweiten Leseversuch kommt sowieso alles aus
dem Ram und die Anordnung der Daten auf der Platte ist vollkommen
schnurz.<P>

Defragmentierung ist Zeitverschwendung,
        Kristian
<p><img alt="---" src="../gifs/gl.gif" height=2 width=100%><p>
<strong>Stichwörter:</strong> <a href=keylist.EXT2.html>EXT2</a>, <a href=keylist.FRAGMENT.html>FRAGMENT</a>, <a href=keylist.DEFRAG.html>DEFRAG</a><br>
<p><img alt="---" src="../gifs/gl.gif" height=2 width=100%><p>
<strong>Kategorien:</strong>
 <a href=katlist.FAQ.html>Fragen und Antworten</a>
<br>
<p><img alt="---" src="../gifs/gl.gif" height=2 width=100%><p>

<strong>
<a href=index.html>Übersicht</a>
<IMG ALT="---- " ALIGN=TOP SRC="../gifs/green2.gif">
<a href=key_form.html>Stichwortsuche</a>
<IMG ALT="---- " ALIGN=TOP SRC="../gifs/green2.gif">
<a href=history.html>History</a>
<IMG ALT="---- " ALIGN=TOP SRC="../gifs/green2.gif">
<a href=versionspage.html>Versionen</a>
<IMG ALT="---- " ALIGN=TOP SRC="../gifs/green2.gif">
<a href=katlist.html>Kategorien</a>
<IMG ALT="---- " ALIGN=TOP SRC="../gifs/green2.gif">
<a href=inhalt.html>Alle Artikel</a>
</strong>
<img alt="---" src="../gifs/gl.gif" height=2 width=100%>
<ADDRESS>
SDB-ext2frag, Copyright <a href="http://www.suse.de/">S.u.S.E. GmbH</a>, Fürth, Germany
 - Version: 10.02.98
<br><A HREF="http://www.suse.de/impressum.html">Impressum</A> - Last generated: 10. Feb 1998 13:06:15
 by rj
 with sdb_gen 0.70.0
</ADDRESS>
</body>

</html>