Diskussion:Fragmentierung (Dateisystem)/Archiv/1

aus Wikipedia, der freien Enzyklopädie

Artikel unterbrochen?

Wie bei meinem Vorredner, der sich über einen nicht mehr fortgeführten Satz beklagt, geht es auch bei meiner "Beschwerde" um unvollständigkeit... Im Artikel steht:

Die durch unterschiedliche Verfahren bestimmte Fragmentierungsgrade sind nicht vergleichbar; nichteinmal durch gleiche Verfahren bestimmte Fragmentierungen sind vergleichbar, weil die realen Auswirkungen bei vielen Verfahren weiterhin von Blockgröße, durchschnittlicher Dateigröße und Geschwindigkeit des Mediums abhängen.


in denen Köpfe positioniert (Festplatten) oder Blocks umgeschaltet (Flash-Speicher) werden und in denen real gelesen und geschrieben wird. Stark fragmentierte Dateisysteme können die Geschwindigkeit eines Dateisystems auf einen winzigen Bruchteil der theoretisch möglichen Geschwindigkeit reduzieren, indem dieses Verhältnis sehr groß wird.


Irgendwie kann ich mit dieser Aussage nichts anfangen. Da es der zweite Abschnitt den ich hier zitiere auch kleingedruckt weitergeht, nehme ich an, dass jemand wild irgendetwas gelöscht hat... Kann des sein?!? --Jd-fun 21:05, 1. Mai 2006 (CEST)

Stilistische Fehler

Dieser letzte Teil des Artikels enthalt mehrere faktische und stilistische Fehler:

"Grades der Fragmentierung" soll wohl "Grad der Fragmentierung heißen.

"Den Grad der Fragmentierung bestimmt man Messung der Geschwindigkeit des fragmentierten (realen) Dateisystemes gegenüber einem nichtfragmentierten (optimalen) Dateisystems."

Dieser Satz ist irreführend und falsch.

"Aus dieser unterschiedlichen Sichtweise der Messung der Fragmentierung beruht der Mythos, daß Linux-Dateisysteme nicht oder nur gering fragmentieren. Zumindest die klassischen Linux-Dateisysteme Ext2 und Ext3 haben gegenüber Windows-Dateisystemen wie NTFS und FAT keinerlei zusätzliche Mechanismen, um eine Fragmentierung zu verringern oder gar zu verhindern. Die oft gepriesenen Vorteile sind genauso im Windows-Dateisystem implementiert."

Allerdings sind unter Linux aufgrund der Optimierungen in den IO-Schedulern Fragmentierungen weitgehend unbedeutend. Das muss wesentlich genauer erläutert werden und insbesondere mit Quellen belegt werden.

Dafür würde ich auch gern Quellen sehen. Ich kann nämlich ne Menge Quellen angeben, die genau das besagen, was in dem Satz geleugnet wird. 84.161.102.31 23:40, 12. Mai 2006 (CEST)

Letzer Abschitt

Im Artikel steht „Gute Ergebnisse liefern nach einem Test der Zeitschrift c't ...“. Welcher Scherzkeks war hier am Werk? Soll sich jetzt jeder seinen Teil denken? Sind die Programme so trivial, dass sie hier keiner Erwähnung bedarfen? Oder heißen die Programme „...“? --84.177.123.137 16:29, 23. Apr 2006 (CEST)

Bezüglich der Bilder

Bei den Bildern ist scheinbar noch das Copyright ungeklärt?! Die Bilder sind wohl als ScreenShot unserer Software O&O Defrag entstanden. Da zahlreiche Sites solche Bilder in Eigenregie anfertigen und veröffentlichen, haben wir (O&O Software) natürlich auch nichts gegen die Benutzung hier in Wiki. Bei Fragen hierzu bitte einfach melden bei mailto://carsten.fischer@oo-software.de (C. Fischer 20060427)

Ich weiß auch nicht, warum das Copyright da nicht geklärt sein soll. Der Autor hat doch eindeutig unter das Bild geschrieben, dass er es selber mit der ScreenShot Funktion gemacht hat... Bei anderen Bildern wird dies doch auch akzeptiert? Ist doch eigentlich nichts drann auszusetzen, oder doch? --Jd-fun 21:08, 1. Mai 2006 (CEST)

