Diskussion:Fragmentierung (Dateisystem)/Archiv/1

message: 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)
thread_title:  Artikel unterbrochen? 

message: 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)
thread_title:  Stilistische Fehler 

message: 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)
thread_title:  Letzer Abschitt 

message: 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)
replies: text: 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)
thread_title:  Bezüglich der Bilder 

message: ....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)
replies: text: 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)
thread_title:  Werkzeuge zur Defragmentierung 

message: 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)
thread_title:  Defragmentierung unter Windows XP starten 

message: 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)
replies: text: 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)

text: 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)

text: 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)
thread_title:  Windows NT 

message: „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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
thread_title:  USB-Sticks 

message: 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)
thread_title:  Wichtigste Frage unbeantwortet 

message: 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.
: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)
thread_title:  Artikel zu stark auf Festplatten als Medium beschränkt 

message: 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)
thread_title:  Mac OS X 

message: 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)
thread_title:  Fehlt: [[Algorithmus]] 

message: 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)
thread_title:  Windows 7 

message: 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)
thread_title:  Weblinks 

message: 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)
thread_title:  "Vermeidung von Fragmentierung" 

message: 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)
thread_title:  Durch Fragmentierung wird Speicherplatz frei 

message: 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)
replies: text: 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)
thread_title:  Defragmentierung ist nicht generell sinnvoll 

message: 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)
thread_title:  Ergänzungsvorschlag zum berrech ( Auswirkungen ) bei  Fragmentierung der Festplatte 

message: 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)
thread_title:  Ist das Status Windows 95? Was ist mit fragmentierungsabweisenden Dateisystemen und inhärenter Reorganisation? 

message: : gif in besserer qualität im artikel enthalten. --Wetterwolke (Diskussion) 21:48, 1. Aug. 2021 (CEST)
replies: text: Archivierung dieses Abschnittes wurde gewünscht von: Wetterwolke (Diskussion) 21:48, 1. Aug. 2021 (CEST)
thread_title:  Bildfrage