Login
Newsletter
Werbung

Thema: Pro-Linux: Das Dateisystem ext4 - Eigenschaften und Benchmarks

79 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von dd am So, 18. Januar 2009 um 23:18 #
hui, das butterfs geht aber gut ab! freu mich schon, wenns fertig & weiter getunt ist. wird sicher spannend, zfs vs btrfs, io-tests/geschwindigkeiten etc. herrlich!
bis grub2 mal rauskommt, wirds wohl auch noch ewig dauern :/
  • 0
    Von Chris am So, 18. Januar 2009 um 23:31 #
    Ich habe seit gestern Mittag btrfs zum Testen auf meiner root-Partition... Bisher läuft alles rund und echt super! Keinerlei Ärger soweit. Ich hoffe die letzten wirklichen Probleme (z.B. der ENOSPC-Problem) werden bald behoben - dann brauche ich ext3/4 nur noch für meine boot-Partition (vorausgesetzt bis dahin ist nicht grub2 auch so weit ;) ).
    • 0
      Von dd am So, 18. Januar 2009 um 23:43 #
      *sehr* mutig!!
      btw: guter test, mir gefällt, das ihr btrfs mitgetestet habt!
      0
      Von Christopher Bratusek am Mo, 19. Januar 2009 um 00:29 #
      Ich benutze grub2 schon seit 3 Monaten (mit JFS) und habe keinerlei Probleme. (Und da du ja eh grub-legacy drüber installieren kannst, ist es einen Versuch wert)
      0
      Von MichaelK am Mo, 19. Januar 2009 um 22:42 #
      >>dann brauche ich ext3/4 nur noch für meine boot-Partition
      Ein Journal für die Bootpartition ist ja nun wirklich schwachsinnig und obendrein Speicherplatzverschwendung.

      Gruß
      MichaelK

0
Von Sven am So, 18. Januar 2009 um 23:58 #
Ich fände in dem Säulendiagramm noch ein Vergleich zu NTFS und FAT32/16 interressant
  • 0
    Von glasen am Mo, 19. Januar 2009 um 00:37 #
    Und was soll uns der Vergleich bringen?

    FAT taugt gerade noch für USB-Sticks und NTFS ist wohl das am wenigsten geeignete Dateisystem für den alltäglichen Einsatz unter Linux.

    • 0
      Von Jasager am Mo, 19. Januar 2009 um 12:49 #
      Was mich wundert ist, dass sich noch keine freie Alternative für USB-Sticks etablieren konnte. Fat32 stößt längst an seine Grenzen und NTFS ist Overkill, trotzdem konnte sich bisher kein Freies Dateisystem als Quasi-Industriestandard durchsetzen und das bei Millionen von Handys, Kameras und MP3-Playern.

      Warten die alle wieder, bis Microsoft kommt und sie erneut unter die Knute zwingt?

      • 0
        Von LH am Mo, 19. Januar 2009 um 15:21 #
        Woher soll ein freues System kommen? Solange Windows nicht heute schon eines unterstützt, wird auch in 10 Jahren kein USB Stick anders ausgeliefert.

        Ein USB Stick muss ja nunmal das bieten was die Leute brauchen. Und es nützt ja auch nicht viel wenn man einen Stick z.B. mit ext3 ausliefert, und die Leute ihn dann sofort mit FAT formatieren.

        • 0
          Von Jasager am Mo, 19. Januar 2009 um 19:39 #
          Ich glaube, einem freien Dateisystem als Industriestandard könnte sich Microsoft kaum verschließen. Zu Beginn noch ein paar Treiber-CDs in die Schachtel und kurz darauf käme das Ding über Windows-Update.
        0
        Von PolitikerNEU am Mo, 19. Januar 2009 um 21:27 #
        Erstens gibt es glaub ich einige Formate, die spezialisiert auf USB-Sticks zu sein und
        zweitens: Warum kann man keine NTFS auf USB-Sticks verwenden? Ich habe meinen USB-Stick sehrwohl mit NTFS formatiert, funktioniert problemlos (mit Windows und Linux) und mir wurde auch zugesichert, dass die Lebenszeit dadurch nicht beeinträchtigt wird.
        • 0
          Von Andreas am Di, 20. Januar 2009 um 21:08 #
          Dann hat man dir Unsinn zugesichert. Journaling-Filesysteme welche zusätzlich zu den Daten auch noch ein Journal führen sind nichts für USB-Sticks, da sie ein vielfaches an Schreibvorgängen erfordern und damit die Lebensdauer der Flash-Speicherchips um ein vielfaches reduzieren.
