Dateisystem für Linux

Mr. Brooks

Lt. Commander
Registriert
Aug. 2011
Beiträge
1.441
Hallo,

bisher habe ich für Datenpartitionen unter Linux ext4 genutzt, mich nervt aber der lost+found-Ordner, den man auch nicht ausgeblendet bekommt. Welches Dateisystem würde sich unter Linux anbieten als Ersatz für ext4 (ext2 udn ext3 nutzen diesen Ordner auch). Ich dachte spontan an ReiserFS. Bei xfs gibt es wohl den Nachteil, dass man die Partition nicht nachträglich verkleinern könnte - was ja immer mal wieder passieren kann. Letztlich genügen mich die Funktionen die auch unter ext4 laufen.

Mr. Brooks
 
Zuletzt bearbeitet:
Hab jetzt auch erstmal als ReiserFS formatiert, das braucht gleich mal 20GB mehr als NTFS vorher (ich hab hier 2 Datenpartitionen, von denen eine erstmal weiter ext4 bleibt und die 2. bisher NTFS war, jetzt ReiserFS - ich boote Windows kaum noch.

An ZFS hab ich auch gedacht, das bot mit aber GParted nicht zum formatieren an.
 
zfs verwaltest du auch nicht mit gparted sondern mit den zfs tools (zpool, zfs). aber ja, ich bin auch gparted gewöhnt. hätte auch reiser genommen.
 
Zuletzt bearbeitet:
Du kannst ohne Probleme alle lost+found Ordner aller genutzten ext4-Partitionen woanders hin "mounten" wenn du diese nicht sehen willst. Oder du versteckst diesen Ordner, manche der grafischen Dateiexplorer bieten nativ eine Funktion dafür, bei anderen kann man die Ordner generell verstecken, Google liefert dazu genug Tipps und Tutorials.

Desweiteren ist dir bewusst, dass es reiserFS und reiser4 gibt und naja... der Hauptentwickler kann keines der System mehr unterstützen und bisher wurde keines der beiden Dateisysteme in den Linux-Kernel aufgenommen und laufen daher afaik im Userspace... Auch ist zumindest reiserFS nur Single-Core-fähig, was bei Last bzw je nach CPU zum Flaschenhals werden kann.

Die Aussage bzw ext4 und Größenänderung stimmt auch so übrigens nicht. Ein ext4 lässt sich ohne weiteres verkleinern, die Partition sollte dafür nur nicht gemountet sein. Generell sollte man Änderungen an Partitionen und Dateisystemen nur "offline" vornehmen, also wenn die entsprechenden Partitionen nicht gemountet sind.

Du hast jetzt also ein sehr stabiles und "abgehangenes" Dateisystem gegen ein nicht im Kernel integriertes Dateisystem getauscht ohne einen wirklichen Vorteil zu gewinnen, naja außer ggf die für dich sauberere Optik im Dateiexplorer.

Den Vorschlag mit ZFS würde ich getrost vergessen, zumindest liest es sich so, dass du Linux an einem PC oder Laptop verwendest. ZFS hingegen ist auf (große) Server und vor allem Storage-Systeme ausgelegt die zwei essentielle Dinge voraussetzen, die der Durchschnitts-PC nicht besitzt: ECC-RAM und davon raue Mengen. Aus (beruflicher) Erfahrung kann ich sagen, dass ZFS auch erst so richtig Spaß macht, wenn man ausreichende Mengen an SSDs bzw entsprechend große SSDs nutzt für ZIL und L2ARC.
 
Mr. Brooks schrieb:
mich nervt aber der lost+found-Ordner, den man auch nicht ausgeblendet bekommt
Echt jetzt? Die Leute haben Probleme ....
Bitte sag mir, dass Du ein Forentroll bist, damit ich nicht den Glauben an die Menschen verliere.

Aber ok. Vielleicht hast Du ja tatsächlich vernünftige Gründe. Warum willst Du lost+found ausgeblendet haben? Vielleicht gibts ja ein Weg Dein Ansinnen zu erreichen, ohne das Filesystem kaputt zu machen oder zu wechseln.
Ergänzung ()

snaxilian schrieb:
Den Vorschlag mit ZFS würde ich getrost vergessen, zumindest liest es sich so, dass du Linux an einem PC oder Laptop verwendest. ZFS hingegen ist auf (große) Server und vor allem Storage-Systeme ausgelegt die zwei essentielle Dinge voraussetzen, die der Durchschnitts-PC nicht besitzt: ECC-RAM und davon raue Mengen.
Richtig ist, dassZFS seine Stärken erst auf "großen Systemen" ausspielt. Andererseits spricht nix dagegen es auch auf dem Desktop laufen zu lassen. BSDs wie TrueOS (früher PC-BSD) verwenden selbst in der Desktop-Variante per default ZFS.

Und ECC oder gar viel RAM als Voraussetzung konnte ich bisher nicht feststellen. Es verhält sich so, wie man es von einem Dateisystem erwartet. Man merkt nicht, das man Eines hat. :-)
 
