Zum Archiv

Wie wird ein Archiv angelegt?

(Vorlage:Archiv-Tabelle) (erstes) Archiv nicht gefunden. (Parameter 'Base' und 'Basisname' richtig?)

Auf dieser Seite werden Abschnitte monatlich automatisch archiviert, deren jüngster Beitrag mehr als 365 Tage zurückliegt und die mindestens 2 signierte Beiträge enthalten. Um die Diskussionsseite nicht komplett zu leeren, verbleiben mindestens 2 Abschnitte. Die Archivübersicht befindet sich unter Archiv.

Auf dieser Seite werden Abschnitte automatisch archiviert, wenn sie mit {{Erledigt|1=--~~~~}} markiert sind.

Könnte jemand den Absatz über die Fragmentierung von ext2 etwas besser verständlich machen? Da kommen plötzlich Blocks (Blöcke?) und Blockgrößen ins Spiel und schließlich Prozentangaben, deren Herleitung sich mir so nicht erschließt. Vielleicht könnte auch jemand einen Absatz einschieben, der die Organisation von Dateisystemen grob erläutert?

Ein Fragmentierungsgrad von 1% in einem ext2-Dateisystem bedeutet, dass Fragmente aus durchschnittlich 100 Blocks bestehen. Das ist falsch. Vgl. check_blocks() in e2fsprogs/e2fsck/pass1.c: Die non-contiguous-Angabe von e2fsck besagt, wieviele Dateien nicht nur aus zusammenhängenden Blocks bestehen. Der Abschnitt, der erläutert, dass man NTFS-Fragmentierung nicht mit ext2-Fragmentierung vergleichen könne, müsste also neu geschrieben, oder gegebenenfalls komplett gelöscht werden.

Aus dieser unterschiedlichen Sichtweise der Messung der Fragmentierung beruht der Mythos, dass Unix-Dateisysteme nicht oder nur gering fragmentieren. Ich werde diesen Satz entfernen. Erstens ist ein Mythos gemäss Wikipedia in diesem Zusammenhang eine nicht verifizierbare noch falsifizierbare Meinung, was sicher nicht stimmt. Wie der Artikel richtig feststellt, kann man sehr wohl die Fragmentierung messen, ob man den Output von fsck mit demjenigen von scandisk einfach vergleichen kann, ist eine andere Frage, hat aber nichts mit der Aussage des Satzes zu tun.

mst Defrag wieder aufgenommen. Im Zuge der Gleichbehandlung sollten alle kommerziellen Anbieter genannten werden dürfen, die durch die Fachpresse bereits bewertet wurden oder aber es sollten alle Einträge entfernt werden. Es scheint, als ob entweder Diskeeper, Raxco oder O&O etwas gegen die Nennung von mst Defrag haben. Vielleicht kann mir mal einer erklären, wieso. Ansonsten würde ich doch bitten, von solchen Kindereien zukünftig Abstand zu nehmen.

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))Beantworten

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))Beantworten

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))Beantworten

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))Beantworten

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)Beantworten

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)Beantworten

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)Beantworten