Fragmentierung gibt's unter Linux (Reiser) nicht
Timo Nentwig
Leuchtet mir nicht so recht sein. Reiser mag zwar schau sein, wie er wo
welches files anlegt, aber Fragmentierung ist doch ein unvermeidliches
Problem, vor allem bei großen (riesigen ;) files und weniger werdendem
space auf der Platte.
Oder defragmentiert sich das file system selbstständig im Hintergrund, wenn
die Büchse idlet?
Wenn nein, wieso gibt es keine Defragmentierer in der ganzen weiten
Un*x-Welt, bzw. warum gibt's jetzt plötzlich einen von OO (ext2/3)?
Knut Rauscher
Hallo,
Defragmentierung ist Zeitverschwendung. Ziehe dir dafür folgende
Beschreibung von Kristian Koehntopp rein.
http://pc06.physik.uni-jena.de/sdb/de/html/ext2frag.html
Gruß
Knut
Timo Nentwig
> Defragmentierung ist Zeitverschwendung. Ziehe dir dafür folgende
> Beschreibung von Kristian Koehntopp rein.
>
> http://pc06.physik.uni-jena.de/sdb/de/html/ext2frag.html
Das war Zeitverschwendung.
Konkret interessiert mich u.a. die Defragmentierung von partition files, die
locker mehrere GBytes gross sind.
Malte J. Wetz
> Leuchtet mir nicht so recht sein. Reiser mag zwar schau sein, wie er
> wo welches files anlegt, aber Fragmentierung ist doch ein
> unvermeidliches Problem, vor allem bei großen (riesigen ;) files und
> weniger werdendem space auf der Platte.
Siehe: http://sdb.suse.de/de/sdb/html/ext2frag.html
> Oder defragmentiert sich das file system selbstständig im Hintergrund,
> wenn die Büchse idlet?
Nope. Ist unnötig, s.o.
> Wenn nein, wieso gibt es keine Defragmentierer in der ganzen weiten
> Un*x-Welt
Weil man sowas nicht braucht?
> bzw. warum gibt's jetzt plötzlich einen von OO (ext2/3)?
Hmm... Schlangenöl-Software. Es gibt ja auch PersonalFirewalls. Du
kannst aber von mir auch einen Sheng-Pfui-Kristall bekommen, dessen
Aura Deinen PC vor den schädlichen Auswirkungen der ext2-Fragmentierung
*und* Erdstrahlen *und* Entführungen durch Ausserirdische schützt. Nur
99,95 zzgl. Versandkosten.
--
Malte J. Wetz <spa...@malte-wetz.de>
http://www.malte-wetz.de
PGP/GPG keys available on homepage
Rainer Haessner
"Timo Nentwig" <t...@spamgourmet.com> schrieb:
Selbstverstaendlich fragmentiert auch ReiserFS, wie jedes andere
Filesystem auch. Ob eine Defragmentierung Zeitverschwendung ist,
wie in vielen Beitraegen hier behauptet, haengt ganz entscheidend
von der Plattennutzung ab. Um ein paar Dokumente zu bearbeiten,
ist die Fragmentierung der Platte egal.
Sobald es aber um Echtzeitfragen geht, ist das Ganze nicht mehr
gleichgueltig, vor allem, wenn es sich noch um IDE-Platten ohne
TCQ-Faehigkeiten handelt. Das betrifft beispielsweise Videobearbeitungen
oder wie in unserem Fall der Kommunikation mit einem NMR-
Spektrometer.
Fuer Reiser gibt es derzeit kein Deframentierungstool. Es haette
freilich auch nur Sinn, wenn es am gemounteten Filesystem
arbeiten koennte. Ansonsten kann man ja gleich unmounten,
alles zwischenspeichern und dann die Daten neu anlegen.
Da sieht es bei Reiser ganz traurig aus.
Nicht einmal ein Filesystemcheck ist im gemounteten Zustand
moeglich!
Uebrigens ist die ganze Diskussion so neu nicht. XFS von SGI
kam am Anfang ganz ohne Reparaturwerkzeuge. Weil es ja nicht
kaputt gehen konnte. Nur dem XFS hat das niemand erzaehlt.
Nachdem dann xfs_repair etwa 1 Jahr spaeter nachgereicht wurde,
gab es viele Jahre kein Defragmentierungstool. Weil man das ja
nicht benoetigt, siehe oben. Ein xfs_fsr ist dann aber seit zwei
Jahren auch verfuegbar.
Vielleicht wird Reiser ja auch noch ein mal erwachsen. Zumindest
ein online-check ist die allermindeste Forderung.
Rainer Haessner
Markus Raab
> welches files anlegt, aber Fragmentierung ist doch ein unvermeidliches
> Problem, vor allem bei großen (riesigen ;) files und weniger werdendem
> space auf der Platte.
Die Platzierung der Dateien auf der Festplatte ist so intelligent, dass bei
vertretbarer Auslastung keine Fragmentierung stattfindet.
Das System legt die Dateien in einen Bereich wo links und rechts davon viel
Platz zur erweiterung frei ist. D.h. nur sehr große Dateien und bei voller
Festplatte ist die Fragmentierung vorhanden. Große Dateien müssen aber
sicherlich nicht unbedingt so performant gelesen werden, da es sich da sowieso
nur um Videos, Backups und dergleichen handelt.
Zudem hat die Fragmentierung nur eine begrenzte Auswirkung auf die Performance,
da das Dateisystem eine Datenbank ist und dadurch Dateien so schnell gefunden
werden, dass die paar nanosekunden zum Platzieren des Lesekopfes fast "egal"
sind.
Ich hoffe ich konnte ein bisschen weiterhelfen. Aber du kannst gerne so viel
Defragmentieren wie du willst. Besser ist aber die Kapazität nicht über so ca.
80 Prozent auslasten (zumindest bei root part, home ist egal)
mfg Markus
Michael Bergbauer
Hast du den Text gelesen?
Hast du den Text verstanden?
--
Michael Bergbauer <mic...@noname.franken.de>
use your idle CPU cycles - See http://www.distributed.net for details.
Visit our mud Geas at geas.franken.de Port 3333
Timo Nentwig
> Du hast zwar Recht, daß es denkbare Plattennutzung gibt, bei der
> schädliche Fragmentierung auftreten kann, aber das fällt überwiegend in
> den Bereich Theorie und ist in der Praxis völlig vernachlässigbar.
Ich hatte unter XP mal ein pagefile mit ca. 15.000 Fragmenten. Das habe ich
dann doch gemerkt.
Und wenn ich MS frage, wieso Windows keine Swap-Partitionen kennt, dann
bekomme ich vermutlich die Antwort, dass ein file nahezu genauso schnell
ist und es in der Praxis gar nicht auffällt... - nur, dass man sich das
Partitionieren eben spart.
Michael Bergbauer
> Ich hatte unter XP mal ein pagefile mit ca. 15.000 Fragmenten. Das habe ich
> dann doch gemerkt.
Ich wuerde hier auf eine vollgelaufene Partition NTFS tippen - das
ist dafuer sehr anfaellig.
Fup2p
Timo Nentwig
> Die Platzierung der Dateien auf der Festplatte ist so intelligent, dass
> bei vertretbarer Auslastung keine Fragmentierung stattfindet.
So intelligent kann das FS gar nicht sein, weil's nicht weiß, was ich mache.
Und wenn ich einen Videostrem mitschneide, dann ist das file hinterher 1MB
oder auch 1GB und dann ist das FS in den Arsch gekniffen.
> Zudem hat die Fragmentierung nur eine begrenzte Auswirkung auf die
> Performance, da das Dateisystem eine Datenbank ist und dadurch Dateien so
OFS?
Rainer Haessner
"Marcus Jodorf" <tr...@killfile.de> schrieb:
> Du hast zwar Recht, daß es denkbare Plattennutzung gibt, bei der
> schädliche Fragmentierung auftreten kann, aber das fällt überwiegend in
> den Bereich Theorie und ist in der Praxis völlig vernachlässigbar.
Jetzt weiss ich zwar nicht, inwieweit unsere Nutzung in den Bereich der
Theorie faellt. Allerdings weiss ich ganz genau, was passiert, wenn
das Spektrometer nicht innerhalb von 30 ms seine Daten los wird.
So Pi*Zeigefinger passiert das bei XFS (IRIX) nach einem Jahr
Nutzung, bei Reiser (Linux) nach der halben Zeit. XFS kann ich
reparieren, Reiser muss ich halt umkopieren und danach ist
alles wieder o.K.
Das Ganze gilt fuer SCSI-Laufwerke. Wie das Ganze unter IDE
aussehen wuerde, kann ich auch nur mutmassen.
> Bei den sehr seltenen Fällen, in denen es vielleicht doch mal auftritt,
> kopiert man einfach einmal um und das Thema ist wieder erledigt.
> Jedenfalls ist das Problem so unbedeutend, daß sich jahrelang noch nicht
> mal jemand um entsprechende Tools zum defragmentieren gekümmert hat.
> War halt schlicht überflüssig.
May be, may not be. Ganz schluessig ist zumindest die Kausalkette
nicht. Es gibt sicher keinen Zweifel, dass ein Tool zum Testen der
Integritaet des Filesystems ohne ein umount fuer einen Fileserver
ein Muss ist. Gibt es aber fuer reiser nicht. Alle Energie ist halt bisher
in das Filesystem selbst geflossen, fuer wichtige Tools hat's noch
nicht gelangt.
Rainer Haessner
florian kriener
> Jedenfalls ist das Problem so unbedeutend, daß sich jahrelang noch nicht
> mal jemand um entsprechende Tools zum defragmentieren gekümmert hat.
> War halt schlicht überflüssig.
>
> Defragmentierungstool für ext2, aber dessen Vorhandensein dürfte sich
> wohl eher auf die merklichen Zahlen von Windowsumsteigern und deren
> leicht vorbelastete Weltsicht erklären.
gibt auch ein os programm:
apt-cache show defrag
Malte J. Wetz
> Jetzt weiss ich zwar nicht, inwieweit unsere Nutzung in den Bereich
> der Theorie faellt. Allerdings weiss ich ganz genau, was passiert,
> wenn das Spektrometer nicht innerhalb von 30 ms seine Daten los wird.
Schlagt mich, wenn ich irre, aber wenn man schon ein
Multiuser/Multitasking-Betriebssystem für Echtzeitanwendungen hernimmt,
sollte man sich dann nicht wenigstens um ausreichende Puffer kümmern?
Das, was Marcus beschrieben hat, steht hier (für ext2) auch nochmal
etwas ausführlicher:
http://groups.google.com/groups?selm=7ec89m$i...@valiant.koehntopp.de
Rainer Haessner
"Malte J. Wetz" <spa...@malte-wetz.de> schrieb:
> > Jetzt weiss ich zwar nicht, inwieweit unsere Nutzung in den Bereich
> > der Theorie faellt. Allerdings weiss ich ganz genau, was passiert,
> > wenn das Spektrometer nicht innerhalb von 30 ms seine Daten los wird.
>
> Schlagt mich, wenn ich irre, aber wenn man schon ein
> Multiuser/Multitasking-Betriebssystem für Echtzeitanwendungen hernimmt,
> sollte man sich dann nicht wenigstens um ausreichende Puffer kümmern?
Das ist wohl voellig korrekt, aber nicht durch den Endanwender
zu beeinflussen. Warum die Software in der derzeitigen Art und Weise
implementiert ist, weiss ich nicht. Die Datenmenge, die innerhalb der
genannten Zeit auf den Weg gebracht werden muss, ist nicht sonderlich
riesig. Normalerweise 4 oder 8 kByte, aber selbst in Extremfaellen
bestenfalls 256 kByte. Die kann man in der Tat bequem puffern.
Ich denke einmal, dass da das schon sehr alte Grunddesign (etwa 20
Jahre) und der bisher fehlende Leidensdruck (solange eine Defragmentierung
hilft ...) eine Rolle spielen. So sehr gern aendert man ja prinzipiell
funktionierende Dinge auch nicht. Bringt wieder eine neue Verzweigung
in die Software und macht die noch unuebersichtlicher.
Ist aber alles nur Vermutung.
Rainer Haessner
Malte J. Wetz
> "Malte J. Wetz" <spa...@malte-wetz.de> schrieb:
>
>> Schlagt mich, wenn ich irre, aber wenn man schon ein
>> Multiuser/Multitasking-Betriebssystem für Echtzeitanwendungen
>> hernimmt, sollte man sich dann nicht wenigstens um ausreichende
>> Puffer kümmern?
>
> Das ist wohl voellig korrekt, aber nicht durch den Endanwender
> zu beeinflussen.
Ramdisk?
Michael Bergbauer
> Hallo,
>
> "Malte J. Wetz" <spa...@malte-wetz.de> schrieb:
>
> > > Jetzt weiss ich zwar nicht, inwieweit unsere Nutzung in den Bereich
> > > der Theorie faellt. Allerdings weiss ich ganz genau, was passiert,
> > > wenn das Spektrometer nicht innerhalb von 30 ms seine Daten los wird.
> >
> > Schlagt mich, wenn ich irre, aber wenn man schon ein
> > Multiuser/Multitasking-Betriebssystem für Echtzeitanwendungen hernimmt,
> > sollte man sich dann nicht wenigstens um ausreichende Puffer kümmern?
>
> Das ist wohl voellig korrekt, aber nicht durch den Endanwender
> zu beeinflussen. Warum die Software in der derzeitigen Art und Weise
> implementiert ist, weiss ich nicht. Die Datenmenge, die innerhalb der
> genannten Zeit auf den Weg gebracht werden muss, ist nicht sonderlich
> riesig. Normalerweise 4 oder 8 kByte, aber selbst in Extremfaellen
> bestenfalls 256 kByte. Die kann man in der Tat bequem puffern.
Also ich kann mir beim bestenn willen nicht vorstellen, dass
Fragmentierung hier ne Rolle spielt. Ausser du hast nen 386 und schreibst
auf Diskette.
Rainer Haessner
"Michael Bergbauer" <nos...@nospam.franken.de> schrieb:
> > Das ist wohl voellig korrekt, aber nicht durch den Endanwender
> > zu beeinflussen. Warum die Software in der derzeitigen Art und Weise
> > implementiert ist, weiss ich nicht. Die Datenmenge, die innerhalb der
> > genannten Zeit auf den Weg gebracht werden muss, ist nicht sonderlich
> > riesig. Normalerweise 4 oder 8 kByte, aber selbst in Extremfaellen
> > bestenfalls 256 kByte. Die kann man in der Tat bequem puffern.
>
> Also ich kann mir beim bestenn willen nicht vorstellen, dass
> Fragmentierung hier ne Rolle spielt. Ausser du hast nen 386 und schreibst
> auf Diskette.
Kein Problem. Einfach vorbeikommen und etwa 2 Monate warten
(habe sieben Spektrometer). ;-)
Es ist einfach so, dass die genannten Bloecke an ein grosses
File angehaengt werden und natuerlich erst mal dessen Ende
gesucht werden muss. Die 8 kByte addieren sich bei einer
3D- oder 4D-Messung schon mal auf 50 ... 200 MByte.
Rainer Haessner
Rainer Haessner
"Heiko Schlenker" <hsc...@gmx.de> schrieb:
> > Allerdings weiss ich ganz genau, was passiert, wenn das
> > Spektrometer nicht innerhalb von 30 ms seine Daten los wird.
>
> Äh, für Echtzeitanwendungen ist ein handelsübliches Linux *nicht*
> geeignet.
Doch, ist es. Ein paar tausend Spektrometer weltweit inklusive
der Kontrollrechner sind der Beweis. Das Filesystem darf halt
nicht stark fragmentiert sein, weshalb dieser Job im Falle von IRIX als
Computerplattform auch regelmaessig per cron ablaeuft.
Unter IRIX geht das live.
Rainer Haessner
Michael Bergbauer
> Kein Problem. Einfach vorbeikommen und etwa 2 Monate warten
> (habe sieben Spektrometer). ;-)
> Es ist einfach so, dass die genannten Bloecke an ein grosses
> File angehaengt werden und natuerlich erst mal dessen Ende
> gesucht werden muss. Die 8 kByte addieren sich bei einer
> 3D- oder 4D-Messung schon mal auf 50 ... 200 MByte.
Au weh, du hast recht. Da ist wirklich das Grundkonzept kaputt.
Kai Dupke
> Sobald es aber um Echtzeitfragen geht, ist das Ganze nicht mehr
> gleichgueltig, vor allem, wenn es sich noch um IDE-Platten ohne
> TCQ-Faehigkeiten handelt. Das betrifft beispielsweise Videobearbeitungen
> oder wie in unserem Fall der Kommunikation mit einem NMR-
> Spektrometer.
Du definierst gerade eher ein Problem mit Deiner Hardware.
Kai Dupke
> Warum die Software in der derzeitigen Art und Weise
> implementiert ist, weiss ich nicht.
Und da beschwerst Du Dich über ein aktuelles Dateisystem?
Wie wär's Du schreibst in eine Pipe?
Matthias Wieser
> Das System legt die Dateien in einen Bereich wo links und rechts davon
> viel Platz zur erweiterung frei ist. D.h. nur sehr große Dateien und
> bei voller Festplatte ist die Fragmentierung vorhanden.
... und bei häufig genutzten Partitionen, da dort keine großen, sondern
nur sehr viele kleine freie Bereiche vorkommen.
> Große Dateien
> müssen aber sicherlich nicht unbedingt so performant gelesen werden, da
> es sich da sowieso nur um Videos, Backups und dergleichen handelt.
Aber wenn die hunderten Dateien von z.B. OpenOffice zwar unfragmentiert,
aber gleichmäßig über die ganze Partition verteilt sind, kann das
Starten von OO schon mal um den Faktor 10 länger dauern.
> Zudem hat die Fragmentierung nur eine begrenzte Auswirkung auf die
> Performance, da das Dateisystem eine Datenbank ist und dadurch Dateien
> so schnell gefunden werden, dass die paar nanosekunden zum Platzieren
> des Lesekopfes fast "egal" sind.
Bei der Positionierungszeit des Lesekopfes hast Du dich etwa um den
Faktor 1000 vertan. Eine moderne Festplatte überträgt dank über 50Mb/s,
wenn die Daten hintereinander liegen. Aber nur ein zehntel bis ein
hundertstel, wenn die Daten wild über die Partition verteilt sind (wie
es die meisten Dateisysteme tun).
Viele Grüße,
Matthias
Matthias Wieser
> Hast du den Text gelesen?
> Hast du den Text verstanden?
Kristian beschreibt ausführlich, daß sich allgemein für den Multitasking-
und mehr noch für Serverbetrieb das defragmentieren von ext2 und Co
nicht lohnt.
Bei reiner Desktopnutzung kann der Geschwindigkeitsnachteil von wild auf
der Partition verteilten Dateien schon merkbar sein.
Viele Grüße,
Matthias
Michael Bergbauer
> Kristian beschreibt ausführlich, daß sich allgemein für den Multitasking-
> und mehr noch für Serverbetrieb das defragmentieren von ext2 und Co
> nicht lohnt.
>
> Bei reiner Desktopnutzung kann der Geschwindigkeitsnachteil von wild auf
> der Partition verteilten Dateien schon merkbar sein.
Aber genau das passiert ja nicht - im Normalfall sind die Bloecke nicht
wild auf der Platte verteilt. Aus eben den von Kristian angefuehrten
Gruenden.
Michael Bergbauer
> Markus Raab wrote:
>
> > Zudem hat die Fragmentierung nur eine begrenzte Auswirkung auf die
> > Performance, da das Dateisystem eine Datenbank ist und dadurch Dateien
> > so schnell gefunden werden, dass die paar nanosekunden zum Platzieren
> > des Lesekopfes fast "egal" sind.
>
> Bei der Positionierungszeit des Lesekopfes hast Du dich etwa um den
> Faktor 1000 vertan.
Wo kann man solche Platten kaufen? AFAIK sind die Seek-Zeiten im
ms-Bereich, und das waere Faktor 10^6 zu ns.
Joern Seemann
> Wenn nein, wieso gibt es keine Defragmentierer in der ganzen weiten
> Un*x-Welt, bzw. warum gibt's jetzt plötzlich einen von OO (ext2/3)?
Den gibt es schon lange, allerdings überschätzt Du den Faktor
Fragmentierung.
Gruss Jörn
--
Wir ertrinken in Information, aber hungern nach Wissen - John Naisbitt
Matthias Wieser
> Matthias Wieser <matthia...@gmx.de> writes:
>
>> Bei der Positionierungszeit des Lesekopfes hast Du dich etwa um den
>> Faktor 1000 vertan.
>
> Wo kann man solche Platten kaufen? AFAIK sind die Seek-Zeiten im
> ms-Bereich, und das waere Faktor 10^6 zu ns.
Stimmt. Da hab dann auch ich mich um den Faktor 1000 vertan.
Viele Grüße,
Matthias
Matthias Wieser
> Matthias Wieser <matthia...@gmx.de> writes:
>
>> Kristian beschreibt ausführlich, daß sich allgemein für den
>> Multitasking- und mehr noch für Serverbetrieb das defragmentieren von
>> ext2 und Co nicht lohnt.
>>
>> Bei reiner Desktopnutzung kann der Geschwindigkeitsnachteil von wild
>> auf der Partition verteilten Dateien schon merkbar sein.
>
> Aber genau das passiert ja nicht - im Normalfall sind die Bloecke nicht
> wild auf der Platte verteilt. Aus eben den von Kristian angefuehrten
> Gruenden.
Ich habe nicht geschrieben, daß *eine* Datei fragmentiert ist, sondern,
daß mehrere, logisch zusammengehörende Dateien wild verteilt sein können
(und auch meist sind). Kristians Ausführungen besagen nur, daß ext2 u.a.
ganze 16kB (!) Platz für zukünftiges Wachstum der einzelnen Dateien
lässt und damit die Fragmentierung einzelner Dateien etwas entschärft.
Daß beim Starten von OpenOffice die meiste Zeit für Lesekopfbewegungen
drauf geht, weil z.B. das nächste Toolbar-icon nicht vom Readahead Cache
der Platte erfasst wird, sondern am anderen Ende der Partition liegt,
wird von keinem mir bekannten Linux Dateisystem verhindert.
Viele Grüße,
Matthias
Herbert Pophal
>
> "Malte J. Wetz" <spa...@malte-wetz.de> meinte am 09 Jun 2003:
>
> > Hmm... Schlangenöl-Software. Es gibt ja auch PersonalFirewalls. Du
*LOL*
> > kannst aber von mir auch einen Sheng-Pfui-Kristall bekommen,
> > dessen Aura Deinen PC vor den schädlichen Auswirkungen der
> > ext2-Fragmentierung *und* Erdstrahlen *und* Entführungen durch
> > Ausserirdische schützt. Nur 99,95 zzgl. Versandkosten.
>
> Boa geil!!!
>
> Wie weit wirkt der Kristall denn? Ich hab 3 Rechner nebeneinander
> stehen. Werden die durch einen Kristall geschützt, oder muss ich für
Bitte poste die Entfernung zwischen den Rechnern, das dürfte MAlte
helfen.
Herbert
Malte J. Wetz
> "Malte J. Wetz" <spa...@malte-wetz.de> meinte am 09 Jun 2003:
>
>> Hmm... Schlangenöl-Software. Es gibt ja auch PersonalFirewalls. Du
>> kannst aber von mir auch einen Sheng-Pfui-Kristall bekommen,
>> dessen Aura Deinen PC vor den schädlichen Auswirkungen der
>> ext2-Fragmentierung *und* Erdstrahlen *und* Entführungen durch
>> Ausserirdische schützt. Nur 99,95 zzgl. Versandkosten.
>
> Wie weit wirkt der Kristall denn? Ich hab 3 Rechner nebeneinander
> stehen. Werden die durch einen Kristall geschützt, oder muss ich für
> jeden Rechner einen eigenen aufstellen?
Der normale Kristall für 99,95 wirkt nur für einen Rechner. Bei mehr als
einem Rechner kannst Du für supergünstige 199,95 die extragrosse
Server-Inkarnation bekommen, die schützt alle Rechner in einem Raum.
Bonus: Zwei am Kristall befestigte RJ45-Buchsen machen ihn, vor das
externe Netzinterface gestöpselt, zu einer garantiert absolut sicheren
Firewall und schützen so auch noch vor bösen Hackerangriffen!
> Bitte um Zusendung der benötigten Menge.
Klar doch. Schick mir Deine Adresse per PM, dann geht das diese Woche
noch per Nachnahme raus.
Und die ersten 100 Besteller erhalten noch die CD "Best Of Johannes
Sackmann" gratis dazu!
F'up2p, da leicht OT
Ralf Muschall
> Jetzt weiss ich zwar nicht, inwieweit unsere Nutzung in den Bereich der
> Theorie faellt. Allerdings weiss ich ganz genau, was passiert, wenn
> das Spektrometer nicht innerhalb von 30 ms seine Daten los wird.
Einfache Idee (falls Ramdisk nicht reicht): Kleine Partition für die
Daten anlegen, diese nächtlich per cron umkopieren und leeren.
Abgesehen davon würde ich für wenige, große Files nicht unbedingt
Reiser nehmen (bei mir darf der nur an /var/spool/news ran).
Ralf
--
GS d->? s:++>+++ a+ C++++ UL+++ UH++ P++ L++ E+++ W- N++ o-- K- w--- !O M- V-
PS+>++ PE Y+>++ PGP+ !t !5 !X !R !tv b+++ DI+++ D? G+ e++++ h+ r? y?
Michael Bergbauer
Bevor wir hier weiterreden, lies dir bitte die technische Beschreibung
aktueller Filessysteme durch. Die haben sehr wohl Methoden, dafuer zu
sorgen, dass z.B nacheinander geschriebene Dateienen (z.B. bei
einer Installation), die noch dazu im selben Verzeichnis liegen auch
in unmittelbarer Naehe auf der Platte laden, sofern die Umstaende es
zulassen.
Es ist nicht so das open.icon am Anfang der Platte ladet und das als
naechste geschriebene close.icon am Ende der Platte, sofern noch
entsprechend Plattenplatz vorhanden ist (Wenn die Platte nahezu voll
ist wird wohl jedes Filessystem Performance-Probleme bekommen,
Mangelverwaltung ist eben nicht das, was man haben will).
Ein guter Einstieg duerften hierzu auch Kristian Koentopps Artikel
zu diesem Thema sein, nur nur der eine bisher zittierte.
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&q=author%3Akoehntopp+fragmentierung&btnG=Google+Search
http://123.koehntopp.de/kris/inkomploehntopp/
Matthias Wieser
>[Blah]
Es geht nicht darum, daß nacheinander geschriebene Dateien nicht
hintereinander angelegt werden. Das hat hier niemend bezweifelt.
Spätestens nach dem zweiten oder dritten Update einer Software liegen
die Dateien aber (zumindest bei meinem Rechner) wild verstreut. Das ist
immer der Fall, wenn zwischen den Updates mit der Partition gearbeitet
wird.
Viele Grüße,
Matthias
Matthias Wieser
> Matthias Wieser <matthia...@gmx.de> schrieb:
>
>> Daß beim Starten von OpenOffice die meiste Zeit für Lesekopfbewegungen
>> drauf geht, weil z.B. das nächste Toolbar-icon nicht vom Readahead
>> Cache der Platte erfasst wird, sondern am anderen Ende der Partition
>> liegt, wird von keinem mir bekannten Linux Dateisystem verhindert.
>
> Du verkennst die Sachlage.
Mal schaun.
> OO ist nicht so katastrophal lahm beim Start, weil da irgendwelche
> Icons gesucht werden, sondern weil da Defizite der unter Linux
> verwendeten Linker zuschlagen.
Meiner Erfahrung nach reagiert OO sehr viel weniger als beispielsweise
KDE auf schnelleres Linken.
> Nicht nur, daß OO endlos viele Libraryzugriffe produziert, die finden
> auch noch in kunterbunter Reihenfolge statt. Selbst wenn die Libraries
> optimal im dem Filesystem liegen, ändert das nichts am Problem, weil
> die Zugriffsmuster so idotisch sind.
Das stimmt vermutlich, schließt aber die Effekte durch die Verteilung der
Dateien nicht aus.
Vielleicht muss ich Startzeiten o.ä. wirklich mal reproduzierbar messen.
Viele Grüße,
Matthias
Rainer Haessner
"Jan Heitkoetter" <use...@heitkoetter.net> schrieb:
>
> [...]
> > Nicht einmal ein Filesystemcheck ist im gemounteten Zustand
> > moeglich!
>
> Ein FS im gemounteten Zustand zu checken ist ja auch nicht gerade klug,
> weshalb auch immer davor gewarnt wird. Google mal in vergangenen
> Postings dieser Gruppe -- du wirst genug Postings von Leuten finden,
> die's wider besseres Wissen gemacht haben und sich böse das FS zerlegt
> haben.
Das mag ja unter Linux gelten. Es gibt aber noch andere Betriebssysteme.
Und fuer einen 24/7-Fileserver ist eine Filesystemcheck im gemounteten
Zustand ein absolutes Muss. Kaputt gehen kann sowieso nichts.
Der Test ist schliesslich r/o. Es sei denn das Testprogramm ist
mangelhaft (oder alternativ eine Katastrophe, wie z.B. reiserfsck -)) ).
Rainer Haessner
Timo Nentwig
> Aber genau das passiert ja nicht - im Normalfall sind die Bloecke nicht
> wild auf der Platte verteilt. Aus eben den von Kristian angefuehrten
> Gruenden.
Nun hör doch mal mit deinem Religionskrieg auf, Soldat. Es ist nicht so,
dass bei MS nur Vollidioten hocken, die Welt ist viel bösartiger.
Fragmentierung ist eine unvermeidliche Tatsache. Wenn ich auch meine Platte
ein 10GB großes files schreiben will, aber das größte zusammenhängende
freie Stück nur 9 GB groß ist, na, was passiert dann? Und ich hoffe, es
bricht nicht gleich dein ganzes Weltbild zusammen, wenn ich dir sage, dass
dasselbe sogar mit RAM passiert.
Verhindern kann das nur Batman (bzw. Bush) - und das auch nur in Hollywood.
Bzw. Fragmentierung ist Propaganda der Matrix!
Und wie der Vorgänger schon richtig bemerkte, wir reden hier von
Desktop-Systemen!
Ich habe inzw. einen Knopf bei VMWare gefunden, mit dem man das image file
defragmentieren kann ;)
Trotzdem danke an dieser Stelle, die Sache mit dem write-ahead etc. war
schon aufschlußreich.
Rainer Haessner
"Marcus Jodorf" <tr...@killfile.de> schrieb:
> > apt-cache show defrag
>
> Ein defrag für ext2 gab es schon ewig. Nur ist das nie so ganz über
> Betastadium hinausgekommen und wurde über zig Jahre hinweg auch von
> niemandem mehr weiterentwickelt.
> Wenn es auch nur irgendein Bedürfnis für so ein Tool gegeben hätte,
> hätte das sicher nicht viele Jahre lang völlig unbeachtet vor sich
> hingegammelt.
Koestliche Beweisfuehrung. Etwa dieser Art:
"Unter der Bastille hat man verrostete Draehte gefunden. Das ist ein
Beweis dafuer, dass damals bereits drahtgebundene Telegrafie
beherrscht wurde. Unter dem Kolosseum hat man keine Draehte
gefunden. Die Roemer kannten folglich bereits die drahtlose
Telegrafie."
Etwas weniger ironisch: die Wege mancher Programmautoren
und ihrer Projekte sind nicht unbedingt logisch nachzuvollziehen.
Nehmen wir ein Beispiel. SciGraphica. Sehr schoener Anfang.
Im wissenschaftlichen Umfeld besteht ganz grosses Beduerfnis
an einer Weiterentwicklung. Die ist aber seit etwa zwei jahren
mit Version 0.8 eingeschlafen. Kein Nachfolger in Sicht.
Bei der Defragmentierung kann man es von hinten angehen.
Fuer XFS (auf IRIX) gibt es seit zwei Jahren ein Defragmentierungs-
tool. Warum wohl? Weil SGI zuviel Geld hat und aus Barm-
herzigkeit ein paar Programmierer beschaeftigt hat?
Rainer Haessner
Friedemann Stoyan
> Aber genau das passiert ja nicht - im Normalfall sind die Bloecke nicht
> wild auf der Platte verteilt. Aus eben den von Kristian angefuehrten
> Gruenden.
Solange nicht LVM im Einsatz ist.
mfg Friedemann
Eric 'EW-Tech' Wick
> Un*x-Welt, bzw. warum gibt's jetzt plötzlich einen von OO (ext2/3)?
Schau den einfach mal genauer an und vergleiche mit Defrag vom Dos. Du
siehst das ext2/3 Dateien zerrissen über die gesamte Partition hinter
Knoten anlagert. Beim defragmentieren ändert sich daran nichts, die
Dateien bleiben über die gesamte Partition hinter den Knoten liegen.
Das Dos Defrag schaufelt stundenlang bis alle Dateien oben liegen,
macht also was anderes.
P.S. Schau mal beim Mounten nach dem Defragmentierungsgrad, bei Linux
steigt er durch draufkopieren großer Dateien und sinkt durch bewegen
kleiner Dateien wieder. Defrag ist etwas worüber sich pubertierende
Jugendliche auf dem Schulhof ausstechen können, oder etwas womit
krause Anbieter dem Nutzer Kohle aus der Tasche ziehen.
Gruß
Eric
--
Advertisement to this mail address is prohibited!
PC Infopage: http://www.ew-tech-hh.de (DE)
Michael Bergbauer
> Michael Bergbauer wrote:
>
> > Aber genau das passiert ja nicht - im Normalfall sind die Bloecke nicht
> > wild auf der Platte verteilt. Aus eben den von Kristian angefuehrten
> > Gruenden.
>
> Nun hör doch mal mit deinem Religionskrieg auf, Soldat.
Nix Religionskrieg.
> Es ist nicht so, dass bei MS nur Vollidioten hocken, die Welt ist
> viel bösartiger.
Hab ich das behauptet? Ich denke, ich hab in diesem Thread an keiner
Stelle das Wort "Microsoft" benutzt. Selbstverstaendlich spielt
Fragmentierung fuer Windows mittlerweile eine ebenso untergeordnete
Rolle wie fuer Unix-Systeme, lediglich zu DOS-Zeiten war Fragmentierung
fuer die Plattform von Microsoft ein Problem.
Leg mir bitte keine Worte in den Mund, die nicht von mir kommen.
> Fragmentierung ist eine unvermeidliche Tatsache. Wenn ich auch meine Platte
> ein 10GB großes files schreiben will, aber das größte zusammenhängende
> freie Stück nur 9 GB groß ist, na, was passiert dann? Und ich hoffe, es
> bricht nicht gleich dein ganzes Weltbild zusammen, wenn ich dir sage, dass
> dasselbe sogar mit RAM passiert.
Das sich Fragmentierung nicht vermeiden laesst ist mir sehr wohl klar,
und Fragmentierung ist auch nicht unbedingt ultraboese - vor allem
dann nicht, wenn man mehrere Prozesse hat, die auf die Platte
zugreiffen wollen.
Haettest du den Kontext meiner Aussage stehen gelassen, dann waere auch
klar, worauf sich die Aussage "Aber genau das passiert ja nicht bezieht",
naemlich auf Feststellung
|Bei reiner Desktopnutzung kann der Geschwindigkeitsnachteil von wild auf
|der Partition verteilten Dateien schon merkbar sein.
> Verhindern kann das nur Batman (bzw. Bush) - und das auch nur in Hollywood.
> Bzw. Fragmentierung ist Propaganda der Matrix!\
Score adjusted.
> Und wie der Vorgänger schon richtig bemerkte, wir reden hier von
> Desktop-Systemen!
Auch auf Desktopsystemen und Linux gibt es in der Regel mehrere Prozesse
mit Zugriffen ins Filesystem. Ich hoffe _dein_ Weltbild bricht jetzt nicht
zusammen.
Fup2poster
Thomas Flaig
> Bei der Defragmentierung kann man es von hinten angehen.
> Fuer XFS (auf IRIX) gibt es seit zwei Jahren ein Defragmentierungs-
> tool. Warum wohl? Weil SGI zuviel Geld hat und aus Barm-
> herzigkeit ein paar Programmierer beschaeftigt hat?
ciao
thomas
--
coming soon...
Markus Raab
> Markus Raab wrote:
>
>> Die Platzierung der Dateien auf der Festplatte ist so intelligent, dass
>> bei vertretbarer Auslastung keine Fragmentierung stattfindet.
>
> So intelligent kann das FS gar nicht sein, weil's nicht weiß, was ich mache.
> Und wenn ich einen Videostrem mitschneide, dann ist das file hinterher 1MB
> oder auch 1GB und dann ist das FS in den Arsch gekniffen.
Schau dir die Algorithmen der FS an, und dann verstehst du es.
Es fragmentiert große Dateien sehrwohl, aber so dass die Performance nicht
einbricht.
mfg Markus
Andreas Haupt
>Bei der Defragmentierung kann man es von hinten angehen.
>Fuer XFS (auf IRIX) gibt es seit zwei Jahren ein Defragmentierungs-
>tool. Warum wohl? Weil SGI zuviel Geld hat und aus Barm-
>herzigkeit ein paar Programmierer beschaeftigt hat?
Es gibt auch wunderbare Lamadecken und Magnetarmringe. Warum wurden die
wohl entwickelt? Ich weiß... weil sie _wirklich_ gebraucht werden ;-)
MfG
--
Andreas Haupt E-Mail: aha...@ifh.de
DESY Zeuthen
Platanenallee 6
15738 Zeuthen
Rainer Haessner
"Andreas Haupt" <aha...@juno.ifh.de> schrieb:
> >Bei der Defragmentierung kann man es von hinten angehen.
> >Fuer XFS (auf IRIX) gibt es seit zwei Jahren ein Defragmentierungs-
> >tool. Warum wohl? Weil SGI zuviel Geld hat und aus Barm-
> >herzigkeit ein paar Programmierer beschaeftigt hat?
>
> Es gibt auch wunderbare Lamadecken und Magnetarmringe. Warum wurden die
> wohl entwickelt? Ich weiß... weil sie _wirklich_ gebraucht werden ;-)
So ein Unfug. Die Dinger werden auf den allseits beliebten Bustouren
verkauft. Neben vielen anderen "nuetzlichen" Dingen. Die Hersteller
verdienen
daran, ganz unabhaengig davon, ob der Kunde einen Nutzen aus den
Produkten ziehen kann. SGI verdient nix. Das genannte Produkt kam
zusammen mit Patch 6.5.12 und den gibts frei fuer jedermann.
Rainer Haessner
Rainer Haessner
"Thomas Flaig" <t....@freenet.de> schrieb:
> > Bei der Defragmentierung kann man es von hinten angehen.
> > Fuer XFS (auf IRIX) gibt es seit zwei Jahren ein Defragmentierungs-
> > tool. Warum wohl? Weil SGI zuviel Geld hat und aus Barm-
> > herzigkeit ein paar Programmierer beschaeftigt hat?
> Weil es sich verkaufen lنكt.
Und wie geht das? Die genannte Software ist ab Patch
6.5.12 Bestandteil von IRIX. Alle Patches sind frei
erhaeltlich.
Rainer Haessner
Malte J. Wetz
> SGI verdient nix. Das genannte Produkt kam zusammen mit Patch 6.5.12
> und den gibts frei fuer jedermann.
Um mal Dein eigenes Argument aus <bc51m8$4p3$01$1...@news.t-online.com>
aufzugreifen: Wenn sie wirklich gar nichts daran verdienen würden,
würden Sie den ganzen Kram kaum entwickeln, nicht wahr? Sie verkaufen
das XFS nicht direkt, verdienen aber z.B. an den daran geknüpften
Produkten und Dienstleistungen (Server mit XFS, Service- und
Wartungsverträge, etc.). Die entsprechenden Einnahmen erhöhen sich
proportional zur Anzahl der Leute, die so etwas wollen. Und die wollen
einen Defragmentierer, weil man den ja braucht. Am besten noch einen
möglichst bunten. :->