und wohl auch NTFS
Leider nein, NTFS versucht die Dateien möglichst linear abzuspeichern. Was MS übrigens schon zugegeben hat, dass dies nicht von Vorteil ist. (haben sich ja lange genug gewehrt)
mfg
mythos
Anmeldungsdatum: Beiträge: 1080 |
Leider nein, NTFS versucht die Dateien möglichst linear abzuspeichern. Was MS übrigens schon zugegeben hat, dass dies nicht von Vorteil ist. (haben sich ja lange genug gewehrt) mfg |
Ehemaliger
(Themenstarter)
Anmeldungsdatum: Beiträge: 28954 Wohnort: WW |
Hallo, ok, das ist schon besser. Habe den Artikel in der Einleitung um einen Abschnitt ergänzt und die Links von chrissss dazu genommen. Wahrscheinlich werden nie alle mit dem Artikel glücklich sein, wobei die Kernaussage ja die erste Hinweis-Box ist. 😉 @chrissss:
Was ist das denn? Ich glaube, ich will es garnicht wissen. Oder "anal" hat noch eine andere Bedeutung, die ich nicht kenne... Gruß, noisefloor |
Anmeldungsdatum: Beiträge: 1080 |
Muss ich wieder anfangen zu erklären, oder kommt ihr selber auf den Fehler? weder verhindert ext3 eine Fragmentierung, noch ist eine geringe Fragmentierung das primäre Ziel.
Fragmentierung ist nicht böse und auf I/O-Lastigen Systemen verwendet man aus diesen Gründen auch kein ext3.
nicht zwingend? Es bringt garantiert nichts. mfg |
Anmeldungsdatum: Beiträge: 2870 |
mythos hat geschrieben:
Die Seektime steigt dabei effektiv garnicht, denn die Daten liegen quasi nie 'passend', egal ob fragmentiert oder nicht. mythos hat geschrieben:
Natürlich werden kleinere Dateien wie Dokumente, etc, ganz gelesen. mythos hat geschrieben:
Und da heute meist viele Prozesse auf viele Dateien gleichzeitig zugreifen, stört Fragmentierung weniger als früher - bis hin zu garnicht in Extremfällen. mythos hat geschrieben:
Also wenn man einfach einen Film schaut, und nicht will, dass die Festplatte die ganze Zeit rattert. |
Anmeldungsdatum: Beiträge: 37971 |
|
Anmeldungsdatum: Beiträge: 2870 |
Chrissss hat geschrieben:
..weil dann jede Erweiterung der Datei dazu führt dass sie fragmentiert - also nicht mehr aus einem Stück besteht. 😉 Deshalb hat ext4 nun extents (wie andere System auch...) - also Freiraum hinter den Dateien, damit die Raum zu Wachsen haben. Scheint also doch wünschenswert zu sein dass Dateien in einem Stück vorliegen, sonst würden die Entwickler das wohl kaum einbauen. Wirklich wichtig wird es vor allem bei der Datenrettung. |
Anmeldungsdatum: Beiträge: 1080 |
Bei einer komplett neuen Parition mit genügend Speicherplatz und wenig I/O, wie sie beim Desktopbetrieb vorkommt, ist das genau das veralten, was man nicht möchte. Man liest eine große Datei ein, ein Prozess kommt dazwischen, die Seektime ist extrem, da vielleicht ein GB übersprungen werden muss und dann auch noch wieder zurück, damit weitergelesen werden kann. Ist das etwa das Verhalten, was du dir wünscht?
Niemand spricht hier von kleinen Dateien. Kleine Datein sind wie Fragmente einer großen Datei anzusehen.
Die Fragmentierung stört nicht, sie ist gewollt und HILFT.
Ja, weil kein Logging stattfindet, der IM nicht läuft, usw usw ... Die HDD rattert doch nicht, sie muss nur von Fragment zu Fragment springen. Damit dir das nicht auffällt werden Caching-Mechanismen verwendet. Es ändert sich das Verhalten einer HDD überhaupt nicht. Der Vorteil vom vorausschaunden Fragmentieren ist bloß ein viel besser einschätzbares Gesamtverhalten. mfg |
Anmeldungsdatum: Beiträge: 37971 |
Das macht auch ext3 auch heute schon, siehe http://geekblog.oneandoneis2.org/index.php/2006/08/17/why_doesn_t_linux_need_defragmenting Vorraussetzung ist jedoch nunmal ausreichend Platz auf der Platte... |
Anmeldungsdatum: Beiträge: 2870 |
"Chrissss"Das macht auch ext3 auch heute schon[/quote hat geschrieben:
|
Anmeldungsdatum: Beiträge: 37971 |
Doch 😉 ext4 reserviert tatsächlich Speicherplatz, eben die Extents. ext3 lässt Speicherplatz zwischen Dateien frei. Diese Funktionalität ist also in beiden Dateisystemen gegeben, in ext4 ist sie jedoch garantiert. Btw, die englische Wikipedia tangiert das Thema ebenfalls Für den Endanwender zuhause sind das Szenarien, die einfach nicht relevant sind. |
Anmeldungsdatum: Beiträge: 2870 |
mythos hat geschrieben:
Doch, eigentlich schon. mythos hat geschrieben:
Das ist völlig normal und passiert erst recht bei fragmentierten Dateien. mythos hat geschrieben:
Prima. Dann hast Du ja verstanden warum Fragmentierung böse ist: mythos hat geschrieben:
Erklär das bitte den Enwicklern von ext4, damit sie von ihren Irrungen auf den rechten Pfad zurückfinden. mythos hat geschrieben:
Richtig. Das Programm und die meisten Daten liegen im Cache und der Rechner greift eigentlich nur für den Datenstream auf die Platte zu. mythos hat geschrieben:
Also seekt sie, also rattert sie. mythos hat geschrieben:
Dazu werden vor allem Methoden wie NCQ verwendet, um die Bewegungen des Lesekopfes zu glätten. mythos hat geschrieben:
Ja, wenn man alle Blöcke zufällig über die Platte verteilt hat man die Garantie, dass man die schlechtst-mögliche Leistung hat: |
Anmeldungsdatum: Beiträge: 37971 |
Btw, auch sehr interessant...
|
Anmeldungsdatum: Beiträge: 1080 |
Ja natürlich dreht sich immer alles um die Fragmentierung. Wachsende Dateien sind ein Problem, überfüllte Festplatten ebenso, da dann die optimale Fragmentierung nicht mehr vorhanden ist. Die Online-Defragmentierung soll _nicht_ die Fragmentierung primär reduzieren, sondern die Fragmente wieder so anordnen, sodass man wieder ein garantiertes Verhalten erreicht. Wie gesagt, ist das bei ext3 nur auf sehr I/O lastigen Systemen ein Problem. Beim Desktop ist das Thema eigentlich nicht existent. mfg |
Anmeldungsdatum: Beiträge: 2870 |
Chrissss hat geschrieben:
Wo ist das Verhalten beschrieben? Chrissss hat geschrieben:
Der Endanwender füllt seine Platte bis zum Anschlag und betreibt munter P2P.
|
Anmeldungsdatum: Beiträge: 1080 |
Wer redet denn hier von zufällig? Die Seektime nähert sich einem Durchnschnittswert an, der weit entfernt von der Random Seektime ist. Zum Rest schreibe ich gar nichts mehr, da mir die Zeit zu schade ist, alles zu beantworten (die Zeit fehlt mir sogar für diesen Post). Bei Gelegenheit schreibe ich den Artikel um. mfg |