freebsd stable - Jul 2016 - Not-so stable if you take a CAM error....

Got a (nasty) surprise this afternoon on my sandbox machine.

I was updating some Raspberry Pi2 machines which involved taking the sd
card out, sticking it in an adapter and plugging it into the sandbox,
then mounting the partition and using rsync.

Unfortunately one of the cards was, unknown to me, bad and returned a
write error during the update.

The machine panic'd immediately after the CAM write error popped up.

I was quite surprised by this, since (1) the SD card was (of course)
mounted as a UFS filesystem; it shows up as a CAM device, (2) the
machine itself is running off a ZFS root on a normal host-adapter and
thus there is no comingling of the buffer cache and (3) there were no
images being run from (can't, wrong architecture!) nor any system I/O
(e.g. pagefile) going to the SD card.

I certainly understand that under some circumstances (maybe even most
circumstances) taking a hard I/O error to a system device is going to
hose you and a panic() is arguably "least astonishment" when the price
of being wrong might be a corrupted system file or worse (e.g. corrupted
paged-out RSS, etc.)  But I didn't expect a panic out a failed write to
a device that is mounted and being used purely for data.

I don't have a crash dump but can almost-certainly reproduce this if
it's something that shouldn't happen and thus merits investigation.

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2996 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20160710/3e0a7301/attachment.bin>

On Mon, 11 Jul 2016 02:54:38 +0200, Karl Denninger <karl at denninger.net>
wrote:
> Got a (nasty) surprise this afternoon on my sandbox machine.
>
> I was updating some Raspberry Pi2 machines which involved taking the sd
> card out, sticking it in an adapter and plugging it into the sandbox,
> then mounting the partition and using rsync.
>
> Unfortunately one of the cards was, unknown to me, bad and returned a
> write error during the update.
>
> The machine panic'd immediately after the CAM write error popped up.
>
> I was quite surprised by this, since (1) the SD card was (of course)
> mounted as a UFS filesystem; it shows up as a CAM device, (2) the
> machine itself is running off a ZFS root on a normal host-adapter and
> thus there is no comingling of the buffer cache and (3) there were no
> images being run from (can't, wrong architecture!) nor any system I/O
> (e.g. pagefile) going to the SD card.
>
> I certainly understand that under some circumstances (maybe even most
> circumstances) taking a hard I/O error to a system device is going to
> hose you and a panic() is arguably "least astonishment" when the
price
> of being wrong might be a corrupted system file or worse (e.g. corrupted
> paged-out RSS, etc.)  But I didn't expect a panic out a failed write to
> a device that is mounted and being used purely for data.
>
> I don't have a crash dump but can almost-certainly reproduce this if
> it's something that shouldn't happen and thus merits investigation.
>
Hi,

I understand you are surprised by this. I don't think it is the way it  
should work.
Is there _any_ debugging information for people to use and try to help  
you? Like which FreeBSD version are you running? Which FreeBSD version was  
used to create the UFS fs? Does it use softupdates (SU) or also journaling  
(SU+J)?
Maybe some output of dmesg? Or type of SD-card and reader. Other people  
might have similar problems with similar hardware.

Regards,
Ronald.