Klar läuft zfs auch ohne ECC-RAM, und es fällt bei kleinen Datenmengen und kurzen Laufzeiten auch nicht sonderlich ins Gewicht. Bei größeren Datenmengen aber und/oder langen Laufzeiten sollte man schon über ECC-RAM nachdenken. Wie bei BTRFS auch unterstützt man damit sinnvoll gewisse Features zur Datenintegrität, mag man googles Studien zu Fehlerhäufigkeit im RAM bei langen Laufzeiten entsprechend interpretieren.

ECC-RAM ist kein Muß für ZFS oder BTRFS, aber sicher eine sinnvolle Unterstützung. Man kauft sich ja auch keine Bugatti und schraubt dann Schubkarrenräder drunter, oder?

Viel RAM ist vor allem dann bei ZFS notwendig, möchte man Features wie deduplication nutzen. Aber auch so sollte man 1-2GB RAM pro 1TB Poolkapazität einplanen, um das FS nicht ggf. unnötig auszubremsen. Bei geringer Aktivität kann es auch etwas weniger sein, jedoch ist ZFS schon anspruchsvoller als z.B. ext4 (oder FAT16 :P), RAM kostet nicht die Welt und wie war das doch gleich mit der Bugatti?
 
Zuletzt bearbeitet:
An welcher Stelle genau stört dich denn die Anzeige von lost+found? Da gibts bestimmt eine Möglichkeit, die Anzeige an der Stelle zu unterdrücken.

Wenn du wirklich ein anderes Filesystem nutzen möchtest, ist dein Gedanke an xfs genau richtig. Verkleinern ist doch egal, wenn mans nicht tagtäglich benötigt.
 
Twostone schrieb:
Klar läuft zfs auch ohne ECC-RAM, und es fällt bei kleinen Datenmengen und kurzen Laufzeiten auch nicht sonderlich ins Gewicht. Bei größeren Datenmengen aber und/oder langen Laufzeiten sollte man schon über ECC-RAM nachdenken. Wie bei BTRFS auch unterstützt man damit sinnvoll gewisse Features zur Datenintegrität, mag man googles Studien zu Fehlerhäufigkeit im RAM bei langen Laufzeiten entsprechend interpretieren.
Noch mal zur Erinnerung. Es ging hier darum, ob man ZFS an einem Desktop-System einsetzen kann. Und meine Erfahrung ist: Ja, kann man. Ohne Einschränkungen.

Ob das unbedingt notwendig ist, da ja viele Features von ZFS gar nicht zur Geltung kommen, da ist sicher richtig das es nicht notwendig ist. Aber das hab ich so auch gesagt.



Twostone schrieb:
Viel RAM ist vor allem dann bei ZFS notwendig, möchte man Features wie deduplication nutzen. Aber auch so sollte man 1-2GB RAM pro 1TB Poolkapazität einplanen, um das FS nicht ggf. unnötig auszubremsen. Bei geringer Aktivität kann es auch etwas weniger sein, jedoch ist ZFS schon anspruchsvoller als z.B. ext4 (oder FAT16 :P), RAM kostet nicht die Welt und wie war das doch gleich mit der Bugatti?
Noch einmal: Es ging darum, ZFS bei einem Desktop-System. Und da hast Du üblicherweise kein RAM-Problem, weil Du die Datenmengen gar nicht hast.
Und anscheinend sehen es die PC-BSD-Leute genauso, sonst würden sie es ja nicht zum default machen. Bei einem Endanwender-System wohlgemerkt.
Mag ja sein, dass Du skeptisch bist, wenn ich so was sage. Aber wenn es selbst die BSD-Leute machen, behaupte ich mal, das man sich sehr weit aus dem Fenster lehnt, wenn man sagt ZFS wäre für Desktop generell untauglich.

