Hallo zusammen. Von Windows her kenne ich die Daten - Defragrementierung wie Diskeeper oder das interne Windowstool, dank denen im extremfall das System wieder einiges schneller laufen kann. Gibt es sowas unter Linux auch? Was ist am besten? Grüsse, NiX.
Am Sonntag, 3. August 2003 12:37 schrieb NiX - Erich Troxler:
Von Windows her kenne ich die Daten - Defragrementierung wie Diskeeper oder das interne Windowstool, dank denen im extremfall das System wieder einiges schneller laufen kann. Linux braucht sowas nicht wirklich, da es den platz auf der platte anders verwaltet (http://www.linuxfaq.de/f/cache/42.html). Defragmentieren wird dir zwar nichts bringen, die Platte sollte nie so fragmentiert wie unter Windows sein, aber wenns dir spass macht: http://www.oosoft.de/german/products/oodlinux/
Frieder
Hallo, Am Sonntag, 3. August 2003 12:37 schrieb NiX - Erich Troxler
Von Windows her kenne ich die Daten - Defragrementierung wie Diskeeper oder das interne Windowstool, dank denen im extremfall das System wieder einiges schneller laufen kann.
Gibt es sowas unter Linux auch? Was ist am besten?
Ein einfaches Suchen mit den Begriffen "Defragmentierung linux" auf google zeigt an erster Stelle den link http://www.oosoft.de/german/products/oodlinux/ Auf www.pro-linux.de findet sich ein Bericht über das Ding. Es ist wohl immer noch "Beta" und scheint nicht mehr weiterentwickelt zu werden.... Ein "freies" Tool ist mir nicht bekannt. Gruß Harald -- Noch bei Telekom?- Ich nicht mehr lange! http://www.free-t.de/ -lesen,verstehen,handeln
hallo Peter, Am Sonntag, 3. August 2003 16:43 schrieb Peter Wiersig
Harald Huthmann wrote:
Ein "freies" Tool ist mir nicht bekannt.
cp
...hm (Freie Tools kenn ich schon) Schüne Sache, wenn Dein "cp" gleich defragmentiert. Mein "cp" macht das eher nicht.... Gruß Harald Ps.: Die Bits auf einer modernen Platte liegen halt nicht angeordnet wie auf einer Vinyl-Lp . Der Controller benutzt über seinen Schreib-Cache eigene: Optimierungsstrategien. Und das Ganze verteilt sich über mehrere Plattten und Köpfe. Eigentlich kann da ein Ordnen nach "logischen" Blocknummern nix brngen. Das war anders als Platten noch 20 MB groß waren...
Harald Huthmann schrieb:
hallo Peter, Am Sonntag, 3. August 2003 16:43 schrieb Peter Wiersig
Harald Huthmann wrote:
Ein "freies" Tool ist mir nicht bekannt.
cp
...hm (Freie Tools kenn ich schon)
Schüne Sache, wenn Dein "cp" gleich defragmentiert. Mein "cp" macht das eher nicht....
Falsch, kopiere den Inhalt einer Partition auf eine Neue, frisch eingerichtete und Du hast die Daten auf der neuen Partition garantiert unfragmentiert. Anschliessend mountest Du die neue Partition anstelle der Alten... Sinn hat das nicht, aber es ist so ;)
Gruß Harald
Ps.: Die Bits auf einer modernen Platte liegen halt nicht angeordnet wie auf einer Vinyl-Lp . Der Controller benutzt über seinen Schreib-Cache eigene: Optimierungsstrategien. Und das Ganze verteilt sich über mehrere Plattten und Köpfe. Eigentlich kann da ein Ordnen nach "logischen" Blocknummern nix brngen. Das war anders als Platten noch 20 MB groß waren...
Ja, früher... ;) aber auch die ganzen Defragmentierer machen im Grunde nix anderes, ausser, dass sie sich vorher Platz zum kopieren verschaffen. so long... bernd
Am Montag, 4. August 2003 01:02 schrieb Bernd Obermayr
Harald Huthmann schrieb:
Am Sonntag, 3. August 2003 16:43 schrieb Peter Wiersig
cp
Schüne Sache, wenn Dein "cp" gleich defragmentiert. Mein "cp" macht das eher nicht....
Falsch, kopiere den Inhalt einer Partition auf eine Neue, frisch eingerichtete und Du hast die Daten auf der neuen Partition garantiert unfragmentiert. Anschliessend mountest Du die neue Partition anstelle der Alten...
...hm,-ja.... http://sdb.suse.de/sdb/de/html/ext2frag.html Gruß Harald
Am Sonntag, 3. August 2003 21:36 schrieb Harald Huthmann:
Ps.: Die Bits auf einer modernen Platte liegen halt nicht angeordnet wie auf einer Vinyl-Lp . Aber fast ;-)
Der Controller benutzt über seinen Schreib-Cache eigene: Optimierungsstrategien.
Natürlich. Das ändert aber doch nichts an der Datenanordnung.
Und das Ganze verteilt sich über mehrere Plattten und Köpfe.
Egal, da der Wechsel von einem Kopf auf den nächsten erst nach jeweils recht vielen Megabyte geschieht. Schön sieht man das bei neuen Samsung Festplatten, da dort in einem Gehäuse Platten mit unterschiedlichen Datendichten verbaut werden. Moderne Platte beschreiben, wenn man die Sektoren durchzählt, immer einen Weile mit Kopf 1, dann Kopf2, dann Kopf 3,... bis sie dann wieder mit Kopf 1 beginnen.
Eigentlich kann da ein Ordnen nach "logischen" Blocknummern nix brngen.
Doch, kann es.
Das war anders als Platten noch 20 MB groß waren...
Das sicher. Matthias
On Tue, Aug 05, 2003 at 01:35:33AM +0200, Matthias Wieser wrote:
Der Controller benutzt über seinen Schreib-Cache eigene: Optimierungsstrategien.
Natürlich. Das ändert aber doch nichts an der Datenanordnung.
Der Buffer-Cache des Betriebssystems, und das Ordnen und Umschreiben der Requests in der Queue des Betriebssystems und der Cache der Platte ändern zwar nicht die Anordnung der Daten auf der Platte, aber sie ändern die _Bedeutung_, die diese Anordnung für die Performance hat. Auf meiner Kiste zum Beispiel kris@valiant:~> free total used free shared buffers cached Mem: 1033080 964376 68704 0 391912 249132 -/+ buffers/cache: 323332 709748 Swap: 750448 36040 714408 ist es weitgehend Wurst, wie die Daten auf der Platte angeordnet sind, weil nach einem Tag oder so niemals mehr zum Lesen auf die Platte zugegriffen wird. Stattdessen liegen 700 MB wohlgefüllter Buffercache rum, aus dem die gesuchten Blöcke geladen werden. Dieses System compiliert arts, kdelib, kdebase und kdepim, ohne die Sourcen oder den Compiler jemals von der Platte laden zu müssen. Auch dann noch, wenn wie üblich eine vmware und ein OOo im Hintergrund geladen rumstehen, weil ich keinen Bock habe auf das Starten von den Dingern zu warten... Das ist die Goldene Regel für das Performancetuning von UNIX-Systemen: RAM ist nur durch mehr RAM zu ersetzen.
Datendichten verbaut werden. Moderne Platte beschreiben, wenn man die Sektoren durchzählt, immer einen Weile mit Kopf 1, dann Kopf2, dann Kopf 3,... bis sie dann wieder mit Kopf 1 beginnen.
Das ist eine von drei bekannten Möglichkeiten, die Daten auf einer Platte anzuordnen. In Bo96a Harald Bögeholz, ,,Platten-Karussell; Festplatten mit EIDE- und SCSI-Schnittstelle im Überblick``, c't, Magazin für Computertechnik, Heise, Hannover, April 1996, Seite 268 ff. finden sich Beispiele für Platten, die Daten nicht vertikal, sondern horizontal anordnen oder noch wirrerere Schemata verwenden. Und das ist nur der Fall für eine Platte - verwende LVM oder gar einen richtigen Storage Manager (Veritas VM etwa) und entsprechend komplizierte Storage Architekturen, und Du hast sogar Probleme zu bestimmen, auf welcher Platte Deine Daten liegen (In einem Rechenzentrum, mit dem ich zu tun hatte, hätte man in diesem Fall sogar Probleme festzustellen, unter welcher Postleitzahl (!) die Daten gespeichert sind). Wie auch immer - selbst bei Desktop-Rechnern ist die konkrete Sortierung der Daten auf der Platte nach logischen Blocknummern zunehmend irrelevant. Es reicht aus, wenn die Daten in zusammenhängenden Blöcken gespeichert sind, die groß genug sind und moderne Dateisysteme stellen das automatisch sicher, wenn sie nicht zu voll gemacht werden (80-90% Füllgrad). Alles andere wird von den dynamischen Zugriffsmustern überdeckt, die im Betrieb aus dem Zusammenwirken mehrere Prozesse entstehen und den Ordnungsmechanismen des Kernels und den verschiedenen Caches überdeckt. Defraggen ist vollkommen sinnlos. Es hat überhaupt nur eine Wirkung, wenn Du - FAT einsetzt UND - ein Single User System fährst, das AUßERDEM NOCH - keinen Buffer Cache hat. Mithin nur unter MS-DOS. Gewöhne Dir das defraggen ab. Es macht die Dinge nicht besser, und es gefährdet nur Deine Daten. Kristian
Am Dienstag, 5. August 2003 08:04 schrieb Kristian Koehntopp:
> On Tue, Aug 05, 2003 at 01:35:33AM +0200, Matthias Wieser wrote:
> > > Der Controller benutzt über seinen
> > > Schreib-Cache eigene: Optimierungsstrategien.
> >
> > Natürlich. Das ändert aber doch nichts an der Datenanordnung.
>
> Der Buffer-Cache des Betriebssystems, und das Ordnen und
> Umschreiben der Requests in der Queue des Betriebssystems und
> der Cache der Platte ändern zwar nicht die Anordnung der Daten
> auf der Platte, aber sie ändern die _Bedeutung_, die diese
> Anordnung für die Performance hat.
Immer dann, wenn einen die verhältnismäßig geringe Geschwindigkeit von
Festplatten stört, nämlich beim erstmaligen Lesen, ändert ein großer
Cache kaum etwas.
> Auf meiner Kiste zum Beispiel
>
> kris@valiant:~> free
> total used free shared buffers
> cached Mem: 1033080 964376 68704 0 391912
> 249132 -/+ buffers/cache: 323332 709748
> Swap: 750448 36040 714408
>
> ist es weitgehend Wurst, wie die Daten auf der Platte angeordnet
> sind, weil nach einem Tag oder so niemals mehr zum Lesen auf die
> Platte zugegriffen wird.
Da mag bei Dir so sein, bei vielen anderen (den meisten?!) läuft (gerade
bei den derzeitigen Temperaturen) ihr PC maximal ein paar Stunden am
Stück.
Mir scheint es, Du übersiehst, daß es einen großen Unterschied zwischen
Arbeitsplatzrechnern, Servern und Home-PCs gibt.
> Das ist die Goldene Regel für das Performancetuning von
> UNIX-Systemen: RAM ist nur durch mehr RAM zu ersetzen.
Eher:
Das ist die Goldene Regel für das Performancetuning von
vielen Server-Systemen: RAM ist nur durch mehr RAM zu ersetzen.
> > Datendichten verbaut werden. Moderne Platte beschreiben, wenn man die
> > Sektoren durchzählt, immer einen Weile mit Kopf 1, dann Kopf2, dann
> > Kopf 3,... bis sie dann wieder mit Kopf 1 beginnen.
>
> Das ist eine von drei bekannten Möglichkeiten, die Daten auf
> einer Platte anzuordnen. In
Das ist die mit Abstand verbreitetste.
>
> Bo96a
> Harald Bögeholz, ,,Platten-Karussell; Festplatten mit EIDE- und
> SCSI-Schnittstelle im Überblick``, c't, Magazin für
> Computertechnik, Heise, Hannover, April 1996, Seite 268 ff.
>
> finden sich Beispiele für Platten, die Daten nicht vertikal,
> sondern horizontal anordnen oder noch wirrerere Schemata
> verwenden.
Ich habe den Artikel nicht mehr genau im Kopf ;-) aber ich denke, das
dürfte das Beispiel mit der Notebookfestplatte gewesen sein? Wenn ja,
dann bestätigt diese Ausnahme eher die Regel.
> Und das ist nur der Fall für eine Platte - verwende
> LVM oder gar einen richtigen Storage Manager (Veritas VM etwa)
Das tut der OP garantert nicht.
> Defraggen ist vollkommen sinnlos. Es hat überhaupt nur eine
> Wirkung, wenn Du
>
> - FAT einsetzt UND
> - ein Single User System fährst, das AUßERDEM NOCH
> - keinen Buffer Cache hat.
- oder wenn die Partition recht voll ist
- wenn es einem beim Lesen von z.B. CD Images auf maximalen Durchsatz
ankommt
- ..
> Mithin nur unter MS-DOS.
Nö.
> Gewöhne Dir das defraggen ab. Es macht die Dinge nicht besser,
> und es gefährdet nur Deine Daten.
Nette Unterstellung, aber ich habe weder etwas defragmentiert, noch
irgendwelche Daten gefährdet, sondern nur darauf hingewiesen, daß moderne
IDE Festplatten schon etwas deterministischer sind, als Du dargestellt
hast.
Matthias
On Tue, Aug 05, 2003 at 11:22:04AM +0200, Matthias Wieser wrote:
> Immer dann, wenn einen die verhältnismäßig geringe
> Geschwindigkeit von Festplatten stört, nämlich beim
> erstmaligen Lesen, ändert ein großer Cache kaum etwas.
Solange die Frags groß genug sind (größer als der Read-Ahead des
Kernels, besser so groß wie eine Spur, noch besser größer als
der Cache der Platte), interessiert es nicht, ob eine Datei
fragmentiert ist.
BSD FFS fragmentiert Dateien zum Beispiel absichtlich ("long
seek") in Stücke von etwa 1/8 der Größe einer CG: Wenn ein
Dateifragment mehr als 1/8 der CG auffüllt, wechselt FFS zu
einer anderen CG und schreibt die weiteren Sektoren dort hin.
Dadurch werden alle CGs gleichmäßig aufgefüllt und FFS hat eine
Chance, Dateianfangsblöcke in der Nähe der jeweiligen Inodes zu
positionieren. Das ist wichtiger als die ganze Datei am Stück zu
schreiben und eine große Datei ist in FFS IMMER fragmentiert.
In ext2 ist es ganz ähnlich: Zwar kennt ext2 keine long seeks,
aber durch die Struktur von ext2 in Blockgruppen ist jede Datei,
die länger ist als eine Blockgruppe zwangsläufig fragmentiert.
>> [ Meine Desktop-Kiste mit 1 GB RAM, davon 720 MB Cache ]
> Da mag bei Dir so sein, bei vielen anderen (den meisten?!)
> läuft (gerade bei den derzeitigen Temperaturen) ihr PC maximal
> ein paar Stunden am Stück.
Das reicht aus, um den Cache aufzuheizen. Diese Personen
verwenden in der Regel auch weniger viele unterschiedliche
Programme als ich das im Laufe einer Laufzeit meines Rechners
mache. So ergibt sich ein ähnliches Bild, oft schon nach 15
Minuten, jedoch auf einem entsprechend niedrigeren Niveau.
> > Das ist eine von drei bekannten Möglichkeiten, die Daten auf
> > einer Platte anzuordnen. In
>
> Das ist die mit Abstand verbreitetste.
Nichtsdestotrotz ist eine unbedingte lineare Anordnung bei
Platten, die nicht diese Geshcwindigkeitsverteilung haben nicht
förderlich, sondern sogar kontraproduktiv (jedoch nicht
kontraproduktiver als gar nicht zu defragmentieren, denn auch
diese Anordnung geht in den Caches und Betriebssystemstrategien
vollkommen unter).
> > - keinen Buffer Cache hat.
> - oder wenn die Partition recht voll ist
Besser: Größere Platte kaufen. Die hat dann auch ein neueres
Interface, einen größeren Cache und ist generel schneller.
Dieser Effekt ist weit stärker als jeder Gewinn, den
Defragmentierung selbst im theoretischen Optimalfall haben kann.
> - wenn es einem beim Lesen von z.B. CD Images auf maximalen Durchsatz
> ankommt
Ähem, 50x Speed = 7.500 KB/sec.
Zum Vergleich:
kris:~ # hdparm -t /dev/hda
/dev/hda:
Timing buffered disk reads: 64 MB in 4.24 seconds = 15.09 MB/sec
kris:~ # hdparm -I /dev/hda| head -10
/dev/hda:
ATA device, with non-removable media
Model Number: HITACHI_DK23CA-20
Serial Number: 11MVXL
Firmware Revision: 00H1A0G1
Standards:
Used: ATA/ATAPI-5 T13 1321D revision 3
Supported: 5 4 3 2 & some of 6
Das ist eine Notebook-Platte in einem Inspiron 8100.
valiant:~ # hdparm -t /dev/hdd
/dev/hdd:
Timing buffered disk reads: 64 MB in 1.41 seconds = 45.39 MB/sec
valiant:~ # hdparm -I /dev/hdd | head -10
/dev/hdd:
ATA device, with non-removable media
Model Number: WDC WD800JB-00CRA1
Serial Number: WD-WMA8E2420882
Firmware Revision: 17.07W17
Standards:
Supported: 5 4 3 2
Likely used: 6
Ich denke, das kann man entspannt sehen.
Kristian
Am Dienstag, 5. August 2003 11:55 schrieb Kristian Koehntopp:
On Tue, Aug 05, 2003 at 11:22:04AM +0200, Matthias Wieser wrote:
Immer dann, wenn einen die verhältnismäßig geringe Geschwindigkeit von Festplatten stört, nämlich beim erstmaligen Lesen, ändert ein großer Cache kaum etwas.
Solange die Frags groß genug sind (größer als der Read-Ahead des Kernels, besser so groß wie eine Spur, noch besser größer als der Cache der Platte), interessiert es nicht, ob eine Datei fragmentiert ist.
Ich habe hier nicht von Dateifragmentierung geredet.
[ Meine Desktop-Kiste mit 1 GB RAM, davon 720 MB Cache ]
Da mag bei Dir so sein, bei vielen anderen (den meisten?!) läuft (gerade bei den derzeitigen Temperaturen) ihr PC maximal ein paar Stunden am Stück.
Das reicht aus, um den Cache aufzuheizen. Diese Personen verwenden in der Regel auch weniger viele unterschiedliche Programme als ich das im Laufe einer Laufzeit meines Rechners mache. So ergibt sich ein ähnliches Bild, oft schon nach 15 Minuten, jedoch auf einem entsprechend niedrigeren Niveau.
Wie ich schon geschrieben hatte: Es ist IMHO irrelevant, daß der zweite Start von OOo oder Mozilla oder KDE aus dem Cache abläuft. Es gibt immer einen ersten Start, der eben manchmal zu lange braucht und die Leute dadurch stört.
- oder wenn die Partition recht voll ist
Besser: Größere Platte kaufen.
Genau. Oder gleich einen neuen Computer. ;-)
- wenn es einem beim Lesen von z.B. CD Images auf maximalen Durchsatz ankommt
Ähem, 50x Speed = 7.500 KB/sec.
Zum Vergleich: [Tolle "Messwerte" von Kristians Festplatten]
Ich denke, das kann man entspannt sehen.
Zwar weiß ich nicht, was die Angabe der 7.5MB/s soll, aber da moderne Festplatten (wie auch in deinen Beispielen) mehr als 40MB/s übertragen, finde ich es unbefriedigend mehr als eine halbe Minute auf das Lesen eines 800MB CD Images warten zu müssen. Genau das hat Reiserfs aber bei mir gamacht (~1,5min). Wenn man sich dann die Festplattenzugriffe visualisiert hat, hat man schön gesehen, daß die Übertragungsrate genau zu der Zeit von anfänglich ~40MB/s auf unter 5 MB/s eingebrochen ist, als die Lesekopfpositionierungen extrem (>100/sek) anstiegen. (Andere Festplattenzugriffe während des lesens waren vernachlässigbar selten) Es ist ja rührend, daß das Dateisystem tausende Lücken mit dem CD Image aufgefüllt hat, performant war es aber nicht. Ein Cache oder irgendeine Readaheadtaktik hat daran offensichtlich auch nichts ändern können. Was ich sagen möchte: Es macht keinen Sinn, jegliche Vorteile einer vernünftigen Anordnung von Daten abzustreiten¹. Man muss aber zwischen Server- als auch Desktop Einsatz unterscheiden. "Eine vernünftige Anordnung" muss nicht "defragmentieren" heißen, sondern kann auch schon eine sinnvolle Partitionierung der Festplatte sein, die die zurückzulegenden Lesekopfwege minimiert. Matthias Ach, ja, ich lese die Mailinglisten, die ich beziehe. Eine Kopie Deiner Antwort an meine Emailadresse ist also unnötig, danke. ¹Ein einziges Gegenbeispiel reicht, um das formal zu zeigen.
NiX - Erich Troxler wrote:
Gibt es sowas unter Linux auch?
Reiser4 wird wohl ein entsprechendes Tool mitbringen. ( http://lwn.net/Articles/41652/ - Noch nicht umsonst verfuegbar...)
Was ist am besten?
Schwer zu sagen. Es koennen bei einigen Dateioperationen die bestehenden Fragmentierungen wieder aufgeloest werden. Insgesamt ist das Linux ext2 filesystem sehr unanfaellig gegen Fragmentierung, so das sich der Desktop-Linux-Benutzer darum keine Sorgen machen muss. -- Have fun, Peter
On Sun, Aug 03, 2003 at 04:48:14PM +0200, Peter Wiersig wrote:
NiX - Erich Troxler wrote:
Gibt es sowas unter Linux auch?
Reiser4 wird wohl ein entsprechendes Tool mitbringen. ( http://lwn.net/Articles/41652/ - Noch nicht umsonst verfuegbar...)
Das ist zu guten Teilen etwas anderes. Reiser4 ist eine Wiederaufwärmung der Ideen zum Thema LFS (Log-Structured File System) von Margo Seltzer aus dem BSD-Team, so wie ext2 eine Wiederaufwärmung der Ideen von Margo Seltzer zum Thema ffs/ufs ist. Reiser4 ist genauso eine Verallgemeinerung von LFS, wie ext2 eine Verallgemeinerung von ffs/ufs ist. BSD LFS ist ein Dateisystem, das nicht "ein Log hat", wie ext3, Reiser3, XFS oder JFS, sondern das ein Log ist. Das bedeutet, daß alle Schreibzugriffe auf die Platte immer "hinten angehängt" werden. Wenn eine Datei überschrieben wird, überschreibt LFS nicht, sondern hängt eine Kopie der geänderten Blöcke bzw. der ganzen Datei hinten an und markiert die Kopie vorne als ungültig. Wenn die Platte voll ist, werden die als ungültig markierten und damit freien Teile der Platte vorne wieder beschrieben. Damit das funktioniert, muß ein Aufräumprozeß laufen, der die freien Teile der Platte vorne ein wenig zusammenschiebt. Außerdem muß das Dateisystem eine Idee davon haben, welche Dateien "heiß" sind, also oft geändert werden und welche Dateien "kalt" sind, also ewig liegen bis das die Zeit den Tod besiegt. LFS teilt dazu die Platte in Zonen ein (ähnlich den Block Groups in ext2 oder den Cylinder Groups in ffs) und markiert diese als kalte und heiße Zonen. Es verwendet die Platte nicht wirklich umlaufend, wo oben dargestellt, sondern es verwendet bevorzugt umlaufend die heißen Zonen. Der Aufräumprozeß fegt dann nur noch die heißen Zonen aus. LFS hatte in vielen Dingen eine bessere Performance als BSD ffs, hat aber vollkommen versagt, wenn auf dem LFS eine Datenbankdatei oder eine andere Datei lag, die datenbankartig beschrieben wurde (also in der mit fseek und write operiert wurde). Reiser4 hat ähnliche Probleme, auch wenn Hans Reiser da eine ganze Reihe von Verbesserungen vorgenommen hat. LFS hat sich nicht durchgesetzt, unter anderem weil Larry McVoy (der Bitkeeper-Typi, der damals noch bei Sun gearbeitet hat) sich den ffs-Code mal vorgenommen hat und dort nach Investition von jeder Menge Hirnschmalz ca. 50 Zeilen geändert hat. Mit dieser Änderung (die im wesentlichen kleine Teile einer Idee enthält, die eines der vielen guten Fundamente von SGI XFS sind) macht das neue FFS das LFS dann in jedem Benchmark fertig. Das ist sehr frustrierend für das Team um Margo Seltzer gewesen - FFS ist ihr Baby gewesen und weil es ihnen zu schlecht performt hat, haben sie LFS erfunden - während jemand anders genau das Problem mit 50 Zeilen aus dem Weg räumt, das Ursache für die Erfindung von LFS war... Es dokumentiert nicht nur, daß Kernelhacken zwar aussieht wie Userlandprogrammierung, aber in Wirklichkeit eine ganz andere Sportart ist. Es zeigt auch, daß Larry zwar auf der LKML ein arrogantes Arschloch ist, daß er sich das aber auch berechtigt erlauben kann, weil er um Größenordnungen genialer als der durchschnittliche Standardentwickler ist. Wer es selber lesen will: BSD84 McKusick, Karels, Leffler, ,,A Fast File System for UNIX``, ACM Transactions on Computer Systems, Vol. 2, No. 3, August 1984, Seiten 181-197 Das ist das originale FFS-Paper. Ou88 Ousterhout, Douglis, ,,Beating the I/O Bottleneck: A Case for Log Structured File Systems``, UCB/CSD 88/467, Computer Science Division (EECS), University of California, Berkeley, October 1988 Das ist die originale Idee zu LFS von Ousterhout (der, der auch TCL/Tk erfunden hat). Ou90 Ousterhout, ,,Why Aren't Operating Systems Getting Faster As Fast As Hardware?``, Proceedings of the USENIX 1990 Summer Conference, Anaheim, 1990 Ousterhout trommelt noch mal für LFS. Ro91 Rosenblum, Ousterhout, ,,The Design and Implementation of a Log-Structured File System``, Proceedings of the Symposium on Operating System Principles, Monterey, Oktober 1991 Ousterhout wieder mit "Wie geil ist unser LFS?" BSD93 Seltzer, Bostic, McKusick, Staelin, ,,An Implementation of a Log-Structured File System for UNIX``, Proceedings of the USENIX 1993 Summer Conference, San Diego, 1993 Das ist das LFS-Paper, mit einer LFS-Implementierung für BSD. Vo91 Larry McVoy, S.R. Kleiman, ,,Extent-like Performance from a UNIX File System``, Proceedings of the USENIX 1991 Winter Conference, Dallas, 1991, Seiten 33-44 Das ist Larry mit dem 50 Zeilen-Patch. Se95a Margo Seltzer, Keith A. Smith et. al., ,,File System Logging Versus Clustering: A Performance Comparison``, Proceedings of the USENIX 1995 Annual Technical Conference, Kalifornien, 1995 Margo schmollt (natürlich akademisch nur zwischen den Zeilen): "Lohnt LFS? Naja, wir haben es getuned, und es performt ganz ordentlich, aber Larry hinter den fünfzig Platten, mit den fünfzig Zeilen Patch performt noch viel besser als wir. 5 Jahre Forschung für was?" Se96 Margo Seltzer, Keith A. Smith, ,,A Comparison of FFS Disk Allocation Policies``, Proceedings of the USENIX 1996 Annual Technical Conference, San Diego, 1996 Margo macht wieder FFS... Sw96 Adam Sweeney et.al., ,,Scalability in the XFS File System``, Proceedings of the USENIX 1996 Annual Technical Conference, San Diego, Januar 1996 Die Antwort auf die Frage "Kristian, warum findest Du XFS so genial und warum will man kein anderes Dateisystem benutzen?"
Was ist am besten?
Schwer zu sagen. Es koennen bei einigen Dateioperationen die bestehenden Fragmentierungen wieder aufgeloest werden.
Insgesamt ist das Linux ext2 filesystem sehr unanfaellig gegen Fragmentierung, so das sich der Desktop-Linux-Benutzer darum keine Sorgen machen muss.
Yep. Siehe dazu den bereits zitierten SDB-Eintrag. Kristian
participants (7)
-
Frieder Simmeth -
Harald_mail＠t-online.de -
Illuminatus＠t-online.de -
Kristian Koehntopp -
matthias-wieser＠t-online.de -
NiX - Erich Troxler -
Peter Wiersig