On 7/11/2016 12:39, Ian Lepore wrote: > On Mon, 2016-07-11 at 12:30 -0500, Karl Denninger wrote: >> 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 < >>>> k...@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()? >> > Patches welcome. > > -- Ian Any hints on where the routine(s) live that would forcibly detach a volume? (I'll go digging as well but shortening the time would help :))
-- Karl Denninger k...@denninger.net <mailto:k...@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/
smime.p7s
Description: S/MIME Cryptographic Signature