Bugatti hin oder her.
 
Ich habe keineswegs gesagt, ZFS wäre für einen Desktop untauglich. Tatsächlich verwende ich es auch selbst auf meinem Desktop, was den Abgleich mit meinen Servern deutlich vereinfacht, da ich Datensicherungen über snapshots machen kann und auch die gleichen scripte nutzen kann, die auch beim Abgleich zwischen den Servern zum Einsatz kommen. Die Frage, ob ECC oder nicht, ist da einfach eine Frage der Laufzeit, nicht des Dateisystems. Das jedoch scheinst Du nicht verstanden zu haben.

Relativ wenige Desktop-Rechner laufen 24/7, stehen auch meist alleine, was die Wahrscheinlichkeit eines kritischen Bitflips deutlich verringert. Ganz auszuschließen ist das nicht, aber auf Grund der kurzen Laufzeiten auch nicht ganz so tragisch. Wer jedoch seinen Rechner nie ausschaltet, sollte sich nicht wundern, wenn selbst bei ZFS oder BTRFS mal ein Fehler in einer Datei auftritt.

andy_m4 schrieb:
Noch einmal: Es ging darum, ZFS bei einem Desktop-System. Und da hast Du üblicherweise kein RAM-Problem, weil Du die Datenmengen gar nicht hast.

dedup ist selbst bei "geringen" Datenmengen ein ziemlicher Speicherfresser, aber default eben auch nicht aktiv. Auf einem Desktop macht das auch keinen wirklichen Sinn. Auch wenn's ein nettes Feature ist, auf den meisten Datensätzen ist es auch gar nicht nötig. Will man es dennoch mit möglichst wenig Leistungseinbußen nutzen, sollte man auch deutlich mehr RAM einplanen als die von mir erwähnten 1-2GB pro TB Plattenkapazität.

ZFS ist ein gutes Dateisystem, auch was das Handling angeht. Aber selbst das Beste Dateisystem bringt einem keinen Zugewinn, wenn der Unterbau scheiße ist.

Allerdings schweifen wir ab, der TE stört sich ja lediglich am l+f-Ordner, nicht an defekten Dateien. Insofern ist hier jede Diskussion über Hardware eher unnötig, da hier auch kein besonderer Anwendungsfall zur Geltung kommt. Ich gehe nicht davon aus, daß der Rechner des TE 24/7 läuft, in einer industriellen Umgebung mit größeren Wechsellasten steht, größere Datenbanken bewältigen muß oder sonst irgendwie großartig belastet wird noch mission critical ist. Wenn der Rechner halbwegs "modern" ist, ist er somit sowieso schon überdimensioniert.
 
Twostone schrieb:
Ich habe keineswegs gesagt, ZFS wäre für einen Desktop untauglich.
Dann weiß ich nicht, warum Du diskutierst. Alles andere wurde ja längst schon gesagt. Sogar von mir selbst. Wenn auch nicht in der Ausführlichkeit. Aber darin war ja auch gar keine Notwendigkeit.


Twostone schrieb:
ZFS ist ein gutes Dateisystem, auch was das Handling angeht. Aber selbst das Beste Dateisystem bringt einem keinen Zugewinn, wenn der Unterbau scheiße ist.
Du schnallst es immer noch nicht, oder?

Es ging nie um einen "Zugewinn". Das hab ich von Anfang an klar gemacht. Es ging darum, ob man ZFS auf Desktops einsetzen kann. Abgesehen von der Frage, ob sich das lohnt, bringt es aber erstmal keine mir bekannten Nachteile. Daher macht es auch wenig Sinn jetzt irgendwelche Serverszenarien aufzuzeigen, weils völlig im "Subtopic" vorbei geht,
Ansonsten verweise ich auf die vorherigen Postings.

Twostone schrieb:
Allerdings schweifen wir ab, der TE stört sich ja lediglich am l+f-Ordner, nicht an defekten Dateien.
Nur äußert der sich ja nicht mehr. Daher gibts zum Topic bis auf Weiteres ja nix zu sagen.
 