0
Von Thoralf Will am Mo, 19. Januar 2009 um 00:49 #
Ist zwar recht nett zu lesen aber das wichtigste fehlt mir: Performance unter realistischen Bedingungen
Bisher war ext3 vor allem bei vielen Dateien sowie tiefer und komplexer Ordnerstruktur schnarchlahm (und reiserfs pfeilschnell). Einen entsprechenden Test vermisse ich. Es ist zwar schoen zu wissen, wie lange es dauert eine einzelne Datei anzulegen oder eine grosse Datei zu kopieren - aber derartige Aufgaben sind sowas von trivial, dass sich hier kein Dateisystem eine echte Bloesse geben sollte.
  • 0
    Von glasen am Mo, 19. Januar 2009 um 01:54 #
    Hast du schonmal versucht die Option "dir_index" unter Ext3 einzuschalten? Das sollte einen Performancegewinn im Zusammenspiel mit großen bzw. komplexen Verzeichnissen bringen.

    > Bisher war ext3 vor allem bei vielen Dateien sowie tiefer und komplexer Ordnerstruktur schnarchlahm (und reiserfs pfeilschnell).

    Aus eigener Erfahrung weiß ich zwar das Reiser3 in gewissen Situation deutlich schneller als Ext3 ist, aber nach einem größeren Datenverlust in Folge eines Xserver-Absturzes und eines Zwangsneustartes des Rechners (Einschaltknopf), lasse ich die Finger von diesem Dateisystem. Die Erfahrung ist schon eine Weile her (so um die 5 Jahre), aber ein gebranntes Kind scheut das Feuer.

    Ext3 mag stellenweise langsamer als andere Dateisysteme sein, dafür ist es zuverlässig und stabil.

    0
    Von hjb am Mo, 19. Januar 2009 um 07:55 #
    bonnie++ hätte auch eine große Zahl von Verzeichnissen testen können. Ich hatte die Zahl in der Option -n auf 1 gesetzt, man müsste mal probieren, ob auch so etwas wie 128k möglich ist.
    0
    Von ac am Mo, 19. Januar 2009 um 21:55 #
    > Performance unter realistischen Bedingungen

    Eben. Da paßt das Bild im Aufmacher zum Artikel. Wie schnell 8GB gelesen werden, ist für 99% der Anwendungen im Vergleich zu anderen Größen irrelevant und wenn dann im Artikel selber lapidar "blockweise durchgeführt mit dd" steht, sagt das nichts über die Verteilung der Zugriffe auf das rotierende Medium aus. Insbesondere ist es verwunderlich, daß einige Dateisysteme bei sequentiellem Lesen eine schlechtere Leistung aufweisen sollen, als beim (vermutlich angedachten) wahlfreien Zugriff. Das hätte schon vor Veröffentlichung auffallen dürfen...