Die deutsche Wikipedia ist recht streng, was die Anforderungen für hochgeladene Bilder angeht. Und Screenshots von kommerziellen Programmen sind im Allgemeinen nicht "frei", auch wenn sie für die Presse oder ähnliches kostenlos verwendet werden dürfen. Siehe Wikipedia:Bildrechte. So muss z.B. auch die kommerzielle Nutzung und das beliebige Verändern der Bilder gestattet sein. Die meisten kommerziellen Softwareanbieter gestatten dies nicht. --RokerHRO 21:57, 11. Nov. 2006 (CET)

Beschädigung durch Defragmentierung

Ist es möglich, dass die Festplatte durch die Defragmentierung beschädigt werden kann?

Eigentlich nicht. Keine Frage, bei der Defragmentierung hat die Festplatte viel zu tun, viele Spurwechsel usw. Besonders bei einem bereits recht vollen Dateisystem kann es vorkommen, dass manche Daten mehrfach umkopiert werden müssen. Dies beansprucht eine Platte stärker als der normale Betrieb. Bei einer altersschwachen Festplatte oder einer mit bereits vielen defekten Sektoren kann diese Prozedur dazu führen, dass die letzten Reserven ausgereizt werden und die Festplatte kaputtgeht. Dann wäre sie im normalen Betrieb aber sicher auch in Kürze kaputtgegangen.
Anders sieht es etwa bei Flash-Speichern aus, da diese nur eine begrenzte Anzahl von Schreibzyklen pro Sektor erlauben. Durch das Defragmentieren und die damit verbundenen Umkopieraktionen kann diese Anzahl schneller erreicht werden und somit schneller Sektoren ausfallen. Aber auf Flash-Speichern bringt Defragmentieren eh nichts, da die Zugriffszeiten bei fragmentierten Daten nur unwesentlich größer sind als bei unfragmentierten Daten. --RokerHRO 21:50, 11. Nov. 2006 (CET)
Ein Lehrer von mir hat mal gesagt dass die Festplatte kaputt ist wenn beim Defragmentieren plötzlich der Strom ausfällt, aber das dürfte wohl nicht viel wahrscheinlicher sein als von einem Blitz getroffen zu werden.
MfG - Paragleiber 23:52, 30. Nov. 2006 (CET)
Naja, aber die Daten auf der Platte dürften dann zumindest teilweise weg sein. Soll heißen: Das Dateisystem ist inkonsistent und muss repariert werden, wobei ggf. nicht alle Daten wieder gerettet werden können. Je nach dem, wie der Defragmentierer arbeitet. --RokerHRO 08:44, 1. Dez. 2006 (CET)
(Benutzer: Max Aigner am 05.04.07 um 19:40 Uhr )
    Bei mir sind soeben alle Daten verloren gegangen, da sich mein Laptop beim Defragmentieren in den Ruhezustand 
    versetzt hat, von aber nicht mehr aufgewacht ist (nur Desktop-bild und maus). Beim Radikalen Neustart hatter dann 
    Windows nicht gefunden und dank einiger ungünstiger Umstände is jetzt alles weg. 
    Warscheinlich wurde zur Zeit des "in den Ruhezustand gehens" eine Systemdatei verschoben.
Ich glaube nicht, das es am Defragmentierer gelegen hat. Wenn dein Notebook nicht aus dem Standby erwacht, kann der Defragmentierer auch nichts dafuer. Zudem beendet der Defragmentierer sofort seine arbeit, sobald der Rechner abgeschaltet wird. Und das tut er beim Ruhezustand. Zumindest werden alle schwebenden Daten auf die Platte geschrieben. ich schaetze mal eher das der Fehler mal wieder in Front des Rechners saß...
Interessante Mitteilung! Und warum benutzt Du dann MS-BS?? --Paule Boonekamp - eine Silbersonne 12:39, 6. Jan. 2008 (CET)

Werkzeuge zur Defragmentierung

....also der zweite Satz hat doch logische, rhetorische und grammatikalische Lücken für mich als lesenden Laien.

