Reiserfs plötzlich 0 Byte Dateien
Hallo zusammen, ich habe ein Problem mit einer Reiserfs partition. Diese wird von mit als Datenablage verwendet. Jetzt ist mir heute morgen aufgefallen, dass 2 Dateien plötzlich eine Größe von 0 Byte haben(hatten vorher jeweils 200MB). Der Zeitstempel ist 00:18 und 00:29 heute Nacht. Zu dieser Zeit hat niemand Zugriff auf den Rechner. Habe zwar ein Backup, aber das ist ärgerlich. Ich finde nichts in den Log Dateien. Wie kann ich herausfinden was da passiert ist? Danke. Gruß Markus
Am Montag, 17. Januar 2005 17:08 schrieb Markus Senn:
(...). Ich finde nichts in den Log Dateien. Wie kann ich herausfinden was da passiert ist? Danke.
reiserfsck --check /dev/... Bestenfalls mit dem aktuellen Release: http://ftp.namesys.com/pub/reiserfsprogs/reiserfsprogs-3.6.19.tar.gz HTH, Jan -- Old programmers never die. They just branch to a new address.
Hallo, Jan Ritzerfeld schrieb:
Am Montag, 17. Januar 2005 17:08 schrieb Markus Senn:
(...). Ich finde nichts in den Log Dateien. Wie kann ich herausfinden was da passiert ist? Danke.
reiserfsck --check /dev/...
Bestenfalls mit dem aktuellen Release: http://ftp.namesys.com/pub/reiserfsprogs/reiserfsprogs-3.6.19.tar.gz
Habe ich durchgeführt, bringt anscheinend nichts. Genauso wie ein reiserfsck --fix-fixable und reiserfsck --rebuild-tree reiserfsck --check started at Mon Jan 17 19:05:27 2005 ########### Replaying journal.. Reiserfs journal '/dev/hda5' in blocks [18..8211]: 0 transactions replayed Checking internal tree..finished Comparing bitmaps..finished Checking Semantic tree: finished No corruptions found There are on the filesystem: Leaves 5780 Internal nodes 38 Directories 14 Other files 148 Data block pointers 5821831 (1463834 of them are zero) Safe links 0 ########### reiserfsck finished at Mon Jan 17 19:05:53 2005 Noch um was zu meinem System zu sagen, ist eine Suse9.2 Installation komplett mit Standard Packeten. Markus
Am Montag, 17. Januar 2005 19:12 schrieb Markus Senn:
(...). Habe ich durchgeführt, bringt anscheinend nichts.
"--check" ist bis auf's journal replay eh read only, es sollte nur feststellen, ob mit dem Datei-System prinzipiell alles in Ordnung ist. Du hast dafür auch das aktuelle Release von reiserfsprogs kompiliert und eigesetzt?
Genauso wie ein
reiserfsck --fix-fixable und
Ohne Fehler macht das auch nicht viel. .)
reiserfsck --rebuild-tree
Für die Mitleser und das Archiv: Sowas nicht ohne Backup machen. Am besten Platte mit dd oder dd_rescue spiegeln oder in eine Datei schreiben, und im letzteren Fall reiserfsck auf's loop device loslassen. Es gibt noch die Option "--scan-whole-partition", aber in deinem Fall sind die Dateien ja nicht "verschwunden" oder ähnliches ...
(...). Noch um was zu meinem System zu sagen, ist eine Suse9.2 Installation komplett mit Standard Packeten.
Es gibt also keine Fehlermeldungen im Logfile und aktuellstes reiserfschk findet keine Fehler. Das ist sehr merkwürdig. Wenn überhaupt wer, dann können dir die Entwickler auf der Mailing-Liste helfen ... http://www.namesys.com/mailinglist.html MfG, Jan -- Of all the things I've lost, I miss my mind the most.
Am Montag, 17. Januar 2005 17:08 schrieb Markus Senn:
Hallo zusammen,
ich habe ein Problem mit einer Reiserfs partition. Diese wird von mit als Datenablage verwendet. Jetzt ist mir heute morgen aufgefallen, dass 2 Dateien plötzlich eine Größe von 0 Byte haben(hatten vorher jeweils 200MB). Der Zeitstempel ist 00:18 und 00:29 heute Nacht. Zu dieser Zeit hat niemand Zugriff auf den Rechner. Habe zwar ein Backup, aber das ist ärgerlich. Ich finde nichts in den Log Dateien. Wie kann ich herausfinden was da passiert ist? Danke.
Du könntest statt "REISSWOLF" auch ein sicheres Dateisystem einsetzen (ext3, xfs...). Das Problem ist doch seit langem bekannt: Reiser erhält die Integrität des DATEISYSTEMS, von den Daten war nie die Rede. *SCNR* Peter -- If I had a message, I´d write a letter! (R. Polanski)
Peter Baumgartner schrieb:
Am Montag, 17. Januar 2005 17:08 schrieb Markus Senn:
Hallo zusammen,
ich habe ein Problem mit einer Reiserfs partition. Diese wird von mit als Datenablage verwendet. Jetzt ist mir heute morgen aufgefallen, dass 2 Dateien plötzlich eine Größe von 0 Byte haben(hatten vorher jeweils 200MB). Der Zeitstempel ist 00:18 und 00:29 heute Nacht. Zu dieser Zeit hat niemand Zugriff auf den Rechner. Habe zwar ein Backup, aber das ist ärgerlich. Ich finde nichts in den Log Dateien. Wie kann ich herausfinden was da passiert ist? Danke.
Du könntest statt "REISSWOLF" auch ein sicheres Dateisystem einsetzen (ext3, xfs...). Das Problem ist doch seit langem bekannt: Reiser erhält die Integrität des DATEISYSTEMS, von den Daten war nie die Rede.
Nein, war mir nicht bekannt. Und mit ext3 passieren mir nicht solche Querelen? Kann ich eine reiser Partition in ext3 umwandeln oder muss ich sie neu erstellen? Markus
Markus Senn, Dienstag, 18. Januar 2005 14:09:
Und mit ext3 passieren mir nicht solche Querelen?
Weniger. Der Code ist älter und daher mit weniger Kinderkrankheiten behaftet. Probier ggf. auch mal xfs.
Kann ich eine reiser Partition in ext3 umwandeln oder muss ich sie neu erstellen?
Daten wegkopieren, neues Dateisystem anlegen, Daten wieder zurückkopieren. Nicht vergessen, die fstab anzupassen. -- Antworten an lists@feile.net werden in /dev/null archiviert! Bitte ggf. lists... durch mail... ersetzen. Andreas Feile www.feile.net
Am Dienstag, 18. Januar 2005 14:09 schrieb Markus Senn:
Peter Baumgartner schrieb:
(...).
Du könntest statt "REISSWOLF" auch ein sicheres Dateisystem einsetzen (ext3, xfs...). Das Problem ist doch seit langem bekannt: Reiser erhält die Integrität des DATEISYSTEMS, von den Daten war nie die Rede.
Nein, war mir nicht bekannt.
Mir auch nicht, das ist nämlich falsch. Peter spricht vom Fall eines unsauberen Herunterfahrens oder eines Absturzes. Im normalen Betrieb erhält ReiserFS natürlich die Integrität des Dateisystems und der Daten, wie es jedes andere Dateisystem auch macht. Im Falle eines Absturzes ist aber auch bei ext3 so wie bei ReiserFS. Es gibt IIRC sowohl für ext3 als auch ReiserFS drei Modi (data=...): writeback (nur Metadaten-Journaling), ordered (prinzipiell auch nur nur Metadaten; Datenblöcke eines Metadaten-Updates werden aber gesammelt und vor dessen Update geschrieben) und journal (Journal über Daten und Meta-Daten). Unter neuren SUSE LINUX wird ordered genutzt und das ist auch der Default bei ext3.
Und mit ext3 passieren mir nicht solche Querelen?
Hatest du einen Absturz oder ähnliches? Wäre noch gut zu wissen. Ich glaube nicht, daß ext3 weniger Fehler hat oder sonderlich "sicherer" ist als ein aktuelles ReiserFS.
Kann ich eine reiser Partition in ext3 umwandeln oder muss ich sie neu erstellen?
Letzteres. MfG, Jan -- Any sufficiently advanced technology is indistinguishable from magic. - Arthur C. Clarke
Am Dienstag, 18. Januar 2005 11:44 schrieb Peter Baumgartner:
(...). Du könntest statt "REISSWOLF" auch ein sicheres Dateisystem einsetzen (ext3, xfs...).
FUD!
Das Problem ist doch seit langem bekannt: Reiser erhält die Integrität des DATEISYSTEMS, von den Daten war nie die Rede. (...).
Moment. 1. geht es hier AFAIK nicht um einen Crash oder einen Hardwarefehler. Die Dateien scheinen einfach so im laufenden Betrieb genullt worden zu sein. 2. ist dein Vergleich auch so schon einfach falsch! ReiserFS benutzt bei neueren SUSE LINUX data=ordered. Ext3 nutzt das auch als Default. Und data=ordered ist kein(!) volles Journal über Meta-Daten und Daten.
*SCNR*
Das macht's irgendwie nicht besser. MfG, Jan -- If the opposite of pro is con, what is the opposite of Progress?
Jan Ritzerfeld schrieb:
Das Problem ist doch seit langem bekannt: Reiser erhält die Integrität des DATEISYSTEMS, von den Daten war nie die Rede. (...).
Moment. 1. geht es hier AFAIK nicht um einen Crash oder einen Hardwarefehler. Die Dateien scheinen einfach so im laufenden Betrieb genullt worden zu sein.
Genau, es war kein Crash oder Hardwarefehler. Ich werde mich mal an die Enwickler richten.
2. ist dein Vergleich auch so schon einfach falsch! ReiserFS benutzt bei neueren SUSE LINUX data=ordered. Ext3 nutzt das auch als Default. Und data=ordered ist kein(!) volles Journal über Meta-Daten und Daten.
Hmm, da werd ich mich mal dazu einlesen. Markus
On 2005-01-18 15:51:16 +0100, Markus Senn wrote:
Genau, es war kein Crash oder Hardwarefehler. Ich werde mich mal an die Enwickler richten.
Bist Du GANZ sicher, daß kein cron-Job o.Ä. die Dateien verkürzt hat? Ist wirklich kein Eintrag in /var/log/message vorhanden? Gruß Martin -- Martin Schröder, ms@artcom-gmbh.de ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10 http://www.artcom-gmbh.de
Martin Schröder schrieb:
On 2005-01-18 15:51:16 +0100, Markus Senn wrote:
Genau, es war kein Crash oder Hardwarefehler. Ich werde mich mal an die Enwickler richten.
Bist Du GANZ sicher, daß kein cron-Job o.Ä. die Dateien verkürzt hat? Ist wirklich kein Eintrag in /var/log/message vorhanden?
Nein ich habe keinerlei cronjobs am laufen(außer die schon da waren) in /var/log/message gibt es nur folgendes um den Zeitpunkt herum: Jan 17 00:23:21 asterix -- MARK -- Jan 17 00:43:21 asterix -- MARK -- Jan 17 00:59:01 asterix /usr/sbin/cron[4365]: (root) CMD ( rm -f /var/spool/cron/lastrun/cron.hourly) Jan 17 01:23:21 asterix -- MARK -- Jan 17 01:43:21 asterix -- MARK -- Jan 17 01:59:01 asterix /usr/sbin/cron[4443]: (root) CMD ( rm -f /var/spool/cron/lastrun/cron.hourly) Markus
Am Dienstag, 18. Januar 2005 11:44 schrieb Peter Baumgartner:
(...). Du könntest statt "REISSWOLF" auch ein sicheres Dateisystem einsetzen (ext3, xfs...).
FUD! <flame>< Du meintest "FAKT"? Ich konnte es anfangs auch nicht glauben, aber nach dreimaligem Datenverlust habe ich die Finger von Reiser gelassen und seitdem Ruhe! QED!<>/flame> Wenn Du im Archiv blätterst, wirst Du bestimmt an die 10-20 Leute finden, die dieses Problem hatten. BTW, was meinst Du, woher ich obige Bezeichnung habe? Es mag ja sein, daß es "besser" geworden ist, aber das hieß es schon ein
Am Dienstag, 18. Januar 2005 14:42 schrieb Jan Ritzerfeld: paarmal. Fakt ist, daß ich seitdem für Datenplatten XFS einsetze und keine Probleme mehr habe (außer natürlich bei der 9.1, aber das ist ja bekanntlich ein anderes Problem ;-) ). [...] Gruß Peter
-- If the opposite of pro is con, what is the opposite of Progress?
-- If I had a message, I´d write a letter! (R. Polanski)
Am Dienstag, 18. Januar 2005 17:18 schrieb Peter Baumgartner:
Am Dienstag, 18. Januar 2005 14:42 schrieb Jan Ritzerfeld:
Am Dienstag, 18. Januar 2005 11:44 schrieb Peter Baumgartner:
(...). Du könntest statt "REISSWOLF" auch ein sicheres Dateisystem einsetzen (ext3, xfs...).
FUD! <flame>< Du meintest "FAKT"? Ich konnte es anfangs auch nicht glauben, aber nach dreimaligem Datenverlust habe ich die Finger von Reiser gelassen und seitdem Ruhe! QED!<>/flame> Wenn Du im Archiv blätterst, wirst Du bestimmt an die 10-20 Leute finden, die dieses Problem hatten.
Probleme mit Datenverlust ja,- aber eben nicht dieses Problem. Gruß Harald
Am Dienstag, 18. Januar 2005 17:28 schrieb Harald Huthmann:
Am Dienstag, 18. Januar 2005 17:18 schrieb Peter Baumgartner:
Am Dienstag, 18. Januar 2005 14:42 schrieb Jan Ritzerfeld:
Am Dienstag, 18. Januar 2005 11:44 schrieb Peter Baumgartner: [...]
Probleme mit Datenverlust ja,- aber eben nicht dieses Problem.
OK, aber ich würde 0-byte Dateien schon als Datenverlust im weiteren Sinne einstufen... IMHO ist JEDE Art von Datenverlust ein guter Grund, ein Betriebs- ;;-) Datei- oder sonstiges System nicht einzusetzen. Mehr wollte ich damit nicht sagen, deshalb hatte ich auch deutlich sichtbar die Ironiefahne geschwungen. Gruß Peter -- If I had a message, I´d write a letter! (R. Polanski)
Am Mittwoch, 19. Januar 2005 10:45 schrieb Peter Baumgartner:
Am Dienstag, 18. Januar 2005 17:28 schrieb Harald Huthmann:
Am Dienstag, 18. Januar 2005 17:18 schrieb Peter Baumgartner:
Am Dienstag, 18. Januar 2005 14:42 schrieb Jan Ritzerfeld:
Am Dienstag, 18. Januar 2005 11:44 schrieb Peter Baumgartner:
[...]
Probleme mit Datenverlust ja,- aber eben nicht dieses Problem.
OK, aber ich würde 0-byte Dateien schon als Datenverlust im weiteren Sinne einstufen... IMHO ist JEDE Art von Datenverlust ein guter Grund, ein Betriebs- ;;-) Datei- oder sonstiges System nicht einzusetzen. Mehr wollte ich damit nicht sagen, deshalb hatte ich auch deutlich sichtbar die Ironiefahne geschwungen.
Oh, oh!!! Datenverlust hatte ich sogar schon mit meinem Taschenkalender... ;-) Gruß, Michael -- ____ / / / / /__/ Michael Höhne / / / / / / mih-hoehne@t-online.de / _____________________________________/
Am Mittwoch, 19. Januar 2005 14:51 schrieb Michael Hoehne:
Am Mittwoch, 19. Januar 2005 10:45 schrieb Peter Baumgartner:
Am Dienstag, 18. Januar 2005 17:28 schrieb Harald Huthmann:
Am Dienstag, 18. Januar 2005 17:18 schrieb Peter Baumgartner:
Am Dienstag, 18. Januar 2005 14:42 schrieb Jan Ritzerfeld:
Am Dienstag, 18. Januar 2005 11:44 schrieb Peter Baumgartner:
[...]
Oh, oh!!! Datenverlust hatte ich sogar schon mit meinem Taschenkalender... ;-)
Au weia, da solltest Du aber schleunigst einen anderen besorgen - vielleicht von Debian, da ist dann sogar der Offsetdruck GPL ;-) Cheers Peter -- If I had a message, I´d write a letter! (R. Polanski)
Am Dienstag, 18. Januar 2005 17:18 schrieb Peter Baumgartner:
(...). <flame>< Du meintest "FAKT"? Ich konnte es anfangs auch nicht glauben, aber nach dreimaligem Datenverlust habe ich die Finger von Reiser gelassen und seitdem Ruhe! QED!<>/flame>
Beweis durch Beispiel? Das haben wir im ersten Semester in einer Analysis-Übung gemacht, weil uns nichts besseres einfiel. Der Übungsgruppenleiter fand es auch lustig. Trotzdem gab das 0 Punkte.
Wenn Du im Archiv blätterst, wirst Du bestimmt an die 10-20 Leute finden, die dieses Problem hatten.
ReiserFS ist das Standard-Dateisystem bei SUSE LINUX. Wen wundert es, daß dann 10 oder 20 Installationen von 100000en Probleme machen?
BTW, was meinst Du, woher ich obige Bezeichnung habe?
ReiserFS und defekte Hardware ist keine gute Kombination. Es ist durch seine komplexere Strukter in dieser Hinsicht weniger fehlertolerant als z. B. ext2. Dafür hat es andere Vorteile. Und Datenverlust hatte ich mit ext2 nach einem Crash, bei ReiserFS war es nur Datenmüll in /var/log/messages.
Es mag ja sein, daß es "besser" geworden ist, aber das hieß es schon ein paarmal.
Ich lese auch die ReiserFS-Mailingliste. Wenn es wirklich systematische Fehler wären, müßten ja jeden Tag zig Postings über Probleme eintrudeln.
Fakt ist, daß ich seitdem für Datenplatten XFS einsetze und keine Probleme mehr habe (außer natürlich bei der 9.1, aber das ist ja bekanntlich ein anderes Problem ;-) ). [...]
Bei älteren SUSE LINUX ohne den ordered-Modus konnten prinzipbedingt nach einem Crash Datenkorrumptionen auftreten (sehr beliebt: Null-Bytes am Ende von /var/log/messages). Genauso unter wie bei jedem anderen Dateisystemen ohne Journaling bzw. ausschließlichem Metadaten-Journaling. Wer denkt, daß Journaling Backups ersetzt, hat etwas grundlegendes nicht verstanden. MfG, Jan -- Your enemy is never a villain in his own eyes, keep this in mind.
Am Dienstag, 18. Januar 2005 18:20 schrieb Jan Ritzerfeld:
Am Dienstag, 18. Januar 2005 17:18 schrieb Peter Baumgartner:
(...). <flame>< Du meintest "FAKT"? Ich konnte es anfangs auch nicht glauben, aber nach dreimaligem Datenverlust habe ich die Finger von Reiser gelassen und seitdem Ruhe! QED!<>/flame>
Beweis durch Beispiel? Das haben wir im ersten Semester in einer Analysis-Übung gemacht, weil uns nichts besseres einfiel.
Das ist bei mir zwar ziemlich genau 30 Jahre her, also so ganz genau kenne ich die Feinheiten der Erstsemestermathekurse nicht mehr...
Der Übungsgruppenleiter fand es auch lustig. Trotzdem gab das 0 Punkte.
Wenn Du im Archiv blätterst, wirst Du bestimmt an die 10-20 Leute finden, die dieses Problem hatten.
ReiserFS ist das Standard-Dateisystem bei SUSE LINUX.
Das ist schön, aber Win$ ist auch das Standard-Betriebssystem auf Millionen von Rechnern... Du merkst langsam, worauf ich raus will? In meinem näheren Umfeld verwendet aus genanntem Grund NIEMAND Reiser, und alle fahren gut damit. Vielleicht würde eine Statistik oder "Volksbefragung" mal Klarheit bringen, wieviele Suse-Nutzer aus Faulheit "OK" klicken (und dies wahrscheinlich auch bei FAT32 tun würden), das dürften IMO nicht die Leute sein, für die Datenverlust eine entscheidende Rolle spielt *SCNR*, und wieviele ein "Dateisystem ihrer Wahl" einsetzen.
Wen wundert es, daß dann 10 oder 20 Installationen von 100000en Probleme machen? ^^^^^^^^^^^^^^ Das Problem ist doch nicht die Installation?
BTW, was meinst Du, woher ich obige Bezeichnung habe?
ReiserFS und defekte Hardware ist keine gute Kombination. Es ist durch
^^^^^^^^^^^^^^^^ Davon war, glaube ich, auch nie die Rede [...]
Bei älteren SUSE LINUX ohne den ordered-Modus konnten prinzipbedingt nach einem Crash Datenkorrumptionen auftreten (sehr beliebt: Null-Bytes am Ende von /var/log/messages). Genauso unter wie bei jedem anderen Dateisystemen ohne Journaling bzw. ausschließlichem Metadaten-Journaling. Wer denkt, daß Journaling Backups ersetzt, hat etwas grundlegendes nicht verstanden.
Wir reden hier nicht über Journalling vs. Backup, sondern über Datenverlust im Dateisystem, wer das gleichsetzt, "hat etwas grundlegendes nicht verstanden". Wenn Suse aus politischen oder sonstigen Gründen ein Dateisystem einsetzt, das per se nicht sicher ist (siehe Deine Aussage oben "(sehr beliebt: Null-Bytes am Ende...)"), dann MUSS es jedem Admin überlassen sein, ein anderes ("besseres"?) zu verwenden. Der OP hat schließlich nur festgestellt, dass er ein Problem mit Reiserfs hat, und dann sollte auch der Hinweis gestattet sein (mit Bezug auf das Archiv!), daß solche Probleme schon öfter aufgetreten sind, ohne daß einem die Notwendigkeit eines Backups - das er ja hat - um die Ohren geschlagen wird. BTW: ich habe in den letzen 4 Jahren nur einmal eines gebraucht, das war bei der Installation der 9.1, als Yast mir entgegen der Anweisung, die mit xfs versehenen /dev/sdb2 und /dev/sdc2 als "data1" und "data2" einzubinden, diese mit reiserfs formatiert hat. Wessen "Schuld" das wohl war? Sei froh, daß wir nicht in den USA leben ;-) Gruß und nichts für ungut Peter -- If I had a message, I´d write a letter! (R. Polanski)
On Wednesday 19 January 2005 11:15, Peter Baumgartner wrote:
eine entscheidende Rolle spielt *SCNR*, und wieviele ein "Dateisystem ihrer Wahl" einsetzen.
Hallo, Ich habe bei der SuSe 9.2 Installation bewußt Reiserfs gewählt. (davor mit 9.1 ext3) Es kursieren zwar Schauermärchen über Reiser im Netz aber auch genauso viele Positivberichte. Ich hoffe meine Installation gehört zu den "Positiven". :-) Gibt es denn irgendwas zu beachten was man mit Reiserfs nicht machen sollte weil darunter die Stabilität leidet/leiden könnte? Mein Grund für den Einsatz von Reiserfs war vor allem die höhere Performance im Vergleich zu ext3. XFS und JFS habe ich nicht weiter betrachtet. Gruß Wolf -- * Registered Linux user #37136 http://counter.li.org * Suse Linux 9.2pro, AMD Sempron 2800+, SIS 748 * Matrox MGA-450, 1GB/120GB * http://www.dl2wrj.de
Hallo, Am Mittwoch, 19. Januar 2005 17:02 schrieb Wolf-Ruediger Juergens:
On Wednesday 19 January 2005 11:15, Peter Baumgartner wrote:
eine entscheidende Rolle spielt *SCNR*, und wieviele ein "Dateisystem ihrer Wahl" einsetzen.
Hallo, Ich habe bei der SuSe 9.2 Installation bewußt Reiserfs gewählt. (davor mit 9.1 ext3) Es kursieren zwar Schauermärchen über Reiser im Netz aber auch genauso viele Positivberichte. Ich hoffe meine Installation gehört zu den "Positiven". :-)
Nun, so eine (nein leider mehrere) Schauergeschichte(n) kann ich auch erzählen. Gebranntes Kind scheut das Feuer. Ich würde weder ReiserFS nochmal einsetzen, noch einen Opel kaufen. Mit beiden habe ich schlechte Erfahrungen gemacht. Dennoch gibt es Leute die auf Opel bzw. ReiserFS schwören.
Gibt es denn irgendwas zu beachten was man mit Reiserfs nicht machen sollte weil darunter die Stabilität leidet/leiden könnte?
Ein Kunde von mir schaltet seinen "Server" immer via An/Aus-Knopf aus. Reiser hat hier noch nie Probleme gemacht. Achten sollte man aber auf funktionsfähige Hardware. Reiser gibt nach meiner Erfahrung bei defekten Clustern u.ä. schnell mit fehlenden Dateien auf. Auf XFS ist mir das noch nie passiert. Da jede Festplatte irgendwann, und meistens dann wenn man es am wenigsten gebrauchen kann, kaputt geht, setzte ich bewußt kein Reiser mehr ein.
Mein Grund für den Einsatz von Reiserfs war vor allem die höhere Performance im Vergleich zu ext3. XFS und JFS habe ich nicht weiter betrachtet.
Das war auch mein Grund auf Reiser zu setzen. Viele kleine Dateien sollen unter ReiserFS erheblich performanter sein. Mit XFS kann ich aber auch nicht klagen :-) Und XFS hat auch sehr nette Tools wie z.b. FS-dump.
Gruß Wolf
HTH Andreas
Andreas Hergesell wrote:
Hallo,
Am Mittwoch, 19. Januar 2005 17:02 schrieb Wolf-Ruediger Juergens:
....
Ein Kunde von mir schaltet seinen "Server" immer via An/Aus-Knopf aus. Reiser hat hier noch nie Probleme gemacht.
Achten sollte man aber auf funktionsfähige Hardware. Reiser gibt nach meiner Erfahrung bei defekten Clustern u.ä. schnell mit fehlenden Dateien auf. Auf XFS ist mir das noch nie passiert. Da jede Festplatte irgendwann, und meistens dann wenn man es am wenigsten gebrauchen kann, kaputt geht, setzte ich bewußt kein Reiser mehr ein.
.....
Ich hatte bisher nur einmal Probleme mit ReiserFS und da waren tatsächlich zwei Sektoren auf der Platte kaputt. Das habe ich erst mit einem Diskanalysetool des Herstellers gefunden. Erstaunlich war, mit welcher Hartnäckigkeit ReiserFS immer wieder auf die kaputten Sektoren geschrieben und eine Zeitlang erfolgreich davon gelesen hat. Am Ende hat es die Dateien doch für 0 Byte groß befunden und aufgegeben. Allerdings konnte ich mangels defekter Festplatten nicht überprüfen, wie andere Dateisysteme darauf reagieren. Das Diskanalysetool hatte die Sektoren nämlich für ungültig erklärt und danach lief jedes FS wieder problemlos auf der Platte. Gruß Detlef
On Wednesday 19 January 2005 17:56, Andreas Hergesell wrote: Hallo,
Nun, so eine (nein leider mehrere) Schauergeschichte(n) kann ich auch erzählen. Gebranntes Kind scheut das Feuer. Ich würde weder ReiserFS nochmal einsetzen, noch einen Opel kaufen. Mit beiden habe ich schlechte Erfahrungen gemacht. Dennoch gibt es Leute die auf Opel bzw. ReiserFS schwören.
Opel? na gut ;-)
Achten sollte man aber auf funktionsfähige Hardware. Reiser gibt nach meiner Erfahrung bei defekten Clustern u.ä. schnell mit fehlenden Dateien auf. Auf XFS ist mir das noch nie passiert. Da jede Festplatte irgendwann, und meistens dann wenn man es am wenigsten gebrauchen kann, kaputt geht, setzte ich bewußt kein Reiser mehr ein.
Meine 2 Platten (je 120GB von Maxtor bzw. Hitachi) laufen nicht in einem Cluster. Bei beiden benutzte ich aber UDMA. Das läuft auch ohne Tadel. Bei der Maxtor schon seit ca. 1Jahr. Smartctl hat auch noch nie einen Fehler gemeldet. Ok, kaputt können sie von Heute auf Morgen gehen. Aber wie sollte ein anderes Filesystem das Verhindern können?
Das war auch mein Grund auf Reiser zu setzen. Viele kleine Dateien sollen unter ReiserFS erheblich performanter sein. Mit XFS kann ich aber auch nicht klagen :-)
Auch längliche Umkopieraktionen z.B. 30GB Ogg/Vorbis-Files(Musikarchiv) von einer auf die andere Platte liefen sehr schnell. Kann jetzt aber nicht sagen wie lange das genau dauerte. Gruß Wolf -- * Registered Linux user #37136 http://counter.li.org * Suse Linux 9.2pro, AMD Sempron 2800+, SIS 748 * Matrox MGA-450, 1GB/120GB * http://www.dl2wrj.de
Hi Wolf, Am Mittwoch, 19. Januar 2005 22:54 schrieb Wolf-Ruediger Juergens:
On Wednesday 19 January 2005 17:56, Andreas Hergesell wrote:
Achten sollte man aber auf funktionsfähige Hardware. Reiser gibt nach meiner Erfahrung bei defekten Clustern u.ä. schnell mit fehlenden Dateien auf. Auf XFS ist mir das noch nie passiert. Da jede Festplatte irgendwann, und meistens dann wenn man es am wenigsten gebrauchen kann, kaputt geht, setzte ich bewußt kein Reiser mehr ein.
Meine 2 Platten (je 120GB von Maxtor bzw. Hitachi) laufen nicht in einem Cluster. Bei beiden benutzte ich aber UDMA. Das läuft
Tschuldige, ich meinte Sektoren auf der Festplatte :-/
auch ohne Tadel. Bei der Maxtor schon seit ca. 1Jahr. Smartctl hat auch noch nie einen Fehler gemeldet. Ok, kaputt können sie von Heute auf Morgen gehen. Aber wie sollte ein anderes Filesystem das Verhindern können?
Nein, natürlich kann kein Dateisystem Hardwarefehler verhindern. Aber wenn fehlerhafte Sektoren auf der Platte auftreten, können die Dateisysteme unterschiedlich empfindlich darauf reagieren. Mit ReiserFS waren bei mir sehr schnell Dateien verloren, während XFS noch eine Zeit auf dieser Platte stabil lief. Aber das sind halt meine pers. Erfahrungen und natürlich keine statistischen Erhebungen.
Das war auch mein Grund auf Reiser zu setzen. Viele kleine Dateien sollen unter ReiserFS erheblich performanter sein. Mit XFS kann ich aber auch nicht klagen :-)
Auch längliche Umkopieraktionen z.B. 30GB Ogg/Vorbis-Files(Musikarchiv) von einer auf die andere Platte liefen sehr schnell. Kann jetzt aber nicht sagen wie lange das genau dauerte.
In einem Musikarchiv fehlende Lieder zu finden ist eine sehr nervige Aufgabe... Viele Grüße Andreas
Am Donnerstag, den 20.01.2005, 09:20 +0100 schrieb Andreas Hergesell:
Nein, natürlich kann kein Dateisystem Hardwarefehler verhindern. Aber wenn fehlerhafte Sektoren auf der Platte auftreten, können die Dateisysteme unterschiedlich empfindlich darauf reagieren.
Das kann sehe ich dann eher als negativ an. Schließlich kann einem so tückischerweise eine heile Welt vorgegaukelt werden. Bei einem Hardwareproblem sollte man sowieso ASAP reagieren und die defekte Komponente entfernen.
Aber das sind halt meine pers. Erfahrungen und natürlich keine statistischen Erhebungen.
Das ist ja auch ok. Und jeder darf so handeln, wie er es für richtig hält. Was ich nur nicht mag ist, wenn die Ursache nicht genau definiert wurde dennoch die Schuld jemanden in die Schuhe zu schieben. Ciao, Torsten
Hi Torsten, Am Samstag, 22. Januar 2005 16:49 schrieb Torsten Hallmann:
Am Donnerstag, den 20.01.2005, 09:20 +0100 schrieb Andreas Hergesell:
Nein, natürlich kann kein Dateisystem Hardwarefehler verhindern. Aber wenn fehlerhafte Sektoren auf der Platte auftreten, können die Dateisysteme unterschiedlich empfindlich darauf reagieren.
Das kann sehe ich dann eher als negativ an. Schließlich kann einem so tückischerweise eine heile Welt vorgegaukelt werden. Bei
Das sehe ich eben anders. Das Dateisystem ist für mich nicht zuständig mich über Hardwareausfälle zu informieren. Das machen andere Tools. Und wenn diese Tools mir sagen "Kauf ne neue Platte" will ich noch an alle Daten auf der defekten Platte herankommen.
einem Hardwareproblem sollte man sowieso ASAP reagieren und die defekte Komponente entfernen.
Absolut richtig.
Aber das sind halt meine pers. Erfahrungen und natürlich keine statistischen Erhebungen.
Das ist ja auch ok. Und jeder darf so handeln, wie er es für richtig hält. Was ich nur nicht mag ist, wenn die Ursache nicht genau definiert wurde dennoch die Schuld jemanden in die Schuhe zu schieben.
Wem schiebe ich die Schuld in die Schuhe? Das meine Platte über den Jordan gegangen ist, ist nicht die Schuld von ReiserFS :-)
Ciao, Torsten
Viele Grüße Andreas
Am Mittwoch, 19. Januar 2005 11:15 schrieb Peter Baumgartner:
Am Dienstag, 18. Januar 2005 18:20 schrieb Jan Ritzerfeld: (...).
ReiserFS ist das Standard-Dateisystem bei SUSE LINUX.
Das ist schön, aber Win$ ist auch das Standard-Betriebssystem auf Millionen von Rechnern... Du merkst langsam, worauf ich raus will?
Über beides regt man sich gerne auf, wenn Probleme auftauchen?
In meinem näheren Umfeld verwendet aus genanntem Grund NIEMAND Reiser, und alle fahren gut damit.
Ich würde auch nicht behaupten, daß alle anderen Dateisysteme schlechter sind.
(...).
Wen wundert es, daß dann 10 oder 20 Installationen von 100000en Probleme machen? ^^^^^^^^^^^^^^ Das Problem ist doch nicht die Installation?
"Installationen von/auf/mit ReiserFS"
BTW, was meinst Du, woher ich obige Bezeichnung habe?
ReiserFS und defekte Hardware ist keine gute Kombination. Es ist durch ^^^^^^^^^^^^^^^^ Davon war, glaube ich, auch nie die Rede
Würde mich wundern: http://www.namesys.com/faq.html#hard-prob | (...). Real bug reports are at the time of writing outnumbered 10 to 1 by | hardware bugs that trigger error messages. (...).
[...]
Bei älteren SUSE LINUX ohne den ordered-Modus konnten prinzipbedingt nach einem Crash Datenkorrumptionen auftreten (sehr beliebt: Null-Bytes am Ende von /var/log/messages). Genauso unter wie bei jedem anderen Dateisystemen ohne Journaling bzw. ausschließlichem Metadaten-Journaling. Wer denkt, daß Journaling Backups ersetzt, hat etwas grundlegendes nicht verstanden.
Wir reden hier nicht über Journalling vs. Backup, sondern über Datenverlust im Dateisystem, wer das gleichsetzt, "hat etwas grundlegendes nicht verstanden".
Bei/nach einem Crash kann bei jedem Dateisystem Datenverlust auftreten. Deshalb braucht man trotz Journals Backups. Ich setze da nichts gleich.
Wenn Suse aus politischen oder sonstigen Gründen ein Dateisystem einsetzt, das per se nicht sicher ist (siehe Deine Aussage oben "(sehr beliebt: Null-Bytes am Ende...)"),
Es gibt kein per se sicheres Dateisystem! Wie soll SUSE eins einsetzen können? Und meine Aussage bezog sich auf den Fall eines Crashs, die Null-Bytes oder anderer Datenmüll sind ein prinzipielles Problem bei Metadaten-Journaling, z. B. wenn die Daten an sich eben noch nicht physikalisch auf der Platte gelandet sind, die Metadaten durch das Journal aber schon.
dann MUSS es jedem Admin überlassen sein, ein anderes ("besseres"?) zu verwenden.
Wer behauptet was anderes?
Der OP hat schließlich nur festgestellt, dass er ein Problem mit Reiserfs hat,
Eigentlich hat er nur festgestellt, daß seine Platte mit ReiserFS formatiert ist und zwei Dateien plötzlich nur noch 0 Bytes groß sind. Ohne Crash und Fehlermeldungen. Und du schiebst die Schuld direkt ReiserFS in die Schuhe. Nicht sonderlich seriös.
und dann sollte auch der Hinweis gestattet sein (mit Bezug auf das Archiv!),
Im Archiv finde ich Artikel von "Angstbeißern", die reflexartig bei den Worten "Problem" und "ReiserFS" von ReiserFS abraten ...
daß solche Probleme schon öfter aufgetreten sind, (...).
Wie gesagt, die Wahrscheinlichkeit, daß eine SUSE-Installation Probleme macht und ReiserFS benutzt wird, ist sehr groß. MfG, Jan -- It's better to be a lion for a day, than a sheep all your life.
Am Donnerstag, 20. Januar 2005 17:58 schrieb Jan Ritzerfeld:
Würde mich wundern: http://www.namesys.com/faq.html#hard-prob
| (...). Real bug reports are at the time of writing outnumbered 10 | to 1 by hardware bugs that trigger error messages. (...).
Dem Artikel kann ich mich nur anschliessen und ReiserFS dankbar sein das es mich vor ca. 1 Jahr durch solche überraschend auftauchenden 0-Byte-Dateien auf den nahenden Tod einer meiner Festplatten aufmerksam gemacht hat. Ich weiss nicht ob mich eins dieser anderen "hochgelobten" Filesystems genauso charmant darauf hingewiesen hätte. Gruss Thomas -- powered by SuSE Ocius, firmus, stabilis, viridis
Am Mittwoch, den 19.01.2005, 11:15 +0100 schrieb Peter Baumgartner:
ReiserFS ist das Standard-Dateisystem bei SUSE LINUX.
Das ist schön, aber Win$ ist auch das Standard-Betriebssystem auf Millionen von Rechnern... Du merkst langsam, worauf ich raus will?
Allerdings unterschlägst Du mit dieser Antwort den Punkt, auf den der Vorredner hinaus will: Wo gehobelt wird, da fallen ... Wenn Du schon den Vergleich mit Win ansetzt, dann solltest Du in diesem Zusammenhang auch die Problemquote in Relation setzen - sonst ist das unbrauchbar.
In meinem näheren Umfeld verwendet aus genanntem Grund NIEMAND Reiser, und alle fahren gut damit. Vielleicht würde eine Statistik oder "Volksbefragung" mal Klarheit bringen, wieviele Suse-Nutzer aus Faulheit "OK" klicken (und dies wahrscheinlich auch bei FAT32 tun würden), das dürften IMO nicht die Leute sein, für die Datenverlust eine entscheidende Rolle spielt *SCNR*, und wieviele ein "Dateisystem ihrer Wahl" einsetzen.
Komisch nur das viele mit reiserfs im professionellen Einsatz keine Probleme verzeichnen. In diesem Zusammenhang stelle ich Dir nun einmal die Frage, ob Du genau herausgefunden hast, woran es lag. Ohne die genaue Ursache ist jedes verdammen und beschimpfen einer Sache vollkommenes "Kaffesatzlesen". Ciao, Torsten
Hi, habe mich bisher für den Thread nicht besonders interessiert, bis mich jemand im Thread "Datei unsichtbar" darauf aufmerksam gemacht hat, dass mein Problem eventuell auch mit reiserfs zusammenhängen konnte. Ich habe schon 4mal Probleme mit meinem Dateisystem gehabt, nachdem ich Suspend-To-Disk verwendet hatte. 2mal so schwer, dass eine Neuinstallation notwendig war. :-( Könnte ein anderes Dateisystem abhilfe schaffen? Wenn ja welches? Ich nutze meinen Laptop täglich, meistens als normalen Office-PC (also Internet, OOO und Entwicklung). So wie ich es verstanden habe, kann man nicht einfach das Dateisystem nicht einfach im laufende Betrieb wechseln. Richtig? MfG Kay
* Donnerstag, 20. Januar 2005 um 12:54 (+0100) schrieb Kay Patzwald:
habe mich bisher für den Thread nicht besonders interessiert, bis mich jemand im Thread "Datei unsichtbar" darauf aufmerksam gemacht hat, dass mein Problem eventuell auch mit reiserfs zusammenhängen konnte. Ich habe schon 4mal Probleme mit meinem Dateisystem gehabt, nachdem ich Suspend-To-Disk verwendet hatte. 2mal so schwer, dass eine Neuinstallation notwendig war. :-(
Sowohl "Software Suspend" als auch die "ACPI Sleep States" sind in der
Kernelkonfiguration nicht ohne Grund (noch) als "EXPERIMENTAL" bezeichnet.
Siehe auch "<kernel>/Documentation/power/swsusp.txt":
----------- Schnipp -----------
* BIG FAT WARNING *********************************************************
*
* If you have unsupported (*) devices using DMA...
* ...say goodbye to your data.
*
* If you touch anything on disk between suspend and resume...
* ...kiss your data goodbye.
*
* If your disk driver does not support suspend... (IDE does)
* ...you'd better find out how to get along
* without your data.
*
* If you change kernel command line between suspend and resume...
* ...prepare for nasty fsck or worse.
*
* (*) suspend/resume support is needed to make it safe.
[ ... ]
---------- Schnapp -------------
Gruß
Andreas
--
Andreas Könecke "Andreas Koenecke
participants (14)
-
Andreas Feile -
Andreas Hergesell -
Andreas Koenecke -
detlef.grittner＠t-online.de -
Harald_mail＠t-online.de -
Jan Ritzerfeld -
Kay Patzwald -
Markus Senn -
Martin Schröder -
Michael Hoehne -
Peter Baumgartner -
Thomas Janssen -
Torsten Hallmann -
WJuergens＠t-online.de