0
Von f00xbau am Mo, 19. Januar 2009 um 01:13 #
Es wäre schön gewesen, wenn man noch Reiser4 getestet hätte. In vielen Disziplinen schlägt das nämlich alle bisher verfügbaren Dateisysteme! Aber Reiser4 ist ja von Anfang an politisch nicht gewollt gewesen :-(
  • 0
    Von Christopher Bratusek am Mo, 19. Januar 2009 um 01:38 #
    Lässt sich bei mir nicht mal kompilieren.
    0
    Von glasen am Mo, 19. Januar 2009 um 02:03 #
    Dafür braucht Reiser4 deutlich mehr CPU-Leistung als alle anderen Dateisysteme. Auch gibt es Benchmarks, welche die viel beschworende Überlegenheit von Reiser4 in einem anderen Licht erscheinen lassen :

    http://linuxgazette.net/122/TWDT.html#piszcz

    Was das "politisch nicht gewollt" betrifft. Hier mal ein paar Links zu diesem Thema :

    http://www.linux.com/articles/56093
    http://kernelnewbies.org/WhyReiser4IsNotIn
    http://lkml.org/lkml/2006/7/21/109

    0
    Von hjb am Mo, 19. Januar 2009 um 07:58 #
    Der aktuelle Reiser4-Patch greift auf Funktionen im Kernel zurück, die nicht von außerhalb genutzt werden sollten. Wenn das endlich mal behoben wäre, würde Reiser4 größere Akzeptanz finden und sich leichter testen lassen.
    0
    Von Robert am Mo, 19. Januar 2009 um 08:48 #
    In vielen Disziplinen? Die müsste man mir aber mal nennen. In der Realität würde ich von einigen Disziplinen sprechen, mehr jedoch nicht. Gerade bei mehr als ganz kleinen Dateien ist die Performance von Resier4 auch nicht rosig. Ich hoffe, Disziplinen wie das Crashen von Dateisystemen werden nicht gemessen... ;-)
    • 0
      Von energyman am Mo, 19. Januar 2009 um 15:58 #
      warum nicht? Das wäre mal ein Test wo r4 richtig punkten kann. Als 'atomic' fs ist die Transaktion entweder abgeschlossen oder nicht begonnen.

      Und bei Tests die ich bei mir gemacht habe (inklusive mehrerer tausend Bilder und einer halben million emails in ~/Mail) war r4 das schnellste fs. XFS war gut mit großen Dateien, aber unzumutbar bei kleinen, ext3+barriers war unzumutbar in jeder Hinsicht. reiserfs hat sich wacker geschlage, konnte aber mit r4 nicht mithalten.

      Ich habe halt so getestet, wie es auch ungefähr dem entspricht, was ich jeden Tag tue - und so das optimale FS für mich herausgefunden:
      reiser4+lzo-Kompression.

      • 0
        Von gustl am Di, 20. Januar 2009 um 16:32 #
        Meine Partitionsstrategie sieht so aus:

        XFS für /boot und /, ReiserFS für /home.

        Warum?

        XFS braucht weit weniger Prozessorleistung als ReiserFS (15% vs. 50%), und nachdem ich einen Athlon Single Core Prozessor (1.3 GHz) habe ist es gerade beim Starten von Anwendunguen wichtig, dass wenig Prozessorzeit für das Dateisystem draufgeht.

        ReiserFS ist sauschnell bei vielen kleinen Dateien, und nur unwesentlich langsamer als andere Dateisysteme bei großen Dateien. Ideal für /home.
        Mountzeiten z.B. sind für meinen Einsatz echt irrelevant. Und wenns 2 s dauern würde währ's egal.

        Ich würde mich aber freuen, das irgendwann einmal vereinheitlichen zu können (BtrFS). Vielleicht wird es allerdings die eierlegende Wollmilchsau nie geben.

    0
    Von ac am Mo, 19. Januar 2009 um 22:04 #
    Reiser 4 ist (schein-)tot. Nicht politisch gewollt stimmt nicht, es mangelt an Interesse seitens einer hinreichenden Anzahl von Entwicklern.
0
Von energyman am Mo, 19. Januar 2009 um 05:10 #
welche mount optionen wurden benutzt?
Waren barriers für alle an- oder abgeschaltet?
Denn reiserfs und xfs schalten sie per default an, ext3 per default aus (da sie bei ext3 30% Performance kosten).

