Hallo, zwecks Neuinstallation von OS10.2 stellt sich gerade die Frage, welches Dateisystem wohl am besten sei. Ext3 wird als default voreingestellt. Von SL8.1 bis OS10 habe ich mit ReiserFS gearbeitet. Ich verwende neben Squid und Samba eigentlich nur gewöhnliche Standard-Software, also nichts wirklich besonderes. In den Dokumentationen habe ich für meine Zwecke nichts Herausragendes gefunden, weshalb ich mich nun für ein bestimmtes Dateisystem entscheiden solle. Gibt es da gravierende Unterschiede, die für das eine oder für das andere Dateisystem sprechen? BTW: Falls hierfür von Interesse: OS10.2 soll auf einer WD Raptor an einem 3ware Controller betrieben werden. CPU AMD Athlon 1800+ mit 1GB RAM. Wie sollte man sich nun entscheiden? TIA Schöne Grüße Mathias Klose -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
RTFAQ: http://suse-linux-faq.koehntopp.de/q/q-filesystems-auswahl.html Gruß Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mathias Klose schrieb:
Ext3 wird als default voreingestellt. Von SL8.1 bis OS10 habe ich mit ReiserFS gearbeitet. Gibt es da gravierende Unterschiede, die für das eine oder für das andere Dateisystem sprechen?
BTW: Falls hierfür von Interesse: OS10.2 soll auf einer WD Raptor an einem 3ware Controller betrieben werden. CPU AMD Athlon 1800+ mit 1GB RAM.
Eine richtige bzw. eindeutige Antwort wirst du nicht bekommen. (Hierzu hilft auch das FAQ'chen von [1]) Aber ich kann die Vor/Nachteile aus meiner Sicht schildern: Ich verwende reiserfs/ext3 "abwechselnd" auf meinen Maschienen Das Vergrößern/Verkleinern von Reiserfs geht zwar mit einem Tool, man muss aber höllisch aufpassen. Ich habe es schon mal gemacht, es hat auch funktioniert, muss aber nicht immer. Bei ext3 habe ich noch nichts derartiges versucht. Bei Fehlern (Absturz/Strom weg) hat schon mal reiserfs viel versemmelt, wo ext3 kaum Probleme hatte. Auch merkt man beim Löschen größerer Dateien (z.B.: DVB-Timeshifting), dass es mit reiserfs schnell gelöscht ist, wobei ext3 ziemlich viel länger braucht. Auch hat der Herrn Reiser vllt keine reine Weste... :-) [2] Spaß beiseite: Er hat AFAIR mitten in der Entwicklung von reiserfs das FS fallen gelassen und nicht mehr weitergearbeitet, da haben aber schon viele User es eingesetzt. HTH Martin [1] http://suse-linux-faq.koehntopp.de/q/q-filesystems-auswahl.html [2] http://www.heise.de/newsticker/meldung/86524 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGyfS/E5UqXaCvB8IRAq7ZAJ978Of5Wl8nhHp29OkU5hRD+EGJpACbBQQf O8eGOpOHn8FVv41SV6sSc9g= =aE0e -----END PGP SIGNATURE----- -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
On Monday 20 August 2007 22:08, Martin Ereth wrote:
Mathias Klose schrieb:
Ext3 wird als default voreingestellt. Von SL8.1 bis OS10 habe ich mit ReiserFS gearbeitet. Gibt es da gravierende Unterschiede, die für das eine oder für das andere Dateisystem sprechen?
BTW: Falls hierfür von Interesse: OS10.2 soll auf einer WD Raptor an einem 3ware Controller betrieben werden. CPU AMD Athlon 1800+ mit 1GB RAM.
Eine richtige bzw. eindeutige Antwort wirst du nicht bekommen. (Hierzu hilft auch das FAQ'chen von [1])
Aber ich kann die Vor/Nachteile aus meiner Sicht schildern: Ich verwende reiserfs/ext3 "abwechselnd" auf meinen Maschienen
Das Vergrößern/Verkleinern von Reiserfs geht zwar mit einem Tool, man muss aber höllisch aufpassen. Ich habe es schon mal gemacht, es hat auch funktioniert, muss aber nicht immer. Bei ext3 habe ich noch nichts derartiges versucht.
Bei Fehlern (Absturz/Strom weg) hat schon mal reiserfs viel versemmelt, wo ext3 kaum Probleme hatte.
<schnipp> ich kann nur bestätigen, dass ich nach einem Crash ReiserFs unser Server neu installieren mußte, mit einem Downtime für unsere Firma von einem Tag. Nicht schön. So etwas ist mit ext2/ext3 noch nie passiert. Ich benutze also ext3. "Features" und "Sonerausstattungen" sind mir egal, ein Dasteisystem ist kein Auto, es muss funzen. -- Regards, Walter Ulmke Ulmke Machine Tools, 48496 Hopsten, Germany -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
On 8/20/07, Mathias Klose <info@mathias-klose.de> wrote:
Hallo,
zwecks Neuinstallation von OS10.2 stellt sich gerade die Frage, welches Dateisystem wohl am besten sei.
Ext3 wird als default voreingestellt. Von SL8.1 bis OS10 habe ich mit ReiserFS gearbeitet.
Ich verwende neben Squid und Samba eigentlich nur gewöhnliche Standard-Software, also nichts wirklich besonderes.
In den Dokumentationen habe ich für meine Zwecke nichts Herausragendes gefunden, weshalb ich mich nun für ein bestimmtes Dateisystem entscheiden solle.
Gibt es da gravierende Unterschiede, die für das eine oder für das andere Dateisystem sprechen?
BTW: Falls hierfür von Interesse: OS10.2 soll auf einer WD Raptor an einem 3ware Controller betrieben werden. CPU AMD Athlon 1800+ mit 1GB RAM.
Wie sollte man sich nun entscheiden?
XFS ;-) . Nehme ich fast überall. kk
On 8/20/07, Michael Skiba <michael@michael-skiba.de> wrote:
Am Dienstag, 21. August 2007 00:03 schrieb Karsten Künne:
On 8/20/07, Mathias Klose <info@mathias-klose.de> wrote:
Wie sollte man sich nun entscheiden?
XFS ;-) . Nehme ich fast überall.
Ist XFS nicht eher für _wirklich_ große Dateisysteme ausgelegt?
Sicher, aber das heisst ja nicht, dass man's für kleine nicht auch nehmen kann, oder? Und das mit der Grösse ist sowieso immer relativ. Ich habe z.B. jetzt in meinem PC zu Hause eine 500 GB Platte drin, das war vor ein paar Jahren noch "wirklich extrem gross", und bei der Grösse, denke ich, ist XFS schon das Filesystem der Wahl (bis dann irgendwann mal ZFS kommt ;-) ). Gruss, Karsten.
Am Dienstag, 21. August 2007 03:33(Ja, um halb vier morgends..) schrieb Karsten Künne:
On 8/20/07, Michael Skiba <michael@michael-skiba.de> wrote:
Am Dienstag, 21. August 2007 00:03 schrieb Karsten Künne:
On 8/20/07, Mathias Klose <info@mathias-klose.de> wrote:
Wie sollte man sich nun entscheiden?
XFS ;-) . Nehme ich fast überall.
Ist XFS nicht eher für _wirklich_ große Dateisysteme ausgelegt?
Sicher, aber das heisst ja nicht, dass man's für kleine nicht auch nehmen kann, oder? Und das mit der Grösse ist sowieso immer relativ. Ich habe z.B. jetzt in meinem PC zu Hause eine 500 GB Platte drin, das war vor ein paar Jahren noch "wirklich extrem gross", und bei der Grösse, denke ich, ist XFS schon das Filesystem der Wahl (bis dann irgendwann mal ZFS kommt ;-) ). Ich hab hier irgendwo glaub ich noch nen Linux Users Magazin rumliegen, wo das mal behandelt wurde, und da war von richtig großen Dateisystemen die Rede, mehrere PBs AFAIK. Aber ich werd mal gucken ob ich das morgen nochmal finde ;)
Solange es gut und schnell läuft gibts ja auch eigentlich nichts zu meckern ;D Grüße Michael
Karsten Künne wrote:
[...] Ich habe z.B. jetzt in meinem PC zu Hause eine 500 GB Platte drin, das war vor ein paar Jahren noch "wirklich extrem gross", und bei der Grösse, denke ich, ist XFS schon das Filesystem der Wahl
Als XFS designed wurde (und das ist schon etliche Jaehrchen her; es ist eines der aeltesten Journaling Filesysteme ueberhaupt) hatten die Entwickler bereits weitaus Groesseres im Sinn. Es ist erstaunlich, wie zukunftsorientiert das damals war. 500 GB ist da echt nicht der Rede wert. Bei uns sind es ueber >500 TB, und selbst das ist weit unter der Grenze von 8 EB (wohlgemerkt: da liegt noch PT dazwischen), die XFS fuer die maximale Groesse eines Filesystems hat. Th. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Thomas Hertweck wrote:
[...] (wohlgemerkt: da liegt noch PT dazwischen) [...]
Grrr, sollte natuerlich "PB" heissen. Th. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Dienstag, 21. August 2007 20:06 schrieb Thomas Hertweck:
Als XFS designed wurde (und das ist schon etliche Jaehrchen her; es ist eines der aeltesten Journaling Filesysteme ueberhaupt) hatten die Entwickler bereits weitaus Groesseres im Sinn.
Ja, aber als es designed wurde, wurde sicher nicht nur an die Zukunft gedacht, sondern auch darauf geachtet, das es auf real existierender Hardware (und die damaligen Platten selbst von Großrechnern waren "etwas" kleiner dimensioniert, als die heute üblichen Platten) gut lief. Hier auf der "kleinen" 60 GB Notebook-Platte läufts jedenfalls hervorragend, kann ich jedem nur ans Herz legen. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Montag, 20. August 2007 schrieb Mathias Klose:
Hallo,
zwecks Neuinstallation von OS10.2 stellt sich gerade die Frage, welches Dateisystem wohl am besten sei.
Ext3 wird als default voreingestellt. Von SL8.1 bis OS10 habe ich mit ReiserFS gearbeitet.
Ich verwende neben Squid und Samba eigentlich nur gewöhnliche Standard-Software, also nichts wirklich besonderes.
In den Dokumentationen habe ich für meine Zwecke nichts Herausragendes gefunden, weshalb ich mich nun für ein bestimmtes Dateisystem entscheiden solle.
Gibt es da gravierende Unterschiede, die für das eine oder für das andere Dateisystem sprechen?
BTW: Falls hierfür von Interesse: OS10.2 soll auf einer WD Raptor an einem 3ware Controller betrieben werden. CPU AMD Athlon 1800+ mit 1GB RAM.
Wie sollte man sich nun entscheiden?
Du kannst auch den Squid-cache auf eine Reiserfs Partiton legen und die root Partition mit ext3 formatieren. Vorteil von ext3 ist immer noch, das es im Notfall von jeder Bootdiskette/LiveCD als ext2 gemountet werden kann. Obendrein verhinderst du so, das dir irgendwann wegen des Squid / volläuft. Ebenso kannst du /tmp auf eine Partition auslagern (/var/tmp löschen und Link auf /tmp machen) MFG Markus -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, On Tuesday 21 August 2007 02:32:36 Markus Wunder wrote:
Ebenso kannst du /tmp auf eine Partition auslagern (/var/tmp löschen und Link auf /tmp machen)
Macht es hier Sinn ext2 fuer /tmp zu verwenden? Roman -- Roman Fietze Telemotive AG Büro Mühlhausen -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Dienstag, 21. August 2007 schrieb Roman Fietze:
Hallo,
On Tuesday 21 August 2007 02:32:36 Markus Wunder wrote:
Ebenso kannst du /tmp auf eine Partition auslagern (/var/tmp löschen und Link auf /tmp machen)
Macht es hier Sinn ext2 fuer /tmp zu verwenden?
Denke eher nicht. Bei einem Absturz des Systems dauert der Filesystemcheck ewig. Da du dort viele offene Dateien hast. Dir wird dann /tmp/lost+found bald aus allen Nähten Platzen, obwohl die Dateien nicht "Lebenswichtig" sind. Ich würde dort eher auf ReiserFS setzen. Datenverluste beim Systemcrash sind dort egal. Die Dateien werden dort beim Booten bzw. öffnen der jeweiligen Anwendung wieder angelegt. Ext2 verwende ich nur noch für die bis zu 250 MB für /boot. Das ist für viele andere Dateisysteme Winzig. In /boot befinden sich selten offene Dateien die bei einem Crash beschädigt werden. Ich verwende für: / ext3 /boot ext2 /tmp reiserfs (link von /var/tmp auf /tmp) /home kommt übers Netz per NFS (sind 2 Platten, eine ext3 die andere ReiserFS die sich per Cron und rsync sycronisieren - wenn das eine FS Fehler hat liegen die Daten nochmals auf einem Fehlerfreien) Den Squid-Cache wprde ich auch auf ein ReiserFS legen. Selbst wenn dort Daten verloren gehen, ist es eigentlich egal. Im zweifelsfall kann man Squid sagen, er soll den Cache neu aufbauen. MFG Markus -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Gibt es da gravierende Unterschiede, die für das eine oder für das andere Dateisystem sprechen?
Hallo Matthias, Vor wenigen Wochen gab es hierzu bereits einen längeren thread. Lief unter dem Topic "OpenSUSE 10.2 64-bit". Der Topic wurde später in "Dateisysteme" umbennant. Führ Dir den mal zu gemüte. Ich habe daraus entnommen (und auch aus anderer Recherche), daß erheblich mehr Leute Probleme mit reiserfs als mit ext3 hatten. Reiserfs hat allerdings den grossen Vorteil, daß es resizeable ist, und die Anzahl der inodes (und damit der Dateien) unbegrenzt ist. Bei ext3 kannst Du nicht mehr inodes anlegen als bei der Formatierung der Partition angelegt wurden. Damit bist Du dann auf ewig veheiratet. Kann ein problem werden, wenn Du viele kleine dateien hast. Bernd -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Vor wenigen Wochen gab es hierzu bereits einen längeren thread. Lief unter
dem Topic "OpenSUSE 10.2 64-bit". Der Topic wurde später in "Dateisysteme" umbennant. Führ Dir den mal zu gemüte. Ich habe daraus entnommen (und auch aus anderer Recherche), daß erheblich mehr Leute Probleme mit reiserfs als mit ext3 hatten. Reiserfs hat allerdings den grossen Vorteil, daß es resizeable ist, und die Anzahl der inodes (und damit der Dateien) unbegrenzt ist. Bei ext3 kannst Du nicht mehr inodes anlegen als bei der Formatierung der Partition angelegt wurden. Damit bist Du dann auf ewig veheiratet. Kann ein problem werden, wenn Du viele kleine dateien hast.
Ein weiterer Punkt ist, dass nach einem Crash ext3 ein fsck durchführt. Und bei ein paar Hundert GB kann dass schon eine Weile dauern. Schrecke darum ein wenig vom Einsatz von ext3 ab. Liege ich da falsch? Toni -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Ein weiterer Punkt ist, dass nach einem Crash ext3 ein fsck durchführt. Und bei ein paar Hundert GB kann dass schon eine Weile dauern. Schrecke darum ein wenig vom Einsatz von ext3 ab.
Liege ich da falsch?
Toni
Hallo, Ich gehe davon aus, daß jedes vernünftige Dateisystem nach einem Crash einen Check durchführt. Das ist ja auch gut so. Und das sollte bei jounailling-Dateisystemen wie reiserfs und ext3 eigentlich recht flott gehen. Bernd -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
On Tuesday 21 August 2007 16:22:07 Lentes, Bernd wrote:
Ein weiterer Punkt ist, dass nach einem Crash ext3 ein fsck durchführt. Und bei ein paar Hundert GB kann dass schon eine Weile dauern. Schrecke darum ein wenig vom Einsatz von ext3 ab.
Liege ich da falsch?
Ich gehe davon aus, daß jedes vernünftige Dateisystem nach einem Crash einen Check durchführt. Das ist ja auch gut so. Und das sollte bei jounailling-Dateisystemen wie reiserfs und ext3 eigentlich recht flott gehen.
Also bei ext3 kann es einwnig dauern. Je nach dem wie groß die Partition ist. Ich habe mit xfs gute Erfahrung gemacht. Bei xfs kann man auch die Größe ändern. Bye Michael -- Enttäuscht vom Affen, schuf Gott den Menschen. Danach verzichtete er auf weitere Experimente. -- Mark Twain _____________________________________________________________________________ http://macbyte.info/ Mobile Loadavg.: 0.44 1.24 1.06 http://dattuxi.de/ Registered Linux User #228306 Linux 2.6.20-16-x86_64 ICQ #151172379 -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo,
Ich gehe davon aus, daß jedes vernünftige Dateisystem nach einem Crash einen Check durchführt. Das ist ja auch gut so. Und das sollte bei jounailling-Dateisystemen wie reiserfs und ext3 eigentlich recht flott gehen.
Bernd -- Um die Liste abzubestellen, schicken Sie eine Mail an:
Soweit verstehe ich das. Gibt's irgendwelche Infos, welches schneller mit checken ist. Meine Erfahrung ist, ext3 braucht lange dazu, reiserfs ist schneller hoch (ok, kommt natürlich auf die Art des Crashes an) Toni -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, Am Dienstag, 21. August 2007 16:22 schrieb Lentes, Bernd:
Ein weiterer Punkt ist, dass nach einem Crash ext3 ein fsck durchführt.
Nach einem schlimmen Crash tun das auch andere Dateisysteme. Es ist eher die Frage, wie anfällig Journalling-Systeme für so heftige Defekte sind, daß das Journalling auch nichts mehr bringt.
Und bei ein paar Hundert GB kann dass schon eine Weile dauern. Schrecke darum ein wenig vom Einsatz von ext3 ab.
Dauert schon bei einigen zehn GB nach meiner Erfahrung ziemlich lange, aber natürlich hängt das sowohl von der Geschwindigkeit der Platte als auch von der Anzahl der Defekte im Dateisystem ab. Andere Parameter mögen dafür auch eine Rolle spielen. Aber die Korrektheit der Reparatur geht für mich vor. Die Reparaturdauer ist Nebensache, denn allzu oft wird es ja wohl nicht passieren. Sonst wäre das Dateisystem nicht so stabil, wie ich mir das wünsche. Mit reiserfs habe ich keine Reparaturerfahrung, da ich damit noch nie einen Crash (z.B. auf einem kleinen Mail-Server) hatte. Allerdings hatte ich mal beim Einrichten von reiserfs einige Ungereimtheiten, so daß ich gleich wieder die Finger davon ließ (obwohl ich es schon mit Erfolg benutzte).
Ich gehe davon aus, daß jedes vernünftige Dateisystem nach einem Crash einen Check durchführt. Das ist ja auch gut so.
Ich dachte bis vor kurzem immer, daß durch das Journalling auch bei einem Stromausfall noch nicht abgeschlossene Schreibvorgänge protokolliert werden und somit nach einem Wiederhochfahren des Systems entweder fertiggestellt oder bei Mangel an genügenden Infos über den Schreibvorgang gar nicht mehr getätigt werden, so daß am Ende keine im technischen Sinne fehlerhaften Dateien übrigbleiben. Es können natürlich der einen oder anderen Datei dann Informationen fehlen, die man schon für geschrieben hielt. Aber technisch sollten sie in Ordnung sein. Durch das Journalling sollten m.a.W. die Schreibvorgänge atomar (unteilbar) werden, also entweder ganz oder gar nicht auf dem Dateisystem durchgeführt werden - zumindest war das bisher immer meine Vorstellung. Bisher, denn im letzten halben Jahr hatte ich zwei heftige Defekte auf mehreren ext3-Dateisystemen auf zwei Platten, und zwar nicht aufgrund eines Stromausfalls, sondern kürzlich einmal mitten im normalen Betrieb (cups druckte nicht mehr richtig und Firefox ließ sich nicht mehr starten und einige andere seltsame, aber harmlose Anomalien) und das andere Mal war vor 6 Monaten, nach einem gezielten Reboot. Beim Hochfahren waren die ext3-Systeme derart defekt, daß eine automatische Reparatur durch fsck.ext3 nicht mehr möglich war. Das Journalling von ext3 scheint nicht so das Gelbe vom Ei zu sein. Es ist wohl auch nicht so fest mit dem eigentlichen Dateisystem wie z.B. bei reiserfs verbunden, sondern scheint eher ein Aufsatz auf ext2 zu sein. Ob das ein Nachteil sein muß, weiß ich nicht. Freilich habe ich mit meinen zwei Ausfällen keine gute statistische Signifikanz - da kann auch mal viel Pech im Spiel sein. Nach der Reparatur jeweils mit fsck.ext3 -cvy /dev/hda<x> waren auf den Systemen unter /usr und /opt etliche Software-Pakete defekt aber auch auf anderen Systemen fehlten jeden Menge Daten, die jedoch alle wieder installiert bzw. wiederhergestellt werden konnten. Auffällig war, daß in beiden Fällen die Uptime > 150 Tage war, aber ich dachte, das sei für Unix-Systeme nichts besonderes. Ich hatte übrigens keine Bad Blocks auf den Platten. Ich erwähne das nur, weil natürlich Journalling dagegen auch nichts machen kann, wenn welche während des Betriebs auftreten.
Und das sollte bei jounailling-Dateisystemen wie reiserfs und ext3 eigentlich recht flott gehen.
Genauer gesagt, ist es ja der Sinn von Journalling, daß nach einem Stromausfall oder allgemein nach einem "Nichtabschließenkönnen" von Schreibvorgängen Reparaturen mit fsck am Dateisystem unnötig sind, weil das System sozusagen "clean" bleibt, denn ein Schreibvorgang ins Dateisystem wird solange nicht aus dem Journal ausgetragen, bis er vollständig im Dateisystem abgeschlossen ist. Bei einem unvollständigen Schreibvorgang muß der ursprüngliche Zustand einer Datei aus dem Journal rekonstruiert werden können, so das eben keine Reparatur mit fsck nötig ist. Welche Vorgänge bei mir passierten, daß das Journalling nichts mehr half, weiß ich nicht. Gruß, Tom -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Thomas Michalka wrote:
[...] Ich dachte bis vor kurzem immer, daß durch das Journalling auch bei einem Stromausfall noch nicht abgeschlossene Schreibvorgänge protokolliert werden und somit nach einem Wiederhochfahren des Systems entweder fertiggestellt oder bei Mangel an genügenden Infos über den Schreibvorgang gar nicht mehr getätigt werden, so daß am Ende keine im technischen Sinne fehlerhaften Dateien übrigbleiben. Es können natürlich der einen oder anderen Datei dann Informationen fehlen, die man schon für geschrieben hielt. Aber technisch sollten sie in Ordnung sein. Durch das Journalling sollten m.a.W. die Schreibvorgänge atomar (unteilbar) werden, also entweder ganz oder gar nicht auf dem Dateisystem durchgeführt werden - zumindest war das bisher immer meine Vorstellung.
Das ist nicht ganz korrekt. Wenn von "Journaling" gesprochen wird, wird darunter oft nur das Journaling von Metadaten verstanden. Das garantiert Dir lediglich ein konsistentes Filesystem, aber *keine* konsistenten Dateien. Um letzteres zu gewaehrleisten brauchst Du "Full Journaling" - das ist ueblicherweise allerdings *nicht* die Standardeinstellung, da die Erhoehung der Sicherheit Einbussen bei der Performance mit sich bringt. Cheers, Thomas -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
On Wed, 22 Aug 2007 19:42:57 +0100, Thomas Hertweck wrote:
Um letzteres zu gewaehrleisten brauchst Du "Full Journaling" - das ist ueblicherweise allerdings *nicht* die Standardeinstellung, da die Erhoehung der Sicherheit Einbussen bei der Performance mit sich bringt.
Und zwar ziemlich deutlich, zumindest bei meinen Versuchen vor einiger Zeit. Philipp -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Anton Renner wrote:
[...] Ein weiterer Punkt ist, dass nach einem Crash ext3 ein fsck durchführt. Und bei ein paar Hundert GB kann dass schon eine Weile dauern. Schrecke darum ein wenig vom Einsatz von ext3 ab.
Liege ich da falsch?
Ja. Nach einem Crash wird ext3 keinen vollstaendigen Check des Filesystems durchfuehren, es findet lediglich ein Journal replay statt - das ist ja genau der Sinn eines Journaling Filesystems. Danach ist das Filesystem normalerweise als "clean" markiert und es wird ohne weitere Komplikationen gebootet. Sollte beim Replay etwas schief gehen und/oder es zu einem Fehler kommen, d.h. das Filesystem kann nicht als "clean" markiert werden, dann wird fsck einen vollstaendigen Check des Filesystems vornehmen. Das kann dann natuerlich recht lange dauern. Gleiches kann aber auch bei anderen Journaling Filesystemen wie ReiserFS und XFS passieren, und dann wird dort ebenfalls ein vollstaendiger Check durchgefuehrt. Welches der fsck Tools dann schneller ist, kann ich nicht sagen. In dem Falle ist mir persoenlich die Schnelligkeit auch nicht so wichtig, da bevorzuge ich, nach dem Check zuverlaessig ein konsistentes brauchbares Filesystem zu haben. Th. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Dienstag August 21 2007 schrieb Thomas Hertweck:
Anton Renner wrote:
[...] Ein weiterer Punkt ist, dass nach einem Crash ext3 ein fsck durchführt. Und bei ein paar Hundert GB kann dass schon eine Weile dauern. Schrecke darum ein wenig vom Einsatz von ext3 ab.
Liege ich da falsch?
Ja.
Nach einem Crash wird ext3 keinen vollstaendigen Check des Filesystems durchfuehren, es findet lediglich ein Journal replay statt - das ist ja genau der Sinn eines Journaling Filesystems. Danach ist das Filesystem normalerweise als "clean" markiert und es wird ohne weitere Komplikationen gebootet. Sollte beim Replay etwas schief gehen und/oder es zu einem Fehler kommen, d.h. das Filesystem kann nicht als "clean" markiert werden, dann wird fsck einen vollstaendigen Check des Filesystems vornehmen. Das kann dann natuerlich recht lange dauern. Gleiches kann aber auch bei anderen Journaling Filesystemen wie ReiserFS und XFS passieren, und dann wird dort ebenfalls ein vollstaendiger Check durchgefuehrt. Welches der fsck Tools dann schneller ist, kann ich nicht sagen. In dem Falle ist mir persoenlich die Schnelligkeit auch nicht so wichtig, da bevorzuge ich, nach dem Check zuverlaessig ein konsistentes brauchbares Filesystem zu haben. Nach meinen jahrelangen Erfahrungen ist dabei xfs wesentlich schneller und zuverlässiger als ext2 und ReiserFS. Habe alle schon ausprobiert, auch im mischbetrieb. Viele Grüße, Heinz Dittmar
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
On 8/21/07, Heinz Dittmar <hdttmr@compuserve.de> wrote:
Am Dienstag August 21 2007 schrieb Thomas Hertweck:
Anton Renner wrote:
[...] Ein weiterer Punkt ist, dass nach einem Crash ext3 ein fsck durchführt. Und bei ein paar Hundert GB kann dass schon eine Weile dauern. Schrecke darum ein wenig vom Einsatz von ext3 ab.
Liege ich da falsch?
Ja.
Nach einem Crash wird ext3 keinen vollstaendigen Check des Filesystems durchfuehren, es findet lediglich ein Journal replay statt - das ist ja genau der Sinn eines Journaling Filesystems. Danach ist das Filesystem normalerweise als "clean" markiert und es wird ohne weitere Komplikationen gebootet. Sollte beim Replay etwas schief gehen und/oder es zu einem Fehler kommen, d.h. das Filesystem kann nicht als "clean" markiert werden, dann wird fsck einen vollstaendigen Check des Filesystems vornehmen. Das kann dann natuerlich recht lange dauern. Gleiches kann aber auch bei anderen Journaling Filesystemen wie ReiserFS und XFS passieren, und dann wird dort ebenfalls ein vollstaendiger Check durchgefuehrt. Welches der fsck Tools dann schneller ist, kann ich nicht sagen. In dem Falle ist mir persoenlich die Schnelligkeit auch nicht so wichtig, da bevorzuge ich, nach dem Check zuverlaessig ein konsistentes brauchbares Filesystem zu haben. Nach meinen jahrelangen Erfahrungen ist dabei xfs wesentlich schneller und zuverlässiger als ext2 und ReiserFS. Habe alle schon ausprobiert, auch im mischbetrieb. Viele Grüße, Heinz Dittmar
Kann ich nur bestätigen. Wir haben auch alle Dateisysteme durch. Bei Reiserfs (im Volksmund auch "Reisswolf-FS" genannt ;-) ) hatten wir in regelmässigen Abständen kaputte, unreparierbare Filesysteme, die man nur neu anlegen konnte. Mit Ext3 hatten wir Datenverluste auf den Echtzeit-Systemen, weil es irgendwie in regelmässigen Abständen alle Schreib-Operationen angehalten hat und die Anwendungen nicht genug puffern konnten. Ausserdem hat's nachweislich zu verkürzter Batterie-Laufzeit auf den Laptops geführt. Mit XFS sind wir seit Jahren rundum glücklich, wobei unsere Filesystem-Grössen so zwischen 10 und 200 GB liegen. Den einzigen Vorteil, den ich bei Ext3 sehe, ist, dass es auch die Daten in's Journal packen kann, das kann weder XFS noch Reiserfs. Aber, wenn man so viele Stromausfälle hat, das man das braucht, dann sollte man vielleicht mal über eine UPS nachdenken ;-) . kk
On Wednesday 22 August 2007 02:57, Karsten Künne wrote:
On 8/21/07, Heinz Dittmar <hdttmr@compuserve.de> wrote:
Am Dienstag August 21 2007 schrieb Thomas Hertweck:
Anton Renner wrote:
[...] Ein weiterer Punkt ist, dass nach einem Crash ext3 ein fsck durchführt. Und bei ein paar Hundert GB kann dass schon eine Weile dauern. Schrecke darum ein wenig vom Einsatz von ext3 ab.
Liege ich da falsch?
Ja.
Nach einem Crash wird ext3 keinen vollstaendigen Check des Filesystems durchfuehren, es findet lediglich ein Journal replay statt - das ist ja genau der Sinn eines Journaling Filesystems. Danach ist das Filesystem normalerweise als "clean" markiert und es wird ohne weitere Komplikationen gebootet. Sollte beim Replay etwas schief gehen und/oder es zu einem Fehler kommen, d.h. das Filesystem kann nicht als "clean" markiert werden, dann wird fsck einen vollstaendigen Check des Filesystems vornehmen. Das kann dann natuerlich recht lange dauern. Gleiches kann aber auch bei anderen Journaling Filesystemen wie ReiserFS und XFS passieren, und dann wird dort ebenfalls ein vollstaendiger Check durchgefuehrt. Welches der fsck Tools dann schneller ist, kann ich nicht sagen. In dem Falle ist mir persoenlich die Schnelligkeit auch nicht so wichtig, da bevorzuge ich, nach dem Check zuverlaessig ein konsistentes brauchbares Filesystem zu haben.
Nach meinen jahrelangen Erfahrungen ist dabei xfs wesentlich schneller und zuverlässiger als ext2 und ReiserFS. Habe alle schon ausprobiert, auch im mischbetrieb. Viele Grüße, Heinz Dittmar
Kann ich nur bestätigen. Wir haben auch alle Dateisysteme durch. Bei Reiserfs (im Volksmund auch "Reisswolf-FS" genannt ;-) ) hatten wir in regelmässigen Abständen kaputte, unreparierbare Filesysteme, die man nur neu anlegen konnte.
das entspricht auch meinen Erfahrungen.
Mit Ext3 hatten wir Datenverluste auf den Echtzeit-Systemen, weil es irgendwie in regelmässigen Abständen alle Schreib-Operationen angehalten hat und die Anwendungen nicht genug puffern konnten.
eine sehr interessante Beobachtung, die auch vereinzelte aber selten auftretende Ungereimtheiten erklären würde, die bei mir unter ext3 aufgetreten sind.
Ausserdem hat's nachweislich zu verkürzter Batterie-Laufzeit auf den Laptops geführt. Mit XFS sind wir seit Jahren rundum glücklich, wobei unsere Filesystem-Grössen so zwischen 10 und 200 GB liegen.
Den einzigen Vorteil, den ich bei Ext3 sehe, ist, dass es auch die Daten in's Journal packen kann, das kann weder XFS noch Reiserfs. Aber, wenn man so viele Stromausfälle hat, das man das braucht, dann sollte man vielleicht mal über eine UPS nachdenken ;-) .
kk
-- Regards, Walter Ulmke -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Mittwoch, 22. August 2007 02:57 schrieb Karsten Künne:
(...). Den einzigen Vorteil, den ich bei Ext3 sehe, ist, dass es auch die Daten in's Journal packen kann, das kann weder XFS noch Reiserfs. (...).
Sicher? Die Mount-Option "data=journal" gibt es bei ReiserFS IIRC seit dem Kernel 2.6, also schon seit Ewigkeiten. Gruß Jan -- Age and treachery will always overcome youth and skill. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
On Wednesday 22 August 2007 01:42, Heinz Dittmar wrote:
Am Dienstag August 21 2007 schrieb Thomas Hertweck:
Anton Renner wrote:
[...] Ein weiterer Punkt ist, dass nach einem Crash ext3 ein fsck durchführt. Und bei ein paar Hundert GB kann dass schon eine Weile dauern. Schrecke darum ein wenig vom Einsatz von ext3 ab.
Liege ich da falsch?
Ja.
Nach einem Crash wird ext3 keinen vollstaendigen Check des Filesystems durchfuehren, es findet lediglich ein Journal replay statt - das ist ja genau der Sinn eines Journaling Filesystems. Danach ist das Filesystem normalerweise als "clean" markiert und es wird ohne weitere Komplikationen gebootet. Sollte beim Replay etwas schief gehen und/oder es zu einem Fehler kommen, d.h. das Filesystem kann nicht als "clean" markiert werden, dann wird fsck einen vollstaendigen Check des Filesystems vornehmen. Das kann dann natuerlich recht lange dauern. Gleiches kann aber auch bei anderen Journaling Filesystemen wie ReiserFS und XFS passieren, und dann wird dort ebenfalls ein vollstaendiger Check durchgefuehrt. Welches der fsck Tools dann schneller ist, kann ich nicht sagen. In dem Falle ist mir persoenlich die Schnelligkeit auch nicht so wichtig, da bevorzuge ich, nach dem Check zuverlaessig ein konsistentes brauchbares Filesystem zu haben.
Nach meinen jahrelangen Erfahrungen ist dabei xfs wesentlich schneller und zuverlässiger als ext2 und ReiserFS. Habe alle schon ausprobiert, auch im mischbetrieb. Viele Grüße, Heinz Dittmar
Hallo Heinz, läuft deine root partitiom und ggf. boot partition auch unter XFS, oder läßt Du die mit ext3 laufen? Wie sieht es aus nach einem Absturz? Erkennt das recovery system XFS und werden die entsprechenden Treiber geladen? -- Regards, Walter Ulmke -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Walter Ulmke wrote:
[...] läuft deine root partitiom und ggf. boot partition auch unter XFS, oder läßt Du die mit ext3 laufen? Wie sieht es aus nach einem Absturz? Erkennt das recovery system XFS und werden die entsprechenden Treiber geladen?
XFS ist Teil des Vanilla-Kernels, genau wie ext3. In der Hinsicht verhaelt es sich nicht anders, und natuerlich funktioniert ein Replay des Journals und falls noetig ein fsck beim Booten. Cheers, Thomas -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo! Am 21.08.2007 um 19:20 Uhr schrieb Thomas Hertweck:
[...] In dem Falle ist mir persoenlich die Schnelligkeit auch nicht so wichtig, da bevorzuge ich, nach dem Check zuverlaessig ein konsistentes brauchbares Filesystem zu haben. Gibt es darüber Vergleichswerte oder Erfahrunungsberichte (ev. eigene Erfahrungen)?
cu Peter -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Peter Geerds wrote:
Am 21.08.2007 um 19:20 Uhr schrieb Thomas Hertweck:
[...] In dem Falle ist mir persoenlich die Schnelligkeit auch nicht so wichtig, da bevorzuge ich, nach dem Check zuverlaessig ein konsistentes brauchbares Filesystem zu haben.
Gibt es darüber Vergleichswerte oder Erfahrunungsberichte (ev. eigene Erfahrungen)?
Meiner Meinung nach sind die Filesystem-Tools von XFS wirklich sehr gut, schau Dir fuer einen Ueberblick einfach mal die Programme xfs_* an. Bisher habe ich nur ein einziges Mal erlebt, dass ein XFS Filesystem nicht wiederhergestellt werden konnte - das lag daran, dass der primaere Superblock beschaedigt war und kein einziger sekundaerer Superblock validiert werden konnte. Ich nutze XFS schon sehr lange, frueher auf unseren SGI Servern, heute eben auch unter Linux, teilweise mit recht grossen Filesystemen. Mit ReiserFS habe ich selbst schlechte Erfahrungen gemacht, die liegen allerdings schon recht lange zurueck (als ReiserFS in SuSE Distros eingefuehrt und dann zum Standard-Filesystem wurde). Nun, wenn man sich mehrmals die Finger verbrannt hat, dann zieht man daraus doch die Konsequenzen, und so wurde ReiserFS von all meinen Systemen verbannt. Daher habe ich keine aktuellen Erfahrungen mit reiserfsck. Andere setzen ReiserFS zufrieden ein, insofern moechte ich mir kein generelles Urteil ueber dieses Filesystem erlauben. Neben XFS nutze ich ext3 z.B. auf Dual-Boot Desktop Systemen, eigentlich mit recht guten Erfahrungen, bisher konnte das Filesystem bei selten notwendigen fsck ohne Probleme wiederhergestellt werden. Ext3 hat den Vorteil, dass man die Filesysteme z.B. auch von Windows aus lesen kann. Cheers, Thomas -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
On Wednesday 22 August 2007 20:57, Thomas Hertweck wrote: <schnipp>
Neben XFS nutze ich ext3 z.B. auf Dual-Boot Desktop Systemen, eigentlich mit recht guten Erfahrungen, bisher konnte das Filesystem bei selten notwendigen fsck ohne Probleme wiederhergestellt werden. Ext3 hat den Vorteil, dass man die Filesysteme z.B. auch von Windows aus lesen kann.
Cheers, Thomas
ich will mein Laptop jetzt mal auf XFS umstellen. Funzt folgende Vorgehensweise? 1) alle mit cpio aif USB-Tape sichern. 2) ein neues Rumpfsystem installieren, dabei alle Partitionen als XFS neu formatieren. 3) init 1 4) mit cpio vom Band alle Dateien rücksichern, dabei einfach alles überbügeln. Ditto für die anderen Partitionen 5) 'runter und hochfahren, fertig. Wie lautet der passende cpio -o Befehl, um alles, z.B. auch die symbolic links zu sichern? Wie lautet der passende cpio -i Befehl, um ALLES einschl. der symbolic links rückzusichern? -- Regards, Walter Ulmke -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Walter Ulmke, Freitag, 24. August 2007 01:32:
1) alle mit cpio aif USB-Tape sichern.
Weiß ich nicht, ich nehm immer tar. Such gegebenenfalls nach "Linux umkopieren" auf der Opensuse-Seite.
2) ein neues Rumpfsystem installieren, dabei alle Partitionen als XFS neu formatieren.
Nicht nötig. Einfach vom Rettungssystem oder der Knoppix aus ein mkfs.xfs /dev/irgendwas machen, auf alle Deine Partitionen halt.
4) mit cpio vom Band alle Dateien rücksichern, dabei einfach alles überbügeln. Ditto für die anderen Partitionen
Jep. Anschließend noch die fstab anpassen, sonst wirds nix mit booten. Jetzt fällt mir aber noch was ein: kann eine SuSE, die zB auf ein ext3 installiert wurde, später von xfs starten? Fehlt da nicht evtl. das entsprechende Kernelmodul? Was ist mit der initrd? Da müßte wer anders was dazu sagen. Schlimmstenfalls kannst Du ja Dein System wiederherstellen, indem Du die Partitionen wieder als ext3 formatierst, und die Daten dann nochmal zurückspielst. Du solltest vielleicht auch dafür sorgen, daß Du die ganzen xfs-Tools installierst, bevor Du mit dem umkopieren anfängst, dann hast Du später schon alles bereit. -- Andre Tann -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
On 8/24/07, Andre Tann <atann@gmx.net> wrote:
Walter Ulmke, Freitag, 24. August 2007 01:32:
1) alle mit cpio aif USB-Tape sichern.
Weiß ich nicht, ich nehm immer tar. Such gegebenenfalls nach "Linux umkopieren" auf der Opensuse-Seite.
2) ein neues Rumpfsystem installieren, dabei alle Partitionen als XFS neu formatieren.
Nicht nötig. Einfach vom Rettungssystem oder der Knoppix aus ein mkfs.xfs /dev/irgendwas machen, auf alle Deine Partitionen halt.
4) mit cpio vom Band alle Dateien rücksichern, dabei einfach alles überbügeln. Ditto für die anderen Partitionen
Jep.
Anschließend noch die fstab anpassen, sonst wirds nix mit booten.
Jetzt fällt mir aber noch was ein: kann eine SuSE, die zB auf ein ext3 installiert wurde, später von xfs starten? Fehlt da nicht evtl. das entsprechende Kernelmodul? Was ist mit der initrd? Da müßte wer anders was dazu sagen. Schlimmstenfalls kannst Du ja Dein System wiederherstellen, indem Du die Partitionen wieder als ext3 formatierst, und die Daten dann nochmal zurückspielst.
Wenn die Root-Partition XFS ist, dann muss XFS in der initrd sein. also in /etc/sysconfig/kernel "xfs" zu den INITRD_MODULES hinzufügen, wenn's noch nicht dabei ist und anschliessend "mkinitrd" ausführen.
Du solltest vielleicht auch dafür sorgen, daß Du die ganzen xfs-Tools installierst, bevor Du mit dem umkopieren anfängst, dann hast Du später schon alles bereit.
Die xfsprogs sind auf jeden Fall nützlich und xfsdump benutze ich immer gerne zum schnellen Kopieren ganzer XFS-Dateisysteme. kk
Hallo Thomson, Am Mit, 22 Aug 2007, Thomas Hertweck schrieb:
Meiner Meinung nach sind die Filesystem-Tools von XFS wirklich sehr gut, schau Dir fuer einen Ueberblick einfach mal die Programme xfs_* an. Bisher habe ich nur ein einziges Mal erlebt, dass ein XFS Filesystem nicht wiederhergestellt werden konnte
Und was ist mit den Daten? Thema: http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-07/2496.html Die WP[1] nennt das Problem auch: "Eine an einen Fehlerfall anschließende Überprüfung des Dateisystems wird jedoch zumindest eine Konsistenz wiederherstellen und Datenbereiche, die nicht geschrieben werden konnten, durch Nullen auffüllen. Dadurch sind mögliche Fehler durch "Datenreste" ausgeschlossen." und "Wegen des verzögerten Schreibens von Daten sind Datenverluste bei aktuell geöffneten Dateien bei einem Systemabsturz (z. B. Stromausfall) möglicherweise größer als bei anderen Dateisystemen (siehe Abschnitt Verzögerte Allokation)." Irgendwo hab ich das auch mal bei ner seriöseren Quelle gelesen, die mir aber gerade nicht einfällt und die ich auch grad nicht finde. Das Dateisystem wird wohl immer konsistent sein, aber ich lege nicht nur Wert auf die Dateisystemintegrität, sondern auch (und sogar mehr) Wert auf die Datenintegrität. Und ein e2fsck hat bei mir die Dateisysteme bisher auch immer wieder konsistent hinbekommen. Bei ext2/ext3 hatte ich bisher noch nie Probleme, trotz teilweise (meist Hardware-bedingter) übler Crashes (einmal tat nichtmal mehr der Reset-Knopf)... Für Desktop-Systeme ohne auf Stabilität und Ausfallsicherheit optimierte Hardware (und ne UPS) ist IMO ext3 das geeignetere Dateisystem, ggfs. kann man ja 'dir_index' aktivieren. Mir ist ext3 auch ohne dir_index schnell genug. Ich muß aber zugeben, daß ich bisher keine eigenen Erfahrungen mit XFS habe. Hm. Mal sehen, ob ich das mal testen kann[2]... Kann sein, daß ich die Tage mal ne Partition freiräumen kann... -dnh, ~3 TB ext3 in 2 Rechnern ;) [1] http://de.wikipedia.org/wiki/XFS_%28Dateisystem%29 http://en.wikipedia.org/wiki/XFS [2] Testszenario: Verhalten des FS (auch bzgl. der Daten!) wenn während Schreiboperationen: - der schreibende Prozess (per SIGINT, SIGHUP o.ä.) unterbrochen wird - der schreibende Prozess (per SIGKILL) gekillt wird - SysRq + s + s + u + b (mit Pause nach +s) - SysRq + s + u + b (ohne Pause nach +s) - SysRq + b - Resetknopf - Ausschalter Gefordert: Datenintegrität. Der zuletzt erfolgreich geschriebene Zustand der Daten sollte erhalten bleiben -- und nicht, wie es IIRC bei XFS der Fall sein kann, auf einmal ausgenullt sein. -- "The idea that Bill Gates has appeared like a knight in shining armour to lead all customers out of a mire of technological chaos neatly ignores the fact that it was he who, by peddling second-rate technology, led them into it in the first place." -- Douglas Adams in Guardian, 25-Aug-95 -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am 24.08.07 schrieb David Haller <lists@dhaller.de>:
Das Dateisystem wird wohl immer konsistent sein, aber ich lege nicht nur Wert auf die Dateisystemintegrität, sondern auch (und sogar mehr) Wert auf die Datenintegrität. Und ein e2fsck hat bei mir die Dateisysteme bisher auch immer wieder konsistent hinbekommen.
http://oss.sgi.com/projects/xfs/faq.html#nulls http://oss.sgi.com/projects/xfs/faq.html#wcache_fix Welchen Kernel hat 10.3? :-) Wenn Dir Datenintegrität wirklich wichtig ist, möchtest Du aber ZFS. Achja: Daß e2fsck immer alles restauriert, halte ich für ein Gerücht; /lost+found existiert nicht ohne Grund. Gruß Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, Am Fre, 24 Aug 2007, Martin Schröder schrieb:
Am 24.08.07 schrieb David Haller <lists@dhaller.de>:
Das Dateisystem wird wohl immer konsistent sein, aber ich lege nicht nur Wert auf die Dateisystemintegrität, sondern auch (und sogar mehr) Wert auf die Datenintegrität. Und ein e2fsck hat bei mir die Dateisysteme bisher auch immer wieder konsistent hinbekommen.
http://oss.sgi.com/projects/xfs/faq.html#nulls http://oss.sgi.com/projects/xfs/faq.html#wcache_fix
Ah.
Welchen Kernel hat 10.3? :-)
Wenn Dir Datenintegrität wirklich wichtig ist, möchtest Du aber ZFS.
Muß ich mir mal angucken ;)
Achja: Daß e2fsck immer alles restauriert, halte ich für ein Gerücht;
Das hat auch niemand behauptet. _MIR_ hat e2fsck immer ein konsistentes Dateisystem hinterlassen...
/lost+found existiert nicht ohne Grund.
... was ja auch der Fall ist, wenn Dateien in lost+found landen. Und ich hatte IIRC erst einmal was in lost+found, und das war IIRC mein Fehler (hab mit debugfs rumgespielt ;) Bei den ganzen HW-bedingten fiesen Abstürzen in den letzten Jahren gab's hier nie ein Problem -- weder bei den Daten noch den Metadaten. -dnh -- Such an archaic device, the letter -- but personal in a way no recording could achieve. -- from "Dune Messiah" by Frank Herbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
David Haller wrote:
[...]
Das Dateisystem wird wohl immer konsistent sein, aber ich lege nicht nur Wert auf die Dateisystemintegrität, sondern auch (und sogar mehr) Wert auf die Datenintegrität. Und ein e2fsck hat bei mir die Dateisysteme bisher auch immer wieder konsistent hinbekommen.
Auch ext3 garantiert Dir in den Standardeinstellungen erst einmal nur ein konsistentes Filesystem, nicht konsistente Dateien. Ein fsck wird Dir eben komplette Dateien aus dem Filesystem entfernen und Du findest dann Fragmente in lost+found wieder. Ob das nun besser ist, ist sicher Ansichtssache.
Bei ext2/ext3 hatte ich bisher noch nie Probleme, trotz teilweise (meist Hardware-bedingter) übler Crashes (einmal tat nichtmal mehr der Reset-Knopf)...
Nun, ich hatte zu Hause auch mit xfs keine Probleme, selbst ohne Notstromversorgung. Im Buero haben wir natuerlich entsprechende Vorkehrungen, die zumindest ein geregeltes Herunterfahren der Server erlauben, sollte der Strom gekappt werden. Ich selbst habe auch mit ext2/3 schon so einige Dinge erlebt: wenn Du nach einem fsck ungefaehr die Haelfte aller Dateien in lost+found wiederfindest, dann hilft eben nur noch das Backup. Zum Glueck gibt es ja die Auswahl an Filesystemen, so kann eben jeder selbst entscheiden. Ich persoenlich bin mit einer Mischung aus ext3 und xfs bisher sehr gut gefahren... Cheers, Thomson -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, Am Die, 21 Aug 2007, Anton Renner schrieb:
Ein weiterer Punkt ist, dass nach einem Crash ext3 ein fsck durchführt. Und bei ein paar Hundert GB kann dass schon eine Weile dauern. Schrecke darum ein wenig vom Einsatz von ext3 ab.
Liege ich da falsch?
Ja. Damit ein journal-replay länger als 1s dauert muß vor dem Absturz _einiges_ losgewesen sein... Und noch was, was bisher nicht erwähnt wurde: man kann bei ext3 z.B. das "dir_index" Feature aktivieren, allerdings auf Kosten der Rückwärtskompatibilität zu ext2, und damit sollte ext3 dann auch bei vielen Dateien (>10000) in einem Verzeichnis deutlich schneller sein. -dnh -- Warning: Some of my best mistakes are yet to be made. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Bernd, Lentes, Bernd schrieb:
Ich habe daraus entnommen (und auch aus anderer Recherche), daß erheblich mehr Leute Probleme mit reiserfs als mit ext3 hatten.
Hmmm... Ich habe mich zunächst für reiserFS entschieden und OS installiert. Tja, ich hatte auch mal einen crash unter reiserFS, kann aber nicht genau sagen, warum das Ganze gecrasht ist. Wenn ich nun höre, dass mehr Probleme bei reiserFS auftraten, bekomme ich langsam Bauchschmerzen und überlege nochmal zu installieren und Ext3 einzusetzen. Naja, da muss ich wohl noch eine Nacht drüber schlafen... Schöne Grüße Mathias -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Dienstag, 21. August 2007 22:22 schrieb Mathias Klose:
(...). Wenn ich nun höre, dass mehr Probleme bei reiserFS auftraten, bekomme ich langsam Bauchschmerzen und überlege nochmal zu installieren und Ext3 einzusetzen. (...).
Laß dich nicht zu sehr verunsichern. Ich habe ReiserFS eingesetzt seitdem SUSE es halt per default angeboten hat, sprich seit einigen Jahren. Selbst mehr als eine sterbende IBM Deathstar konnten meinen ReiserFS-Installationen nichts anhaben. Gruß Jan -- Reputation is character minus what you've been caught doing. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Mathias, Am Dienstag, 21. August 2007 22:22 schrieb Mathias Klose:
Lentes, Bernd schrieb:
Ich habe daraus entnommen (und auch aus anderer Recherche), daß erheblich mehr Leute Probleme mit reiserfs als mit ext3 hatten.
Hmmm... Ich habe mich zunächst für reiserFS entschieden und OS installiert. Tja, ich hatte auch mal einen crash unter reiserFS, kann aber nicht genau sagen, warum das Ganze gecrasht ist.
das Problem bei Crashes und Filesystemdefekten ist mitunter, dass man vielleicht am Anfang gar nicht mitkriegt, dass ein File defekt ist sondern erst sehr viel später, wenn man mal versucht eine alte Datei zu öffnen und feststellt, dass diese sich auf einmal weigert weil sie eben irgendwann mal einen Treffer abgekriegt hat.
Wenn ich nun höre, dass mehr Probleme bei reiserFS auftraten, bekomme ich langsam Bauchschmerzen und überlege nochmal zu installieren und Ext3 einzusetzen.
Wieso neu installieren? Besorg Dir einfach eine Platte/ Partition wo genügend Platz drauf ist, boote irgendein Linux von CD und dann kopierst Du mit cp, tar, cpio, afio, ... (irgendeinem Tool Deiner Wahl) Du erst das alte System da hin, machst die Platte platt, formatierst mit ext3 neu und spielst Dein System dann wieder zurück. Da sparst Du Dir die Neuinstallation und lernst noch was dazu :-) (und irgendwie passt sogar die E-Mail der Signatur a bisserl zu dem Vorhaben... und das wirklich rein zufällig) Grüße Philipp -- Alle Reisen haben eine heimliche Bestimmung, die der Reisende nicht ahnt. -- Martin Buber ###signature by fortune### -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallöle, Am Mittwoch, 22. August 2007 01:00 schrieb Philipp Zacharias: [...]
Wieso neu installieren? Besorg Dir einfach eine Platte/ Partition wo genügend Platz drauf ist, boote irgendein Linux von CD und dann kopierst Du mit cp, tar, cpio, afio, ... (irgendeinem Tool Deiner Wahl) Du erst das alte System da hin, machst die Platte platt, formatierst mit ext3 neu und spielst Dein System dann wieder zurück. Da sparst Du Dir die Neuinstallation und lernst noch was dazu :-) (und irgendwie passt sogar die E-Mail der Signatur a bisserl zu dem Vorhaben... und das wirklich rein zufällig)
Grüße Philipp
Siehe hier [1]. Das ganze machst Du hin und wieder zurück - und vergiss nicht vor dem rebooten die /etc/fstab zu ändern. So einfach ist das... :) Wär mir viel zu aufwändig, alles neu zu konfigurieren. [...] Gruss Mario -- [1] http://de.opensuse.org/SDB:SuSE_Linux_umkopieren -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Dienstag, den 21.08.2007, 22:22 +0200 schrieb Mathias Klose: ....
Wenn ich nun höre, dass mehr Probleme bei reiserFS auftraten, bekomme ich langsam Bauchschmerzen und überlege nochmal zu installieren und Ext3 einzusetzen.
Naja, da muss ich wohl noch eine Nacht drüber schlafen...
Schöne Grüße Mathias
Hallo Mathias und Liste, ich verwende zur Zeit ReiserFs3 auf einem Notebook und Ext3 auf einem Desktopsystem, das ging bisher ganz gut. ReiserFs3 hat aber mit dem Kernellocking arge Probleme, d.h. ich hatte mal zwei Festplatten mit Reiser formatiert und dann beide gemountet und zwischen diesen mehrere GB kopiert. Das war eine echte Katastrophe, was die Performance betrifft. Ich habe auf dem System alles auf Ext3 geändert und seitdem ist das um mind. Faktor 3 schneller. Wenn man nur eine Partition hat, dann fällt das nicht auf, das Journal-Replay war unter Reiser immer schneller. XFS habe ich vor ein paar Jahren ausprobiert und bin in die Falle mit dem aggressiven Write-Caching gefallen. Wenn XFS beim Journal-Replay eine Datei findet, die nicht als vollständig geschrieben markiert ist, dann wird sie mit Null-Bytes aufgefüllt. Das ist aus Datenkonsistenzgründen auch sinnvoll. Ich hatte damals aber gerade große Dateien kopiert und nebenher an Konfigurationsdateien gebastelt, als die Maschine abschmierte. Ich konnte dann nicht mehr booten, weil XFS die kleineren Dateien noch im Cache hatte, aber schon als beschrieben markiert. Da haben dann etliche Konfigurationsdateien nur Null-Bytes enthalten ;-). Die alten nicht geänderten wären mir lieber gewesen. Ob sich da was gebessert hat, kann ich mangels Erfahrung nicht sagen. Gruß, Detlef -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Mittwoch, 22. August 2007 21:42 schrieb Detlef Grittner:
(...).
ReiserFs3 hat aber mit dem Kernellocking arge Probleme, d.h. ich hatte mal zwei Festplatten mit Reiser formatiert und dann beide gemountet und zwischen diesen mehrere GB kopiert. Das war eine echte Katastrophe, was die Performance betrifft. (...).
Seitdem SUSE per default ReiserFS eingesetzt hat, habe ich bei so gut jedem Update eine neue Platte gekauft und somit die alten Nutzdaten von ReiserFS auf ReiserFS kopiert. Von einer Performance-Katastrophe habe ich da nie etwas bemerkt. Was für Transferraten hast du denn da so erlebt? Vielleicht bin ich auch nur etwas genügsamer. :) Gruß Jan -- Boycott Jane Fonda. (everyone hates Jane Fonda, don't they?) -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Mittwoch, den 22.08.2007, 22:10 +0200 schrieb Jan Ritzerfeld:
Seitdem SUSE per default ReiserFS eingesetzt hat, habe ich bei so gut jedem Update eine neue Platte gekauft und somit die alten Nutzdaten von ReiserFS auf ReiserFS kopiert. Von einer Performance-Katastrophe habe ich da nie etwas bemerkt. Was für Transferraten hast du denn da so erlebt? Vielleicht bin ich auch nur etwas genügsamer. :)
.... Hallo Jan, ich habe die genauen Perfomancedaten nicht mehr im Kopf, es waren aber etwa 20 min für eine 20GB große Datei, ergibt ungefähr 17 MB/s. Mit Ext3 kann ich die Daten in etwa 14 min kopieren, das sind ungefähr 24 MB/s. Es sind in diesem Fall zwei verschiedene Festplatten, jeweils mit eigenem Dateisystem und auf unterschiedliche Pfade gemountet. Ich bin darauf aufmerksam geworden, als ich mal zwischen Ext3 und Reiser kopiert habe, das geht nämlich auch in der schnellen Variante. Detlef -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Samstag, 25. August 2007 17:58 schrieb Detlef Grittner:
Am Mittwoch, den 22.08.2007, 22:10 +0200 schrieb Jan Ritzerfeld:
Seitdem SUSE per default ReiserFS eingesetzt hat, habe ich bei so gut jedem Update eine neue Platte gekauft und somit die alten Nutzdaten von ReiserFS auf ReiserFS kopiert. Von einer Performance-Katastrophe habe ich da nie etwas bemerkt. Was für Transferraten hast du denn da so erlebt? Vielleicht bin ich auch nur etwas genügsamer. :) (...). ich habe die genauen Perfomancedaten nicht mehr im Kopf, es waren aber etwa 20 min für eine 20GB große Datei, ergibt ungefähr 17 MB/s. Mit Ext3 kann ich die Daten in etwa 14 min kopieren, das sind ungefähr 24 MB/s. (...).
Okay. Du schriebst was von "mind. Faktor 3" schneller. Eine derartige langsame Übertragung von ReiserFS zu ReiserFS wäre mir bestimmt aufgefallen. Und 24 MB/s statt 17 MB/s ist von "mind. Faktor 3" nunmal meilenweit entfernt. Gruß Jan -- He who has a shady past knows that nice guys finish last. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Samstag, den 25.08.2007, 23:00 +0200 schrieb Jan Ritzerfeld: ....
Okay. Du schriebst was von "mind. Faktor 3" schneller. Eine derartige langsame Übertragung von ReiserFS zu ReiserFS wäre mir bestimmt aufgefallen. Und 24 MB/s statt 17 MB/s ist von "mind. Faktor 3" nunmal meilenweit entfernt.
.... Da hast Du recht, das ist ja wohl höchstens mind. Faktor 1/3. Detlef -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
On 8/22/07, Detlef Grittner <detlef.grittner@t-online.de> wrote:
Am Dienstag, den 21.08.2007, 22:22 +0200 schrieb Mathias Klose: ....
Wenn ich nun höre, dass mehr Probleme bei reiserFS auftraten, bekomme ich langsam Bauchschmerzen und überlege nochmal zu installieren und Ext3 einzusetzen.
Naja, da muss ich wohl noch eine Nacht drüber schlafen...
Schöne Grüße Mathias
Hallo Mathias und Liste,
ich verwende zur Zeit ReiserFs3 auf einem Notebook und Ext3 auf einem Desktopsystem, das ging bisher ganz gut.
ReiserFs3 hat aber mit dem Kernellocking arge Probleme, d.h. ich hatte mal zwei Festplatten mit Reiser formatiert und dann beide gemountet und zwischen diesen mehrere GB kopiert. Das war eine echte Katastrophe, was die Performance betrifft. Ich habe auf dem System alles auf Ext3 geändert und seitdem ist das um mind. Faktor 3 schneller. Wenn man nur eine Partition hat, dann fällt das nicht auf, das Journal-Replay war unter Reiser immer schneller.
XFS habe ich vor ein paar Jahren ausprobiert und bin in die Falle mit dem aggressiven Write-Caching gefallen. Wenn XFS beim Journal-Replay eine Datei findet, die nicht als vollständig geschrieben markiert ist, dann wird sie mit Null-Bytes aufgefüllt. Das ist aus Datenkonsistenzgründen auch sinnvoll. Ich hatte damals aber gerade große Dateien kopiert und nebenher an Konfigurationsdateien gebastelt, als die Maschine abschmierte. Ich konnte dann nicht mehr booten, weil XFS die kleineren Dateien noch im Cache hatte, aber schon als beschrieben markiert. Da haben dann etliche Konfigurationsdateien nur Null-Bytes enthalten ;-). Die alten nicht geänderten wären mir lieber gewesen. Ob sich da was gebessert hat, kann ich mangels Erfahrung nicht sagen.
Dieses Problem lässt sich nur mit Data-Journaling vermeiden, was XFS (so wie auch ReiserFS und Ext3 in der Standard-Einstellung) nicht macht. Aber das ganze Dateien mit Nullen aufgefüllt werden, stimmt nicht, es werden nur die halbgeschriebenen Blöcke genullt, weil da ja schon zur neuen Datei gehören, aber noch alte, eventuell vertrauliche, Daten enthalten könnten. Bei mir war das bis jetzt noch nie ein Problem, aber wenn man eine instabile Kiste oder schlechte Stromversorgung hat, dann könnte das schon zum Problem werden, dass gebe ich zu. In dem Fall bleibt dann nur noch ein Filesystem mit Full-Data-Journaling, womit natürlich dann die Performance den Bach runter geht. Ich setze XFS auch schon seit den Anfängen auf SGI IRIX ein und hatte noch kein Filesystem, was einfach so (ohne kaputte Platten oder Controller) kaputt gegangen ist. Bei ReiserFS dagegen kam das ziemlich häufig vor und deshalb kommt mir das auch auf keines meiner Systeme mehr. Ext3 verwende ich zu Hause bei Filesystemen, die ich mit Windows teilen will, weil's dafür einen Windows-Treiber gibt. kk Rgbx������ץ���r���҉碝��V������ uﮞ˛���m�)z{.��+�I��w���^jY^���~�m�ޜ�&��ݢ��m�(�g���brG�J'��w�j)Z��^�ˬy��i����� ��
participants (23)
-
Andre Tann -
Anton Renner -
David Haller -
Detlef Grittner -
Heinz Dittmar -
Jan Ritzerfeld -
Karsten Künne -
Lentes, Bernd -
Manfred Tremmel -
Mario van der Linde -
Markus Wunder -
Martin Ereth -
Martin Schröder -
Mathias Klose -
Michael Raab -
Michael Skiba -
Peter Geerds -
Philipp Thomas -
Philipp Zacharias -
Roman Fietze -
Thomas Hertweck -
Thomas Michalka -
Walter Ulmke