Reiserfs und grosse Festplatte

  • Hallo !


    Will meinen VDR mit einer 200 GB Platte aufrüsten.
    Das Bios des Motherboard ist update, und erkennt die Platte richtig.


    Habe noch das steinalte Suse 9.0 , habe schon eine zusätzliche platte 20 GB (reiserfs) als video1 gemountet.


    Frage:
    Kann der Kernel und das reiserfs meiner Distro mit der neuen Platte (200GB) umgehen ?


    oder muss ich auf neuere Versionen umsteigen ?


    Gruß

    VDR 1 (SD) : ASRock A330 GC, 1 GB RAM, TT- FF Karte rev. 2.3, 7'' TFT, Lirc X10 - Selbstbau Gehäuse - Suse 11.3 (64) vdr-1.7.10 diverse Plugins
    VDR 2 (HD) : MSI G41M-P25, 2 GB RAM, E6700 2x3.20GHz, Gainward GT220, 2TB HD, Lirc X10, TT S2-3600 USB, TT S2-1600, - Suse 11.3 (64) NvidiaTreiber 260.19 vdr-1.7.18 - xineliboutplugin 1.0.90 cvs, xine-lib 1.1.90 , s2-liplianin DVB Treiber

  • Ich denke nicht, dass das Probleme machen sollte. Bei mir rennen 2x 200 GB-Festplatten tadellos unter Linux, selbst wenn diese nicht einmal korrekt vom Bios erkannt wurden. Laut Bios sind das nur 140 GB-Platten. Sollte also funktionieren und so alt ist Suse 9.0 ja dann auch nicht...

    Hardware: AMD Duron 900 MHz, 256 MB Ram, 1 x 400 GB und 2 x 200 GB Maxtor, 1 x 500 GB USB 2.0, Nec DVD-RW ND-3500AG, 1 x TT 1.6 FF DVB-S, 1 x Twinhan Budget DVB-T
    Software: VDR 1.4.1, BigPatch, DMH-DVD-Archive-Patch, Kernel 2.6.12
    ---
    "Hörma, wie heißt nomma dat Instrument mit den 3 Knöppen oben drauf...? - Ja richtig, Flöte!"

  • Überhaupt kein Problem. Bei mir im Keller werkelt eine SuSE 8.2, die immer wieder mal eine neu größere Platte dazubekommt und die kleinste verschwindet dafür. Die zwei "großen" sind momentan eine 250er und eine 200er. Und die laufen mit reiser wunderbar.

  • Hi !


    THX an alle !


    OK - Wollte nur auf nummer sicher gehen. ;)

    Gruß ! 8) 8)

    VDR 1 (SD) : ASRock A330 GC, 1 GB RAM, TT- FF Karte rev. 2.3, 7'' TFT, Lirc X10 - Selbstbau Gehäuse - Suse 11.3 (64) vdr-1.7.10 diverse Plugins
    VDR 2 (HD) : MSI G41M-P25, 2 GB RAM, E6700 2x3.20GHz, Gainward GT220, 2TB HD, Lirc X10, TT S2-3600 USB, TT S2-1600, - Suse 11.3 (64) NvidiaTreiber 260.19 vdr-1.7.18 - xineliboutplugin 1.0.90 cvs, xine-lib 1.1.90 , s2-liplianin DVB Treiber

    Einmal editiert, zuletzt von rudirabbit ()

  • Wobei Reiser3 halt Kack hoch vierundfünfzig ist, seit ich überall daheim auf XFS setze, lebe ich sorgenfreier *ggg*

    This is a .44 Magnum, the most powerful handgun in the world. It can take your head clean off. You've got to ask yourself one question, Do I feel lucky?
    easyvdr 0.9a2 - TT-DVB-S2-6400 - ASUS AT3IONT-I deluxe - Atom 330 - 1,5TB WD EADS - Denon 1910 - Toshiba 42X3030D - Harmony 700

    Einmal editiert, zuletzt von s_herzog ()

  • Zitat

    Original von s_herzog
    Wobei Reiser3 halt Kack hoch vierundfünfzig ist, seit ich überall daheim auf XFS setze, lebe ich sorgenfreier *ggg*


    dto.


    Kann ich nur beipflichten. Hatte einmal Probleme mit ReiserFS. Seitdem nur noch XFS!


    Gruß, schmalzz

    Streamingclient 1:
    [-] RaspiVDR MLD 5.x an Panasonic TV mit CEC :D


    Streamingclient 2:
    [-] RaspiVDR MLD 5.x - Samsung TV mit CEC


    Streamingserver:
    [---] Proxmox Server PVE7
    [- ] MLD 5.x Server - OctopusNet 4 Tuner

  • Hallo,


    habe nicht viel Ahnung davon, aber was habt Ihr gegen ext3?


    Ich will keinen Streit-Thread starten, nur fragen obs reiner Zufall ist, oder ob ich was suboptimal gelöst habe ?(

  • Zitat

    Original von Trekkie2
    Hallo,


    habe nicht viel Ahnung davon, aber was habt Ihr gegen ext3?


    Ich will keinen Streit-Thread starten, nur fragen obs reiner Zufall ist, oder ob ich was suboptimal gelöst habe ?(


    Ext3 ist Ext2 mit implantiertem Journal. Deshalb hat es den einzigen Vorteil, dass man es auch als ext2 mounten kann.


    Performancemäßig kannst du es allerdings total vergessen (es läßt keinerlei Intelligenz bei Zugriffen walten) und einige der advanced Features von XFS und Reiser hat es einfach nicht. XFS kannst du im Betrieb vergrößern -> Perfekt in nem RAID/LVM-Verbund.


    Stabil dürfte es allerdings sein. Ist ja schon uralt plus Journal. ;)

    This is a .44 Magnum, the most powerful handgun in the world. It can take your head clean off. You've got to ask yourself one question, Do I feel lucky?
    easyvdr 0.9a2 - TT-DVB-S2-6400 - ASUS AT3IONT-I deluxe - Atom 330 - 1,5TB WD EADS - Denon 1910 - Toshiba 42X3030D - Harmony 700

  • Hi !


    Da ich kein Linux Freak bin, und mein Reiserfs auch schon mal Probs gemacht hat, sind eure Antworten sehr interessant für mich !


    Ich könnte also meine neue Platte auf XFS aufsetzen.


    Meine fstab:


    /dev/hda6 / reiserfs defaults 1 1
    /dev/hda1 /video0 reiserfs defaults 0 0
    /dev/hdb1 /video1 reserfs defaults 0 0
    /dev/hda5 swap swap pri=42 0 0



    Ich will hdb1 (video1) mit meiner neuen Platte ersetzen in der fstab
    auf XFS setzen - richtig ?


    Will mein System nicht zerschießen, da es ansonsten super läuft !


    Also bei Neuinstallion als fs XFS wähen, vorgabe ist ja immer reiserfs ?


    THX !

    VDR 1 (SD) : ASRock A330 GC, 1 GB RAM, TT- FF Karte rev. 2.3, 7'' TFT, Lirc X10 - Selbstbau Gehäuse - Suse 11.3 (64) vdr-1.7.10 diverse Plugins
    VDR 2 (HD) : MSI G41M-P25, 2 GB RAM, E6700 2x3.20GHz, Gainward GT220, 2TB HD, Lirc X10, TT S2-3600 USB, TT S2-1600, - Suse 11.3 (64) NvidiaTreiber 260.19 vdr-1.7.18 - xineliboutplugin 1.0.90 cvs, xine-lib 1.1.90 , s2-liplianin DVB Treiber

  • Hi,


    weiß nicht, ob Novell mal wieder mit Big Blue im Clinch liegt, oder warum jfs bei Suse rausgeflogen ist, ich habe es mindestens 5-6 Jahre im Einsatz und möchte es nicht missen.


    Schau mal hier, ein aktueller Vergleich. Bei XFS sollte man sich im Klaren sein, dass das FS viel Speicher verwendet und wenn ein Stromausfall ist, sind die Daten wech.
    Gut, ist vielleicht nix, was alle Tage vorkommt, aber wissen sollte man es schon.
    Also ohne USV würde ich XFS nicht bedenkenlos empfehlen.


    Von reiserfs habe ich mal gelesen, dass es rel. schlecht wird, wenn die Platte rel. voll is - kann aber die Quelle nicht mehr nennen.

    Ich bin verantwortlich für das, was ich schreibe, nicht für das, was Du verstehst!

  • Hi !


    THX an geronimo !


    Die Nachteile des XFS sind schon sehr groß !
    Kann ja auch mal sein, daß das stabile Linux einen Warmstart benötigt, also Reset und die Platte ist Müll !! :§$%


    Gibt es eine Möglichkeit das jfs mit meiner Distro zu nutzen ?

    VDR 1 (SD) : ASRock A330 GC, 1 GB RAM, TT- FF Karte rev. 2.3, 7'' TFT, Lirc X10 - Selbstbau Gehäuse - Suse 11.3 (64) vdr-1.7.10 diverse Plugins
    VDR 2 (HD) : MSI G41M-P25, 2 GB RAM, E6700 2x3.20GHz, Gainward GT220, 2TB HD, Lirc X10, TT S2-3600 USB, TT S2-1600, - Suse 11.3 (64) NvidiaTreiber 260.19 vdr-1.7.18 - xineliboutplugin 1.0.90 cvs, xine-lib 1.1.90 , s2-liplianin DVB Treiber


  • Fehler: Auch XFS hat Journalling, die Dateisystemintegrität ist gesichert. Es gibt keine halb durchgeführten Writes, und ist ein Write erstmal im Journal, ist er nach dem Neustart auch korrekt auf Platte.


    Hast du einen Stromausfall, so sind weg:


    - im Cache verbliebene Writes, die noch nicht ins Journal kamen


    Mein Gott, dem System macht das prinzipiell nichts. Selbst wenn du gerade den Kernel neu bäckst, so wird der noch nicht vollständig abgeschlossene Write erst ins Journal gemacht, erst wenn die Datei geschlossen wird, wird sie gültig und ersetzt das alte Image.


    Der Linux Kernel kann Journal-Writes nichtmal puffern, ins Journal wird IMMER ungepuffert geschrieben. (Problematik: noflushd auf was Andrem als ext2 geht einfach nicht)


    Da kannst du zwischendrin den Strom wegnehmen wie du willst, XFS ist im Prinzip genauso sicher wie andere Journalling Filesysteme. Das ist ja gerade der Trick dabei. Siehe entsprechende Theorie beim Datenbankbau, zuerst das Log (Journal) "ausforcen", danach in die Datenbank schreiben. Nicht committete Operationen werden beim ANlauf rückgängig gemacht, committete Operationen werden wiederholt.


    Dass du ungespeicherte Daten in jedem Fall verlierst, ist klar, aber dein Linux ist mit XFS nicht weniger unkaputtbar als mit anderen Journalling FS...

    This is a .44 Magnum, the most powerful handgun in the world. It can take your head clean off. You've got to ask yourself one question, Do I feel lucky?
    easyvdr 0.9a2 - TT-DVB-S2-6400 - ASUS AT3IONT-I deluxe - Atom 330 - 1,5TB WD EADS - Denon 1910 - Toshiba 42X3030D - Harmony 700

    Einmal editiert, zuletzt von s_herzog ()

  • Hallo,


    das ist wie bei Radio Eriwan: im Prinzip ja, ...


    ... denn sofern ich es richtig behalten habe, werden außer bei ntfs bei keinem fs die echten Daten im journal gehalten, sondern nur die Metadaten, wie z.B. Dateiname, Größe, etc.
    Die echten Dateidaten gehen dagegen durch den/die Caches.


    Wenn Du mal etwas nach den einzelnen Kandiaten gurgelst, wirst Du selbst über die entsprechenden Kommentare stolpern. Ist nicht auf meinem Mist gewachsen.
    Aber das 'mal hier und mal da was lesen' war für mich auch unbefriedigend und deshalb habe ich Bonnie und Clyde auf die Kandidaten losgelassen :)


    Ich finde, dass die Ergebnisse ganz gut die Theorie widerspiegeln - nicht umsonst ist xfs bei fast allen Tests an der Spitze. Jeder muss für sich selbst entscheiden, welches FS für welchen Einsatz das richtige ist. Ich persönlich habe aus dem Vergleichstest mitgenommen, dass jfs für die Systempartition bestens geeignet ist (liegt bei den Dateioperationen recht gut) und xfs für große Video-Partitionen, wo es auf kontinuierlichen Durchsatz ankommt.


    Bei der aktuellen Suse habe ich es so gehandhabt, dass ich von CD starte, dann (mit Ctrl-Alt-F2) die Konsole wechsle und dort die Platte partitioniere / formatiere. Anschließend nochmal neu starten und im Installations-menü die Partition auswählen ohne neuformatieren.
    Funktioniert problemlos.

    Ich bin verantwortlich für das, was ich schreibe, nicht für das, was Du verstehst!

  • Zitat

    Original von geronimo
    Hallo,


    das ist wie bei Radio Eriwan: im Prinzip ja, ...


    ... denn sofern ich es richtig behalten habe, werden außer bei ntfs bei keinem fs die echten Daten im journal gehalten, sondern nur die Metadaten, wie z.B. Dateiname, Größe, etc.
    Die echten Dateidaten gehen dagegen durch den/die Caches.


    Jo, aber dann macht man kein Update-in-Place, sondern die neu geschriebenen Daten werden wenn sie aus dem Cache geforced werden an nen freien Platz geschrieben und anhand des Journals kann dann festgestellt werden, welches der richtige Datensatz ist...ist das Commit laut Journal durch, ist es der Neue, ist das Commit nicht durch, ist es der Alte ;)


    Bei aggressivem Cachen findet der virtuelle Stromausfall dadurch deutlich früher statt als der reale, das ist das Einzige, das passieren dürfte :D


    Also wenn man weiß, dass in 5 Minuten Stromausfall ist, möglichst JETZT schnell speichern und danach ein cat /dev/zero ~/fuellung machen *gggg*

    This is a .44 Magnum, the most powerful handgun in the world. It can take your head clean off. You've got to ask yourself one question, Do I feel lucky?
    easyvdr 0.9a2 - TT-DVB-S2-6400 - ASUS AT3IONT-I deluxe - Atom 330 - 1,5TB WD EADS - Denon 1910 - Toshiba 42X3030D - Harmony 700

    2 Mal editiert, zuletzt von s_herzog ()

  • Hi rudirabbit,


    Also bez. eines VDR brauchst Du Dir, denke ich, keine grossen Sorgen um dass FS machen. Solange Du keinen hochperformanten Fileserver aufsetzen moechtest, tun sich JFS/XFS/EXT3/Reiser3 nicht viel. Einige sind beim lesen schneller, andere beim schreiben, andere wiederumm bei vielen kleinen Zugriffen etc.


    Ich wuerde daher eher einen Blick auf Luxux-Features wie die o.g. "Resizing"-Moeglichkeiten legen.


    Ich habe damals schon rel. frueh von ext2 auf reiser gewechselt (1999? 2000?) und hatte mit Reiser NIE probleme, mit ext3 hingegen schon. Dabei muss man wissen dass das ext3 Problem bei mir an einen damaligen Bug im Kernel lag, der nur in einer Version existierte, ebenfalls der oft zitierte Reiser-Bug (Daten weg wenn Platte fast voll), das war glaube ich in einer alten Linux 2.4.11 (ca.) Version.


    Subjektiv bei mir folgendes:
    - ReiserFS: nehme ich immer fuer Desktop/Arbeitssyteme. Arbeitet schnell genug und SEHR zuverlaessig.
    - Ext3: verwende ich fuer den VDR, da nach meine Beobachtung das Initialisieren des FS beim Booten schneller geht als bei Reiser. Allerdings wird Ext2/3 alle X mal beim Init geprueft. Das dauert immer ein wenig, der Intervall (bzw. das "ob") laesst sich jedoch einstellen.


    Also: solange Du ein Journaling-FS verwendest, bist Du beim normalen Heimgebrauch eigentlich immer gut beraten.


    Gruss,
    Timo

    yaVDR 0.4-pre1 on ASUS 1015PN -> Big Screen and XBMC remote on Android.

  • Dateisysteme: Frag 10 Leute, und du wirst 10 verschiedene Antworten bekommen...


    Ich persönlich arbeite seit Ewigkeiten mit Reiser, und hatte auch noch nie mit Datenverlusten zu kämpfen. Für die VDR-Videopartition wird meist nur von ext2/3 abgeraten, da ext2 mangels Journal nicht mehr Zeitgemäss ist, und ext3 bei der Performance hinterher hinkt.


    Qualitativ halte ich XFS und Reiser3 beide für gut geeignet, trotz Vor- und Nachteilen auf beiden Seiten.


    Reiser4 soll sehr gute Performance bei Streaming-Anwendungen haben, aber so lange Reiser4 nicht in den Kernel aufgenommen ist und ich noch keine Knoppix-CD mit Reiser4 habe, lasse ich davon die Finger.


    Ein konkretes Problem ist mir bei Reiser3 und VDR aufgefallen: Da die Videopartition meistens randvoll ist, und es ein stetiges kommen und gehen an großen Dateien gibt, kommt es zwangsläufig über die Zeit zu starker Fragmentierung der Partition - unabhängig vom Dateisystem.
    Reiser3 scheint dann bei starker Fragmentierung sehr CPU-Lastig zu sein, und hat wohl meinen schwachen C3-600 bei mehreren Aufnahmen parallel ans Limit gefahren. Ob XFS da auch patzen würde, ist schwer zu sagen.


    Leider gibt es unter Linux noch bei keinem Dateisystem einen Defragmentierer, so dass nur das Umkopieren und Formatieren bleibt. Ein Dream-Team wäre da LVM und Reiser, damit kann man die Daten stückweise auf eine neue Partition kopieren, die alte Partition verkleinern und die neue vergrößern. Wenn, ja wenn LVM endlich im 2.6er Kernel wäre...


    Gruß,


    Udo

  • Hallo,


    Urig
    ist das inzwischen bei Dir gesichert, dass die Probleme am FS liegen?
    Also kein Unterschied mehr zwischen 2.4 und 2.6?


    Vielleicht solltest Du auch mal jfs probieren. Ist zwar bei Dauerdurchsatz nicht an der Spitze, braucht dafür aber auch weniger CPU

    Ich bin verantwortlich für das, was ich schreibe, nicht für das, was Du verstehst!

  • Hallo zusammen,


    hab's wieder gefunden - und zwar im Gentoo-Handbuch. Dort ist eine gute und *imho* faire Zusammenfassung der Dateisysteme.
    Ich stell den Ausschnitt mal hier rein:



    ... wobei vielleicht erwähnenswert wäre, dass das "vor kurzem" bei JFS ein Zeitraum von annähernd 10 Jahren beschreibt. Es wurde für AIX entwickelt, hieß bei OS/2 HTFS und wurde dann freigegeben bzw. für Linux portiert. Könnte also vom Alter mit XFS ungefär mithalten :)

    Ich bin verantwortlich für das, was ich schreibe, nicht für das, was Du verstehst!

    Einmal editiert, zuletzt von geronimo ()

  • @Tüdelkopp:
    > LVM ist im 2.6er Kernel, ist im "Menuconfig" bei Multi-device support (RAID and LVM)


    Seit wann? In meinem 2.6.13.4 ist LVM jedenfalls noch nicht wieder enthalten. So weit ich weis, flog LVM1 irgendwann während 2.5 heraus, weil ja sowieso LVM2 integriert werden sollte. Nur hat sich bisher niemand darum gekümmert.


    geronimo:
    > ist das inzwischen bei Dir gesichert, dass die Probleme am FS liegen?
    > Also kein Unterschied mehr zwischen 2.4 und 2.6?


    Schwer zu sagen. Seit dem dokumentierten Fall habe ich keine Probleme mehr beobachtet. Mittlerweile habe ich auch das Dateisystem erneuert, und subjektiv läuft das Schneiden jetzt deutlich schneller ab, als vorher. 2.4 scheint trotzdem etwas schneller dabei zu sein, vielleicht wurden die Fragmentierungs-Vermeidungs-Strategien in 2.6 verfeinert, was auf langsamen CPUs bremst.


    Bevor ich aufgeräumt hab, hab ich mit debugreiserfs und ein paar Skripten folgende Blockgrößen-Analyse des freien Speichers (8Gb von 105Gb) gemacht:


    4k..8k: 16024x, 93.9Mb
    12k..32k: 27388x, 554.4Mb
    36k..128k: 39895x, 2229Mb
    132k..512k: 7735x, 1882Mb
    516k..2048k: 1558x, 1284Mb
    2052k..8192k: 130x, 493.5Mb
    8196k..32768k: 56x, 877.6Mb
    32768k..131072k: 15x, 894.4Mb


    dh. fast 3 Gb des freien Speichers bestand aus mehr als 80.000 Brocken kleiner als 128k. Wenn das nicht fragmentiert ist...


    Gruß,


    Udo

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!