So wie es da steht, sind die benchmarks ziemlich inhaltsleer.

  • 0
    Von hjb am Mo, 19. Januar 2009 um 07:59 #
    > welche mount optionen wurden benutzt?

    Keine. Wenn du welche kennst, die generell sinnvoll sind, dann her damit.

    • 0
      Von energyman am Mo, 19. Januar 2009 um 15:11 #
      ah, wie ich mir gedacht habe. Damit wurden reiserfs und xfs unfair benachteiligt.

      Die extX machen barriers aus, weil es Sicherheit bringt und performance kostet. reiserfs und xfs machen sie aus gleichem Grund an - Sicherheit ist wichtiger.
      ext3 verliert angeblich (laut lkml) 30% performance wenn barriers angeschlatet werden.

      Sinnige Option ist also:

      barrier=1

      für ext3 (und vielleicht ext4 - hoffentlich sind sie da nicht so hirntot).

      • 0
        Von sebbo am Mo, 19. Januar 2009 um 18:42 #
        Deine Frage ging mir auch schon durch den Kopf.
        Mit hjb disqualifizert er sich und seinen Benchmark in meinen Augen als wahrheitsgetreut.
        Pfui, wir haben doch schon genug Falschaussagen im Internet, wieso geht das hier so weiter?
        0
        Von orhan am Mo, 19. Januar 2009 um 21:19 #
        Ich habe vor 5 Tagen mein System auf ext4 umgestellt. Dazu wurde einfach mit mkfs.ext4 /dev/$PLATTE ein ext4 Dateisystem erstellt. Nachdem ich deinen Beitrag gelesen haben probierte ich ein "dmesg | grep -i barr"

        10.761283] EXT4-fs: barriers enabled
        [ 10.808636] EXT4-fs: barriers enabled
        [ 10.851967] EXT4-fs: barriers enabled
        [ 10.891364] EXT4-fs: barriers enabled
        [ 51.856602] EXT4-fs: barriers enabled
        [ 732.502224] EXT4-fs: barriers enabled
        [ 1220.694500] EXT4-fs: barriers enabled
        [ 2507.140885] EXT4-fs: barriers enabled
        [ 2565.865957] EXT4-fs: barriers enabled
        [ 2592.910540] EXT4-fs: barriers enabled
        [ 2641.045530] EXT4-fs: barriers enabled


        In der fstab ist auch alles auf default

        /dev/sdb2 /mnt/sdb2 ext4 defaults 0 1
        /dev/sdb3 /mnt/sdb3 ext4 defaults 0 1
        /dev/sdb5 /mnt/sdb5 ext4 defaults 0 1
        /dev/sdb6 /mnt/sdb6 ext4 defaults 0 1


        Ich verstehe deine Argumentation nicht ganz.

0
Von catconfuser am Mo, 19. Januar 2009 um 07:10 #
Kann man eine ext3-Partition eigentlich ohne Formatierung in ext4 umwandeln (so wie das meines Wissens von ext2 nach ext3 geht)?
0
Von Robert am Mo, 19. Januar 2009 um 08:45 #
Erstmal vielen Dank für die Messungen und Tests. Das ist ja alles sehr schön, was ihr gemessen habt. Aber für mehr als lediglich eine grobe Tendenz kann man die Ergebnisse meines Erachtens nicht verwenden (ihr selbst gebt ja auch klar an, dass Zeitmangel ein Grund für wenig ausführliche Tests war):

Ihr habt beispielsweise nicht die Dauer des Handlings von vielen kleinen Dateien (lesen und schreiben separat sowie parallel) gemessen. Da es sich hier jedoch um ein eigentlich alltägliches Szenario handelt, vermisse ich diese Messwerte. Sequentielles Lesen und Schreiben ist nur ein Idealfall, der Werte unnötig schönt, aber von der Realität doch entfernt ist.

Die Hinzunahme von SELinux-Attributen fehlt ebenfalls, diese Option hat ebenfalls einen Einfluss auf die Performance, auch wenn SELinux von nicht allen Dateisystemen unterstützt wird (ext2, ext3, ext4, xfs). Da immer mehr diese Sicherheitsoptionen in die Linux-Distributionen standardmäßig Einzug finden, eine nicht unwichtige Sache.

