kernel panic(?) trying to copy data off failed drive with dd

[Oliver Fromme]

Greg Lane <greg.lane at internode.on.net> wrote:
 > Michael P. Soulier <msoulier at digitaltorque.ca> wrote:
 > > 
 > > Regardless, file a bug report. The box should never hang, or reboot. 
 > 
 > Is this the case?  I had another box (a piece of crap I played around on) 
 > that had a failing disk, and this would bring the machine down. So I didn't 
 > think this was necessarily unusual.  However, on the previous occasion the disk 
 > was the root file system with swap on it, whereas in this case, the disk is 
 > only a data disk, not any part of the OS.  
 > 
 > Are you saying that the box should never hang or reboot, but should 
 > recover from the error, and whatever command was running should fail and 
 > return an error message?

It depends.  Usually the system should _not_ panic in case
of software errors.  For example, when running fsck on a
broken file system, it should not cause a panic.  However,
mounting a broken file system might cause a panic or other
misbehaviour, which is clearly documented as a bug in the
mount(8) manpage:  "It is possible for a corrupted file
system to cause a crash."

However, in the case of hardware failures (including broken
disk drives), anything bad can happen, ranging from silent
data corruption to panics or cold freezes.  Any many cases
the operating system simply has no chance to deal with it
properly.

So, if your panic is caused purely by software error, and
it's not already known and documented, filing a PR might be
a good idea.  But if faulty hardware is involved, sending
a PR is probably useless.

Best regards
   Oliver

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

"A language that doesn't have everything is actually easier
to program in than some that do."
        -- Dennis M. Ritchie