Mein Problem ist in der Tat nur der lost+found-Ordner. Das mag nicht jeder verstehen, aber wenn man das als Maßstab ansieht sind 50% der Beiträge in allen Internetforen nutzlos. Leider gibt es für mich unter Linux nur Dolphin als brauchbaren Dateimanager (und ich habe jeden versucht der mir bekannt ist) und Dolphin scheint keine Möglichkeit zu bieten diesen Ordner auszublenden.

Ich verwende die Partition um zu bearbeitende Daten zwischenzuspeichern. Das können Audio-, Video- oder Bilddateien sein. Es kann auch mal gerne zig GB ausmachen (z. B. bei HD- oder 4K-Videos, bei Videos mit geringerer Auflösung die aber unkomprimiert gespeichert werden oder bei unkomprimiert gespeicherten Bilddateien). Einzelne Dateien die im 2-stelligen GB-Bereich liegen sind aber selten. Zuviel RAM hab ich nicht, das war ein Planungsfehler als ich mir den Rechner zugelegt habe und jetzt ist er so verbaut, dass ich vermutlich erst bei einem Mainboardupgrade neu kaufen würde. es ist ein Gigabyte P55UD3R mit einem i5-760 und 2x2GB RAM. Ob das jetzt für meinen Einsatzzweck zu wenig ist kann ich nicht sagen.

Kann man hier Tests laufen lassen um die Auslastung und Geschwindigkeit der Dateisysteme zu testen? Ich brauche die Partition vermutlich in den nächsten 2 Wochen nicht.

Du kannst ohne Probleme alle lost+found Ordner aller genutzten ext4-Partitionen woanders hin "mounten" wenn du diese nicht sehen willst.

Der Punkt hier ist auch interessant. Ich versteh aber nicht so ganz wie das gehen soll.
 
Zuletzt bearbeitet:
Mr. Brooks schrieb:
Mein Problem ist in der Tat nur der lost+found-Ordner. Das mag nicht jeder verstehen, aber wenn man das als Maßstab ansieht sind 50% der Beiträge in allen Internetforen nutzlos. Leider gibt es für mich unter Linux nur Dolphin als brauchbaren Dateimanager (und ich habe jeden versucht der mir bekannt ist) und Dolphin scheint keine Möglichkeit zu bieten diesen Ordner auszublenden.
Und einen Unterordner anlegen den Du gleichzeitig auch unter "Orte" in Dolphin plazierst?
So wärst Du One-Click da und hättest kein lost+found.

Das wäre nur dann störend, falls Du auf Deinem "TEMP-Laufwerk" selbst tiefe Ordnerhierachien verwendest.



Mr. Brooks schrieb:
Kann man hier Tests laufen lassen um die Auslastung und Geschwindigkeit der Dateisysteme zu testen? Ich brauche die Partition vermutlich in den nächsten 2 Wochen nicht.
Generell machst Du ja mit ext4 nicht viel falsch. Wenn man will, kann man hier und da auch Einstellungen vornehmen, um es auf die Verarbeitung großer Dateien hin zu optimieren.

Benchmarks gibtsübrigens im Netz. Aber wenn Du willst, kannst Du natürlich auch selber benchmarken und einfach mal die Zeit messen, die typische arbeiten benötigen. Dann hättest Du auch ein Benchmark, der genau auf Deinen Fall passt.



Mr. Brooks schrieb:
Der Punkt hier ist auch interessant. Ich versteh aber nicht so ganz wie das gehen soll.
Vielleicht weiß Google Rat :-)
 
Und einen Unterordner anlegen den Du gleichzeitig auch unter "Orte" in Dolphin platzierst?
So wärst Du One-Click da und hättest kein lost+found.

Das wäre nur dann störend, falls Du auf Deinem "TEMP-Laufwerk" selbst tiefe Ordnerhierachien verwendest.

Hier kann ich dir nicht folgen. Wo soll ich einen Unterordner anlegen? Ich verwende die "Orte-Übersicht" in Dolphin nicht, ich verwende die Ordner- und die Geräte-Ansicht. Die Geräte-Ansicht aber nur um USB-Sticks und externe Platten sicher zu entfernen.
Ergänzung ()

@ andy_m4

Ich weiß nicht ob du das meintest. ImNetz hat jemand geschrieben:

  • ext-Partition z. B. als /media/.hdd1 mounten (durch den Punkt wird diese versteckt)
  • darin einen Ordner, z. B. "Daten" anlegen
  • dann unter dem bisherigen Mountpoint einen symbolischen Link erstellen zu dem Ordner per ln -s /media/.hdd1/Daten /media/hdd1

