Am Sonntag 03 August 2003 05:30 schrieb Manuel Jenne:

Nun habe ich mal ein "badblock /dev/system/gl" gestarten und mal abwarten. Das dauert bei 360Gb natürlich ne Weile. Aber ist das überhaupt der richtige Weg? Gibt es nicht irgendwelche Tools vom LVM um Fehler zu beheben?

Hmm ... Das ist ja kein Problem vom LVM. LVM ist lediglich eine (statische [1]) Schicht, welche Blöcke auf der Festplatte zu logischen Partitionen zuordnet. Diese sind ja weiterhin ok. Wenn ein Block nicht gelesen werden kann, dann deutet dies schon auf einen Defekt der Platte oder auf Probleme beim ansprechen der Platte (Treiber, Verkabelung und so) hin. Ich würde Dir hier aber dazu raten, evtl. einmal auf andere Filesysteme zu wechseln. Ich habe solche "Stories" bisher nur von ReiserFS gehört. Seltsamer Weise noch nie von XFS und ext3 Anwendern! (Wobei bei SuSE ReiserFS der Standard ist, so dass dies mit an der geringen Nutzung von ext3 / xfs liegen könnte. Aber da wir [2] hier ständig darauf hinweisen, dass wir reiserfs nie verwenden würden, weil es da öfters zu Problemen kommt, dann denke ich, dass sich dies doch eine nicht zu vernachlässigende Anzahl von Anwendern zu Herzen nimmt, was den obrigen Punkt evtl. wiederlegt. Aber da ich keine Zahlen habe, wollte ich auch auf diese Möglichkeit hinweisen) Ich selbst habe schon XFS und JFS ausprobiert und war mit beidem sehr zufrieden. Derzeit habe ich meine Daten auf meinem Laptop auf ext3 liegen und bin sehr zufrieden. An dieser Stelle möchte ich noch sagen, dass ich mit meinem Laptop ein ganz extremes Vorgehen habe, das ich niemandem ans Herz legen würde: Ich schalte den Rechner einfach aus, d.h. Anwendungen schliessen und dann AUS. Runterfahren praktiziere ich nur, wenn ich an der KDE Oberfläche etwas geändert habe (Icons auf Ihren Plätzen bleiben sollen). (Hier möchte ich aber auch noch kurz darauf hinweisen, dass ich auf meinem Laptop ein spezielles System hierfür aufgebaut habe. Ich arbeite mit Knoppix auf Festplatte, wobei ich _keine_ Festplatteninstallation habe, sondern lediglich ein compressed Image booten lasse! (Also von CD das (knoppix/knoppix auf die vfat32 Partition unter \knoppix\knoppix gelegt und dann findet Knoppix dies automatisch! Und damit kann am System nie etwas kaputt gehen und es geht hier nur noch um das /home/knoppix Verzeichnis! Aber genau diese Vorgehensweise habe ich auch früher auf meinem Laptop immer betrieben!) [1] Natürlich ist die schicht nicht ganz statisch, aber Veränderungen werden nur vorgenommen, wenn Du neue LVs und so anlegst, dann ändert sich da natürlich auch etwas, aber im normalen Betrieb sind bleiben die Daten unverändert und sind dabei sogar meist so klein, dass sie komplett im 3rd Level Cache verbleiben, so dass die IO Operationen kaum verlangsamt werden (Der Zugriff auf den Cache ist im Vergleich zu den IO Operationen auf der Platte zu vernachlässigen. Bei Speicherzugriffen auf den Hauptspeicher ist das Verhältnis zu den IO Operationen der Platte zwar auch nicht so wild, aber diese würden schon messbare spürbare Verluste bringen. Und dies ist nicht der Fall. (Das Dokument bei SuSE, welches dies mit klaren Testreihen dokumentiert, konnte ich leider nicht mehr finden. Die hatten eine deutschsprachie HowTo zum LVM, wo dies drin war ...) [2] Einige Anwender hier auf der Liste weisen regelmässig auf diese Problematik hin. Probleme mit ReiserFS kommen hier halt "öfters" über die Liste! Mit den besten Grüßen, Konrad Neitzel