Habt ihr LVM verwendet oder ist der Zugriff direkt auf Festplatten erfolgt? Bei LVM2 gibt es noch immer diverse Performance-Probleme, die die Ergebnisse auch noch verfälschen können - ein dd über die Festplatte bzw. über die VG hebt diese in der Regel bei Aktionen, die nicht über das Dateisystem laufen, eigentlich hervor. Also mir fehlenden auch ganz klar die Raw-Werte in einer zusätzlichen Spalte (sofern möglich natürlich).

  • 0
    Von hjb am Mo, 19. Januar 2009 um 12:24 #
    Ich stimme dir zu, dass die Testbedingungen nicht optimal waren. Ich habe aber nur wenige Rechner zur Verfügung, die zeitgemäße Geschwindigkeit aufweisen und genug Plattenplatz. Aber ich habe da eine Idee, wie ich das ändern kann ;-)

    Man kann sich darüber streiten, ob ein Benchmark wie bonnie++ ausreicht, um die Realität ausreichend anzunähern, also das Handling von vielen kleinen Dateien mit einschließt. Teilweise war dies dann im Test mit dem Kopieren von 20 GB dabei. Man muss sich fragen, ob es wirklich notwendig ist, "praxisnäher" zu testen, und ob das für das Endergebnis relevant ist. Aber man könnte weitere Tests hinzufügen - welche würdest du konkret vorschlagen?

    SELinux ist so eine Sache, es ist nicht unbedingt installiert geschweige denn aktiviert. Und wenn es nicht von allen Dateisystemen unterstützt wird, ist fraglich, ob es in einem allgemeinen Test sein muss.

    Bei den Tests wurde LVM verwendet. Ich kenne da keine Performance-Probleme, aber wenn es welche geben sollte, müssten alle Dateisysteme gleich betroffen sein, oder nicht?

    Was für Raw-Werte meinst du? Irgendwas, was nicht in den Protokolldateien zu finden ist?

0
Von Erik am Mo, 19. Januar 2009 um 10:01 #
Hallo zusammen,

das Problem von XFS beim Löschen von Dateien kenne ich leider auch. Ich setze es trotzdem ein, weil seine Vorteile diesen Nachteil locker ausgleichen. Hat jemand einen Trick auf Lager, wie man das clever ausgleichen könnte?


lg
Erik

  • 0
    Von Erik am Mo, 19. Januar 2009 um 11:02 #
    Hmm, ich beantworte mir die Frage mal selbst: btrfs scheint von den Features her ebenbürtig zu sein (oder werden?), hat diesen gravierenden Nachteil allerdings nicht. Vielleicht sollte ich das mal auf die Agenda setzen.


    lg
    Erik

    0
    Von hjb am Mo, 19. Januar 2009 um 12:11 #
    Du kannst z.B. die zu löschenden Daten in ein Verzeichnis "trash" verschieben und von einem Hintergrundprozess löschen lassen. Dieser kann ein primitives Skript sein, so ungefähr:

    cd trash
    while true; do
      sleep 60
      nice -n 19 echo * | xargs rm -rf
    done

    0
    Von Jack am Di, 20. Januar 2009 um 00:21 #
    Hey Erik,
    du hast völlig Recht. Löschen ist wirklich teils wesentlich langsamer als unter anderen Dateisystemen. Und da ich XFS sehr gerne einsetze, habe ich nach einer Lösung gesucht und nach etwas Suchen im Netz folgenden Artikel gefunden:
    http://everything2.com/index.pl?node_id=1479435
    Ist zwar auf englisch, aber die Ausführungen haben das Löschen und einige andere Operationen beschleunigt. Guck es dir mal in Ruhe an!
    mfg, Jack
0
Von timestamps am Mo, 19. Januar 2009 um 10:16 #
Das hochauflösende Zeitstempel nicht genutzt werden (können) ist falsch, das gibt es schon seit Linux 2.5 und wird unter anderem von ls wie auch von gmake genutzt. Immerhin kennt Linux schon sehr lange Dateissysteme die hochauflösende Zeitstempel anbieten.

Siehe z.B. http://sources.redhat.com/ml/libc-alpha/2002-12/msg00011.html

0
Von Micha am Mo, 19. Januar 2009 um 12:35 #
Weiß einer wie sich ZFS im Vergleich so schlägt?
Gibt es überhaupt ZFS für Linux?

Gruß Micha

  • 0
    Von Daniel H. am Mo, 19. Januar 2009 um 12:56 #
    Hallo

    In absehbarer Zeit wird es leider (ausser über fuse = filesystem in userspace = grotten langsam ;) keine Implementierung von ZFS im Linuxkernel geben da SUN es nicht unter der GPL veröffentlicht hat.Eine eigene Portierung dürfte an der Komplexität von ZFS scheitern.Alternativen zu dem von SUN in Opensolaris oder Solaris 11 x86 (SunOS 5.11 ; soweit ich Informiert bin noch nicht stable) implementierten ZFS gibt es nur unter FreeBSD.Könnte ich zwischen den beiden wählen ,viele meine Wahl auf FreeBSD 7.x da es dort wesentlich einfacher ist Applikationen aus der Linux Welt zu portieren als das bei Opensolaris (trotz gcc) der Fall ist.In meinen Augen ist diese Dateisystem in Bezug auf die Features wie snapshots und Replakation anderen Konkurenten um Lichtjahre vorraus.


    Daniel

