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

On Mon, Jul 11, 2016 at 9:46 AM, Karl Denninger <karl at denninger.net>
wrote:
> Here's the backtrace ... sounds like expected behavior, which is not-so
> good all-in for a situation like this.  I guess the strategy is to turn
> off softupdates before attempting such an update so as not to crash the
> host machine if there's a problem with the card.
>
I would tend to assume that removable media should not have softupdates
enabled. Even with properly working media, it's practically begging for
corruption.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at
sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

On 7/11/2016 08:50, Brandon Allbery wrote:
> On Mon, Jul 11, 2016 at 9:46 AM, Karl Denninger <karl at
denninger.net> wrote:
>
>> Here's the backtrace ... sounds like expected behavior, which is
not-so
>> good all-in for a situation like this.  I guess the strategy is to turn
>> off softupdates before attempting such an update so as not to crash the
>> host machine if there's a problem with the card.
>>
> I would tend to assume that removable media should not have softupdates
> enabled. Even with properly working media, it's practically begging for
> corruption.
But it's not normally "removable media" -- which is the point.

The operation in question occurs when you take a storage device out of
an embedded machine (where softupdates has a material positive
performance impact in that it obviates the need for most fsck-on-boot
operations before the system comes up) and mount it temporarily to
update it on a second device.

It appears, however, that to prevent crashing the updating machine you
first need to make sure softupdates is off (tunefs it) and then turn it
back on when done -- otherwise you risk this outcome in the event there
is an unknown write error lurking around.

Oh, and for flash-based media those errors are *frequently* going to be
unknown in advance -- I suspect the reason it occurred is that the card
in question ran out of reallocation blocks and took a write error which
would normally cause it to use a spare, but it has no spares left and
thus returns a hard error.  The existing data on the card at that point
is still readable, but you can't make changes since a write on such a
card invokes a read/erase/write cycle.

-- 
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/20160711/7a0bb6fd/attachment.bin>

On Mon, 2016-07-11 at 09:50 -0400, Brandon Allbery
wrote:
> On Mon, Jul 11, 2016 at 9:46 AM, Karl Denninger <karl at
denninger.net>
> wrote:
> 
> > Here's the backtrace ... sounds like expected behavior, which is
> > not-so
> > good all-in for a situation like this.  I guess the strategy is to
> > turn
> > off softupdates before attempting such an update so as not to crash
> > the
> > host machine if there's a problem with the card.
> > 
> 
> I would tend to assume that removable media should not have
> softupdates
> enabled. Even with properly working media, it's practically begging
> for
> corruption.
> 
Writing to an sdcard without softupdates enabled will be an exercise in
patience.  Like, come back next week and maybe it'll be done.

The only thing that comes to mind with this is maybe some sort of mount
flag to say you're willing to live with any amount of filesystem
corruption in lieu of panicking.  I'm not sure how easy/practical that
would be to implement, though.

-- Ian