4. Welches Dateisystem für Linux?

Welches Dateisystem für Linux?

  • M

    @nman: nö...also die daten waren absolut ned komprimiert...

    ich kann das symptom auch nochmal genauer beschreiben:

    der zeigte mir bei "größe" die richtige größe an, also irgendwas mit 400 mb und bei "größe auf datenträger" hat er eben die knapp 2,5 gb angezeigt.

    ich glaube ich werde das ma nochma mim reiser probieren und schaun was dabei rauskommt

    noch ne frage zum reiser:
    beim ext3 hab ich ma gelesen / gehört, dass sich des sozusagen selbst defragmentiert...tut das s reiser auch??

    0
  • N

    mb0156ba schrieb:

    der zeigte mir bei "größe" die richtige größe an, also irgendwas mit 400 mb und bei "größe auf datenträger" hat er eben die knapp 2,5 gb angezeigt.

    Dann haben diese Daten schon auf dem NTFS 2.5 Giga belegt, sind wohl sehr viele kleine Dateien, oder? (Dann lässt sich das mit den handelsüblichen Dateisystemen vermutlich nicht allzusehr verbessern...

    noch ne frage zum reiser:
    beim ext3 hab ich ma gelesen / gehört, dass sich des sozusagen selbst defragmentiert...tut das s reiser auch??

    Keines der Mainstream-Unix-Dateisysteme fragmentiert.

    0
  • *

    nman schrieb:

    Keines der Mainstream-Unix-Dateisysteme fragmentiert.

    fsck sagt mir aber immer sowas wie
    ... clean (0.6 % non-contigous) ...

    was das wohl heisst?
    Wie soll ein Dateisystem nicht fragmentieren, ohnen Massen an Platz zu verschwenden?
    Hab ich wieder 'nen Denkfehler? 🙄

    0
  • K

    Alsoooo:

    ext2 (und ich schätze mal ext3 auch) fragmentieren kaum da die Daten anders gespeichert werden:

    FAT32: ABCD
    ext2: A B C D

    Falls jetzt Datei A etwas größer wird siehts so aus:

    FAT32: ABCDA
    ext2: AAB C D

    Wie das reiser macht habe ich keine Ahnung, aber da Reiser eh alles in
    Bäumen organisiert denke ich mal wird die Fragmentierung noch kleiner gehalten.

    Edit: ach nichts! 😉

    0
  • N

    ºgrimmsenº® schrieb:

    fsck sagt mir aber immer sowas wie
    ... clean (0.6 % non-contigous) ...

    was das wohl heisst?
    Wie soll ein Dateisystem nicht fragmentieren, ohnen Massen an Platz zu verschwenden?
    Hab ich wieder 'nen Denkfehler? 🙄

    *schnupper* Riechts hier nach Rosinen? 🙄
    Dann formuliere ich eben um: Alle gängigen Unix-Dateisysteme halten die Fragmentierung sehr stark in Grenzen.
    Vergleich das mal mit FAT, NTFS und Co; unter Unix braucht man üblicherweise keine Defragmentierungs-Tools.

    0
  • M

    Dann haben diese Daten schon auf dem NTFS 2.5 Giga belegt, sind wohl sehr viele kleine Dateien, oder? (Dann lässt sich das mit den handelsüblichen Dateisystemen vermutlich nicht allzusehr verbessern...

    na bei ntfs sah des ganze ned ganz so krass aus...da war die "wirkliche größe" eben die ca 400 mb und der platz auf platte lag be ca 520 oder sowas in dem dreh...hat das also schon ganz gut kaschiert...oder was weiss ich...

    und all zu klein sind die daten ned wirklich...alles so im dreh zwischen 2 und 20 mb...oder nennt ihr das schon besonders klein 😉

    gut...ich danke trotzdem für die vielen einblicke und meinungen...und werde das ganze nun nochma mim resier probieren...wenns da auch wieder mist macht texte ich hier wohl nochmal...

    merci

    gruß
    mb

    0
  • R

    versuch es ruhig mal mit ReiserFS, weil das soll ja für kleine Dateien besonders geeignet sein.

    0
  • U

    Fragemntiert wird schon aber nicht so wie bei WINDOWS.

    WIN beginnt immer beim ersten freien Block und speichert forlaufen bei den nächsten freien. Dadurch ergibt sich das die Daten framentiert also nicht nacheinander gespeichert sind da dazwischen belegte blöcke sind.

    Bei den Linux-FS: Es wird ein freier Speichrplatz gesucht wo die Daten ganz rein passen. Da dies nicht immer der Fall ist kommt es auch hier zur fragmentierung. Man kann sich aber ausrechen wie belegt die Platte sein muss um zu fragmentieren.

    reiserFS ist bei viele kleine Datein unschlagbar. SUSE hatt in einer Version mal ein Problem mit reiseFS wo Daten zerstört wurden. Ext3 baut auf ext2 auf und ist eigentlich nur eine Erweiterung. Im Grunde bleibt es ein ext2 mit JF.
    Nimm reiserFS oder Ext3

    0
  • ?

    Ich habe vor kurzen ein Ext3 erstellt. Da gibt es ja soooo viele Optionen 😃
    Es gibt eine Einstellung für kleine Dateien im Kilobyte Bereich, ein für MP3's und eine für noch größere Dateien. Darüber hinaus kannst Du auch festlegen wieviel Platz eine Datei auf jeden Fall beansprucht. Gut für 160'er Platten wo man eh nur maximal 1000 Dateien a 100MB + X abspeichert. Außerdem kann man mit einer Option den für Root freigehaltenen Speicherplatz freigeben. Waren glaube ich 5% die sonst fehlen.

    Zu Deinem Prob: Vielleicht hast Du einfach ein falsche Dateisystem erstellt. Wenn Du eine Partition auf einer großen Platte angelegt hast, macht mke2fs vielleicht automatisch ein FS für Dateien die mindestens Megabytegroß sind. Während auf Deiner Fat32 Partition jede Datei nur mindestens 32Kilobyte groß waren...

    Erstell doch mal eine 1 Byte große Datei und schau mal wieviel Platz sie belegt. Befehl "du -b myFile.txt"

    0
  • S

    da passt http://navindra.blogspot.com/2004/10/kde-dot-news-ext3s-miserable-failure.html ganz gut. Fand ich sehr interessant.

    0
  • K

    Wo wir gerade beim Thema sind:
    Hat schon jemand Reiser4 getestet?
    Bis ich selber darauf umsteige werde ich noch einige Zeit ins Land gehen lassen,
    bei Dateisystemen bin ich recht konservativ, aber was ich bisher gehört habe soll Reiser4 so ziemlich alles toppen.

    0
  • S

    Habe reiser4 mal kurz mit yoper angetestet (hat schon reiser4 support), allerdings gabs da dann einige komische fehlermeldungen und ich hab es gelassen.

    muss aber nicht an reiser4 gelegen haben - obwohl eine neu installation mit reiserfs dann problemlos klappte... aber yoper hat da so seine eigenheiten.

    0
  • K

    aber yoper hat da so seine eigenheiten.

    Allerdings! Ich wollte es mal auf einen Test-PC installieren und habe die
    dollsten Sachen erlebt.
    Partionen nicht gefunden, mit in der Installation wollte er plötzlich Grub installieren obwohl er die Files dafür noch nicht kopiert hatte etc etc.

    Außerdem ist es nicht so schnell wie die Entwickler immer behaupten.
    Ein einfaches Mandrake (Ja genau Mandrake ;)), mit eigenem Kernel der mal nicht auf Debug kompiliert wurde (@Mandrake: noch alles ok bei euch?! Ich bin zwar Programmierer aber kein Kernelentwickler! Warum Debug und Profiling aktivieren?)
    steckt Yoper locker in die Tasche.

    0
  • N

    Kane schrieb:

    Außerdem ist es nicht so schnell wie die Entwickler immer behaupten.
    Ein einfaches Mandrake [...] steckt Yoper locker in die Tasche.

    Das stimmt so nicht; Yoper ist definitiv schneller als Mandrake, das liegt in der Natur der Sache.

    0
  • S

    Kane schrieb:

    Außerdem ist es nicht so schnell wie die Entwickler immer behaupten.
    Ein einfaches Mandrake [...]
    steckt Yoper locker in die Tasche.

    Kann ich nicht bestätigen. Habe Mandrake 9.2 und 10 auf 2 verschiedenen PCs laufen gehabt. Mit IceWM. Und yoper läuft jetzt drauf. Mit KDE. Und yoper ist schneller. Merkbar schneller.

    Natürlich nicht so ultimativ mega extrem wahnwitzig schnell - aber KDE läuft schön rund, super startzeiten,...

    also yoper ist da definitiv schneller.

    PS: wieso er grub UND lilo installiert ist mir aber auch ein rätsel. allerdings ist die installation ja hoffentlich noch lange nicht final - da gibt es noch viel zu verbessern.

    0
  • M

    fragmentierung ist bei linearen speichern (was eh alle derzeit verfügbaren sind) nur durch defragmentierung zu verhindern. defragmentierung kann entweder sofort gemacht werden, sobald eine fragmentierung erkannt wird oder erst später. nötig ist sie immer. so gut kann ein dateisystem gar nie sein, dass es ohne defragmentierung auskommt.

    ein beispiel:
    ich hab eine datei, die in direkt aufeinander folgenden sektoren auf der platte liegt. lösche ich einen sektor aus der mitte heraus, so wird die datei unweigerlich fragmentiert. ich kann das jetz ignorieren oder ich defragmentier die datei sofort, indem ich einfach alle sektoren nach dem loch um einen sektor weiter nach vorn schreib. im prinzip machen die windows defragmentierungsprogramme nichts anderes, als solche löcher zu stopfen.

    daraus folgt, dass es ein mythos ist, dass die bekannten linux dateisysteme keine fragmentierung erzeugen.

    björn

    0
  • M

    fragmentierung ist bei linearen speichern (was eh alle derzeit verfügbaren sind) nur durch defragmentierung zu verhindern. defragmentierung kann entweder sofort gemacht werden, sobald eine fragmentierung erkannt wird oder erst später. nötig ist sie immer. so gut kann ein dateisystem gar nie sein, dass es ohne defragmentierung auskommt.

    ein beispiel:
    ich hab eine datei, die in direkt aufeinander folgenden sektoren auf der platte liegt. lösche ich einen sektor aus der mitte heraus, so wird die datei unweigerlich fragmentiert. ich kann das jetz ignorieren oder ich defragmentier die datei sofort, indem ich einfach alle sektoren nach dem loch um einen sektor weiter nach vorn schreib. im prinzip machen die windows defragmentierungsprogramme nichts anderes, als solche löcher zu stopfen.

    daraus folgt, dass es ein mythos ist, dass die bekannten linux dateisysteme keine fragmentierung erzeugen.

    björn

    0
  • K

    Kann ich nicht bestätigen. Habe Mandrake 9.2 und 10 auf 2 verschiedenen PCs laufen gehabt. Mit IceWM. Und yoper läuft jetzt drauf. Mit KDE. Und yoper ist schneller. Merkbar schneller.

    Seltsam. Sicher dass du bei Mandrake nen eigenen Kernel installiert hast
    der ohne Debugging und Profiling compiliert ist?
    Also seit ich einen eigenen Kernel drauf habe hat Yoper performancetechnisch
    keine Chance.
    Vielleicht liegts aber auch an meiner Hardware-Config.😕

    Wie gesagt, mein Posting spiegelt nur meine persönliche Erfahrung wieder.

    0
  • N

    mastamind: Das hatten wir doch bereits erläutert... 🙄

    Kane: Dass eine Distro aus lauter i386(oder i586?)-optimierten Paketen performancemäßig nicht mit einer Distro mit -march=foobar-Paketen mithalten kann, ist doch normal, was erwartest Du Dir denn? 🙂

    0
  • K

    Wenn ich mich recht erinnere ist Yoper auf i686 compiliert.
    Mandrake afaik auf i568, also nicht der wesentliche Unterschied.

    0
Anmelden zum Antworten