1. Foren
  2. Kommentare
  3. Applikationen
  4. Alle Kommentare zum Artikel
  5. › Microsoft: Windows-10-Juni…

Natürlich fragmentieren auch Linux-FS

Für Konsolen-Talk gibt es natürlich auch einen Raum ohne nerviges Gedöns oder Flamewar im Freiraum!
  1. Thema

Neues Thema Ansicht wechseln


  1. Natürlich fragmentieren auch Linux-FS

    Autor: MountWalker 17.06.20 - 18:32

    Alle Linux-Dateisysteme fragmentieren mehr oder wenioegr und bei allen kann es bei großen Füllzuständen zu mehr oder weniger "Problemen" kommen. XFS bietet Defragmentierung seit 20 Jahren, dabei wurde das Dateisystem selbst in diesen 20 Jahren mehrmals massiv überarbeitet und hat für Flashspeicher auch besondere Anpassungen bekommen.

    Ext4 braucht nur deshalb nie defragmentiert werden, weil ext4 halt einfach kein Defragmentierungstool hat. Die Begründung ist aber, dass viele Admins die ext4 einsetzen, Angst haben, dass Defragmentierer auch mal Dateien kaputt machen können - auf Nicht-COW-Dateisystemen. Wenn einem ext4-Admin ein Volume zu lahm wird, wird es einmal kopiert - groß sind ext4-Volumes eh nie, dafür ist das Dateisystem genauso veraltet wie NTFS. Wer auf Linux riesige Volumes verwaltet, nutzt entweder XFS mit defrag oder er nutzt ZFS und ist in einer Sphäre, in der Zugriffsgeschwindigkeit egal zu sein scheint (ich sag nur Hashtable).

    Ext4 hat ein Problem mit dem Platz für die inodes. Wenn sie erst während der Nutzung bei Bedarf erstellt werden, ist ext4 langsamer als alle anderen. Das kann man umgehen, indem man beim Formatieren der Partition Platz für inodes fest zuweisen lässt. Dadurch dauert aber nicht nur der Formatierungsprozess plötzlich merklich Zeit, sondern es wird eine feste Einschätzung über die durchschnittliche Dateigröße des irgendwann gefüllten Volumes getroffen, die, weil keiner die Zukunft sieht, auch falsch liegen kann. Liegt sie falsch, kann das Volume voll sein obwohl da noch viel Platz frei ist. Damit das nicht passiert, ist die Standardformatierung der meisten Distros ohne spezielle Anhängsel ohne inode-Vorerstellung. Dann ist ext4 aber halt eben langsamer als die anderen Mainline-Dateisysteme. Stört auf kleinen Volumes nicht und auf einer NAS wird man das wahrscheinlich kaum bemerken, aber es ist nicht so, als hätte ext4 keine Nachteile.

    Und auch auf HDD-Volumes ist seit mindestens 15 Jahren das Ziel einer Defragmentierung nicht mehr, alle Dateien komplett in nur je ein einziges Fragment zu schreiben, sondern dafür zu sorgen, dass die Fragmente so groß sind, dass die Zugriffszeit nicht mehr ins Gewicht fällt. Windows defragmentiert schon seit Vista keine Fragmente die größer als 64 MiB sind mehr; auch auf HDD nicht. Wenn ein 4,2 GiB DVD-Image in 67 Fragmente zerteilt auf einer HDD liegt, wird der Windows-Defragmentierer (seit Vista aufwärts) das nie anfassen. ;-)



    1 mal bearbeitet, zuletzt am 17.06.20 18:35 durch MountWalker.

  2. Re: Natürlich fragmentieren auch Linux-FS

    Autor: wurstdings 18.06.20 - 10:31

    MountWalker schrieb:
    --------------------------------------------------------------------------------
    > Alle Linux-Dateisysteme fragmentieren mehr oder wenioegr und bei allen kann
    > es bei großen Füllzuständen zu mehr oder weniger "Problemen" kommen.
    Welche Probleme sind das denn?
    > Ext4 braucht nur deshalb nie defragmentiert werden, weil ext4 halt einfach
    > kein Defragmentierungstool hat.
    Quatsch: man e4defrag

    Es ist einfach nicht nötig, sofern man nicht länger Zeit mit einem vollen Dateisystem arbeitet entsteht einfach keine relevante Fragmentierung.
    > Die Begründung ist aber, dass viele Admins
    > die ext4 einsetzen, Angst haben, dass Defragmentierer auch mal Dateien
    > kaputt machen können
    Du kannst diesen "Admins" mal sagen, dass es Backups gibt und sie diese ab jetzt verwenden sollen.
    > Wenn einem ext4-Admin
    > ein Volume zu lahm wird, wird es einmal kopiert
    Also kopieren macht dann aber keine Dateien kaputt?
    > Das kann man umgehen, indem man beim Formatieren der Partition
    > Platz für inodes fest zuweisen lässt. Dadurch dauert aber nicht nur der
    > Formatierungsprozess plötzlich merklich Zeit
    Nein dass passiert erst beim ersten Mount im Hintergrund, die Erstellung ist trotzdem super flott.
    > sondern es wird eine feste
    > Einschätzung über die durchschnittliche Dateigröße des irgendwann gefüllten
    > Volumes getroffen, die, weil keiner die Zukunft sieht, auch falsch liegen
    > kann.
    Also wenn du das komplette Dateisystem mit Dateien von durchschnittlich < 16KB voll haust, dann hast du schon ein sehr spezielles Anwendungsprofil und solltest dies dementsprechend bei der Erstellung berücksichtigen, jeder normale Anwender hat irgendwo ne paar GB große Datei und ist damit aus diesem Extremfall raus.
    > Damit das nicht passiert, ist die Standardformatierung der
    > meisten Distros ohne spezielle Anhängsel ohne inode-Vorerstellung. Dann ist
    > ext4 aber halt eben langsamer als die anderen Mainline-Dateisysteme
    Nette Behauptung, zeig mal den Benchmark dazu und noch viel interessanter, mit welchem Befehl erstellst du ein ext4 Dateisystem, mit dynamisch zur Laufzeit generierten Inodes?
    > Stört
    > auf kleinen Volumes nicht und auf einer NAS wird man das wahrscheinlich
    > kaum bemerken, aber es ist nicht so, als hätte ext4 keine Nachteile.
    Hat das wer behauptet? Weil du hast gerade ein neues Thema erstellt und im Artikel wird ext4 nicht erwähnt.
    Und nein ext4 geht nicht einfach kaputt wenn es zu sehr fragmentiert ist, es wird nur langsamer. Und diesen Zustand muss man auch noch mit "Gewalt" herbeiführen.
    > Und auch auf HDD-Volumes ist seit mindestens 15 Jahren das Ziel einer
    > Defragmentierung nicht mehr, alle Dateien komplett in nur je ein einziges
    > Fragment zu schreiben, sondern dafür zu sorgen, dass die Fragmente so groß
    > sind, dass die Zugriffszeit nicht mehr ins Gewicht fällt.
    Das war doch schon immer das Ziel der Defragmentierung?

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. medavis GmbH, Karlsruhe
  2. Nagel-Group | Kraftverkehr Nagel SE & Co. KG, Berlin, Hamburg, Frankfurt am Main, München
  3. THD - Technische Hochschule Deggendorf, Deggendorf
  4. Meibes System-Technik GmbH, Gerichshain

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 8,75€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Programm für IT-Jobeinstieg: Hoffen auf den Klebeeffekt
Programm für IT-Jobeinstieg
Hoffen auf den Klebeeffekt

