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?
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?
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: @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
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?
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)