0
Von Der Gast am Mo, 19. Januar 2009 um 12:45 #
Dieser Test ist sooo etwas von primitiv.... Es sind je nach Anwendung verschiedene Dinge zu testen und da wäre nicht nur der IO-Durchsatz interessant, sondern auch das Finden von Dateien, der Dateisystemcheck etc etc etc.

Ich nutze privat immer noch Reiser3, weil es viele Dateien gut händelt und schnell beim Dateisystemcheck ist. Bei einem DB-Server würde ich evtl. auf etwas anderes setzen. Bei einem reinem Sambaserver noch etwas anderes.

Dieser Test sagt auch nichts in Relation zu einem Anwendungsfall aus.

  • 0
    Von Daddeisüstem am Mo, 19. Januar 2009 um 13:14 #
    Wenn du schon so clever bist zu unterscheiden das dieser Test nicht anwendungsbezogen ist, hättest du dir ja die Mühe sparen können diesen Bericht als "mies" zu beschreiben.
    Ich kopiere auch nicht mehrmals jeden Tag GB-Files durch die Gegend oder ähnliches, und wenn dann ist es mir wurscht ob es 10 Sekunden länger dauert, aber dann spar ich mir so einen Kommentar wie der von dir.
0
Von amd-linux am Mo, 19. Januar 2009 um 14:38 #
Was spricht eigentlich gegen XFS?

In allen Tests vorne mit dabei, stabil, ausgereift, Dateigrössen für die nächsten 15 Jahre ausreichend - das klingt alles ganz gut?

Mit BTRFS kommts nicht mit, was die neuen features angeht, aber im Vergleich zu EXT4 sehe ich nicht so wirklich den Mehrwert von EXT4 zu XFS?

