Moin,
ZitatOriginal von Riscool
... oder gepatchter 2.4er Kernel ist notwendig.
ist spätestens seit 2.4.25 (kann auch schon 2.4.24 sein, hab gerade keine alten original Kernelsourcen zur Hand) im std. Kernel enthalten.
mfG
Carsten
Moin,
ZitatOriginal von Riscool
... oder gepatchter 2.4er Kernel ist notwendig.
ist spätestens seit 2.4.25 (kann auch schon 2.4.24 sein, hab gerade keine alten original Kernelsourcen zur Hand) im std. Kernel enthalten.
mfG
Carsten
ZitatDa für Videodaten eine Optimierung auf kleine Dateien wohl kaum nötig ist , fallen die Neueren Systeme doch fast alle raus - da sich deren Optimierung doch im Wesentlichen auf den Klinkruscht bezieht - oder hab ich da was nich mitgekriegt ?
Leider etwas zu kurz gedacht: Bei mir ist es so, dass auf der Daten-Partion neben den Videos noch unzählige .mp3 und .jpg-Dateien liegen (MP3-Plugin und Image-Plugin sei Dank!).
Ich glaube, vielen anderen Usern dürfte es ebenso gehen.
Ein auf große Dateien optimiertes FS scheidet daher für mich aus.
Ich glaube, die Wörter "kleine Dateien" beziehen sich im Fall von optimierten Dateisystemen auf Files mit einer größe von wenigen KB.
Z. B. die Dateien, die das Videotext Plugin ablegt. <1KB
MP3s sind dagegen ja gigantisch groß...
JPGs von Digi-Cams jenseits der 4MP sind ja mittlerweile auch schon größer als 1MB!
Gruß
Riscool
eindeutig xfs.
hatte schon uebele probleme mit reiserfs und ext3 ... seit dem ich xfs nutze nie wieder probleme gehabt.
kann ich auch nur empfehlen.
Fürs System ext3, für die Video-Daten Partition xfs.
Bitte eins nicht vergessen. Die Ressourcen Usage.
Besonders Reiser braucht deutlich mehr CPU (und ich glaube auch Speicher)
um eine Geschwindigkeit zu erreichen.
Ganz am Anfang der Diskussion sagte wer ext3 hat lange Dateisystem Checks.
Das kann (und sollte) man ganz einfach abdrehen, dann wird nicht mehr
gecheckt. Braucht man ja auch nicht bei einem Journal.
Ich habe auch bei Reiser schon defekte Partitionen erlebt, daher kommt mir
der Reiser auf keine Partition mehr.
Man kann beim Formattieren auch ein paar Kleinigkeiten beachten. Ich
kenns nur von ext3, aber bei anderen vielleicht ähnlich:
VDR hat große Dateien, also die Blockgröße auf maximal stellen (8KB ?).
Das verbratet bei kleinen Dateien etwas Platz aber für /video ists ideal.
Das Dateisystem reserviert für Root etwas Platz (5%), für den Fall dass die
Platte voll wird, damit Root noch aufräumen kann. Das kann man abdrehen.
--Stefan
Hab schon immer (d.h. seit es als Kernel-Patch verfügbar war) xfs benutzt, bis - ja bis ich meinen Fileserver endlich auf ein Soft-Raid-5 umgestellt habe.
Denn da stößt man auf ein Problem, das zwar angeblich lösbar ist, mir jedoch nicht gelungen ist. Und zwar die Block-Größe. Die ist bei xfs per default für Journal und Daten unterschiedlich (512 <-> 4096). Nun hat aber das Soft-Raid beim Einrichten eine fest eingebrannte Blockgröße und die paßt entweder zum einen oder zum anderen Wert (oder noch schlimmer zu keinem von beiden). Abgesehen von haufenweise Einträgen in /var/log/messages (die einige sogar mit Kernel-Patch ausblenden) führt das dazu, daß jeder Wechsel zum Flush des Cache zwingt. Das killt jede Performance. Nun gibt's diverse Möglichkeiten an den verschiedenen Parametern von mkfs.xfs zu drehen, aber gelungen ist es mir nicht, so daß ich dann irgendwann aus Zeitmangel aufgab und den Server nun unter reiserfs laufen lasse.
marvel
ZitatOriginal von marvel
Hab schon immer (d.h. seit es als Kernel-Patch verfügbar war) xfs benutzt, bis - ja bis ich meinen Fileserver endlich auf ein Soft-Raid-5 umgestellt habe.
Gelten die Probleme nur für ein Software-RAID oder muss man bei Hardware-RAID (z.B. 3ware-Controller) auch damit rechnen? Ich liebäugele gerade mit einem derartigen Gerät, um meine Datensicherheit zu erhöhen.
Hi,
Seit ca. nem Jahr jfs für die Systempartition,und
immer ext3 für die /video.
Noch nie Probleme damit gehabt.
Vorher auch länger xfs für die Systempartition.
Damit gabs ebenfalls nie Probleme.
Bert
Hi!
Ich habe zuerst auch ext3 gehabt, aber ext3 wird langsam wenn mehrere Dateien gleichzeitig gelesen und geschrieben werden. Also genau das was vdr tut.
habe jetzt xfs und bin zufrieden.
Kann mich über reiserfs gar nicht beklagen. Läuft auf mehreren Kisten stabil und auch mal ein fsck mit härteren Maßnahmen brachte alles wieder ins Lot.
Für die Statistik: Bei mir ist seit langem auch alles mit reiserfs formatiert. Angefangen irgendwann 2000 (Kernel 2.2 -> reiserfs-Support selber per Patch nachgerüstet) mit einer einzelnen Testpartition hatte ich bisher ("trotz" reiserfs ) noch keine Datenverluste.
Mhh. mein VDR läuft schon seit Ewigkeiten mit ext3 FS. (Auch schon der VDR vor c't vdr). Alles im allen so an die 2 Jahre.
Ich hatte noch nie Probleme. Gut, mein VDR wird selten ausgeschaltet,
wenn dann aber meist "hart" per Knopfdruck. (Ich weiss nicht woher bei manchen die langen Checkzeiten kommen, da das transparent im Hintergrund läuft)
Das Gute dabei ist, das man ext3 auch als ext2 mounten kann um dann ext2 Tools nutzen zu können.
Gegen raiserfs haben mich zwei Punkte gestimmt:
1) der (CPU-) Resourcenverbrauch ist gegenüber ext3 wesentlich
grösser
2) es gibt kein dump etc. um "ordentliche" Sicherungen anzulegen
ext3: no way das ich warte bis meine platten gescannt sind (siehe sig)
Bei mir bis jetzt reiserfs >2..3J.
Probleme: minimal
Datenverlust: ja, 1x,
root cause: reiserfsck falsch bedient (hände weg von --scan-whole-partition !!)
Gerade auf xfs umgestiegen (3x120G++1x 160G+ 2x250G, da kommt freude beim kopieren auf ).
Performance glatt verdoppelt
Nachteil: teilweise wird das system träge beim kopieren. Offensichtlich schluckt der kopierprozess massiv cpu-last. Diese probleme hatte ich mit reiser nicht !
Vielleicht hat xfs ein last problem.
Mal sehen wie sich das entwickelt . . .
gruss Peter
ZitatOriginal von PeterD
ext3: no way das ich warte bis meine platten gescannt sind (siehe sig)
Kann man ja auch ausschalten... aber Du hast schon recht, auf Datenpartitionen nehme ich das auch nicht.
ZitatBei mir bis jetzt reiserfs >2..3J.
Probleme: minimal
Auch seit langem reiserfs, allerdings z.T. erhebliche Probleme- glücklicherweise beim fsck alles wieder gefunden.
Vielleicht liegt es auch an der relativ frühen Version (Suse 8.0)? Insbesondere PRobleme beim resize des Dateisystems Probleme. Danach ist oft ein --rebuild-tree notwendig.
Zitat
Gerade auf xfs umgestiegen (3x120G++1x 160G+ 2x250G, da kommt freude beim kopieren auf ).
HAtte ich mir auch überlegt- xfs läßt sich aber halt nicht verkleinern. Und damit ist es für mich absolut unbrauchbar!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!