In diesem Abschnitt wird auch der Begriff "selbstdefragmentierend" verwendet. Diesen finde ich so sehr schwierig zu verwenden. Da meines Wissens keines der Dateisysteme nen Extra-Thread im Treiber implementiert, der ne Defragmentierung durchführt und die sonstigen Eigenschaften der beschriebenen Dateisysteme ebenfalls nicht auf ein solches Verhalten deuten, sollte dieser Begriff entweder genauer definiert werden oder aber gestrichen/ersetzt werden. Florian Rittmeier 00:50, 3. Mai 2007 (CEST)

Wikipedia soll natürlich keine Werbung enthalten, doch sollten dem Wikipedia-Nutzer auch mögliche Werkzeuge zur Defragmentierung genannt werden, ohne den Anspruch zu stellen, dass keines genannt wird, wenn man nicht alle nennt. Dies gilt besonders, wenn einzelne Werkzeuge kostenfrei zu haben sind und dem Benutzer einen echten Mehrwert bieten. Schliesslich ist nicht jeder gleich ein Experte im Bedienen von Suchmaschinen. Ich sehe Wikipedia nicht als akademischen Selbstzweck sondern als eine Quelle möglichst umfassender, möglichst neutraler Information. Eventuell wäre ein Extra-Eintrag zum Vergleich von Defragmentierern eine sinnvolle Sache. Bestimmte Mängel wie z.B. die nur rudimentär vorhandene Zusammenführung von freiem Speicherplatz durch den Windows Defragmentierer sollten aber nicht verschwiegen werden. (Der vorstehende, nicht signierte Beitrag stammt von 91.32.35.182 (Diskussion • Beiträge) 15:39, 11. Aug. 2007)

Ich denke auch, dass es nicht schaden kann einige der gängisten kommerziellen Werkzeuge und einige wenige frei verfügbare aufzulisten. Mir fehlt dafür jedoch der Überblick. Wer kann helfen? --134.28.47.54 08:25, 18. Feb. 2008 (CET)

Defragmentierung unter Windows XP starten

Brauchen wir diesen Absatz in dem Artikel wirklich. Wer das Defragmentierungprogramm unter Windows nicht findet soll doch die "exzellente" Hilfefunktion von Windows verwenden. -- MarkusHagenlocher 18:49, 16. Mai 2007 (CEST)

Windows NT

Seid Ihr Euch bei dem Satz: Unter Windows NT Betriebssystemen steht nur dem Administrator der mitgelieferte Defragmentierer zur Verfügung. über die Allgemeingültigkeit für alle NT-Varianten sicher ?

Unter NT 3.5 und 4.0 gab es - soweit ich mich erinnere - keinen mitgeliefertes Defrag-Programm. Es musste immer auf das externe Programm zurückgegriffen werden. Meist das Freewareprogramm "Diskkeeper Lite". Angeblich hat M$ dann die Firma aufgekauft und auf dieser Basis eine eigene Variante (ab W2K) eingebaut. - 85.0.21.146 21:52, 18. Jan. 2008 (CET)

Ja, das Windows eigene Defrag kann nur per Admin-Rechte aufgerufen werden. Fremdanbieter-Software ist etwas anderes :)

Stimmt, hab's grad ausprobiert (XP), Diskeeper lite geht unter NT 4.0 mit allen Rechten (bei entsprechender Rechtekonfiguration beim installieren), aber das läßt sich ab Win 2k nicht mehr installieren. Bis NT 4.0 gab's nix von M$. Irgendwo (ich glaub im Tech Net) hab ich mal gelesen M$ hielt das offiziell nicht für nötig, da NTFS weniger stark bzw. schnell fragmentiert als FAT. Ich hab die Quelle nicht mehr zur Hand. War aber ja eh bloß 'ne Ausrede von denen, sonst hätten sie's ja später auch nicht eingebaut. --Qhx 10:12, 3. Apr. 2008 (CEST)

Ja, das NTFS nicht stark Fragmentiert ist eher ein Ammenmaerchen. Auch wenn es wohl theoretisch nicht so anfaellig dafuer ist (Gibts sicherlich eine Statistik fuer). Praxis vs Theorie. Diese Aussage gilt ja angeblich auch fuer Linux/Unix dateisysteme. ich moechte dort gerne mal sehen, wie es auf der Platte wirklich aussieht, besonders nach der Kernelherumkompiliererei ^^

