Date: Mon, 11 Jul 2016 08:56:41 -0500 From: Karl Denninger <karl@denninger.net> To: freebsd-stable@freebsd.org Subject: Re: Not-so stable if you take a CAM error.... Message-ID: <155d322e-01c9-ef36-bc68-5c3a58835bb6@denninger.net> In-Reply-To: <CAKFCL4WrRS1ic1CZqcmbCEnsrD2pkh4VHPBFyB%2B-3NaNJZ%2BJkw@mail.gmail.com> References: <2b0c454b-c1a0-4b5b-e778-bf0939e90ae1@denninger.net> <op.ykfe1fvbkndu52@ronaldradial.radialsg.local> <6e9c07e1-12a6-a7cd-f775-6b0fe5a706bc@denninger.net> <1468243977.72182.118.camel@freebsd.org> <877f5e8e-c1e7-6fb0-6ceb-031ce3e68582@denninger.net> <CAKFCL4WrRS1ic1CZqcmbCEnsrD2pkh4VHPBFyB%2B-3NaNJZ%2BJkw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
On 7/11/2016 08:50, Brandon Allbery wrote:
> On Mon, Jul 11, 2016 at 9:46 AM, Karl Denninger <karl@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@denninger.net <mailto:karl@denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
[-- Attachment #2 --]
0 *H
010
`He 0 *H
_0[0C)0
*H
01 0 UUS10UFlorida10U Niceville10U
Cuda Systems LLC1 0UCuda Systems LLC CA1"0 *H
Cuda Systems LLC CA0
150421022159Z
200419022159Z0Z1 0 UUS10UFlorida10U
Cuda Systems LLC1 0 UKarl Denninger (OCSP)0"0
*H
0
X@vkY
Tq/vE]5#֯MX \8LJ/V?5Da+
sJc*/r{ȼnS+ w")ąZ^DtdCOZ ~7Q '@a#ijc۴oZdB&!Ӝ-< ? HN5y
5}F|e f"V لio74zn">a1qWuɖbFeGE&3(KhixG3!#e_XƬ Ϝ/,$+;4y 'Bz<qT9_?rRUpn5
Jn&Rx/p Jyel*pN8/#9u/YP EC)TY>~/˘N[vyiDKˉ ,^" ?$T8 v& K%z8C @?K{9f`+@,| Mbia 007++0)0'+0http://cudasystems.net:88880 U 0 0 `HB0 U 0, `HB
OpenSSL Generated Certificate0 U -h\Ff Y0 U #0$q}ݽʒm50 U 0karl@denninger.net0
*H
Owbabɺx&Uk[ (Oj!%p MQ0I!#QH}.>~2&D}<wm_>V6 v ]f>=Nn+8;q wfΰ/RLyUG#b}n!Dր _up|_ǰc/%ۥ
nN8:d;-UJd/m1~VނיnN I˾$tF1&}|?q?\đXԑ&\4V<lKۮ3%Am_(q -(cAeGX)f}-˥6cv~Kg8m~v ;|9:-iAPқ6ېn-.)<[$KJtt/L4ᖣ^Cmu4vb{+BG$M0c\[MR|0FԸP&78"4p# }D Z9;V9#>Sw"[UP710001 0 UUS10UFlorida10U Niceville10U
Cuda Systems LLC1 0UCuda Systems LLC CA1"0 *H
Cuda Systems LLC CA)0
`He M0 *H
1 *H
0 *H
1
160711135641Z0O *H
1B@,d,9\Oxzp9#"q cᥦS R?h@L~0l *H
1_0]0 `He*0 `He0
*H
0*H
0
*H
@0+0
*H
(0 +71001 0 UUS10UFlorida10U Niceville10U
Cuda Systems LLC1 0UCuda Systems LLC CA1"0 *H
Cuda Systems LLC CA)0 *H
101 0 UUS10UFlorida10U Niceville10U
Cuda Systems LLC1 0UCuda Systems LLC CA1"0 *H
Cuda Systems LLC CA)0
*H
8X0ڸs(7.8B}a! RXkG=>nTtH&hHXw 9cgEzBLB*G1ČQ`~S쮍d;M'~ ȓ9h3eҀxM+(CeE$p=1%%8 -S?k~O4Ž14<YH-GF ;|| 9[+bfiE 1RR#}HIBYK^W]xHoM}L SAN1 E_@l ?̟ foy8\^({v3:rP{xT'44 q|]W/!x$v 7ī>X>Lãt|;^JdW4|<OMGkkFwȆ;tǎG=O)4<4ǝo|R#h?v2I ՛9q
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?155d322e-01c9-ef36-bc68-5c3a58835bb6>