What's required to make removal of a mounted USB stick safe?
Bob Bishop
rb at gid.co.uk
Thu May 7 09:48:49 UTC 2015
> On 6 May 2015, at 22:59, Julian H. Stacey <jhs at berklix.com> wrote:
>
> Hi, Reference:
>> From: NGie Cooper <yaneurabeya at gmail.com>
>> Date: Wed, 6 May 2015 14:28:12 -0700
>
> NGie Cooper wrote:
>> On Wed, May 6, 2015 at 1:49 PM, Ryan Stone <rysto32 at gmail.com> wrote:
>>> Currently FreeBSD stands a fair chance at panicking if a mounted USB drive
>>> is removed while I/O is in flight. Does anybody know what work is involved
>>> to have the kernel safely recover from this case? Losing data from the
>>> drive is expected of course but there's no reason that the entire kernel
>>> has to crash.
>>>
>>> A co-worker has been looking at this but I don't feel that we understand
>>> the problem well enough to produce a real fix. All that we've been doing
>>> so far is papering over the explicit panics without having a full
>>> understanding of what we're doing.
>>
>> What version are you working on and how is the USB stick mounted (/, /mnt, etc)?
>
> Not a new problem, it' been so over 30 years with Unix.
> Remove media without umount & game over.
> Some Solutions:
> - Deep kernel work (dont hold your breath, see 30 above, & don't look at me :-)
> - Cobble up some C to run from user space, not as root,
> so that your UFS is not mounted, but accessed by user level
> programs (much like mwrite & mread for accessing DOS media of old)
> - man 8 amd : set a short timeout to auto unmount,
> it wont total solve your problem, but should lessen the frequency of panics.
> - Mount the USB media on a spare laptop running as an NFS+ AMD server,
> then access the FS via NFS from your real client big PC. When
> you pull the stick by accident forgetting its mounted, just the
> laptop crashes afte a bit, the AMD access on the other PC just
> hangs but doesnt crash.
> - Encourage A SOC (google summer of code) student to look at it,
> probably wont come to a solution though, see 30 above.
> - Toss money at the problem :-) If your company can afford some cash, either:
> - help fund FreeBSD Foundation & ask them to solve it,
> - Or pay some consultant somewhere to look at it, Here's a globaly
> geographicaly indexed list http://berklix.com/consultants/
> maybe there's one near your company ?
Hack up gnop(8) to report success upstream for every operation regardless.
(Maybe -r 0 -w 0 will do that already but I’d be surprised.)
> Cheers,
> Julian
> --
> Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com
> Indent previous with "> ". Reply Below as a play script.
> Send plain text, Not quoted-printable, HTML, or base64.
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>
--
Bob Bishop
rb at gid.co.uk
More information about the freebsd-hackers
mailing list