Re: Mögliche Fallstricke RAID und XFS auf dem Weg zu Etch!?
Hi Philipp, Am Dienstag, den 10.10.2006, 13:55 +0200 schrieb Philipp Frik: > Ehm welche Sterbeprobleme sind des denn bei XFS? Hier an der Uni haben > wir in letzter Zeit immer wieder Probleme die wir nicht wirlich > lokalisieren konnten (immer bei nem XFS) > zudem hab ich daheim bei alle Kisten auch XFS gewaehlt somit wuerde mich > bissal input zu dem Sterbeproblem interresieren. Kann mir jemand was > dazu erzaehlen bzw. hat jemand links wo mehr darueber steht? 2.6.17.?? hatte einen äusserst unangenehmen XFS Bug welcher unweigerlich zu data corruption + data loss führte wenn er zu spät erkannt wurde. Abhilfe schaffte nur eiligst veröffentlichte neue Versionen von xfs_repair & friends. Ältere Versionen hatten das Problem nur verschlimmert Alle Kernel ab 2.6.18 sind zu 100% nicht von dem Bug betroffen, genauso wie der neuste 2.6.17.?? Kernel. -- Matthias 'CoreDump' Hentges My OS: Debian SID. Geek by Nature, Linux by Choice signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Mögliche Fallstricke RAID und XFS auf dem Weg zu Etch!?
Dirk Salva schrieb: >Hi Leute, > > Moin Moin [...] > >Auf den Rechnern wird momentan fast überall Grub, Kernel 2.6 und XFS >als Dateisystem eingesetzt. Ausserdem auf dem Server ein Soft-RAID-1. > > > [...] >ad2) ist beim aktuellen Etch-2.6er-Kernel das XFS-Sterbeproblem >tatsächlich zu 100% behoben? Sprich: kann ich meine XFS-Partitionen >(auf den meisten Rechnern läuft XFS klaglos, nur noch ein Rechner hat >ext3) sicher so weiternutzen, wie das jetzt passiert, oder muss ich >Angst um die Integrität haben? > > > > Ehm welche Sterbeprobleme sind des denn bei XFS? Hier an der Uni haben wir in letzter Zeit immer wieder Probleme die wir nicht wirlich lokalisieren konnten (immer bei nem XFS) zudem hab ich daheim bei alle Kisten auch XFS gewaehlt somit wuerde mich bissal input zu dem Sterbeproblem interresieren. Kann mir jemand was dazu erzaehlen bzw. hat jemand links wo mehr darueber steht? >ciao, Dirk > > Gruss Philipp signature.asc Description: OpenPGP digital signature
Re: XFS-root auf LVM und Grub
Andreas Pakulat schrieb: On 24.08.06 21:24:10, Paul Muster wrote: Wie kann ich Grub installieren, damit es mir das System bootet? Eine "normale" Partition kann ich ihm als Installationsort nicht nennen, Dann hast du ein Problem. Nachtblindheit. 5 Minuten Google(grub boot from lvm volume) brachten die Erkenntnis das Grub ganz einfach LVM nicht versteht und deswegen auch die /boot Partition nicht im LVM liegen darf. Ja. :-( Aber es besteht Hoffnung (leider nur für Grub 2): http://lists.gnu.org/archive/html/grub-devel/2006-08/msg00024.html . Bei Grub 1 (also 0.9x) scheint sich diesbzgl. nicht mehr viel zu tun. Kurz: Repartitioniere dein System. Bei LVM2 kann man IIRC ein PV kleiner machen, und du koenntest danach die Partition mit fdisk loeschen und neu anlegen (kleiner natuerlich) um den erforderlichen Platz zu erhalten. Habs aber noch nie selbst gemacht. Ja, danke für die Hinweise. Ist nur ein Testsystem, wäre also kein Problem, es plattzumachen. Ich wollte halt ausprobieren, wie ich meinen Server umgestalte. Danke & viele Grüße Paul -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
XFS-root auf LVM und Grub
Hallo, ich habe auf /dev/hda nur eine Partition, ein LVM phys. Volume. Darin sind mehrere XFS-Partitionen, u.a. auch "/". LILO bootet das problemlos. Nun möchte ich auf dem Rechner Xen einrichten, was sich - soweit ich verstanden habe - nur von Grub booten lässt. Wie kann ich Grub installieren, damit es mir das System bootet? Eine "normale" Partition kann ich ihm als Installationsort nicht nennen, "grub-install /dev/volg1/root" quittiert er mit "... does not have a corresponding BIOS drive." "grub-install /dev/hd0" bringt "...: Not found or not a block device". Das System ist aktuell reines Sarge, also Grub 0.95. Brauche ich Grub 0.97 von Backports.org? Mir fehlt momentan etwas der Überblick... Danke & viele Grüße Paul -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: XFS-root auf LVM und Grub
On 24.08.06 21:24:10, Paul Muster wrote: > ich habe auf /dev/hda nur eine Partition, ein LVM phys. Volume. Darin sind > mehrere XFS-Partitionen, u.a. auch "/". LILO bootet das problemlos. > > Nun möchte ich auf dem Rechner Xen einrichten, was sich - soweit ich > verstanden habe - nur von Grub booten lässt. > > Wie kann ich Grub installieren, damit es mir das System bootet? Eine > "normale" > Partition kann ich ihm als Installationsort nicht nennen, Dann hast du ein Problem. 5 Minuten Google(grub boot from lvm volume) brachten die Erkenntnis das Grub ganz einfach LVM nicht versteht und deswegen auch die /boot Partition nicht im LVM liegen darf. Kurz: Repartitioniere dein System. Bei LVM2 kann man IIRC ein PV kleiner machen, und du koenntest danach die Partition mit fdisk loeschen und neu anlegen (kleiner natuerlich) um den erforderlichen Platz zu erhalten. Habs aber noch nie selbst gemacht. Andreas -- You are not dead yet. But watch for further reports. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Datensicherheit von XFS erhöhen?
ÖFrom: Michelle Konzack <[EMAIL PROTECTED]> X-Message-Flag: Improper configuration of Outlook is a breeding ground for viruses. Please take care your Client is configured correctly. Greetings Michelle. X-Disclaimer-DE: Eine weitere Verwendung oder die Veroeffentlichung dieser Mail oder dieser Mailadresse ist nur mit der Einwilligung des Autors gestattet. Organisation: Michelle's Selbstgebrautes X-Operating-System: Linux michelle1.private 2.4.27-2-386 X-Uptime: 03:45:03 up 13 days, 7:31, 9 users, load average: 0.05, 0.13, 0.11 X-Homepage: http://www.debian.tamay-dogan.homelinux.net/ X-Mutt-References: <[EMAIL PROTECTED]> Date: Fri, 26 May 2006 03:54:14 +0200 Message-ID: <[EMAIL PROTECTED]> Am 2006-05-23 11:45:16, schrieb Jan Kesten: > Ich weiss auch, dass ext3 auch data=journal anbietet, was sowohl > Metadaten als auch Dateidaten ins Journal schreibt - das war bisher das > stabilste Szenario, aber leider grauenhaft langsam, weil ja alles > doppelt geschrieben werden muss - keine Option. Ich habe das durch schw... teure Hardware ausgeglichen. U320 und raid-5, was sich halt nicht jeder leisten kann. Jetzt muß ich aufrüsten und mir fehlt das Geld für 8 neue 300er. (denke, du weist was so ne platte kostet) > Sicher, und man kann ja auch bei xfs dafür sorgen. Problematisch wird > das Thema eh nur, wenn Schreibzugriffe stattfinden, die die Größe von > Dateien verändern. Wird nur gelesen ist das alles halb so, da ändert > sich ja nichts. Aber hat man denn keine UPS in DE? > >Aber da selbst mit ext3 der fsck ein paar Stunden dauerte (1,8 TByte > >auf 3Ware Raid-5), habe ich es vorgezogen endlich ne neue APC mit > >zwei externen Akku-Blocks zu besorgen... ist einfach nervenschonender. > > Oder einfach den optionalen Akku-Pack für den 3ware Controller, der den > Cache sichert für genau diesen Fall ;-) Sofern man einen 'guten'(TM) > 3ware Controller hat. Meine 8xxx können es, die 6507 und 7507 allerdings nicht ;-( Auch wenns nicht so ne teure UPS für ein Netzwerk ist, aber so ne kleine poplige 800er kostet gerade mal 70 € und erspart einem jede menge nerven. > Cheers, > Jan Greetings Michelle Konzack -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Datensicherheit von XFS erhöhen?
Elias Oltmanns wrote: Das erstaunt mich allerdings sehr. Die Dokumentation zu ext3 und xfs im kernel-Archiv verstehe ich so, dass die Option data=ordered bei ext3 gerade den Vorteil gegenüber xfs darstellt. Wenn hier die Metadaten ins Journal geschrieben werden, ist bereits sichergestellt, dass die eigentlichen Daten ins Dateisystem geschrieben wurden. Vielleicht irre ich mich auch, war der Meinung das die Optionen wie folgt sind: ordered - Die Metadaten wandern ins Journal und werden dort als 'committed' markiert, nachdem die Dateien wirklich auf die Platte geschrieben wurden. Damit lassen sich nach einem unsauberen Neustart alle nicht korrekt geschriebenen Dateien finden, wie die dann aussehen ist ein anderes Thema, weil die Schreiboperation ja noch nicht abgeschlossen war, es können also Daten fehlen. writeback - arbeitet wie ordered, nur mit dem Unterschied dass der 'commit' nicht auf das Ende des realen Schreibens auf die Platte wartet, was etwas schneller sein soll. Hier können nach einem unsauberen Neustart in einer Datei z.B. alte Daten auftauchen, wie das auch bei ext2 der Fall ist (nur ist das fsck wesentlich schneller). journal - schreibt sowohl Metadaten als auch Dateiinhalte ins Journal (und ist deswegen deutlich langsamer). Hier kann nach einem Neustart alles wieder so hergestellt werden, wie es schon im Journal steht. erscheinen, mit der Option data=ordered auszuschließen sein. Bitte sagt Bescheid, wenn ich das falsch verstanden haben sollte. Es sollte so sein, richtig. Kommt aber auf die Schreiboperation an, die gerade stattgefunden (Anhängen ist freundlicher als Änderungen mittendrin) und wann der Strom ausfiel. Beispiel: eine 100 MB grosse Datei wird binär geöffnet und im ersten MB geändert. Das Journal vermerkt das, die Daten werden geschrieben *zack* Strom weg. Jetzt steht im Journal der Eintrag ohne commit - aber auf der Platte sind die Daten schon geändert. So erkläre ich mir das Verhalten was ich beobachten konnte - sollte ich da auf de, Holzweg sein, lass ich mich aber gerne korrigieren. auf den Unterschied zwischen ordered und writeback war ja oben nicht explizit eingegangen worden. Jetzt aber :-) Das ist in der Tat ein starkes Argument für xfs. Trotzdem ist mir auch bei dem Gedanken an ein scheinbar heiles Dateisystem nicht wohl, in welchem ich mit einzelnen Dateien rechnen muss, die von vornherein gar nicht den Inhalt irgend einer vorherigen Version dieser Dateien widerspiegeln können, weil einfach mit beliebigem Inhalt aufgefüllt wurde. Sicherlich ein gutes Argument, aber es wird auch genauso viele Leute geben die mit ext3 besser gefahren sind. Mein persönliches Fazit ist daher unabhängig vom nun verwendetem Dateisystem, dass nach einem solchen GAU immer(!) Vorsicht geboten ist. Egal ob ext3, xfs, reiserfs oder was auch immer. Auf der einen Seite ist das Auftauchen von Nullen nicht so besonders auffällig und unschön - auf der anderen Seite ist der Verlust eines Dateisystems auch nicht besser. Daher (es ist mal wieder an der Zeit es zu erwähnen) mache man Backups. Genau hier sollte ext3 / data=ordered eben xfs überlegen sein, wenn ich das richtig verstehe. Hast Du bei deinen Tests auch darauf geachtet? Richtig, zumindest beschränkt sich der Rahmen für mögliche Probleme auf 15 Minuten (oder entsprechend kürzer). Ich habe mein xfs damals nicht dazu gezwungen, aber auch selten die 15 Minuten gewartet bis zum 'Steckerziehen'. Letztlich ist es Geschmackssache und Glaubensfrage, welches Dateisystem man nimmt, auch ist nicht jedes für jeden Fall brauchbar. Wie gesagt, ich hatte mit xfs bisher die besten Erfahrungen (trotz seiner Schwäche bei einem Stromausfall Dateien zu beschädigen). Andere haben genau das Gegenteil berichten können, wieder andere waren begeistert von ReiserFS. Also hat noch keiner DAS Dateisystem gefunden :-) Cheers, Jan -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Datensicherheit von XFS erhöhen?
Jan Kesten <[EMAIL PROTECTED]> wrote: > Michelle Konzack wrote: > >>> diesem Effekt als dem eines sich auflösenden Dateisystems (ext3 mit >>> journal ist im Vergleich doch deutlich langsamer - und ähnliche Effekte >>> entstehen bei Stromausfall dennoch). > >> Wie meinst Du denn das? > > So wie geschrieben. Ich habe seinerzeit einige Tests gemacht und > mehrere Dateisysteme im laufenden Zugriff 'abgeklemmt' um das > Verhalten bei Stromausfall zu simulieren, Kandidaten waren ext2, ext3, > reiserfs und xfs (und noch ein paar Exoten). Das ganze unter vielen > parallelen Schreib- und Lesezugriffen. [...] > Was ext3 mit data=ordered oder data=writeback und xfs > treiben ist ein Journaling der Metadaten, sprich das soll > sicherstellen, dass das Dateisystem selbst heile bleibt, von den > selbst Daten ist keine Rede. Meine Tests haben das auch bestätigt, in > der Regel bleibt das Dateisystem selbst heil, nur fehlerhafte Daten > treten auf. Und das bei mir mit xfs deutlich seltener als bei ext3 > (und wenn dann offensichtlicher). Das erstaunt mich allerdings sehr. Die Dokumentation zu ext3 und xfs im kernel-Archiv verstehe ich so, dass die Option data=ordered bei ext3 gerade den Vorteil gegenüber xfs darstellt. Wenn hier die Metadaten ins Journal geschrieben werden, ist bereits sichergestellt, dass die eigentlichen Daten ins Dateisystem geschrieben wurden. Insbesondere sollte die Situation, dass nach einem Stromausfall einige Dateien mit angehängten Nullen (also mit einem Inhalt, der mit Sicherheit zu gar keinem Zeitpunkt tatsächlich dorthin gehörte) erscheinen, mit der Option data=ordered auszuschließen sein. Bitte sagt Bescheid, wenn ich das falsch verstanden haben sollte. Da ich selbst bisher keinerlei ``böse'' Erfahrung mit Datenverlust infolge von Stromausfällen gemacht habe, würde mich schon interessieren, wie sich ext3 speziell mit der Option data=ordered gegenüber xfs bezüglich der Datensicherheit in der Praxis bewährt -- auf den Unterschied zwischen ordered und writeback war ja oben nicht explizit eingegangen worden. > Bei ext3 habe ich es dennoch geschafft, das Dateisystem selbst zu > zerlegen, bei xfs nur ein einziges Mal bisher. Das ist in der Tat ein starkes Argument für xfs. Trotzdem ist mir auch bei dem Gedanken an ein scheinbar heiles Dateisystem nicht wohl, in welchem ich mit einzelnen Dateien rechnen muss, die von vornherein gar nicht den Inhalt irgend einer vorherigen Version dieser Dateien widerspiegeln können, weil einfach mit beliebigem Inhalt aufgefüllt wurde. > > Ich weiss auch, dass ext3 auch data=journal anbietet, was sowohl > Metadaten als auch Dateidaten ins Journal schreibt - das war bisher > das stabilste Szenario, aber leider grauenhaft langsam, weil ja alles > doppelt geschrieben werden muss - keine Option. > > Daher bin ich 'offizieller XFS Fan' :-) Mal sehen wie lange noch... > was ich bisher von ZFS gesehen hab begeistert mich schon, nur vom > Linux Port hab ich wenig gehört bisher und ausserdem zielt es auch auf > einen anderen Einsatzbereich ab. > >> Also ext3 wird spätestens alle 15 minuten geflushed und ich habe hier >> in Strasbourg regelmäßig Stromausfälle, so das ich pro Monat mindestens >> einen Reboot hatte... Also Daten habe ich so gut wie nie unter ext3 > > Sicher, und man kann ja auch bei xfs dafür sorgen. Problematisch wird > das Thema eh nur, wenn Schreibzugriffe stattfinden, die die Größe von > Dateien verändern. Genau hier sollte ext3 / data=ordered eben xfs überlegen sein, wenn ich das richtig verstehe. Hast Du bei deinen Tests auch darauf geachtet? Gruß, Elias
Re: Datensicherheit von XFS erhöhen?
Michelle Konzack wrote: diesem Effekt als dem eines sich auflösenden Dateisystems (ext3 mit journal ist im Vergleich doch deutlich langsamer - und ähnliche Effekte entstehen bei Stromausfall dennoch). Wie meinst Du denn das? So wie geschrieben. Ich habe seinerzeit einige Tests gemacht und mehrere Dateisysteme im laufenden Zugriff 'abgeklemmt' um das Verhalten bei Stromausfall zu simulieren, Kandidaten waren ext2, ext3, reiserfs und xfs (und noch ein paar Exoten). Das ganze unter vielen parallelen Schreib- und Lesezugriffen. Ein ext2 ohne Journal kommt ja ohne langwieriges fsck ohnehin nicht wieder in den Betrieb und wies eindeutig die meisten Fehler auf, bis hin zum total unbrauchbaren Dateisystem. ReiserFS war (damals) nicht nennenswert besser, zwar stabiler, aber wenn es einen Fehler gab, dann war meist ein sehr großer Teil des Dateisystem und das auch sehr gründlich betroffen, soll ja heute besser sein. In der Hinsicht verhielten sich ext3 und xfs doch schon wesentlich besser. Nur ein Stromausfall ist und bleibt der Alptraum für jedes Dateisystem, denn alles was heute auf Leistung optimiert ist, nutzt Puffer und Caches massiv und die Daten die dort drin sind gehen verloren. Was ext3 mit data=ordered oder data=writeback und xfs treiben ist ein Journaling der Metadaten, sprich das soll sicherstellen, dass das Dateisystem selbst heile bleibt, von den selbst Daten ist keine Rede. Meine Tests haben das auch bestätigt, in der Regel bleibt das Dateisystem selbst heil, nur fehlerhafte Daten treten auf. Und das bei mir mit xfs deutlich seltener als bei ext3 (und wenn dann offensichtlicher). Bei ext3 habe ich es dennoch geschafft, das Dateisystem selbst zu zerlegen, bei xfs nur ein einziges Mal bisher. Ich weiss auch, dass ext3 auch data=journal anbietet, was sowohl Metadaten als auch Dateidaten ins Journal schreibt - das war bisher das stabilste Szenario, aber leider grauenhaft langsam, weil ja alles doppelt geschrieben werden muss - keine Option. Daher bin ich 'offizieller XFS Fan' :-) Mal sehen wie lange noch... was ich bisher von ZFS gesehen hab begeistert mich schon, nur vom Linux Port hab ich wenig gehört bisher und ausserdem zielt es auch auf einen anderen Einsatzbereich ab. Also ext3 wird spätestens alle 15 minuten geflushed und ich habe hier in Strasbourg regelmäßig Stromausfälle, so das ich pro Monat mindestens einen Reboot hatte... Also Daten habe ich so gut wie nie unter ext3 Sicher, und man kann ja auch bei xfs dafür sorgen. Problematisch wird das Thema eh nur, wenn Schreibzugriffe stattfinden, die die Größe von Dateien verändern. Wird nur gelesen ist das alles halb so, da ändert sich ja nichts. Aber da selbst mit ext3 der fsck ein paar Stunden dauerte (1,8 TByte auf 3Ware Raid-5), habe ich es vorgezogen endlich ne neue APC mit zwei externen Akku-Blocks zu besorgen... ist einfach nervenschonender. Oder einfach den optionalen Akku-Pack für den 3ware Controller, der den Cache sichert für genau diesen Fall ;-) Sofern man einen 'guten'(TM) 3ware Controller hat. Cheers, Jan -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Datensicherheit von XFS erhöhen?
Am 2006-05-14 21:00:50, schrieb Jan Kesten: > Soweit ich das weiss, bietet XFS diese Option leider nicht (auch wenn > ich sonst sehr gerne XFS einsetze), aber ich persönlich lebe lieber mit > diesem Effekt als dem eines sich auflösenden Dateisystems (ext3 mit > journal ist im Vergleich doch deutlich langsamer - und ähnliche Effekte > entstehen bei Stromausfall dennoch). Wie meinst Du denn das? Also ext3 wird spätestens alle 15 minuten geflushed und ich habe hier in Strasbourg regelmäßig Stromausfälle, so das ich pro Monat mindestens einen Reboot hatte... Also Daten habe ich so gut wie nie unter ext3 verloren. Ein Grund, warum ich von ext3 nicht weggehe. Aber da selbst mit ext3 der fsck ein paar Stunden dauerte (1,8 TByte auf 3Ware Raid-5), habe ich es vorgezogen endlich ne neue APC mit zwei externen Akku-Blocks zu besorgen... ist einfach nervenschonender. Greetings Michelle Konzack -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Datensicherheit von XFS erhöhen?
Dirk Salva schrieb: > Das aktuelle Problem war und ist nicht nachvollziehbar und lag nicht > an der Spannungsversorgung von extern. Ich habe an den > Firewire-Anschluß des Rechners meine Videokamera (Akkubetrieb) > angeschlossen und eingeschaltet. Und schwupps war der Rechner aus, > hart, so wie bei einem Stromausfall. Strom war aber noch da, hab > extra nachgesehen. Das hat er Das klingt nicht besonders gut - defekte Leitung oder defektes Netzteil kannst Du ausschließen? Besonders bei letzterem bin ich in letzter Zeit immer skeptisch, denn mein subjektiver Eindruck ist, dass Netzteile auch nicht mehr das sind was sie mal waren. Sind früher Platten am laufenden Meter ausgefallen, Speicher kaputt gegangen so hab ich hier mehr Schäden an Netzteilen, deren Lüftern und ähnlichem. Alles Dinge bei denen ich sagen muss, dass das unnötige Fehler sind in meinen Augen. Cheers, Jan signature.asc Description: OpenPGP digital signature
Re: Datensicherheit von XFS erhöhen?
On 2006-05-16 00:00:23 +0200, Dirk Salva wrote: > Hmm. Die Textdokumentation zu proc sagt: > > dirty_writeback_centisecs > - > The pdflush writeback daemons will periodically wake up and write d' > data out to disk. This tunable expresses the interval between those > wakeups, in 100'ths of a second. > Setting this to zero disables periodic writeback altogether. > > Das scheint mir der entsprechende Parameter zu sein. Der steht > allerdings bei mir bei zero. Wie ändert man das? z.B. mit sysctl. Abfragen kannst du den Wert mit sysctl vm.dirty_writeback_centisecs Bei mir steht dort 500, was 5 sec entspricht. Schau dir auch mal dirty_expire_centisecs an. > Andere Frage wäre, ob das die richtige Schraube zum dran drehen wäre, > denn in der gleichen Quelle, nur der Datei xfs.txt, steht u.a.: > sysctls > === > fs.xfs.sync_interval (Min: HZ Default: 30*HZ Max: 60*HZ) > The interval at which the xfssyncd thread for xfs filesystems > flushes metadata out to disk. This thread will flush log > activity out, and do some processing on unlinked inodes > > Jetzt stelle ich mir die Frage, a) wo ich das für XFS einstelle und b) > was denn jetzt der defaultwert besagt. 30Hz wäre ja 30x pro Sekunde, > das kann ich mir wirklich nicht vorstellen. Ich vermute, dass das HZ ist nicht das echte Hz, sondern dass kernel-interne. Such mal in deiner Kernel-Config nach HZ. Außerdem geht es laut Beschreibung bei dieser Option um Metadata, was dir wohl nicht wirklich viel helfen wird. Michael -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Datensicherheit von XFS erhöhen?
Hi! Am Mon, 15 May 2006 10:53:59 +0200 schrieb Jan Kesten <[EMAIL PROTECTED]>: > Ansonsten: USV :-) Jo, das Gentoo-Handbuch sagt hierzu z.B.: --8<-- XFS ist ein Dateisytem mit Metadata-Journaling, das mit einer Menge robuster Fähigkeiten glänzt und auf Skalierbarkeit ausgelegt ist. Wir empfehlen den Einsatz dieses Dateisystems nur auf Linux-Systemen mit High-End-SCSI und/oder Fibre-Channel-Storage und einer redundaten Stromversorgung. Da XFS agressiv vom RAM gebraucht macht, können unsachgemäß designte Programme (solche die keine Vorsichtsmaßnahmen treffen, wenn Sie auf die Festplatte schreiben und davon gibt es einige) dazu führen, dass eine ganze Menge Daten verloren gehen, wenn das System unerwartet ausfällt. -->8-- LG, Ace -- () ASCII Ribbon Campaign - against HTML mail /\- against Microsoft attachments http://www.efn.no/html-bad.html http://www.goldmark.org/netrants/no-word/attach.html signature.asc Description: PGP signature
Re: Datensicherheit von XFS erhöhen?
Dirk Salva schrieb: > Ok. Aber da bleiben dann immer noch Fragen offen: > - als erste ganz wichtig obige "wie kann ich die defekten Dateien finden?" > - was meinst Du mit "die entsprechenden Dateien"? Ich habe das jetzt > erst drei oder vier mal gehabt, und jedesmal fallen mir nach einigen > Tagen wieder welche auf, die ich noch nicht kannte. Der Effekt ist, dass XFS Metadaten-Updates macht und das Problem tritt auf, wenn eine Datei schreibend geöffnet ist, das Metadaten-Update stattgefunden hat, aber die Datei selbst noch nicht auf die Platte geschrieben wird. XFS stellt an dieser Stelle nur sicher, dass das Dateisystem in sich konsistent ist und nicht die Dateien selbst. Wollte man das, müsste man auf Caching verzichten und alles synchron auf die Platte schreiben, was a) die Platte belastet und b) zu großen Geschwindigkeitseinbußen führt. > - können wichtige Systemdateien (libs, module, irgendsowas) davon > betroffen sein, oder eher nicht, sondern "nur" Log-, Status- und > Config-Dateien? Betroffen sind i.d.R. nur schreibend geöffnete Dateien, also weniger Programme, Configs oder Bibliotheken. Log sind da sehr gerne anfällig oder aber auch Datenbanken - darauf sollte man sein Hauptaugenmerk richten. Bei den Logs ist es nicht soo tragisch, aber kaputte Datenbank kann sehr ärgerlich sein. Das erkennen welche Dateien dort betroffen sind ist aus deswegen schwierig, md5sum kann man nicht verwenden, weil die Dateien ja gerade schreibend offen waren. Entgegenwirken kann man den Effekten durch ein halbwegs regelmäßiges 'sync' wenn das die Perfomance zulässt, dadurch wird die Wahrscheinlichkeit kleiner. Ist zwar nicht schön, aber lieber so und ein Backup zur Hand als wenn sich ein Dateisystem komplett auflöst, das habe ich mit XFS noch nie geschafft :-) Ansonsten: USV :-) Cheers, Jan signature.asc Description: OpenPGP digital signature
Re: Datensicherheit von XFS erhöhen?
On 14.05.06 22:44:08, Dirk Salva wrote: > - können wichtige Systemdateien (libs, module, irgendsowas) davon > betroffen sein, oder eher nicht, sondern "nur" Log-, Status- und > Config-Dateien? Prinzipiell alle Dateien die zum Schreiben geoeffnet werden. Alle Dateien die nur zum Lesen geoeffnet werden sollten nicht betroffen sein, solange das Dateisystem sich nicht in Luft aufloest... Andreas -- This life is yours. Some of it was given to you; the rest, you made yourself. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Datensicherheit von XFS erhöhen?
Hallo, Dirk! > Angeblich nutzt XFS ja als journalling-Option standardmäßig writeback. > Kann man das (und wenn ja: wie?) irgendwie umstellen auf die - so weit > ich das verstehe - sicherste Variante journal umstellen? Soweit ich das weiss, bietet XFS diese Option leider nicht (auch wenn ich sonst sehr gerne XFS einsetze), aber ich persönlich lebe lieber mit diesem Effekt als dem eines sich auflösenden Dateisystems (ext3 mit journal ist im Vergleich doch deutlich langsamer - und ähnliche Effekte entstehen bei Stromausfall dennoch). Aus der XFS-FAQ: Q: Why do I see binary NULLS in some files after recovery when I unplugged the power? XFS journals metadata updates, not data updates. After a crash you are supposed to get a consistent filesystem which looks like the state sometime shortly before the crash, NOT what the in memory image looked like the instant before the crash. Since XFS does not write data out immediately unless you tell it to with fsync, an O_SYNC or O_DIRECT open (the same is true of other filesystems), you are looking at an inode which was flushed out, but whose data was not. Typically you'll find that the inode is not taking any space since all it has is a size but no extents allocated (try examining the file with the xfs_bmap(8) command). > Und: kann man irgendwie die beim crash modifizierten/zerstörten Dateien > herausfinden? Ob das von Haus aus geht weiss ich leider nicht, zumindest nicht dass ich das jetzt aus dem Kopf wüsste. Aber nach einem Stromausfall ist so oder so vorsicht geboten, dass ich dazu übergegangen bin, die entsprechenden Dateien danach erstmal zu überprüfen. Spiele gerade mit ZFS, das soll ja auch dagegen immun sein. Cheers, Jan signature.asc Description: PGP signature signature.asc Description: OpenPGP digital signature
Re: Datensicherheit von XFS erhöhen?
Dirk Salva schrieb: @Dirk, sorry für die Mail. Wann lerne ich endlich mit Thunderbird umzugehen? > ich benutze hier ein Debian Sarge (32- und 64-Bit) mit Partitionen mit > XFS Filesystem. Prinzipiell bin ich damit sehr zufrieden, allerdings > stört mich das Verhalten bei Stromausfall (was in letzter Zeit ein paar > mal vorgekommen ist). Problem ist dann nämlich, daß dann irgendwie Müll > entsteht (näher kann ich das gerade nicht erläutern): Genau das Problem hatte ich auch mit XFS. Ich hatte es auf meinem Laptop eingesetzt, sowohl für /var als auch /home. Da ich mit sehr aktuellen Suspend2-Kernel-Versionen experimentiere hatte ich es auch manchmal, das der Laptop nicht wieder aufwachte, also das selbe als wenn er abgestürtzt wäre. Und am liebsten hat es AFAIK offene Config-Dateien zerschossen. Mehrfach meine ICQ-Config und mein News-Spool oder einmal auch mehrere Bilder, die ich die Stunde davor bearbeitet habe. :-( Bevor ich nochmal XFS anfasse werde ich noch etwas Zeit vergehen lassen... Jakob, wieder auf sicherem Boden mit ext3 signature.asc Description: OpenPGP digital signature
Datensicherheit von XFS erh öhen?
Hi Leute, ich benutze hier ein Debian Sarge (32- und 64-Bit) mit Partitionen mit XFS Filesystem. Prinzipiell bin ich damit sehr zufrieden, allerdings stört mich das Verhalten bei Stromausfall (was in letzter Zeit ein paar mal vorgekommen ist). Problem ist dann nämlich, daß dann irgendwie Müll entsteht (näher kann ich das gerade nicht erläutern): - heute z.B. war bei einer Partition der Superblock defekt. - in offenbar vom System offengehaltenen Dateien wie Log- und .Conf-Dateien steht dann bei einem Neustart (xfs_check und xfs_repair ausgeführt) am Anfang immer @ oder ... Damit kann die entsprechende Software nix anfangen und läuft dann oftmals nicht, was nur leider nicht immer sofort bemerkt wird. So z.B. bei /var/lib/logrotate/status passiert. Aufgefallen erst, weil logrotate mir ne Mail geschickt hat. Angeblich nutzt XFS ja als journalling-Option standardmäßig writeback. Kann man das (und wenn ja: wie?) irgendwie umstellen auf die - so weit ich das verstehe - sicherste Variante journal umstellen? Und: kann man irgendwie die beim crash modifizierten/zerstörten Dateien herausfinden? ciao, Dirk -- | Akkuschrauber Kaufberatung and AEG GSM stuff | | Visit my homepage: http://www.nutrimatic.ping.de/ | | FIDO: Dirk Salva 2:244/6305.10 Internet: dsalvaATgmx.de | |The "Ruhrgebiet", best place to live in Germany! | -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: XFS-Raid1-Root Filesyst em möglich?
On Mon, Apr 10, 2006 at 02:03:00PM +0200, Markus Schulz wrote: > Joerg Rieger schrieb: > > On Mon, Apr 10, 2006 at 11:03:38AM +0200, Markus Schulz wrote: > > [...] > >> Falls übrigens jemand eine Idee hat, wie man mit solchem > >> Überlastsituationen besser umgehen kann, dann immer her damit. > >> Das Problem ist leider, das ich die Apache Instanz Anzahl (momentan 230) > >> nicht senken möchte um Überlast grundsätzlich einen Riegel > >> vorzuschieben, da auch viele Anfragen auf einfache Bilder stattfinden > >> (also keine dyn. Pages). Wenn aber alle 230 Instanzen für dynamische > >> Seiten gebraucht werden, geht der Rechner in die Knie. Mit der > >> Anwendungs Optimierung beschäftigen wir uns natürlich ebenfalls. > > > > Bei sovielen Zugriffen, vorallem statischen Sachen, würde ich den den > > Apache durch lighttpd[1] ersetzen. > > > > Lighttpd erzeugt insgesamt deutlich weniger Last, ist schneller > > (besonders bei statischen Sachen) und verbraucht dabei weniger RAM als > > Apache. Auch bei dynamischen Seiten kann er von Vorteil sein. > > Also von statischer Natur sind die Seiten eher nicht. Selbst die Bilder > werden generiert. Allerdings werden alle generierten Bilder (momentan > knapp 3 Mio [auf viele Verzeichnisebenen verteilt]) gecached und bei > erneuter Anfrage direkt von Platte ausgeliefert. Falls sie nicht > existieren, werden sie mittels Errorhandler+Rewriting auf das > Generationsscript umgeleitet und das Bild wird erzeugt und ausgeliefert. Dann könnte es sich für dich lohnen vom apache prefork auf threaded umzustellen. Müsstest dann aber PHP über die fastcgi Schnittstelle laufen lassen. Letzteres habe ich selbst noch nicht in einer Produktionsumgebung am laufen, also von daher erstmal ausgiebig testen. Habe nämlich gehört, dass der fastcgi support bei Apache nämlich zu merkwürdigen Fehlern führen soll, mit lighttpd + fastcgi klappts hingegen problemlos. -- http://www.lumrix.net -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: XFS-Raid1-Root Filesystem möglich?
Joerg Rieger schrieb: > On Mon, Apr 10, 2006 at 11:03:38AM +0200, Markus Schulz wrote: > [...] >> Falls übrigens jemand eine Idee hat, wie man mit solchem >> Überlastsituationen besser umgehen kann, dann immer her damit. >> Das Problem ist leider, das ich die Apache Instanz Anzahl (momentan 230) >> nicht senken möchte um Überlast grundsätzlich einen Riegel >> vorzuschieben, da auch viele Anfragen auf einfache Bilder stattfinden >> (also keine dyn. Pages). Wenn aber alle 230 Instanzen für dynamische >> Seiten gebraucht werden, geht der Rechner in die Knie. Mit der >> Anwendungs Optimierung beschäftigen wir uns natürlich ebenfalls. > > Bei sovielen Zugriffen, vorallem statischen Sachen, würde ich den den > Apache durch lighttpd[1] ersetzen. > > Lighttpd erzeugt insgesamt deutlich weniger Last, ist schneller > (besonders bei statischen Sachen) und verbraucht dabei weniger RAM als > Apache. Auch bei dynamischen Seiten kann er von Vorteil sein. Also von statischer Natur sind die Seiten eher nicht. Selbst die Bilder werden generiert. Allerdings werden alle generierten Bilder (momentan knapp 3 Mio [auf viele Verzeichnisebenen verteilt]) gecached und bei erneuter Anfrage direkt von Platte ausgeliefert. Falls sie nicht existieren, werden sie mittels Errorhandler+Rewriting auf das Generationsscript umgeleitet und das Bild wird erzeugt und ausgeliefert. Aber einen Blick werde ich mal darauf werfen, danke. Speicher scheint momentan übrigens noch kein Problem zu sein, es steht nahezu immer rund 750MB Cache zur Verfügung.(2GB Maschine) MfG Markus Schulz -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: XFS-Raid1-Root Filesyst em möglich?
On Mon, Apr 10, 2006 at 11:03:38AM +0200, Markus Schulz wrote: [...] > Falls übrigens jemand eine Idee hat, wie man mit solchem > Überlastsituationen besser umgehen kann, dann immer her damit. > Das Problem ist leider, das ich die Apache Instanz Anzahl (momentan 230) > nicht senken möchte um Überlast grundsätzlich einen Riegel > vorzuschieben, da auch viele Anfragen auf einfache Bilder stattfinden > (also keine dyn. Pages). Wenn aber alle 230 Instanzen für dynamische > Seiten gebraucht werden, geht der Rechner in die Knie. Mit der > Anwendungs Optimierung beschäftigen wir uns natürlich ebenfalls. Bei sovielen Zugriffen, vorallem statischen Sachen, würde ich den den Apache durch lighttpd[1] ersetzen. Lighttpd erzeugt insgesamt deutlich weniger Last, ist schneller (besonders bei statischen Sachen) und verbraucht dabei weniger RAM als Apache. Auch bei dynamischen Seiten kann er von Vorteil sein. [1] http://www.lighttpd.net/ -- http://www.lumrix.net -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: XFS-Raid1-Root Filesystem möglich?
Jan Kesten schrieb: > Markus Schulz schrieb: > >> hmm, du machst mir Angst. Der Server läuft später unter recht hohem >> Load (>200) zu Spitzenlastzeiten. Ist unter diesen Umständen wirklich >> davon abzuraten xfs einzusetzen? > > In meinen Augen ganz klar: XFS ja, Software-RAID bedingt. Hatte auch > eine ganze Zeit ein XFS auf einem Software-RAID am laufen und auch unter > hoher Last keine Probleme damit gehabt (wird nur irgendwann langsam), > besonders wenn es zu IO-Wait kommt - hatte zwar nie Probleme, doch wenn > IO der Engpass wird würde ich lieber auf Hardware vertrauen. Das beruhigt doch schonmal ungemein. > Fairerweise muss ich aber auch sagen, dass ich als XFS-Fan auch die > Auflösung des Dateisystems mal beobachten musste: das war in den > Anfangszeiten von XFS und führte zu vielen 0-Byte-Dateien. War jedoch > einmalig und ist mit neueren Versionen nie wieder vorgekommen. (Und nein > einen FS-War will ich nicht anzetteln :-) > > Was verursacht denn diese massiv hohe Last? Wenn es IO ist wo es hängt, > rate ich dringend zu Hardware-RAID und vernüftigen(TM) Platten :-) Das Problem ist auf der alten Kiste die CPU, sobald die ans Limit gerät schaukelt sich der Rechner in endlos hohe Load-Bereiche. Die Apache/postmaster Instanz Anzahl steigt dann munter weiter, da ja jede einzelne Abfrage (dynamische Pages) länger braucht. Im Regelbetrieb, sofern keine Überlast Situation auftritt, liegt der Load meist bei 10-20. Nur leider kommt auf der alten Kiste es regelmäßig (fast täglich) zu dieser Überlastsitutation. Daher sollte das FS keine Probleme mit solcher Last haben. IO ist eigentlich weniger das Problem, die Kiste hat 2GB Ram und das Caching (hauptsächlich für die Postgres DB) greift sehr gut. ca. 750MB sind ständig als Cache verfügbar und z.B. dstat zeigt auch keine ständige Harddisk Aktivität in größerem Umfang an. Auch der IO-Wait Anteil ist sehr gering (< 5%). Falls übrigens jemand eine Idee hat, wie man mit solchem Überlastsituationen besser umgehen kann, dann immer her damit. Das Problem ist leider, das ich die Apache Instanz Anzahl (momentan 230) nicht senken möchte um Überlast grundsätzlich einen Riegel vorzuschieben, da auch viele Anfragen auf einfache Bilder stattfinden (also keine dyn. Pages). Wenn aber alle 230 Instanzen für dynamische Seiten gebraucht werden, geht der Rechner in die Knie. Mit der Anwendungs Optimierung beschäftigen wir uns natürlich ebenfalls. Markus Schulz -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: XFS-Raid1-Root Filesystem möglich?
Markus Schulz schrieb: > hmm, du machst mir Angst. Der Server läuft später unter recht hohem > Load (>200) zu Spitzenlastzeiten. Ist unter diesen Umständen wirklich > davon abzuraten xfs einzusetzen? In meinen Augen ganz klar: XFS ja, Software-RAID bedingt. Hatte auch eine ganze Zeit ein XFS auf einem Software-RAID am laufen und auch unter hoher Last keine Probleme damit gehabt (wird nur irgendwann langsam), besonders wenn es zu IO-Wait kommt - hatte zwar nie Probleme, doch wenn IO der Engpass wird würde ich lieber auf Hardware vertrauen. Fairerweise muss ich aber auch sagen, dass ich als XFS-Fan auch die Auflösung des Dateisystems mal beobachten musste: das war in den Anfangszeiten von XFS und führte zu vielen 0-Byte-Dateien. War jedoch einmalig und ist mit neueren Versionen nie wieder vorgekommen. (Und nein einen FS-War will ich nicht anzetteln :-) Was verursacht denn diese massiv hohe Last? Wenn es IO ist wo es hängt, rate ich dringend zu Hardware-RAID und vernüftigen(TM) Platten :-) Cheers, Jan signature.asc Description: OpenPGP digital signature
Re: [SOLVED] Re: XFS-Raid1-Root F ilesystem möglich?
Hi! Markus Schulz wrote: Am Sonntag, 9. April 2006 17:03 schrieb Christian Fröse: Hi Markus Schulz wrote: Am Samstag, 8. April 2006 20:49 schrieb Markus Schulz: Hallo, ich versuche seit Stunden auf einem Rootserver ein XFS-Software-Raid1- Rootfilesystem mit einem Debian-Sarge aufzusetzen. Bisher leider ohne Erfolg. Hab es nun geschafft. Ich habe jetzt bei lilo mittels append die Devices des MD-Raids von Hand angegeben: append="md=1,/dev/sda2,/dev/sdb2" Warum das für XFS Filesystem notwendig ist und für ext3 nicht entzieht sich meinem Verständnis. Umso Interessanter sieht jetzt das Bootlog aus: Apr 8 21:44:14 debian31m kernel: Kernel command line: auto BOOT_IMAGE=Linux ro root=901 md=1,/dev/sda2,/dev/sdb2 Apr 8 21:44:14 debian31m kernel: md: Will configure md1 (super-block) from /dev/sda2,/dev/sdb2, below. Kann es sein, das du dein Raid ohne Superblock erstellt hast? Bei mir geht es im RAID 1 mit XFS ohne Kernelparameter. Meine Version: /dev/md1: Version : 00.90.03 Creation Time : Sat Jul 2 21:17:58 2005 Raid Level : raid1 Array Size : 4883648 (4.66 GiB 5.00 GB) Device Size : 4883648 (4.66 GiB 5.00 GB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 1 Persistence : Superblock is persistent Update Time : Sun Apr 9 21:26:37 2006 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 UUID : c4041f18:785bfcc5:94fcf87e:078e36a3 Events : 0.2191445 Number Major Minor RaidDevice State 0 310 active sync /dev/hda1 1 2211 active sync /dev/hdc1 Dieses System läuft auf einem 2.6.15.6 (ist mein aktuellster Kernel) MfG Christian
Re: [SOLVED] Re: XFS-Raid1-Root Filesystem möglich?
Am Sonntag, 9. April 2006 17:03 schrieb Christian Fröse: > Hi > > Markus Schulz wrote: > > Am Samstag, 8. April 2006 20:49 schrieb Markus Schulz: > >> Hallo, > >> > >> ich versuche seit Stunden auf einem Rootserver ein > >> XFS-Software-Raid1- Rootfilesystem mit einem Debian-Sarge > >> aufzusetzen. Bisher leider ohne Erfolg. > > > > Hab es nun geschafft. > > Ich habe jetzt bei lilo mittels append die Devices des MD-Raids von > > Hand angegeben: > > append="md=1,/dev/sda2,/dev/sdb2" > > > > Warum das für XFS Filesystem notwendig ist und für ext3 nicht > > entzieht sich meinem Verständnis. Umso Interessanter sieht jetzt > > das Bootlog aus: > > > > Apr 8 21:44:14 debian31m kernel: Kernel command line: auto > > BOOT_IMAGE=Linux ro root=901 md=1,/dev/sda2,/dev/sdb2 > > Apr 8 21:44:14 debian31m kernel: md: Will configure md1 > > (super-block) from /dev/sda2,/dev/sdb2, below. > > Kann es sein, das du dein Raid ohne Superblock erstellt hast? Bei mir > geht es im RAID 1 mit XFS ohne Kernelparameter. debian31m:~# mdadm -D /dev/md1 /dev/md1: Version : 00.90.03 Creation Time : Fri Apr 7 15:40:10 2006 Raid Level : raid1 Array Size : 155300288 (148.11 GiB 159.03 GB) Device Size : 155300288 (148.11 GiB 159.03 GB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 1 Persistence : Superblock is persistent Update Time : Sun Apr 9 20:57:05 2006 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 UUID : 7c122640:df3a2d6a:39ac909f:f2ba2f8d Events : 0.16331 Number Major Minor RaidDevice State 0 820 active sync /dev/sda2 1 8 181 active sync /dev/sdb2 Superblock ist also persistent. Benutzt du auch Kernel 2.6.16.2? Sobald ich das Raid mit ext3 formatiere, brauch ich die Parameter ja auch nicht mehr. Nur XFS stellt sich quer?!? -- Markus Schulz Kreuzigt mich - aber Debian ist einfach deppensicher. Es lässt Deppen gegen eine Wand von Schwierigkeiten klatschen und langsam abtropfen. Wer die Tür findet, darf mitspielen - und so sieht das Spielzeug dann eben aus: Gut gepflegt. -- Joerg Rossdeutscher
Re: XFS-Raid1-Root Filesystem möglich?
Am Sonntag, 9. April 2006 18:35 schrieb Joern Seemann: > On Sat, 08 Apr 2006 20:49:44 +0200, Markus Schulz wrote: > > Ist mein Vorhaben womöglich garnicht > > umsetzbar? Kann XFS kein RootFS für ein Software-Raid1 bieten? > > Sagen wir es so: Sobald dein FS unter Last kommt wird es sich selbst > aushängen. Ich habe jedenfalls nur schlechte Erfahrungen mit XFS auf > MD-Devices gemacht. hmm, du machst mir Angst. Der Server läuft später unter recht hohem Load (>200) zu Spitzenlastzeiten. Ist unter diesen Umständen wirklich davon abzuraten xfs einzusetzen? -- Markus Schulz > denn von vi bin ich erstmal grundsätzlich abgeschreckt und hoffe dass > ich mich niemals damit auseinandersetzen muss :) Das hofft der vi von Dir übrigens auch. (Joerg Zimmermann)
Re: XFS-Raid1-Root Filesyst em möglich?
On Sun, Apr 09, 2006 at 06:35:38PM +0200, Joern Seemann wrote: > Sagen wir es so: Sobald dein FS unter Last kommt wird es sich selbst > aushängen. Ich habe jedenfalls nur schlechte Erfahrungen mit XFS auf > MD-Devices gemacht. Das scheint wie immer alles eine Definitionsfrage zu sein, bei mir zu Hause läuft ein XFS-RAID1 in Software bisher völlig problemlos. Allerdings bin ich auch fast einziger User auf dem Server, außer beim regelmäßigen Plattentest hat er also wirklich nicht viel zu tun. Einzig der letzte Kernel-update von 2.6.8-2 auf 2.6.8-3 hat Probleme bereitet, weil aus einem nicht nachvollziehbaren Grund auf dem Rechner offensichtlich kein update-grub gemacht wurde. Dafür weiß ich jetzt, wie ich mein RAID1 mit Knoppix maunte;-) ciao, Dirk -- | Akkuschrauber Kaufberatung and AEG GSM stuff | | Visit my homepage: http://www.nutrimatic.ping.de/ | | FIDO: Dirk Salva 2:244/6305.10 Internet: dsalvaATgmx.de | |The "Ruhrgebiet", best place to live in Germany! | -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: XFS-Raid1-Root Filesystem möglich?
Hi Joern Seemann wrote: On Sat, 08 Apr 2006 20:49:44 +0200, Markus Schulz wrote: Ist mein Vorhaben womöglich garnicht umsetzbar? Kann XFS kein RootFS für ein Software-Raid1 bieten? Sagen wir es so: Sobald dein FS unter Last kommt wird es sich selbst aushängen. Ich habe jedenfalls nur schlechte Erfahrungen mit XFS auf MD-Devices gemacht. Gruss Jörn Dies kann ich auf keinen Fall bestätigen. Habe mehrere verschiedene Raids (eins und fünf) auf verschiedenen Rechnern und habe ein solches Verhalten noch nicht erlebt. Christian
Re: XFS-Raid1-Root Filesystem möglich?
On Sat, 08 Apr 2006 20:49:44 +0200, Markus Schulz wrote: > Ist mein Vorhaben womöglich garnicht > umsetzbar? Kann XFS kein RootFS für ein Software-Raid1 bieten? Sagen wir es so: Sobald dein FS unter Last kommt wird es sich selbst aushängen. Ich habe jedenfalls nur schlechte Erfahrungen mit XFS auf MD-Devices gemacht. Gruss Jörn -- Wir ertrinken in Information, aber hungern nach Wissen - John Naisbitt Mein Weblog: http://horatio.aumund.org/ -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: [SOLVED] Re: XFS-Raid1-Root F ilesystem möglich?
Hi Markus Schulz wrote: Am Samstag, 8. April 2006 20:49 schrieb Markus Schulz: Hallo, ich versuche seit Stunden auf einem Rootserver ein XFS-Software-Raid1- Rootfilesystem mit einem Debian-Sarge aufzusetzen. Bisher leider ohne Erfolg. Hab es nun geschafft. Ich habe jetzt bei lilo mittels append die Devices des MD-Raids von Hand angegeben: append="md=1,/dev/sda2,/dev/sdb2" Warum das für XFS Filesystem notwendig ist und für ext3 nicht entzieht sich meinem Verständnis. Umso Interessanter sieht jetzt das Bootlog aus: Apr 8 21:44:14 debian31m kernel: Kernel command line: auto BOOT_IMAGE=Linux ro root=901 md=1,/dev/sda2,/dev/sdb2 Apr 8 21:44:14 debian31m kernel: md: Will configure md1 (super-block) from /dev/sda2,/dev/sdb2, below. Kann es sein, das du dein Raid ohne Superblock erstellt hast? Bei mir geht es im RAID 1 mit XFS ohne Kernelparameter. MfG Christian Fröse
[SOLVED] Re: XFS-Raid1-Root Filesystem möglich?
Am Samstag, 8. April 2006 20:49 schrieb Markus Schulz: > Hallo, > > ich versuche seit Stunden auf einem Rootserver ein > XFS-Software-Raid1- Rootfilesystem mit einem Debian-Sarge > aufzusetzen. Bisher leider ohne Erfolg. Hab es nun geschafft. Ich habe jetzt bei lilo mittels append die Devices des MD-Raids von Hand angegeben: append="md=1,/dev/sda2,/dev/sdb2" Warum das für XFS Filesystem notwendig ist und für ext3 nicht entzieht sich meinem Verständnis. Umso Interessanter sieht jetzt das Bootlog aus: Apr 8 21:44:14 debian31m kernel: Kernel command line: auto BOOT_IMAGE=Linux ro root=901 md=1,/dev/sda2,/dev/sdb2 Apr 8 21:44:14 debian31m kernel: md: Will configure md1 (super-block) from /dev/sda2,/dev/sdb2, below. .. Apr 8 21:44:14 debian31m kernel: md: Autodetecting RAID arrays. Apr 8 21:44:14 debian31m kernel: md: autorun ... Apr 8 21:44:14 debian31m kernel: md: considering sdb2 ... Apr 8 21:44:14 debian31m kernel: md: adding sdb2 ... Apr 8 21:44:14 debian31m kernel: md: adding sda2 ... Apr 8 21:44:14 debian31m kernel: md: created md1 Apr 8 21:44:14 debian31m kernel: md: bind Apr 8 21:44:14 debian31m kernel: md: bind Apr 8 21:44:14 debian31m kernel: md: running: Apr 8 21:44:14 debian31m kernel: raid1: raid set md1 active with 2 out of 2 mirrors Apr 8 21:44:14 debian31m kernel: md: ... autorun DONE. Apr 8 21:44:14 debian31m kernel: md: Loading md1: /dev/sda2 Apr 8 21:44:14 debian31m kernel: md: couldn't update array info. -22 Apr 8 21:44:14 debian31m kernel: md: could not bd_claim sda2. Apr 8 21:44:14 debian31m kernel: md: md_import_device returned -16 Apr 8 21:44:14 debian31m kernel: md: could not bd_claim sdb2. Apr 8 21:44:14 debian31m kernel: md: md_import_device returned -16 Apr 8 21:44:14 debian31m kernel: md: starting md1 failed Apr 8 21:44:14 debian31m kernel: UDF-fs: No VRS found Apr 8 21:44:14 debian31m kernel: XFS mounting filesystem md1 Apr 8 21:44:14 debian31m kernel: Ending clean XFS mount for filesystem: md1 Apr 8 21:44:14 debian31m kernel: VFS: Mounted root (xfs filesystem) readonly. Apr 8 21:44:14 debian31m kernel: Freeing unused kernel memory: 152k freed Das verstehe ich nun wiederum garnicht. Aber es funktioniert anstandslos. Das Raid ist gemountet und läuft laut /proc/mdstats auch im Sync. -- Markus Schulz Grid Computing erfreut sich gerade bei Windows-Nutzern sehr regem Zuspruch, auch wenn die Rechnerbesitzer meist nichts von ihrem Glück wissen.
XFS-Raid1-Root Filesystem möglich?
Hallo, ich versuche seit Stunden auf einem Rootserver ein XFS-Software-Raid1- Rootfilesystem mit einem Debian-Sarge aufzusetzen. Bisher leider ohne Erfolg. Folgende Ausgangslage: Device Boot Start End Blocks Id System /dev/sda1 1 7 56196 83 Linux /dev/sda2 124 19457 155300355 fd Linux raid autodetect /dev/sda3 8 123 931770 82 Linux swap / Solaris (sda1 kann ignoriert werden, war ein Test mit /boot drauf) Device Boot Start End Blocks Id System /dev/sdb1 1 123 987966 83 Linux /dev/sdb2 * 124 19457 155300355 fd Linux raid autodetect Das Raid enthält sda2 + sdb2. Auf sdb1 liegt ein eigenes Rescue System. Wenn ich das Raid1 mit ext3 erstelle und folgende lilo.conf verwende: boot=/dev/md1 map=/boot/map delay=5 vga=normal raid-extra-boot=mbr-only default=rescue image=/boot/vmlinuz-2.6.16.2 label=LinuxNew root=/dev/md1 read-only image=/boot/vmlinuz-2.6.16.2 label=rescue root=/dev/sdb1 read-only kann ich wunderbar sowohl das rescue als auch das raid1 booten.(mit lilo -R ...) Sobald ich das Raid mit xfs formatiere und die Daten vom eigenen rescue System rüberkopiere (+ lilo aufruf) funktioniert weder das eigene rescue noch das Raid1-rootfs. Der Kernel ist selbstverständlich in beiden Fällen gleich (selfmade) und ohne initrd. Er hat natürlich xfs einkompiliert: CONFIG_XFS_FS=y CONFIG_XFS_QUOTA=y CONFIG_XFS_SECURITY=y CONFIG_XFS_POSIX_ACL=y # CONFIG_XFS_RT is not set # CONFIG_VXFS_FS is not set Jetzt kommt das Problem, ich habe keine Logausgaben. Da mir bis Montag keine serielle Konsole zur Verfügung steht. Mir ist allerdings schleierhaft, wieso nach formatieren mit XFS nichtmal mehr das eigene rescue System (weiterhin mit ext3) funktioniert. Die lilo Option raid-extra-boot=mbr-only sorgt ja dafür, das der Raid-Boot-Code nur im MBR beider Platten residiert und ein ext3-raid funktioniert damit ja auch tadellos. Andere Optionen für diesen Parameter sind nicht möglich, da XFS den Bootsektor der Partition selbst mitverwendet für sein Filesystem (im Gegensatz zu ext3, lilo warnt in diesem Fall auch). Ich denke hier liegt auch irgendwo der Hund begraben, nur wo? Btw. kann ich jederzeit mit dem Rescue System des Hosters das Raid als ext3 Formatieren, wieder vom eigenen Rescue kopieren + Lilo Aufruf und es funktioniert wieder. Hat noch irgend jemand eine Idee? Ist mein Vorhaben womöglich garnicht umsetzbar? Kann XFS kein RootFS für ein Software-Raid1 bieten? -- Markus Schulz "Ich dachte immer, UNIX ist was für Leute, denen es gefällt, auf einen Bildschirm zu starren, auf dem es aussieht, als hätte sich gerade ein Gürteltier auf der Tastatur gewälzt." (Stefan Schneider)
Re: xfs problem ?!
On Sun, Jan 29, 2006 at 10:03:05PM +0100, Harald Krammer wrote: > >>habt ihr schon einmal das problem gehabt, dass ihr "merkwürdige" > >>einträge in einem xfs file system gehabt habt ??? Ja, aber ewig her... > ist das erste mal, dass ich ein problem mit einem xfs-fs habe so > gibt es immer etwas neues Achnaja, haengt wohl auch mit der verwendeten XFS Treiber Version im Kernel ab. Ich hatte z.B. heftige Probleme, als ich einen G3 mit fehlerhafter dcbz opcode Implementierung hatte. Dennoch blieb das FS an sich konsistent erhalten - im Gegensatz zu ext3, wo sich das FS nach dem ersten Absturz schon nahezu komplett in /lost+found wiederfand... > [...] > >>ich kann den fehler werde mit den tools von xfs beheben, noch kann ich > >>das file löschen, verschieben usw. > > Ich wuerde schnellstens ein Backup von den Daten machen und dann z.B. > > mit badblocks scannen. Weiter gehts mit Speicher-Checks, Pruefen der > > Kabel, Anschluesse usw... > > Sieht mir sehr nach Problemen der Festplatte aus, insbesondere wenn der > > FS-Check keine Fehler meldet (oder eben Speicherprobleme). > backup habe ich eh schon, weil sonst wären meine nerven "blank". > der hd check meint, meine hd ist ok. Aber das muss letztendlich auch nicht heissen, dass es am FS liegt. Es kann auch das Motherboard sein, fehlerhafte Kabel zur Festplatte, Stromschwankungen im Netzteil... > einen speichertest wie memtest86 für i386 habe für powerpc noch nicht > gefunden. komisch sache... Ja, das ist korrekt. Ein PPC-Aequivalent zu memtest86 gibt es leider nicht. Hab ich mich auch schon drueber geaergert. > ich werde die partition neu formatieren und abwarten ob es noch einmal > passiert. meine anderen partitionen (/var, /home) haben keine probleme. Ansonsten sind die Entwickler auf [EMAIL PROTECTED] auch recht hilfsbereit. Mit xfs_db kann man da eventuell auch noch so etwas retten, wenn man weiss, wo man da an welcher Schraube drehen muss. > >>2.6.14.5 > >>arch: > >>powerpc g4 1ghz Hier laeuft XFS auf zwei PegasosII G4 ohne jegliche Probleme. > > Vllt. liegts auch am Prozessor *grins* > wer weiss - sollte es die playstation3 mit linux geben, ist nun ext3 die > richtige wahl ;) Ext3? *schauder*... -- Ciao...//Fon: 0381-2744150 Ingo \X/ SIP: [EMAIL PROTECTED] gpg pubkey: http://www.juergensmann.de/ij/public_key.asc -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: xfs problem ?!
Andreas Pakulat wrote: > On 29.01.06 14:58:33, Harald Krammer wrote: > >>habt ihr schon einmal das problem gehabt, dass ihr "merkwürdige" >>einträge in einem xfs file system gehabt habt ??? > > > Noe. > ist das erste mal, dass ich ein problem mit einem xfs-fs habe so gibt es immer etwas neues [...] >>ich kann den fehler werde mit den tools von xfs beheben, noch kann ich >>das file löschen, verschieben usw. > > > Ich wuerde schnellstens ein Backup von den Daten machen und dann z.B. > mit badblocks scannen. Weiter gehts mit Speicher-Checks, Pruefen der > Kabel, Anschluesse usw... > > Sieht mir sehr nach Problemen der Festplatte aus, insbesondere wenn der > FS-Check keine Fehler meldet (oder eben Speicherprobleme). > backup habe ich eh schon, weil sonst wären meine nerven "blank". der hd check meint, meine hd ist ok. einen speichertest wie memtest86 für i386 habe für powerpc noch nicht gefunden. komisch sache... ich werde die partition neu formatieren und abwarten ob es noch einmal passiert. meine anderen partitionen (/var, /home) haben keine probleme. > >>2.6.14.5 >>arch: >>powerpc g4 1ghz > > > Vllt. liegts auch am Prozessor *grins* wer weiss - sollte es die playstation3 mit linux geben, ist nun ext3 die richtige wahl ;) Harald -- Harald Krammer Brucknerstrasse 33 A - 4020 Linz AUSTRIA Mobil +43.(0) 664. 130 59 58 Mail: Harald.Krammer (at) hkr.at -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: xfs problem ?!
Harald Krammer schrieb: > habt ihr schon einmal das problem gehabt, dass ihr "merkwürdige" > einträge in einem xfs file system gehabt habt ??? Nein, bisher nicht. > ich kann den fehler werde mit den tools von xfs beheben, noch kann ich > das file löschen, verschieben usw. Hattest Du Stromausfall oder eine sonstige Unterbrechnung. Ansonsten, wie alt ist Deine Platte? Ich würde schnellstens die Daten darauf sichern und dann mal nach Festplattenfehlern suchen lassen (badblocks, smartctl oder das Tool des Herstellers), hatte ähnliches nur, wenn die Platte kurz vorm Sterben war (auch in Blick in die Logs könnte Aufschluss bringen). Cheers, Jan signature.asc Description: OpenPGP digital signature
Re: xfs problem ?!
On 29.01.06 14:58:33, Harald Krammer wrote: > habt ihr schon einmal das problem gehabt, dass ihr "merkwürdige" > einträge in einem xfs file system gehabt habt ??? Noe. > pluto:/usr/share/texmacs/TeXmacs/doc/devel/source# ls -al > total 244 > [...] > -rw-r--r-- 1 26124 root 1151063450482992792 Jun 29 1978 boxes.fr.tm > [...] Gibts den User? Ich vermute mal nicht. > Wow! PBytes - und meine HD hat nur 60 GB Hmm > ich kann den fehler werde mit den tools von xfs beheben, noch kann ich > das file löschen, verschieben usw. Ich wuerde schnellstens ein Backup von den Daten machen und dann z.B. mit badblocks scannen. Weiter gehts mit Speicher-Checks, Pruefen der Kabel, Anschluesse usw... Sieht mir sehr nach Problemen der Festplatte aus, insbesondere wenn der FS-Check keine Fehler meldet (oder eben Speicherprobleme). > 2.6.14.5 > arch: > powerpc g4 1ghz Vllt. liegts auch am Prozessor *grins* Andreas -- Your love life will be... interesting. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
xfs problem ?!
Hi, habt ihr schon einmal das problem gehabt, dass ihr "merkwürdige" einträge in einem xfs file system gehabt habt ??? pluto:/usr/share/texmacs/TeXmacs/doc/devel/source# ls -al total 244 [...] -rw-r--r-- 1 26124 root 1151063450482992792 Jun 29 1978 boxes.fr.tm [...] pluto:/usr/share/texmacs/TeXmacs/doc/devel/source# ls -lh [...] -rw-r--r-- 1 26124 root 1023P Jun 29 1978 boxes.fr.tm [...] Wow! PBytes - und meine HD hat nur 60 GB ich kann den fehler werde mit den tools von xfs beheben, noch kann ich das file löschen, verschieben usw. ideen willkommen! gruss, harald kernel: 2.6.14.5 arch: powerpc g4 1ghz debian testing -- Harald Krammer Brucknerstrasse 33 A - 4020 Linz AUSTRIA Mobil +43.(0) 664. 130 59 58 Mail: Harald.Krammer (at) hkr.at -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
XFS mount und sunit/swidth
Hallo Listige! Ein XFS auf einem (sw)raid0 ist laut /proc/mounts: /dev/md2 /out xfs rw,noatime,logbufs=8,sunit=128,swidth=256 0 0 und laut $ mount: /dev/md2 on /out type xfs (rw,noatime,logbufs=8) gemounted. # xfs_info /dev/md2 [so wurde es AFAIK auch erstellt] meta-data=/ isize=256agcount=8, agsize=30128 blks = sectsz=512 data = bsize=4096 blocks=240928, imaxpct=25 = sunit=16 swidth=32 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=16384, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=131072 blocks=0, rtextents= Kann mir ein Wissender den Unterschied zu sunit/swidth zwischen der xfs_info und /proc-Ausgabe erlaeren? Das mounten mit sunit=128 und swidth=256 muss irgendwie automatisch geschehen. Alle XFS's sind mit diesen Werten in /proc/mounts vohanden aber in der fstab sind keine derartigen Eintraege. Der Grund warum ich frage ist der, dass ja su und sw bestenfalls mit dem raid-chunksize uebereinstimmen sollten. Seh' ich das so richtig? Anm.: Mir ist das eben erst aufgefallen und es scheint mit einem der letzten Kernelupdates (nun 2.6.14.2) zusammenzuhaengen. Bei welchem es erstmals aufgetreten ist, kann ich leider nicht sagen. Was mir auch gerade auffaellt: Der ratio zwischen der /proc- und xfs_info-Ausgabe ist ja der selbe. Ist das eine blocks und das andere sectoren ..oder so? TIA, ritch -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: nfs und xfs
On 19.09.05 20:32:54, Andreas Pakulat wrote: > On 19.09.05 20:08:34, Gerald Holl wrote: > > Hallo! > > > > Ich habe auf meinem Server eine neue HDD eingebaut, zwei Partitionen > > erstellt und diese unter /ftp/dir1 und /ftp/dir2 gemountet (XFS > > Dateisystem). > > /ftp ist als NFS share freigegeben. > > > > Nun kann ich vom Client aus problemlos auf /ftp zugreifen, jedoch sind > > /ftp/dir und /ftp/dir2 leer (am Server jedoch nicht). > > > > Wo is da der Fehler? > > Vermutung: Der FTP-Server darf nicht über Partitionsgrenzen hinaus. Mist, man sollte nicht nur lesen sondern auch verstehen was der OP fragt :-( Andreas -- You are magnetic in your bearing. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: nfs und xfs
Thomas Antepoth wrote: >>/ftp ist als NFS share freigegeben. >>Nun kann ich vom Client aus problemlos auf /ftp zugreifen, jedoch sind >>/ftp/dir und /ftp/dir2 leer (am Server jedoch nicht). >>Wo is da der Fehler? > > > man 5 exports - Stichwort "nohide" > > [..] > nohide > This option is based on the option of the same name provided in IRIX NFS. > Normally, if a server exports two filesystems one of which is mounted on > the other, then the client will have to mount both filesystems explicitly > to get access to them. If it just mounts the parent, it will see an > empty directory at the place where the other filesystem is mounted. That > filesystem is "hidden". > [..] > > Entweder "nohide" oder beide Unterverzeichnisse explizit mounten. Danke, das war's. Funktioniert allerdings nur mit dem nfs-user-server und nicht mit dem nfs-kernel-server cheers, -- Gerald Holl http://holl.co.at -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: nfs und xfs
> /ftp ist als NFS share freigegeben. > Nun kann ich vom Client aus problemlos auf /ftp zugreifen, jedoch sind > /ftp/dir und /ftp/dir2 leer (am Server jedoch nicht). > Wo is da der Fehler? man 5 exports - Stichwort "nohide" [..] nohide This option is based on the option of the same name provided in IRIX NFS. Normally, if a server exports two filesystems one of which is mounted on the other, then the client will have to mount both filesystems explicitly to get access to them. If it just mounts the parent, it will see an empty directory at the place where the other filesystem is mounted. That filesystem is "hidden". [..] Entweder "nohide" oder beide Unterverzeichnisse explizit mounten. t++ -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: nfs und xfs
On 19.09.05 20:08:34, Gerald Holl wrote: > Hallo! > > Ich habe auf meinem Server eine neue HDD eingebaut, zwei Partitionen > erstellt und diese unter /ftp/dir1 und /ftp/dir2 gemountet (XFS > Dateisystem). > /ftp ist als NFS share freigegeben. > > Nun kann ich vom Client aus problemlos auf /ftp zugreifen, jedoch sind > /ftp/dir und /ftp/dir2 leer (am Server jedoch nicht). > > Wo is da der Fehler? Vermutung: Der FTP-Server darf nicht über Partitionsgrenzen hinaus. Andreas -- You will be recognized and honored as a community leader. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
nfs und xfs
Hallo! Ich habe auf meinem Server eine neue HDD eingebaut, zwei Partitionen erstellt und diese unter /ftp/dir1 und /ftp/dir2 gemountet (XFS Dateisystem). /ftp ist als NFS share freigegeben. Nun kann ich vom Client aus problemlos auf /ftp zugreifen, jedoch sind /ftp/dir und /ftp/dir2 leer (am Server jedoch nicht). Wo is da der Fehler? Debian Kernel 2.6.8 am Server und 2.6.13 am Client cheers, -- Gerald Holl http://holl.co.at -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
XFS debuggen
Tach allerseits, dummerweise hat mir der Smartd einen kaputten Sektor auf einer Platte gemeldet. Mit dem Badblock-Howto von der Smartmontools-Seite ist das ja kein Problem. Ausgenommen man benutzt ein anderes FS als ext2/3. Da ich XFS nutze und mich schon totgesucht habe nach Dokumentationen und die Man-Pages wahrlich kryptisch sind nun die Bitte an euch: Wie kann ich herausfinden welche Datei und welcher Inode zu dem kaputten Block gehört? Ich bin bis zum "Fourth Step" des Howtos gekommen und will nur den Sektor reparieren und die Datei aus dem Backup zurückspielen. Und falls zufällig jemand von euch den Ort brauchbarer Dokumentation dazu kennt, laßt es mich bitte wissen. Sollte ich wieder mal zu blöd gewesen sein $Suchmaschine zu benutzen, dann soll mir der Himmel auf den Kopf fallen! Shalom, -- Markus Meyer - encrypted email preferred -> GPG: B87120ED pgpgYMd2kb7zd.pgp Description: PGP signature
Re: XFS unter Windows lesen
Am Montag 16 Mai 2005 10:46 schrieb Michael Holtermann: > LÃsst sich XFS eigentlich unter Windows lesen? Also nicht Ãber Samba, > sondern direkt auf einer Dualboot-Maschine? Das einzige was ich finden konnte kann man hier nachlesen: http://www.osnews.com/comment.php?news_id=5516 ciao Gerhard
Re: XFS unter Windows lesen
Andreas Pakulat wrote: > Was ist so schwer mal "xfs unter windows lesen" in Google einzutippen? > Ich schaetze mal nicht. NatÃrlich nicht. Das Problem war nur, dass bei den Ergebnissen nichts dabei war. Sonst hÃtte ich hier nicht gefragt. Ich kann natÃrlich was Ãbersehen haben, aber das was ich gefunden habe waren Fontserver fÃr Windows und XFS fÃr Samba-Shares. GrÃÃe, Michael. -- Kein Wort im Evangelium ist in unseren Tagen mehr befolgt worden als das: Werdet wie die Kindlein. -- Georg Christoph Lichtenberg -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: XFS unter Windows lesen
hi, fÃr ext2/3 gibt es einen driver fÃr windows, bei xfs wÃrde ich leider nichts wissen. gruss, harald Michael Holtermann wrote: > Moin! > > Nachdem hier ausfÃrhlich Ãber Dateisysteme diskutiert wurde: > > LÃsst sich XFS eigentlich unter Windows lesen? Also nicht Ãber Samba, > sondern direkt auf einer Dualboot-Maschine? > > Danke! > GrÃÃe, Michael. > > -- Harald Krammer Brucknerstrasse 33 A - 4020 Linz AUSTRIA Mobil +43.(0) 664. 130 59 58 Mail: hkrammer at a1.net Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: XFS unter Windows lesen
Hi Michael, Soweit ich es noch weiß, unterstützt Windows nur sehr wenige Dateisysteme (NTFS, FAT, FAT32 und ich glaube die von Apple noch). Nur 100%ig festlegen will ich mich da nicht, da ich schon lange nichts mehr mit Windows zu tun habe. MFG Christian -- Sie benutzen immer noch Windows? Wie uncool Am Montag, den 16.05.2005, 10:46 +0200 schrieb Michael Holtermann: >Moin! > >Nachdem hier ausfürhlich über Dateisysteme diskutiert wurde: > >Lässt sich XFS eigentlich unter Windows lesen? Also nicht über Samba, >sondern direkt auf einer Dualboot-Maschine? > >Danke! >Grüße, Michael. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: XFS unter Windows lesen
On 16.Mai 2005 - 10:46:33, Michael Holtermann wrote: > Moin! > > Nachdem hier ausfürhlich über Dateisysteme diskutiert wurde: > > Lässt sich XFS eigentlich unter Windows lesen? Also nicht über Samba, > sondern direkt auf einer Dualboot-Maschine? Was ist so schwer mal "xfs unter windows lesen" in Google einzutippen? Ich schaetze mal nicht. Andreas -- Beware of a dark-haired man with a loud tie. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
XFS unter Windows lesen
Moin! Nachdem hier ausfÃrhlich Ãber Dateisysteme diskutiert wurde: LÃsst sich XFS eigentlich unter Windows lesen? Also nicht Ãber Samba, sondern direkt auf einer Dualboot-Maschine? Danke! GrÃÃe, Michael. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: ext3, XFS, Reiser
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Roth wrote: > Hallo Leute, > > ich muss mein System neu aufsetzen. Bisher verwende ich ext3 und bin > damit auch ganz zufrieden. Trotzdem wollte ich mal nachfragen was eure > Erfahrungen bzgl. Journaling FS sind. Im Netz gibt es so ein paar > Meinungen die ext3 als langsam beurteilen, Reiser erst in der Version > 4 als sehr gut. XFS gibt es schon sehr lange, es soll schnell sein und > auch robust. Der Linux Magazin Artikel zu diesem Thema ist schon 3 > Jahre alt. > > Der eine oder andere hier stand bestimmt auch schon vor dieser Frage. > Vielleicht koennt ihr bitte kurz eure Meinungen kundtun. laut mount (8) gibt es drei Arten, wie Journaling Dateisysteme mit Daten umgehen, bei ext3 und reiserfs kann man den gewünschten Modus beim mounten angeben: data=ordered: Standard bei ext3 und seit einiger Zeit auch bei reiserfs bei xfs nicht verfügbar Dateisystem- und Datenintegrität data=journal: nur bei ext3 die Daten kommen mit den Metadaten zusammen ins Journal manchmal schneller als data=ordered Dateisystem- und Datenintegrität data=writeback: Standard bzw. einzige Möglichkeit bei xfs und vor einiger Zeit bei reiserfs bei allen dreien verfügbar Dateisystem- aber keine Datenintegrität reiserfs und xfs können effizient mit kleinen Dateien umgehen. reiserfs und xfs kann man in gemountetem Zustand vergrößern. ext3 und reiserfs können verkleinert werden. Durch Verwendung von Bäumen sind reiserfs und xfs sehr schnell beim Suchen in und Auflisten von großen Verzeichnissen. Ich verwende ext2 mit -o sync für /boot, ext3 für / und reiserfs für /home, /usr, /var, beide mit data=ordered Timo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iQEcBAEBAgAGBQJCNEEoAAoJEEn74FOC+06tbQ0H/jBrrR17vbtAvI+DxP0kTD27 H84XsdOotNbGr0KeFwsS7QC8STK0md4oPENW5bMfYQXwRdryg8xXB9gg2Z34whPC XgIdZd7e2ryKDfBO+RIjRSz57mhOQbdc5QgSzR3eWxMV9Ii+rkjXan5LrAaZAQtd bc6cOzifjREK0iVqRiPgs/z2KuQDQbvM8XhAaG//SG/M6L4jbpl4p7UnWdQtjQIn +NBWJokvLdamMxiEuU65L+JX63L33ddy4O2xdnJN2+nAtwiztL3Gc/g2mwnYNGpd g8egCfa8P4dokFw3taCQ5QLcUaFztsMSAmEwhKp5mYf6qgGI90fsenP/O14DN8Y= =cRF1 -END PGP SIGNATURE- -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: ext3, XFS, Reiser
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Roth wrote: > Hallo Leute, > > ich muss mein System neu aufsetzen. Bisher verwende ich ext3 und bin > damit auch ganz zufrieden. Trotzdem wollte ich mal nachfragen was eure > Erfahrungen bzgl. Journaling FS sind. Im Netz gibt es so ein paar > Meinungen die ext3 als langsam beurteilen, Reiser erst in der Version > 4 als sehr gut. XFS gibt es schon sehr lange, es soll schnell sein und > auch robust. Der Linux Magazin Artikel zu diesem Thema ist schon 3 > Jahre alt. > > Der eine oder andere hier stand bestimmt auch schon vor dieser Frage. > Vielleicht koennt ihr bitte kurz eure Meinungen kundtun. laut mount (8) gibt es drei Arten, wie Journaling Dateisysteme mit Daten umgehen, bei ext3 und reiserfs kann man den gewünschten Modus beim mounten angeben: data=ordered: Standard bei ext3 und seit einiger Zeit auch bei reiserfs bei xfs nicht verfügbar Dateisystem- und Datenintegrität data=journal: nur bei ext3 die Daten kommen mit den Metadaten zusammen ins Journal manchmal schneller als data=ordered Dateisystem- und Datenintegrität data=writeback: Standard bzw. einzige Möglichkeit bei xfs und vor einiger Zeit bei reiserfs bei allen dreien verfügbar Dateisystem- aber keine Datenintegrität reiserfs und xfs können effizient mit kleinen Dateien umgehen. reiserfs und xfs kann man in gemountetem Zustand vergrößern. ext3 und reiserfs können verkleinert werden. Durch Verwendung von Bäumen sind reiserfs und xfs sehr schnell beim Suchen in und Auflisten von großen Verzeichnissen. Ich verwende ext2 mit -o sync für /boot, ext3 für / und reiserfs für /home, /usr, /var, beide mit data=ordered Timo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iQEcBAEBAgAGBQJCNDlqAAoJEEn74FOC+06t+sUH/iooOox9fZvZyGmmN8A1cJbT o1sBFNa5IypmkwdArGMlgw2SMoEhO9eM3cpU53F53gfL27QnlvSeXqYL0u3Ocrqt +k33bprQDjryhupCj/6mKsLRnjvDy+gxmRB//YjUr3PhBMEeipbNIDclJWwJ4Us1 pY/iShvKdfdFox7bZAoxk/NN+xnMJPD94klZPmRpnxW8x6lajo/7Tk5ghx2Bl/OV FnfQZPN8HlYLocAEAB9YxZbmSdeQkCm8uqJEzkhaXgGp+pmsxY6lI1eKeVkRXGWB yDvKB0Pn4HMKOxlN9UiIc82O4lPYGPESQuFC0fQKTUBmmYjJ6i0WDsFJFrwmvvk= =KSNH -END PGP SIGNATURE- -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: ext3, XFS, Reiser
Joerg Sommer <[EMAIL PROTECTED]> writes: > > Hast du mal dir_index probiert? Bei mir hat sich das auf dem Newsserver > echt bemerkbar gemacht. Nein, noch nicht, ist ein interessanter Tip. JÃrgen -- NO to software patents -- stop the European patents directive JÃrgen Stuber <[EMAIL PROTECTED]> http://www.jstuber.net/ gnupg key fingerprint = 2767 CA3C 5680 58BA 9A91 23D9 BED6 9A7A AF9E 68B4 -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: ext3, XFS, Reiser
Mario Holbe <[EMAIL PROTECTED]> writes: > Michelle Konzack <[EMAIL PROTECTED]> wrote: >> Denke, das md5sum das effektivste ist, um kaputte Dateien zu finden. > > Naja, da md5sum nunmal das gesamte File lesen muss, ist es naturgemaess > zumindest wenig effizient :) > Es gibt Heuristiken, die das abkuerzen, diff kennt z.B.: >--speed-large-files > Assume large files and many scattered small changes. > Offensichtlich kommt damit eine gewisse Unsicherheit ins Spiel - wie > gross die ist haengt halt davon ab, wie gut die Heuristik auf die > Realitaet passt :) Ich habe schon mal rsync (das per Default auch sowas macht) dabei erwischt, daà es die Subversion-DB nicht korrekt abgeglichen hat. Alles auÃer dem Inhalt war gleich geblieben, inkl. Datum. Da war Ãbrigens kein Absturz passiert, nur normale Benutzung. JÃrgen -- NO to software patents -- stop the European patents directive JÃrgen Stuber <[EMAIL PROTECTED]> http://www.jstuber.net/ gnupg key fingerprint = 2767 CA3C 5680 58BA 9A91 23D9 BED6 9A7A AF9E 68B4 -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: ext3, XFS, Reiser
Juergen Stuber <[EMAIL PROTECTED]> wrote: > Michelle Konzack <[EMAIL PROTECTED]> writes: >> Wird auch nicht schneller sein, denn die Zugriffe auf die Platte >> ändern sich ja nicht... > > Ext3 ist bekannt dafür, daß es auf Verzeichnissen mit vielen Dateien > langsam ist (lineare Suche), Reiser soll da schneller sein. Hast du mal dir_index probiert? Bei mir hat sich das auf dem Newsserver echt bemerkbar gemacht. Jörg. -- MCSE = Minesweeper Consultant & Solitaire Expert -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: ext3, XFS, Reiser
Am 2005-03-11 17:54:10, schrieb Jan Kesten: > Ingo Juergensmann wrote: > LOL ;-) Aber ich hab leider keinen gefunden, der mir eine Workstation > von der einen Firma als auch die andere spenden mag zum Vergleich (btw > wenn jemand eine Ultra 5 oder besser loswerden will - lasst es mich wissen). Kannst ja meine haben, vorausgesetzt, jemand schenkt mir eine Ultra 10 :-) Aber die 5 läuft einwandfrei... > Sollte mich das nun animieren, dass vielleicht mal zu tun? Aber was mach > ich wenn ich nicht Luke heisse? Werd mir vielleicht wirklich mal einen > großen Schluck gönnen und mal einen Blich in den Code werfen aus reiner > Neugier - mal sehen wann mich meine Programmierkenntnisse kläglich im > Stich lassen... :-) Ich bastele gerade an einem Security-Patch für ssmtp BUG #298054 > Hmm, das ist doch aber nicht offen IMHO? Aber wo Du sicher recht hast, > den Mut ein LVM auf mehreren Platten ohne RAID-5 hab ich auch noch nicht > aufgebracht. Im privaten leider als Software RAID, aber es tut seine > Dienste doch ganz gut :-) Aber die Rettung ist nah... ein Hardware-RAID > Controller ist schon greifabar neben mir im Regal *g* 3Ware ? > Cheers, > Jan Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: ext3, XFS, Reiser
Roland Sommer wrote: > FÃr statischen Dateien ist das sicherlich ein LÃsung, was ist aber > mit verÃnderlichen Dateien wie z.B. von einer Datenbank. XFS stellt > sicher, dass das Filesystem in Ordnung ist, einzelne Dateien aber > mÃglicherweise fehlerhaft sind. Demnach wÃrde ein fsck keine Fehler > melden, die Datenbank kÃnnte aber beschÃdigt oder inkonstistent sein. > Letzteres wÃre natrÃlich das grÃÃere Problem, weil man das ja nicht > unbedingt sofort erkennt. Da hast Du vollkommen recht - und helfen tut sicherlich nur ein gutes Backup und ein Transaktionslog (und/oder die Replikation der Datenbank auf einen zweiten Server, wenns 'ganz' sicher sein muss). So wie ich die Idee hinter ZFS gesehen hab, wollen die wohl aber genau auch solche Fehler erkennen wollen: - Provable data integrity ZFS protects all data with 64-bit checksums that detect and correct silent data corruption. <http://www.sun.com/2004-0914/feature/> Bleibt ja zu hoffen, dass auch ZFS mit in OpenSolaris eingeht und sich vielleicht einige andere die Idee auch abgucken. Im Prinzip sollte es ja auch erstmal genÃgen, wenn man wirklich zu jeder Datei eine Checksumme speichert und diese beim lesen prÃft und nach dem erfolgreichen Schreiben ins FS updated. Klar, das bringt mit Sicherheit Durchsatzverluste, aber als Option fÃr 'hochwertige' Daten ist das sicher zu verschmerzen. Aber ein fsck kÃnnte dann eben auch die PrÃfsummen testen und solche stillen Fehler entdecken. Cheers, Jan signature.asc Description: OpenPGP digital signature
Re: ext3, XFS, Reiser
* Roland Sommer <[EMAIL PROTECTED]>: > > Praktisch ist es so, dass man es erst bei Zugriff auf die Datei > > erkennt. > > Das äußert sich wie? > [...] > D.h. es war aufgrund von Fehlermeldungen oder Fehlfunktionen klar > erkennbar, dass irgendwelche Dateien defekt waren. Genau so. > Wäre kein größeres Problem, sofern man den Defekt eindeutig erkennen > kann. Was aber, wenn z.B. eine in Ordnung ist, der Inhalt aber Schaden > genommen hat oder eine letzte Änderung nicht geschrieben wurde? Soweit ich das verstanden habe, passiert das mit XFS nicht. Dann wäre die Datei voller binary-zeros. Das passiert immer dann, wenn eine Datei zum Schreiben geöffnet wurde, die Metadaten schon ins Journal geschrieben wurden, die Daten jedoch noch nicht. Aus Sicherheitsgründen füllt XFS die Datei dann mit "\0". Im Falle eines Stromausfalles müsste man also alle vor dem Absturz geöffneten Dateien nach Datenverlust überprüfen. Stellt man das nämlich erst nach dem Backup-Zyklus fest, sind die Daten verloren. Kai -- » http://www.glorybox.de/ PGP 1024D/594D4132 B693 5073 013F 7F56 5DCC D9C2 E6B5 448C 594D 4132
Re: ext3, XFS, Reiser
Ingo Juergensmann wrote: > Meine Abneigung gegen Sun ist ziemlich trivial: - ich finde deren > Design im Vergleich zu dem der SGIs geradezu haesslich - die > Tastaturen sind einfach nur schauderhaft vom Layout her... Also > vollkommen objektive Gruende... ;) LOL ;-) Aber ich hab leider keinen gefunden, der mir eine Workstation von der einen Firma als auch die andere spenden mag zum Vergleich (btw wenn jemand eine Ultra 5 oder besser loswerden will - lasst es mich wissen). > Staendig wird herumgelaestert, dass XFS kein shrinking kann, aber > niemand kommt auf Idee, da mal selber seine Nase in den vorhandenen > Source-Code zu stecken und es dann halt mal zu implementieren, obwohl > man ansonsten bei jeder noch so kleinen Gelegenheit ein UTSL an den > Kopf geschmissen bekommt... ;) Sollte mich das nun animieren, dass vielleicht mal zu tun? Aber was mach ich wenn ich nicht Luke heisse? Werd mir vielleicht wirklich mal einen groÃen Schluck gÃnnen und mal einen Blich in den Code werfen aus reiner Neugier - mal sehen wann mich meine Programmierkenntnisse klÃglich im Stich lassen... > Naja, wer solch eine Funktionalitaet braucht, kann ja auch zum CXFS > greifen. ;) Ich persoenlich kaeme z.B. nie auf die Idee, ein LVM > ueber mehrere Platten hinweg ohne (mindestens) ein RAID(5) zu > benutzen... Hmm, das ist doch aber nicht offen IMHO? Aber wo Du sicher recht hast, den Mut ein LVM auf mehreren Platten ohne RAID-5 hab ich auch noch nicht aufgebracht. Im privaten leider als Software RAID, aber es tut seine Dienste doch ganz gut :-) Aber die Rettung ist nah... ein Hardware-RAID Controller ist schon greifabar neben mir im Regal *g* > Naja, auf dem P200 dauert das so oder so schon was laenger... ;) Aber > der Effekt war der, dass scheinbar alle Files eine recht hohe > Fragmentierung bzw. Anzahl der extents aufwiesen (ca. 67, 48 oder > 27). Naja, bei groÃen Dateien ist das ja nicht so schlimm sondern eher normal. Und eigentlich sollte es nach dem fsr ja kleinere Zahlen von belegten extents geben. > Lustigerweise stelle ich allerdings gerade fest, dass das nicht die > Files auf dem Raid betrifft, sondern auf / *sehr* strange... ;) In der Tat - was liegt denn alles physikalisch unter / ? > Naja, mal weiterhin beobachten... In jedem Fall ;-) Weiss gar nicht, ob fsr auch die inode Nummer der aktuellen Datei mit ausgibt, so dass man mal forschen kann, welche Dateien das sind.. Cheers, Jan signature.asc Description: OpenPGP digital signature
Re: ext3, XFS, Reiser
* Ingo Juergensmann <[EMAIL PROTECTED]> wrote: > Ich wuesste nicht, wie man das generell erkennen sollte (also weder bei XFS > noch bei anderen FSen)? > Es sei denn, man vergleicht direkt mit einem vorhandenen und aktuellem > Backup und kopiert dann nur die Files zurueck, die das gleiche Datum, > Groesse, aber nicht den gleichen Inhalt haben... Für statischen Dateien ist das sicherlich ein Lösung, was ist aber mit veränderlichen Dateien wie z.B. von einer Datenbank. XFS stellt sicher, dass das Filesystem in Ordnung ist, einzelne Dateien aber möglicherweise fehlerhaft sind. Demnach würde ein fsck keine Fehler melden, die Datenbank könnte aber beschädigt oder inkonstistent sein. Letzteres wäre natrülich das größere Problem, weil man das ja nicht unbedingt sofort erkennt. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: ext3, XFS, Reiser
* Kai Weber <[EMAIL PROTECTED]> wrote: > Praktisch ist es so, dass man es erst bei Zugriff auf die Datei > erkennt. Das äußert sich wie? > Aus irgendeinem Grund betraf das bei mir immer Dateien, die beim > Hochfahren benötigt werden, was dann regelmäßig auf Reparieren oder > gar komplett Neumachen mittels Rescue-CD hinauslief. D.h. es war aufgrund von Fehlermeldungen oder Fehlfunktionen klar erkennbar, dass irgendwelche Dateien defekt waren. > Da wünschte ich mir etwas einfacheres, das nur die betroffenen > Dateien erkennt und austauscht (womit sich der Kreis deiner Frage > schließt und ich vielleicht mal ein Projekt starte). Wäre kein größeres Problem, sofern man den Defekt eindeutig erkennen kann. Was aber, wenn z.B. eine in Ordnung ist, der Inhalt aber Schaden genommen hat oder eine letzte Änderung nicht geschrieben wurde? > P.S. XFS hat gerade auf einer Partition eine 2. Chance bekommen. Hab bislang ext3 problemlos im Einsatz und wollte den neuen Server mit XFS testen. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: ext3, XFS, Reiser
Jan Kesten <[EMAIL PROTECTED]> wrote: > Michelle Konzack wrote: >> Denke, das md5sum das effektivste ist, um kaputte Dateien zu finden. > Weiss ja nicht, wie performant andere Checksummen gegen=C3=BCber md5 sind= Naja, heutzutage ist CPU an der Stelle eher nicht das Problem. Bottleneck ist vielmehr das I/O-System. Und drum wirst Du wohl kein performanteres Checksumming hinbekommen - selbst wenn es weniger CPU braeuchte. regards Mario -- We are the Bore. Resistance is futile. You will be bored. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: ext3, XFS, Reiser
On Fri, Mar 11, 2005 at 01:27:00PM +0100, Jan Kesten wrote: > > Erwaehnte ich schon, dass ich Sun nicht mag? Muss wohl daran liegen, > > dass ich aus der SGI-Ecke komme. Aber wenn OpenSolaris fuer die > > ODW/Pegasos Rechner fertig ist, werde ich mir das auch mal > > anschauen... > *g* Bin fast mit Sun aufgewachsen - mag vielleicht daran liegen, das ich > da einen Hang zu den sonnigen Leuten (ja, ich weiss auch, dass Sun in > dem Sinne hier nicht mit der Sonne zu tun hat *g*) her hab ;-) Und auch > zur Zeit auf der Arbeit mit denen zu tun hab... Meine Abneigung gegen Sun ist ziemlich trivial: - ich finde deren Design im Vergleich zu dem der SGIs geradezu haesslich - die Tastaturen sind einfach nur schauderhaft vom Layout her... Also vollkommen objektive Gruende... ;) > Hab aber auch man den Genuss gehabt, auf einer Origin 2000 zu > programmieren, das war richtig Spass (und das war auch der Zeitpunkt wo > ich XFS für mich entdeckt hab...) :-) > > Ganz einfach: Der Bedarf ist nicht da. Die Entwickler auf #xfs haben > > sich mal dahingehend geaeussert, dass man das Verkleinern durchaus > > auch implementieren koennte, wenn es ein (zahlender) Kunde wuensche. > Sollte vielleicht doch dort öfter mitlesen - hatte mir aber auch schon > soetwas gedacht, denn vom prinzipiellen Aufbau her sollte das bei XFS > eigentlich kein unlösbares Problem sein. Leider bin ich selbst nicht fit > genug mich damit mal zu beschäftigen.. Tja, das verstehe ich ja z.B. auch nicht... Staendig wird herumgelaestert, dass XFS kein shrinking kann, aber niemand kommt auf Idee, da mal selber seine Nase in den vorhandenen Source-Code zu stecken und es dann halt mal zu implementieren, obwohl man ansonsten bei jeder noch so kleinen Gelegenheit ein UTSL an den Kopf geschmissen bekommt... ;) > > Nur braucht es anscheinend niemand (ausser ein paar > > LVM-Linux-Freaks), also werden die wenigen Ressourcen, die man hat, > > nicht auf Features verschwendet, die eh niemand (Zahlendes) braucht. > Interessant ist einfach nur, dass man eine anfängliche Aufteilung des > vorhandenen Platzes vornehmen kann und danach dynamisch umverteilen. > Sprich wenn es in einem Bereich zum Engpass kommt, kann man einen > anderen verkleinern (ohne Umkopieren) und dann den anderen vergrößern - > dafür ist ja LVM da. Andererseits, kann man natürlich (so wie ich es > auch mache und daher auch fast nur wachsende Dateisysteme kenne) einfach > mit kleinen Bereichen anfangen und immer on-demand vergrößern. Nur das > zerstückelt natürlich die PE quer über eine Volume Group (und > unterschiedliche Platten u.U.), was wiederum ein Performance Problem > werden kann. Naja, wer solch eine Funktionalitaet braucht, kann ja auch zum CXFS greifen. ;) Ich persoenlich kaeme z.B. nie auf die Idee, ein LVM ueber mehrere Platten hinweg ohne (mindestens) ein RAID(5) zu benutzen... > >> Dafür ist die Baumreorganisation eine schöne Option, wenn man die > >> Zugriffszeiten optimieren will/muss. > > In der Tat... wobei ich da nun auf einem Raid irgendwie auf einen > > seltsamen Effekt gestossen bin, aber naja... > Lass mich nicht unwissend sterben - welche Effekte hattest Du denn > beobachten können? Mit ist aufgefallen, dass die Reorganisation auf > einem RAID-5-Verbund wesentlich langsamer ist als auf einer einzelnen > Platte für sich. Aber sonst? Naja, auf dem P200 dauert das so oder so schon was laenger... ;) Aber der Effekt war der, dass scheinbar alle Files eine recht hohe Fragmentierung bzw. Anzahl der extents aufwiesen (ca. 67, 48 oder 27). Lustigerweise stelle ich allerdings gerade fest, dass das nicht die Files auf dem Raid betrifft, sondern auf / *sehr* strange... ;) Naja, mal weiterhin beobachten... -- Ciao... // Ingo \X/ -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: ext3, XFS, Reiser
Michelle Konzack wrote: > Ich habe ein eigenes Backup Script was md5sum verwendet... Ist > natÃrlich ne Killer-LÃsung, besonderst wenn Du ein paar millionen > Dateien (maildir) hast. Leider - denn wenn ich daran denke, dass ich md5-Summen regelmÃÃig Ãber meinen gesammten Datenbestand berechnen lassen muss, autsch. Der schÃne Strom... Allein das komplette lesen des gesamten Datenbestands ist schon Overkill :-) > Denke, das md5sum das effektivste ist, um kaputte Dateien zu finden. Weiss ja nicht, wie performant andere Checksummen gegenÃber md5 sind, aber einen versuch wÃr das ja Wert, denn ich meine, eine kÃrzere Summe wÃrde es auch tun, denn 'Sicherheit' ist hier ja nicht oberstes Gebot. Wenn ich dann noch kurz an XFS denke, kÃme mir in den Sinn die Checksumme doch gleich als Extended Attribut mit an die Datei zu hÃngen. Dann noch einen Patch, der die prÃft.. Hmm... Cheers, Jan signature.asc Description: OpenPGP digital signature
Re: ext3, XFS, Reiser
Ingo Juergensmann wrote: > Das fsck ist bei XFS angenehm zuegig... :-) Das stimmt wohl :-) Aber eigentlich trifft das schon fast fÃr alle Journaling Dateisysteme zu.. Nur unter ext2 war das damals eine Krankheit und wirklich getraut, den Ãblichen Check nach n-Mounts abzuschalten hatte ich mich dann doch nicht.. > Erwaehnte ich schon, dass ich Sun nicht mag? Muss wohl daran liegen, > dass ich aus der SGI-Ecke komme. Aber wenn OpenSolaris fuer die > ODW/Pegasos Rechner fertig ist, werde ich mir das auch mal > anschauen... *g* Bin fast mit Sun aufgewachsen - mag vielleicht daran liegen, das ich da einen Hang zu den sonnigen Leuten (ja, ich weiss auch, dass Sun in dem Sinne hier nicht mit der Sonne zu tun hat *g*) her hab ;-) Und auch zur Zeit auf der Arbeit mit denen zu tun hab... Hab aber auch man den Genuss gehabt, auf einer Origin 2000 zu programmieren, das war richtig Spass (und das war auch der Zeitpunkt wo ich XFS fÃr mich entdeckt hab...) > Ganz einfach: Der Bedarf ist nicht da. Die Entwickler auf #xfs haben > sich mal dahingehend geaeussert, dass man das Verkleinern durchaus > auch implementieren koennte, wenn es ein (zahlender) Kunde wuensche. Sollte vielleicht doch dort Ãfter mitlesen - hatte mir aber auch schon soetwas gedacht, denn vom prinzipiellen Aufbau her sollte das bei XFS eigentlich kein unlÃsbares Problem sein. Leider bin ich selbst nicht fit genug mich damit mal zu beschÃftigen.. > Nur braucht es anscheinend niemand (ausser ein paar > LVM-Linux-Freaks), also werden die wenigen Ressourcen, die man hat, > nicht auf Features verschwendet, die eh niemand (Zahlendes) braucht. Interessant ist einfach nur, dass man eine anfÃngliche Aufteilung des vorhandenen Platzes vornehmen kann und danach dynamisch umverteilen. Sprich wenn es in einem Bereich zum Engpass kommt, kann man einen anderen verkleinern (ohne Umkopieren) und dann den anderen vergrÃÃern - dafÃr ist ja LVM da. Andererseits, kann man natÃrlich (so wie ich es auch mache und daher auch fast nur wachsende Dateisysteme kenne) einfach mit kleinen Bereichen anfangen und immer on-demand vergrÃÃern. Nur das zerstÃckelt natÃrlich die PE quer Ãber eine Volume Group (und unterschiedliche Platten u.U.), was wiederum ein Performance Problem werden kann. >> DafÃr ist die Baumreorganisation eine schÃne Option, wenn man die >> Zugriffszeiten optimieren will/muss. > In der Tat... wobei ich da nun auf einem Raid irgendwie auf einen > seltsamen Effekt gestossen bin, aber naja... Lass mich nicht unwissend sterben - welche Effekte hattest Du denn beobachten kÃnnen? Mit ist aufgefallen, dass die Reorganisation auf einem RAID-5-Verbund wesentlich langsamer ist als auf einer einzelnen Platte fÃr sich. Aber sonst? Cheers, Jan signature.asc Description: OpenPGP digital signature
Re: ext3, XFS, Reiser
Michelle Konzack <[EMAIL PROTECTED]> wrote: > Denke, das md5sum das effektivste ist, um kaputte Dateien zu finden. Naja, da md5sum nunmal das gesamte File lesen muss, ist es naturgemaess zumindest wenig effizient :) Es gibt Heuristiken, die das abkuerzen, diff kennt z.B.: --speed-large-files Assume large files and many scattered small changes. Offensichtlich kommt damit eine gewisse Unsicherheit ins Spiel - wie gross die ist haengt halt davon ab, wie gut die Heuristik auf die Realitaet passt :) regards Mario -- The social dynamics of the net are a direct consequence of the fact that nobody has yet developed a Remote Strangulation Protocol. -- Larry Wall -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: ext3, XFS, Reiser
Am 2005-03-11 12:03:25, schrieb Kai Weber: > Zu möglichen Strategien für das Erkennen siehe die anderen Antworten. > Praktisch ist es so, dass man es erst bei Zugriff auf die Datei erkennt. > > Aus irgendeinem Grund betraf das bei mir immer Dateien, die beim > Hochfahren benötigt werden, was dann regelmäßig auf Reparieren oder gar > komplett Neumachen mittels Rescue-CD hinauslief. Da wünschte ich mir > etwas einfacheres, das nur die betroffenen Dateien erkennt und > austauscht (womit sich der Kreis deiner Frage schließt und ich > vielleicht mal ein Projekt starte). Das ist doch kein problem, denn wenn Du ein Backup auf der gleichen Platte aber andere Partition hast, kannste Dir ein init-script basteln und ganz am Anfang positionieren. Allerdings solltest Du md5sum im path haben, also von /usr/bin nach /bin verschieben/umkopieren. Dann kannste die Backup-Partition mounten, die md5sum vergleichen und automatisch wieder herstellen. Erfordert aber konsequentes Backup von /bin /boot /dev /etc /lib /root (eventuell) /sbin > Kai Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: ext3, XFS, Reiser
* Ingo Juergensmann <[EMAIL PROTECTED]>: > > Aber bis dahin bleib ich bei XFS - mit dem einzigen Abstrich, dass man > > es nicht verkleinern kann (wobei ich immer mal fragen wollte, warum > > eigentlich nicht). > > Ganz einfach: Der Bedarf ist nicht da. > [...] > Und mal ehrlich gesagt: *ich* hab eigentlich noch kein FS gesehen, was immer > kleiner wurde. Vielmehr kenne ich nur FS, die nur eine Groessenveraenderung > kennen: nach oben! Falls man eine Partition zu groß bemessen hat und diesen Platz für eine andere Partition nutzen möchte, ist Verkleinern schon praktisch, weil das dann ganz ohne Umkopieren funktioniert. Kai -- » http://www.glorybox.de/ PGP 1024D/594D4132 B693 5073 013F 7F56 5DCC D9C2 E6B5 448C 594D 4132
Re: ext3, XFS, Reiser
* Roland Sommer <[EMAIL PROTECTED]>: > Kann man auch erkennen bzw. wird man informiert, welche Datei(en) defekt > ist/sind? Oder anders gefragt: Wie erfährt man, welche Datei(en) zurück > gesichert werden muss/müssen? Zu möglichen Strategien für das Erkennen siehe die anderen Antworten. Praktisch ist es so, dass man es erst bei Zugriff auf die Datei erkennt. Aus irgendeinem Grund betraf das bei mir immer Dateien, die beim Hochfahren benötigt werden, was dann regelmäßig auf Reparieren oder gar komplett Neumachen mittels Rescue-CD hinauslief. Da wünschte ich mir etwas einfacheres, das nur die betroffenen Dateien erkennt und austauscht (womit sich der Kreis deiner Frage schließt und ich vielleicht mal ein Projekt starte). P.S. XFS hat gerade auf einer Partition eine 2. Chance bekommen. Kai -- » http://www.glorybox.de/ PGP 1024D/594D4132 B693 5073 013F 7F56 5DCC D9C2 E6B5 448C 594D 4132
Re: ext3, XFS, Reiser
Am 2005-03-11 10:49:33, schrieb Ingo Juergensmann: > > Kann man auch erkennen bzw. wird man informiert, welche Datei(en) defekt > > ist/sind? Oder anders gefragt: Wie erfährt man, welche Datei(en) zurück > > gesichert werden muss/müssen? > > Ich wuesste nicht, wie man das generell erkennen sollte (also weder bei XFS > noch bei anderen FSen)? > Es sei denn, man vergleicht direkt mit einem vorhandenen und aktuellem > Backup und kopiert dann nur die Files zurueck, die das gleiche Datum, > Groesse, aber nicht den gleichen Inhalt haben... Ich habe ein eigenes Backup Script was md5sum verwendet... Ist natürlich ne Killer-Lösung, besonderst wenn Du ein paar millionen Dateien (maildir) hast. Aber ich habe jeden Montag morgen ein Full-Backup und Dienstag bis Sonntag jeweils ein Inkremental-Backup. Das Dateisystem wird exact in das Backup kopiert und die Dateien bei Bedarf komprmiert. Ist ein einfache ( :-(=) ) BASH Script und kaputte Dateien können einfach wieder hergestellt werden. Denke, das md5sum das effektivste ist, um kaputte Dateien zu finden. Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: ext3, XFS, Reiser
On Fri, Mar 11, 2005 at 10:26:05AM +0100, Roland Sommer wrote: > * Ingo Juergensmann <[EMAIL PROTECTED]> wrote: > > Ja eben... Datei kaputt? Backup hernehmen und restoren... > Kann man auch erkennen bzw. wird man informiert, welche Datei(en) defekt > ist/sind? Oder anders gefragt: Wie erfährt man, welche Datei(en) zurück > gesichert werden muss/müssen? Ich wuesste nicht, wie man das generell erkennen sollte (also weder bei XFS noch bei anderen FSen)? Es sei denn, man vergleicht direkt mit einem vorhandenen und aktuellem Backup und kopiert dann nur die Files zurueck, die das gleiche Datum, Groesse, aber nicht den gleichen Inhalt haben... -- Ciao... // Ingo \X/ -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: ext3, XFS, Reiser
* Ingo Juergensmann <[EMAIL PROTECTED]> wrote: > Ja eben... Datei kaputt? Backup hernehmen und restoren... Kann man auch erkennen bzw. wird man informiert, welche Datei(en) defekt ist/sind? Oder anders gefragt: Wie erfährt man, welche Datei(en) zurück gesichert werden muss/müssen? -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: ext3, XFS, Reiser
On Thu, Mar 10, 2005 at 04:29:28PM +0100, Ingo Juergensmann wrote: > On Thu, Mar 10, 2005 at 04:13:45PM +0100, Kai Weber wrote: Hallo Ingo, danke fuer Deine Erfahrungen mit ext3 und XFS. > Kurzum: Die Frage nach dem richtigen Dateisystem muss jeder fuer sich selber > beantworten und ist genauso ueberfluessig wie die Frage nach dem richtigen > Editor. Ich habe lediglich um Meinungen und Erfahrungen gebeten. Das hast Du ja auch getan, nochmal recht herzlichen Dank dafuer. Ein Erfahrungsaustausch ist IMHO sehr wertvoll und vor allem zeitsparend. Ich habe keine Zeit alle Dateisysteme zu testen um schliesslich nach einigen Monaten und x Stunden Arbeit, die Erfahrungen anderer zu bestaetigen. Das mag bei Dir anders sein. Mit eurer Information kann ich nun die Frage nach dem richtigen Dateisystem fuer mich beantworten. Danke an alle. Gruss Christian -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: ext3, XFS, Reiser
On Thu, Mar 10, 2005 at 05:56:32PM +0100, Jan Kesten wrote: > > Das binary zero Problem ist eigentlich Geschichte. Muss man sich > > heutzutage eigentlich keinen Kopf drum machen. > Ich hatte das Problem genau einmal bisher - und wie ja auch schon Ich hatte das durchaus massiv frueher. Damals trat das aber auch bei einem ordnungsgemaessen Shutdown auf, nicht "nur" bei einem Crash... Ich glaube, es sollte einleuchtend sein, dass bei einem Crash alles moegliche mit einer Datei passieren kann und man ganz einfach nichts dagegen machen kann. > erwähnt, soll das Journal ja nur dafür sorgen, dass das Dateisystem und > nicht der Inhalt konsistent bleibt. Dieses Feature werden all die zu > schätzen wissen, die mal nach einem Reboot einen fsck auf langsamen > Systemen haben ein ext2 reparieren lassen müssen (irgendwie hab ich > damit mal 30 Stunden verbraten). Das fsck ist bei XFS angenehm zuegig... :-) > > Schoen. Dafuer zersemmelt ext3 mir in aller Regelmaessigkeit das FS > > beyond repair. Was ist besser? Ein paar *eventuell* kaputte Dateien > > oder ein komplettes Dateisystem in lost+found? Ext3 hat sich > > jedenfalls fuer *mich* als total instabil erwiesen. XFS hingegen > > funktionierte auch unter widrigsten Bedingungen zufriedenstellend. > > Das ist mir allerdings sowohl mit ext2, ext3 und ReiserFS passiert. Noch > nie mit einem XFS (oder UFS unter Solaris). Meistens verwende ich einen > Mix aus beidem, die großen Datenparitionen wie /srv und /home sind XFS > und der Rest ext3 - das funktioniert sauber und prima schon seit langem. > Und überlebte auch diverse Abstürze und Stromausfälle.. Ich benutze fast ausschliesslich XFS. Nur gewisse Archs mit gewissen 2.2er Kernel sind noch ausserhalb von /boot mit ext2/3 unterwegs... > Gespannt bin ich (vorsicht OT) auf das neue ZFS von Solaris 10, welches > ja neben dem Journal und der Dateisystemintegrität auch noch > Storagepools und Daten(!)integrität bringen soll (und eine geniale > Architektur, so dass man kein LVM etc. mehr braucht). Einen kleinen > Blick durfte ich mal erhaschen... Vielleicht kommt das ja im Zuge von > OpenSolaris dann ja auch mal in die Linux-Welt. Erwaehnte ich schon, dass ich Sun nicht mag? Muss wohl daran liegen, dass ich aus der SGI-Ecke komme. Aber wenn OpenSolaris fuer die ODW/Pegasos Rechner fertig ist, werde ich mir das auch mal anschauen... > Aber bis dahin bleib ich bei XFS - mit dem einzigen Abstrich, dass man > es nicht verkleinern kann (wobei ich immer mal fragen wollte, warum > eigentlich nicht). Ganz einfach: Der Bedarf ist nicht da. Die Entwickler auf #xfs haben sich mal dahingehend geaeussert, dass man das Verkleinern durchaus auch implementieren koennte, wenn es ein (zahlender) Kunde wuensche. Nur braucht es anscheinend niemand (ausser ein paar LVM-Linux-Freaks), also werden die wenigen Ressourcen, die man hat, nicht auf Features verschwendet, die eh niemand (Zahlendes) braucht. Und mal ehrlich gesagt: *ich* hab eigentlich noch kein FS gesehen, was immer kleiner wurde. Vielmehr kenne ich nur FS, die nur eine Groessenveraenderung kennen: nach oben! > Dafür ist die Baumreorganisation eine schöne Option, > wenn man die Zugriffszeiten optimieren will/muss. In der Tat... wobei ich da nun auf einem Raid irgendwie auf einen seltsamen Effekt gestossen bin, aber naja... -- Ciao... // Ingo \X/ -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: ext3, XFS, Reiser
On Thu, Mar 10, 2005 at 04:58:47PM +0100, Helmut Wollmersdorfer wrote: > [XFS] > >Das binary zero Problem ist eigentlich Geschichte. Muss man sich heutzutage > >eigentlich keinen Kopf drum machen. > D.h. mit Kernel 2.8.6 müste XFS problemlos laufen? Zumindest tat es das hier lange Zeit lang (auf etlichen Rechnern). > >Was ist besser? Ein paar *eventuell* kaputte Dateien oder ein komplettes > >Dateisystem in lost+found? Ext3 hat sich jedenfalls fuer *mich* als total > >instabil erwiesen. XFS hingegen funktionierte auch unter widrigsten > >Bedingungen zufriedenstellend. > Na dann werde ich XFS mal ausprobieren. Mein apt-proxy müsste eh auf > meinen DRBD-Cluster. Nachdem apt-proxy zeitweise absemmelt, und > apt-proxy keine unwiederbringlichen Daten enthält, wär das ein gutes > Testobjekt. S. meine andere Mail: Die Qualitaet eines FS mache *ich* anhand des Verhaltens im Falle eines Fehlers fest - und jedes FS hat/macht Fehler! -- Ciao... // Ingo \X/ -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: ext3, XFS, Reiser
On Thu, Mar 10, 2005 at 05:07:40PM +0100, Kai Weber wrote: > http://marc.free.net.ph/message/20050211.121829.ad580ed2.en.html > Kurz: XFS garantiert nur Dateisystemkonsistenz. Die Datensicherheit > kann nur von Backups, RAID, UPS usw. kommen. Ja eben... Datei kaputt? Backup hernehmen und restoren... Allemal besser, ein paar vereinzelte Dateien restoren zu muessen, als nahezu das komplette FS... ;) > > Kurzum: Die Frage nach dem richtigen Dateisystem muss jeder fuer sich selber > > beantworten und ist genauso ueberfluessig wie die Frage nach dem richtigen > > Editor. > Da hast du natürlich recht. Dennoch fehlen einfach an manchen Stellen > die notwendigen Informationen, die zur Beantwortung der Frage notwendig > sind. Und nach denen darf man gerne hier Fragen, denke ich. Klar darf man. Nur ob man die gewuenschte Antwort erhaelt ist mehr als fraglich, da jeder seine eigenen Erfahrungen gemacht hat. Ergo muss man selber seine eigenen Erfahrungen sammeln. Meine Erfahrung besagt: Es gibt kein absolut sicheres FS. Die Qualitaet eines FS macht sich vor allem dann bemerkbar, *wenn* es zum GAU kommt. Und *jedes* FS wird frueher oder spaeter einen solchen GAU haben. Wie man dann allerdings an seine Daten herankommt, ist sehr unterschiedlich. Ext3 faellt zurueck auf ext2 und macht einen fsck.ext2/3 Run, was darin enden kann, dass das FS verschlimmbessert wird und quasi das gesamte FS hinueber ist. Mit XFS hab ich selbst bei RAM-Fehler und badblocks auf der Platte noch *sehr* gute Ergebnisse gehabt. Es waren Dateien kaputt, aber das FS war eigentlich immer weitestgehend les- und benutzbar, eventuell erst nach einem xfs_repair -L oder ein paar xfs_db Tricks, aber ich hatte nie einen groesseren Datenverlust. Selbst nicht mit defekter Hardware ueber Monate hinweg... Momentan vertraue ich in dieser Hinsicht nur zwei Filesystemen meine Daten an, da das worst case scenario bei beiden gute Ergebnisse bringt: XFS und AmigaFFS. :-) -- Ciao... // Ingo \X/ -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: ext3, XFS, Reiser
Salüt Christian, Christian Roth wrote: > ich muss mein System neu aufsetzen. Bisher verwende ich ext3 und bin > damit auch ganz zufrieden. Trotzdem wollte ich mal nachfragen was eure > Erfahrungen bzgl. Journaling FS sind. Mit einem XFS root hat sich auf meinem iBook der Shutdown (/etc/init.d/umountfs) gelegentlich aufgehängt. Genauer: der Remount-ro-Syscall hing. Mit ext3-Root keine Probleme mehr. Nikolaus -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: ext3, XFS, Reiser
On 2005-03-10 17:07:40 +0100, Kai Weber wrote: > http://marc.free.net.ph/message/20050211.121829.ad580ed2.en.html > > Kurz: XFS garantiert nur Dateisystemkonsistenz. Die Datensicherheit > kann nur von Backups, RAID, UPS usw. kommen. Man sollte aber auch erwähnen, das alle Journalled Filesystems in erster Linie nur die Dateisystemkonsistenz sicherstellen sollen. Michael -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: ext3, XFS, Reiser
Hallo Ingo, > Kurzum: Die Frage nach dem richtigen Dateisystem muss jeder fuer sich > selber beantworten und ist genauso ueberfluessig wie die Frage nach > dem richtigen Editor. da schlieÃe ich mich doch gleich erstmal an - denn das gibt eh eine Diskussion ohne Ende ;-) > Das binary zero Problem ist eigentlich Geschichte. Muss man sich > heutzutage eigentlich keinen Kopf drum machen. Ich hatte das Problem genau einmal bisher - und wie ja auch schon erwÃhnt, soll das Journal ja nur dafÃr sorgen, dass das Dateisystem und nicht der Inhalt konsistent bleibt. Dieses Feature werden all die zu schÃtzen wissen, die mal nach einem Reboot einen fsck auf langsamen Systemen haben ein ext2 reparieren lassen mÃssen (irgendwie hab ich damit mal 30 Stunden verbraten). > Schoen. Dafuer zersemmelt ext3 mir in aller Regelmaessigkeit das FS > beyond repair. Was ist besser? Ein paar *eventuell* kaputte Dateien > oder ein komplettes Dateisystem in lost+found? Ext3 hat sich > jedenfalls fuer *mich* als total instabil erwiesen. XFS hingegen > funktionierte auch unter widrigsten Bedingungen zufriedenstellend. Das ist mir allerdings sowohl mit ext2, ext3 und ReiserFS passiert. Noch nie mit einem XFS (oder UFS unter Solaris). Meistens verwende ich einen Mix aus beidem, die groÃen Datenparitionen wie /srv und /home sind XFS und der Rest ext3 - das funktioniert sauber und prima schon seit langem. Und Ãberlebte auch diverse AbstÃrze und StromausfÃlle.. Gespannt bin ich (vorsicht OT) auf das neue ZFS von Solaris 10, welches ja neben dem Journal und der DateisystemintegritÃt auch noch Storagepools und Daten(!)integritÃt bringen soll (und eine geniale Architektur, so dass man kein LVM etc. mehr braucht). Einen kleinen Blick durfte ich mal erhaschen... Vielleicht kommt das ja im Zuge von OpenSolaris dann ja auch mal in die Linux-Welt. Aber bis dahin bleib ich bei XFS - mit dem einzigen Abstrich, dass man es nicht verkleinern kann (wobei ich immer mal fragen wollte, warum eigentlich nicht). DafÃr ist die Baumreorganisation eine schÃne Option, wenn man die Zugriffszeiten optimieren will/muss. Cheers, Jan signature.asc Description: OpenPGP digital signature
Re: ext3, XFS, Reiser
Ingo Juergensmann wrote: [XFS] Das binary zero Problem ist eigentlich Geschichte. Muss man sich heutzutage eigentlich keinen Kopf drum machen. D.h. mit Kernel 2.8.6 müste XFS problemlos laufen? Was ist besser? Ein paar *eventuell* kaputte Dateien oder ein komplettes Dateisystem in lost+found? Ext3 hat sich jedenfalls fuer *mich* als total instabil erwiesen. XFS hingegen funktionierte auch unter widrigsten Bedingungen zufriedenstellend. Na dann werde ich XFS mal ausprobieren. Mein apt-proxy müsste eh auf meinen DRBD-Cluster. Nachdem apt-proxy zeitweise absemmelt, und apt-proxy keine unwiederbringlichen Daten enthält, wär das ein gutes Testobjekt. Helmut Wollmersdorfer -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: ext3, XFS, Reiser
* Ingo Juergensmann <[EMAIL PROTECTED]>: > Das binary zero Problem ist eigentlich Geschichte. Muss man sich heutzutage > eigentlich keinen Kopf drum machen. Da ich endlich einen Namen für das Problem habe, habe ich gleich einmal gesucht und einen sehr erhellenden Thread auf der XFS-Mailingliste gefunden. Er beginnt hier: http://marc.free.net.ph/message/20050211.121829.ad580ed2.en.html Kurz: XFS garantiert nur Dateisystemkonsistenz. Die Datensicherheit kann nur von Backups, RAID, UPS usw. kommen. > Was ist besser? Ein paar *eventuell* kaputte Dateien oder ein komplettes > Dateisystem in lost+found? Ext3 hat sich jedenfalls fuer *mich* als total > instabil erwiesen. XFS hingegen funktionierte auch unter widrigsten > Bedingungen zufriedenstellend. > > Kurzum: Die Frage nach dem richtigen Dateisystem muss jeder fuer sich selber > beantworten und ist genauso ueberfluessig wie die Frage nach dem richtigen > Editor. Da hast du natürlich recht. Dennoch fehlen einfach an manchen Stellen die notwendigen Informationen, die zur Beantwortung der Frage notwendig sind. Und nach denen darf man gerne hier Fragen, denke ich. Kai -- » http://www.glorybox.de/ PGP 1024D/594D4132 B693 5073 013F 7F56 5DCC D9C2 E6B5 448C 594D 4132
Re: ext3, XFS, Reiser
On Thu, Mar 10, 2005 at 04:13:45PM +0100, Kai Weber wrote: > Ich kann die Erfahrungen von Eduard leider bestätigen. Ich kann das nicht (in diesem Ausmass) bestaetigen. > XFS verursachte > bei Abstürzen Datenmüll in Dateien. Dies waren Dateien, in die zuletzt > geschrieben wurde. Wenn ich mich recht erinnere, waren die Dateien dann > voller "\0". Das binary zero Problem ist eigentlich Geschichte. Muss man sich heutzutage eigentlich keinen Kopf drum machen. > Ich verwende nun ausschließlich ext3 auf allen Partitionen. Das > entscheidende Kriterium für mich war -- neben der spürbar besseren > Stabilität -- dass man ext3-Partitionen vergrößern _und_ verkleinern > kann. Schoen. Dafuer zersemmelt ext3 mir in aller Regelmaessigkeit das FS beyond repair. Was ist besser? Ein paar *eventuell* kaputte Dateien oder ein komplettes Dateisystem in lost+found? Ext3 hat sich jedenfalls fuer *mich* als total instabil erwiesen. XFS hingegen funktionierte auch unter widrigsten Bedingungen zufriedenstellend. Kurzum: Die Frage nach dem richtigen Dateisystem muss jeder fuer sich selber beantworten und ist genauso ueberfluessig wie die Frage nach dem richtigen Editor. -- Ciao... // Ingo \X/ -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: ext3, XFS, Reiser
* Paul Puschmann <[EMAIL PROTECTED]>: > Wann sind den die Files defekt gewesen? nach einem Reboot, im Betrieb, > nach einem Absturz / Stromausfall, war es sicher kein User-Fehler, ...? > > Die Beschreibung ist einfach unzureichend. Da brauchst du mich nicht > anzumeckern, sondern kannst das ganz neutral schreiben. Ich kann die Erfahrungen von Eduard leider bestätigen. XFS verursachte bei Abstürzen Datenmüll in Dateien. Dies waren Dateien, in die zuletzt geschrieben wurde. Wenn ich mich recht erinnere, waren die Dateien dann voller "\0". Ich verwende nun ausschließlich ext3 auf allen Partitionen. Das entscheidende Kriterium für mich war -- neben der spürbar besseren Stabilität -- dass man ext3-Partitionen vergrößern _und_ verkleinern kann. Wenn jemand JFS ausprobiert oder benutzt würde mich interessieren, ob die Unverträglichkeiten hinsichtlich UTF-8-Dateinamen verschwunden sind. Kai -- » http://www.glorybox.de/ PGP 1024D/594D4132 B693 5073 013F 7F56 5DCC D9C2 E6B5 448C 594D 4132
Re: ext3, XFS, Reiser
Michelle Konzack <[EMAIL PROTECTED]> writes: > Am 2005-03-09 10:13:29, schrieb Juergen Stuber: >> >> Im Moment habe ich hier vermutlich ein Performance-Problem mit Ext3: >> >> - 45GB Backup von Backuppc erstellt >> - ca 1.000.000 Dateien >> - gut 200 Dateien pro Verzeichnis >> >> Mein erster Versuch das mit Tar auf eine neue Ext3-Partition zu kopieren >> hÃtte geschÃtzt ca 10h gedauert (= USB 1.1-Performance :-( ) und wurde > > 1.28 MByte/Sekunde ? > > Ich kenne ja Deine Hardware configuration nicht, aber sowas habe > ich auch erlebt, als ich keinen anderen IDE-Steckplatz zur verfÃgung > hatte, wie hdb. Tarr muà ha auf jede der 1.000.000 Datein zugreifen > und dann gleichzeitig auf ne ander Partition schreiben... > > Das kann gewaltigen Ãrger geben auch wenn Deine Platte im seriellen > Zugrif 60 MB macht. Beim mir ist das Problem bei zwei Platten > aufgetaucht die am gleichen Controller hÃngen... Die Quellplatte war PATA und die Zielplatte SATA. Ich nehme mal an, daà das getrennte Controller sind, und andere Platten gab es nicht. Das Tarfile nach /dev/null schicken geht auch nicht wesentlich schneller. > Wird auch nicht schneller sein, denn die Zugriffe auf die Platte > Ãndern sich ja nicht... Ext3 ist bekannt dafÃr, daà es auf Verzeichnissen mit vielen Dateien langsam ist (lineare Suche), Reiser soll da schneller sein. > Ich mache abundzu Backups von meinem FileServer auf ne USB 2.0 Platte, Habe ich auch vor, und dann woanders lagern, fÃr den Extremfall. Leider ist die alte 40GB-Notebookplatte dafÃr schon wieder etwas zu klein. JÃrgen -- NO to software patents -- stop the European patents directive JÃrgen Stuber <[EMAIL PROTECTED]> http://www.jstuber.net/ gnupg key fingerprint = 2767 CA3C 5680 58BA 9A91 23D9 BED6 9A7A AF9E 68B4 -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: ext3, XFS, Reiser
Michelle Konzack wrote: > Am 2005-03-09 12:24:54, schrieb Paul Puschmann: > > >>Mir ist schon klar, dass das ein K.O.-Kriterium ist. >>Da ich aber noch keine dieser Fehler hatte, würde ich natürlich gerne >>wissen, wie die zustande gekommen sind. >> >>Wann sind den die Files defekt gewesen? nach einem Reboot, im Betrieb, > > Wie oft rebootest Du ? Auf einem Laptop oder einer Workstation wohl häufiger... > > Also bei mir war es mitten im Betrieb... > > XFS wird fon SGI auf großen FileServern eingesetzt, weshalb ich es > auf meine 1,2T FileServer (3Ware Raid-5 mit 4 mal 400 GByte) ebenfals > einsetzen wollte... Aber wenn Du dann 400 GByte an Sourcecodes drauf > hast und laufen der Compiler abbricht, weil sich eine Datei verändert > hat, finde ich das nicht besonderst lustig. > Na wenns wirklich am FS liegt... ist es schon fies. Paul -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: ext3, XFS, Reiser
Am 2005-03-09 10:25:33, schrieb Joerg Friedrich: > Juergen Stuber schrieb am Mittwoch, 09. März 2005 um 10:13:29 +0100: > > hätte geschätzt ca 10h gedauert (= USB 1.1-Performance :-( ) und wurde > Was hat Dein Problem jetzt mit Ext3 zutun? Du schreibst doch selbst, > dass es an USB1.1 liegt. Das kann halt nicht mehr als 12Mbit/s brutto, > selbst bei nicht erreichbarem Brutto-Durchsatz brauchst Du mehr als 8 > 1/2 Stunden, um 45GB über USB1.1 zu transprotieren. Er sagte das es USB 1.1 Performance entspricht ! Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: ext3, XFS, Reiser
Am 2005-03-09 10:13:29, schrieb Juergen Stuber: > Hallo Christian, > das würde mich auch mal interessieren. > > Im Moment habe ich hier vermutlich ein Performance-Problem mit Ext3: > > - 45GB Backup von Backuppc erstellt > - ca 1.000.000 Dateien > - gut 200 Dateien pro Verzeichnis > > Mein erster Versuch das mit Tar auf eine neue Ext3-Partition zu kopieren > hätte geschätzt ca 10h gedauert (= USB 1.1-Performance :-( ) und wurde 1.28 MByte/Sekunde ? Ich kenne ja Deine Hardware configuration nicht, aber sowas habe ich auch erlebt, als ich keinen anderen IDE-Steckplatz zur verfügung hatte, wie hdb. Tarr muß ha auf jede der 1.000.000 Datein zugreifen und dann gleichzeitig auf ne ander Partition schreiben... Das kann gewaltigen Ärger geben auch wenn Deine Platte im seriellen Zugrif 60 MB macht. Beim mir ist das Problem bei zwei Platten aufgetaucht die am gleichen Controller hängen... > deshalb erst mal abgebrochen. Jetzt wird die neue Partition wohl > stattdessen ein Reiser3 werden, oder hat jemand einen besseren Vorschlag? > Stabilität ist mir wichtiger als die letzten 10% Performance. Wird auch nicht schneller sein, denn die Zugriffe auf die Platte ändern sich ja nicht... Ich mache abundzu Backups von meinem FileServer auf ne USB 2.0 Platte, indem ich die ganzen Source-Verzeichnisse einzeln zusammen tarzipe. Ich komme dabei auf rund 13 MByte/Sekunde. > Ansonsten hatte ich bisher keine Probleme mit Ext3, und nie Datenverlust. Ebenso > Jürgen Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: ext3, XFS, Reiser
Am 2005-03-09 12:24:54, schrieb Paul Puschmann: > Mir ist schon klar, dass das ein K.O.-Kriterium ist. > Da ich aber noch keine dieser Fehler hatte, würde ich natürlich gerne > wissen, wie die zustande gekommen sind. > > Wann sind den die Files defekt gewesen? nach einem Reboot, im Betrieb, Wie oft rebootest Du ? > nach einem Absturz / Stromausfall, war es sicher kein User-Fehler, ...? Also bei mir war es mitten im Betrieb... XFS wird fon SGI auf großen FileServern eingesetzt, weshalb ich es auf meine 1,2T FileServer (3Ware Raid-5 mit 4 mal 400 GByte) ebenfals einsetzen wollte... Aber wenn Du dann 400 GByte an Sourcecodes drauf hast und laufen der Compiler abbricht, weil sich eine Datei verändert hat, finde ich das nicht besonderst lustig. > Die Beschreibung ist einfach unzureichend. Da brauchst du mich nicht > anzumeckern, sondern kannst das ganz neutral schreiben. :-) > Paul Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: ext3, XFS, Reiser
Hallo Christian, Am 2005-03-09 09:03:54, schrieb Christian Roth: > Hallo Leute, > > ich muss mein System neu aufsetzen. Bisher verwende ich ext3 und bin > damit auch ganz zufrieden. Trotzdem wollte ich mal nachfragen was eure > Erfahrungen bzgl. Journaling FS sind. Im Netz gibt es so ein paar > Meinungen die ext3 als langsam beurteilen, Reiser erst in der Version > 4 als sehr gut. XFS gibt es schon sehr lange, es soll schnell sein und > auch robust. Der Linux Magazin Artikel zu diesem Thema ist schon 3 > Jahre alt. Solche Anfragen können sehr leicht in einen FlameWar enden... Also ich verwende ext3 seit dem WOODY r0 und kann keine Geschwindig- keitsprobleme feststellen. Mein Größtes FS ist eine 3Ware Raid-5 mit 4 mal 400 GByte und rund 18.000.000 Dateien. Ist ein Buildsystem mit diversen Crosscompilern, auf dem ich fast täglich arbeite... Mit XFS bin ich beim Tsten auf die N... gefallen. Auch Wenn XFS von SGI stammt und ausgereift ist, dann mag das für die MIPS mit Irix gelten aber nicht auf i386 und Linux. ReiserFS hat mir mehrfach nach systemabstürzen ganze Dateisysteme mitgenommen. Also bleibe ich bei ext3. > Danke > > Christian Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: ext3, XFS, Reiser
Hallo Christian, * Christian Roth <[EMAIL PROTECTED]> [20050309 12:50]: > > Ich habe vor nem halben Jahr alles von ext3 auf Reiser (3.6) > > umgestellt. Seither hatte ich keinerlei Datenverfälschungen. (Auch > Hattest Du Datenverfaelschungen unter ext3? Einfach so? > Ich habe Erfahrungen nur mit ext3. Das laeuft bisher problemlos. Nur einmal nach einem Absturz. Und dagegen kann ja auch ReiserFS prinzipbedingt nichts ausrichten. Das Journalling sorgt leider in beiden Fällen nur für die Konsistenz des Dateisystems, nicht der Daten. > Einmal hatte ich auf einer neuen Platte das Problem, dass sich > verschiedene Partitionen unmounted haben und das System nicht mehr > darauf zugreifen konnte. Ich habe das einem Plattenfehler > zugeschrieben und alles auf eine neue, identische Platte migriert. > Jetzt wollte ich diese Platte zum Austausch einschicken. > Kann so ein Verhalten auch andere Ursachen haben? Ist die Platte etwa > doch nicht kaputt? Formatieren und wieder beschreiben liess sie sich > problemlos. Ich glaube nicht, dass man das hier mit diesen Informationen entscheiden kann, es hört sich jedenfalls allemal seltsam an. Interessant wäre aber zumindest die Fehlermeldung beim mount-Versuch. > > Aufgefallen ist mir ein enormer Geschwindigkeitsunterschied bei großen > > Verzeichnissen. Wo es mit ext3 10 Sekunden gedauert hat, bis mir der > Das waere ein Argument fuer Reiser. Sehe ich auch so. Allerdings habe ich weder XFS noch JFS probiert, kann ja sein, dass die in diesem Fall ähnlich schnell oder vielleicht sogar schneller sind. Ich hatte nur den Vergleich von ext3 und ReiserFS. Grüße, Felix -- | /"\ ASCII Ribbon | Felix M. Palmen (Zirias)http://zirias.ath.cx/ | | \ / Campaign Against | [EMAIL PROTECTED] encrypted mail welcome | | XHTML In Mail | PGP key: http://zirias.ath.cx/pub.txt | | / \ And News | ED9B 62D0 BE39 32F9 2488 5D0C 8177 9D80 5ECF F683 | signature.asc Description: Digital signature
Re: ext3, XFS, Reiser
Christian Roth wrote: Hallo Leute, ich muss mein System neu aufsetzen. Bisher verwende ich ext3 und bin damit auch ganz zufrieden. Trotzdem wollte ich mal nachfragen was eure Erfahrungen bzgl. Journaling FS sind. Im Netz gibt es so ein paar Meinungen die ext3 als langsam beurteilen, Reiser erst in der Version 4 als sehr gut. XFS gibt es schon sehr lange, es soll schnell sein und auch robust. Der Linux Magazin Artikel zu diesem Thema ist schon 3 Jahre alt. Der eine oder andere hier stand bestimmt auch schon vor dieser Frage. Vielleicht koennt ihr bitte kurz eure Meinungen kundtun. Danke Christian XFS: Rock Solid, ACL, Extended Attributes, B-Tree. Hab ich zuerst in 2000 unter IRIX kennengelernt, seit SGI das nach Linux portiert hat, nutze ich nichts anderes mehr für Disks. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: ext3, XFS, Reiser
Also sprach Christian Roth <[EMAIL PROTECTED]> (Wed, 9 Mar 2005 09:03:54 +0100): > Hallo Leute, hi. > Vielleicht koennt ihr bitte kurz eure Meinungen kundtun. also ich hab hier ext3 schon lange im einsatz, und hatte keinerlei probleme damit. reiserfs (3.6) ergo. wobei ich reiserfs um einen tick schneller empfinde (speziell auf langsameren kisten, platten/cpu). probleme mit dateifehlern kann ich bei beiden nicht bestaetigen. fuer die squid caches sind ext2 in einsatz - da sind mir die daten aber auch nicht so wichtig; aber schnell. xfs hab ich noch nicht getestet. sl ritch. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: ext3, XFS, Reiser
Joerg Friedrich <[EMAIL PROTECTED]> writes: > Juergen Stuber schrieb am Mittwoch, 09. MÃrz 2005 um 10:13:29 +0100: > > > > Im Moment habe ich hier vermutlich ein Performance-Problem mit Ext3: > > > > - 45GB Backup von Backuppc erstellt > > - ca 1.000.000 Dateien > > - gut 200 Dateien pro Verzeichnis > > > > Mein erster Versuch das mit Tar auf eine neue Ext3-Partition zu kopieren > > hÃtte geschÃtzt ca 10h gedauert (= USB 1.1-Performance :-( ) und wurde > > deshalb erst mal abgebrochen. Jetzt wird die neue Partition wohl > > stattdessen ein Reiser3 werden, oder hat jemand einen besseren Vorschlag? > > StabilitÃt ist mir wichtiger als die letzten 10% Performance. > > Was hat Dein Problem jetzt mit Ext3 zutun? Du schreibst doch selbst, > dass es an USB1.1 liegt. Nein, die Platte ist ganz normal angeschlossen (PATA, DMA ist an), und der Rechner ist auch nicht schlecht (2.6GHz P4 i865G, FSB800, 1GB RAM). Deswegen erwarte ich eigentlich etwas mehr an Performance. 'tschuldigung fÃr die miÃverstÃndliche Ausdrucksweise JÃrgen -- NO to software patents -- stop the European patents directive JÃrgen Stuber <[EMAIL PROTECTED]> http://www.jstuber.net/ gnupg key fingerprint = 2767 CA3C 5680 58BA 9A91 23D9 BED6 9A7A AF9E 68B4 -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: ext3, XFS, Reiser
On Wed, Mar 09, 2005 at 12:19:46PM +0100, Felix M. Palmen wrote: Hallo, danke fuer die vielen Beitraege! Sehr interessant. > Ich habe vor nem halben Jahr alles von ext3 auf Reiser (3.6) > umgestellt. Seither hatte ich keinerlei Datenverfälschungen. (Auch Hattest Du Datenverfaelschungen unter ext3? Einfach so? Ich habe Erfahrungen nur mit ext3. Das laeuft bisher problemlos. Einmal hatte ich auf einer neuen Platte das Problem, dass sich verschiedene Partitionen unmounted haben und das System nicht mehr darauf zugreifen konnte. Ich habe das einem Plattenfehler zugeschrieben und alles auf eine neue, identische Platte migriert. Jetzt wollte ich diese Platte zum Austausch einschicken. Kann so ein Verhalten auch andere Ursachen haben? Ist die Platte etwa doch nicht kaputt? Formatieren und wieder beschreiben liess sie sich problemlos. > Aufgefallen ist mir ein enormer Geschwindigkeitsunterschied bei großen > Verzeichnissen. Wo es mit ext3 10 Sekunden gedauert hat, bis mir der Das waere ein Argument fuer Reiser. Gruesse Christian
Re: ext3, XFS, Reiser
Eduard Bloch wrote: > #include > * Paul Puschmann [Wed, Mar 09 2005, 11:24:14AM]: > > >>> - XFS: läuft jetzt ca. ein Jahr lang, macht fast alles mit. Subjektiv >>> muss ich sagen, dass die Geschwindigkeit mit der Zeit abnimmt, d.h. >>> z.Z. wird es träger und träger. >>> Nachteil: verfälscht manchmal Daten, sehr ärgerlich >> >>Hi, was wird denn da verfälscht? >>Da musst du schon was genauer werden (FUD). > > > Hallo? Kaputte Dateiinhalte ohne Warnung sind ein KO-Kriterium. > > Beschädigt war meistens eine der Dateien, die zuletzt geöffnet wurden. > IMHO auch längere Zeit nach dem letzten Zugriff auf diese Datei. > > .bash_history, manchmal Pakete im Apt-Cache, manchmal Programme, die > daraus installiert wurden. > > Diesen Scs habe ich schon einmal vor ca. zwei Jahren bemängelt, > damals ist sehr viel öfter etwas verfälscht worden. Vor ca. einem Jahr > wurde "Das Problem" angeblich gefunden und behoben, aber leider wohl > nicht ganz. > > Und "genauer" geht es schlecht, das sind Langzeiteffekte in komplexen > Systemen und Troubleshooting ist zu aufwendig. Bugbeschreibung auch. > > Eduard. Mir ist schon klar, dass das ein K.O.-Kriterium ist. Da ich aber noch keine dieser Fehler hatte, würde ich natürlich gerne wissen, wie die zustande gekommen sind. Wann sind den die Files defekt gewesen? nach einem Reboot, im Betrieb, nach einem Absturz / Stromausfall, war es sicher kein User-Fehler, ...? Die Beschreibung ist einfach unzureichend. Da brauchst du mich nicht anzumeckern, sondern kannst das ganz neutral schreiben. Paul -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: ext3, XFS, Reiser
Hallo Christian, * Christian Roth <[EMAIL PROTECTED]> [20050309 09:03]: > Der eine oder andere hier stand bestimmt auch schon vor dieser Frage. > Vielleicht koennt ihr bitte kurz eure Meinungen kundtun. Ich habe vor nem halben Jahr alles von ext3 auf Reiser (3.6) umgestellt. Seither hatte ich keinerlei Datenverfälschungen. (Auch nicht bei Abstürzen, aber das war wohl Glück, schließlich macht auch Reiser nur ein Journalling der Meta-Daten). Aufgefallen ist mir ein enormer Geschwindigkeitsunterschied bei großen Verzeichnissen. Wo es mit ext3 10 Sekunden gedauert hat, bis mir der gtk-Filedialog ein Verzeichnis mit sehr sehr vielen Bildern angezeigt hat, geht das mit Reiser fast sofort. Also kurz gesagt, ich bin ziemlich zufrieden damit. Grüße, Felix -- | /"\ ASCII Ribbon | Felix M. Palmen (Zirias)http://zirias.ath.cx/ | | \ / Campaign Against | [EMAIL PROTECTED] encrypted mail welcome | | XHTML In Mail | PGP key: http://zirias.ath.cx/pub.txt | | / \ And News | ED9B 62D0 BE39 32F9 2488 5D0C 8177 9D80 5ECF F683 | signature.asc Description: Digital signature
Re: ext3, XFS, Reiser
Joerg Friedrich schrieb: Juergen Stuber schrieb am Mittwoch, 09. März 2005 um 10:13:29 +0100: Christian Roth <[EMAIL PROTECTED]> writes: Mein erster Versuch das mit Tar auf eine neue Ext3-Partition zu kopieren hätte geschätzt ca 10h gedauert (= USB 1.1-Performance :-( ) und wurde deshalb erst mal abgebrochen. Was hat Dein Problem jetzt mit Ext3 zutun? Du schreibst doch selbst, dass es an USB1.1 liegt. Das kann halt nicht mehr als 12Mbit/s brutto, selbst bei nicht erreichbarem Brutto-Durchsatz brauchst Du mehr als 8 1/2 Stunden, um 45GB über USB1.1 zu transprotieren. Hi, da steht, dass das so schnell wie USB 1.1 war ;O) Ext3 verwendete ich auch relativ lange, allerdings wollte ich mal was anderes probieren, da kam mir ein Fehler im FS gerade recht. Aus irgendeinem mir unerfindlichen Grund war meine Home-Partition voll, selbst nachdem ich 1GB Daten löschte. Einmal ließ ich dem das durchgehen, ein 2.tes mal nicht, dann durfte sich ReiserFS probieren. Das wiederum führte sich gleich mit einem anderen Problem ein: ich durfte vorsichtshalber gar nicht mehr auf meine Platte schreiben. Aber auch das lies sich mit den Reisertools beheben und seit dem hat ReiserFS seine Second - Chance genutzt. Achja vielleicht ganz interessant: ich nutze meinen Rechner #1 als kleinen WG Fileserver und #2 als Desktop. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: ext3, XFS, Reiser
#include * Paul Puschmann [Wed, Mar 09 2005, 11:24:14AM]: > > - XFS: läuft jetzt ca. ein Jahr lang, macht fast alles mit. Subjektiv > >muss ich sagen, dass die Geschwindigkeit mit der Zeit abnimmt, d.h. > >z.Z. wird es träger und träger. > >Nachteil: verfälscht manchmal Daten, sehr ärgerlich > > Hi, was wird denn da verfälscht? > Da musst du schon was genauer werden (FUD). Hallo? Kaputte Dateiinhalte ohne Warnung sind ein KO-Kriterium. Beschädigt war meistens eine der Dateien, die zuletzt geöffnet wurden. IMHO auch längere Zeit nach dem letzten Zugriff auf diese Datei. .bash_history, manchmal Pakete im Apt-Cache, manchmal Programme, die daraus installiert wurden. Diesen Scs habe ich schon einmal vor ca. zwei Jahren bemängelt, damals ist sehr viel öfter etwas verfälscht worden. Vor ca. einem Jahr wurde "Das Problem" angeblich gefunden und behoben, aber leider wohl nicht ganz. Und "genauer" geht es schlecht, das sind Langzeiteffekte in komplexen Systemen und Troubleshooting ist zu aufwendig. Bugbeschreibung auch. Eduard. -- Everything is illusion. Constructs of language, light, metaphor; nothing is real. -- Babylon 5, Season 4 -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: ext3, XFS, Reiser
Eduard Bloch wrote: > Moin Markus! > Markus Heller schrieb am Mittwoch, den 09. März 2005: > > >>>Der eine oder andere hier stand bestimmt auch schon vor dieser Frage. >>>Vielleicht koennt ihr bitte kurz eure Meinungen kundtun. >> >>ich verwende nur noch XFS. Es ist robust, sicher und schnell. Allerdings kann >>ich zu den anderen nix sagen, da ich sie schon Ewigkeiten nicht mehr >>verwendet habe. XFS kann ich auf jeden Fall empfehlen. > > - XFS: läuft jetzt ca. ein Jahr lang, macht fast alles mit. Subjektiv >muss ich sagen, dass die Geschwindigkeit mit der Zeit abnimmt, d.h. >z.Z. wird es träger und träger. >Nachteil: verfälscht manchmal Daten, sehr ärgerlich Hi, was wird denn da verfälscht? Da musst du schon was genauer werden (FUD). Paul -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: ext3, XFS, Reiser
Moin Markus! Markus Heller schrieb am Mittwoch, den 09. März 2005: > > Der eine oder andere hier stand bestimmt auch schon vor dieser Frage. > > Vielleicht koennt ihr bitte kurz eure Meinungen kundtun. > > ich verwende nur noch XFS. Es ist robust, sicher und schnell. Allerdings kann > ich zu den anderen nix sagen, da ich sie schon Ewigkeiten nicht mehr > verwendet habe. XFS kann ich auf jeden Fall empfehlen. Meine Erfahrung mit verschiedenen Dateisystem auf dem Laptop (habe alle drei mehrere Monate verwendet): - ext3: manchmal sehr schnell, manchmal etwas zäh aber ziemlich robust. Auch bei Abstürzen IIRC keine verfälschte Daten bekommen o.ae. Nachteil: verschwendet Platz - ReiserFS 3.6: war ganz okay, im Schnitt (subjektiv) nicht schneller als Ext3, aber nachdem das FS ziemlich voll wurde, ist die Geschwindigkeit der Dateizugriffe gesunken. Auf der sicheren Hardware lief es ohne Datenverluste. Vorteil: sparrt Platz Nachteil: s.o., auf meinem Desktop hat sich ein Test-ReiserFS innerhalb von wenigen Stunden zerlegt, als da ein fehlerhafter RAM-Riegel eingebaut wurde. Ext3 lief zur gleichen Zeit fröhlich weiter. - XFS: läuft jetzt ca. ein Jahr lang, macht fast alles mit. Subjektiv muss ich sagen, dass die Geschwindigkeit mit der Zeit abnimmt, d.h. z.Z. wird es träger und träger. Nachteil: verfälscht manchmal Daten, sehr ärgerlich Beim nächsten Umstieg wird es JFS sein. Auf AIX läuft es immerhin ganz gut, warum also nicht auf Linux testen. Gruss, Eduard. -- Joey was bist du eigentlich offiziell im debian projekt genau? -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