Oder was spricht gegen XFS?

  • 0
    Von hjb am Mo, 19. Januar 2009 um 14:54 #
    Das einzige mir bekannte Argument ist, dass man ext3 nicht in xfs konvertieren kann.

    Außerdem kann GRUB nicht von xfs booten. Das behebe ich regelmäßig mit einer kleinen /boot-Partition, die auch nützlich ist, wenn man den Rest des Systems mit LVM oder RAID aufsetzt. Mit GRUB 2 sollte es aber auch direkt gehen.

    • 0
      Von amd-linux am Mo, 19. Januar 2009 um 15:12 #
      Hmm, ok, also GRUB unterstützt XFS nicht - ohne manuelle Partitionierung lässt sich Ubuntu unter XFS beispielsweise also nicht installieren.

      Schade - aber damit ist klar, warum XFS nicht weiter verbreitet ist.

      0
      Von fuffy am Mo, 19. Januar 2009 um 15:19 #
      Außerdem kann GRUB nicht von xfs booten.
      Das wäre mir neu. Kannst du das näher erläutern?
      0
      Von glasen am Mo, 19. Januar 2009 um 15:42 #
      Grub kann schon seit Jahren von XFS booten.

      XFS hat eigentlich nur einen kleinen, aber nicht ganz unwichtigen, Nachteil :

      XFS stellt nur die Integrität des Dateisystems und nicht der Daten sicher. Das heißt, das man z.B. nach einem Stromausfall oder Totalabsturz zwar ein sauberes Dateisystem hat, der Inhalt von noch nicht fertig geschriebenen Dateien aber nicht mehr konsistent ist.

      Anstatt den Ursprungszustand der Datei per Journal wieder herzustellen, füllt XFS fehlende Daten einfach mit Nullen auf. Dadurch hat die Datei zwar die gleiche Größe wie vorher, enthält aber meistens nur noch unbrauchbaren Datenmüll (Sehr toll, wenn dadurch eine wichtige Konfigurationsdatei zerstört wird, die zum Booten des System notwendig ist).
      Das ist auch der Hauptgrund warum ext3 in der Standardeinstellung langsamer als andere Dateisysteme ist. Dort werden erst die Daten und dann das Journal geschrieben.

      XFS ist ein wunderbares Dateisystem für Rechner an denen eine USV hängt oder von dem man 100% weiß das alle Treiber stabil sind und das System nicht ins Nirvana schicken. Für alle anderen Systeme ist es in meinen Augen zu riskant.

      • 0
        Von hjb am Mo, 19. Januar 2009 um 15:53 #
        Wenn man grub auf einem XFS-Dateisystem zu installieren versucht, kommt eine Warnung, dass das Booten fehlschlagen könnte. Bei allen Systemen, die ich getestet habe, scheiterte das Booten in der Tat. Die Installer einiger Distributionen lassen es mittlerweile nicht mehr zu, dass man eine Partition mit XFS zur Bootpartition macht.

        > XFS ist ein wunderbares Dateisystem für Rechner an denen eine USV hängt
        > oder von dem man 100% weiß das alle Treiber stabil sind und das System
        > nicht ins Nirvana schicken. Für alle anderen Systeme ist es in meinen
        > Augen zu riskant.

        Ich habe reichlich Crash-Tests mit XFS gemacht und keine Probleme festgestellt. XFS als riskant zu bezeichnen, ist und bleibt FUD. Wenn im Moment eines Stromausfalls gerade Daten geschrieben wurden, weiß man bei keinem Dateisystem, welche davon auf der Platte gelandet sind. Beim nächsten Mount bringt sich XFS wieder in einen konsistenten Zustand und gut ist.

        • 0
          Von fuffy am Mo, 19. Januar 2009 um 18:04 #
          Es macht einen Unterschied, ob du GRUB in den Bootsektor einer XFS-Partition installieren willst oder ob /boot auf XFS liegt. Ersteres geht in der Regel schief, aber die meisten dürften GRUB ohnehin in den MBR schreiben.
        0
        Von energyman am Mo, 19. Januar 2009 um 15:54 #
        in den Standardeinstellungen istr ext3 schneller, weil es auf ein wichtiges Sicherheitsfeature verzichtet. Die Standardeinstellungen von xfs sind bekanntermaßen langsam.
        0
        Von amd-linux am Mo, 19. Januar 2009 um 15:57 #
        "XFS stellt nur die Integrität des Dateisystems und nicht der Daten sicher. Das heißt, das man z.B. nach einem Stromausfall oder Totalabsturz zwar ein sauberes Dateisystem hat, der Inhalt von noch nicht fertig geschriebenen Dateien aber nicht mehr konsistent ist."

        Hmm, aber unter ext3 ist die Datei auch nicht komplett, oder? Sondern liegt halt in der Länge vor, in der sie bis zum Ausfall geschrieben war, aber mit Hinweis auf den fehlenden Teil?

        Mit fsck.ext3 kriegste den fehlenden Teil aber doch auch nicht her, oder?

        • 0
          Von energyman am Mo, 19. Januar 2009 um 16:34 #
          nein.
          Und da ext3 barriers per default nicht benutzt und bei den heutigen cache-größen kann ext3 nichtmal garantieren, daß das fs sauber ist. Wenn die Hälfte des journals es noch nichtmal auf die Platte geschafft hat, dann ist das schon bitter.
          Aber für manche Leute (ext3 devs, Distris, ext3 Benutzer) ist Datensicherheit halt nachrangig.
          • 0
            Von peschmae am Mo, 19. Januar 2009 um 17:15 #
            Kannst du das mit den Barriers mal etwas genauer erläutern?

            Die Manpage scheint mir im Prinzip genau das Gegenteil zu sagen von dem was du die Tage so schreibst, denn:
            Enables the use of block layer write barriers for writes into
            the journal and unwritten extent conversion. This allows for
            drive level write caching to be enabled, for devices that sup‐
            port write barriers.

            D.h. dank den Barriers kann der Plattencache [für die Journal writes] aktiviert werden. Das hiesse doch dass er bei den Barrierlosen writes deaktiviert ist (und ergo hier Ext3 benachteiligt worden wäre...; es aber keine Konsistenzprobleme nach einem Stromausfall hat (zumindest nicht wegen der Barriers))

            -Peschmä

            • 0
              Von fuffy am Mo, 19. Januar 2009 um 18:04 #
              Das hiesse doch dass er bei den Barrierlosen writes deaktiviert ist (und ergo hier Ext3 benachteiligt worden wäre...; es aber keine Konsistenzprobleme nach einem Stromausfall hat (zumindest nicht wegen der Barriers))

              Das steht da nicht. Du musst schon selbst mittels hdparm o.ä. dafür sorgen, dass deine Festplatte keinen Write-Cache benutzt.

              0
              Von energyman am Mo, 19. Januar 2009 um 18:31 #
              nein, mit barriers kann das fs sicher stellen, daß die Platte bestimmte Daten direkt auf den Platter schreibt und nicht im cache vermoddern läßt. Die caches sind so oder so an. Wenn das fs und die Platte (und das sind heutzutage eigentlich alle) barrier unterstützten kann das fs der Platte mitteilen, daß bestimmte Datensätze direkt auf die Platte geschrieben werden müssen, bevor irgendetwas anderes getan wird.

              Die Gefahr mit cache und ohne barrier: das journal liegt zum großen Teil darin (oder andere wichtige fs-Strukturdaten) und schaffen es nicht mehr auf die Platte. Resultat: nach dem crash ist das fs beschädigt, Datenverluste wahrscheinlich.
              Wenn ein fs keine barrier unterstützt oder per default deaktiviert, sollte man auch den Festplattencache deaktivieren - was allerdings auch Leistung kostet. Und für viele FS ist barrier+cache schneller, als keine barrier+keine cache. ext3 unterstützt nun zwar barriers, aber weil dadurch die Leistung bei ext3 sehr stark einbricht, sind sie per default aus. Woraus man schließen kann:
              ext3 schert sich nicht um deine Daten.

    0
    Von astacx am Mo, 19. Januar 2009 um 20:24 #
    Ist nicht wirklich ein Argument gegen XFS, aber man sollte berücksichtigen, dass ein fsck 1/1000 der Partitonsgröße an freiem RAM haben will. Für ne 8 TB Partition sollten also ca. 8 GB an RAM und Swap zur Verfügung stehen. Gerade bei puren File-Servern ist das Verhältnis von RAM:Disk eher weit unter 1:1000, da könne dann im Fall der Fälle ein fsck eng werden.

    cya, jens:wq

    0
    Von ... am Mi, 21. Januar 2009 um 16:08 #
    Oder was spricht gegen XFS?

    XFS-Dateisysteme lassen sich nicht verkleinern. Das macht XFS natürlich besonders für ein Zusammenspiel mit LVM uninteressant.

