Date: Mon, 11 Jul 2016 12:30:34 -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: <f22ab40d-42f0-78a3-d3a7-945387259109@denninger.net> In-Reply-To: <1468254746.72182.121.camel@freebsd.org> 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> <1468254746.72182.121.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
On 7/11/2016 11:32, Ian Lepore wrote:
> On Mon, 2016-07-11 at 09:50 -0400, 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.
>>
> 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
Why not force-detach the volume that takes the error instead of a panic()?
That would lead to a panic if the detached volume was the system volume
(obviously) but for a data volume it would simply result in it being
forcibly unmounted (and dirty, so if it's corrupt it will get caught
when reattached.)
It seems that the current paradigm of saying "screw you, panic the
machine" violates the principle of least astonishment and is overly
punitive vis-a-vis necessity. Refusing further I/O because the volume
may now have a corrupt filesystem appears to be facially reasonable, but
that doesn't necessarily wind up being fatal the system itself -- it is
if that's the system volume and is not covered by some sort of
redundancy, obviously, but it's not in all cases.
(Note that you can't just unmount the filesystem involved in the error;
it has to be the volume that gets forcibly detached and whatever flows
through from that you have to live with. The reason is that on any sort
of solid-state media the OS has zero control over zoning and write
amplification means far more the data you were actually modifying may
have been lost -- it's entirely possible that *several megabytes* of
data just got trashed by the write error, and it's even possible that
the block(s) involved cross a filesystem boundary!)
--
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
160711173034Z0O *H
1B@C-E>ȗ 2
"{3I+dlp+e^> W-] 6 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
diGe{IЙPivlmTʗYT1Wq~PߩS\s }r ]a
Hva7<he Yo@%NrU!#QO yyr氼v e2~=_ u<s%%Q^_ݷ ~=mn?,?:dYE~p zm:$5UES#l#$DԑA0iGm ;DSi=ӄ2w vHif ql {Bl_n:LuT}5
0q bRC"V(+r]6!ŎY\dD &VYk*HY5_"W[J<QH( _ܳPzdEW/q&NW 9ȐXҷI ;ȕ.,iBG?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f22ab40d-42f0-78a3-d3a7-945387259109>