Re: Spass mit Floppies

From: Oliver Fromme <olli(at)secnetix.de>
Date: Sun, 17 Mar 2002 10:23:43 +0100 (CET)

Oli Kuemmel <bsd(at)gvs.dyn.bawue.de> wrote:
> Oliver Fromme <olli(at)secnetix.de> wrote:
> > Das ist 'ne gute Frage. Wenn Du es nicht reproduzieren
> > kannst, kann man es leider auch nicht richtig debuggen.
>
> Ich kann es evtl. reproduzieren wenn ich wieder an das
> Diskettenlaufwerk des Originalrechers rankomme - mit dem
> Medium geht ja nichts mehr.

Naja, es ist natürlich die Frage, ob es mit einem funktio-
nierenden Medium reproduzierbar ist.

> > Möglicherweise war die Datei auf der Floppy, die das diff
> > lesen wollte, bereits von dem I/O-Error betroffen, und
> > diff hat einen Bug, der in so einer Situation zuschlägt.
> > Das ist jetzt aber nur reine Spekulation.
>
> Nach Sichern der Summen hatte ich direkt auf dem System selbiges
> Kommando ausgeführt, was keine Probleme bereitete.

Das war aber ein anderes Floppy-Laufwerk, nicht wahr?

> Da müsste die
> Diskette einen Transportschaden erlitten haben - was ich mir
> schwerlich vorstellen kann.

Entweder das, oder die beiden Laufwerke sind geringfügig
unterschiedlich justiert, so daß die betreffende Floppy
auf dem ersten noch innerhalb der Toleranz war, auf dem
zweiten aber nicht mehr.

Floppies würde ich prinzipiell _alles_ zutrauen und nichts
ausschließen. Dafür habe ich mit denen schon zu viele ko-
mische Dinge erlebt.

> > > Kann ein coredump einfach so ein Filesystem schrotten?
> > Nö, aber eine kaputte Floppy kann das. :-)
>
> Dh. wenn der core nicht auf das Filesystem passt, dann wird auch
> nicht versucht ihn zu schreiben?

Doch, natürlich, es wird solange geschrieben wie es geht,
d.h. bis der Coredump fertig ist, oder bis irgendeine Art
von Fehler auftritt (ENOSPC oder EIO oder sonstwas).

> Ja, es sieht nach Harwaredefekt
> aus, aber ich dachte zuerst die Floppy ging wegen des coredump
> kaputt.

Nein, höchstwahrscheinlich wäre das gleich passiert, wenn
Du statt des Coredumps irgendeine andere große Datei darauf
zu kopieren versucht hättest.

> > > Sind dmesg-Meldungen irgendwo dokumentiert (für Leute die
> > > keinen Sourcecode lesen können)?
> > Ich finde, »hard error reading ...« ist relativ klar.
>
> Ja, schon, die von dir erwähnten
> > no_am == no address mark
> > no_dam == no data address mark
> meinte ich.

Achso, OK. Die sind aber eher von untergeordneter Bedeu-
tung. Kaputt ist kaputt.

> Die Daten sind egal, ich kann sie ja wieder erzeugen. Aber das
> klappt, mit diversen I/O-Fehlern bekomme ich ein Image.
>
> > Aber Vorsicht beim Mounten eines kaputten FS -- das kann
> > zu Panics führen.
>
> Mounten kann ich das eh nicht mehr, auch nicht readonly oder
> mit -f. (/dev/fd0: Input/output error)

Schon klar, aber Du könntest das Image mounten (oder es zu-
mindest versuchen). Wenn der Superblock und das Stammver-
zeichnis nicht gelitten haben, sollte das gehen (sofern es
UFS ist; aber bei FAT z.B. ist ein Mounten ohnehin unnötig,
da man ja die mtools verwenden kann, was erheblich sicherer
ist).

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"All that we see or seem is just a dream within a dream" (E. A. Poe)
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Sun 17 Mar 2002 - 10:23:47 CET

search this site