From owner-freebsd-fs@FreeBSD.ORG Sun Mar 15 04:33:22 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A828F1 for ; Sun, 15 Mar 2015 04:33:22 +0000 (UTC) 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 0F6B890C for ; Sun, 15 Mar 2015 04:33:22 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2F4XL3T044172 for ; Sun, 15 Mar 2015 04:33:21 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 193965] [zfs] zpool coredump on import Date: Sun, 15 Mar 2015 04:33:22 +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-RELEASE 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 04:33:22 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193965 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 Sun Mar 15 04:33:53 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6F2341A7 for ; Sun, 15 Mar 2015 04:33:53 +0000 (UTC) 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 560AE916 for ; Sun, 15 Mar 2015 04:33:53 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2F4XrYG044634 for ; Sun, 15 Mar 2015 04:33:53 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 193949] [zfs] panic on zvol resize Date: Sun, 15 Mar 2015 04:33:52 +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 Some People 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 04:33:53 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193949 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 Sun Mar 15 04:34:11 2015 Return-Path: Delivered-To: freebsd-fs@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 118AD25B for ; Sun, 15 Mar 2015 04:34:11 +0000 (UTC) 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 EB57591E for ; Sun, 15 Mar 2015 04:34:10 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2F4YAfZ044866 for ; Sun, 15 Mar 2015 04:34:10 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 193875] [zfs] [panic] [reproducable] zfs/space_map.c: solaris assert: sm->sm_space + size <= sm->sm_size Date: Sun, 15 Mar 2015 04:34:10 +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-RELEASE 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 04:34:11 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193875 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 Sun Mar 15 04:34:51 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B28E31C for ; Sun, 15 Mar 2015 04:34:51 +0000 (UTC) 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 01426931 for ; Sun, 15 Mar 2015 04:34:51 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2F4Yoem045520 for ; Sun, 15 Mar 2015 04:34:50 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 193803] fix zvol rename failing due to out of order locking Date: Sun, 15 Mar 2015 04:34:49 +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-RELEASE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: short_desc assigned_to keywords 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 04:34:51 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193803 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|zvol rename failing due to |fix zvol rename failing due |out of order locking |to out of order locking Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org Keywords| |patch -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Sun Mar 15 04:37:23 2015 Return-Path: Delivered-To: freebsd-fs@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 EA660598 for ; Sun, 15 Mar 2015 04:37:23 +0000 (UTC) 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 D11CF973 for ; Sun, 15 Mar 2015 04:37:23 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2F4bNLU047456 for ; Sun, 15 Mar 2015 04:37:23 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 192622] restore corrupting filesystem when using dump levels Date: Sun, 15 Mar 2015 04:37:23 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 04:37:24 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192622 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 Sun Mar 15 04:41:29 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3909C759 for ; Sun, 15 Mar 2015 04:41:29 +0000 (UTC) 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 1FC6CA2B for ; Sun, 15 Mar 2015 04:41:29 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2F4fSZb052697 for ; Sun, 15 Mar 2015 04:41:28 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 192085] [zfs] panic on zvol resize Date: Sun, 15 Mar 2015 04:41:29 +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: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People 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 keywords 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 04:41:29 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192085 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org Keywords| |patch -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Sun Mar 15 04:44:10 2015 Return-Path: Delivered-To: freebsd-fs@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 F0B7C89D for ; Sun, 15 Mar 2015 04:44:10 +0000 (UTC) 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 D71E0A48 for ; Sun, 15 Mar 2015 04:44:10 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2F4iALn055837 for ; Sun, 15 Mar 2015 04:44:10 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 189673] hast on top of gvinum unstable, freezes system Date: Sun, 15 Mar 2015 04:44:10 +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: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@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: 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 04:44:11 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189673 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 Sun Mar 15 11:23:17 2015 Return-Path: Delivered-To: freebsd-fs@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 373138D8 for ; Sun, 15 Mar 2015 11:23:17 +0000 (UTC) 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 1E63C23D for ; Sun, 15 Mar 2015 11:23:17 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2FBNGra038226 for ; Sun, 15 Mar 2015 11:23:16 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 193949] [zfs] panic on zvol resize Date: Sun, 15 Mar 2015 11:23:16 +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 Some People X-Bugzilla-Who: smh@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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 11:23:17 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193949 Steven Hartland changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |smh@FreeBSD.org --- Comment #2 from Steven Hartland --- (In reply to Marcus von Appen from comment #1) Please confirm your running stable/10 after r277483 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Sun Mar 15 11:29:17 2015 Return-Path: Delivered-To: freebsd-fs@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 AB139A9A for ; Sun, 15 Mar 2015 11:29:17 +0000 (UTC) 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 9134B261 for ; Sun, 15 Mar 2015 11:29:17 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2FBTHRU040816 for ; Sun, 15 Mar 2015 11:29:17 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 193803] fix zvol rename failing due to out of order locking Date: Sun, 15 Mar 2015 11:29:16 +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-RELEASE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: smh@FreeBSD.org X-Bugzilla-Status: Open 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 11:29:17 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193803 --- Comment #34 from Steven Hartland --- (In reply to kash from comment #33) Please confirm exactly what revision your running and report an updated stack. The fix was included in r277483 for stable/10 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Sun Mar 15 11:33:02 2015 Return-Path: Delivered-To: freebsd-fs@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 81E2EC8A for ; Sun, 15 Mar 2015 11:33:02 +0000 (UTC) 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 6891F343 for ; Sun, 15 Mar 2015 11:33:02 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2FBX27E048294 for ; Sun, 15 Mar 2015 11:33:02 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 192085] [zfs] panic on zvol resize Date: Sun, 15 Mar 2015 11:33:02 +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: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: smh@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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 11:33:02 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192085 Steven Hartland changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |smh@FreeBSD.org --- Comment #5 from Steven Hartland --- This should be already fixed by r276069 in current and r277483 in stable/10 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Sun Mar 15 11:59:53 2015 Return-Path: Delivered-To: freebsd-fs@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 AB9E6F38 for ; Sun, 15 Mar 2015 11:59:53 +0000 (UTC) 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 92536812 for ; Sun, 15 Mar 2015 11:59:53 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2FBxreJ069805 for ; Sun, 15 Mar 2015 11:59:53 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 193965] [zfs] zpool coredump on import Date: Sun, 15 Mar 2015 11:59: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.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: smh@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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 11:59:53 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193965 Steven Hartland changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |smh@FreeBSD.org --- Comment #3 from Steven Hartland --- Please try with stable/10 and if still unsuccessfully current to see if this is already fixed as 10.0-RELEASE is pretty old now. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Sun Mar 15 15:15:49 2015 Return-Path: Delivered-To: freebsd-fs@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 5AF32EC8 for ; Sun, 15 Mar 2015 15:15:49 +0000 (UTC) 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 40FE6D5C for ; Sun, 15 Mar 2015 15:15:49 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2FFFnae028544 for ; Sun, 15 Mar 2015 15:15:49 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 193949] [zfs] panic on zvol resize Date: Sun, 15 Mar 2015 15:15:48 +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 Some People X-Bugzilla-Who: kristof@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 15:15:49 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193949 Kristof Provost changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|New |Closed --- Comment #3 from Kristof Provost --- I've been unable to reproduce this on a stable/10 from February 10th, so yes, this looks like it's fixed. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Sun Mar 15 15:19:38 2015 Return-Path: Delivered-To: freebsd-fs@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 9C47A256 for ; Sun, 15 Mar 2015 15:19:38 +0000 (UTC) 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 815E9D82 for ; Sun, 15 Mar 2015 15:19:38 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2FFJcXM030104 for ; Sun, 15 Mar 2015 15:19:38 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 192085] [zfs] panic on zvol resize Date: Sun, 15 Mar 2015 15:19:38 +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: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: kristof@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 15:19:38 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192085 Kristof Provost changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|New |Closed --- Comment #6 from Kristof Provost --- I've been unable to reproduce this on a current system (from March 8th), so this seems to be fixed. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Sun Mar 15 21:00:18 2015 Return-Path: Delivered-To: freebsd-fs@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 1C797C37 for ; Sun, 15 Mar 2015 21:00:18 +0000 (UTC) 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 E771E383 for ; Sun, 15 Mar 2015 21:00:17 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2FL0HHg057534 for ; Sun, 15 Mar 2015 21:00:17 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201503152100.t2FL0HHg057534@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-fs@FreeBSD.org Subject: Problem reports for freebsd-fs@FreeBSD.org that need special attention X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 Date: Sun, 15 Mar 2015 21:00:17 +0000 Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 21:00:18 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 136470 | [nfs] Cannot mount / in read-only, over NFS Open | 139651 | [nfs] mount(8): read-only remount of NFS volume d Open | 144447 | [zfs] sharenfs fsunshare() & fsshare_main() non f 3 problems total for which you should take action. From owner-freebsd-fs@FreeBSD.ORG Sun Mar 15 21:07:17 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7640F778 for ; Sun, 15 Mar 2015 21:07:17 +0000 (UTC) Received: from mx.tetcu.info (mx.tetcu.info [217.19.15.179]) by mx1.freebsd.org (Postfix) with ESMTP id 3276D754 for ; Sun, 15 Mar 2015 21:07:16 +0000 (UTC) Received: from it.tim.tetcu.info (5-12-109-108.residential.rdsnet.ro [5.12.109.108]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.tetcu.info (Postfix) with ESMTPSA id 07BC02C53BF for ; Sun, 15 Mar 2015 23:12:37 +0200 (EET) Date: Sun, 15 Mar 2015 23:07:09 +0200 From: Ion-Mihai Tetcu To: freebsd-fs@FreeBSD.org Subject: 'zdb-d' doesn't like 'z' pool name anymore? Message-ID: <20150315230709.5631c35c@it.tim.tetcu.info> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; amd64-portbld-freebsd10.1) 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 21:07:17 -0000 Hi, On any of my other systems zdb -d outputs something useful. But on one of them: root@cav:/home/itetcu # uname -v FreeBSD 10.1-RELEASE-p6 #0: Tue Feb 24 19:00:21 UTC 2015 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC root@cav:/home/itetcu # zdb -d z | more zdb: can't open 'z': No such file or directory Still, the pool is there: root@cav:/home/itetcu # zpool status pool: z state: ONLINE scan: scrub repaired 0 in 4h19m with 0 errors on Sat Mar 14 21:20:31 2015 config: NAME STATE READ WRITE CKSUM z ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 ada0p3 ONLINE 0 0 0 ada1p3 ONLINE 0 0 0 ada2p3 ONLINE 0 0 0 ada3p3 ONLINE 0 0 0 errors: No known data errors What gives? Tnx, -- IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" FreeBSD committer -> itetcu@FreeBSD.org, PGP Key ID 29597D20 From owner-freebsd-fs@FreeBSD.ORG Mon Mar 16 09:46:48 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8CD8D166 for ; Mon, 16 Mar 2015 09:46:48 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2E063E for ; Mon, 16 Mar 2015 09:46:48 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t2G9khGn051100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Mar 2015 11:46:43 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t2G9khGn051100 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t2G9khus051099; Mon, 16 Mar 2015 11:46:43 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 16 Mar 2015 11:46:43 +0200 From: Konstantin Belousov To: Mateusz Guzik Subject: Re: atomic v_usecount and v_holdcnt Message-ID: <20150316094643.GZ2379@kib.kiev.ua> References: <20141122002812.GA32289@dft-labs.eu> <20141122092527.GT17068@kib.kiev.ua> <20141122211147.GA23623@dft-labs.eu> <20141124095251.GH17068@kib.kiev.ua> <20150314225226.GA15302@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150314225226.GA15302@dft-labs.eu> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 09:46:48 -0000 On Sat, Mar 14, 2015 at 11:52:26PM +0100, Mateusz Guzik wrote: > On Mon, Nov 24, 2014 at 11:52:52AM +0200, Konstantin Belousov wrote: > > On Sat, Nov 22, 2014 at 10:11:47PM +0100, Mateusz Guzik wrote: > > > On Sat, Nov 22, 2014 at 11:25:27AM +0200, Konstantin Belousov wrote: > > > > On Sat, Nov 22, 2014 at 01:28:12AM +0100, Mateusz Guzik wrote: > > > > > The idea is that we don't need an interlock as long as we don't > > > > > transition either counter 1->0 or 0->1. > > > > I already said that something along the lines of the patch should work. > > > > In fact, you need vnode lock when hold count changes between 0 and 1, > > > > and probably the same for use count. > > > > > > > > > > I don't see why this would be required (not that I'm an VFS expert). > > > vnode recycling seems to be protected with the interlock. > > > > > > In fact I would argue that if this is really needed, current code is > > > buggy. > > Yes, it is already (somewhat) buggy. > > > > Most need of the lock is for the case of counts coming from 1 to 0. > > The reason is the handling of the active vnode list, which is used > > for limiting the amount of vnode list walking in syncer. When hold > > count is decremented to 0, vnode is removed from the active list. > > When use count is decremented to 0, vnode is supposedly inactivated, > > and vinactive() cleans the cached pages belonging to vnode. In other > > words, VI_OWEINACT for dirty vnode is sort of bug. > > > > Modified the patch to no longer have the usecount + interlock dropped + > VI_OWEINACT set window. > > Extended 0->1 hold count + vnode not locked window remains. I can fix > that if it is really necessary by having _vhold return with interlock > held if it did such transition. In v_upgrade_usecount(), you call v_incr_devcount() without without interlock held. What prevents the devfs vnode from being recycled, in particular, from invalidation of v_rdev pointer ? I think that refcount_acquire_if_greater() KPI is excessive. You always calls acquire with val == 0, and release with val == 1. WRT to _refcount_release_lock, why is lock_object->lc_lock/lc_unlock KPI cannot be used ? This allows to make refcount_release_lock() a function instead of gcc extension macros. Not to mention that the macro is unused. From owner-freebsd-fs@FreeBSD.ORG Mon Mar 16 17:39:55 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B0ECB801 for ; Mon, 16 Mar 2015 17:39:55 +0000 (UTC) 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 960537B8 for ; Mon, 16 Mar 2015 17:39:55 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2GHdtHx063689 for ; Mon, 16 Mar 2015 17:39:55 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 193875] [zfs] [panic] [reproducable] zfs/space_map.c: solaris assert: sm->sm_space + size <= sm->sm_size Date: Mon, 16 Mar 2015 17:39:55 +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-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: delphij@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 17:39:55 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193875 Xin LI changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |Feedback Timeout Status|New |Closed --- Comment #6 from Xin LI --- Closed because of timeout. Please reopen if it reoccurs or you have additional information. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Mon Mar 16 23:10:16 2015 Return-Path: Delivered-To: freebsd-fs@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 66DCCB63 for ; Mon, 16 Mar 2015 23:10:16 +0000 (UTC) Received: from DUB004-OMC4S18.hotmail.com (dub004-omc4s18.hotmail.com [157.55.2.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "*.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C39686A1 for ; Mon, 16 Mar 2015 23:10:15 +0000 (UTC) Received: from DUB131-W44 ([157.55.2.73]) by DUB004-OMC4S18.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Mon, 16 Mar 2015 16:09:05 -0700 X-TMN: [TwfVb+iKj5O1m7stWlXF3Meo2ZYAf6sM] X-Originating-Email: [cipher_nl@hotmail.com] Message-ID: From: Dirk E To: "freebsd-fs@FreeBSD.org" Subject: ZFS doing background writes? Date: Tue, 17 Mar 2015 00:09:05 +0100 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 16 Mar 2015 23:09:05.0829 (UTC) FILETIME=[33473D50:01D0603E] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 23:10:16 -0000 I'm curious now=3B does ZFS do any I/O on the background?=0A= =0A= Because i'm getting periodic writes from ZFS to my disks=2C beginning right= after i import the pool.=0A= =0A= Even going to single user mode does not help=3B zpool iostat -v 1 still sho= ws the writes with static 5 second interval.=0A= =0A= What would cause this behaviour? I encountered it with both 10.1-RELEASE an= d a very recent HEAD.=0A= = From owner-freebsd-fs@FreeBSD.ORG Mon Mar 16 23:47:25 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B8B3176 for ; Mon, 16 Mar 2015 23:47:25 +0000 (UTC) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) (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 A7120AD8 for ; Mon, 16 Mar 2015 23:47:23 +0000 (UTC) Received: by wgdm6 with SMTP id m6so52436860wgd.2 for ; Mon, 16 Mar 2015 16:47:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=k5HHvXevh8aGbaUrY36P8wyzDgjjoLCP5nwNGvyS+fg=; b=XSr5tXICG4rk9ctxMMoslGbPNCsKvjqmAPof6YSx9OTIpc/ZX/s7OBFq+J5u/hsvwM N+f8moT5LZZgFg7YoP5Pzg2DES7Of3EJsBVZbgeVy0rVg2SJ5r+rnKjGK2Bks0DI1+S7 pc9lxa9D2WPCmS1RcEvLaKSjcoqxeG11DxHe2ByOn14VUBqHwPgRdJNm521PenvIY/Gm mPKit7JosWWl2fqwVcKnokklBTIwdOyY4uKExW7lq43+wcnF3eps4g44qqoe9SuFdcdw 59AfX4Z23/jp+E23KzF5Kj1KS0Y/kzf7UoKvNTLNDq+izJk+0WBPqdMv4mrdVWUZLncO X9Rw== X-Gm-Message-State: ALoCoQkRro0MTvnIWyRDKDvSY9nAhQEvAymLshgwSdbWMIbqrgVFM681Q4MW3xn3Uf1e5wLjsFnf X-Received: by 10.194.142.205 with SMTP id ry13mr130419610wjb.73.1426549642367; Mon, 16 Mar 2015 16:47:22 -0700 (PDT) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id dj5sm17498450wjb.28.2015.03.16.16.47.21 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Mar 2015 16:47:21 -0700 (PDT) Message-ID: <55076B84.0@multiplay.co.uk> Date: Mon, 16 Mar 2015 23:47:16 +0000 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: ZFS doing background writes? References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 23:47:25 -0000 yes exactly that its defined by vfs.zfs.txg.timeout. On 16/03/2015 23:09, Dirk E wrote: > I'm curious now; does ZFS do any I/O on the background? > > Because i'm getting periodic writes from ZFS to my disks, beginning right after i import the pool. > > Even going to single user mode does not help; zpool iostat -v 1 still shows the writes with static 5 second interval. > > What would cause this behaviour? I encountered it with both 10.1-RELEASE and a very recent HEAD. > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Tue Mar 17 01:41:45 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2C39E766; Tue, 17 Mar 2015 01:41:45 +0000 (UTC) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 76CE2885; Tue, 17 Mar 2015 01:41:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id t2H1ZXAY085650; Tue, 17 Mar 2015 04:36:23 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Tue, 17 Mar 2015 04:35:33 +0300 (MSK) From: Dmitry Morozovsky To: Pedro Giffuni Subject: Re: Willing to do what I can to help with a decent fs for removable media... In-Reply-To: <54FB0BBE.7060907@FreeBSD.org> Message-ID: References: <54FB0BBE.7060907@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [0.0.0.0]); Tue, 17 Mar 2015 04:36:24 +0300 (MSK) Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 01:41:45 -0000 On Sat, 7 Mar 2015, Pedro Giffuni wrote: > What is wrong with ext2/3 ? > > OK, we don't support journalling but I doubt you really need that for > removable media. Well, as I did (sparely) tested it, the most irritating problem was that FreeBSD declined to even mount ext* with "unsupported" journalling features, even whan journal was clean. For removable media, I supose it *could* be resolved in a clean and non-intrusive ways, but I could of course miss something important... -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-fs@FreeBSD.ORG Tue Mar 17 01:44:19 2015 Return-Path: Delivered-To: freebsd-fs@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 48852831 for ; Tue, 17 Mar 2015 01:44:19 +0000 (UTC) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (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 C2C3889C for ; Tue, 17 Mar 2015 01:44:18 +0000 (UTC) Received: by wgdm6 with SMTP id m6so53782633wgd.2 for ; Mon, 16 Mar 2015 18:44:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=MuLlz19IurRnXJC22NEOq4QEyTSXHAfbwwfoa7qPktg=; b=TW7xP16KVxWUJid39Bj4EyPBiwdA1VrqYr1wOHd1HK2WlskYQWKnKwoXqJ/9Zcdnof wusBm6uG8lxxLRuZz+q6o/iCjubd2CEFitAqi6gOzlB6yMlHomAxOYERYfhvKk2TzfUT YVuF93GL/vezTpnZPr2/ox/d/E8vZrl/g5uSd6ZAJK/dgLVyl0Zjl6VMc5Nf7EXFr/nX 8seoJ9Cfv3MDP/UfZ8tN0HWuYBso97YgiLF0OP2qCT5FM964H7vOG4r1wdBvVCzy7Iqs mQUVjcTjzKGI6SSMq1CNQ58Fz+aeYhCM8kphqH6TSjJ7Ej6vqxrQy3UYH9pQQb/Et31G EiBQ== X-Received: by 10.180.79.35 with SMTP id g3mr44200188wix.42.1426556656385; Mon, 16 Mar 2015 18:44:16 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id kr5sm17796837wjc.1.2015.03.16.18.44.14 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 16 Mar 2015 18:44:15 -0700 (PDT) Date: Tue, 17 Mar 2015 02:44:12 +0100 From: Mateusz Guzik To: Konstantin Belousov Subject: Re: atomic v_usecount and v_holdcnt Message-ID: <20150317014412.GA10819@dft-labs.eu> References: <20141122002812.GA32289@dft-labs.eu> <20141122092527.GT17068@kib.kiev.ua> <20141122211147.GA23623@dft-labs.eu> <20141124095251.GH17068@kib.kiev.ua> <20150314225226.GA15302@dft-labs.eu> <20150316094643.GZ2379@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150316094643.GZ2379@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 01:44:19 -0000 On Mon, Mar 16, 2015 at 11:46:43AM +0200, Konstantin Belousov wrote: > On Sat, Mar 14, 2015 at 11:52:26PM +0100, Mateusz Guzik wrote: > > On Mon, Nov 24, 2014 at 11:52:52AM +0200, Konstantin Belousov wrote: > > > On Sat, Nov 22, 2014 at 10:11:47PM +0100, Mateusz Guzik wrote: > > > > On Sat, Nov 22, 2014 at 11:25:27AM +0200, Konstantin Belousov wrote: > > > > > On Sat, Nov 22, 2014 at 01:28:12AM +0100, Mateusz Guzik wrote: > > > > > > The idea is that we don't need an interlock as long as we don't > > > > > > transition either counter 1->0 or 0->1. > > > > > I already said that something along the lines of the patch should work. > > > > > In fact, you need vnode lock when hold count changes between 0 and 1, > > > > > and probably the same for use count. > > > > > > > > > > > > > I don't see why this would be required (not that I'm an VFS expert). > > > > vnode recycling seems to be protected with the interlock. > > > > > > > > In fact I would argue that if this is really needed, current code is > > > > buggy. > > > Yes, it is already (somewhat) buggy. > > > > > > Most need of the lock is for the case of counts coming from 1 to 0. > > > The reason is the handling of the active vnode list, which is used > > > for limiting the amount of vnode list walking in syncer. When hold > > > count is decremented to 0, vnode is removed from the active list. > > > When use count is decremented to 0, vnode is supposedly inactivated, > > > and vinactive() cleans the cached pages belonging to vnode. In other > > > words, VI_OWEINACT for dirty vnode is sort of bug. > > > > > > > Modified the patch to no longer have the usecount + interlock dropped + > > VI_OWEINACT set window. > > > > Extended 0->1 hold count + vnode not locked window remains. I can fix > > that if it is really necessary by having _vhold return with interlock > > held if it did such transition. > > In v_upgrade_usecount(), you call v_incr_devcount() without without interlock > held. What prevents the devfs vnode from being recycled, in particular, > from invalidation of v_rdev pointer ? > Right, that was buggy. Fixed in the patch below. > I think that refcount_acquire_if_greater() KPI is excessive. You always > calls acquire with val == 0, and release with val == 1. > Yea i noted in my prevoius e-mail it should be changed (see below). I replaced them with refcount_acquire_if_not_zero and refcount_release_if_not_last. > WRT to _refcount_release_lock, why is lock_object->lc_lock/lc_unlock KPI > cannot be used ? This allows to make refcount_release_lock() a function > instead of gcc extension macros. Not to mention that the macro is unused. These were supposed to be used by other code, forgot to remove it from the patch I sent here. We can discuss this in another thread. Striclty speaking we could use it here for vnode interlock, but I did not want to get around VI_LOCK macro (which right now is just a mtx_lock, but this may change). Updated patch is below: diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/vnode.c b/sys/cddl/contrib/opensolaris/uts/common/fs/vnode.c index 83f29c1..b587ebd 100644 --- a/sys/cddl/contrib/opensolaris/uts/common/fs/vnode.c +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/vnode.c @@ -99,6 +99,6 @@ vn_rele_async(vnode_t *vp, taskq_t *taskq) (task_func_t *)vn_rele_inactive, vp, TQ_SLEEP) != 0); return; } - vp->v_usecount--; + refcount_release(&vp->v_usecount); vdropl(vp); } diff --git a/sys/kern/vfs_cache.c b/sys/kern/vfs_cache.c index d57dc90..f3f8339 100644 --- a/sys/kern/vfs_cache.c +++ b/sys/kern/vfs_cache.c @@ -665,12 +665,12 @@ success: ltype = VOP_ISLOCKED(dvp); VOP_UNLOCK(dvp, 0); } - VI_LOCK(*vpp); + vhold(*vpp); if (wlocked) CACHE_WUNLOCK(); else CACHE_RUNLOCK(); - error = vget(*vpp, cnp->cn_lkflags | LK_INTERLOCK, cnp->cn_thread); + error = vget(*vpp, cnp->cn_lkflags | LK_VNHELD, cnp->cn_thread); if (cnp->cn_flags & ISDOTDOT) { vn_lock(dvp, ltype | LK_RETRY); if (dvp->v_iflag & VI_DOOMED) { @@ -1368,9 +1368,9 @@ vn_dir_dd_ino(struct vnode *vp) if ((ncp->nc_flag & NCF_ISDOTDOT) != 0) continue; ddvp = ncp->nc_dvp; - VI_LOCK(ddvp); + vhold(ddvp); CACHE_RUNLOCK(); - if (vget(ddvp, LK_INTERLOCK | LK_SHARED | LK_NOWAIT, curthread)) + if (vget(ddvp, LK_SHARED | LK_NOWAIT | LK_VNHELD, curthread)) return (NULL); return (ddvp); } diff --git a/sys/kern/vfs_hash.c b/sys/kern/vfs_hash.c index 930fca1..48601e7 100644 --- a/sys/kern/vfs_hash.c +++ b/sys/kern/vfs_hash.c @@ -84,9 +84,9 @@ vfs_hash_get(const struct mount *mp, u_int hash, int flags, struct thread *td, s continue; if (fn != NULL && fn(vp, arg)) continue; - VI_LOCK(vp); + vhold(vp); rw_runlock(&vfs_hash_lock); - error = vget(vp, flags | LK_INTERLOCK, td); + error = vget(vp, flags | LK_VNHELD, td); if (error == ENOENT && (flags & LK_NOWAIT) == 0) break; if (error) @@ -128,9 +128,9 @@ vfs_hash_insert(struct vnode *vp, u_int hash, int flags, struct thread *td, stru continue; if (fn != NULL && fn(vp2, arg)) continue; - VI_LOCK(vp2); + vhold(vp2); rw_wunlock(&vfs_hash_lock); - error = vget(vp2, flags | LK_INTERLOCK, td); + error = vget(vp2, flags | LK_VNHELD, td); if (error == ENOENT && (flags & LK_NOWAIT) == 0) break; rw_wlock(&vfs_hash_lock); diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c index fda80c9..c2cd91e 100644 --- a/sys/kern/vfs_subr.c +++ b/sys/kern/vfs_subr.c @@ -68,6 +68,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -102,9 +103,9 @@ static int flushbuflist(struct bufv *bufv, int flags, struct bufobj *bo, static void syncer_shutdown(void *arg, int howto); static int vtryrecycle(struct vnode *vp); static void v_incr_usecount(struct vnode *); -static void v_decr_usecount(struct vnode *); -static void v_decr_useonly(struct vnode *); static void v_upgrade_usecount(struct vnode *); +static void v_incr_devcount(struct vnode *, bool locked); +static void v_decr_devcount(struct vnode *); static void vnlru_free(int); static void vgonel(struct vnode *); static void vfs_knllock(void *arg); @@ -863,7 +864,7 @@ vnlru_free(int count) */ freevnodes--; vp->v_iflag &= ~VI_FREE; - vp->v_holdcnt++; + refcount_acquire(&vp->v_holdcnt); mtx_unlock(&vnode_free_list_mtx); VI_UNLOCK(vp); @@ -2082,70 +2083,60 @@ static void v_incr_usecount(struct vnode *vp) { + ASSERT_VI_UNLOCKED(vp, __func__); CTR2(KTR_VFS, "%s: vp %p", __func__, vp); - vholdl(vp); - vp->v_usecount++; - if (vp->v_type == VCHR && vp->v_rdev != NULL) { - dev_lock(); - vp->v_rdev->si_usecount++; - dev_unlock(); - } + vhold(vp); + v_upgrade_usecount(vp); } /* - * Turn a holdcnt into a use+holdcnt such that only one call to - * v_decr_usecount is needed. + * Turn a holdcnt into a use+holdcnt. */ static void v_upgrade_usecount(struct vnode *vp) { + bool locked = false; + ASSERT_VI_UNLOCKED(vp, __func__); CTR2(KTR_VFS, "%s: vp %p", __func__, vp); - vp->v_usecount++; - if (vp->v_type == VCHR && vp->v_rdev != NULL) { - dev_lock(); - vp->v_rdev->si_usecount++; - dev_unlock(); + if (!refcount_acquire_if_not_zero(&vp->v_usecount)) { + VI_LOCK(vp); + locked = true; + refcount_acquire(&vp->v_usecount); } + v_incr_devcount(vp, locked); + if (locked) + VI_UNLOCK(vp); } /* - * Decrement the vnode use and hold count along with the driver's usecount - * if this is a chardev. The vdropl() below releases the vnode interlock - * as it may free the vnode. + * Increment si_usecount of the associated device, if any. */ static void -v_decr_usecount(struct vnode *vp) +v_incr_devcount(struct vnode *vp, bool locked) { - ASSERT_VI_LOCKED(vp, __FUNCTION__); - VNASSERT(vp->v_usecount > 0, vp, - ("v_decr_usecount: negative usecount")); - CTR2(KTR_VFS, "%s: vp %p", __func__, vp); - vp->v_usecount--; + ASSERT_VI_LOCK(vp, __func__, locked); + if (vp->v_type != VCHR) + return; + if (!locked) + VI_LOCK(vp); if (vp->v_type == VCHR && vp->v_rdev != NULL) { dev_lock(); - vp->v_rdev->si_usecount--; + vp->v_rdev->si_usecount++; dev_unlock(); } - vdropl(vp); + if (!locked) + VI_UNLOCK(vp); } /* - * Decrement only the use count and driver use count. This is intended to - * be paired with a follow on vdropl() to release the remaining hold count. - * In this way we may vgone() a vnode with a 0 usecount without risk of - * having it end up on a free list because the hold count is kept above 0. + * Increment si_usecount of the associated device, if any. */ static void -v_decr_useonly(struct vnode *vp) +v_decr_devcount(struct vnode *vp) { - ASSERT_VI_LOCKED(vp, __FUNCTION__); - VNASSERT(vp->v_usecount > 0, vp, - ("v_decr_useonly: negative usecount")); - CTR2(KTR_VFS, "%s: vp %p", __func__, vp); - vp->v_usecount--; if (vp->v_type == VCHR && vp->v_rdev != NULL) { dev_lock(); vp->v_rdev->si_usecount--; @@ -2163,17 +2154,22 @@ v_decr_useonly(struct vnode *vp) int vget(struct vnode *vp, int flags, struct thread *td) { - int error; + int error, oweinact; - error = 0; VNASSERT((flags & LK_TYPE_MASK) != 0, vp, ("vget: invalid lock operation")); + + ASSERT_VI_LOCK(vp, __func__, (flags & LK_INTERLOCK) != 0); + if ((flags & LK_VNHELD) != 0) + VNASSERT((vp->v_holdcnt > 0), vp, + ("vget: LK_VNHELD passed but vnode not held")); + CTR3(KTR_VFS, "%s: vp %p with flags %d", __func__, vp, flags); - if ((flags & LK_INTERLOCK) == 0) - VI_LOCK(vp); - vholdl(vp); - if ((error = vn_lock(vp, flags | LK_INTERLOCK)) != 0) { + if ((flags & LK_VNHELD) == 0) + _vhold(vp, (flags & LK_INTERLOCK) != 0); + + if ((error = vn_lock(vp, flags)) != 0) { vdrop(vp); CTR2(KTR_VFS, "%s: impossible to lock vnode %p", __func__, vp); @@ -2181,22 +2177,33 @@ vget(struct vnode *vp, int flags, struct thread *td) } if (vp->v_iflag & VI_DOOMED && (flags & LK_RETRY) == 0) panic("vget: vn_lock failed to return ENOENT\n"); - VI_LOCK(vp); - /* Upgrade our holdcnt to a usecount. */ - v_upgrade_usecount(vp); /* * We don't guarantee that any particular close will * trigger inactive processing so just make a best effort * here at preventing a reference to a removed file. If * we don't succeed no harm is done. + * + * Upgrade our holdcnt to a usecount. */ - if (vp->v_iflag & VI_OWEINACT) { - if (VOP_ISLOCKED(vp) == LK_EXCLUSIVE && + if (refcount_acquire_if_not_zero(&vp->v_usecount)) { + v_incr_devcount(vp, false); + VNASSERT((vp->v_iflag & VI_OWEINACT) == 0, vp, + ("vget: vnode with VI_OWEINACT and usecount")); + } else { + VI_LOCK(vp); + if ((vp->v_iflag & VI_OWEINACT) == 0) { + oweinact = 0; + } else { + oweinact = 1; + vp->v_iflag &= ~VI_OWEINACT; + } + refcount_acquire(&vp->v_usecount); + v_incr_devcount(vp, true); + if (oweinact && VOP_ISLOCKED(vp) == LK_EXCLUSIVE && (flags & LK_NOWAIT) == 0) vinactive(vp, td); - vp->v_iflag &= ~VI_OWEINACT; + VI_UNLOCK(vp); } - VI_UNLOCK(vp); return (0); } @@ -2208,9 +2215,7 @@ vref(struct vnode *vp) { CTR2(KTR_VFS, "%s: vp %p", __func__, vp); - VI_LOCK(vp); v_incr_usecount(vp); - VI_UNLOCK(vp); } /* @@ -2225,13 +2230,8 @@ vref(struct vnode *vp) int vrefcnt(struct vnode *vp) { - int usecnt; - - VI_LOCK(vp); - usecnt = vp->v_usecount; - VI_UNLOCK(vp); - return (usecnt); + return (vp->v_usecount); } #define VPUTX_VRELE 1 @@ -2250,33 +2250,43 @@ vputx(struct vnode *vp, int func) ASSERT_VOP_LOCKED(vp, "vput"); else KASSERT(func == VPUTX_VRELE, ("vputx: wrong func")); + ASSERT_VI_UNLOCKED(vp, __func__); CTR2(KTR_VFS, "%s: vp %p", __func__, vp); - VI_LOCK(vp); - /* Skip this v_writecount check if we're going to panic below. */ - VNASSERT(vp->v_writecount < vp->v_usecount || vp->v_usecount < 1, vp, - ("vputx: missed vn_close")); - error = 0; - - if (vp->v_usecount > 1 || ((vp->v_iflag & VI_DOINGINACT) && - vp->v_usecount == 1)) { + if (refcount_release_if_not_last(&vp->v_usecount)) { if (func == VPUTX_VPUT) VOP_UNLOCK(vp, 0); - v_decr_usecount(vp); + v_decr_devcount(vp); + vdrop(vp); return; } - if (vp->v_usecount != 1) { - vprint("vputx: negative ref count", vp); - panic("vputx: negative ref cnt"); - } - CTR2(KTR_VFS, "%s: return vnode %p to the freelist", __func__, vp); + VI_LOCK(vp); + /* * We want to hold the vnode until the inactive finishes to * prevent vgone() races. We drop the use count here and the * hold count below when we're done. */ - v_decr_useonly(vp); + if (!refcount_release(&vp->v_usecount) || (vp->v_iflag & VI_DOINGINACT)) { + if (func == VPUTX_VPUT) + VOP_UNLOCK(vp, 0); + v_decr_devcount(vp); + vdropl(vp); + return; + } + + v_decr_devcount(vp); + + error = 0; + + if (vp->v_usecount != 0) { + vprint("vputx: negative ref count", vp); + panic("vputx: negative ref cnt"); + } + + CTR2(KTR_VFS, "%s: return vnode %p to the freelist", __func__, vp); + /* * We must call VOP_INACTIVE with the node locked. Mark * as VI_DOINGINACT to avoid recursion. @@ -2346,38 +2356,29 @@ vunref(struct vnode *vp) } /* - * Somebody doesn't want the vnode recycled. - */ -void -vhold(struct vnode *vp) -{ - - VI_LOCK(vp); - vholdl(vp); - VI_UNLOCK(vp); -} - -/* * Increase the hold count and activate if this is the first reference. */ void -vholdl(struct vnode *vp) +_vhold(struct vnode *vp, bool locked) { struct mount *mp; + ASSERT_VI_LOCK(vp, __func__, locked); CTR2(KTR_VFS, "%s: vp %p", __func__, vp); -#ifdef INVARIANTS - /* getnewvnode() calls v_incr_usecount() without holding interlock. */ - if (vp->v_type != VNON || vp->v_data != NULL) { - ASSERT_VI_LOCKED(vp, "vholdl"); - VNASSERT(vp->v_holdcnt > 0 || (vp->v_iflag & VI_FREE) != 0, - vp, ("vholdl: free vnode is held")); + if (refcount_acquire_if_not_zero(&vp->v_holdcnt)) { + VNASSERT((vp->v_iflag & VI_FREE) == 0, vp, + ("_vhold: vnode with holdcnt is free")); + return; } -#endif - vp->v_holdcnt++; - if ((vp->v_iflag & VI_FREE) == 0) + if (!locked) + VI_LOCK(vp); + if ((vp->v_iflag & VI_FREE) == 0) { + refcount_acquire(&vp->v_holdcnt); + if (!locked) + VI_UNLOCK(vp); return; - VNASSERT(vp->v_holdcnt == 1, vp, ("vholdl: wrong hold count")); + } + VNASSERT(vp->v_holdcnt == 0, vp, ("vholdl: wrong hold count")); VNASSERT(vp->v_op != NULL, vp, ("vholdl: vnode already reclaimed.")); /* * Remove a vnode from the free list, mark it as in use, @@ -2394,18 +2395,9 @@ vholdl(struct vnode *vp) TAILQ_INSERT_HEAD(&mp->mnt_activevnodelist, vp, v_actfreelist); mp->mnt_activevnodelistsize++; mtx_unlock(&vnode_free_list_mtx); -} - -/* - * Note that there is one less who cares about this vnode. - * vdrop() is the opposite of vhold(). - */ -void -vdrop(struct vnode *vp) -{ - - VI_LOCK(vp); - vdropl(vp); + refcount_acquire(&vp->v_holdcnt); + if (!locked) + VI_UNLOCK(vp); } /* @@ -2414,20 +2406,25 @@ vdrop(struct vnode *vp) * (marked VI_DOOMED) in which case we will free it. */ void -vdropl(struct vnode *vp) +_vdrop(struct vnode *vp, bool locked) { struct bufobj *bo; struct mount *mp; int active; - ASSERT_VI_LOCKED(vp, "vdropl"); + ASSERT_VI_LOCK(vp, __func__, locked); CTR2(KTR_VFS, "%s: vp %p", __func__, vp); if (vp->v_holdcnt <= 0) panic("vdrop: holdcnt %d", vp->v_holdcnt); - vp->v_holdcnt--; - VNASSERT(vp->v_holdcnt >= vp->v_usecount, vp, - ("hold count less than use count")); - if (vp->v_holdcnt > 0) { + if (refcount_release_if_not_last(&vp->v_holdcnt)) { + if (locked) + VI_UNLOCK(vp); + return; + } + + if (!locked) + VI_LOCK(vp); + if (refcount_release(&vp->v_holdcnt) == 0) { VI_UNLOCK(vp); return; } diff --git a/sys/sys/lockmgr.h b/sys/sys/lockmgr.h index ff0473d..a74d5f5 100644 --- a/sys/sys/lockmgr.h +++ b/sys/sys/lockmgr.h @@ -159,6 +159,7 @@ _lockmgr_args_rw(struct lock *lk, u_int flags, struct rwlock *ilk, #define LK_SLEEPFAIL 0x000800 #define LK_TIMELOCK 0x001000 #define LK_NODDLKTREAT 0x002000 +#define LK_VNHELD 0x004000 /* * Operations for lockmgr(). diff --git a/sys/sys/refcount.h b/sys/sys/refcount.h index 4611664..74c51c9 100644 --- a/sys/sys/refcount.h +++ b/sys/sys/refcount.h @@ -64,4 +64,32 @@ refcount_release(volatile u_int *count) return (old == 1); } +static __inline int +refcount_acquire_if_not_zero(volatile u_int *count) +{ + int old; + + for (;;) { + old = *count; + if (old == 0) + return (0); + if (atomic_cmpset_int(count, old, old + 1)) + return (1); + } +} + +static __inline int +refcount_release_if_not_last(volatile u_int *count) +{ + int old; + + for (;;) { + old = *count; + if (old == 1) + return (0); + if (atomic_cmpset_int(count, old, old - 1)) + return (1); + } +} + #endif /* ! __SYS_REFCOUNT_H__ */ diff --git a/sys/sys/vnode.h b/sys/sys/vnode.h index e1f912e..c695b52 100644 --- a/sys/sys/vnode.h +++ b/sys/sys/vnode.h @@ -547,6 +547,15 @@ void assert_vop_unlocked(struct vnode *vp, const char *str); #define ASSERT_VOP_UNLOCKED(vp, str) ((void)0) #endif /* DEBUG_VFS_LOCKS */ +static __inline void +ASSERT_VI_LOCK(struct vnode *vp, const char *str, bool locked) +{ + + if (locked) + ASSERT_VI_LOCKED(vp, str); + else + ASSERT_VI_UNLOCKED(vp, str); +} /* * This call works for vnodes in the kernel. @@ -649,13 +658,15 @@ int vaccess_acl_posix1e(enum vtype type, uid_t file_uid, struct ucred *cred, int *privused); void vattr_null(struct vattr *vap); int vcount(struct vnode *vp); -void vdrop(struct vnode *); -void vdropl(struct vnode *); +#define vdrop(vp) _vdrop((vp), 0) +#define vdropl(vp) _vdrop((vp), 1) +void _vdrop(struct vnode *, bool); int vflush(struct mount *mp, int rootrefs, int flags, struct thread *td); int vget(struct vnode *vp, int lockflag, struct thread *td); void vgone(struct vnode *vp); -void vhold(struct vnode *); -void vholdl(struct vnode *); +#define vhold(vp) _vhold((vp), 0) +#define vholdl(vp) _vhold((vp), 1) +void _vhold(struct vnode *, bool); void vinactive(struct vnode *, struct thread *); int vinvalbuf(struct vnode *vp, int save, int slpflag, int slptimeo); int vtruncbuf(struct vnode *vp, struct ucred *cred, off_t length, -- Mateusz Guzik From owner-freebsd-fs@FreeBSD.ORG Tue Mar 17 01:54:50 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA6EA91F for ; Tue, 17 Mar 2015 01:54:50 +0000 (UTC) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 38C9E96B for ; Tue, 17 Mar 2015 01:54:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id t2H1qAVs085728; Tue, 17 Mar 2015 04:52:10 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Tue, 17 Mar 2015 04:52:10 +0300 (MSK) From: Dmitry Morozovsky To: Steven Hartland Subject: Re: ZFS doing background writes? In-Reply-To: <55076B84.0@multiplay.co.uk> Message-ID: References: <55076B84.0@multiplay.co.uk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [0.0.0.0]); Tue, 17 Mar 2015 04:53:17 +0300 (MSK) Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 01:54:50 -0000 On Mon, 16 Mar 2015, Steven Hartland wrote: > yes exactly that its defined by vfs.zfs.txg.timeout. Well, but what data (modulo atimes, which I presume OP had turned off before) are written? > > On 16/03/2015 23:09, Dirk E wrote: > > I'm curious now; does ZFS do any I/O on the background? > > > > Because i'm getting periodic writes from ZFS to my disks, beginning right > > after i import the pool. > > > > Even going to single user mode does not help; zpool iostat -v 1 still shows > > the writes with static 5 second interval. > > > > What would cause this behaviour? I encountered it with both 10.1-RELEASE and > > a very recent HEAD. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-fs@FreeBSD.ORG Tue Mar 17 02:07:48 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2F295A5E for ; Tue, 17 Mar 2015 02:07:48 +0000 (UTC) Received: from nm2-vm1.bullet.mail.bf1.yahoo.com (nm2-vm1.bullet.mail.bf1.yahoo.com [98.139.213.158]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CA19BA5D for ; Tue, 17 Mar 2015 02:07:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1426557946; bh=BdJthzTD/4GnhKcm0yvk5F5/2J7//MUJfLOCLn7hBIk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=DP7F4tg5l4hbhW1ziI/Rk5Qg3kgn8sugcWedIxcnFRWN+62tdcZUPDk4MNgn1OHSVqdAW1keyJ5+cvS06soPguojyJ5NZDe6OY1RVIdRqj94JmUc9957ALtK39CTyJ98/5AeRz2wbAVMF+z4CcbglOHB8JOMONALdBfLmcqnBrE834ngnSmpzh/MNs4/tzkwyJTRgRB2mIPFmtCR3JRdC9lciXoMLsgr6aocReUyaSsm7cLoFWa83+/IjgiZlHPDhe4MQnB6bH0/HMD27adXt18sNhOo4xpONnnQEqluaqJ9gGhEJR46tlF0sexCdHOF64GcvZ1JESoH729fuDG2JA== Received: from [98.139.170.178] by nm2.bullet.mail.bf1.yahoo.com with NNFMP; 17 Mar 2015 02:05:46 -0000 Received: from [98.139.211.201] by tm21.bullet.mail.bf1.yahoo.com with NNFMP; 17 Mar 2015 02:05:46 -0000 Received: from [127.0.0.1] by smtp210.mail.bf1.yahoo.com with NNFMP; 17 Mar 2015 02:05:46 -0000 X-Yahoo-Newman-Id: 644058.26372.bm@smtp210.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: jb8HcnMVM1mxVwZ4QD_1ca3.e5nlARuYgvwAw32UsfES9zB i1UsTXKE2QrE_glOhg8WYzfaP5alRJJYLzohNd6uz.ym_jvZws2Y2xEw8wBq mD3iEa6DdcZdYZTGH06UfR7Y7qd8sgo.dgCrCY8iGqrZjLZh9_yhB1Xom7Qq yA56RG.t.GTgO40WSY2aFoXozU1AkeIe3Ksv4sPkXDzHjOxXSC1J1.x9s7qN WNPomT4uitpd1tvsqexM7uYeQ4Mv7XPxood_vwe.UoYcBhwrQLMMkm8QxYgE OmpIGTPk8UEcldHhLxM5hROmu1kLE8Hd7JOaJwF.cJDsVOBO_fok5W3.vjGJ bix1OwNMRIZ3JH.q4yTcv66SK14FY8OF0pbKX0fiKtQ0te5_N7Kx9He9ZJj8 liBcboVyg0dKn8gHk0n6Oj38.gBNc5DHR6bDNDhx_xsDVcWeEvpjYxdc.ly8 5m72HYsFI7fD55RTLIVihMvvASWoejWvH0MCPzaYkhEVQ5amIkNUnbJwIeQw uAAfdsFuEHPJ4L9HMdZdUGIOL0n1u6qmN X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: Willing to do what I can to help with a decent fs for removable media... From: Pedro Giffuni In-Reply-To: Date: Mon, 16 Mar 2015 21:04:01 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54FB0BBE.7060907@FreeBSD.org> To: Dmitry Morozovsky X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 02:07:48 -0000 > Il giorno 16/mar/2015, alle ore 20:35, Dmitry Morozovsky = ha scritto: >=20 > On Sat, 7 Mar 2015, Pedro Giffuni wrote: >=20 >> What is wrong with ext2/3 ? >>=20 >> OK, we don't support journalling but I doubt you really need that for >> removable media. >=20 > Well, as I did (sparely) tested it, the most irritating problem was = that=20 > FreeBSD declined to even mount ext* with "unsupported" journalling = features,=20 > even whan journal was clean. >=20 I had no problems formatting a fresh ext3 filesystem, mounting it and = using it. I even enabled the directory index (which is experimental) and = build a port on top of it. Oh and I ran fsx on it too. This is, of course, a recent version (10-stable). Pedro. From owner-freebsd-fs@FreeBSD.ORG Tue Mar 17 06:31:36 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F042D3D2 for ; Tue, 17 Mar 2015 06:31:36 +0000 (UTC) Received: from DUB004-OMC3S13.hotmail.com (dub004-omc3s13.hotmail.com [157.55.2.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "*.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 74BF087B for ; Tue, 17 Mar 2015 06:31:35 +0000 (UTC) Received: from DUB131-W2 ([157.55.2.7]) by DUB004-OMC3S13.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Mon, 16 Mar 2015 23:30:24 -0700 X-TMN: [blAlu1yxIC5WhcJ7gpiPfh9BykkBfgX+] X-Originating-Email: [cipher_nl@hotmail.com] Message-ID: From: Dirk E To: Dmitry Morozovsky , Steven Hartland Subject: RE: ZFS doing background writes? Date: Tue, 17 Mar 2015 07:30:24 +0100 Importance: Normal In-Reply-To: References: , <55076B84.0@multiplay.co.uk>, Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 17 Mar 2015 06:30:24.0458 (UTC) FILETIME=[D9C562A0:01D0607B] Cc: "freebsd-fs@freebsd.org" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 06:31:37 -0000 > On Mon=2C 16 Mar 2015=2C Steven Hartland wrote:=0A= >=0A= >> yes exactly that its defined by vfs.zfs.txg.timeout.=0A= >=0A= > Well=2C but what data (modulo atimes=2C which I presume OP had turned off= before)=0A= > are written?=0A= =0A= I indeed have atime=3Doff for the whole pool. But even with atime enabled= =2C this behaviour should not happen=2C since no files are being accessed. = Surely not in single user mode=3B the only processes outside of the kernel = were '/bin/sh' and 'top'. Or zpool iostat when i ran it.=0A= =0A= I left the machine on and after a bunch of hours it is still doing periodic= al writes. The total ARC usage remains small: 5300K and changes slightly ov= er time - again with no host writes.=0A= =0A= Even unmounting all ZFS filesystems will NOT cause this behaviour to go awa= y. It seems to originate from the ZFS kernel itself=2C doing some autonomou= s maintenance on the background=2C or other feature.'=0A= =0A= Using top to sort processes with the longest CPU TIME=2C i can see:=0A= =0A= idle: 27.9H=0A= kernel: 6:48=0A= intr: 4:34=0A= zfskern: 0:33=0A= geom: 0:29=0A= syncer: 0:16=0A= rand_harv 0:11=0A= cam: 0:09=0A= pf purge: 0:08=0A= powerd: 0:03=0A= =0A= This machine has done very little than boot and import the pool. As can be = seen=2C the kernel and ZFS are pretty active in terms of CPU power.=0A= =0A= Anyone have a clue?=0A= = From owner-freebsd-fs@FreeBSD.ORG Tue Mar 17 09:18:26 2015 Return-Path: Delivered-To: freebsd-fs@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 C7491A5E for ; Tue, 17 Mar 2015 09:18:26 +0000 (UTC) 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 934EFCB6 for ; Tue, 17 Mar 2015 09:18:26 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2H9IQmE036799 for ; Tue, 17 Mar 2015 09:18:26 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 198242] [zfs] L2ARC degraded. Checksum errors, I/O errors Date: Tue, 17 Mar 2015 09:18: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.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: lehel.bernadt@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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 09:18:26 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198242 Lehel Bernadt changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lehel.bernadt@gmail.com --- Comment #4 from Lehel Bernadt --- I'm having the same problem. L2ARC is on a Samsung 840 PRO SSD. ------------------------------------------------------------------------ ZFS Subsystem Report Tue Mar 17 10:12:30 2015 ------------------------------------------------------------------------ L2 ARC Summary: (DEGRADED) Passed Headroom: 79.34m Tried Lock Failures: 8.06m IO In Progress: 934 Low Memory Aborts: 33 Free on Write: 2.38k Writes While Full: 8.99k R/W Clashes: 243 Bad Checksums: 5.83m IO Errors: 768.49k SPA Mismatch: 21.27b L2 ARC Size: (Adaptive) 76.25 GiB Header Size: 0.26% 200.69 MiB L2 ARC Evicts: Lock Retries: 11 Upon Reading: 0 L2 ARC Breakdown: 35.31m Hit Ratio: 31.74% 11.21m Miss Ratio: 68.26% 24.11m Feeds: 1.59m L2 ARC Buffer: Bytes Scanned: 1.36 PiB Buffer Iterations: 1.59m List Iterations: 101.39m NULL List Iterations: 994.41k L2 ARC Writes: Writes Sent: 100.00% 40.13k ------------------------------------------------------------------------ -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Tue Mar 17 10:25:20 2015 Return-Path: Delivered-To: freebsd-fs@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 DD342EED for ; Tue, 17 Mar 2015 10:25:20 +0000 (UTC) Received: from muller.mulle-kybernetik.com (muller.mulle-kybernetik.com [5.9.30.29]) by mx1.freebsd.org (Postfix) with ESMTP id 563EF7AD for ; Tue, 17 Mar 2015 10:25:19 +0000 (UTC) Received: (qmail 79780 invoked from network); 17 Mar 2015 10:18:35 -0000 Received: from unknown (HELO optimist.z.net) (znek@5.9.30.11) by mail.mulle-kybernetik.com with AES128-SHA encrypted SMTP; 17 Mar 2015 10:18:35 -0000 From: =?iso-8859-1?Q?Marcus_M=FCller?= Content-Type: multipart/signed; boundary="Apple-Mail=_1B0459AF-4EA6-4045-8763-AC80FD884051"; protocol="application/pkcs7-signature"; micalg=sha1 Subject: zfs destroy dry-run lying about reclaimable space? Message-Id: Date: Tue, 17 Mar 2015 11:18:32 +0100 To: freebsd-fs@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 10:25:20 -0000 --Apple-Mail=_1B0459AF-4EA6-4045-8763-AC80FD884051 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi ZFS experts, I just stumbled across this one: root@tank:(/)# zfs-destroy-snapshots.sh -n tank/usr/local would destroy tank/usr/local@zfs-auto-snap_monthly-2014-04-01-00h28 would reclaim 53.6M would destroy tank/usr/local@zfs-auto-snap_monthly-2014-05-01-00h28 would reclaim 8.32M would destroy tank/usr/local@zfs-auto-snap_monthly-2014-06-01-00h28 would reclaim 81.4M would destroy tank/usr/local@zfs-auto-snap_monthly-2014-07-01-00h28 would reclaim 170M [...] root@tank:(/)# zfs-destroy-snapshots.sh tank/usr/local will destroy tank/usr/local@zfs-auto-snap_monthly-2014-04-01-00h28 will reclaim 53.6M will destroy tank/usr/local@zfs-auto-snap_monthly-2014-05-01-00h28 will reclaim 191M will destroy tank/usr/local@zfs-auto-snap_monthly-2014-06-01-00h28 will reclaim 1.17G will destroy tank/usr/local@zfs-auto-snap_monthly-2014-07-01-00h28 will reclaim 177M [...] zfs-destroy-snapshots.sh iterates on all snapshots of the given = filesystem and calls zfs destroy -v [-n] , no magic involved. I was a bit stumped by the fact that the sum of the reclaimable space = reported via dry-run of zfs-destroy-snapshots.sh wasn't anywhere near = the supposed "usedbysnapshots" value of the filesystem, so I just = deleted all snapshots for real to see what would happen. Unfortunately I = cannot zfs diff any of them now to get any clues why the dry-run would = be so wrong, but maybe anyone else knows? Is this a known bug already? Cheers, Marcus -- Marcus M=FCller . . . http://www.mulle-kybernetik.com/znek/ --Apple-Mail=_1B0459AF-4EA6-4045-8763-AC80FD884051 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFeDCCBXQw ggNcoAMCAQICAQUwDQYJKoZIhvcNAQEEBQAwgYkxCzAJBgNVBAYTAkRFMREwDwYDVQQHEwhEb3J0 bXVuZDEMMAoGA1UECBMDTlJXMRkwFwYDVQQKExBNdWxsZSBreWJlcm5ldGlLMRMwEQYDVQQLEwpD cnlwdG9NdWxsMSkwJwYJKoZIhvcNAQkBFhphZG1pbkBtdWxsZS1reWJlcm5ldGlrLmNvbTAeFw0w NzExMTMyMjQ0MTFaFw0xNzExMTAxMzU5MTVaMEMxFzAVBgNVBAMMDk1hcmN1cyBNw7xsbGVyMSgw JgYJKoZIhvcNAQkBFhl6bmVrQG11bGxlLWt5YmVybmV0aWsuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAsfY3y3gSAXARzS9kU6fI86rTrxZ8Xwr2Y3nWyGxZzCR+TBDP+wt9Xrox 9DYXMKsULSWPJo7m7VAJom2W9HvVHJysSHe6XAlc337SKebRrZU3EZZa9XxqtIpkj4ofaNdYR7rm ccWNgF/cw/ktS6q7oEZmp0mZbENZAWhlTRvMS/isr5UWjZzltB/h80ek2zH1IKtvLrTW7f8FPOD2 Ko/inTfTse+vwMJDVsKC7IixibCM/TNCHz9B7RwMbDnUd7w9x5w+i72OP5m9wM0T2B/3y9JFm9nj FFgR9XU03rjcqrGNmmyNacdG3OWjD3uC2VlyD8Epzieu+nGgocyFe3xy8wIDAQABo4IBKjCCASYw DAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQUOgJFw4VT2Al6PqOPhNjzB6OA/1gwgbYGA1UdIwSBrjCB q4AUi4wPa5pKvXInb/+V4R14pS98BlOhgY+kgYwwgYkxCzAJBgNVBAYTAkRFMREwDwYDVQQHEwhE b3J0bXVuZDEMMAoGA1UECBMDTlJXMRkwFwYDVQQKExBNdWxsZSBreWJlcm5ldGlLMRMwEQYDVQQL EwpDcnlwdG9NdWxsMSkwJwYJKoZIhvcNAQkBFhphZG1pbkBtdWxsZS1reWJlcm5ldGlrLmNvbYIB ATALBgNVHQ8EBAMCBLAwEQYJYIZIAYb4QgEBBAQDAgWgMB4GCWCGSAGG+EIBDQQRFg94Y2EgY2Vy dGlmaWNhdGUwDQYJKoZIhvcNAQEEBQADggIBAKPsEUz8o2pTVYmcc6FO9oyzjgHPVqbQxPD/Ku+u 1WvS2P+z+zGKKoD67sp8+0DdEoysEKjiY9uKhvGpK0YQ09cFRL4lJwtVz5WwGe/g9Q/kAMNp0Nif 3KOD8H76Z7nUw10MwQ5hRf0apn1kv8R/2Tz3wP2amCU0XJm+AC1Q2oeFPo20uRQckBIwKcHo/NRl NNgSUs2m6pnqyndk2+fTpqpoY77UV6CDTEDEDzzZJnRXyzjzkop2fzYtZBET71Xv1e++s7KsSEiX EQmaJoBBgDglLMZZlNyX/qLC75STK6BlWVjHnNIeq7ziSyAQ1ZLjAcn46bvc/JXpIkFUEEC5qyOi t0WUBZFnhCQm9ehd7jcKQdQ23PcW+bg5256EhU4OPrfdoSsWOvGvxFETuc/jfIXFqXgfN/1rGjZF O6ZvMuTkj/WNNiiJqFITuRpp3REyEqqLKebDqPjyhVLKqbJvcsUw39WwjcybbyhbWAGw4xSVpeqG WA1I11hBf60TBoH6pQ8LJS4cPvsmE0Un8tlgo8odbH1FO3AGQhsq/URvXc0qb6Dn3TGcVjLSrDUa FLwriHzreSBMbPKMyLBwGgq0WsGc0hQ43as3qWDIg1BdMGkNC/EU1tdyxiXiSkFBtV21pgXG1jlU qyegDrKfmZeoLhMQoQV454e+D+2cA3VybszrMYIDYDCCA1wCAQEwgY8wgYkxCzAJBgNVBAYTAkRF MREwDwYDVQQHEwhEb3J0bXVuZDEMMAoGA1UECBMDTlJXMRkwFwYDVQQKExBNdWxsZSBreWJlcm5l dGlLMRMwEQYDVQQLEwpDcnlwdG9NdWxsMSkwJwYJKoZIhvcNAQkBFhphZG1pbkBtdWxsZS1reWJl cm5ldGlrLmNvbQIBBTAJBgUrDgMCGgUAoIIBpTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xNTAzMTcxMDE4MzJaMCMGCSqGSIb3DQEJBDEWBBSrtiDM1R/rvoGbs+NH X9Icu7EXbjCBoAYJKwYBBAGCNxAEMYGSMIGPMIGJMQswCQYDVQQGEwJERTERMA8GA1UEBxMIRG9y dG11bmQxDDAKBgNVBAgTA05SVzEZMBcGA1UEChMQTXVsbGUga3liZXJuZXRpSzETMBEGA1UECxMK Q3J5cHRvTXVsbDEpMCcGCSqGSIb3DQEJARYaYWRtaW5AbXVsbGUta3liZXJuZXRpay5jb20CAQUw gaIGCyqGSIb3DQEJEAILMYGSoIGPMIGJMQswCQYDVQQGEwJERTERMA8GA1UEBxMIRG9ydG11bmQx DDAKBgNVBAgTA05SVzEZMBcGA1UEChMQTXVsbGUga3liZXJuZXRpSzETMBEGA1UECxMKQ3J5cHRv TXVsbDEpMCcGCSqGSIb3DQEJARYaYWRtaW5AbXVsbGUta3liZXJuZXRpay5jb20CAQUwDQYJKoZI hvcNAQEBBQAEggEATnu78WAYLL5g4ifdk8UFSBVmYHuuWlbr/Uem/ZjEpwTxGUm+L+XkR/0boAVD WKtTRi39E8Eg5U7dWv7HU7yDnJwara6SBVjNfP7Tay9ZwiHZyhSvFoyPSrxi+N3a6akw/l69xElE 4I2wo+g/4bwSkFWBmw053BZ4MP6NQxQV0+5jsyA/4VFERBo5IbumHCLC64ABimYT4d6IKrQ7d1Xo jnwyuhFKasIcG0+aw/ZOhprAtLsYyDyT6tPKZrAm9FeBoW0+ZyysC6J6aUZSTE8/M+iI/miFBJ0K 3ag1b6GuCP5go5YEEAG34N5QcPxvLNhyj9TLMFhL/MwKfrfvk8uMBwAAAAAAAA== --Apple-Mail=_1B0459AF-4EA6-4045-8763-AC80FD884051-- From owner-freebsd-fs@FreeBSD.ORG Tue Mar 17 11:28:07 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B2929D4E for ; Tue, 17 Mar 2015 11:28:07 +0000 (UTC) Received: from muller.mulle-kybernetik.com (muller.mulle-kybernetik.com [5.9.30.29]) by mx1.freebsd.org (Postfix) with ESMTP id 11AD0E80 for ; Tue, 17 Mar 2015 11:28:06 +0000 (UTC) Received: (qmail 87671 invoked from network); 17 Mar 2015 11:28:04 -0000 Received: from unknown (HELO optimist.z.net) (znek@5.9.30.11) by mail.mulle-kybernetik.com with AES128-SHA encrypted SMTP; 17 Mar 2015 11:28:04 -0000 From: =?iso-8859-1?Q?Marcus_M=FCller?= Content-Type: multipart/signed; boundary="Apple-Mail=_08659759-6A1E-4D16-907E-BE831652E096"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <321BAF06-210B-4E0C-8152-756FCCD82E18@mulle-kybernetik.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: zfs destroy dry-run lying about reclaimable space? Date: Tue, 17 Mar 2015 12:28:04 +0100 References: To: freebsd-fs@FreeBSD.org In-Reply-To: X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 11:28:07 -0000 --Apple-Mail=_08659759-6A1E-4D16-907E-BE831652E096 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 17.03.2015, at 11:18, Marcus M=FCller = wrote: > I was a bit stumped by the fact that the sum of the reclaimable space = reported via dry-run of zfs-destroy-snapshots.sh wasn't anywhere near = the supposed "usedbysnapshots" value of the filesystem, so I just = deleted all snapshots for real to see what would happen. Unfortunately I = cannot zfs diff any of them now to get any clues why the dry-run would = be so wrong, but maybe anyone else knows? Is this a known bug already? A bit more context: root@fbsd:(/)# uname -a FreeBSD fbsd.z.net 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #0 = 8e3e4f9(stable/10)-dirty: Wed Nov 19 16:06:59 CET 2014 = root@fbsd:/usr/obj/usr/src/sys/tank amd64 root@fbsd:(/)# zfs get version tank/usr/local NAME PROPERTY VALUE SOURCE tank/usr/local version 5 - root@fbsd:(/)# zpool get all tank NAME PROPERTY VALUE = SOURCE [...] tank feature@async_destroy enabled = local tank feature@empty_bpobj active = local tank feature@lz4_compress active = local tank feature@multi_vdev_crash_dump enabled = local tank feature@spacemap_histogram active = local tank feature@enabled_txg active = local tank feature@hole_birth active = local tank feature@extensible_dataset enabled = local tank feature@embedded_data active = local tank feature@bookmarks enabled = local tank feature@filesystem_limits enabled = local The pool was only upgraded recently, but it already had feature flag = support before (don't recall which feature flags were new). Also, I = don't recall when the filesystem version was upgraded from 4 to 5, but I = presume that's been before the snapshots had been created (I did search = in the pool history, but didn't find an upgrade statement. This pool had = been created last year and populated with a recursive dump of another = pool which has been destroyed in the meantime, thus no history logs for = this.) Cheers, Marcus -- Marcus M=FCller . . . http://www.mulle-kybernetik.com/znek/ --Apple-Mail=_08659759-6A1E-4D16-907E-BE831652E096 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFeDCCBXQw ggNcoAMCAQICAQUwDQYJKoZIhvcNAQEEBQAwgYkxCzAJBgNVBAYTAkRFMREwDwYDVQQHEwhEb3J0 bXVuZDEMMAoGA1UECBMDTlJXMRkwFwYDVQQKExBNdWxsZSBreWJlcm5ldGlLMRMwEQYDVQQLEwpD cnlwdG9NdWxsMSkwJwYJKoZIhvcNAQkBFhphZG1pbkBtdWxsZS1reWJlcm5ldGlrLmNvbTAeFw0w NzExMTMyMjQ0MTFaFw0xNzExMTAxMzU5MTVaMEMxFzAVBgNVBAMMDk1hcmN1cyBNw7xsbGVyMSgw JgYJKoZIhvcNAQkBFhl6bmVrQG11bGxlLWt5YmVybmV0aWsuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAsfY3y3gSAXARzS9kU6fI86rTrxZ8Xwr2Y3nWyGxZzCR+TBDP+wt9Xrox 9DYXMKsULSWPJo7m7VAJom2W9HvVHJysSHe6XAlc337SKebRrZU3EZZa9XxqtIpkj4ofaNdYR7rm ccWNgF/cw/ktS6q7oEZmp0mZbENZAWhlTRvMS/isr5UWjZzltB/h80ek2zH1IKtvLrTW7f8FPOD2 Ko/inTfTse+vwMJDVsKC7IixibCM/TNCHz9B7RwMbDnUd7w9x5w+i72OP5m9wM0T2B/3y9JFm9nj FFgR9XU03rjcqrGNmmyNacdG3OWjD3uC2VlyD8Epzieu+nGgocyFe3xy8wIDAQABo4IBKjCCASYw DAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQUOgJFw4VT2Al6PqOPhNjzB6OA/1gwgbYGA1UdIwSBrjCB q4AUi4wPa5pKvXInb/+V4R14pS98BlOhgY+kgYwwgYkxCzAJBgNVBAYTAkRFMREwDwYDVQQHEwhE b3J0bXVuZDEMMAoGA1UECBMDTlJXMRkwFwYDVQQKExBNdWxsZSBreWJlcm5ldGlLMRMwEQYDVQQL EwpDcnlwdG9NdWxsMSkwJwYJKoZIhvcNAQkBFhphZG1pbkBtdWxsZS1reWJlcm5ldGlrLmNvbYIB ATALBgNVHQ8EBAMCBLAwEQYJYIZIAYb4QgEBBAQDAgWgMB4GCWCGSAGG+EIBDQQRFg94Y2EgY2Vy dGlmaWNhdGUwDQYJKoZIhvcNAQEEBQADggIBAKPsEUz8o2pTVYmcc6FO9oyzjgHPVqbQxPD/Ku+u 1WvS2P+z+zGKKoD67sp8+0DdEoysEKjiY9uKhvGpK0YQ09cFRL4lJwtVz5WwGe/g9Q/kAMNp0Nif 3KOD8H76Z7nUw10MwQ5hRf0apn1kv8R/2Tz3wP2amCU0XJm+AC1Q2oeFPo20uRQckBIwKcHo/NRl NNgSUs2m6pnqyndk2+fTpqpoY77UV6CDTEDEDzzZJnRXyzjzkop2fzYtZBET71Xv1e++s7KsSEiX EQmaJoBBgDglLMZZlNyX/qLC75STK6BlWVjHnNIeq7ziSyAQ1ZLjAcn46bvc/JXpIkFUEEC5qyOi t0WUBZFnhCQm9ehd7jcKQdQ23PcW+bg5256EhU4OPrfdoSsWOvGvxFETuc/jfIXFqXgfN/1rGjZF O6ZvMuTkj/WNNiiJqFITuRpp3REyEqqLKebDqPjyhVLKqbJvcsUw39WwjcybbyhbWAGw4xSVpeqG WA1I11hBf60TBoH6pQ8LJS4cPvsmE0Un8tlgo8odbH1FO3AGQhsq/URvXc0qb6Dn3TGcVjLSrDUa FLwriHzreSBMbPKMyLBwGgq0WsGc0hQ43as3qWDIg1BdMGkNC/EU1tdyxiXiSkFBtV21pgXG1jlU qyegDrKfmZeoLhMQoQV454e+D+2cA3VybszrMYIDYDCCA1wCAQEwgY8wgYkxCzAJBgNVBAYTAkRF MREwDwYDVQQHEwhEb3J0bXVuZDEMMAoGA1UECBMDTlJXMRkwFwYDVQQKExBNdWxsZSBreWJlcm5l dGlLMRMwEQYDVQQLEwpDcnlwdG9NdWxsMSkwJwYJKoZIhvcNAQkBFhphZG1pbkBtdWxsZS1reWJl cm5ldGlrLmNvbQIBBTAJBgUrDgMCGgUAoIIBpTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xNTAzMTcxMTI4MDVaMCMGCSqGSIb3DQEJBDEWBBT6LnRXM3LYi1gv7ugt 6EmGDu0HDDCBoAYJKwYBBAGCNxAEMYGSMIGPMIGJMQswCQYDVQQGEwJERTERMA8GA1UEBxMIRG9y dG11bmQxDDAKBgNVBAgTA05SVzEZMBcGA1UEChMQTXVsbGUga3liZXJuZXRpSzETMBEGA1UECxMK Q3J5cHRvTXVsbDEpMCcGCSqGSIb3DQEJARYaYWRtaW5AbXVsbGUta3liZXJuZXRpay5jb20CAQUw gaIGCyqGSIb3DQEJEAILMYGSoIGPMIGJMQswCQYDVQQGEwJERTERMA8GA1UEBxMIRG9ydG11bmQx DDAKBgNVBAgTA05SVzEZMBcGA1UEChMQTXVsbGUga3liZXJuZXRpSzETMBEGA1UECxMKQ3J5cHRv TXVsbDEpMCcGCSqGSIb3DQEJARYaYWRtaW5AbXVsbGUta3liZXJuZXRpay5jb20CAQUwDQYJKoZI hvcNAQEBBQAEggEAemmlHKn/K9HI8Bj2vthTDZPqNvWUm0ydBeYJjryHb31V5XRPyCYz91yNwGdb uUf457C4P+toIDb1i2S3KezjzIseye1yrkKCkKAyxbvxmW1VGcIqPLg+z8/TLO4rhqqbcWwCXINJ 19QiBNuaJpoexBhYDC4A+Ou7x7ye1srQ05EnP+PfbGhJZb6CIHSkvA886EqJj1HucUHspY+lNCVW bPD9YhieUpr8e3e9umVp2Xps0IWzumTNJpiGcGj7uTSXPiPgDo9pemREzmhOWREpzM9koxyt4Dh6 VIRQOZFs6bCy3ioXHeCRNtTH+ROJlOHn+Cs4/RVk7a9VEexQKR9zcQAAAAAAAA== --Apple-Mail=_08659759-6A1E-4D16-907E-BE831652E096-- From owner-freebsd-fs@FreeBSD.ORG Tue Mar 17 14:19:23 2015 Return-Path: Delivered-To: freebsd-fs@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 C56CA505 for ; Tue, 17 Mar 2015 14:19:23 +0000 (UTC) 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 AB62031C for ; Tue, 17 Mar 2015 14:19:23 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2HEJNYw020718 for ; Tue, 17 Mar 2015 14:19:23 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 198626] Mounted USB key with FAT32 file-system, inserted 2nd key, mounted file-system went blank Date: Tue, 17 Mar 2015 14:19:23 +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-RELEASE 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 14:19:23 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198626 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org --- Comment #3 from Mark Linimon --- Unsure about where the error lies, but assume that it's in msdosfs. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Tue Mar 17 15:36:37 2015 Return-Path: Delivered-To: freebsd-fs@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 C0A13B32 for ; Tue, 17 Mar 2015 15:36:37 +0000 (UTC) Received: from mx1.repromedia.at (unknown [IPv6:2001:858:105::1:a13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.repromedia.at", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 68545E43 for ; Tue, 17 Mar 2015 15:36:37 +0000 (UTC) Received: from sea1.repro.intra (sea1.repro.intra [192.168.7.20]) by mx2.repromedia.at (Postfix) with ESMTP id D43D03001C9E for ; Tue, 17 Mar 2015 16:36:34 +0100 (CET) Received: from sea1.repro.intra (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 13C9A9069C_5084A03B for ; Tue, 17 Mar 2015 15:36:35 +0000 (GMT) Received: from mx1.repromedia.at (mailcheck1.repro.intra [192.168.7.137]) by sea1.repro.intra (Sophos Email Appliance) with ESMTP id B808E8D6E6_5084A02F for ; Tue, 17 Mar 2015 15:36:34 +0000 (GMT) Received: from rhodos.repromedia.at (rhodos.repromedia.at [IPv6:2001:858:105::1:aca]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.repromedia.at (Postfix) with ESMTPSA id 79C7F1000DD4 for ; Tue, 17 Mar 2015 16:36:34 +0100 (CET) From: Thomas Kotzian Subject: ZFS Bug Report (2nd try) Message-Id: <75C69269-E62C-4670-BD27-672A50A39934@repromedia.at> Date: Tue, 17 Mar 2015 16:36:34 +0100 To: freebsd-fs@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 15:36:37 -0000 Hello! I am running a freebsd based samba server and have regular zfs lockups. = The systems keeps on running, but the filesystem shows defects. *** Example: $ ls -al /tank/printarchive/ [...] ls: ./.zfs: Operation not supported dr-xr-xr-x 4 root wheel 4 Jan 16 17:36 .zfs drwxrws--- 7 rm_maetz printarchive 9 Dec 4 09:15 Diverse [...] or sometimes =E2=80=9Els" hangs on an entry and cannot finish the = operation and return to the shell or be interrupted. Samba crashes and drops connection (client disconnects) Reboot doesn=E2=80=99t work (reaches =E2=80=9Eall buffers synced=E2=80=9C = and stops there - doesn=E2=80=99t shut down geom raid of boot drives) *** Info (maybe useful): attached =E2=80=A6 i have gathered some information described from = https://wiki.freebsd.org/AvgZfsDeadlockDebug = Please help! Thank you! Best regards, Thomas Kotzian From owner-freebsd-fs@FreeBSD.ORG Tue Mar 17 15:47:40 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AEA1EE22 for ; Tue, 17 Mar 2015 15:47:40 +0000 (UTC) Received: from mx1.repromedia.at (unknown [IPv6:2001:858:105::1:a12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.repromedia.at", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 69AC6F7A for ; Tue, 17 Mar 2015 15:47:40 +0000 (UTC) Received: from sea2.repro.intra (sea2.repro.intra [192.168.7.21]) by mx1.repromedia.at (Postfix) with ESMTP id 4DBBF1001E03 for ; Tue, 17 Mar 2015 16:47:37 +0100 (CET) Received: from sea2.repro.intra (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 6D3AA220BF_5084C99B for ; Tue, 17 Mar 2015 15:47:37 +0000 (GMT) Received: from mx1.repromedia.at (mailcheck1.repro.intra [192.168.7.137]) by sea2.repro.intra (Sophos Email Appliance) with ESMTP id 549331F262_5084C99F for ; Tue, 17 Mar 2015 15:47:37 +0000 (GMT) Received: from rhodos.repromedia.at (rhodos.repromedia.at [IPv6:2001:858:105::1:aca]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.repromedia.at (Postfix) with ESMTPSA id 170DF1001E03 for ; Tue, 17 Mar 2015 16:47:37 +0100 (CET) From: Thomas Kotzian Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: ZFS Bug Report (2nd try) - followup Message-Id: Date: Tue, 17 Mar 2015 16:47:37 +0100 To: freebsd-fs@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 15:47:40 -0000 Hello! Seems the attachment with the additional info was lost. https://gist.github.com/935201e32bc0893792ea.git Thomas From owner-freebsd-fs@FreeBSD.ORG Tue Mar 17 20:40:06 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA036C68 for ; Tue, 17 Mar 2015 20:40:06 +0000 (UTC) Received: from wssmtp1.net4all.ch (wssmtp1.net4all.ch [80.80.228.81]) by mx1.freebsd.org (Postfix) with ESMTP id 63A9D88E for ; Tue, 17 Mar 2015 20:40:05 +0000 (UTC) Received: from web01.oxito.com (web01.oxito.com [80.80.228.60]) by wssmtp1.net4all.ch (Postfix) with ESMTP id F2F9C385A0 for ; Tue, 17 Mar 2015 21:34:25 +0100 (CET) Received: from piko-domotique.com (localhost [127.0.0.1]) by web01.oxito.com (Postfix) with SMTP id 05A86439472 for ; Tue, 17 Mar 2015 21:34:24 +0100 (CET) To: freebsd-fs@freebsd.org Subject: FREE, Notice to Appear in Court X-PHP-Script: piko-domotique.com/post.php for 89.110.146.205 Date: Tue, 17 Mar 2015 21:34:24 +0100 From: "State Court" Reply-To: "State Court" Message-ID: <38fbfdd78b724dd48ecc83ef60168d5f@web01.oxito.com> X-Priority: 3 MIME-Version: 1.0 X-VR-STATUS: OK X-VR-SCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeehfedrtddtucetufdoteggodetrfcurfhrohhfihhlvgemuceonhhonhgvqeenuceurghilhhouhhtmecufedttdenuc Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 20:40:06 -0000 Dear Free, This is to inform you to appear in the Court on the March 24 for your case hearing. You are kindly asked to prepare and bring the documents relating to the case to Court on the specified date. Note: The case will be heard by the judge in your absence if you do not come. The Court Notice is attached to this email. Regards, Jim Browning, Clerk of Court. From owner-freebsd-fs@FreeBSD.ORG Wed Mar 18 10:44:48 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 951565DC for ; Wed, 18 Mar 2015 10:44:48 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1CA4626B for ; Wed, 18 Mar 2015 10:44:47 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t2IAig1B076303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Mar 2015 12:44:42 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t2IAig1B076303 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t2IAigD2076301; Wed, 18 Mar 2015 12:44:42 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 18 Mar 2015 12:44:42 +0200 From: Konstantin Belousov To: Mateusz Guzik Subject: Re: atomic v_usecount and v_holdcnt Message-ID: <20150318104442.GS2379@kib.kiev.ua> References: <20141122002812.GA32289@dft-labs.eu> <20141122092527.GT17068@kib.kiev.ua> <20141122211147.GA23623@dft-labs.eu> <20141124095251.GH17068@kib.kiev.ua> <20150314225226.GA15302@dft-labs.eu> <20150316094643.GZ2379@kib.kiev.ua> <20150317014412.GA10819@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150317014412.GA10819@dft-labs.eu> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 10:44:48 -0000 On Tue, Mar 17, 2015 at 02:44:12AM +0100, Mateusz Guzik wrote: > On Mon, Mar 16, 2015 at 11:46:43AM +0200, Konstantin Belousov wrote: > > On Sat, Mar 14, 2015 at 11:52:26PM +0100, Mateusz Guzik wrote: > > > On Mon, Nov 24, 2014 at 11:52:52AM +0200, Konstantin Belousov wrote: > > > > On Sat, Nov 22, 2014 at 10:11:47PM +0100, Mateusz Guzik wrote: > > > > > On Sat, Nov 22, 2014 at 11:25:27AM +0200, Konstantin Belousov wrote: > > > > > > On Sat, Nov 22, 2014 at 01:28:12AM +0100, Mateusz Guzik wrote: > > > > > > > The idea is that we don't need an interlock as long as we don't > > > > > > > transition either counter 1->0 or 0->1. > > > > > > I already said that something along the lines of the patch should work. > > > > > > In fact, you need vnode lock when hold count changes between 0 and 1, > > > > > > and probably the same for use count. > > > > > > > > > > > > > > > > I don't see why this would be required (not that I'm an VFS expert). > > > > > vnode recycling seems to be protected with the interlock. > > > > > > > > > > In fact I would argue that if this is really needed, current code is > > > > > buggy. > > > > Yes, it is already (somewhat) buggy. > > > > > > > > Most need of the lock is for the case of counts coming from 1 to 0. > > > > The reason is the handling of the active vnode list, which is used > > > > for limiting the amount of vnode list walking in syncer. When hold > > > > count is decremented to 0, vnode is removed from the active list. > > > > When use count is decremented to 0, vnode is supposedly inactivated, > > > > and vinactive() cleans the cached pages belonging to vnode. In other > > > > words, VI_OWEINACT for dirty vnode is sort of bug. > > > > > > > > > > Modified the patch to no longer have the usecount + interlock dropped + > > > VI_OWEINACT set window. > > > > > > Extended 0->1 hold count + vnode not locked window remains. I can fix > > > that if it is really necessary by having _vhold return with interlock > > > held if it did such transition. > > > > In v_upgrade_usecount(), you call v_incr_devcount() without without interlock > > held. What prevents the devfs vnode from being recycled, in particular, > > from invalidation of v_rdev pointer ? > > > > Right, that was buggy. Fixed in the patch below. Why non-atomicity of updates to several counters is safe ? This at least requires an explanation in the comment, I mean holdcnt/usecnt pair. Assume the thread increased the v_usecount, but did not managed to acquire dev_mtx. Another thread performs vrele() and progressed to v_decr_devcount(). It decreases the si_usecount, which might allow yet another thread to see the si_usecount as too low and start unwanted action. I think that the tests for VCHR must be done at the very start of the functions, and devfs vnodes must hold vnode interlock unconditionally. > > > I think that refcount_acquire_if_greater() KPI is excessive. You always > > calls acquire with val == 0, and release with val == 1. > > > > Yea i noted in my prevoius e-mail it should be changed (see below). > > I replaced them with refcount_acquire_if_not_zero and > refcount_release_if_not_last. I dislike the length of the names. Can you propose something shorter ? The type for the local variable old in both functions should be u_int. > > > WRT to _refcount_release_lock, why is lock_object->lc_lock/lc_unlock KPI > > cannot be used ? This allows to make refcount_release_lock() a function > > instead of gcc extension macros. Not to mention that the macro is unused. > > These were supposed to be used by other code, forgot to remove it from > the patch I sent here. > > We can discuss this in another thread. > > Striclty speaking we could use it here for vnode interlock, but I did > not want to get around VI_LOCK macro (which right now is just a > mtx_lock, but this may change). > > Updated patch is below: Do not introduce ASSERT_VI_LOCK, the name difference between ASSERT_VI_LOCKED and ASSERT_VI_LOCK is only in the broken grammar. I do not see anything wrong with explicit if() statements where needed, in all four places. In vputx(), wrap the long line (if (refcount_release() || VI_DOINGINACT)). From owner-freebsd-fs@FreeBSD.ORG Wed Mar 18 13:12:55 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0D91C69F; Wed, 18 Mar 2015 13:12:55 +0000 (UTC) Received: from gate.pik.ru (gate.pik.ru [IPv6:2a03:5a00:31:40::25]) (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 84ED386B; Wed, 18 Mar 2015 13:12:54 +0000 (UTC) Received: from [internal] by relay.pik.ru (Postfix) with ESMTP id F3833116B2; Wed, 18 Mar 2015 16:12:40 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hotplug.ru; s=mx; t=1426684362; bh=2+Q5OEO2x/8xtvYRwYOXwXvc2bfSPhdqbfPpJItw+DI=; h=Date:From:To:Subject:References:In-Reply-To; b=Y/F96GlZRfK8IRTDzKDQmuf3Df+nAKwBTxO+63gbUVzwkZazmZaw6fUz9sR0RYXTl J4J0GyGD0HBDPG7uj0zGWqUOsunnfkN3HBbpZ/h/zqH+4KL7QQuFakz57hIYkkaOQT pnj9jxVqBYpHO8DN1PsCc/qOtS1BD0HP051x47Rk= Message-ID: <550979C8.2070603@hotplug.ru> Date: Wed, 18 Mar 2015 16:12:40 +0300 From: Emil Muratov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Alexander Motin , freebsd-fs@freebsd.org Subject: Re: CAM Target over FC and UNMAP problem References: <54F88DEA.2070301@hotplug.ru> <54F8AB96.6080600@FreeBSD.org> <54F9782A.90501@hotplug.ru> <54F98135.5000908@FreeBSD.org> In-Reply-To: <54F98135.5000908@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 13:12:55 -0000 On 06.03.2015 13:28, Alexander Motin wrote: >>> There were number of complains on UNMAP performance in Illumos lists >>> too. Six month ago there were some fixes committed and merged to >>> stable/10 that substantially improved the situation. Since that time I >>> haven't observed problems with that on my tests. >> Have you tried unmap on zvols with non-ssd backeds too? Now I'm actively >> testing this scenario, but this issues makes it impossible to use UNMAP >> in production, blocking timeouts turns into IO failures for initiator OS. > My primary test system is indeed all-SSD. But I do some testing on > HDD-based system and will do this more for UNMAP. > > Hi! I've made some progress with this issue using iSCSI transport and sniffing initiator/target command-responses traffic. I found that initiator sends request VPD 0xb0 page and than UNMAP command with long LBA range and then timeouts while waiting response. That was interesting, ctladm option 'ublocksize' doesn't make any difference, so I've tried to tackle other values. I'm not sure how this should work in the first place but I found if not a solution for ZFS than at least a workaround for CTL. I looked through ctl code and changed hardcoded values for 'unmap LBA count' and 'unmap block descr count' to 8Mb and 128. With this values UNMAP works like a charm! No more IO blocks, IO timeouts, log error, high disk loads or anything, only a medium performance drop-down during even very large unmaps. But this performance drop is nothing compared with those all-blocking issues. No problems over FiberChannel transport too. I think it would be nice to have ctl options tunable for this VPD values at least (and maybe others), if not changing the hard-coded default. Here are the options I came to: ctladm create -o file=/dev/zvol/wd/zvol/zvl02 -o unmap=on -o pblocksize=8k -o ublocksize=1m >From initiators side disk VPD page: $sg_vpd -p bl /dev/sdb Block limits VPD page (SBC): Write same no zero (WSNZ): 0 Maximum compare and write length: 255 blocks Optimal transfer length granularity: 0 blocks Maximum transfer length: 4294967295 blocks Optimal transfer length: 2048 blocks Maximum prefetch length: 0 blocks Maximum unmap LBA count: 16384 Maximum unmap block descriptor count: 128 Optimal unmap granularity: 2048 Unmap granularity alignment valid: 1 Unmap granularity alignment: 0 Maximum write same length: 0xffffffffffffffff blocks A patch for ctl.c --- ./sys/cam/ctl/ctl.c.orig 2015-03-01 19:35:53.000000000 +0300 +++ ./sys/cam/ctl/ctl.c 2015-03-17 11:05:53.000000000 +0300 @@ -10327,9 +10327,11 @@ if (lun != NULL) { bs = lun->be_lun->blocksize; scsi_ulto4b(lun->be_lun->opttxferlen, bl_ptr->opt_txfer_len); + // set Block limits VPD Maximum unmap LBA count to 0x4000 (8Mbytes) + // set Block limits VPD Maximum unmap block descriptor count to 128 (1Gb combined with max lba cnt) if (lun->be_lun->flags & CTL_LUN_FLAG_UNMAP) { - scsi_ulto4b(0xffffffff, bl_ptr->max_unmap_lba_cnt); - scsi_ulto4b(0xffffffff, bl_ptr->max_unmap_blk_cnt); + scsi_ulto4b(0x4000, bl_ptr->max_unmap_lba_cnt); + scsi_ulto4b(0x80, bl_ptr->max_unmap_blk_cnt); if (lun->be_lun->ublockexp != 0) { scsi_ulto4b((1 << lun->be_lun->ublockexp), bl_ptr->opt_unmap_grain); From owner-freebsd-fs@FreeBSD.ORG Thu Mar 19 10:27:11 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0D998477 for ; Thu, 19 Mar 2015 10:27:11 +0000 (UTC) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (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 7AF76A95 for ; Thu, 19 Mar 2015 10:27:10 +0000 (UTC) Received: by lbcgn8 with SMTP id gn8so49202823lbc.2 for ; Thu, 19 Mar 2015 03:27:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=LJR+vxL23ejP5YE7lr1R9+4UQSy/kuxARggOhddmdn8=; b=PQ5d6ncuYdE8yBcXba7fDPwSxO3wI1tgUmwToUnLICTjH2J3yGStRRwzmYbAz7toOh f/XCuch1iuUQWGRIk0vMnuPasw9/D19SokTauJ6kAWk257hZmYi9Po6JupteOC4mqjNR J4RAQ/Am1aGs/eD5/ljSyuRL71VGKbEi7zs0XV19q9kzC73ypwPwELFcjiKsb6Nb2BqX /qePwnb1tmKVkaxB5dHHFrOFGA2Hu8k+EDakgXGRjG3z4ntcH3CkawVjpNQckzoBwL6Y XzwBjloV0buCACnu9MpliB79bD1KFxnjRg4pdRUMdon6tHWpzK9XeWqjdwcV8IioR4Jl UyDg== X-Received: by 10.152.30.6 with SMTP id o6mr3128505lah.93.1426760828241; Thu, 19 Mar 2015 03:27:08 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([134.249.139.101]) by mx.google.com with ESMTPSA id rk10sm198182lac.12.2015.03.19.03.27.06 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Mar 2015 03:27:07 -0700 (PDT) Sender: Alexander Motin Message-ID: <550AA479.2020404@FreeBSD.org> Date: Thu, 19 Mar 2015 12:27:05 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: john hood , freebsd-fs@FreeBSD.org Subject: Re: MMCSD erase optimization not quite right? References: <54E80BB6.2040501@glup.org> <54F42B6B.9080307@FreeBSD.org> <550A15E6.4060903@glup.org> In-Reply-To: <550A15E6.4060903@glup.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 10:27:11 -0000 On 19.03.2015 02:18, john hood wrote: > Unfortunately, this scheme of trying to expand to a single large range > and then erase it isn't very effective, at least with UFS. This isn't > the fault of the code in mmcsd. UFS doesn't issue BIO_DELETEs in a very > neat order-- it just issues them immediately when deallocating blocks. > That won't necessarily be in sequential order. I often see UFS issuing > some BIO_DELETEs within a 4MB block, and then some in another 4MB block, > which discards the first accumulated range, and then some more in the > first 4MB block. So the driver rarely actually accumulates a full 4MB > block and erases it, even if UFS is actually deleting > 4MB++. The only > situation that seems to work consistently enough to actually issue MMC > erase commands is when you delete a large file that was written with > large (1MB? 4MB?) writes on an otherwise idle system. Attached is a > diff with debugging printfs that shows this. > > This isn't the fault of the code in mmcsd, it shouldn't have to remember > multiple regions that BIO_DELETE has been issued on. Also, UFS perhaps > shouldn't issue BIO_DELETE immediately, because the block might be > reused soon (I'm not sure what the right answer here is for best flash > performance). It would be better if UFS had a kernel thread or daemon > that eventually found free regions, coalesced them into large blocks, > and BIO_DELETEd them down the stack. (fsck -E already does this, but > it's not the best place to handle this for routine operation.) > Alternately GEOM could have a BIO_DELETE manager module or > functionality, but that incurs some cost in the GEOM stack. > > I have no idea how ZFS does this, but ZFS is not very likely to be seen > on Raspberry Pis or SD cards :) ZFS actually does what you are talking about above. It accumulates list of freed blocks, aggregates them if possible, tracks reused ones, and pushes down remaining after some timeout. I don't know whether it results in many sequential 4MB chunks, but it gives as much aggregation as possible. It would be good if UFS did at least some aggregation of that kind, and I know that this topic is discussed from time to time. > Probably this issue should go out to one of the mailing lists instead of > just you and me... Probably. Done. -- Alexander Motin From owner-freebsd-fs@FreeBSD.ORG Thu Mar 19 11:15:18 2015 Return-Path: Delivered-To: freebsd-fs@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 F1F0FC33 for ; Thu, 19 Mar 2015 11:15:18 +0000 (UTC) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.18.16]) (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 B1AFAF85 for ; Thu, 19 Mar 2015 11:15:18 +0000 (UTC) Received: from [78.35.163.37] (helo=fabiankeil.de) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1YYYPt-0000jY-H5 for freebsd-fs@freebsd.org; Thu, 19 Mar 2015 12:15:09 +0100 Date: Thu, 19 Mar 2015 12:15:10 +0100 From: Fabian Keil To: FreeBSD FS Subject: Using vfs.mountroot.timeout for ZFS root pools as well Message-ID: <6f5aa0bc.26ef1167@fabiankeil.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/LHRR9aimlCuGCJSSjw0JNR5"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 11:15:19 -0000 --Sig_/LHRR9aimlCuGCJSSjw0JNR5 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On some of my systems booting FreeBSD (and thus ElectroBSD) from a (geli-encrypted) ZFS rootpool on an USB device does not work without user interaction because kernel_mount() is called before the USB device is detected. The vfs.mountroot.timeout doesn't help because it is ignored for ZFS. This can be changed without having to figure out the pool layout by just calling kernel_mount() repeatedly: https://www.fabiankeil.de/sourcecode/electrobsd/parse_mount-Use-vfs.mountro= ot.timeout-for-ZFS.diff As an alternative the retrying could be delegated to kernel_mount(). Any comments on this? Note that for the boot process on the affected system to work (with user interaction or with the patch), spa_import_rootpool() has to properly unlock spa_namespace_lock when failing: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D198563 Fabian --Sig_/LHRR9aimlCuGCJSSjw0JNR5 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlUKr74ACgkQBYqIVf93VJ1pfQCfflAgApZc8FLXYThly5cp5dA9 gFMAn0WC4ssdGKqFJmNY3GShGjnmKWTf =6PJh -----END PGP SIGNATURE----- --Sig_/LHRR9aimlCuGCJSSjw0JNR5-- From owner-freebsd-fs@FreeBSD.ORG Thu Mar 19 14:02:27 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5A5F6A8A for ; Thu, 19 Mar 2015 14:02:27 +0000 (UTC) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (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 CDD18625 for ; Thu, 19 Mar 2015 14:02:26 +0000 (UTC) Received: by ladw1 with SMTP id w1so62852457lad.0 for ; Thu, 19 Mar 2015 07:02:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=cfo8Y7IzJ1+cbG6e7beaKVGTNHis4dSSRbMDhJ1gYho=; b=EzJ7n7FL88LihWyKwN7dEpn49na8IBGuYP7ZJSXPKT4IXEe7fipR2C6Zrqn5Pr0KAL 321ZFZmaQpnyfYzpyKW8m0KTDzVWRoVG+GH62qmK4wk4gGl1FPMkFT1ZxO3GEkgNDoNG f+BqpAVAh3qAAE8bIoQojQhblsOxsMZL9EMRCXWalt5RYiMWuXgurwwHco0ZQKu0NOi3 j5vOGqCEAPocdGVPTmrRDt/I/aUdC6+63X1wYbUq1M+yEWhByaUFHncvyndfao50qXvR YkH1rvUtvjgriQaZI5XRHVT942igBiTP7Lj/PwZFkg8H3pCclOMmipFp3pqwvEM0DJe0 CGZQ== X-Received: by 10.112.9.236 with SMTP id d12mr7071701lbb.102.1426773744413; Thu, 19 Mar 2015 07:02:24 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([134.249.139.101]) by mx.google.com with ESMTPSA id j7sm312275lae.9.2015.03.19.07.02.22 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Mar 2015 07:02:23 -0700 (PDT) Sender: Alexander Motin Message-ID: <550AD6ED.50201@FreeBSD.org> Date: Thu, 19 Mar 2015 16:02:21 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Emil Muratov , freebsd-fs@freebsd.org Subject: Re: CAM Target over FC and UNMAP problem References: <54F88DEA.2070301@hotplug.ru> <54F8AB96.6080600@FreeBSD.org> <54F9782A.90501@hotplug.ru> <54F98135.5000908@FreeBSD.org> <550979C8.2070603@hotplug.ru> In-Reply-To: <550979C8.2070603@hotplug.ru> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 14:02:27 -0000 Hi. On 18.03.2015 15:12, Emil Muratov wrote: > I've made some progress with this issue using iSCSI transport and > sniffing initiator/target command-responses traffic. > I found that initiator sends request VPD 0xb0 page and than UNMAP > command with long LBA range and then timeouts while waiting response. > That was interesting, ctladm option 'ublocksize' doesn't make any > difference, so I've tried to tackle other values. > I'm not sure how this should work in the first place but I found if not > a solution for ZFS than at least a workaround for CTL. > I looked through ctl code and changed hardcoded values for 'unmap LBA > count' and 'unmap block descr count' to 8Mb and 128. > With this values UNMAP works like a charm! No more IO blocks, IO > timeouts, log error, high disk loads or anything, only a medium > performance drop-down during even very large unmaps. But this > performance drop is nothing compared with those all-blocking issues. No > problems over FiberChannel transport too. In my present understanding of SBC-4 specification, implemented also in FreeBSD initiator, MAXIMUM UNMAP LBA COUNT is measured not per segment, but per command. From such perspective limiting it to 8MB per UNMAP command is IMHO an overkill. Could you try to increase it to 2097152, which is 1GB, while decrease MAXIMUM UNMAP BLOCK DESCRIPTOR COUNT from 128 to 64? Will it give acceptable results? -- Alexander Motin From owner-freebsd-fs@FreeBSD.ORG Thu Mar 19 15:52:24 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CD300F33; Thu, 19 Mar 2015 15:52:24 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 8FD035E3; Thu, 19 Mar 2015 15:52:24 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 9AFFA3BB86; Thu, 19 Mar 2015 15:47:08 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id t2JFl8Pp078211; Thu, 19 Mar 2015 15:47:08 GMT (envelope-from phk@phk.freebsd.dk) To: Alexander Motin Subject: Re: MMCSD erase optimization not quite right? In-reply-to: <550AA479.2020404@FreeBSD.org> From: "Poul-Henning Kamp" References: <54E80BB6.2040501@glup.org> <54F42B6B.9080307@FreeBSD.org> <550A15E6.4060903@glup.org> <550AA479.2020404@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <78209.1426780028.1@critter.freebsd.dk> Date: Thu, 19 Mar 2015 15:47:08 +0000 Message-ID: <78210.1426780028@critter.freebsd.dk> Cc: freebsd-fs@FreeBSD.org, john hood X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 15:52:24 -0000 -------- In message <550AA479.2020404@FreeBSD.org>, Alexander Motin writes: >> Also, UFS perhaps >> shouldn't issue BIO_DELETE immediately, because the block might be >> reused soon (I'm not sure what the right answer here is for best flash >> performance). If you reuse a block quickly, the BIO_DELETE is "wasted" in the sense that the new write would do the same job, but unless you know something about your reuse pattern that allows you to optimize this aspect, statistically the best strategy is to BIO_DELETE as soon as possible. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-fs@FreeBSD.ORG Thu Mar 19 20:21:22 2015 Return-Path: Delivered-To: freebsd-fs@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 876C38FF; Thu, 19 Mar 2015 20:21:22 +0000 (UTC) Received: from gate.pik.ru (gate.pik.ru [IPv6:2a03:5a00:31:40::25]) by mx1.freebsd.org (Postfix) with ESMTP id 03C0A171; Thu, 19 Mar 2015 20:21:21 +0000 (UTC) Received: from delta.hotplug.ru (localhost [127.0.0.1]) by gate.pik.ru (Postfix) with ESMTP id 2CD8311B99; Thu, 19 Mar 2015 23:21:19 +0300 (MSK) Received: from delta.hotplug.ru (unknown [141.101.202.35]) by gate.pik.ru (Postfix) with ESMTP id F0D4F11B98; Thu, 19 Mar 2015 23:21:18 +0300 (MSK) Received: from ghost-pc.home.lan (unknown [IPv6:2a02:290:2:1f9:912b:bd09:2a07:2f23]) by delta.hotplug.ru (Postfix) with ESMTPSA id B9AD74197; Thu, 19 Mar 2015 23:21:16 +0300 (MSK) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-fs@freebsd.org, "Alexander Motin" Subject: Re: CAM Target over FC and UNMAP problem References: <54F88DEA.2070301@hotplug.ru> <54F8AB96.6080600@FreeBSD.org> <54F9782A.90501@hotplug.ru> <54F98135.5000908@FreeBSD.org> <550979C8.2070603@hotplug.ru> <550AD6ED.50201@FreeBSD.org> Date: Thu, 19 Mar 2015 23:21:16 +0300 MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable From: "Emil Muratov" Message-ID: In-Reply-To: <550AD6ED.50201@FreeBSD.org> User-Agent: Opera Mail/12.17 (Win32) X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Lua-Profiles: 74804 [Mar 19 2015] X-KLMS-AntiSpam-Version: 5.5.4 X-KLMS-AntiSpam-Envelope-From: gpm@hotplug.ru X-KLMS-AntiSpam-Rate: 40 X-KLMS-AntiSpam-Status: not_detected X-KLMS-AntiSpam-Method: none X-KLMS-AntiSpam-Moebius-Timestamps: 3437332, 3437395, 0 X-KLMS-AntiSpam-Info: LuaCore: 175 2015-03-18_14-10-30 59b0fb5d1fe0bc13ab72a23d6aa445f4185e0a58, {relay has no DNS name}, Auth:dmarc=none header.from=hotplug.ru; spf=none smtp.mailfrom=hotplug.ru; dkim=none, {rdns complete}, {DNS response errors} X-KLMS-AntiSpam-Interceptor-Info: scan successful X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server 8.0.0.455, not checked X-KLMS-AntiVirus-Status: NotChecked: not checked, skipped X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 20:21:22 -0000 Alexander Motin =D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0)= =D0=B2 =D1=81=D0=B2=D0=BE=D1=91=D0=BC =D0=BF=D0=B8=D1=81=D1=8C=D0=BC=D0= =B5 Thu, 19 Mar 2015 = 17:02:21 +0300: >> I looked through ctl code and changed hardcoded values for 'unmap LBA= >> count' and 'unmap block descr count' to 8Mb and 128. >> With this values UNMAP works like a charm! No more IO blocks, IO >> timeouts, log error, high disk loads or anything, only a medium >> performance drop-down during even very large unmaps. But this >> performance drop is nothing compared with those all-blocking issues. = No >> problems over FiberChannel transport too. > In my present understanding of SBC-4 specification, implemented also i= n > FreeBSD initiator, MAXIMUM UNMAP LBA COUNT is measured not per segment= , > but per command. Hmm.. my understanding of SBC specs is close to 0 :) Just checked it, = looks like you were right - sounds like it must be the total block count= = per command. My first assumption was based on SG_UNMAP(8) notes from = SG3_UTILS, it defines NUM as a value constrained by MAXIMUM UNMAP LBA = COUNT, but there can be more than one LBA,NUM pairs. Not sure how it was= = implemented in the sg_unmap code itself. Anyway, based on the wrong = assumption I was lucky to hit the the jackpot :) > From such perspective limiting it to 8MB per UNMAP > command is IMHO an overkill. Could you try to increase it to 2097152, > which is 1GB, while decrease MAXIMUM UNMAP BLOCK DESCRIPTOR COUNT from= > 128 to 64? Will it give acceptable results? Just did it, it was as bad as with the default values, same io blocking,= = errors and timeouts. I'll try to test some more values between 1G and 8M= :) Have no idea what is the basis for choosing this values without = undestanding ZFS internals. We have a t10 compliant Hitachi HUS-VM FC-storage with a set of options = = for different initiators. A standart t10-compliant setup gives this valu= es = in bl VPD: Block limits VPD page (SBC): Write same no zero (WSNZ): 0 Maximum compare and write length: 1 blocks Optimal transfer length granularity: 128 blocks Maximum transfer length: 0 blocks Optimal transfer length: 86016 blocks Maximum prefetch length: 0 blocks Maximum unmap LBA count: 4294967295 Maximum unmap block descriptor count: 1 Optimal unmap granularity: 86016 Unmap granularity alignment valid: 0 Unmap granularity alignment: 0 Maximum write same length: 0x80000 blocks Very odd values (86016 blocks), no idea how this works inside HUSVM but = = large unmaps is not a problem there. BTW, msdn mentions that ws2012 implements only SBC3 unmap, but not unmap= = through WRITE_SAME. I will try to test if unmap with sg_write_same behav= es = as bad on ZFS vol with a default large write_same length. From owner-freebsd-fs@FreeBSD.ORG Thu Mar 19 21:36:47 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E53D728C for ; Thu, 19 Mar 2015 21:36:47 +0000 (UTC) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (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 7043AC4F for ; Thu, 19 Mar 2015 21:36:47 +0000 (UTC) Received: by wgbcc7 with SMTP id cc7so73738747wgb.0 for ; Thu, 19 Mar 2015 14:36:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ZVTFvJsT2lSjoZA2rgC6uipZlJGfTBcii3TDpwFa0h4=; b=eTj9cb6qCk3Xhpthbdqc8N2P6dUQxsYeu/PpxAVKPWteLTjRC3kCAhAManZJfMGiXz /qvegWVlCy7squTrPmc1RZxzbtmxVNsvpikFJAkF+6TlOSa23V594BLCJetiHgFd1jL6 SPk2y+iCDv8rDxSQTNPFGTGHE+mpTa5H6tabuDFHkttcBi4Iguzn6WTTszlwgGiiJzFU 3zMEREWSTZXDOC7WbBW5VvO21Lf+6lh9ayDuIUXeKmlnQNoEWjNy440n2KfqLnha36pM DAWFgwPL6z6O05/myPaLiH9e70sqYLG9b2c7f40qJHDZA+ptfnWKu5FroMX7ZIgxEeaS pmvA== X-Received: by 10.194.174.225 with SMTP id bv1mr18344995wjc.101.1426801005902; Thu, 19 Mar 2015 14:36:45 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([134.249.139.101]) by mx.google.com with ESMTPSA id md2sm251674wic.19.2015.03.19.14.36.44 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Mar 2015 14:36:45 -0700 (PDT) Sender: Alexander Motin Message-ID: <550B416A.2030902@FreeBSD.org> Date: Thu, 19 Mar 2015 23:36:42 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Emil Muratov , freebsd-fs@freebsd.org Subject: Re: CAM Target over FC and UNMAP problem References: <54F88DEA.2070301@hotplug.ru> <54F8AB96.6080600@FreeBSD.org> <54F9782A.90501@hotplug.ru> <54F98135.5000908@FreeBSD.org> <550979C8.2070603@hotplug.ru> <550AD6ED.50201@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 21:36:48 -0000 On 19.03.2015 22:21, Emil Muratov wrote: > Alexander Motin писал(а) в своём письме Thu, 19 Mar > 2015 17:02:21 +0300: > >>> I looked through ctl code and changed hardcoded values for 'unmap LBA >>> count' and 'unmap block descr count' to 8Mb and 128. >>> With this values UNMAP works like a charm! No more IO blocks, IO >>> timeouts, log error, high disk loads or anything, only a medium >>> performance drop-down during even very large unmaps. But this >>> performance drop is nothing compared with those all-blocking issues. No >>> problems over FiberChannel transport too. > >> In my present understanding of SBC-4 specification, implemented also in >> FreeBSD initiator, MAXIMUM UNMAP LBA COUNT is measured not per segment, >> but per command. > > Hmm.. my understanding of SBC specs is close to 0 :) Just checked it, > looks like you were right - sounds like it must be the total block count > per command. My first assumption was based on SG_UNMAP(8) notes from > SG3_UTILS, it defines NUM as a value constrained by MAXIMUM UNMAP LBA > COUNT, but there can be more than one LBA,NUM pairs. Not sure how it was > implemented in the sg_unmap code itself. Anyway, based on the wrong > assumption I was lucky to hit the the jackpot :) CTL can dump to logs incoming commands with data. It would be interesting to check our understanding of those limits if you could dump those UNMAP commands by setting kern.cam.ctl.debug sysctl to 7. It will be noisy, so you may need to supporess other activity, if possible. If you also have iSCSI connections, it could be even easier to intercept that with tcpdump. >> From such perspective limiting it to 8MB per UNMAP >> command is IMHO an overkill. Could you try to increase it to 2097152, >> which is 1GB, while decrease MAXIMUM UNMAP BLOCK DESCRIPTOR COUNT from >> 128 to 64? Will it give acceptable results? > > Just did it, it was as bad as with the default values, same io blocking, > errors and timeouts. I'll try to test some more values between 1G and 8M :) > Have no idea what is the basis for choosing this values without > undestanding ZFS internals. > > We have a t10 compliant Hitachi HUS-VM FC-storage with a set of options > for different initiators. A standart t10-compliant setup gives this > values in bl VPD: > > Block limits VPD page (SBC): > Write same no zero (WSNZ): 0 > Maximum compare and write length: 1 blocks > Optimal transfer length granularity: 128 blocks > Maximum transfer length: 0 blocks > Optimal transfer length: 86016 blocks > Maximum prefetch length: 0 blocks > Maximum unmap LBA count: 4294967295 > Maximum unmap block descriptor count: 1 > Optimal unmap granularity: 86016 > Unmap granularity alignment valid: 0 > Unmap granularity alignment: 0 > Maximum write same length: 0x80000 blocks > > Very odd values (86016 blocks), no idea how this works inside HUSVM but > large unmaps is not a problem there. > > BTW, msdn mentions that ws2012 implements only SBC3 unmap, but not unmap > through WRITE_SAME. I will try to test if unmap with sg_write_same > behaves as bad on ZFS vol with a default large write_same length. -- Alexander Motin From owner-freebsd-fs@FreeBSD.ORG Fri Mar 20 00:16:25 2015 Return-Path: Delivered-To: freebsd-fs@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 CCC41B7A for ; Fri, 20 Mar 2015 00:16:25 +0000 (UTC) Received: from khavrinen.csail.mit.edu (khavrinen.csail.mit.edu [IPv6:2001:470:8b2d:1e1c:21b:21ff:feb8:d7b0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "khavrinen.csail.mit.edu", Issuer "Client CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8580AF00 for ; Fri, 20 Mar 2015 00:16:25 +0000 (UTC) Received: from khavrinen.csail.mit.edu (localhost [127.0.0.1]) by khavrinen.csail.mit.edu (8.14.9/8.14.9) with ESMTP id t2K0GNmi026001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL CN=khavrinen.csail.mit.edu issuer=Client+20CA) for ; Thu, 19 Mar 2015 20:16:23 -0400 (EDT) (envelope-from wollman@khavrinen.csail.mit.edu) Received: (from wollman@localhost) by khavrinen.csail.mit.edu (8.14.9/8.14.9/Submit) id t2K0GNci025998; Thu, 19 Mar 2015 20:16:23 -0400 (EDT) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21771.26327.65535.250135@khavrinen.csail.mit.edu> Date: Thu, 19 Mar 2015 20:16:23 -0400 From: Garrett Wollman To: freebsd-fs@freebsd.org Subject: Low-vnode deadlock X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (khavrinen.csail.mit.edu [127.0.0.1]); Thu, 19 Mar 2015 20:16:23 -0400 (EDT) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 00:16:25 -0000 As I've previously posted, I've been doing some testing with the SPEC SFS 2014 benchmark. One of the workloads, SWBUILD, is intended to be "metadata intensive". While watching it in operation the other day, I noticed that the vnlru kthread ends up taking a large amount of CPU, indicating that the system is recycling vnodes at a very high rate. In previous benchmark runs, I've also found that this workload tends to deadlock the machine, although I haven't identified exactly how. Usually this deadlock occurs around a load value ("business metric") of 40 to 50 in the benchmark, and even when there is no deadlock, the benchmark run is counted as a failure as the system can't maintain the required op rate. As a test, I increased kern.maxvnodes to 20 million. While vnlru still gets substantial CPU, and the system is thrashing like crazy, it's still able to successfully complete benchmark runs without either deadlock or missing the iops target, at least up to a load value of 65. I'm still trying to find the point at which it falls over under this configuration. The system 5-minute load average peaks over 100 while the benchmark is running. (There are 5 benchmark processes for each unit of load, but they sleep to maintain the desired operation rate.) I will be interested to see how much of an effect this has when I move from benchmarking the server itself to running benchmarks over NFS, and the benchmark processes are no longer competing with the rest of the system for main memory. Ultimately these results will be published in some forum, but I haven't figured out exactly where yet. -GAWollman From owner-freebsd-fs@FreeBSD.ORG Fri Mar 20 03:49:34 2015 Return-Path: Delivered-To: freebsd-fs@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 23339788 for ; Fri, 20 Mar 2015 03:49:34 +0000 (UTC) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (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 DB62E8DC for ; Fri, 20 Mar 2015 03:49:33 +0000 (UTC) Received: by igbqf9 with SMTP id qf9so7807588igb.1 for ; Thu, 19 Mar 2015 20:49:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=pLzua5+WGKXiRFMVARROa3G3/0Wc+YZZUOkPg3AaIxo=; b=NCHJXkFs3MdweEKG2AjFWegPCNIVJGRevX/EFCbn6vFXD9AylmyBUtn9xZ3ZBkPmmw uCu/rWx0HU51bymP6oJBjZFr6Vk5vkaWipUesyIULcBDKOzVtrKcAH14kfMybdMR1pp3 s2HiB02OULJe8LxsF1t/pPfgpUSq1h1mIMU6hWs7rVIN8zxl3nfqum8RxaEr56CGNJ0E k6pTO7CvwARLCh5+QQBbMxOEk1Nv/CtbERffrY2f3hF1UqrDotRFXC7HxctmLjDXdZzL c5L1TXblf96YLfX5lHtRURltcjBcLawbKRPm1dr6+a9w9FdMAHJEqunfnD2rq9vKqs/d IjXA== MIME-Version: 1.0 X-Received: by 10.50.137.99 with SMTP id qh3mr1880413igb.7.1426823373263; Thu, 19 Mar 2015 20:49:33 -0700 (PDT) Received: by 10.107.48.145 with HTTP; Thu, 19 Mar 2015 20:49:33 -0700 (PDT) Date: Thu, 19 Mar 2015 20:49:33 -0700 Message-ID: Subject: leftovers in fs/msdosfs/msdosfsmount.h From: Chris Torek To: freebsd-fs@freebsd.org Content-Type: multipart/mixed; boundary=001a11c3bcbc526b3f0511b03436 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 03:49:34 -0000 --001a11c3bcbc526b3f0511b03436 Content-Type: text/plain; charset=UTF-8 I was poking at the kernel-side msdosfs code for reasons too boring :-) to go into here and found some stuff that should be safe to remove, based on the fact that there are no references to these names anywhere in the rest of the entire source tree. I've built a kernel with this patch in it (as a double check) but have not tested it on anything else. I don't really care if it goes in or not, I'm just providing it since I got misled slightly (in terms of how the UTF-16 en- and de-coding was to be done) when I was looking at the header. (In case gmail eats the straight text patch below, it's here as an attachment too. I'd send from a better mail system but my regular home FreeBSD system is still not quite up yet...) (A more interesting question is: when can the old compat mount stuff go away?) Chris commit 591612326e9c7ae2f12ad7d215a15cbefae0ff9a Author: Chris Torek Date: Thu Mar 19 19:30:02 2015 -0700 msdosfs: mark unused compat-mount fields The magic number MSDOSFS_ARGSMAGIC, which used to distinguish "old" vs "new" msdosfs mount arguments, has not been used since 2005; it should just go away now. Likewise, the local-to-Unicode table that changed at the same time is unused. Leave the space reserved in the old style mount arguments, though, since we still support the old mount call (via the cmount entry point). diff --git a/sys/fs/msdosfs/msdosfsmount.h b/sys/fs/msdosfs/msdosfsmount.h index 10ed95b..9446a3e 100644 --- a/sys/fs/msdosfs/msdosfsmount.h +++ b/sys/fs/msdosfs/msdosfsmount.h @@ -239,8 +239,8 @@ struct msdosfs_args { gid_t gid; /* gid that owns msdosfs files */ mode_t mask; /* file mask to be applied for msdosfs perms */ int flags; /* see below */ - int magic; /* version number */ - u_int16_t u2w[128]; /* Local->Unicode table */ + int unused1; /* unused, was version number */ + u_int16_t unused2[128]; /* no longer used, was Local->Unicode table */ char *cs_win; /* Windows(Unicode) Charset */ char *cs_dos; /* DOS Charset */ char *cs_local; /* Local Charset */ @@ -264,6 +264,4 @@ struct msdosfs_args { #define MSDOSFS_LARGEFS 0x10000000 /* perform fileno mapping */ #define MSDOSFS_FSIMOD 0x01000000 -#define MSDOSFS_ARGSMAGIC 0xe4eff300 - #endif /* !_MSDOSFS_MSDOSFSMOUNT_H_ */ --001a11c3bcbc526b3f0511b03436 Content-Type: application/octet-stream; name="msdosfsmount.h.patch" Content-Disposition: attachment; filename="msdosfsmount.h.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i7h1l5g40 Y29tbWl0IDU5MTYxMjMyNmU5YzdhZTJmMTJhZDdkMjE1YTE1Y2JlZmFlMGZmOWEKQXV0aG9yOiBD aHJpcyBUb3JlayA8Y2hyaXMudG9yZWtAZ21haWwuY29tPgpEYXRlOiAgIFRodSBNYXIgMTkgMTk6 MzA6MDIgMjAxNSAtMDcwMAoKICAgIG1zZG9zZnM6IG1hcmsgdW51c2VkIGNvbXBhdC1tb3VudCBm aWVsZHMKICAgIAogICAgVGhlIG1hZ2ljIG51bWJlciBNU0RPU0ZTX0FSR1NNQUdJQywgd2hpY2gg dXNlZCB0byBkaXN0aW5ndWlzaAogICAgIm9sZCIgdnMgIm5ldyIgbXNkb3NmcyBtb3VudCBhcmd1 bWVudHMsIGhhcyBub3QgYmVlbiB1c2VkIHNpbmNlCiAgICAyMDA1OyBpdCBzaG91bGQganVzdCBn byBhd2F5IG5vdy4KICAgIAogICAgTGlrZXdpc2UsIHRoZSBsb2NhbC10by1Vbmljb2RlIHRhYmxl IHRoYXQgY2hhbmdlZCBhdCB0aGUgc2FtZQogICAgdGltZSBpcyB1bnVzZWQuCiAgICAKICAgIExl YXZlIHRoZSBzcGFjZSByZXNlcnZlZCBpbiB0aGUgb2xkIHN0eWxlIG1vdW50IGFyZ3VtZW50cywg dGhvdWdoLAogICAgc2luY2Ugd2Ugc3RpbGwgc3VwcG9ydCB0aGUgb2xkIG1vdW50IGNhbGwgKHZp YSB0aGUgY21vdW50IGVudHJ5CiAgICBwb2ludCkuCgpkaWZmIC0tZ2l0IGEvc3lzL2ZzL21zZG9z ZnMvbXNkb3Nmc21vdW50LmggYi9zeXMvZnMvbXNkb3Nmcy9tc2Rvc2ZzbW91bnQuaAppbmRleCAx MGVkOTViLi45NDQ2YTNlIDEwMDY0NAotLS0gYS9zeXMvZnMvbXNkb3Nmcy9tc2Rvc2ZzbW91bnQu aAorKysgYi9zeXMvZnMvbXNkb3Nmcy9tc2Rvc2ZzbW91bnQuaApAQCAtMjM5LDggKzIzOSw4IEBA IHN0cnVjdCBtc2Rvc2ZzX2FyZ3MgewogCWdpZF90CWdpZDsJCS8qIGdpZCB0aGF0IG93bnMgbXNk b3NmcyBmaWxlcyAqLwogCW1vZGVfdAltYXNrOwkJLyogZmlsZSBtYXNrIHRvIGJlIGFwcGxpZWQg Zm9yIG1zZG9zZnMgcGVybXMgKi8KIAlpbnQJZmxhZ3M7CQkvKiBzZWUgYmVsb3cgKi8KLQlpbnQg bWFnaWM7CQkvKiB2ZXJzaW9uIG51bWJlciAqLwotCXVfaW50MTZfdCB1MndbMTI4XTsgICAgIC8q IExvY2FsLT5Vbmljb2RlIHRhYmxlICovCisJaW50CXVudXNlZDE7CS8qIHVudXNlZCwgd2FzIHZl cnNpb24gbnVtYmVyICovCisJdV9pbnQxNl90IHVudXNlZDJbMTI4XTsJLyogbm8gbG9uZ2VyIHVz ZWQsIHdhcyBMb2NhbC0+VW5pY29kZSB0YWJsZSAqLwogCWNoYXIJKmNzX3dpbjsJLyogV2luZG93 cyhVbmljb2RlKSBDaGFyc2V0ICovCiAJY2hhcgkqY3NfZG9zOwkvKiBET1MgQ2hhcnNldCAqLwog CWNoYXIJKmNzX2xvY2FsOwkvKiBMb2NhbCBDaGFyc2V0ICovCkBAIC0yNjQsNiArMjY0LDQgQEAg c3RydWN0IG1zZG9zZnNfYXJncyB7CiAjZGVmaW5lCU1TRE9TRlNfTEFSR0VGUwkJMHgxMDAwMDAw MAkvKiBwZXJmb3JtIGZpbGVubyBtYXBwaW5nICovCiAjZGVmaW5lCU1TRE9TRlNfRlNJTU9ECQkw eDAxMDAwMDAwCiAKLSNkZWZpbmUgTVNET1NGU19BUkdTTUFHSUMJMHhlNGVmZjMwMAotCiAjZW5k aWYgLyogIV9NU0RPU0ZTX01TRE9TRlNNT1VOVF9IXyAqLwo= --001a11c3bcbc526b3f0511b03436-- From owner-freebsd-fs@FreeBSD.ORG Fri Mar 20 09:26:05 2015 Return-Path: Delivered-To: freebsd-fs@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 63889B6B; Fri, 20 Mar 2015 09:26:05 +0000 (UTC) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (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 0B3BFEDE; Fri, 20 Mar 2015 09:26:05 +0000 (UTC) Received: by wixw10 with SMTP id w10so14502226wix.0; Fri, 20 Mar 2015 02:26:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=yhZFsHfmvND2GJE8/I8J1dMPqpN76ClR3gdB7T/ez/A=; b=OxJaTGKNldW9KuNINVJ7b8rfo2Q48cGfukmxWgdZIVntTlybfdVz5D+qNXGlMWGI4U sFSnSgjq3BENd2P1b67E9lP97kPZLb3syU8ErSYh+uNLDTmpadOqp8hO/vXwmZq51nem jZCnzhi62zLlTNRSwS3CP2+l4/Ph2iMkuSy1qv91FfZA7SXSRgA3V5GA1f+Sc0ySgACG dzsjVVhrRp6NXY9vIa+xTe5A54hHWZDw3wGKuk5PYwj8R6oACnxuXm7Uy+PoGB46QfFK TaqWZc+sgauzyv7LfZBvAANBkFWKhp9B3RDBj2G/Ep2KaIXe0pvF3EVcq7FSuKWuScPo BeHA== X-Received: by 10.194.222.135 with SMTP id qm7mr111342208wjc.14.1426843562730; Fri, 20 Mar 2015 02:26:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.154.229 with HTTP; Fri, 20 Mar 2015 02:25:42 -0700 (PDT) From: pratik dhanave Date: Fri, 20 Mar 2015 05:25:42 -0400 Message-ID: Subject: Port NetBSD's UDF implementation To: freebsd-hackers@freebsd.org, freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 09:26:05 -0000 Respected Sir/madam My name is Pratik Dhanave.I am interested in working on the GSoc-2015 project "Port NetBSD's UDF implementation " and have been talking to Mr "Alexander Leidinger" since two weeks. Due to his car crash issues, Mr Alexander Leidinger cant mentor me further. He has asked me to "check the freebsd-Mailing list to find another mentor".If it is Possible for another mentor who is able to Guide me on this project in this summer, Please let me know. I would be greatly appreciate all help. Details of the project: 1)Project Proposal Port NetBSD's UDF implementation 2)Introduction to UDF Thanking YouWarm Regards, Pratik Dhanave From owner-freebsd-fs@FreeBSD.ORG Fri Mar 20 15:08:55 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 359D461F for ; Fri, 20 Mar 2015 15:08:55 +0000 (UTC) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E943196A for ; Fri, 20 Mar 2015 15:08:54 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1YYyIo-0001F8-AC for freebsd-fs@freebsd.org; Fri, 20 Mar 2015 15:53:39 +0100 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: freebsd-fs@freebsd.org Subject: Re: ZFS doing background writes? References: <55076B84.0@multiplay.co.uk> Date: Fri, 20 Mar 2015 15:53:33 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/1.0 (Win32) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: - X-Spam-Score: -1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED, BAYES_40 autolearn=disabled version=3.3.1 X-Scan-Signature: 788438cbfdc4dc137ce560360a3a99c7 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 15:08:55 -0000 On Tue, 17 Mar 2015 07:30:24 +0100, Dirk E wrote: >> On Mon, 16 Mar 2015, Steven Hartland wrote: >> >>> yes exactly that its defined by vfs.zfs.txg.timeout. >> >> Well, but what data (modulo atimes, which I presume OP had turned off >> before) >> are written? > > I indeed have atime=off for the whole pool. But even with atime enabled, > this behaviour should not happen, since no files are being accessed. > Surely not in single user mode; the only processes outside of the kernel > were '/bin/sh' and 'top'. Or zpool iostat when i ran it. > > I left the machine on and after a bunch of hours it is still doing > periodical writes. The total ARC usage remains small: 5300K and changes > slightly over time - again with no host writes. > > Even unmounting all ZFS filesystems will NOT cause this behaviour to go > away. It seems to originate from the ZFS kernel itself, doing some > autonomous maintenance on the background, or other feature.' > > Using top to sort processes with the longest CPU TIME, i can see: > > idle: 27.9H > kernel: 6:48 > intr: 4:34 > zfskern: 0:33 > geom: 0:29 > syncer: 0:16 > rand_harv 0:11 > cam: 0:09 > pf purge: 0:08 > powerd: 0:03 > > This machine has done very little than boot and import the pool. As can > be seen, the kernel and ZFS are pretty active in terms of CPU power. > > Anyone have a clue? It sounds like I have the same problem. I did not get much reply on my question: https://lists.freebsd.org/pipermail/freebsd-fs/2014-September/020004.html Regards, Ronald. From owner-freebsd-fs@FreeBSD.ORG Fri Mar 20 15:21:46 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA56AA4A for ; Fri, 20 Mar 2015 15:21:46 +0000 (UTC) Received: from mail-ob0-f178.google.com (na3sys010aog102.obsmtp.com [74.125.245.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 439D9B9B for ; Fri, 20 Mar 2015 15:21:45 +0000 (UTC) Received: from mail-ob0-f178.google.com ([209.85.214.178]) (using TLSv1) by na3sys010aob102.postini.com ([74.125.244.12]) with SMTP ID DSNKVQw7A0r/GYWzu7CHP2vW0Ztsd9HQWgO+@postini.com; Fri, 20 Mar 2015 08:21:46 PDT Received: by obbgg8 with SMTP id gg8so80251182obb.1 for ; Fri, 20 Mar 2015 08:21:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=groupon.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+hr7WgjSIaDcLZHDcgZ+yj7WZRMa2eLApEJ1yjlhdo0=; b=TFu/lamZDprtnBtmRuCYRV2M83u/ZM2WlV9mZN2AIx005InmtEnmK3Q6g2ja+7CW6U F6sY/TrlT5xcUEXmCxj4D2vtrpP1dSdRL/8z3rP2Lau6VUn1RZumJzZdQ0ORKScRgZab pTewWE9toOFGXU57vD+8oE5Mm7KA93kIlZu1A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+hr7WgjSIaDcLZHDcgZ+yj7WZRMa2eLApEJ1yjlhdo0=; b=H3H+AXBuRIxBdJRixCs+24PynODy3sF3/eNCpl67D/mXdt4ZuF+5k5ptiDjOSjGdmf KTavuR+nbu9HnXdbQujO5REZf5OaFIcQ9LRGmkMdtjVbHAyIivumBVCehhq/J7Ayfgza Y1l74SShAxA2aFChlUvcg+qL/xqHO4UIWzYu0to/iFrZQe8iT1bFBs8rgaP36KtSLpXn fDXmrnz/t0hiE7Q/GjoCQptoEq0gwMHVw3KjvQnDyaW8n8ucS3xfPetU0RgZJ1rHo/d6 m+BzpQHZC78wqOvU3RQOt/ra+ZyUIuV24CAdAYQJUJHgoeg/RjD6LcyuY8irVYILDqHs vKPQ== X-Gm-Message-State: ALoCoQnJN/GfOdpp8tIgN56rhkec4AY3LuLcXzXcUbPA7l0jwU6UGwTChjdJAffkQT9b9oUO2djhyQ6mLpl5skf0pDYwxLz9z2QTFH1HMnstgAgjORwS60bnBcGtztvdKbwClCRhs/THlQSpdKd5jcla35OLCuRzTQ== X-Received: by 10.60.116.4 with SMTP id js4mr66109872oeb.78.1426864899287; Fri, 20 Mar 2015 08:21:39 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.116.4 with SMTP id js4mr66109854oeb.78.1426864899043; Fri, 20 Mar 2015 08:21:39 -0700 (PDT) Received: by 10.202.171.143 with HTTP; Fri, 20 Mar 2015 08:21:38 -0700 (PDT) In-Reply-To: References: <55076B84.0@multiplay.co.uk> Date: Fri, 20 Mar 2015 08:21:38 -0700 Message-ID: Subject: Re: ZFS doing background writes? From: Sean Chittenden To: Ronald Klop Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 15:21:46 -0000 Is atime set on any of your zfs file systems? Grab dtrace, write a probe to see what's doing the writes. Here's a quick script that you can run via `dtrace -s vfs-io.d`. Not the greatest, but useful. -sc #!/usr/sbin/dtrace -s #pragma D option quiet #pragma D option bufsize=8m #pragma D option switchrate=10hz #pragma D option dynvarsize=16m /* See /usr/src/sys/kern/uipc_mqueue.c for vop_read_args. * Also see sys/uio.h. */ vfs::vop_read:entry, vfs::vop_write:entry { self->ts[stackdepth] = timestamp; this->size = args[1]->a_uio->uio_resid; this->name = probefunc == "vop_read" ? "Read" : "Write"; @iosize1[execname, this->name] = quantize(this->size); } vfs::vop_read:return, vfs::vop_write:entry /this->ts = self->ts[stackdepth]/ { this->name = probefunc == "vop_read" ? "Read" : "Write"; @lat1[execname, this->name] = quantize(timestamp - this->ts); self->ts[stackdepth] = 0; } tick-1s { printf("Latencies (ns)\n\n"); printa("%s %s\n%@d\n", @lat1); printf("IO sizes (bytes)\n\n"); printa("%s %s\n%@d\n", @iosize1); printf("--------------------------------------------\n\n"); trunc(@lat1); trunc(@iosize1); } On Fri, Mar 20, 2015 at 7:53 AM, Ronald Klop wrote: > On Tue, 17 Mar 2015 07:30:24 +0100, Dirk E wrote: > > On Mon, 16 Mar 2015, Steven Hartland wrote: >>> >>> yes exactly that its defined by vfs.zfs.txg.timeout. >>>> >>> >>> Well, but what data (modulo atimes, which I presume OP had turned off >>> before) >>> are written? >>> >> >> I indeed have atime=off for the whole pool. But even with atime enabled, >> this behaviour should not happen, since no files are being accessed. Surely >> not in single user mode; the only processes outside of the kernel were >> '/bin/sh' and 'top'. Or zpool iostat when i ran it. >> >> I left the machine on and after a bunch of hours it is still doing >> periodical writes. The total ARC usage remains small: 5300K and changes >> slightly over time - again with no host writes. >> >> Even unmounting all ZFS filesystems will NOT cause this behaviour to go >> away. It seems to originate from the ZFS kernel itself, doing some >> autonomous maintenance on the background, or other feature.' >> >> Using top to sort processes with the longest CPU TIME, i can see: >> >> idle: 27.9H >> kernel: 6:48 >> intr: 4:34 >> zfskern: 0:33 >> geom: 0:29 >> syncer: 0:16 >> rand_harv 0:11 >> cam: 0:09 >> pf purge: 0:08 >> powerd: 0:03 >> >> This machine has done very little than boot and import the pool. As can >> be seen, the kernel and ZFS are pretty active in terms of CPU power. >> >> Anyone have a clue? >> > > It sounds like I have the same problem. I did not get much reply on my > question: > https://lists.freebsd.org/pipermail/freebsd-fs/2014-September/020004.html > > Regards, > Ronald. > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > -- Sean Chittenden From owner-freebsd-fs@FreeBSD.ORG Fri Mar 20 15:51:16 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 20B628F2 for ; Fri, 20 Mar 2015 15:51:16 +0000 (UTC) Received: from p3plsmtpa09-08.prod.phx3.secureserver.net (p3plsmtpa09-08.prod.phx3.secureserver.net [173.201.193.237]) by mx1.freebsd.org (Postfix) with ESMTP id E4C36EC5 for ; Fri, 20 Mar 2015 15:51:15 +0000 (UTC) Received: from [192.168.0.18] ([63.231.252.189]) by p3plsmtpa09-08.prod.phx3.secureserver.net with id 5rpc1q00T45wnoF01rpdva; Fri, 20 Mar 2015 08:49:39 -0700 Message-ID: <550C4190.40508@kateleyco.com> Date: Fri, 20 Mar 2015 10:49:36 -0500 From: Linda Kateley User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: zfs-discuss@zfsonlinux.org, freebsd-fs@freebsd.org, zfs-discuss@list.zfsonlinux.org, freenas-devel@lists.freenas.org, zfs@lists.illumos.org, developer@open-zfs.org Subject: Open-ZFS Office Hours Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 15:51:16 -0000 Hi, I am going to try and get office hours going again for the open-zfs community. We have scheduled a meeting on Thursday April 2nd at 9 AM PDT 11AM EDT 4PM GMT This months guest host is Justin Gibbs from freebsd. I am a little new at using hangouts, but I am pretty sure this link will get you there https://plus.google.com/events/ctt39ds1j8onc2uthm3kkaf6tl0 This info is also posted on open-zfs.org site. If you have ideas for future meetings, let me know. Tia -- Linda Kateley President Kateley Company 612-807-6349 Skype ID-kateleyco http://kateleyco.com From owner-freebsd-fs@FreeBSD.ORG Fri Mar 20 21:39:27 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E537468 for ; Fri, 20 Mar 2015 21:39:27 +0000 (UTC) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (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 284A1F2C for ; Fri, 20 Mar 2015 21:39:27 +0000 (UTC) Received: by pdnc3 with SMTP id c3so120018784pdn.0 for ; Fri, 20 Mar 2015 14:39:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=KhID9OKBweMl2jwQpoeNZbA3ZAcjHTevO8XHiygztqs=; b=d8gBD0pnVpwrwOrQiW8TaQAiXYdN8877p7cP2HO85gHdOIBcRu4ilwB+cjFz9Y+NZS 3u+TW4CpPGZBkASYpxZa+JaN58t4h8WQNWAUGSo4wDnoCQzgr0h/OE1uVmBJl7PIMT6R aDjudSqc6oS75zEdeu1PsX+PfoUmUPFrTZVtqT8sR9AOZwakvkOTXA2F2aY1aEkXgt35 U6B0Nba0riCXJiPSO9mfZdeunEqGqcvkUXOp4Q/SWFpvN5DXfU8v13cAd3HNgGrd6UuB jdr07PrWOsDMZKf05+fIWUDI73F4sUAnRZRgHy5zZ3u3gWSbVAlYuGrAOyzokbcdYuxi TIcQ== X-Received: by 10.66.140.15 with SMTP id rc15mr117669367pab.44.1426887566862; Fri, 20 Mar 2015 14:39:26 -0700 (PDT) Received: from [192.168.125.221] (aswan.sscsinc.com. [199.96.38.41]) by mx.google.com with ESMTPSA id hs4sm24102pbc.79.2015.03.20.14.39.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Mar 2015 14:39:25 -0700 (PDT) Message-ID: <550C938F.70500@gmail.com> Date: Fri, 20 Mar 2015 14:39:27 -0700 From: Motty Cruz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org, Motty Cruz Subject: zfs on FreeBSD 8.2 64bit stuck in "One or more devices is currently being resilvered" References: <550C8D1A.3070402@gmail.com> In-Reply-To: <550C8D1A.3070402@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 21:39:27 -0000 Hello All, am having issues with zfs server, it's hours at 100% done however it continue to resilver. this is the 3rd time is started the "resilver" process. I reboot the server but only to start the "resilver" process again. Any ideas or Suggestions? # zpool status pool: tank state: ONLINE status: One or more devices is currently being resilvered. The pool will continue to function, possibly in a degraded state. action: Wait for the resilver to complete. scrub: resilver in progress for 28h40m, 100.00% done, 0h0m to go config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz2 ONLINE 0 0 0 label/019 ONLINE 0 0 0 label/001b ONLINE 0 0 0 label/003 ONLINE 0 0 0 label/007b ONLINE 0 0 0 1.08T resilvered label/005 ONLINE 0 0 0 label/006 ONLINE 0 0 0 label/0171 ONLINE 0 0 0 label/108 ONLINE 0 0 0 label/009 ONLINE 0 0 0 label/0101 ONLINE 0 0 0 label/011 ONLINE 0 0 0 raidz2 ONLINE 0 0 0 label/0121 ONLINE 0 0 0 label/023 ONLINE 0 0 0 label/014 ONLINE 0 0 0 label/015 ONLINE 0 0 0 label/016 ONLINE 0 0 0 label/024 ONLINE 0 0 0 label/018 ONLINE 0 0 0 label/017 ONLINE 0 0 0 label/020 ONLINE 0 0 0 label/021 ONLINE 0 0 0 label/022 ONLINE 0 0 0 errors: No known data errors #gstat L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 0 0 0 0 0.0 0 0 0.0 0.0| acd0 0 0 0 0 0.0 0 0 0.0 0.0| mfid0 0 0 0 0 0.0 0 0 0.0 0.0| mfid0s1 0 0 0 0 0.0 0 0 0.0 0.0| mfid0s1a 0 0 0 0 0.0 0 0 0.0 0.0| mfid0s1b 0 0 0 0 0.0 0 0 0.0 0.0| mfid0s1d 0 0 0 0 0.0 0 0 0.0 0.0| mfid0s1e 0 0 0 0 0.0 0 0 0.0 0.0| mfid0s1f 1 245 77 1740 16.2 168 8336 10.0 64.5| da0 0 0 0 0 0.0 0 0 0.0 0.0| da1 2 220 88 2411 30.4 132 8336 14.4 85.1| da2 0 0 0 0 0.0 0 0 0.0 0.0| da3 1 223 73 1734 19.1 150 8334 14.8 78.8| da4 1 219 76 1926 27.7 143 8337 15.0 76.3| da5 0 265 6 383 17.2 259 8852 6.5 34.6| da6 1 218 76 2023 31.2 142 8334 15.5 82.1| da7 1 217 81 2054 27.2 136 8334 14.1 87.0| da8 1 245 77 1740 16.2 168 8336 13.5 74.9| label/001b 0 0 0 0 0.0 0 0 0.0 0.0| label/p002b-spare 2 220 88 2411 31.1 132 8336 20.6 86.6| label/003 0 0 0 0 0.0 0 0 0.0 0.0| label/004b-spare 1 223 73 1734 19.2 150 8334 20.1 87.8| label/005 1 219 76 1926 27.8 143 8337 19.3 84.3| label/006 0 265 6 383 17.2 259 8852 8.8 45.1| label/007b the HDD is label/007b or da6. Thanks, Motty From owner-freebsd-fs@FreeBSD.ORG Fri Mar 20 22:10:04 2015 Return-Path: Delivered-To: freebsd-fs@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 ACC72C32 for ; Fri, 20 Mar 2015 22:10:04 +0000 (UTC) Received: from mail.ultra-secure.de (mail.ultra-secure.de [88.198.178.88]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 16436298 for ; Fri, 20 Mar 2015 22:10:03 +0000 (UTC) Received: (qmail 43939 invoked by uid 89); 20 Mar 2015 22:09:39 -0000 Received: from unknown (HELO ?192.168.1.200?) (rainer@ultra-secure.de@217.71.83.52) by mail.ultra-secure.de with ESMTPA; 20 Mar 2015 22:09:39 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: zfs on FreeBSD 8.2 64bit stuck in "One or more devices is currently being resilvered" From: Rainer Duffner In-Reply-To: <550C938F.70500@gmail.com> Date: Fri, 20 Mar 2015 23:09:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <986BB4BF-D960-46EE-8E15-6FC5A5B6D219@ultra-secure.de> References: <550C8D1A.3070402@gmail.com> <550C938F.70500@gmail.com> To: Motty Cruz X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 22:10:04 -0000 > Am 20.03.2015 um 22:39 schrieb Motty Cruz : >=20 > Hello All, > am having issues with zfs server, it's hours at 100% done however it = continue to resilver. this is the 3rd time is started the "resilver" = process. I reboot the server but only to start the "resilver" process = again. Any ideas or Suggestions? >=20 > # zpool status > pool: tank > state: ONLINE > status: One or more devices is currently being resilvered. The pool = will > continue to function, possibly in a degraded state. > action: Wait for the resilver to complete. > scrub: resilver in progress for 28h40m, 100.00% done, 0h0m to go > config: >=20 > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > raidz2 ONLINE 0 0 0 > label/019 ONLINE 0 0 0 > label/001b ONLINE 0 0 0 > label/003 ONLINE 0 0 0 > label/007b ONLINE 0 0 0 1.08T resilvered > label/005 ONLINE 0 0 0 > label/006 ONLINE 0 0 0 > label/0171 ONLINE 0 0 0 > label/108 ONLINE 0 0 0 > label/009 ONLINE 0 0 0 > label/0101 ONLINE 0 0 0 > label/011 ONLINE 0 0 0 > raidz2 ONLINE 0 0 0 > label/0121 ONLINE 0 0 0 > label/023 ONLINE 0 0 0 > label/014 ONLINE 0 0 0 > label/015 ONLINE 0 0 0 > label/016 ONLINE 0 0 0 > label/024 ONLINE 0 0 0 > label/018 ONLINE 0 0 0 > label/017 ONLINE 0 0 0 > label/020 ONLINE 0 0 0 > label/021 ONLINE 0 0 0 > label/022 ONLINE 0 0 0 >=20 What=E2=80=99s the reason for the resilver? Also, is there any reason that stops you from upgrading to 8.3 or 8.4? 8.3 made ZFS actually usable for us, 9.1 improved it further and with = 10.1, it=E2=80=99s just great. From owner-freebsd-fs@FreeBSD.ORG Fri Mar 20 22:25:55 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5DEC6EB0 for ; Fri, 20 Mar 2015 22:25:55 +0000 (UTC) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (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 25F71681 for ; Fri, 20 Mar 2015 22:25:55 +0000 (UTC) Received: by pabxg6 with SMTP id xg6so108908031pab.0 for ; Fri, 20 Mar 2015 15:25:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=TVMSEb4VwrX7NvETQ/Nn+rTdld4N0+Q4cToQn08hWuo=; b=MPre38XFOg9vffJo4SE2eDqt0N3+HsHkIG0DdaV3bj8HOxu/w6u4/aTm2f6+Nk6c2O qTapkp1THTGbSqf8D8WOTVWepSRVSWLBqcIbGelQdzhtcUg05UxT0bNDHnzhNm/4JAIl V39khif00dMM7pgBpr0VImTtaGQByxqMgDXk6A3LE5U9crd9P1Q7JNWoho/21EAU0A8F sV0203tpflGUie3VG7ZrbolaJ+FOKTErO+dDBw7MKNiQvdIXTtzuv55+4v8x0Fm/hcPw PnoL99oiF+VYAlFJWPtJojsBYw/foYEEvc2htOVJYvNupGeLJrRxpeL2iXNh+PVym29C 7q/g== X-Received: by 10.66.185.230 with SMTP id ff6mr194291914pac.102.1426890354635; Fri, 20 Mar 2015 15:25:54 -0700 (PDT) Received: from [192.168.125.221] ([199.96.38.41]) by mx.google.com with ESMTPSA id y2sm9736596pdm.31.2015.03.20.15.25.52 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Mar 2015 15:25:53 -0700 (PDT) Message-ID: <550C9E70.60501@gmail.com> Date: Fri, 20 Mar 2015 15:25:52 -0700 From: Motty Cruz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Rainer Duffner , freebsd-fs@freebsd.org Subject: Re: zfs on FreeBSD 8.2 64bit stuck in "One or more devices is currently being resilvered" References: <550C8D1A.3070402@gmail.com> <550C938F.70500@gmail.com> <986BB4BF-D960-46EE-8E15-6FC5A5B6D219@ultra-secure.de> In-Reply-To: <986BB4BF-D960-46EE-8E15-6FC5A5B6D219@ultra-secure.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 22:25:55 -0000 Hello Rainer, What’s the reason for the resilver? a disk went bad, I had to replace it, soon after replacing the bad HDD it started the "resilver" process. Process went on and on for hours, unfortunately server stop responding, I was force to reboot. after rebooting started "resilver" process again, from zero. I put the HDD offline replace it "thinking it was a factory bad HHD" started the "resilver" process again. Also, is there any reason that stops you from upgrading to 8.3 or 8.4? You're suggesting to upgrade FreeBSD to 8.3? would this process damage data on zpool? if I upgrade FreeBSD, do I need to import/export zpool? 8.3 made ZFS actually usable for us, 9.1 improved it further and with 10.1, it’s just great. If I build another machine with latest FreeBSD, is it difficult to import/export zpool? Thanks in advance, -Motty On 03/20/2015 03:09 PM, Rainer Duffner wrote: >> Am 20.03.2015 um 22:39 schrieb Motty Cruz : >> >> Hello All, >> am having issues with zfs server, it's hours at 100% done however it continue to resilver. this is the 3rd time is started the "resilver" process. I reboot the server but only to start the "resilver" process again. Any ideas or Suggestions? >> >> # zpool status >> pool: tank >> state: ONLINE >> status: One or more devices is currently being resilvered. The pool will >> continue to function, possibly in a degraded state. >> action: Wait for the resilver to complete. >> scrub: resilver in progress for 28h40m, 100.00% done, 0h0m to go >> config: >> >> NAME STATE READ WRITE CKSUM >> tank ONLINE 0 0 0 >> raidz2 ONLINE 0 0 0 >> label/019 ONLINE 0 0 0 >> label/001b ONLINE 0 0 0 >> label/003 ONLINE 0 0 0 >> label/007b ONLINE 0 0 0 1.08T resilvered >> label/005 ONLINE 0 0 0 >> label/006 ONLINE 0 0 0 >> label/0171 ONLINE 0 0 0 >> label/108 ONLINE 0 0 0 >> label/009 ONLINE 0 0 0 >> label/0101 ONLINE 0 0 0 >> label/011 ONLINE 0 0 0 >> raidz2 ONLINE 0 0 0 >> label/0121 ONLINE 0 0 0 >> label/023 ONLINE 0 0 0 >> label/014 ONLINE 0 0 0 >> label/015 ONLINE 0 0 0 >> label/016 ONLINE 0 0 0 >> label/024 ONLINE 0 0 0 >> label/018 ONLINE 0 0 0 >> label/017 ONLINE 0 0 0 >> label/020 ONLINE 0 0 0 >> label/021 ONLINE 0 0 0 >> label/022 ONLINE 0 0 0 >> > > > What’s the reason for the resilver? > > Also, is there any reason that stops you from upgrading to 8.3 or 8.4? > > 8.3 made ZFS actually usable for us, 9.1 improved it further and with 10.1, it’s just great. > > > > From owner-freebsd-fs@FreeBSD.ORG Fri Mar 20 22:32:42 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 578CA11C for ; Fri, 20 Mar 2015 22:32:42 +0000 (UTC) Received: from mail.ultra-secure.de (mail.ultra-secure.de [88.198.178.88]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9A1F87BD for ; Fri, 20 Mar 2015 22:32:40 +0000 (UTC) Received: (qmail 44410 invoked by uid 89); 20 Mar 2015 22:32:39 -0000 Received: from unknown (HELO ?192.168.1.200?) (rainer@ultra-secure.de@217.71.83.52) by mail.ultra-secure.de with ESMTPA; 20 Mar 2015 22:32:39 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: zfs on FreeBSD 8.2 64bit stuck in "One or more devices is currently being resilvered" From: Rainer Duffner In-Reply-To: <550C9E70.60501@gmail.com> Date: Fri, 20 Mar 2015 23:32:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <550C8D1A.3070402@gmail.com> <550C938F.70500@gmail.com> <986BB4BF-D960-46EE-8E15-6FC5A5B6D219@ultra-secure.de> <550C9E70.60501@gmail.com> To: Motty Cruz X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 22:32:42 -0000 > Am 20.03.2015 um 23:25 schrieb Motty Cruz : >=20 > Hello Rainer, >=20 > a disk went bad, I had to replace it, soon after replacing the bad HDD = it started the "resilver" process. Process went on and on for hours, = unfortunately server stop responding, I was force to reboot. after = rebooting started "resilver" process again, from zero. I put the HDD = offline replace it "thinking it was a factory bad HHD" started the = "resilver" process again. >=20 I would assume that the ZFS still thinks it=E2=80=99s the old disk = somehow. This is what usually happens then. I=E2=80=99m not sure if an upgraded FreeBSD will help you with your = resilver-problem. Can you describe what you did to replace the disk? From owner-freebsd-fs@FreeBSD.ORG Fri Mar 20 22:44:15 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5438A3D0 for ; Fri, 20 Mar 2015 22:44:15 +0000 (UTC) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (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 1B63C8A4 for ; Fri, 20 Mar 2015 22:44:15 +0000 (UTC) Received: by pdbni2 with SMTP id ni2so121262652pdb.1 for ; Fri, 20 Mar 2015 15:44:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=nBHIfLQT2Vjr6ov7CSDK2IXEeGNWvKY2pilx8dY4ZNs=; b=dRjwp0sj2mjtphDYpyB/ffBpLotKdWnDARekefgJV/LwAFkeMxvZh9emq4woSDvIdD uapEsEI6c0fPv5nJrvVnRmbykXl0zej8jYiBIGnd6eG/d07xBJ7ThSvrVxQqXYBJ+L4n 8mMjcEq3MxrtnY5LO7BqYsmhsryvH/Lmt96B4+ueVPY56w507y3Lrd3BW6AcRcNprHo3 rsAIiuJW5y+nALWxIFZ3Wg3HPq8bCg+56zdxvZXZictGzkIhuIItgHrWKBEhrDm0KIlY ibNQnL+pxbqRQte9qRsD2FezwVSUu/41mgpwm5cgX9RintDyC5q3FkZXP8o8W3i8vob9 1AMQ== X-Received: by 10.66.65.234 with SMTP id a10mr197023288pat.120.1426891454701; Fri, 20 Mar 2015 15:44:14 -0700 (PDT) Received: from [192.168.125.221] (aswan.sscsinc.com. [199.96.38.41]) by mx.google.com with ESMTPSA id pq8sm97285pbc.73.2015.03.20.15.44.13 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Mar 2015 15:44:13 -0700 (PDT) Message-ID: <550CA2BF.2070406@gmail.com> Date: Fri, 20 Mar 2015 15:44:15 -0700 From: Motty Cruz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Rainer Duffner Subject: Re: zfs on FreeBSD 8.2 64bit stuck in "One or more devices is currently being resilvered" References: <550C8D1A.3070402@gmail.com> <550C938F.70500@gmail.com> <986BB4BF-D960-46EE-8E15-6FC5A5B6D219@ultra-secure.de> <550C9E70.60501@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 22:44:15 -0000 Can you describe what you did to replace the disk? I sure can. I had spare hdd in the pool. #zpool replace tank label/004 label/007b label/003 ONLINE 0 0 0 replacing DEGRADED 0 0 0 433419809408607751 UNAVAIL 0 0 0 was/dev/label/007 label/004 ONLINE 0 0 0 2.47T resilvered label/005 ONLINE 0 0 0 after two days of resilvering, the server became unresponsive. I reboot the server started to resilver again. after that I also detached bad disk. #zpool detach tank 433419809408607751 I have tried zpool clear tank but no success, Thanks, Motty On 03/20/2015 03:32 PM, Rainer Duffner wrote: >> Am 20.03.2015 um 23:25 schrieb Motty Cruz : >> >> Hello Rainer, >> >> a disk went bad, I had to replace it, soon after replacing the bad HDD it started the "resilver" process. Process went on and on for hours, unfortunately server stop responding, I was force to reboot. after rebooting started "resilver" process again, from zero. I put the HDD offline replace it "thinking it was a factory bad HHD" started the "resilver" process again. >> > > I would assume that the ZFS still thinks it’s the old disk somehow. > This is what usually happens then. > > > I’m not sure if an upgraded FreeBSD will help you with your resilver-problem. > > Can you describe what you did to replace the disk? > > > From owner-freebsd-fs@FreeBSD.ORG Fri Mar 20 23:57:59 2015 Return-Path: Delivered-To: freebsd-fs@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 C8A74387 for ; Fri, 20 Mar 2015 23:57:59 +0000 (UTC) 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 AEC77F73 for ; Fri, 20 Mar 2015 23:57:59 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2KNvxQg021551 for ; Fri, 20 Mar 2015 23:57:59 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 198731] Generated ext3 filesystem is reported to have corrupted directory inodes Date: Fri, 20 Mar 2015 23:57:59 +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-RELEASE 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 23:57:59 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198731 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 Sat Mar 21 05:23:55 2015 Return-Path: Delivered-To: freebsd-fs@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 30922E65 for ; Sat, 21 Mar 2015 05:23:55 +0000 (UTC) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::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 DA5F0697 for ; Sat, 21 Mar 2015 05:23:54 +0000 (UTC) Received: by yhim52 with SMTP id m52so20284970yhi.2 for ; Fri, 20 Mar 2015 22:23:54 -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=LDe6pF9zLS8WU2amyTR5tzQi6iTN+vfPwRiqs4ic8Kw=; b=mKtQeuSLSookPEmql6g8sS+lkNRQRbqa+K3Py6pl+3VQLjs6y49D+oUN780A1IJwyU y+iFz9BzAep0LGU5+FsANeu0uraNwnisr0gW2YCylynDo71Ah+QOTf7de5x0NV0xXxLG DM6tWLER/uk2rvy6A4hXfb6Os0+WOE+8AquHs1g+d5/cDwSVkcNZ8x1uI/83G8wio78+ C2hfDq82SRtYuU+l+pBwE6oW25DaqL5j7jfmTwbibp+L07+uLUVoEfASVNWkKISceaIM ccJzFpUqyRCJi/ThSllCmbQLTq6nmWmO6Uqx+PmHrlKURTvTHno7o5zX0ZusRcQ0Ylgf tMXA== MIME-Version: 1.0 X-Received: by 10.236.26.143 with SMTP id c15mr85742347yha.192.1426915433958; Fri, 20 Mar 2015 22:23:53 -0700 (PDT) Received: by 10.170.60.69 with HTTP; Fri, 20 Mar 2015 22:23:53 -0700 (PDT) In-Reply-To: <550CA2BF.2070406@gmail.com> References: <550C8D1A.3070402@gmail.com> <550C938F.70500@gmail.com> <986BB4BF-D960-46EE-8E15-6FC5A5B6D219@ultra-secure.de> <550C9E70.60501@gmail.com> <550CA2BF.2070406@gmail.com> Date: Fri, 20 Mar 2015 22:23:53 -0700 Message-ID: Subject: Re: zfs on FreeBSD 8.2 64bit stuck in "One or more devices is currently being resilvered" From: Mehmet Erol Sanliturk To: Motty Cruz Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 05:23:55 -0000 On Fri, Mar 20, 2015 at 3:44 PM, Motty Cruz wrote: > Can you describe what you did to replace the disk? > > I sure can. I had spare hdd in the pool. > #zpool replace tank label/004 label/007b > > label/003 ONLINE 0 0 0 > replacing DEGRADED 0 0 0 > 433419809408607751 UNAVAIL 0 0 0 > was/dev/label/007 > label/004 ONLINE 0 0 0 2.47T > resilvered > label/005 ONLINE 0 0 0 > > after two days of resilvering, the server became unresponsive. I reboot > the server started to resilver again. after that I also > detached bad disk. > #zpool detach tank 433419809408607751 > > I have tried zpool clear tank but no success, > > Thanks, > Motty > On 03/20/2015 03:32 PM, Rainer Duffner wrote: > >> Am 20.03.2015 um 23:25 schrieb Motty Cruz : >>> >>> Hello Rainer, >>> >>> a disk went bad, I had to replace it, soon after replacing the bad HDD >>> it started the "resilver" process. Process went on and on for hours, >>> unfortunately server stop responding, I was force to reboot. after >>> rebooting started "resilver" process again, from zero. I put the HDD >>> offline replace it "thinking it was a factory bad HHD" started the >>> "resilver" process again. >>> >>> >> I would assume that the ZFS still thinks it=E2=80=99s the old disk someh= ow. >> This is what usually happens then. >> >> >> I=E2=80=99m not sure if an upgraded FreeBSD will help you with your >> resilver-problem. >> >> Can you describe what you did to replace the disk? >> >> >> >> > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" Is there a possibility that the resilvered parts ( port , cable , etc. ) have hardware failure problems which OS is not able to complete resilvering or it is seen that part to be resilvered ? Mehmet Erol Sanliturk From owner-freebsd-fs@FreeBSD.ORG Sat Mar 21 11:28:33 2015 Return-Path: Delivered-To: freebsd-fs@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 E39FA3B9 for ; Sat, 21 Mar 2015 11:28:33 +0000 (UTC) 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 C85D9A26 for ; Sat, 21 Mar 2015 11:28:33 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2LBSXU8006235 for ; Sat, 21 Mar 2015 11:28:33 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 198731] Generated ext3 filesystem is reported to have corrupted directory inodes Date: Sat, 21 Mar 2015 11:28:33 +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-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ardovm@yahoo.it 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: attachments.created 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 11:28:34 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198731 --- Comment #1 from Arrigo Marchiori --- Created attachment 154616 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=154616&action=edit Script that triggers the bug I wrote this script to check different combinations of image size, filesystem (ext2 vs ext3) and sleep time before unmount. On my 10.1-RELEASE-p6 system, these parameters trigger the bug: - size: 128 MB; - fs: ext2 (for mkfs and fsck); - sleep time: 1 second. When changing the size to 64 MB the problem seems to go away, but it's hard to deduce a precise law. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Sat Mar 21 11:28:55 2015 Return-Path: Delivered-To: freebsd-fs@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 A1014423 for ; Sat, 21 Mar 2015 11:28:55 +0000 (UTC) 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 863B9A29 for ; Sat, 21 Mar 2015 11:28:55 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2LBStZI006353 for ; Sat, 21 Mar 2015 11:28:55 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 198731] Generated ext2/ext3 filesystem is reported to have corrupted directory inodes Date: Sat, 21 Mar 2015 11:28:55 +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-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ardovm@yahoo.it 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: short_desc 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.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 11:28:55 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198731 Arrigo Marchiori changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Generated ext3 filesystem |Generated ext2/ext3 |is reported to have |filesystem is reported to |corrupted directory inodes |have corrupted directory | |inodes -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Sat Mar 21 16:01:04 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E8508626 for ; Sat, 21 Mar 2015 16:01:04 +0000 (UTC) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (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 5266D768 for ; Sat, 21 Mar 2015 16:01:04 +0000 (UTC) Received: by lbbrr9 with SMTP id rr9so29255494lbb.0 for ; Sat, 21 Mar 2015 09:01:02 -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=7eDZOVieq7T1Drw+zaY4nj8/tQtWw+uW+MNx/yM1bmc=; b=L4xzmm7a8jYWsfgunCYabh9rrAoNllcgjA3IIRrQ8XR+NzcxXrNiMauY6Iwf6+ZwNo brqcXsOveitcTGQaoWZtlfZqhlnye7t/0iO9VN89zXnqBYYltMJuC4WPEXvdPNZaG207 m3CpFsYDvHlaPhBJ891ErkVswEg9mRbioT2AoKK7ylKqj/6o6q3OevS21loYXH0f9Ic5 y5evbFVb9sepiUXvXCJigNjvMw0+ZwGQbSuIFYqxcJ7aTsMJHTQuGMU0C/8CscqVpBvl r5Ew8paOKJJ1sDFirw+FageiwSuURPpeMSCSKlrSapaZ7EaPC1NaqzAuAX0QpzxgYRKO kRqQ== MIME-Version: 1.0 X-Received: by 10.152.10.209 with SMTP id k17mr47125310lab.50.1426953662190; Sat, 21 Mar 2015 09:01:02 -0700 (PDT) Received: by 10.112.162.5 with HTTP; Sat, 21 Mar 2015 09:01:02 -0700 (PDT) In-Reply-To: References: <550C8D1A.3070402@gmail.com> <550C938F.70500@gmail.com> <986BB4BF-D960-46EE-8E15-6FC5A5B6D219@ultra-secure.de> <550C9E70.60501@gmail.com> <550CA2BF.2070406@gmail.com> Date: Sat, 21 Mar 2015 09:01:02 -0700 Message-ID: Subject: Re: zfs on FreeBSD 8.2 64bit stuck in "One or more devices is currently being resilvered" From: motty cruz To: Mehmet Erol Sanliturk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 16:01:05 -0000 Hi Mehmet, are you thinking a bad HDD bay? If I ran the gstat command I see is writing to disk : dT: 1.002s w: 1.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 0 0 0 0 0.0 0 0 0.0 0.0| acd0 0 9 0 0 0.0 9 144 22.1 3.1| mfid0 0 9 0 0 0.0 9 144 22.6 3.1| mfid0s1 0 9 0 0 0.0 9 144 22.9 3.2| mfid0s1a 0 0 0 0 0.0 0 0 0.0 0.0| mfid0s1b 0 0 0 0 0.0 0 0 0.0 0.0| mfid0s1d 0 0 0 0 0.0 0 0 0.0 0.0| mfid0s1e 0 0 0 0 0.0 0 0 0.0 0.0| mfid0s1f 2 4631 4631 13270 0.4 0 0 0.0 73.0| da0 0 0 0 0 0.0 0 0 0.0 0.0| da1 3 3979 3979 13345 0.7 0 0 0.0 78.0| da2 0 0 0 0 0.0 0 0 0.0 0.0| da3 5 4503 4503 13263 0.5 0 0 0.0 76.0| da4 5 4245 4245 13254 0.6 0 0 0.0 77.5| da5 4 4741 0 0 0.0 4741 11626 1.2 86.7| da6 disk being replace is da6, as you can see w/s11626? unless I am not reading this right? so I don't think is the cable or port. I really don't know what is causing this issue: today is the 3rd day resilvering: # zpool status pool: tank state: ONLINE status: One or more devices is currently being resilvered. The pool will continue to function, possibly in a degraded state. action: Wait for the resilver to complete. scrub: resilver in progress for 47h47m, 100.00% done, 0h0m to go config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz2 ONLINE 0 0 0 label/019 ONLINE 0 0 0 label/001b ONLINE 0 0 0 label/003 ONLINE 0 0 0 label/007b ONLINE 0 0 0 1.79T resilvered label/005 ONLINE 0 0 0 label/006 ONLINE 0 0 0 label/0171 ONLINE 0 0 0 any suggestion on what should be my next step? Thanks in advance! -Motty On Fri, Mar 20, 2015 at 10:23 PM, Mehmet Erol Sanliturk < m.e.sanliturk@gmail.com> wrote: > > > On Fri, Mar 20, 2015 at 3:44 PM, Motty Cruz wrote: > >> Can you describe what you did to replace the disk? >> >> I sure can. I had spare hdd in the pool. >> #zpool replace tank label/004 label/007b >> >> label/003 ONLINE 0 0 0 >> replacing DEGRADED 0 0 0 >> 433419809408607751 UNAVAIL 0 0 0 >> was/dev/label/007 >> label/004 ONLINE 0 0 0 2.47T >> resilvered >> label/005 ONLINE 0 0 0 >> >> after two days of resilvering, the server became unresponsive. I reboot >> the server started to resilver again. after that I also >> detached bad disk. >> #zpool detach tank 433419809408607751 >> >> I have tried zpool clear tank but no success, >> >> Thanks, >> Motty >> On 03/20/2015 03:32 PM, Rainer Duffner wrote: >> >>> Am 20.03.2015 um 23:25 schrieb Motty Cruz : >>>> >>>> Hello Rainer, >>>> >>>> a disk went bad, I had to replace it, soon after replacing the bad HDD >>>> it started the "resilver" process. Process went on and on for hours, >>>> unfortunately server stop responding, I was force to reboot. after >>>> rebooting started "resilver" process again, from zero. I put the HDD >>>> offline replace it "thinking it was a factory bad HHD" started the >>>> "resilver" process again. >>>> >>>> >>> I would assume that the ZFS still thinks it=E2=80=99s the old disk some= how. >>> This is what usually happens then. >>> >>> >>> I=E2=80=99m not sure if an upgraded FreeBSD will help you with your >>> resilver-problem. >>> >>> Can you describe what you did to replace the disk? >>> >>> >>> >>> >> _______________________________________________ >> freebsd-fs@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-fs >> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > > > > Is there a possibility that the resilvered parts ( port , cable , etc. ) > have hardware failure problems which OS is not able to complete resilveri= ng > or it is seen that part to be resilvered ? > > > > Mehmet Erol Sanliturk > > > > > > --=20 Thanks for your support, Motty From owner-freebsd-fs@FreeBSD.ORG Sat Mar 21 16:57:52 2015 Return-Path: Delivered-To: freebsd-fs@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 306559FE for ; Sat, 21 Mar 2015 16:57:52 +0000 (UTC) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::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 D651ECFD for ; Sat, 21 Mar 2015 16:57:51 +0000 (UTC) Received: by yhjf44 with SMTP id f44so52328985yhj.3 for ; Sat, 21 Mar 2015 09:57:51 -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=Vek2RibzCP+buaoQ4d9lP0aaCUKVYW6dp7MbaZbt78w=; b=tmbuCOtT/jfERbXBYp/rQYhBI09bqodGwYwnfBo0ddf/vsJ1hwNaLKwxLATTkBtSWd YF/10zIAnXsF9sAFjVvmZgTJ2p8Ie2MotvTJ+S8y2eYmFA/anWtdAnBiDwrUSBkoYMkf RpwIdP55SbQH++3bnYDx0scgRPKFhLHpAVSRei3xZu0fl6nKRxIx0PK5FuNIrYkpwQgl K+ew+fK0nl5HtNSvlWgJw3GwpaBa93n0jpkOKmdYwAFheQdo2p2vH7irxDKLI71aaPXO gz86rqgq7xq4ToquO4p0stbij1RALHIVp0O8efa+kXzdcdx9oowoeNzXlDesZDmXj2rq 5LPQ== MIME-Version: 1.0 X-Received: by 10.170.90.70 with SMTP id h67mr98499668yka.46.1426957071003; Sat, 21 Mar 2015 09:57:51 -0700 (PDT) Received: by 10.170.60.69 with HTTP; Sat, 21 Mar 2015 09:57:50 -0700 (PDT) In-Reply-To: References: <550C8D1A.3070402@gmail.com> <550C938F.70500@gmail.com> <986BB4BF-D960-46EE-8E15-6FC5A5B6D219@ultra-secure.de> <550C9E70.60501@gmail.com> <550CA2BF.2070406@gmail.com> Date: Sat, 21 Mar 2015 09:57:50 -0700 Message-ID: Subject: Re: zfs on FreeBSD 8.2 64bit stuck in "One or more devices is currently being resilvered" From: Mehmet Erol Sanliturk To: motty cruz Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 16:57:52 -0000 On Sat, Mar 21, 2015 at 9:01 AM, motty cruz wrote: > Hi Mehmet, are you thinking a bad HDD bay? If I ran the gstat command I > see is writing to disk : > dT: 1.002s w: 1.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name > 0 0 0 0 0.0 0 0 0.0 0.0| acd0 > 0 9 0 0 0.0 9 144 22.1 3.1| mfid0 > 0 9 0 0 0.0 9 144 22.6 3.1| mfid0s1 > 0 9 0 0 0.0 9 144 22.9 3.2| mfid0s1a > 0 0 0 0 0.0 0 0 0.0 0.0| mfid0s1b > 0 0 0 0 0.0 0 0 0.0 0.0| mfid0s1d > 0 0 0 0 0.0 0 0 0.0 0.0| mfid0s1e > 0 0 0 0 0.0 0 0 0.0 0.0| mfid0s1f > 2 4631 4631 13270 0.4 0 0 0.0 73.0| da0 > 0 0 0 0 0.0 0 0 0.0 0.0| da1 > 3 3979 3979 13345 0.7 0 0 0.0 78.0| da2 > 0 0 0 0 0.0 0 0 0.0 0.0| da3 > 5 4503 4503 13263 0.5 0 0 0.0 76.0| da4 > 5 4245 4245 13254 0.6 0 0 0.0 77.5| da5 > 4 4741 0 0 0.0 4741 11626 1.2 86.7| da6 > > disk being replace is da6, as you can see w/s11626? unless I am not > reading this right? so I don't think is the cable or port. I really don't > know what is causing this issue: > > today is the 3rd day resilvering: > # zpool status > pool: tank > state: ONLINE > status: One or more devices is currently being resilvered. The pool will > continue to function, possibly in a degraded state. > action: Wait for the resilver to complete. > scrub: resilver in progress for 47h47m, 100.00% done, 0h0m to go > config: > > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > raidz2 ONLINE 0 0 0 > label/019 ONLINE 0 0 0 > label/001b ONLINE 0 0 0 > label/003 ONLINE 0 0 0 > label/007b ONLINE 0 0 0 1.79T resilvered > label/005 ONLINE 0 0 0 > label/006 ONLINE 0 0 0 > label/0171 ONLINE 0 0 0 > any suggestion on what should be my next step? > > Thanks in advance! > -Motty > > Yes , it may be . If you can , you may attach to a working HDD bay and see whether the HDD has problem or the HDD bay . Another step may be to remove HDD from the trouble causing bay and use a correctly working group of HDD bays . Then add a HDD which you know is working correctly to a suspected HDD bay and see whether it is causing trouble or not . Continue in that way , up to identify status of bays or its other related components . One important problem is corruption of your data . My suggestion is to back up your data and up to resolving this issue , do not use this computer for your production works . Sometimes a part starts to failure step by step slowly and at the end may completely fail . I am saying these to emphasize the importance of saving of your data as soon as possible . If you have facility , another step may be to replace HDD bays controller by a new and good quality controller . Version 8.2 is very old . Switching to a new version , either 9.3 , or 10.1 may be useful by using a spare system to transfer your data to newly installed system . I think you know very well how to migrate to a new system when ZFS is used = . I am not using ZFS , therefore , my knowledge is very weak . I have encountered a likely similar problem in a NFS server - client group = . In the server , program sources were corrupted either by truncating lines or by injecting invalid characters into lines , or changing characters to invalid characters randomly . I have replaced server , switch and cables and in suspected ( because of "Access Violation" messages ) client computer the memory chips . At the end it come out that the suspected client computer mother board chips is/are faulty ( not memory chips ) or other parts . When there is no any sufficiently capable testing equipment , only action can be done is to replace suspected parts by other ( known to be working parts as much as possible ) . > On Fri, Mar 20, 2015 at 10:23 PM, Mehmet Erol Sanliturk < > m.e.sanliturk@gmail.com> wrote: > >> >> >> On Fri, Mar 20, 2015 at 3:44 PM, Motty Cruz wrote= : >> >>> Can you describe what you did to replace the disk? >>> >>> I sure can. I had spare hdd in the pool. >>> #zpool replace tank label/004 label/007b >>> >>> label/003 ONLINE 0 0 0 >>> replacing DEGRADED 0 0 0 >>> 433419809408607751 UNAVAIL 0 0 0 >>> was/dev/label/007 >>> label/004 ONLINE 0 0 0 2.47T >>> resilvered >>> label/005 ONLINE 0 0 0 >>> >>> after two days of resilvering, the server became unresponsive. I reboot >>> the server started to resilver again. after that I also >>> detached bad disk. >>> #zpool detach tank 433419809408607751 >>> >>> Since newly attached HDD is generating trouble , this may show that , problem is not in the HDD , but in the HDD bay or its related parts . My suggestion is , "Do not salvage your disk before verifying that it is really defective." . > I have tried zpool clear tank but no success, >>> >>> Thanks, >>> Motty >>> On 03/20/2015 03:32 PM, Rainer Duffner wrote: >>> >>>> Am 20.03.2015 um 23:25 schrieb Motty Cruz : >>>>> >>>>> Hello Rainer, >>>>> >>>>> a disk went bad, I had to replace it, soon after replacing the bad HD= D >>>>> it started the "resilver" process. Process went on and on for hours, >>>>> unfortunately server stop responding, I was force to reboot. after >>>>> rebooting started "resilver" process again, from zero. I put the HDD >>>>> offline replace it "thinking it was a factory bad HHD" started the >>>>> "resilver" process again. >>>>> >>>>> >>>> I would assume that the ZFS still thinks it=E2=80=99s the old disk som= ehow. >>>> This is what usually happens then. >>>> >>>> >>>> I=E2=80=99m not sure if an upgraded FreeBSD will help you with your >>>> resilver-problem. >>>> >>>> Can you describe what you did to replace the disk? >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> freebsd-fs@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-fs >>> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >> >> >> >> Is there a possibility that the resilvered parts ( port , cable , etc. ) >> have hardware failure problems which OS is not able to complete resilver= ing >> or it is seen that part to be resilvered ? >> >> >> >> Mehmet Erol Sanliturk >> >> >> >> >> >> > > > -- > Thanks for your support, > Motty > From owner-freebsd-fs@FreeBSD.ORG Sat Mar 21 17:13:09 2015 Return-Path: Delivered-To: freebsd-fs@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 33316DE4 for ; Sat, 21 Mar 2015 17:13:09 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 98ECAEC2 for ; Sat, 21 Mar 2015 17:13:08 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t2LHD3hG063580 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 21 Mar 2015 19:13:03 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t2LHD3hG063580 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t2LHD3jJ063579; Sat, 21 Mar 2015 19:13:03 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 21 Mar 2015 19:13:03 +0200 From: Konstantin Belousov To: Chris Torek Subject: Re: leftovers in fs/msdosfs/msdosfsmount.h Message-ID: <20150321171303.GL2379@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 17:13:09 -0000 On Thu, Mar 19, 2015 at 08:49:33PM -0700, Chris Torek wrote: > I was poking at the kernel-side msdosfs code for reasons too boring :-) to > go into here and found some stuff that should be safe to remove, based on > the fact that there are no references to these names anywhere in the rest > of the entire source tree. > > I've built a kernel with this patch in it (as a double check) but have not > tested it on anything else. I don't really care if it goes in or not, I'm > just providing it since I got misled slightly (in terms of how the UTF-16 > en- and de-coding was to be done) when I was looking at the header. > > (In case gmail eats the straight text patch below, it's here as an > attachment too. I'd send from a better mail system but my regular home > FreeBSD system is still not quite up yet...) I started the make universe for your patch, will commit after. > > (A more interesting question is: when can the old compat mount stuff go > away?) I did the review of the cmount() usage in the base, and I think now it is the autofs(4) author who is in charge. It seems that the only user of cmount in base is amd, and it should be removed, after autofs is mature enough.