0
Von Formatter am Mo, 19. Januar 2009 um 18:43 #
Ich lese immer: mkfs.ext4 -T device, aber keine Begründung. -T weißt doch nur eine Inode pro 4MB zu, könnte für /var zu viel sein, für einen Videosttreamingserver dagegen zuwenig, wobei mehr Inoden nicht schaden, bis auf den etwa höheren Platzverbrauch?

Wurde das -T also blind übernommen oder gibt es ein konkretes Argument dafür?

  • 0
    Von Hans Wurst am Mo, 19. Januar 2009 um 21:57 #
    -T war ein Tippfehler im ext4-Wiki. -t ist richtig. Ich bin vor ein paar Tagen selber über den Fehler gestolpert :-) Die ext4-Leute im IRC haben überlegt, in Zukunft evtl. eine Warn-/Fehlermeldung einzubauen.
0
Von Hans Wurst am Mo, 19. Januar 2009 um 19:24 #
ext4 hat im Gegensatz zu ext3 'barriers' standardmäßig aktiviert. Barriers sind grob ne ziemlich gute Alternative zum abgeschalteten Schreibcache der Festplatten, aber um ein Vielfaches schneller.

D.h. beeindrucked ist, dass ext4 trotz der barriers schneller als ext3 ist. Abschalten lassen sich diese beim Mounten (barrier=0).

Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung