Hallo liebe Listenmiglieder, ich hoffe Ihr habt Weihnachten alle "gut" überstanden :-) Ich habe hier ein seltsames Problem mit einem Linuxserver und hoffe mir kann jemand von euch helfen. Folgendes Situation: Das System ist auf einem Software Raid (1) installiert und versieht klaglos seinen Dienst. Da es sich jedoch um unseren Mailserver handelt wird täglich eine Datensicherung mit Amanda gemacht. Eine Partition lässt sich jedoch nicht sichern und spuckt immer die gleiche Meldung aus: DUMP: short read error from /dev/md0: [block 385480, ext2blk 192740]: count=1024, got=0 DUMP: bread: lseek2 fails! Google konnte mir bisher nicht weiterhelfen. Kernel ist 2.4.26 Filesystem ist ext3 Was passiert da und wie kann ich das reparieren? Danke schonmal im vorraus Daniel -- Daniel Hanke Linux/Unix Systemadministrator, RHCE windream GmbH - Wasserstrasse 219 - 44799 Bochum Telefon +49 234 9734 0 - Telefax +49 234 9734 520 http://www.windream.com
Hi! On Wed, 29 Dec 2004, Daniel Hanke wrote:
Das System ist auf einem Software Raid (1) installiert und versieht klaglos seinen Dienst. Da es sich jedoch um unseren Mailserver handelt wird täglich eine Datensicherung mit Amanda gemacht. Eine Partition lässt sich jedoch nicht sichern und spuckt immer die gleiche Meldung aus:
DUMP: short read error from /dev/md0: [block 385480, ext2blk 192740]: count=1024, got=0 DUMP: bread: lseek2 fails!
Was mir dazu einfällt: Was sagt "cat /proc/mdstat"? Stehen im Syslog irgendwelche IDE/SCSI-Fehler? Ist die Partition zu diesem Zeitpunkt gemounted (lieber nicht)? Hast Du mal ein "fsck -Cf /dev/md0" gemacht? Wie groß ist die Partition überhaupt? Martin
Am Mittwoch, den 29.12.2004, 13:07 +0100 schrieb Martin Köhling:
Hi!
On Wed, 29 Dec 2004, Daniel Hanke wrote:
Das System ist auf einem Software Raid (1) installiert und versieht klaglos seinen Dienst. Da es sich jedoch um unseren Mailserver handelt wird täglich eine Datensicherung mit Amanda gemacht. Eine Partition lässt sich jedoch nicht sichern und spuckt immer die gleiche Meldung aus:
DUMP: short read error from /dev/md0: [block 385480, ext2blk 192740]: count=1024, got=0 DUMP: bread: lseek2 fails!
Was mir dazu einfällt:
Was sagt "cat /proc/mdstat"?
alles ok
Stehen im Syslog irgendwelche IDE/SCSI-Fehler?
Ja. Diese hier: Dec 29 13:28:59 mailgate-a kernel: attempt to access beyond end of device Dec 29 13:28:59 mailgate-a kernel: 09:00: rw=0, want=1104323352, limit=192640 Aber nur wo ich einen fsck gemacht hab. Alle anderen Partitionen laufen ohne Probleme...
Ist die Partition zu diesem Zeitpunkt gemounted (lieber nicht)?
ja. Warum nicht?
Hast Du mal ein "fsck -Cf /dev/md0" gemacht?
Ausgabe: Group descriptors look bad... trying backup blocks... fsck.ext3: Invalid argument while checking ext3 journal for /dev/md0
Wie groß ist die Partition überhaupt?
183 MB Gruß Daniel -- Daniel Hanke Linux/Unix Systemadministrator, RHCE windream GmbH - Wasserstrasse 219 - 44799 Bochum Telefon +49 234 9734 0 - Telefax +49 234 9734 520 http://www.windream.com
On Wed, 29 Dec 2004, Daniel Hanke wrote:
Am Mittwoch, den 29.12.2004, 13:07 +0100 schrieb Martin Köhling:
On Wed, 29 Dec 2004, Daniel Hanke wrote:
DUMP: short read error from /dev/md0: [block 385480, ext2blk 192740]: count=1024, got=0 DUMP: bread: lseek2 fails!
Was mir dazu einfällt:
Was sagt "cat /proc/mdstat"?
alles ok
Also wohl kein Hardwarefehler.
Stehen im Syslog irgendwelche IDE/SCSI-Fehler?
Ja. Diese hier: Dec 29 13:28:59 mailgate-a kernel: attempt to access beyond end of device Dec 29 13:28:59 mailgate-a kernel: 09:00: rw=0, want=1104323352, limit=192640 Aber nur wo ich einen fsck gemacht hab. Alle anderen Partitionen laufen ohne Probleme...
Das sieht nach beschädigten Verwaltungsstrukturen aus... Die Meldung kam während des "fsck"? Hat "fsck" irgendwelche Reparaturversuche angeboten?
Ist die Partition zu diesem Zeitpunkt gemounted (lieber nicht)?
ja. Warum nicht?
Weil "dump" am Dateisystem-Treiber "vorbei" auf die Partition zugreift; Sektoren, von denen "dump" glaubt, sie enthalten Verwaltungsinformationen (z.B. indirekte Blöcke), können nach Schreibzugriffen dann plötzlich einfache Nutzdaten enthalten, die dann natürlich völlig falsch interpretiert werden - das kann zu Meldungen wie "short read / access beyond end of device" führen. Oder: "dump" sichert Datenblöcke, die zu Datei A gehören sollen, die aber mittlerweile zu Datei B gehören (A ist mittlerweile vieleicht schon wieder gelöscht worden) - dadurch bekommt nach einem Restore User X u.U. private Daten von User Y zu sehen! Wie oft solche Probleme in der Praxis auftreten, hängt natürlich ganz stark von der Nutzung der Partition ab... Ich würde für die Sicherung aktiver Dateisystene eher sowas wie "tar" nehmen. (Oder mit LVM-Snapshots arbeiten - damit hab' ich allerdings keinerlei Erfahrung). Aber da die Fehlermeldung (wie Du sagst) immer *exakt* dieselbe ist, liegt der Fehler wohl nicht hier - es ist wohl eher mit der Partition irgendwas faul...
Hast Du mal ein "fsck -Cf /dev/md0" gemacht?
Ausgabe: Group descriptors look bad... trying backup blocks... fsck.ext3: Invalid argument while checking ext3 journal for /dev/md0
Offenbar ist das Dateisiystem beschädigt; wenn "fsck" das nicht reparieren kann, ist ein Komplettbackup und ein dann "mkfs" angesagt. (Ich gehe mal davon aus, das Du die Partition vor dem "fsck" ge-unmounted hast - richtig???) MfG Martin
participants (2)
-
Daniel Hanke
-
Martin Köhling