Die Fragmentierung eines ext2/3 liegt in etwa bei 5-15%. Kompilieren hat darauf keinen Einfluss. Sehrwohl aber der Fuellgrad einer Platte, da bei einer vollen Platte der freie Speicher nicht mehr sinnvoll aufgeteilt werden kann. -- sparti 20:06, 14. Apr. 2008 (CEST)

Eine direkte Veraenderung der Datei sollte auch Einfluss auf die Fragmentierung haben. Ich kann mir nicht vorstellen, das dies bei Linux-Dateisystemen anders ist. Sobald ein Block von der Datei vollstaendig ausgefuellt wird, und der naechste von einer Datei benutzt wird, muss zwangslaeufig die Datei fragmentiert werden.

Der Trick ist eine Freispeicherverwaltung. Das Betriebsystem hält Buch über seien freien Speicherbereiche. Wenn eine Datei gespeichert wird, dann wird immer ein Bereich gesucht, der die Datei vollständig aufnimmt und je nach Größe einen Puffer läst. Damit läßt sich eine Fragmentierung nicht vollständig verhindern, aber solange ausreichend freie Bereiche da sind, auf ein Minimum reduzieren - eben auf diese 10-15%. Schau mal hier nach: en:Buddy_memory_allocation, diese Technik wird auch in Datenbanken verwendet. Also ich habe in 13 Jahren Linux noch NIE eine Platte defragmentiert! -- sparti 15:12, 18. Apr. 2008 (CEST)

USB-Sticks

„Diese Methode wird auch bei USB-Speichersticks empfohlen, da die Anzahl der Löschzyklen auf diesen Medien durch Verschleiß begrenzt ist und eine Defragmentierung immer eine hohe Anzahl von Schreib- und Löschzyklen bedingt.“

Aus den Ausführungen des Artikels ist doch eigentlich klar verständlich, dass Fragmentierung bei Flash-Medien keinerlei Performance-Einbußen bedeutet, demzufolge mir auch eine Defragmentierung sinnlos erscheint. -- Pemu 12:51, 31. Aug. 2008 (CEST)

Ist zwar nicht von mir (hab auch nichts gegen die Löschung), aber ich kann keinen Hinweis auf Flash-Medien finden. Wo soll das stehen? Ich würde es gerne hervorheben, weil vielleicht auch Andere den Hinweis übersehen. -- Qhx 13:07, 31. Aug. 2008 (CEST)
Na ja, es steht, dass der Performance-Verlust durch das Positionieren der Schreib-Lese-Köpfe entsteht. Ich habe vorhin als bekannt vorausgesetzt, dass Flash-Speicher keinen Schreib-Lese-Kopf hat bzw. Speicher mit wahlfreiem Zugriff (im eigentlichen Sinne des Wortes) ist. -- Pemu 16:59, 31. Aug. 2008 (CEST)
Habe letztens in der c't einen Bericht über Flash-Laufwerke gelesen. Durch die Organisation des Speichers ist es sehr wohl so, dass benachbarte Zugriffe schneller ablaufen als wahlfreie Zugriffe. Wahrscheinlich ist das auch mehr oder weniger gut auf USB-Speichersticks zu übertragen. -- Pemu 17:20, 9. Okt. 2008 (CEST)

Wichtigste Frage unbeantwortet

Was den durchnittlichen Benutzer am meisten interessieren dürfte ist, ob man durch Defragmentierung eine spürbare Geschwindigkeitsverbesserung erzielt (z.B. beim starten des Betriebssystems).

Das dürfte stark vom verwendeten Betriebssystem, Dateisystem, Anwendungsprofil usw. abhängen. Von daher sind diesbezüglich IMHO keine allgemeingültigen Aussagen möglich. --RokerHRO 12:42, 19. Sep. 2008 (CEST)

Artikel zu stark auf Festplatten als Medium beschränkt

Große Teile des Artikels beziehen sich auf Festplatten. Andere Speichermedien, insbesondere Chip-basierte wie Flashspeicher (USB-Sticks, Solid State Disks) oder RAM-Speicher (Ramdisk, Ram-Laufwerke) kommen noch deutlich zu kurz. Das ist besonders deshalb wichtig, da die negativen Seiten einer Dateifragmentierung aufgrund der anderen Technik und anderen Organisation des Speicherplatzes nicht oder nur bedingt zutreffen.(nicht signierter Beitrag von 00:51, 3. Nov. 2008 82.82.222.158 (Diskussion | Beiträge) )

