From owner-freebsd-fs@freebsd.org Sun Dec 20 17:21:26 2015 Return-Path: Delivered-To: freebsd-fs@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 EF535A4D8B9 for ; Sun, 20 Dec 2015 17:21:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E02501B65 for ; Sun, 20 Dec 2015 17:21:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tBKHLQJ8017770 for ; Sun, 20 Dec 2015 17:21:26 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 180438] [smbfs] [patch] mount_smbfs fails on arm because of wrong endianess assumption in libsmb Date: Sun, 20 Dec 2015 17:21:26 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: pi@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2015 17:21:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=180438 Kurt Jaeger changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pi@FreeBSD.org --- Comment #2 from Kurt Jaeger --- See https://reviews.freebsd.org/D4622 for a patch. See also https://lists.freebsd.org/pipermail/freebsd-arm/2015-December/012841.html -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Sun Dec 20 17:22:38 2015 Return-Path: Delivered-To: freebsd-fs@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 E757BA4DAEC for ; Sun, 20 Dec 2015 17:22:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D839E1D49 for ; Sun, 20 Dec 2015 17:22:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tBKHMcQZ022183 for ; Sun, 20 Dec 2015 17:22:38 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 180438] [smbfs] [patch] mount_smbfs fails on arm because of wrong endianess assumption in libsmb Date: Sun, 20 Dec 2015 17:22:39 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: pi@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: see_also Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2015 17:22:39 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=180438 Kurt Jaeger changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.freebsd.org/bu | |gzilla/show_bug.cgi?id=1894 | |15 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Mon Dec 21 16:49:04 2015 Return-Path: Delivered-To: freebsd-fs@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 66DB2A4DF1F for ; Mon, 21 Dec 2015 16:49:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 58026175A for ; Mon, 21 Dec 2015 16:49:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tBLGn4F3009281 for ; Mon, 21 Dec 2015 16:49:04 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 205483] unionfs panics when used with nullfs Date: Mon, 21 Dec 2015 16:49:04 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2015 16:49:04 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205483 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Mon Dec 21 17:17:45 2015 Return-Path: Delivered-To: freebsd-fs@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 A7E6FA4E49E for ; Mon, 21 Dec 2015 17:17:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 98A5F1152 for ; Mon, 21 Dec 2015 17:17:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tBLHHjgT099891 for ; Mon, 21 Dec 2015 17:17:45 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 180438] [smbfs] [patch] mount_smbfs fails on arm because of wrong endianess assumption in libsmb Date: Mon, 21 Dec 2015 17:17:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2015 17:17:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=180438 --- Comment #3 from commit-hook@freebsd.org --- A commit references this bug: Author: ian Date: Mon Dec 21 17:17:00 UTC 2015 New revision: 292552 URL: https://svnweb.freebsd.org/changeset/base/292552 Log: Avoid unaligned memory accesses when encoding netbios names in libsmb. The current code for encoding a netbios name converts each byte to a 16-bit value and stores the result by casting a char* to u_short*, resulting in alignment faults on strict-alignment platforms. This change reimplements the encoding routine using only byte accesses to memory. There is no particular reason to work with 16-bit values just because the encoding process creates two bytes of output for every byte of input. Working a byte at at time also avoids endian problems for big-endian platforms. PR: 180438 PR: 189415 Differential Revision: https://reviews.freebsd.org/D4622 Changes: head/contrib/smbfs/lib/smb/nb_name.c -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Mon Dec 21 17:40:10 2015 Return-Path: Delivered-To: freebsd-fs@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 CC34BA4D206 for ; Mon, 21 Dec 2015 17:40:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BC7CB1B1E for ; Mon, 21 Dec 2015 17:40:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tBLHeAkD040740 for ; Mon, 21 Dec 2015 17:40:10 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 180438] [smbfs] [patch] mount_smbfs fails on arm because of wrong endianess assumption in libsmb Date: Mon, 21 Dec 2015 17:40:11 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ian@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: ian@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2015 17:40:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=180438 Ian Lepore changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ian@FreeBSD.org Assignee|freebsd-fs@FreeBSD.org |ian@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Mon Dec 21 17:44:40 2015 Return-Path: Delivered-To: freebsd-fs@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 76858A4D617 for ; Mon, 21 Dec 2015 17:44:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4E90B1F8B for ; Mon, 21 Dec 2015 17:44:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tBLHiei6052458 for ; Mon, 21 Dec 2015 17:44:40 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 205483] unionfs panics when used with nullfs Date: Mon, 21 Dec 2015 17:44:40 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: c.kworr@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2015 17:44:40 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205483 c.kworr@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |c.kworr@gmail.com --- Comment #1 from c.kworr@gmail.com --- Same to me. I'm using unionfs/nullfs to secure wordpress installations. Fstab sample: /usr/local/www/wordpress /home/price-/www/site1/articles nullfs ro,late 0 0 /home/price-/www/site1.local /home/price-/www/site1/articles unionfs ro,late 0 0 /home/price-/www/site1/wp-content/uploads /home/price-/www/site1/articles/wp-content/uploads nullfs rw,late 0 0 Recently I added fourth site and directory with uploads just failed to become writable even though all the mounts were successful. When I tried to move back to previous configuration utilizing only unionfs via `below` mounting: /usr/local/www/wordpress /home/price-/www/site1/articles below ro,late,below 0 0 /home/price-/www/site1.local /home/price-/www/site1/articles unionfs ro,late 0 0 /home/price-/www/site1.local/wp-content/uploads /home/price-/www/site1/articles/wp-content/uploads unionfs rw,late 0 0 It just died with: panic: __lockmgr_args:downgrade a recursed lockmgr zfs @ /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1936 cpuid = 6 KDB: stack backtrace: #0 0xffffffff803cf770 at kdb_backtrace+0x60 #1 0xffffffff80396086 at vpanic+0x126 #2 0xffffffff80395f53 at panic+0x43 #3 0xffffffff80374a1d at __lockmgr_args+0xe6d #4 0xffffffff80425d1c at vop_stdlock+0x3c #5 0xffffffff80627c0b at VOP_LOCK1_APV+0xab #6 0xffffffff811a2ced at unionfs_lock+0x3cd #7 0xffffffff80627c0b at VOP_LOCK1_APV+0xab #8 0xffffffff811a2c03 at unionfs_lock+0x2e3 #9 0xffffffff80627c0b at VOP_LOCK1_APV+0xab #10 0xffffffff80444003 at _vn_lock+0x43 #11 0xffffffff811a2508 at unionfs_readdir+0x148 #12 0xffffffff806277c7 at VOP_READDIR_APV+0xa7 #13 0xffffffff8044159c at kern_getdirentries+0x21c #14 0xffffffff80441358 at sys_getdirentries+0x28 #15 0xffffffff805eeaf7 at amd64_syscall+0x357 #16 0xffffffff805d3a1b at Xfast_syscall+0xfb I know this is not exactly the same situation as the reporters but we do share a common situation where (I suppose this is unionfs) it fails: joining more than two filesystems by the same mountpoint. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Mon Dec 21 18:12:00 2015 Return-Path: Delivered-To: freebsd-fs@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 99CC9A4E8D5 for ; Mon, 21 Dec 2015 18:12:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8B16A10A6 for ; Mon, 21 Dec 2015 18:12:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tBLIC049045895 for ; Mon, 21 Dec 2015 18:12:00 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 205483] unionfs panics when used with nullfs Date: Mon, 21 Dec 2015 18:12:00 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: yuri@rawbw.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2015 18:12:00 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205483 --- Comment #2 from yuri@rawbw.com --- Did you try doing the same with only unionfs instead? As I learned now, man page mount_unionfs says unionfs is broken. I just don't know to what extent. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Mon Dec 21 18:56:53 2015 Return-Path: Delivered-To: freebsd-fs@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 1B5F7A4FB14 for ; Mon, 21 Dec 2015 18:56:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0CBC8113D for ; Mon, 21 Dec 2015 18:56:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tBLIuqw6071733 for ; Mon, 21 Dec 2015 18:56:52 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 205483] unionfs panics when used with nullfs Date: Mon, 21 Dec 2015 18:56:53 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: c.kworr@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2015 18:56:53 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205483 --- Comment #3 from c.kworr@gmail.com --- AFAIR it was sometimes unstable under load so I was searching for any other to ditch unionfs. I'm still thinking about trying fusefs-unionfs though... -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Mon Dec 21 19:06:16 2015 Return-Path: Delivered-To: freebsd-fs@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 F29D1A4E009 for ; Mon, 21 Dec 2015 19:06:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E3E931735 for ; Mon, 21 Dec 2015 19:06:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tBLJ6GZc024782 for ; Mon, 21 Dec 2015 19:06:16 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 205483] unionfs panics when used with nullfs Date: Mon, 21 Dec 2015 19:06:17 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: yuri@rawbw.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2015 19:06:17 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205483 --- Comment #4 from yuri@rawbw.com --- fusefs-* is probably much slower. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Mon Dec 21 23:37:39 2015 Return-Path: Delivered-To: freebsd-fs@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 5CD3CA4FEA5 for ; Mon, 21 Dec 2015 23:37:39 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 1EE461814 for ; Mon, 21 Dec 2015 23:37:38 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:45cvgRHXbu3fJN+WPIClJ51GYnF86YWxBRYc798ds5kLTJ75o8SwAkXT6L1XgUPTWs2DsrQf27SQ6/iocFdDyKjCmUhKSIZLWR4BhJdetC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TWM5DIfUi/yKRBybrysXNWC0YLvj6ibwN76XUZhvHKFe7R8LRG7/036l/I9ps9cEJs30QbDuXBSeu5blitCLFOXmAvgtI/rpMYwu3cYh/V0+dRNXK/hc+E2VvQMAi4rPmou6IjlrjHNVwaC7GAQFGIMnUwbLRLC6UTAX5zy+g7zvel51SzSadfzRLs3XTmnx7psRwLljD8HcTUwpjKEwvdshb5W9Ury7yd0xJTZNdmY X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CoBABCjHhW/61jaINehH+MTLMRhg2BaRABAQEBAQEBAYEJgi2CDiNoASICDRkCUwgEiEKdBY9wkhkMASCBAYVVhH6EQoM1gUkFji6IUqp1AjkrhCIghC6BCAEBAQ X-IronPort-AV: E=Sophos;i="5.20,461,1444708800"; d="scan'208";a="259281607" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-annu.net.uoguelph.ca with ESMTP; 21 Dec 2015 18:37:37 -0500 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 5B1A615F577 for ; Mon, 21 Dec 2015 18:37:37 -0500 (EST) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 41lX-kcoGMMT for ; Mon, 21 Dec 2015 18:37:37 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 12F3C15F574 for ; Mon, 21 Dec 2015 18:37:37 -0500 (EST) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id r1jTiKWVheLu for ; Mon, 21 Dec 2015 18:37:36 -0500 (EST) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id EF64E15F571 for ; Mon, 21 Dec 2015 18:37:36 -0500 (EST) Date: Mon, 21 Dec 2015 18:37:36 -0500 (EST) From: Rick Macklem To: freebsd-fs Message-ID: <238866144.139901318.1450741056924.JavaMail.zimbra@uoguelph.ca> Subject: review of fuse filesystem patches MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.10] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF43 (Win)/8.0.9_GA_6191) Thread-Topic: review of fuse filesystem patches Thread-Index: ar+Hwc7+bPmCDsf1CW5f8MG2F+i3rQ== X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2015 23:37:39 -0000 Hi, I have just put two patches for fuse up: - adding extended attribute support D4672 - adding advisory byte range file locking D4673 I need these (and some more patches to come) in fuse so that I use GlusterFS to create a pNFS server cluster. Any reviews/testing of these patches would be appreciated. I won't be in a position to commit any of this to -head until at least April, so there is no rush. Thanks, rick From owner-freebsd-fs@freebsd.org Tue Dec 22 15:24:46 2015 Return-Path: Delivered-To: freebsd-fs@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 0FDAAA4F52F for ; Tue, 22 Dec 2015 15:24:46 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 63E8B11D3 for ; Tue, 22 Dec 2015 15:24:45 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from [78.35.157.50] (helo=fabiankeil.de) by smtprelay05.ispgateway.de with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1aBOfD-0000ZH-LF for freebsd-fs@freebsd.org; Tue, 22 Dec 2015 16:15:47 +0100 Date: Tue, 22 Dec 2015 16:12:00 +0100 From: Fabian Keil To: FreeBSD FS Subject: ZFS:dmu_objset_find_dp_impl() - panic: vm_fault: fault on nofault entry, addr: fffffe0094653000 Message-ID: <20151222161200.19ab1832@fabiankeil.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/I1kt9lqEZfT7evbjkYjI0DA"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2015 15:24:46 -0000 --Sig_/I1kt9lqEZfT7evbjkYjI0DA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Using a kernel based on r292334, I got this panic while importing a ZFS pool with vfs.zfs.spa_load_verify_data and vfs.zfs.spa_load_verify_metadata set to 0. I've not been able to reproduce it yet and the changed sysctl's above may not actually matter (but I usually use the defaults). The pool has a single leaf vdev that is backed by ggatec which transfers the data over a slow and easily saturated connection (< ~120 kB/s up). Graph: https://www.fabiankeil.de/talks/versteckter-block-speicher/mgp00030.html fk@r500 /usr/crash $kgdb /usr/lib/debug/boot/kernel/kernel.debug vmcore.2=20 [...] Unread portion of the kernel message buffer: [11912] panic: vm_fault: fault on nofault entry, addr: fffffe0094653000 [11912] cpuid =3D 0 [11912] KDB: stack backtrace: [...] #0 doadump (textdump=3D0) at pcpu.h:221 221 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump (textdump=3D0) at pcpu.h:221 #1 0xffffffff8031752b in db_dump (dummy=3D, dummy2=3D= false, dummy3=3D0, dummy4=3D0x0) at /usr/src/sys/ddb/db_command.c:533 #2 0xffffffff8031731e in db_command (cmd_table=3D0x0) at /usr/src/sys/ddb/= db_command.c:440 #3 0xffffffff803170b4 in db_command_loop () at /usr/src/sys/ddb/db_command= .c:493 #4 0xffffffff80319bbb in db_trap (type=3D, code=3D0) = at /usr/src/sys/ddb/db_main.c:251 #5 0xffffffff805e2dc3 in kdb_trap (type=3D3, code=3D0, tf=3D) at /usr/src/sys/kern/subr_kdb.c:654 #6 0xffffffff8087f207 in trap (frame=3D0xfffffe0094f8f220) at /usr/src/sys= /amd64/amd64/trap.c:549 #7 0xffffffff808641b7 in calltrap () at /usr/src/sys/amd64/amd64/exception= .S:234 #8 0xffffffff805e24ab in kdb_enter (why=3D0xffffffff8097216b "panic", msg= =3D0x32
) at cpufunc.h:63 #9 0xffffffff8059ea4f in vpanic (fmt=3D, ap=3D) at /usr/src/sys/kern/kern_shutdown.c:750 #10 0xffffffff8059e8a3 in panic (fmt=3D0x0) at /usr/src/sys/kern/kern_shutd= own.c:688 #11 0xffffffff80835650 in vm_fault_hold (map=3D, vaddr= =3D, fault_type=3D, fault_flags= =3D, m_hold=3D) at /usr/src/sys/vm/vm_fault.c:332 #12 0xffffffff808332f8 in vm_fault (map=3D0xfffff80002000000, vaddr=3D, fault_type=3D1 '\001', fault_flags=3D0) at /usr/src/sys/v= m/vm_fault.c:277 #13 0xffffffff8087f97a in trap_pfault (frame=3D0xfffffe0094f8f8d0, usermode= =3D0) at /usr/src/sys/amd64/amd64/trap.c:734 #14 0xffffffff8087f21e in trap (frame=3D0xfffffe0094f8f8d0) at /usr/src/sys= /amd64/amd64/trap.c:435 #15 0xffffffff808641b7 in calltrap () at /usr/src/sys/amd64/amd64/exception= .S:234 #16 0xffffffff81900c9a in dmu_objset_find_dp_impl (dcp=3D0xfffff80078cb0200= ) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c:1= 630 #17 0xffffffff81901189 in dmu_objset_find_dp_cb (arg=3D0xfffff80078cb0200) = at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c:1746 #18 0xffffffff818ab8d1 in taskq_run (arg=3D0xfffff800066d3d20, pending=3D1)= at /usr/src/sys/cddl/compat/opensolaris/kern/opensolaris_taskq.c:109 #19 0xffffffff805f3c8b in taskqueue_run_locked (queue=3D0xfffff800666b2500)= at /usr/src/sys/kern/subr_taskqueue.c:430 #20 0xffffffff805f4ad8 in taskqueue_thread_loop (arg=3D) at /usr/src/sys/kern/subr_taskqueue.c:683 #21 0xffffffff8055c77c in fork_exit (callout=3D0xffffffff805f4a00 , arg=3D0xfffff80060937470, frame=3D0xfffffe0094f8fc00) at /u= sr/src/sys/kern/kern_fork.c:1011 #22 0xffffffff808646ee in fork_trampoline () at /usr/src/sys/amd64/amd64/ex= ception.S:609 #23 0x0000000000000000 in ?? () Current language: auto; currently minimal (kgdb) f 16 #16 0xffffffff81900c9a in dmu_objset_find_dp_impl (dcp=3D0xfffff80078cb0200= ) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c:1= 630 1630 if (*dcp->dc_error !=3D 0) (kgdb) p *dcp $1 =3D {dc_tq =3D 0xfffff80060937470, dc_dp =3D 0xfffff8001c3d3000, dc_ddob= j =3D 4996, dc_func =3D 0xffffffff819a2320 , dc_arg =3D 0xfffff8= 0051c72200, dc_flags =3D 2, dc_error_lock =3D 0xfffffe0094653a48,=20 dc_error =3D 0xfffffe0094653a80} (kgdb) p *dcp->dc_error Cannot access memory at address 0xfffffe0094653a80 (kgdb) p *dcp->dc_error_lock Cannot access memory at address 0xfffffe0094653a48 (kgdb) p *dcp->dc_tq $2 =3D {tq_queue =3D 0xfffff800666b2500} (kgdb) p *dcp->dc_dp $3 =3D {dp_spa =3D 0xfffff800062eb000, dp_meta_objset =3D 0xfffff8003db0a40= 0, dp_root_dir =3D 0xfffff8000b0ba800, dp_mos_dir =3D 0xfffff8001cf05800, d= p_free_dir =3D 0xfffff8004ca79400, dp_leak_dir =3D 0x0,=20 dp_origin_snap =3D 0xfffff8001a1d8400, dp_root_dir_obj =3D 2, dp_vnrele_t= askq =3D 0xfffff800285be8e0, dp_meta_rootbp =3D {blk_dva =3D 0xfffff8001c3d= 3048, blk_prop =3D 9226475966770118659, blk_pad =3D 0xfffff8001c3d3080,=20 blk_phys_birth =3D 0, blk_birth =3D 27427, blk_fill =3D 5434, blk_cksum= =3D {zc_word =3D 0xfffff8001c3d30a8}}, dp_tmp_userrefs_obj =3D 0, dp_free_= bpobj =3D {bpo_lock =3D {lock_object =3D { lo_name =3D 0xffffffff81a58f27 "bpo->bpo_lock", lo_flags =3D 409600= 00, lo_data =3D 0, lo_witness =3D 0x0}, sx_lock =3D 1}, bpo_os =3D 0xfffff8= 003db0a400, bpo_object =3D 11, bpo_epb =3D 1024, bpo_havecomp =3D 1 '\001',= =20 bpo_havesubobj =3D 1 '\001', bpo_phys =3D 0xfffff8006a434e00, bpo_dbuf = =3D 0xfffff800385c76c0, bpo_cached_dbuf =3D 0x0}, dp_bptree_obj =3D 0, dp_e= mpty_bpobj =3D 45, dp_scan =3D 0xfffff8001c39dc00, dp_lock =3D { lock_object =3D {lo_name =3D 0xffffffff81a5f0a5 "dp->dp_lock", lo_flags= =3D 40960000, lo_data =3D 0, lo_witness =3D 0x0}, sx_lock =3D 1}, dp_space= avail_cv =3D { cv_description =3D 0xffffffff81a5f0b2 "dp->dp_spaceavail_cv", cv_waiter= s =3D 0}, dp_dirty_pertxg =3D 0xfffff8001c3d3168, dp_dirty_total =3D 0, dp_= mos_used_delta =3D 0, dp_mos_compressed_delta =3D 0,=20 dp_mos_uncompressed_delta =3D 0, dp_last_wakeup =3D 0, dp_tx =3D {tx_cpu = =3D 0xfffff8003db0a800, tx_sync_lock =3D {lock_object =3D {lo_name =3D 0xff= ffffff81a66a91 "tx->tx_sync_lock", lo_flags =3D 40960000, lo_data =3D 0,=20 lo_witness =3D 0x0}, sx_lock =3D 1}, tx_open_txg =3D 27428, tx_quie= sced_txg =3D 0, tx_syncing_txg =3D 0, tx_synced_txg =3D 0, tx_open_time =3D= 0, tx_sync_txg_waiting =3D 0, tx_quiesce_txg_waiting =3D 0,=20 tx_sync_more_cv =3D {cv_description =3D 0xffffffff81a66aa3 "tx->tx_sync= _more_cv", cv_waiters =3D 0}, tx_sync_done_cv =3D {cv_description =3D 0xfff= fffff81a66ab8 "tx->tx_sync_done_cv", cv_waiters =3D 0},=20 tx_quiesce_more_cv =3D {cv_description =3D 0xffffffff81a66acd "tx->tx_q= uiesce_more_cv", cv_waiters =3D 0}, tx_quiesce_done_cv =3D {cv_description = =3D 0xffffffff81a66ae5 "tx->tx_quiesce_done_cv", cv_waiters =3D 0},=20 tx_timeout_cv =3D {cv_description =3D 0x0, cv_waiters =3D 0}, tx_exit_c= v =3D {cv_description =3D 0xffffffff81a66afd "tx->tx_exit_cv", cv_waiters = =3D 0}, tx_threads =3D 0 '\0', tx_exiting =3D 0 '\0', tx_sync_thread =3D 0x= 0,=20 tx_quiesce_thread =3D 0x0, tx_commit_cb_taskq =3D 0x0}, dp_dirty_datase= ts =3D {tl_lock =3D {lock_object =3D {lo_name =3D 0xffffffff81a66b4b "tl->t= l_lock", lo_flags =3D 40960000, lo_data =3D 0, lo_witness =3D 0x0},=20 sx_lock =3D 1}, tl_offset =3D 376, tl_head =3D 0xfffff8001c3d32b8}, d= p_dirty_zilogs =3D {tl_lock =3D {lock_object =3D {lo_name =3D 0xffffffff81a= 66b4b "tl->tl_lock", lo_flags =3D 40960000, lo_data =3D 0,=20 lo_witness =3D 0x0}, sx_lock =3D 1}, tl_offset =3D 984, tl_head =3D= 0xfffff8001c3d3300}, dp_dirty_dirs =3D {tl_lock =3D {lock_object =3D {lo_n= ame =3D 0xffffffff81a66b4b "tl->tl_lock", lo_flags =3D 40960000,=20 lo_data =3D 0, lo_witness =3D 0x0}, sx_lock =3D 1}, tl_offset =3D 8= 0, tl_head =3D 0xfffff8001c3d3348}, dp_sync_tasks =3D {tl_lock =3D {lock_ob= ject =3D {lo_name =3D 0xffffffff81a66b4b "tl->tl_lock", lo_flags =3D 409600= 00,=20 lo_data =3D 0, lo_witness =3D 0x0}, sx_lock =3D 1}, tl_offset =3D 0= , tl_head =3D 0xfffff8001c3d3390}, dp_config_rwlock =3D {rr_lock =3D {lock_= object =3D {lo_name =3D 0xffffffff81a62115 "rrl->rr_lock",=20 lo_flags =3D 40960000, lo_data =3D 0, lo_witness =3D 0x0}, sx_lock = =3D 1}, rr_cv =3D {cv_description =3D 0xffffffff81a62123 "rrl->rr_cv", cv_w= aiters =3D 0}, rr_writer =3D 0x0, rr_anon_rcount =3D {rc_count =3D 0},=20 rr_linked_rcount =3D {rc_count =3D 3}, rr_writer_wanted =3D 0, rr_track= _all =3D 1}, dp_blkstats =3D 0x0} (kgdb) p *dcp->dc_dp->dp_spa $4 =3D {spa_name =3D 0xfffff800062eb000 "tor3", spa_comment =3D 0x0, spa_av= l =3D {avl_child =3D 0xfffff800062eb108, avl_pcb =3D 18446735277720248589},= spa_config =3D 0xfffff800608f4a20, spa_config_syncing =3D 0x0,=20 spa_config_splitting =3D 0x0, spa_load_info =3D 0xfffff800061d99c0, spa_c= onfig_txg =3D 27427, spa_sync_pass =3D 0, spa_state =3D POOL_STATE_ACTIVE, = spa_inject_ref =3D 0, spa_sync_on =3D 0 '\0',=20 spa_load_state =3D SPA_LOAD_OPEN, spa_import_flags =3D 0, spa_zio_taskq = =3D 0xfffff800062eb168, spa_dsl_pool =3D 0xfffff8001c3d3000, spa_is_initial= izing =3D 0, spa_normal_class =3D 0xfffff8001e504400,=20 spa_log_class =3D 0xfffff8004dd19000, spa_first_txg =3D 27428, spa_final_= txg =3D 18446744073709551615, spa_freeze_txg =3D 18446744073709551615, spa_= load_max_txg =3D 18446744073709551615, spa_claim_max_txg =3D 27428,=20 spa_loaded_ts =3D {tv_sec =3D 1450736623, tv_nsec =3D 578802346}, spa_met= a_objset =3D 0xfffff8003db0a400, spa_evicting_os_lock =3D {lock_object =3D = {lo_name =3D 0xffffffff81a660ce "spa->spa_evicting_os_lock",=20 lo_flags =3D 40960000, lo_data =3D 0, lo_witness =3D 0x0}, sx_lock = =3D 1}, spa_evicting_os_list =3D {list_size =3D 1008, list_offset =3D 256, = list_head =3D {list_next =3D 0xfffff800062eb378,=20 list_prev =3D 0xfffff800062eb378}}, spa_evicting_os_cv =3D {cv_descri= ption =3D 0xffffffff81a6619b "spa->spa_evicting_os_cv", cv_waiters =3D 0}, = spa_vdev_txg_list =3D {tl_lock =3D {lock_object =3D { lo_name =3D 0xffffffff81a66b4b "tl->tl_lock", lo_flags =3D 40960000= , lo_data =3D 0, lo_witness =3D 0x0}, sx_lock =3D 1}, tl_offset =3D 624, tl= _head =3D 0xfffff800062eb3c0}, spa_root_vdev =3D 0xfffff8006ab1a000,=20 spa_min_ashift =3D 12, spa_max_ashift =3D 12, spa_config_guid =3D 1327185= 4445444309143, spa_load_guid =3D 10536853844155556401, spa_last_synced_guid= =3D 0, spa_config_dirty_list =3D {list_size =3D 1704,=20 list_offset =3D 672, list_head =3D {list_next =3D 0xfffff800062eb418, l= ist_prev =3D 0xfffff800062eb418}}, spa_state_dirty_list =3D {list_size =3D = 1704, list_offset =3D 688, list_head =3D {list_next =3D 0xfffff800062eb438,= =20 list_prev =3D 0xfffff800062eb438}}, spa_spares =3D {sav_object =3D 0,= sav_config =3D 0x0, sav_vdevs =3D 0x0, sav_count =3D 0, sav_sync =3D 0, sa= v_pending =3D 0x0, sav_npending =3D 0}, spa_l2cache =3D {sav_object =3D 0,= =20 sav_config =3D 0x0, sav_vdevs =3D 0x0, sav_count =3D 0, sav_sync =3D 0,= sav_pending =3D 0x0, sav_npending =3D 0}, spa_label_features =3D 0xfffff80= 0061d99a0, spa_config_object =3D 27, spa_config_generation =3D 0,=20 spa_syncing_txg =3D 0, spa_deferred_bpobj =3D {bpo_lock =3D {lock_object = =3D {lo_name =3D 0xffffffff81a58f27 "bpo->bpo_lock", lo_flags =3D 40960000,= lo_data =3D 0, lo_witness =3D 0x0}, sx_lock =3D 1},=20 bpo_os =3D 0xfffff8003db0a400, bpo_object =3D 31, bpo_epb =3D 128, bpo_= havecomp =3D 1 '\001', bpo_havesubobj =3D 1 '\001', bpo_phys =3D 0xfffff800= 06330a00, bpo_dbuf =3D 0xfffff800385c75e8, bpo_cached_dbuf =3D 0x0},=20 spa_free_bplist =3D 0xfffff800062eb518, spa_cksum_salt =3D {zcs_bytes =3D= 0xfffff800062eb618 "=C3=BC=C3=AC`~-=C2=AAY"}, spa_cksum_tmpls_lock =3D {lo= ck_object =3D {lo_name =3D 0xffffffff81a66129 "spa->spa_cksum_tmpls_lock",= =20 lo_flags =3D 40960000, lo_data =3D 0, lo_witness =3D 0x0}, sx_lock = =3D 1}, spa_cksum_tmpls =3D 0xfffff800062eb658, spa_ubsync =3D {ub_magic = =3D 12235020, ub_version =3D 5000, ub_txg =3D 27427,=20 ub_guid_sum =3D 3109696218321734419, ub_timestamp =3D 1450604034, ub_ro= otbp =3D {blk_dva =3D 0xfffff800062eb6d8, blk_prop =3D 9226475966770118659,= blk_pad =3D 0xfffff800062eb710, blk_phys_birth =3D 0,=20 blk_birth =3D 27427, blk_fill =3D 5434, blk_cksum =3D {zc_word =3D 0x= fffff800062eb738}}, ub_software_version =3D 5000}, spa_uberblock =3D {ub_ma= gic =3D 12235020, ub_version =3D 5000, ub_txg =3D 27427,=20 ub_guid_sum =3D 3109696218321734419, ub_timestamp =3D 1450604034, ub_ro= otbp =3D {blk_dva =3D 0xfffff800062eb788, blk_prop =3D 9226475966770118659,= blk_pad =3D 0xfffff800062eb7c0, blk_phys_birth =3D 0,=20 blk_birth =3D 27427, blk_fill =3D 5434, blk_cksum =3D {zc_word =3D 0x= fffff800062eb7e8}}, ub_software_version =3D 5000}, spa_extreme_rewind =3D 0= , spa_last_io =3D 11912224, spa_scrub_lock =3D {lock_object =3D { lo_name =3D 0xffffffff81a66144 "spa->spa_scrub_lock", lo_flags =3D 40= 960000, lo_data =3D 0, lo_witness =3D 0x0}, sx_lock =3D 1}, spa_scrub_infli= ght =3D 0, spa_scrub_io_cv =3D { cv_description =3D 0xffffffff81a661c6 "spa->spa_scrub_io_cv", cv_waiter= s =3D 0}, spa_scrub_active =3D 0 '\0', spa_scrub_type =3D 0 '\0', spa_scrub= _finished =3D 0 '\0', spa_scrub_started =3D 0 '\0',=20 spa_scrub_reopen =3D 0 '\0', spa_scan_pass_start =3D 1450736643, spa_scan= _pass_exam =3D 0, spa_async_lock =3D {lock_object =3D {lo_name =3D 0xffffff= ff81a6608c "spa->spa_async_lock", lo_flags =3D 40960000, lo_data =3D 0,=20 lo_witness =3D 0x0}, sx_lock =3D 1}, spa_async_thread =3D 0x0, spa_as= ync_thread_vd =3D 0x0, spa_async_suspended =3D 0, spa_async_cv =3D {cv_desc= ription =3D 0xffffffff81a66188 "spa->spa_async_cv", cv_waiters =3D 0},=20 spa_async_tasks =3D 0, spa_root =3D 0x0, spa_ena =3D 0, spa_last_open_fai= led =3D 2, spa_last_ubsync_txg =3D 0, spa_last_ubsync_txg_ts =3D 0, spa_loa= d_txg =3D 27427, spa_load_txg_ts =3D 1450604034, spa_load_meta_errors =3D 0= ,=20 spa_load_data_errors =3D 0, spa_verify_min_txg =3D 27424, spa_errlog_lock= =3D {lock_object =3D {lo_name =3D 0xffffffff81a660b8 "spa->spa_errlog_lock= ", lo_flags =3D 40960000, lo_data =3D 0, lo_witness =3D 0x0},=20 sx_lock =3D 1}, spa_errlog_last =3D 0, spa_errlog_scrub =3D 0, spa_errl= ist_lock =3D {lock_object =3D {lo_name =3D 0xffffffff81a660a1 "spa->spa_err= list_lock", lo_flags =3D 40960000, lo_data =3D 0, lo_witness =3D 0x0},=20 sx_lock =3D 1}, spa_errlist_last =3D {avl_root =3D 0x0, avl_compar =3D = 0xffffffff8194ef20 , avl_offset =3D 40, avl_numnod= es =3D 0, avl_size =3D 64}, spa_errlist_scrub =3D {avl_root =3D 0x0,=20 avl_compar =3D 0xffffffff8194ef20 , avl_offset= =3D 40, avl_numnodes =3D 0, avl_size =3D 64}, spa_deflate =3D 1, spa_histo= ry =3D 32, spa_history_lock =3D {lock_object =3D { lo_name =3D 0xffffffff81a660e9 "spa->spa_history_lock", lo_flags =3D = 40960000, lo_data =3D 0, lo_witness =3D 0x0}, sx_lock =3D 1}, spa_pending_v= dev =3D 0x0, spa_props_lock =3D {lock_object =3D { lo_name =3D 0xffffffff81a66114 "spa->spa_props_lock", lo_flags =3D 40= 960000, lo_data =3D 0, lo_witness =3D 0x0}, sx_lock =3D 1}, spa_pool_props_= object =3D 33, spa_bootfs =3D 0, spa_failmode =3D 1, spa_delegation =3D 1,= =20 spa_config_list =3D {list_size =3D 24, list_offset =3D 0, list_head =3D {= list_next =3D 0xfffff800061d9a00, list_prev =3D 0xfffff800061d9a00}}, spa_a= sync_zio_root =3D 0xfffff80025dfeb50, spa_suspend_zio_root =3D 0x0,=20 spa_suspend_lock =3D {lock_object =3D {lo_name =3D 0xffffffff81a66159 "sp= a->spa_suspend_lock", lo_flags =3D 40960000, lo_data =3D 0, lo_witness =3D = 0x0}, sx_lock =3D 1}, spa_suspend_cv =3D { cv_description =3D 0xffffffff81a661dc "spa->spa_suspend_cv", cv_waiters= =3D 0}, spa_suspended =3D 0 '\0', spa_claiming =3D 1 '\001', spa_debug =3D= 0, spa_is_root =3D 0, spa_minref =3D 0, spa_mode =3D 3,=20 spa_log_state =3D SPA_LOG_UNKNOWN, spa_autoexpand =3D 0, spa_ddt =3D 0xff= fff800062ebaa8, spa_ddt_stat_object =3D 0, spa_dedup_ditto =3D 0, spa_dedup= _checksum =3D 8, spa_dspace =3D 10926396801024, spa_vdev_top_lock =3D { lock_object =3D {lo_name =3D 0xffffffff81a66170 "spa->spa_vdev_top_lock= ", lo_flags =3D 40960000, lo_data =3D 0, lo_witness =3D 0x0}, sx_lock =3D 1= }, spa_proc_lock =3D {lock_object =3D { lo_name =3D 0xffffffff81a66100 "spa->spa_proc_lock", lo_flags =3D 409= 60000, lo_data =3D 0, lo_witness =3D 0x0}, sx_lock =3D 1}, spa_proc_cv =3D = {cv_description =3D 0xffffffff81a661b4 "spa->spa_proc_cv",=20 cv_waiters =3D 0}, spa_proc_state =3D SPA_PROC_NONE, spa_proc =3D 0xfff= fffff81620028, spa_did =3D 0, spa_trim_thread =3D 0xfffff80056b074d0, spa_t= rim_lock =3D {lock_object =3D { lo_name =3D 0xffffffff81a6dfe1 "spa->spa_trim_lock", lo_flags =3D 409= 60000, lo_data =3D 0, lo_witness =3D 0x0}, sx_lock =3D 1}, spa_trim_cv =3D = {cv_description =3D 0xffffffff81a6dff5 "spa->spa_trim_cv",=20 cv_waiters =3D 131}, spa_autoreplace =3D 1, spa_vdev_locks =3D 0, spa_c= reation_version =3D 5000, spa_prev_software_version =3D 5000, spa_feat_for_= write_obj =3D 29, spa_feat_for_read_obj =3D 28, spa_feat_desc_obj =3D 30,=20 spa_feat_enabled_txg_obj =3D 34, spa_feat_refcount_cache =3D 0xfffff80006= 2ebbf8, spa_deadman_cycid =3D {c_links =3D {le =3D {le_next =3D 0x0, le_pre= v =3D 0x0}, sle =3D {sle_next =3D 0x0}, tqe =3D {tqe_next =3D 0x0,=20 tqe_prev =3D 0x0}}, c_time =3D 0, c_precision =3D 0, c_arg =3D 0x0,= c_func =3D 0, c_lock =3D 0x0, c_flags =3D 0, c_iflags =3D 16, c_cpu =3D 0}= , spa_deadman_calls =3D 0, spa_sync_starttime =3D 0,=20 spa_deadman_synctime =3D 1000000000000, spa_ccw_fail_time =3D 0, spa_conf= ig_lock =3D 0xfffff800062ebcb8, spa_refcount =3D {rc_count =3D 31}, spa_spl= itting_newspa =3D 0} tor3 is the imported ZFS pool. Given the location of the trap, this could be a regression caused by the import of illumos #5269 (zpool import slow) in r286686: https://svnweb.freebsd.org/base?view=3Drevision&revision=3Dr286686 Fabian --Sig_/I1kt9lqEZfT7evbjkYjI0DA Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlZ5aEEACgkQBYqIVf93VJ3O9gCfbyiTf9e6mxcPBNYRBqASCDNJ 24oAoKcJY1XeR6qv5lytjzVb2mfZzlam =5+Dz -----END PGP SIGNATURE----- --Sig_/I1kt9lqEZfT7evbjkYjI0DA-- From owner-freebsd-fs@freebsd.org Tue Dec 22 22:37:09 2015 Return-Path: Delivered-To: freebsd-fs@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 6C64BA508EB for ; Tue, 22 Dec 2015 22:37:09 +0000 (UTC) (envelope-from devnullius@gmail.com) Received: from mwork.nabble.com (mwork.nabble.com [162.253.133.43]) by mx1.freebsd.org (Postfix) with ESMTP id 5AEFC1726 for ; Tue, 22 Dec 2015 22:37:09 +0000 (UTC) (envelope-from devnullius@gmail.com) Received: from msam.nabble.com (unknown [162.253.133.85]) by mwork.nabble.com (Postfix) with ESMTP id 445096C94DEF for ; Tue, 22 Dec 2015 14:35:21 -0800 (PST) Date: Tue, 22 Dec 2015 15:37:08 -0700 (MST) From: devnullius To: freebsd-fs@freebsd.org Message-ID: <1450823828700-6062095.post@n5.nabble.com> In-Reply-To: References: Subject: Re: LSI 9260: is there a way to configure it JBOD like mps? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2015 22:37:09 -0000 I hope some guru knows? Reviving this thread for I too have a 9260-4i 6GB/S SATA+SAS MEGARAID RAID PCI Card (L3-25121-61A) I want to use FreeNAS / ZFS on it and for that, I need JBOD 'raid'. As far as I understand, I'll need IT Firmware. Which isn't available for 2960-4i (right?). So now I'm wondering... (How) could I re-flash it with http://www.avagotech.com/products/server-storage/host-bus-adapters/sas-9211-4i#downloads - 9211_4i_Package_P20_IR_IT_Firmware_BIOS_for_MSDOS_Windows ? It kinda feels some expert voodoo would achieve what I want: my own NAS managed with ZFS... Anyone here that can help? Peace! :) Devnullius -- View this message in context: http://freebsd.1045724.n5.nabble.com/LSI-9260-is-there-a-way-to-configure-it-JBOD-like-mps-tp5796967p6062095.html Sent from the freebsd-fs mailing list archive at Nabble.com. From owner-freebsd-fs@freebsd.org Wed Dec 23 02:12:21 2015 Return-Path: Delivered-To: freebsd-fs@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 07D57A4FF76 for ; Wed, 23 Dec 2015 02:12:21 +0000 (UTC) (envelope-from michelle@sorbs.net) Received: from hades.sorbs.net (mail.sorbs.net [67.231.146.200]) by mx1.freebsd.org (Postfix) with ESMTP id EAAFC136B for ; Wed, 23 Dec 2015 02:12:19 +0000 (UTC) (envelope-from michelle@sorbs.net) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from isux.com (firewall.isux.com [213.165.190.213]) by hades.sorbs.net (Oracle Communications Messaging Server 7.0.5.29.0 64bit (built Jul 9 2013)) with ESMTPSA id <0NZS004FZEBMRL00@hades.sorbs.net> for freebsd-fs@freebsd.org; Tue, 22 Dec 2015 17:18:59 -0800 (PST) Message-id: <5679F4EB.4080501@sorbs.net> Date: Wed, 23 Dec 2015 02:12:11 +0100 From: Michelle Sullivan User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.24) Gecko/20100301 SeaMonkey/1.1.19 To: devnullius Cc: freebsd-fs@freebsd.org Subject: Re: LSI 9260: is there a way to configure it JBOD like mps? References: <1450823828700-6062095.post@n5.nabble.com> In-reply-to: <1450823828700-6062095.post@n5.nabble.com> X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2015 02:12:21 -0000 devnullius wrote: > I hope some guru knows? Reviving this thread for I too have a 9260-4i 6GB/S > SATA+SAS MEGARAID RAID PCI Card (L3-25121-61A) > > I want to use FreeNAS / ZFS on it and for that, I need JBOD 'raid'. As far > as I understand, I'll need IT Firmware. Which isn't available for 2960-4i > (right?). > > So now I'm wondering... (How) could I re-flash it with > http://www.avagotech.com/products/server-storage/host-bus-adapters/sas-9211-4i#downloads > - 9211_4i_Package_P20_IR_IT_Firmware_BIOS_for_MSDOS_Windows ? It kinda feels > some expert voodoo would achieve what I want: my own NAS managed with ZFS... > > Anyone here that can help? > I am running a -16i in 2 machines... Configure as all drives as single drives as RAID0.. works fine... though is an arse when something fails but if you get it right will work no issue. -- Michelle Sullivan http://www.mhix.org/ From owner-freebsd-fs@freebsd.org Wed Dec 23 09:40:45 2015 Return-Path: Delivered-To: freebsd-fs@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 66799A496C6 for ; Wed, 23 Dec 2015 09:40:45 +0000 (UTC) (envelope-from devnullius@gmail.com) Received: from mwork.nabble.com (mwork.nabble.com [162.253.133.43]) by mx1.freebsd.org (Postfix) with ESMTP id 56273173C for ; Wed, 23 Dec 2015 09:40:44 +0000 (UTC) (envelope-from devnullius@gmail.com) Received: from msam.nabble.com (unknown [162.253.133.85]) by mwork.nabble.com (Postfix) with ESMTP id 776536E8A9D6 for ; Wed, 23 Dec 2015 01:38:53 -0800 (PST) Date: Wed, 23 Dec 2015 02:40:43 -0700 (MST) From: devnullius To: freebsd-fs@freebsd.org Message-ID: <1450863643917-6062180.post@n5.nabble.com> In-Reply-To: <5679F4EB.4080501@sorbs.net> References: <1450823828700-6062095.post@n5.nabble.com> <5679F4EB.4080501@sorbs.net> Subject: Re: LSI 9260: is there a way to configure it JBOD like mps? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2015 09:40:45 -0000 Michelle Sullivan wrote >> 9260-4i >> 6GB/S >> SATA+SAS MEGARAID RAID PCI Card (L3-25121-61A) >> > >> Anyone here that can help? >> > > I am running a -16i in 2 machines... Configure as all drives as single > drives as RAID0.. works fine... though is an arse when something fails > but if you get it right will work no issue. > > > -- > Michelle Sullivan > http://www.mhix.org/ Quoted from: http://freebsd.1045724.n5.nabble.com/LSI-9260-is-there-a-way-to-configure-it-JBOD-like-mps-tp5796967p6062147.html Ok thanks! Got the same tip somewhere else and also confirmation it won't work otherwise (https://forums.freenas.org/index.php?threads/it-mode-firmware-for-lsi-megaraid-sas-9260-4i.40093/). QUESTION: I'm building all this just because I always have disks crashing and data loss with lots of effort to recover it all. SO... IF I go budget and set it all to RAID0... WHAT will happen if I need to recover data???? Thanks :) Devnullius PS: Michelle, sorry for emailing you too... Kinda rude, it was not my intention :) Happy holidays whatever they are! -- View this message in context: http://freebsd.1045724.n5.nabble.com/LSI-9260-is-there-a-way-to-configure-it-JBOD-like-mps-tp5796967p6062180.html Sent from the freebsd-fs mailing list archive at Nabble.com. From owner-freebsd-fs@freebsd.org Wed Dec 23 10:00:19 2015 Return-Path: Delivered-To: freebsd-fs@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 68474A4F045 for ; Wed, 23 Dec 2015 10:00:19 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 050141177 for ; Wed, 23 Dec 2015 10:00:18 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from [78.35.187.90] (helo=fabiankeil.de) by smtprelay05.ispgateway.de with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1aBgBq-0001cW-QD for freebsd-fs@freebsd.org; Wed, 23 Dec 2015 10:58:38 +0100 Date: Wed, 23 Dec 2015 10:58:37 +0100 From: Fabian Keil To: freebsd-fs@freebsd.org Subject: Re: ZFS:dmu_objset_find_dp_impl() - panic: vm_fault: fault on nofault entry, addr: fffffe0094653000 Message-ID: <20151223105837.53b2c1ae@fabiankeil.de> In-Reply-To: <20151222161200.19ab1832@fabiankeil.de> References: <20151222161200.19ab1832@fabiankeil.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/LkPuX3yEHhb4Kyxp4q4kfIC"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2015 10:00:19 -0000 --Sig_/LkPuX3yEHhb4Kyxp4q4kfIC Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Fabian Keil wrote: > Using a kernel based on r292334, I got this panic while importing > a ZFS pool with vfs.zfs.spa_load_verify_data and > vfs.zfs.spa_load_verify_metadata set to 0. >=20 > I've not been able to reproduce it yet and the changed sysctl's above > may not actually matter (but I usually use the defaults). I unintentionally reproduced it yesterday with the same kernel using the default values for the sysctls above. > The pool has a single leaf vdev that is backed by ggatec which transfers = the > data over a slow and easily saturated connection (< ~120 kB/s up). Graph: > https://www.fabiankeil.de/talks/versteckter-block-speicher/mgp00030.html >=20 > fk@r500 /usr/crash $kgdb /usr/lib/debug/boot/kernel/kernel.debug vmcore.2= =20 > [...] > Unread portion of the kernel message buffer: > [11912] panic: vm_fault: fault on nofault entry, addr: fffffe0094653000 > [11912] cpuid =3D 0 > [11912] KDB: stack backtrace: > [...] > #0 doadump (textdump=3D0) at pcpu.h:221 > 221 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) where > #0 doadump (textdump=3D0) at pcpu.h:221 > #1 0xffffffff8031752b in db_dump (dummy=3D, dummy2= =3Dfalse, dummy3=3D0, dummy4=3D0x0) at /usr/src/sys/ddb/db_command.c:533 > #2 0xffffffff8031731e in db_command (cmd_table=3D0x0) at /usr/src/sys/dd= b/db_command.c:440 > #3 0xffffffff803170b4 in db_command_loop () at /usr/src/sys/ddb/db_comma= nd.c:493 > #4 0xffffffff80319bbb in db_trap (type=3D, code=3D0= ) at /usr/src/sys/ddb/db_main.c:251 > #5 0xffffffff805e2dc3 in kdb_trap (type=3D3, code=3D0, tf=3D) at /usr/src/sys/kern/subr_kdb.c:654 > #6 0xffffffff8087f207 in trap (frame=3D0xfffffe0094f8f220) at /usr/src/s= ys/amd64/amd64/trap.c:549 > #7 0xffffffff808641b7 in calltrap () at /usr/src/sys/amd64/amd64/excepti= on.S:234 > #8 0xffffffff805e24ab in kdb_enter (why=3D0xffffffff8097216b "panic", ms= g=3D0x32
) at cpufunc.h:63 > #9 0xffffffff8059ea4f in vpanic (fmt=3D, ap=3D) at /usr/src/sys/kern/kern_shutdown.c:750 > #10 0xffffffff8059e8a3 in panic (fmt=3D0x0) at /usr/src/sys/kern/kern_shu= tdown.c:688 > #11 0xffffffff80835650 in vm_fault_hold (map=3D, vad= dr=3D, fault_type=3D, fault_flags= =3D, m_hold=3D) > at /usr/src/sys/vm/vm_fault.c:332 > #12 0xffffffff808332f8 in vm_fault (map=3D0xfffff80002000000, vaddr=3D, fault_type=3D1 '\001', fault_flags=3D0) at /usr/src/sys= /vm/vm_fault.c:277 > #13 0xffffffff8087f97a in trap_pfault (frame=3D0xfffffe0094f8f8d0, usermo= de=3D0) at /usr/src/sys/amd64/amd64/trap.c:734 > #14 0xffffffff8087f21e in trap (frame=3D0xfffffe0094f8f8d0) at /usr/src/s= ys/amd64/amd64/trap.c:435 > #15 0xffffffff808641b7 in calltrap () at /usr/src/sys/amd64/amd64/excepti= on.S:234 > #16 0xffffffff81900c9a in dmu_objset_find_dp_impl (dcp=3D0xfffff80078cb02= 00) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c= :1630 > #17 0xffffffff81901189 in dmu_objset_find_dp_cb (arg=3D0xfffff80078cb0200= ) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c:1= 746 [...] > Given the location of the trap, this could be a regression caused > by the import of illumos #5269 (zpool import slow) in r286686: > https://svnweb.freebsd.org/base?view=3Drevision&revision=3Dr286686 On the other hand I've never seen the issue with previous kernels and two times with the one based on r292334. I've updated to a kernel based on r292616 to see if it makes a difference (there were quite a few vm changes). Fabian --Sig_/LkPuX3yEHhb4Kyxp4q4kfIC Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlZ6cE0ACgkQBYqIVf93VJ03xwCgv6n9yYpeREldBPZOhEPxB0+w AmwAnjnlbZyrJ7vLPwAjPWVsBW9izMzr =HlWV -----END PGP SIGNATURE----- --Sig_/LkPuX3yEHhb4Kyxp4q4kfIC-- From owner-freebsd-fs@freebsd.org Wed Dec 23 13:25:50 2015 Return-Path: Delivered-To: freebsd-fs@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 B817AA4EFE6 for ; Wed, 23 Dec 2015 13:25:50 +0000 (UTC) (envelope-from michelle@sorbs.net) Received: from hades.sorbs.net (mail.sorbs.net [67.231.146.200]) by mx1.freebsd.org (Postfix) with ESMTP id A969B17E9 for ; Wed, 23 Dec 2015 13:25:50 +0000 (UTC) (envelope-from michelle@sorbs.net) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from isux.com (firewall.isux.com [213.165.190.213]) by hades.sorbs.net (Oracle Communications Messaging Server 7.0.5.29.0 64bit (built Jul 9 2013)) with ESMTPSA id <0NZT0084LCA9C100@hades.sorbs.net> for freebsd-fs@freebsd.org; Wed, 23 Dec 2015 05:32:35 -0800 (PST) Message-id: <567AA0DB.10509@sorbs.net> Date: Wed, 23 Dec 2015 14:25:47 +0100 From: Michelle Sullivan User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.24) Gecko/20100301 SeaMonkey/1.1.19 To: devnullius Cc: freebsd-fs@freebsd.org Subject: Re: LSI 9260: is there a way to configure it JBOD like mps? References: <1450823828700-6062095.post@n5.nabble.com> <5679F4EB.4080501@sorbs.net> <1450863643917-6062180.post@n5.nabble.com> In-reply-to: <1450863643917-6062180.post@n5.nabble.com> X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2015 13:25:50 -0000 devnullius wrote: > > Quoted from: > http://freebsd.1045724.n5.nabble.com/LSI-9260-is-there-a-way-to-configure-it-JBOD-like-mps-tp5796967p6062147.html > > Ok thanks! Got the same tip somewhere else and also confirmation it won't > work otherwise > (https://forums.freenas.org/index.php?threads/it-mode-firmware-for-lsi-megaraid-sas-9260-4i.40093/). > > QUESTION: I'm building all this just because I always have disks crashing > and data loss with lots of effort to recover it all. SO... IF I go budget > and set it all to RAID0... WHAT will happen if I need to recover data???? > You set all the drives as single disk RAID0 then ZRAID/ZRAID2 all the Logical drives on top.... If you're going the zfs route... otherwise... RAID5/RAID6 at the hardware level and UFS the logical drive... > Thanks :) > > Devnullius > > PS: Michelle, sorry for emailing you too... Kinda rude, it was not my > intention :) > No problem - replied in private as well.. > Happy holidays whatever they are! > Il-Milied u s-Sena t-Tajba. Regards, -- Michelle Sullivan http://www.mhix.org/ From owner-freebsd-fs@freebsd.org Thu Dec 24 09:06:06 2015 Return-Path: Delivered-To: freebsd-fs@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 251DCA51EBD for ; Thu, 24 Dec 2015 09:06:06 +0000 (UTC) (envelope-from karli.sjoberg@slu.se) Received: from exch2-4.slu.se (exch2-4.slu.se [77.235.224.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "webmail.slu.se", Issuer "TERENA SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B2AD61CFD for ; Thu, 24 Dec 2015 09:06:05 +0000 (UTC) (envelope-from karli.sjoberg@slu.se) Received: from exch2-4.slu.se (77.235.224.124) by exch2-4.slu.se (77.235.224.124) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 24 Dec 2015 09:50:50 +0100 Received: from exch2-4.slu.se ([::1]) by exch2-4.slu.se ([fe80::a44b:9cc6:beb0:b0f2%22]) with mapi id 15.00.1104.000; Thu, 24 Dec 2015 09:50:50 +0100 From: =?utf-8?B?S2FybGkgU2rDtmJlcmc=?= To: "freebsd-fs@freebsd.org" Subject: Merry Christmas! Thread-Topic: Merry Christmas! Thread-Index: AQHRPigwb4XJQBPjh0qbuerX3zdmog== Date: Thu, 24 Dec 2015 08:50:49 +0000 Message-ID: <420ed96c9fae4f589d9b3315525ca385@exch2-4.slu.se> Accept-Language: sv-SE, en-US Content-Language: sv-SE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" Content-ID: <240DEC355EB79A409D967DF3E2A1B153@ad.slu.se> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2015 09:06:06 -0000 QW5kIGEgaGFwcHkgbmV3IHllYXIsIGZyb20gU3dlZGVuIQoKL0s= From owner-freebsd-fs@freebsd.org Fri Dec 25 04:03:13 2015 Return-Path: Delivered-To: freebsd-fs@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 B6BA3A51C97 for ; Fri, 25 Dec 2015 04:03:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9E7EA1C28 for ; Fri, 25 Dec 2015 04:03:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id tBP43D7f076451 for ; Fri, 25 Dec 2015 04:03:13 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 194293] FUSE program freezes when seeking pos > file size Date: Fri, 25 Dec 2015 04:03:13 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: rmacklem@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Dec 2015 04:03:13 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194293 Rick Macklem changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rmacklem@FreeBSD.org --- Comment #4 from Rick Macklem --- I think I know what causes the hang for the small write (test.c). Could you try the program, but change "w" to "rw" in the fopen(). - I think the problem happens when a file is opened "write only" and then a partial block is written. The write of the partial buffer cache block requires that the block first be read from the file, but "write only" doesn't allow that to happen and it gets stuck. If test.c works ok when opening "rw", then I think this is what is happening. --> I am thinking that fuse_vnop_open(..O_WRONLY..) should actually do a O_RDWR open. It means that files that only give the user write access won't be able to be opened, but that seems to be preferred to a hang? Please let us know if you get to try this, rick. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@freebsd.org Sat Dec 26 19:57:11 2015 Return-Path: Delivered-To: freebsd-fs@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 BCCC2A534E3 for ; Sat, 26 Dec 2015 19:57:11 +0000 (UTC) (envelope-from devnullius@gmail.com) Received: from mwork.nabble.com (mwork.nabble.com [162.253.133.43]) by mx1.freebsd.org (Postfix) with ESMTP id A0B7C1CDE for ; Sat, 26 Dec 2015 19:57:11 +0000 (UTC) (envelope-from devnullius@gmail.com) Received: from msam.nabble.com (unknown [162.253.133.85]) by mwork.nabble.com (Postfix) with ESMTP id 0F63F7E69ECD for ; Sat, 26 Dec 2015 11:54:51 -0800 (PST) Date: Sat, 26 Dec 2015 12:57:03 -0700 (MST) From: devnullius To: freebsd-fs@freebsd.org Message-ID: <1451159823771-6063032.post@n5.nabble.com> In-Reply-To: <567AA0DB.10509@sorbs.net> References: <1450823828700-6062095.post@n5.nabble.com> <5679F4EB.4080501@sorbs.net> <1450863643917-6062180.post@n5.nabble.com> <567AA0DB.10509@sorbs.net> Subject: Re: LSI 9260: is there a way to configure it JBOD like mps? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Dec 2015 19:57:11 -0000 I also got this info from Michelle (thanks!) Michelle Sullivan wrote > Well depends on your RAID level of zfs... > > On my system I have 16 x 3T drives and all are config'd as RAID0 then I > have zraid2 for 15 of the disks and the remainder is set to be a spare. > > ...and that all looks like: > > $ zpool status -v > pool: storage > state: ONLINE > scan: scrub in progress since Sun Dec 20 00:00:01 2015 > 8.13T scanned out of 28.5T at 28.5M/s, 208h38m to go > 0 repaired, 28.49% done > config: > > NAME STATE READ WRITE CKSUM > storage ONLINE 0 0 0 > raidz2-0 ONLINE 0 0 0 > mfid10 ONLINE 0 0 0 > mfid8 ONLINE 0 0 0 > mfid12 ONLINE 0 0 0 > mfid0 ONLINE 0 0 0 > mfid14 ONLINE 0 0 0 > mfid15 ONLINE 0 0 0 > mfid1 ONLINE 0 0 0 > mfid7 ONLINE 0 0 0 > mfid2 ONLINE 0 0 0 > mfid9 ONLINE 0 0 0 > mfid3 ONLINE 0 0 0 > mfid4 ONLINE 0 0 0 > mfid5 ONLINE 0 0 0 > mfid6 ONLINE 0 0 0 > mfid11 ONLINE 0 0 0 > spares > mfid13 AVAIL > > errors: No known data errors It still feels like I should anticipate a lot of problems, assuming worst case scenarios... So I'm gonna look for one of these cards instead and rule out all risks...: https://forums.freenas.org/index.php?threads/it-mode-firmware-for-lsi-megaraid-sas-9260-4i.40093/ (currently in moderation) -- View this message in context: http://freebsd.1045724.n5.nabble.com/LSI-9260-is-there-a-way-to-configure-it-JBOD-like-mps-tp5796967p6063032.html Sent from the freebsd-fs mailing list archive at Nabble.com.