What's required to make removal of a mounted USB stick safe?

[Ryan Stone]

On Thu, May 7, 2015 at 2:23 AM, Edward Tomasz Napierała <trasz at freebsd.org>
wrote:

>
> I've spent some time on this few years ago, and got it to work, except for
> one case: UFS with softupdates.  It's possible that some regressions have
> been introduced since then.  What's the filesystem?  Do you have a
> backtrace?
>
>
I've been running our stress script* on 10.1-RELEASE, and the situation
does seem to be greatly improved.  I did hit this (using msdosfs):

Fatal trap 12: page fault while in kernel mode
cpuid = 6; apic id = 06
fault virtual address   = 0x18
fault code              = supervisor write data, page not present
instruction pointer     = 0x20:0xffffffff805f5b31
stack pointer           = 0x28:0xfffffe060dc4a2b0
frame pointer           = 0x28:0xfffffe060dc4a2d0
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 54741 (dd)
trap number             = 12
panic: page fault
rasum detected 0 total errors
cpuid = 4
curthread = dd/dd (54741/100358)
cpu_ticks = 35606492530712
KDB: stack backtrace:
db_trace_self_wrapper() at 0xffffffff8030d5ab =
db_trace_self_wrapper+0x2b/frame 0xfffffe060dc49e60
panic() at 0xffffffff805f7e56 = panic+0x216/frame 0xfffffe060dc49ee0
trap_fatal() at 0xffffffff8081489f = trap_fatal+0x38f/frame
0xfffffe060dc49f40
trap_pfault() at 0xffffffff80814af6 = trap_pfault+0x246/frame
0xfffffe060dc49fe0
trap() at 0xffffffff80814227 = trap+0x4e7/frame 0xfffffe060dc4a1f0
calltrap() at 0xffffffff807fa052 = calltrap+0x8/frame 0xfffffe060dc4a1f0
--- trap 0xc, rip = 0xffffffff805f5b31, rsp = 0xfffffe060dc4a2b0, rbp =
0xfffffe060dc4a2d0 ---
_rw_wlock_cookie() at 0xffffffff805f5b31 = _rw_wlock_cookie+0x21/frame
0xfffffe060dc4a2d0
allocbuf() at 0xffffffff80677e42 = allocbuf+0x2f2/frame 0xfffffe060dc4a340
getblk() at 0xffffffff806766e8 = getblk+0x658/frame 0xfffffe060dc4a400
breadn_flags() at 0xffffffff80676f6d = breadn_flags+0x2d/frame
0xfffffe060dc4a440
chainalloc() at 0xffffffff8051cec5 = chainalloc+0x185/frame
0xfffffe060dc4a4e0
clusteralloc() at 0xffffffff8051c37a = clusteralloc+0x3ea/frame
0xfffffe060dc4a570
extendfile() at 0xffffffff8051c9de = extendfile+0xee/frame
0xfffffe060dc4a5e0
msdosfs_write() at 0xffffffff805220a5 = msdosfs_write+0x135/frame
0xfffffe060dc4a6a0
VOP_WRITE_APV() at 0xffffffff80883765 = VOP_WRITE_APV+0x145/frame
0xfffffe060dc4a7b0
vn_write() at 0xffffffff8069ec72 = vn_write+0x2f2/frame 0xfffffe060dc4a830
vn_io_fault() at 0xffffffff8069af6b = vn_io_fault+0x10b/frame
0xfffffe060dc4a8b0
dofilewrite() at 0xffffffff80646658 = dofilewrite+0x88/frame
0xfffffe060dc4a900
kern_writev() at 0xffffffff80646388 = kern_writev+0x68/frame
0xfffffe060dc4a950
sys_write() at 0xffffffff80646313 = sys_write+0x63/frame 0xfffffe060dc4a9a0
amd64_syscall() at 0xffffffff80814fd4 = amd64_syscall+0x224/frame
0xfffffe060dc4aab0
Xfast_syscall() at 0xffffffff807fa33b = Xfast_syscall+0xfb/frame
0xfffffe060dc4aab0
--- syscall (4, FreeBSD ELF64, sys_write), rip = 0x300967efa, rsp =
0x7fffffffea88, rbp = 0x7fffffffeab0 ---
Uptime: 4h4m57s


* Basically it fsck's the USB drive, mounts it and cleans up the LOST.DIR
directory, umounts, mounts it again, writes a 1GB file to it and then yanks
the power from the USB device 20s into the transfer.  It does this in a
loop.