Aktuell ist der Jobeinstieg für junge Ingenieure und Informatiker schwer. Um ihnen zu helfen, hat das Land Baden-Württemberg eine interessante Idee: Es macht sich selbst zur Zeitarbeitsfirma.
Ein Bericht von Peter Ilg

  1. Arbeitszeit Das Sechs-Stunden-Experiment bei Sipgate
  2. Neuorientierung im IT-Job Endlich mal machen!
  3. IT-Unternehmen Die richtige Software für ein Projekt finden

Weclapp-CTO Ertan Özdil: Wir dürfen nicht in Schönheit und Perfektion untergehen!
Weclapp-CTO Ertan Özdil
"Wir dürfen nicht in Schönheit und Perfektion untergehen!"

Der CTO von Weclapp träumt von smarter Software, die menschliches Eingreifen in der nächsten ERP-Generation reduziert. Deutschen Perfektionismus hält Ertan Özdil aber für gefährlich.
Ein Interview von Maja Hoock


    Fiat 500 als E-Auto im Test: Kleinstwagen mit großem Potenzial
    Fiat 500 als E-Auto im Test
    Kleinstwagen mit großem Potenzial

    Fiat hat einen neuen 500er entwickelt. Der Kleine fährt elektrisch - und zwar richtig gut.
    Ein Test von Peter Ilg

    1. Vierradlenkung Elektrischer GMC Hummer SUV fährt im Krabbengang seitwärts
    2. MG Cyberster MG B Roadster mit Lasergürtel und Union Jack
    3. Elektroauto E-Auto-Prämie übersteigt in 2021 schon Vorjahressumme