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