From owner-freebsd-hackers@FreeBSD.ORG Thu May 7 19:46:40 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A131A79B; Thu, 7 May 2015 19:46:40 +0000 (UTC) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 690A7157A; Thu, 7 May 2015 19:46:40 +0000 (UTC) Received: by igbsb11 with SMTP id sb11so3480358igb.0; Thu, 07 May 2015 12:46:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YqIO4wUdwtpgOrSu4APvgYW4LHRF4LyhhoyAHZEgjlI=; b=ju+I1Gpfx++xJLIHTzpEqoIRxIKtiicN7j9CHPFNkyu6wkGK28NCVa8N19JFVVyLtY 2iZRQ81NQhQBN7i05OZuIdGCHbXclkntgAvk6DYWefeTKsMaaGs1Rd7DRENsIDOrHQ9A mpbSzhzENhDrKjFXlqXQ3bMp+e7Scp9SAqcboDtO4JDDZ5uNjdVnPtsbPQ5ZPvpaMcH5 Pw1o6nco6vnnSOgaOavD//CGXaDERE34o7nZUN+DtXS7yDxTkkxZl5eRI4DYjximPlKz 3uXnBEadAzhqjrYXgWGUGlnGhZxGscyjlwKwLludmwQlH+ucM8WUin7jxi/HFKGHpP1G TG/g== MIME-Version: 1.0 X-Received: by 10.50.21.1 with SMTP id r1mr359590ige.46.1431027999748; Thu, 07 May 2015 12:46:39 -0700 (PDT) Received: by 10.107.40.194 with HTTP; Thu, 7 May 2015 12:46:39 -0700 (PDT) In-Reply-To: <1306708F-0872-4D02-9C88-70F683018C39@FreeBSD.org> References: <1306708F-0872-4D02-9C88-70F683018C39@FreeBSD.org> Date: Thu, 7 May 2015 15:46:39 -0400 Message-ID: Subject: Re: What's required to make removal of a mounted USB stick safe? From: Ryan Stone To: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 19:46:40 -0000 On Thu, May 7, 2015 at 2:23 AM, Edward Tomasz Napiera=C5=82a wrote: > > I've spent some time on this few years ago, and got it to work, except fo= r > 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 =3D 6; apic id =3D 06 fault virtual address =3D 0x18 fault code =3D supervisor write data, page not present instruction pointer =3D 0x20:0xffffffff805f5b31 stack pointer =3D 0x28:0xfffffe060dc4a2b0 frame pointer =3D 0x28:0xfffffe060dc4a2d0 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 54741 (dd) trap number =3D 12 panic: page fault rasum detected 0 total errors cpuid =3D 4 curthread =3D dd/dd (54741/100358) cpu_ticks =3D 35606492530712 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff8030d5ab =3D db_trace_self_wrapper+0x2b/frame 0xfffffe060dc49e60 panic() at 0xffffffff805f7e56 =3D panic+0x216/frame 0xfffffe060dc49ee0 trap_fatal() at 0xffffffff8081489f =3D trap_fatal+0x38f/frame 0xfffffe060dc49f40 trap_pfault() at 0xffffffff80814af6 =3D trap_pfault+0x246/frame 0xfffffe060dc49fe0 trap() at 0xffffffff80814227 =3D trap+0x4e7/frame 0xfffffe060dc4a1f0 calltrap() at 0xffffffff807fa052 =3D calltrap+0x8/frame 0xfffffe060dc4a1f0 --- trap 0xc, rip =3D 0xffffffff805f5b31, rsp =3D 0xfffffe060dc4a2b0, rbp = =3D 0xfffffe060dc4a2d0 --- _rw_wlock_cookie() at 0xffffffff805f5b31 =3D _rw_wlock_cookie+0x21/frame 0xfffffe060dc4a2d0 allocbuf() at 0xffffffff80677e42 =3D allocbuf+0x2f2/frame 0xfffffe060dc4a34= 0 getblk() at 0xffffffff806766e8 =3D getblk+0x658/frame 0xfffffe060dc4a400 breadn_flags() at 0xffffffff80676f6d =3D breadn_flags+0x2d/frame 0xfffffe060dc4a440 chainalloc() at 0xffffffff8051cec5 =3D chainalloc+0x185/frame 0xfffffe060dc4a4e0 clusteralloc() at 0xffffffff8051c37a =3D clusteralloc+0x3ea/frame 0xfffffe060dc4a570 extendfile() at 0xffffffff8051c9de =3D extendfile+0xee/frame 0xfffffe060dc4a5e0 msdosfs_write() at 0xffffffff805220a5 =3D msdosfs_write+0x135/frame 0xfffffe060dc4a6a0 VOP_WRITE_APV() at 0xffffffff80883765 =3D VOP_WRITE_APV+0x145/frame 0xfffffe060dc4a7b0 vn_write() at 0xffffffff8069ec72 =3D vn_write+0x2f2/frame 0xfffffe060dc4a83= 0 vn_io_fault() at 0xffffffff8069af6b =3D vn_io_fault+0x10b/frame 0xfffffe060dc4a8b0 dofilewrite() at 0xffffffff80646658 =3D dofilewrite+0x88/frame 0xfffffe060dc4a900 kern_writev() at 0xffffffff80646388 =3D kern_writev+0x68/frame 0xfffffe060dc4a950 sys_write() at 0xffffffff80646313 =3D sys_write+0x63/frame 0xfffffe060dc4a9= a0 amd64_syscall() at 0xffffffff80814fd4 =3D amd64_syscall+0x224/frame 0xfffffe060dc4aab0 Xfast_syscall() at 0xffffffff807fa33b =3D Xfast_syscall+0xfb/frame 0xfffffe060dc4aab0 --- syscall (4, FreeBSD ELF64, sys_write), rip =3D 0x300967efa, rsp =3D 0x7fffffffea88, rbp =3D 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.