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 :/
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 ).
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)
>>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.
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?
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.
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.
Richtig, UDF ist für Flash-Medien wie geschaffen, trotzdem kann Windows zwar UDF auf DVD lesen, nicht aber auf USB-Sticks. Unter Linux ist es aber IMHO das Filesystem der Wahl für Flash-Medien.
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.
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.
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.
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.
> Hast du schonmal versucht die Option "dir_index" unter Ext3 einzuschalten?
Da muß er aller Wahrscheinlichkeit nach gar nichts versuchen einzuschalten, da dies schon lange via /etc/mke2fs.conf bei allen Distributionen die Vorgabe sein sollte.
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.
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...
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
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 :
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.
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...
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.
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.
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.
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).
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?
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"
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).
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?
Tut mir leid, aber dafür habe ich kein Verständnis. Bisher hat sich noch jedes Linuxmagazin mit den FS-Tests blamiert. Soweit würde ich hier zwar nicht gehen, aber wenn nicht genug Zeit oder Equipement da ist, dann lasst es doch einfach. Der Erkenntnisgewinn bei so oberflächigen Tests ist bei Null.
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?
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.
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
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
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
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.
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.
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.
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.
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.
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.
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.
in den Standardeinstellungen istr ext3 schneller, weil es auf ein wichtiges Sicherheitsfeature verzichtet. Die Standardeinstellungen von xfs sind bekanntermaßen langsam.
"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?
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.
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))
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.
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.
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.
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?
-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.
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).
bis grub2 mal rauskommt, wirds wohl auch noch ewig dauern :/
btw: guter test, mir gefällt, das ihr btrfs mitgetestet habt!
Ein Journal für die Bootpartition ist ja nun wirklich schwachsinnig und obendrein Speicherplatzverschwendung.
Gruß
MichaelK
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.
Warten die alle wieder, bis Microsoft kommt und sie erneut unter die Knute zwingt?
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.
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.
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.
> 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.
geht längst nicht immer!
Da muß er aller Wahrscheinlichkeit nach gar nichts versuchen einzuschalten, da dies schon lange via /etc/mke2fs.conf bei allen Distributionen die Vorgabe sein sollte.
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...
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
Da ist ja sogar ein Atom schneller, von den gängigen Quadcores ganz zu schweigen.
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.
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.
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.
Keine. Wenn du welche kennst, die generell sinnvoll sind, dann her damit.
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).
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?
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.
Bei ext3 allerdings nicht.
>>Aufgrund der Kompatibilität kann man ext3-Dateisysteme in ext4 umwandeln, ohne ein Backup mit Rücksicherung vornehmen zu müssen.<<
war vielleicht noch etwas früh
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).
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?
Kein weiterer Kommentar.
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
lg
Erik
cd trash
while true; do
sleep 60
nice -n 19 echo * | xargs rm -rf
done
lg
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
Siehe z.B. http://sources.redhat.com/ml/libc-alpha/2002-12/msg00011.html
Gibt es überhaupt ZFS für Linux?
Gruß Micha
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
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.
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.
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?
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.
Schade - aber damit ist klar, warum XFS nicht weiter verbreitet ist.
Das wäre mir neu. Kannst du das näher erläutern?
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.
> 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.
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?
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.
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ä
Das steht da nicht. Du musst schon selbst mittels hdparm o.ä. dafür sorgen, dass deine Festplatte keinen Write-Cache benutzt.
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.
cya, jens:wq
XFS-Dateisysteme lassen sich nicht verkleinern. Das macht XFS natürlich besonders für ein Zusammenspiel mit LVM uninteressant.
Wurde das -T also blind übernommen oder gibt es ein konkretes Argument dafür?
D.h. beeindrucked ist, dass ext4 trotz der barriers schneller als ext3 ist. Abschalten lassen sich diese beim Mounten (barrier=0).