OK, ich hab aus diesem Grund früher bei Flash-Speichern schon mal was fett markiert, weil das sonst leicht überlesen wird, aber das ist eher eine Verlegenheitslösung. Es steht Dir frei über andere Medien was zu ergänzen bzw. auszubauen. Aber ich befürchte, da müsste man vielleicht den ganzen Artikel neu strukturieren - und was ist nun Dein Vorschlag? Ergänzen, ändern, ...? -- Qhx 04:05, 3. Nov. 2008 (CET)

Ich habe den Artikel nochmals überarbeitet und oben einen Hinweis auf Flash-Medien eingefügt. Ich denke so ist es die beste Lösung. Sonst muss man hinter jeden zweiten Satz schreiben "... dies gilt jedoch nicht für Flash-Speichermedien" und das wäre ziemlich sinnlos. Allerdings fehlen noch so einige Sachen. Siehe der Absatz zur Auswirkung der Fragmentierung auf Flash-Medien. Da müsste sich nochmal ein Experte dransetzen. Aufgrund der internen Speicherorganisation von Flashmedien (Daten werden mitunter von Haus aus verstreut gespeichert) bin ich mir nicht sicher wie sich eine Fragmentierung genau auswirkt. Ich weiss, dass eine Defragmentierung auf einigen Flash-Speichermedien einen Geschwindigkeitsvorteil bringt, das wurde hier auch schon angesprochen. Nur, WARUM dies so ist weiss ich nicht und das müsste noch ergänzt werden. --82.82.100.4 21:23, 13. Nov. 2008 (CET)

Mac OS X

Im Abschnitt über Mac OS X heißt es: "(...) Um der Fragmentierung entgegenzuwirken läuft unter Mac OS X ein Hintergrundprozess, welcher regelmäßig das Dateisystem defragmentiert".

Um welchen Prozess handelt es sich? Kann jemand den Namen dieses Hintergrundprozesses ergänzen? -- Ceeemm 14:56, 21. Apr. 2009 (CEST)

Fehlt: Algorithmus

Mir fehlt eine Aussage, wie eine Defragmentierung erfolgt. Hierzu werden nur Ansätze genannt ("auf unbenutzte Blöcke kopieren"). Auf den ersten Blick würde ich sagen, das Problem eine optimale Dateiorganisation mit minimaler Anzahl an Kopieroperationen (und diese sind ja wesentlich, da die Defragmentierung im Allgemeinen sehr langsam ist und insbesondere bei Flash-Speichern der Datenträger verschleißt) zu erreichen, NP-vollständig ist. Es lohnt also, die verwendeten Heuristiken (es werden wohl nur Heuristiken sein) zu erklären. Ich mach mich mal schlau -- während bei mir hier stundenlang eine Defragmentierung läuft 88.79.134.74 22:37, 26. Sep. 2010 (CEST)

Windows 7

Wenn man unter Windows 7 die Defragmentierung startet wird zwar angezeigt wie weit jede einzellne Phase fortgeschritten ist, aber nicht wie viele Phasen es insgesammt noch geben wird. 13. Es sind 13. (nicht signierter Beitrag von 93.104.60.255 (Diskussion) 02:32, 16. Jul 2010 (CEST))

Das Defragmentierungstool von Windows 7 ist vollständig ausreichen. Ausserdem muss man es gar nicht mehr Formatieren da es dies bereits von selbst macht. CT Heft Nummer 5 2012 --Goleochutz 14:45, 22. Feb. 2012 (CET)

Weblinks

keine weiterführenden Links?! Ich erlaube mir mal, auf die Liste von Defrag-Programmen in der englischen Wiki zu verlinken...in der deutschen gibt's so nen Artikel leider/noch nicht. (nicht signierter Beitrag von ScoutingMel (Diskussion | Beiträge) 15:09, 25. Jun. 2012 (CEST))

"Vermeidung von Fragmentierung"

Fragmentierung tritt nicht immer auf, wie im Artikel gesagt wird, lediglich bei Veränderungen an Festplatteninhalten. Bei reinen Ablagen (wie z.B. den Familienfoto, der Musiksammlung oder bei Backup-Platten, tritt eine Fragtmentierung nicht auf (wer löscht schon Kinderfotos oder eine einmal gerippte CD?).--Mideal (Diskussion) 17:38, 18. Okt. 2012 (CEST)

Durch Fragmentierung wird Speicherplatz frei

Etliche behaupten das durch das Fragmentieren gar kein Speicherplatz frei wird sondern nur das es Fragmentiert wird.

Aber grundsätzlich wird Speicherplatz frei , aber der ist wiederum so gering das es kaum der rede ist. ( von Kilo Bits bis wenige MB Bits )

Denn man muss dazu verstehen wie eine Festplatte grundsätzlich funktioniert und das jegliche Daten die so gesehen aus Fragmente bestehen aber wiederum die Position bzw der zusamenhang welches Fragment zum welchen Fragment wiederum gehört und das welche Datei im enderfeckt alles zusammen ergibt ebenso die Position der Datei , muss diese Information ja irgendwo gespeichert werden.

Denn um so länger bzw vielseitiger diese Information ist um so mehr Speicherplatz wird benötigt, und wenn durch Fragmentieren diese Information weniger wird bzw kürzer wird dementsprechend weniger Speicherplatz wird benötigt und die Master Boot Datei ist ein wenig abgespeckter als zuvor. ( natürlich macht das nicht viel aus, aber dennoch ist Speicherplatz frei geworden ) (nicht signierter Beitrag von 92.206.64.144 (Diskussion) 11:42, 18. Mai 2016 (CEST))

Besteht die Möglichkeit, dass die Schreiber ihren Text mal überarbeiten. Es werden Begriffe verwechselt und die Rechtschreibung sollte auch mal angepasst werden. (nicht signierter Beitrag von SchaubFD (Diskussion | Beiträge) 09:16, 28. Jun. 2016 (CEST))

Defragmentierung ist nicht generell sinnvoll

Dateisysteme haben unterschiedliche Ansprüche. Fragmentierung ist in jedem Dateisystem vorhanden und es macht auch keinen Sinn alles zu defragmentieren. Sicherlich hat einer der vorherigen Schreiber recht, dass die mechanische Belastung bei Platten ein Problem ist, aber es gibt sogar einen Nutzen aus einer gewollten Fragmentierung!

Dateisysteme wie NTFS, WAFL, ZFS, BTRFS, HammerFS nutzen solche Technologien, um Momentaufnahmen von Dateisystemen zu erstellen. Es sind Dinge die ein Windows Anwender z.B. über die Begriffe Wiederherstellung oder "Vorherige Versionen" im Explorer kennt. Ohne eine gewollte Fragmentierung von Daten wäre dies nicht möglich. Eine Defragmentierung wäre in diesem Fall sogar teilweise schädlich.

Ein weiterer Grund weswegen gewollte Defragmentierung schlecht ist: Speichermedien halten nicht ewig und können fehlerhaft sein. Durch jede Datenbewegung wird das Risiko größer Daten zu zerstören. Besonders betroffen sind SSD's, die eine begrenzte Schreibanzahl haben. Die Datenprüfung bei Platten ist durch CRC alleine nicht 100% ausreichend. Gerade deswegen sind Dateisysteme wie ZFS, BTRFS und HammerFS nötig, weil diese Dateisysteme Fehler durch komplexe Prüfcodes korrekt erkennen und bei vorhandener Redundanz auch beheben können. Andere Dateisysteme müssen sich darauf verlassen, dass die ganze Technik von Platte bis CPU 100% und absolut korrekt funktioniert und dies ist ein langer Web von der magnetischen Oberfläche bis zur CPU! (nicht signierter Beitrag von SchaubFD (Diskussion | Beiträge) 09:46, 28. Jun. 2016 (CEST))

Thema Bitrot: CRC32 (BTRFS) ist für Modems entwickelt worden, wo häufig einzelne Bitfehler auftreten. Für Festplatten und blockbasierte Datenverwaltung ist das völlig unsinnig. Sowas passiert, wenn man keine Ahnung von Hashing hat. PS: Übrigens, mit "komplexen Prüfcodes" ist es bei den oben genannten Dateisystemen absolut nicht weit her. --Ghettobuoy (Diskussion) 20:04, 13. Apr. 2017 (CEST)

Ergänzungsvorschlag zum berrech ( Auswirkungen ) bei Fragmentierung der Festplatte

Es ist nicht nur die Geschwindigkeit alleine die dann flöten geht.

Eine gravierende Auswirkung bei Mechanischen Festplatten ist wenn die Daten ungünstig fragmentiert sind,

eine starke mechanische Abnutzung des Lesekopfs und des dazugehörigen Scheibenantrieb der Festplatte.

Pie mal Daumen gesagt:

Um so mehr der Lesekopf hin und her fahren muss bzw darf,

um so höher ist der "Energie(Strom)" verbrach der Festplatte wegen den unnötigen hin und her fahren des Lesekopfes, ( ebenso die fallende Lebenserwartung der internen Kondensatoren usw wegen des Stromflusses )

ebenso um so höher ist dann die "Wärmeentwicklung" der Festplatte an sich wegen den erhöhten mechanischen hin und her fahren des Lesekopfes usw,

und um so geringer ist im Nachhinein die "theoretische Lebenserwartung" der Festplatte wegen den hin und her, zu wie die erhöte Wärmteewicklung bis zum erhöten Stromdurchfluss der Elektronik der Festplatte.

Ganz zur schweigen um die erhöhte Wahrscheinlichkeit von lese und schreibe Fehler durch die Abnutzung der interner Festplatten Hardware als folge von ungünstig fragmentierten Festplatten und die daraus folgende hohe Zugriffsratte. (nicht signierter Beitrag von 92.206.58.221 (Diskussion) 10:46, 6. Nov. 2015 (CET))

Herkömmliche Festplatten speichern immer sequentiell. Die Lese- und Schreibvorgänge dauern länger, wenn eine Fragmentierung bereits vorliegt. Eine sogenannte "volle Geschwindigkeit" gibt es nicht. Die Zugriffszeiten sind hardwaremäßig bedingt und beziehen sich immer auf die Geschwindigkeit der Festplatte, die aber jeweils stets konstant ist. Es gibt keine unterschiedlichen Geschwindigkeiten wie beim Auto. Du kannst also eine Festplatte nicht "schneller" machen, sondern nur den Zugriff bzw. die Suchvorgänge optimieren. Alles andere ist Blödsinn. Ich hab das daher in der Einleitung berichtigt. --Hannover86 (Diskussion) 13:35, 19. Mai 2017 (CEST)

Ist das Status Windows 95? Was ist mit fragmentierungsabweisenden Dateisystemen und inhärenter Reorganisation?

Diese Fragmentierungsgeschichte ist ja etwas 1990er-Jahre-typisch und zusammen mit dem Erscheinen von fragmentierungsabweisenden Dateisystemen - und auch zugehörigen Mechanismen innerhalb des Betriebssystems - aus der Mode geraten.

Auch ist die Tätigkeit des Defragmentierens an sich unsinnig, wenn man einen terabytegroßen BLOB (Datenbank) blockmäßig neusortiert (dauert Stunden) um dann vier Minuten später zu erleben, wer er erneut fragemtniert.

Es wäre eine gute Idee, aktuelle Dateisysteme wie ZFS, XFS, NTFS, ReFS usw. mal kurz - streiflichtartig - anzuschauen, auch und insbesondere die Fähigkeit, sich selbst im laufenden Betrieb zu reorganisieren. Analysen sollte man wohl in einem WP-Artikel nicht bringen. --Ghettobuoy (Diskussion) 19:45, 13. Apr. 2017 (CEST)

Es ist keine Mode-Erscheinung, sondern eine technische Entwicklung. Seit Windows 8 heißt es bei Microsoft auch nicht mehr Defragmentieren, sondern Optimieren. --Hannover86 (Diskussion) 13:27, 19. Mai 2017 (CEST)

Bildfrage

[[Hilfe:Cache|Fehler beim Thumbnail-Erstellen]]:
Sollte dieses Bild nicht verwendet werden??? --Kibert 14:00, 16. Jan. 2008 (CET)
gif in besserer qualität im artikel enthalten. --Wetterwolke (Diskussion) 21:48, 1. Aug. 2021 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: Wetterwolke (Diskussion) 21:48, 1. Aug. 2021 (CEST)
Abgerufen von „https://de.wikiup.org/index.php?title=Diskussion:Fragmentierung_(Dateisystem)/Archiv/1&oldid=216824508“