From owner-freebsd-current@freebsd.org Fri Aug 5 20:31:25 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C742ABAF7E7; Fri, 5 Aug 2016 20:31:25 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::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 8A20E1BB3; Fri, 5 Aug 2016 20:31:25 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi0-x234.google.com with SMTP id 4so169151875oih.2; Fri, 05 Aug 2016 13:31:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=aUCkL52ZP6HE9i/blPFMWgeRjHG6wtN4jDGBkFv1rkU=; b=PBFteg3eOG+OWioZ6crd+uwdt5VeiJwoQtSR1at7PKMi8/eNYtuknmr2Ix0XJSV+Em 8eyPd5Oau7NMLJNh9LicDCQrDxHsX+1VJEoynAGIT6yCdF3FL1qYbzkHcOwZJAWnYf1x kgsv2SS4JqlFrdpvTVlnq5RvtFeHP70LCF/l3FCrdhxcPiWmmDY7dv/jLHcT0pREGZgg g4W3RtVhWgD1RmAy+AOmXWRG1pLangH2rYkIbh0s4Fr0yomZJQl/hmzLMfPAnwWj8nW1 LPzo3UqhNT+iiwwGcS3IeJnb/CY3G1yaP1r1AMFNSliWwLKl09T4fo2rjssbJvPDSSPz TIIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=aUCkL52ZP6HE9i/blPFMWgeRjHG6wtN4jDGBkFv1rkU=; b=RdKpPcJBG1qTdZd1cNZ2ReAWgYcFJEKLWmTuEN7DK7twXFrTAbmfzLXynBbfta3AKH cl/pafBdt6BErVTxhysEbXLDE3qnM7lTzG8rOWyRlfcpiLahBw57qdD6z62GkA1mt/95 9MxXx0HAt5s6mJf34AX8SUWpE6WCLuyd0cPx0i2v/Fq2lA+YqskTzWviUiV5lysbDt+R HywIQw5U4Xj0k7+GEiqvrWOUp6dgxCmhLw81WajNvsv0FTbfKdspYFHuXRCd700rUc2w vF+mKdJXAT3sZCDoPdkF9dAeTQmFULJNKL+xCsIlKuDvusgBTtf1ascMWZydOcJJz/Rk 76Kw== X-Gm-Message-State: AEkoousp6Sa5xDqFgVcvGVXeNbOn2Q4hc+V9C0O2j9osnCvnhYDTKMBL2HKORORuKujIxSsvmfyvCCGwYIbeiQ== X-Received: by 10.157.14.5 with SMTP id c5mr51756662otc.55.1470429084674; Fri, 05 Aug 2016 13:31:24 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.202.196.149 with HTTP; Fri, 5 Aug 2016 13:31:24 -0700 (PDT) In-Reply-To: <04a12279-ab01-5f5c-d8d3-5571db07c229@FreeBSD.org> References: <3f79e88d-a519-0c8d-f16a-7c83460a37c1@FreeBSD.org> <04a12279-ab01-5f5c-d8d3-5571db07c229@FreeBSD.org> From: Alan Somers Date: Fri, 5 Aug 2016 14:31:24 -0600 X-Google-Sender-Auth: J8-f0HNy0CS4YjEA0TtoNjhUAbU Message-ID: Subject: Re: some [big] changes to ZPL (ZFS<->VFS ) To: Andriy Gapon Cc: FreeBSD Filesystems , FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 20:31:25 -0000 I'm not certain it's related, but on a head build at r303767 I see a LOR and a reproducible panic that involve the snapdir code. First, the LOR: $ zpool destroy foo lock order reversal: 1st 0xfffff800404c8b78 zfs (zfs) @ /usr/home/alans/freebsd/head/sys/kern/vfs_mount.c:1244 2nd 0xfffff800404c85f0 zfs_gfs (zfs_gfs) @ /usr/home/alans/freebsd/head/sys/cddl/contrib/opensolaris/uts/common/fs/gfs.c:484 stack backtrace: #0 0xffffffff80aa90b0 at witness_debugger+0x70 #1 0xffffffff80aa8fa4 at witness_checkorder+0xe54 #2 0xffffffff80a22072 at __lockmgr_args+0x4c2 #3 0xffffffff80af8e7c at vop_stdlock+0x3c #4 0xffffffff81018880 at VOP_LOCK1_APV+0xe0 #5 0xffffffff80b19f2a at _vn_lock+0x9a #6 0xffffffff821b9c53 at gfs_file_create+0x73 #7 0xffffffff821b9cfd at gfs_dir_create+0x1d #8 0xffffffff8228aa07 at zfsctl_mknode_snapdir+0x47 #9 0xffffffff821ba1a5 at gfs_dir_lookup+0x185 #10 0xffffffff821ba68d at gfs_vop_lookup+0x1d #11 0xffffffff82289a42 at zfsctl_root_lookup+0xf2 #12 0xffffffff8228a8c3 at zfsctl_umount_snapshots+0x83 #13 0xffffffff822a1d2b at zfs_umount+0x7b #14 0xffffffff80b02a14 at dounmount+0x6f4 #15 0xffffffff80b0228d at sys_unmount+0x35d #16 0xffffffff80ebbb7b at amd64_syscall+0x2db #17 0xffffffff80e9b72b at Xfast_syscall+0xfb Here's the panic: $ zpool create testpool da0 $ touch /testpool/testfile $ zfs snapshot testpool@testsnap $ cd /testpool/.zfs/snapshots Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 04 fault virtual address = 0x8 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80b19f1c stack pointer = 0x28:0xfffffe0b54bf7430 frame pointer = 0x28:0xfffffe0b54bf74a0 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 = 966 (bash) trap number = 12 panic: page fault cpuid = 2 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0b54bf6fc0 vpanic() at vpanic+0x182/frame 0xfffffe0b54bf7040 panic() at panic+0x43/frame 0xfffffe0b54bf70a0 trap_fatal() at trap_fatal+0x351/frame 0xfffffe0b54bf7100 trap_pfault() at trap_pfault+0x1fd/frame 0xfffffe0b54bf7160 trap() at trap+0x284/frame 0xfffffe0b54bf7370 calltrap() at calltrap+0x8/frame 0xfffffe0b54bf7370 --- trap 0xc, rip = 0xffffffff80b19f1c, rsp = 0xfffffe0b54bf7440, rbp = 0xfffffe0b54bf74a0 --- _vn_lock() at _vn_lock+0x8c/frame 0xfffffe0b54bf74a0 zfs_lookup() at zfs_lookup+0x50d/frame 0xfffffe0b54bf7540 zfs_freebsd_lookup() at zfs_freebsd_lookup+0x91/frame 0xfffffe0b54bf7680 VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0xda/frame 0xfffffe0b54bf76b0 vfs_cache_lookup() at vfs_cache_lookup+0xd6/frame 0xfffffe0b54bf7710 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xda/frame 0xfffffe0b54bf7740 lookup() at lookup+0x5a2/frame 0xfffffe0b54bf77d0 namei() at namei+0x5b2/frame 0xfffffe0b54bf7890 kern_statat() at kern_statat+0xa8/frame 0xfffffe0b54bf7a40 sys_stat() at sys_stat+0x2d/frame 0xfffffe0b54bf7ae0 amd64_syscall() at amd64_syscall+0x2db/frame 0xfffffe0b54bf7bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0b54bf7bf0 I can provide core files, test scripts, whatever you need. Thanks for tackling this difficult problem. -Alan On Fri, Aug 5, 2016 at 12:36 AM, Andriy Gapon wrote: > On 03/08/2016 17:25, Andriy Gapon wrote: >> Another change that was not strictly required and which is probably too >> intrusive is killing the support for case insensitive operations. My >> thinking was that FreeBSD VFS does not provide support for those anyway. >> But I'll probably restore the code, at least in the bottom half of the >> ZPL, before committing the change. > > It turned out that most of the removed code was dead anyway and it took > just a few lines of code to restore support for case-insensitive > filesystems. Filesystems with mixed case sensitivity behave exactly the > same as case-sensitive filesystem as it has always been the case on FreeBSD. > > Anyway the big change has just been committed: > https://svnweb.freebsd.org/changeset/base/303763 > Please test away. > > Another note is that the filesystem name cache is now disabled for case > insensitive filesystems and filesystems with normalization other than > none. That may hurt the lookup performance, but should ensure > correctness of operations. > > -- > Andriy Gapon > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"