Meinst du das? Könnte das andere Probleme mit sich bringen an die ich man bisher nicht denkt?
 
Mr. Brooks schrieb:
Hier kann ich dir nicht folgen. Wo soll ich einen Unterordner anlegen? Ich verwende die "Orte-Übersicht" in Dolphin nicht, ich verwende die Ordner- und die Geräte-Ansicht.
Also wenn Deine Partition z.B. nach /mnt/mypart/ gemountet hast, dann ist ja unter /mnt/mypart/ auch der lost+found Ordner. Du legst jetzt einfach unterhalb /mnt/mypart/ ein Ordner an z.B. mit dem Namen XYZ und den tust Du dann in bei Dolphin Orte. Dann hast Du da Deine Partition aber kein lost+found, weil Du ja unter /mnt/mypart/XYZ/ und da gibts kein lost+found.

Mr. Brooks schrieb:
Ich weiß nicht ob du das meintest. ImNetz hat jemand geschrieben:

  • ext-Partition z. B. als /media/.hdd1 mounten (durch den Punkt wird diese versteckt)
  • darin einen Ordner, z. B. "Daten" anlegen
  • dann unter dem bisherigen Mountpoint einen symbolischen Link erstellen zu dem Ordner per ln -s /media/.hdd1/Daten /media/hdd1

Meinst du das? Könnte das andere Probleme mit sich bringen an die ich man bisher nicht denkt?
Ist etwas umständlicher, aber geht natürlich auch. Und man spart sich durch eine Ordnerebene zu hangeln, falls man mal mit einem Non-KDE-Programm drauf zugreift (z.B. beim abspeichern aus irgendeiner Applikation).
 
Wenn es in erster Linie um größere Dateien (also so 1 MB aufwärts) geht, würde ich definitiv XFS in die nähere Auswahl nehmen. Das ist für solche Dateien recht effizient (z.B. löschen geht sehr schnell) und wird deswegen auch gerne für Datenbankserver genommen. Ein Dateisystem verkleinern ist mir in der Praxis noch nie untergekommen.
 
fax668 schrieb:
Ein Dateisystem verkleinern ist mir in der Praxis noch nie untergekommen.

Eine Partition auf eine (kleinere) Platte umziehen. Habe ich bereits öfters bei Laptops oder images für CF-Karten gemacht, ist so abwegig nicht, wenn auch trotzdem ein Sonderfall.
 
fax668 schrieb:
Wenn es in erster Linie um größere Dateien (also so 1 MB aufwärts) geht, würde ich definitiv XFS in die nähere Auswahl nehmen.
Sowohl beim Lesen als auch beim Schreiben großer Dateien ergibt sich zwischen ext4 und XFS ein allzugroßer Unterschied:
https://openbenchmarking.org/result/1610303-LO-MERGE860463

fax668 schrieb:
Das ist für solche Dateien recht effizient (z.B. löschen geht sehr schnell) und wird deswegen auch gerne für Datenbankserver genommen.
Hm. Bei pgbench von PostgreSQL schneidet XFS gegenüber ext4 eher bescheiden ab:
https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.7-FS-5-Way

Insgesamt scheinen mir die Dateisysteme näher zusammengerückt was die Geschwindigkeit angeht.

Mehr hinsichtlich bringen tut es wahrscheinlich an den Mount-Optionen zu drehen als das Dateisystem zu wechseln. Dazu dann noch solche "Hacks" wie das Journal zu deaktivieren (immerhin gehts hier um temporäre Dateien; und Journal sorgt ja primär für Konsistenz und nicht zwangsläufig für Integrität, wenn man nicht gerade ein Fulljournal fährt was einem aber den Speed wieder kaputt macht) oder auf ein anderes Laufwerk zu legen.
 
Mr. Brooks: Schreib uns doch mal, welche Filesysteme du wohin gemountet hast und an welcher Stelle das lost+found stört. Das könnte etwa so aussehen:

/dev/bla /
/dev/blub /home
/dev/schnief /videos <----- NUR HIER in /videos stört mich das lost+found ganz doll und muss weg!!1

Mit den Infos müsste man nicht wild rumschwurbeln sondern könnte ganz konkrete Lösungsvorschläge bringen.
 
Zurück
Oben