From owner-freebsd-fs@FreeBSD.ORG Sun Mar 22 04:49: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 AD71ED6E for ; Sun, 22 Mar 2015 04:49:15 +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 93CEFABE for ; Sun, 22 Mar 2015 04:49:15 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2M4nFSu098307 for ; Sun, 22 Mar 2015 04:49:15 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: Sun, 22 Mar 2015 04:49:15 +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: pfg@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, 22 Mar 2015 04:49:15 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198731 Pedro F. Giffuni changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pfg@FreeBSD.org --- Comment #2 from Pedro F. Giffuni --- (In reply to Arrigo Marchiori from comment #1) Ciao Arrigo; Thank you for the report. There's no need to submit the tarball. Can you try disabling the "dir_index" feature (with e2tunefs) and try again? Thanks, Pedro. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Sun Mar 22 09:22: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 101B6263 for ; Sun, 22 Mar 2015 09:22:24 +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 E9B3B7E0 for ; Sun, 22 Mar 2015 09:22: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 t2M9MNoD053573 for ; Sun, 22 Mar 2015 09:22:23 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: Sun, 22 Mar 2015 09:22: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: 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: 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, 22 Mar 2015 09:22:24 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198731 --- Comment #3 from Arrigo Marchiori --- (In reply to Pedro F. Giffuni from comment #2) Ciao Pedro! Thank you for your answer. It seems that clearing the "dir_index" feature makes the problem disappear! I tested it on the 10.1-release-p6 system using the ad-hoc tarball. I will try this setting tomorrow, on my 9-STABLE system, with the full ext2 filesystem on real hardware. I will keep you updated. Thank you again and have a nice Sunday. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Sun Mar 22 09:24:06 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 2A97C2D5 for ; Sun, 22 Mar 2015 09:24:06 +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 0F9D57E8 for ; Sun, 22 Mar 2015 09:24:06 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2M9O5TB054274 for ; Sun, 22 Mar 2015 09:24:05 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: Sun, 22 Mar 2015 09:24:06 +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.isobsolete 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: Sun, 22 Mar 2015 09:24:06 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198731 Arrigo Marchiori changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #154616|0 |1 is obsolete| | --- Comment #4 from Arrigo Marchiori --- Created attachment 154649 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=154649&action=edit Script that triggers the bug (2nd version: dir_index) Second version of the script. It allows to enable or disable the dir_index feature in the created filesystem. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Sun Mar 22 15:07:10 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 74C1086C for ; Sun, 22 Mar 2015 15:07: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 5A897ABC for ; Sun, 22 Mar 2015 15:07: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 t2MF7AL8050797 for ; Sun, 22 Mar 2015 15:07:10 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: Sun, 22 Mar 2015 15:07: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.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: pfg@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: see_also Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 15:07:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198731 Pedro F. Giffuni changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.freebsd.org/bu | |gzilla/show_bug.cgi?id=1918 | |95 --- Comment #5 from Pedro F. Giffuni --- (In reply to Arrigo Marchiori from comment #4) Thank you for you report and followup. I will be removing the dir_index feature altogether. It's an interesting ext3/4 -specific feature but it is not necessary, and we have two open bugs reports concerning it. Luckily version control works nicely and it can always be resurrected if we need it. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Sun Mar 22 15:07: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 6AE50871 for ; Sun, 22 Mar 2015 15:07: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 50BAAAC0 for ; Sun, 22 Mar 2015 15:07:11 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2MF7B5Z051074 for ; Sun, 22 Mar 2015 15:07:11 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 191895] [ext2fs] [panic] ext2_dirbad: /mnt: bad dir ino 32787 at offset 6136: mangled entry Date: Sun, 22 Mar 2015 15:07: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: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: pfg@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: see_also Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 15:07:11 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191895 Pedro F. Giffuni changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.freebsd.org/bu | |gzilla/show_bug.cgi?id=1987 | |31 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Sun Mar 22 21:00:32 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 864E0F32 for ; Sun, 22 Mar 2015 21:00:32 +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 5B22C752 for ; Sun, 22 Mar 2015 21:00:32 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2ML0Wvc034569 for ; Sun, 22 Mar 2015 21:00:32 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201503222100.t2ML0Wvc034569@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, 22 Mar 2015 21:00:32 +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, 22 Mar 2015 21:00:32 -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 22 22:44:44 2015 Return-Path: Delivered-To: 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 3FCDDC92 for ; Sun, 22 Mar 2015 22:44:44 +0000 (UTC) Received: from smtp.digiware.nl (smtp.digiware.nl [31.223.170.169]) (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 F1FA317F for ; Sun, 22 Mar 2015 22:44:43 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 14FD916A406 for ; Sun, 22 Mar 2015 23:44:35 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzc9lP_GaW76; Sun, 22 Mar 2015 23:44:24 +0100 (CET) Received: from [192.168.10.211] (unknown [192.168.10.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 6214916A402 for ; Sun, 22 Mar 2015 23:44:24 +0100 (CET) Message-ID: <550F45CA.5000302@digiware.nl> Date: Sun, 22 Mar 2015 23:44:26 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: fs@freebsd.org Subject: Missing some ZFS values in sysctl output 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: Sun, 22 Mar 2015 22:44:44 -0000 Hoi, There is this zfs-snmp script that allows one the graph certain things from a ZFS setup. The original uses solaris' kstat, but just about all values are in Sysctl with FreeBSD. However I seem to overlook the values for: Original code: ==== def zfs_read(oid): return ('counter', kstat("unix:0:vopstats_zfs:read_bytes") / 1024 % 2**32) # 32 bit KB counter def zfs_readdir(oid): return ('counter', kstat("unix:0:vopstats_zfs:readdir_bytes") / 1024 % 2**32) # 32 bit KB counter def zfs_write(oid): return ('counter', kstat("unix:0:vopstats_zfs:write_bytes") / 1024 % 2**32) # 32 bit KB counter ======= Read and write are available for L2 arc, but for the global values I seem to miss them. Are they really not in ZFS? And is it possible to add them? Reagards, --WjW From owner-freebsd-fs@FreeBSD.ORG Mon Mar 23 10:51: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 45332B51 for ; Mon, 23 Mar 2015 10:51:38 +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 048E164F for ; Mon, 23 Mar 2015 10:51:37 +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 1YZzx6-0003u3-4D for freebsd-fs@freebsd.org; Mon, 23 Mar 2015 11:51:29 +0100 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: 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> Date: Mon, 23 Mar 2015 11:51:23 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <550C938F.70500@gmail.com> 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: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.3.1 X-Scan-Signature: 9484ae446d4f83cee8bf28db5146d16c 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, 23 Mar 2015 10:51:38 -0000 On Fri, 20 Mar 2015 22:39:27 +0100, Motty Cruz wrote: > 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? As it hangs after a couple of days. Do you use 'deduplication' which uses more and more memory until your machine becomes unresponsive? Ronald. > > # 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 > > _______________________________________________ > 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 Mon Mar 23 12:32:36 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 2728AB83 for ; Mon, 23 Mar 2015 12:32:36 +0000 (UTC) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) (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 CA393231 for ; Mon, 23 Mar 2015 12:32:35 +0000 (UTC) Received: from [192.168.0.183] (laptop1.herveybayaustralia.com.au [192.168.0.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id 3D725620B4 for ; Mon, 23 Mar 2015 22:32:31 +1000 (EST) Message-ID: <551007DD.5020109@herveybayaustralia.com.au> Date: Mon, 23 Mar 2015 22:32:29 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: Delete a directory, crash the system 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, 23 Mar 2015 12:32:36 -0000 On 27/07/2013 22:58, David Noel wrote: >> Post the stack trace of the core and maybe someone can help you. > panic: ufs_dirrem: Bad link count 2 on parent > cpuid = 0 > KDB: stack backtrace: > #0 0xffffffff808680fe at kdb_backtrace+0x5e > #1 0xffffffff80832cb7 at panic+0x187 > #2 0xffffffff80a700e3 at ufs_rmdir+0x1c3 > #3 0xffffffff80b7d484 at VOP_RMDIR_APV+0x34 > #4 0xffffffff808ca32a at kern_rmdirat+0x21a > #5 0xffffffff80b17cf0 at amd64_syscall+0x450 > #6 0xffffffff80b03427 at Xfast_syscall+0xf7 I know this is an old one, but I'm running 10 and I'm still getting this problem. kernel: panic: ufs_dirrem: Bad link count 2 on parent kernel: cpuid = 1 kernel: KDB: stack backtrace: kernel: #0 0xffffffff808e7e90 at kdb_backtrace+0x60 kernel: #1 0xffffffff808af975 at panic+0x155 kernel: #2 0xffffffff80afe7d7 at ufs_rmdir+0x1d7 kernel: #3 0xffffffff80d994f8 at VOP_RMDIR_APV+0x98 kernel: #4 0xffffffff80952a68 at kern_rmdirat+0x1b8 kernel: #5 0xffffffff80c8f127 at amd64_syscall+0x357 kernel: #6 0xffffffff80c7581b at Xfast_syscall+0xfb kernel: Uptime: 2h36m59s Is there a fix or one in the works at all? This also not the first time I've had this issue crop up since I've been running 10. I am using ssd hdds if that helps. From owner-freebsd-fs@FreeBSD.ORG Mon Mar 23 14:55:18 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 BD2C9C12 for ; Mon, 23 Mar 2015 14:55:18 +0000 (UTC) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 49A50942 for ; Mon, 23 Mar 2015 14:55:17 +0000 (UTC) X-AuditID: 1209190f-f79d16d000000d3d-4a-55102820993c Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id E2.94.03389.02820155; Mon, 23 Mar 2015 10:50:09 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t2NEo83i028308; Mon, 23 Mar 2015 10:50:08 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2NEo5Jf025932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 23 Mar 2015 10:50:07 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t2NEo5In014604; Mon, 23 Mar 2015 10:50:05 -0400 (EDT) Date: Mon, 23 Mar 2015 10:50:05 -0400 (EDT) From: Benjamin Kaduk To: Da Rock Subject: Re: Delete a directory, crash the system In-Reply-To: <551007DD.5020109@herveybayaustralia.com.au> Message-ID: References: <551007DD.5020109@herveybayaustralia.com.au> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixCmqrKuoIRBq0LKLyeLY459sFt9/vmB2 YPKY8Wk+i8frjQvZA5iiuGxSUnMyy1KL9O0SuDL+7t3KXDCTt2LL3kdsDYw3uboYOTgkBEwk 1izK6GLkBDLFJC7cW8/WxcjFISSwmEni2JK37BDORkaJg2ePMkM4h5gklrS+YoJwGhglttw8 zwTSzyKgLbH0xRowm01ARWLmm41sILaIgJHE/CvPmUDWMQtISdxZWwESFhYwlFh3opEFxOYU sJSYsfkLM4jNK+Ao8eHPHkaI+ZOZJS7d3AdWJCqgI7F6/xQWiCJBiZMzn4DZzAJaEsunb2OZ wCg4C0lqFpLUAkamVYyyKblVurmJmTnFqcm6xcmJeXmpRbomermZJXqpKaWbGMGhKsm/g/Hb QaVDjAIcjEo8vBUB/KFCrIllxZW5hxglOZiURHk3qAmECvEl5adUZiQWZ8QXleakFh9ilOBg VhLhrQfJ8aYkVlalFuXDpKQ5WJTEeTf94AsREkhPLEnNTk0tSC2CycpwcChJ8PKrAzUKFqWm p1akZeaUIKSZODhBhvMADf8PNry4IDG3ODMdIn+KUVFKnPcnSEIAJJFRmgfXC0slrxjFgV4R 5tUGWcEDTENw3a+ABjMBDT6XzwcyuCQRISXVwJgr+Upt6RGNTywCiQYbVy4Kq9Ha/bR88uI3 EvW7mlknZR8vvrzZa+WHRQGCMs/zM1r0z4iohAf8vmf9O2zLh0sB2uoXX7sVv1YLPavD7HNF +8G91zVmR78x3eP+4c97XN8hyk8pdsflhdcWT7tcsOL+msNu1tFK7md2fv0hO8Mm/sekHWZR fX1KLMUZiYZazEXFiQDSLSVsAAMAAA== 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, 23 Mar 2015 14:55:18 -0000 On Mon, 23 Mar 2015, Da Rock wrote: > On 27/07/2013 22:58, David Noel wrote: > > > Post the stack trace of the core and maybe someone can help you. > > panic: ufs_dirrem: Bad link count 2 on parent > > cpuid = 0 > > KDB: stack backtrace: > > #0 0xffffffff808680fe at kdb_backtrace+0x5e > > #1 0xffffffff80832cb7 at panic+0x187 > > #2 0xffffffff80a700e3 at ufs_rmdir+0x1c3 > > #3 0xffffffff80b7d484 at VOP_RMDIR_APV+0x34 > > #4 0xffffffff808ca32a at kern_rmdirat+0x21a > > #5 0xffffffff80b17cf0 at amd64_syscall+0x450 > > #6 0xffffffff80b03427 at Xfast_syscall+0xf7 > I know this is an old one, but I'm running 10 and I'm still getting this > problem. > > kernel: panic: ufs_dirrem: Bad link count 2 on parent > kernel: cpuid = 1 > kernel: KDB: stack backtrace: > kernel: #0 0xffffffff808e7e90 at kdb_backtrace+0x60 > kernel: #1 0xffffffff808af975 at panic+0x155 > kernel: #2 0xffffffff80afe7d7 at ufs_rmdir+0x1d7 > kernel: #3 0xffffffff80d994f8 at VOP_RMDIR_APV+0x98 > kernel: #4 0xffffffff80952a68 at kern_rmdirat+0x1b8 > kernel: #5 0xffffffff80c8f127 at amd64_syscall+0x357 > kernel: #6 0xffffffff80c7581b at Xfast_syscall+0xfb > kernel: Uptime: 2h36m59s > > Is there a fix or one in the works at all? This also not the first time I've > had this issue crop up since I've been running 10. I am using ssd hdds if that > helps. I don't think there can be a fix in the works until the problem is understood. Given the present data (i.e., lack of other reports), the most likely explanation seems to be that your filesystem is corrupt or your SSD is buggy. A full foreground fsck may be helpful at detecting latent corruption, though. -Ben Kaduk From owner-freebsd-fs@FreeBSD.ORG Tue Mar 24 01:10:57 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 BBC4D9EF for ; Tue, 24 Mar 2015 01:10:57 +0000 (UTC) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) (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 692DBC6E for ; Tue, 24 Mar 2015 01:10:56 +0000 (UTC) Received: from [192.168.0.183] (laptop1.herveybayaustralia.com.au [192.168.0.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id 81951620A6; Tue, 24 Mar 2015 11:10:46 +1000 (EST) Message-ID: <5510B995.8060307@herveybayaustralia.com.au> Date: Tue, 24 Mar 2015 11:10:45 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Benjamin Kaduk Subject: Re: Delete a directory, crash the system References: <551007DD.5020109@herveybayaustralia.com.au> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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, 24 Mar 2015 01:10:57 -0000 On 24/03/2015 00:50, Benjamin Kaduk wrote: > On Mon, 23 Mar 2015, Da Rock wrote: > >> On 27/07/2013 22:58, David Noel wrote: >>>> Post the stack trace of the core and maybe someone can help you. >>> panic: ufs_dirrem: Bad link count 2 on parent >>> cpuid = 0 >>> KDB: stack backtrace: >>> #0 0xffffffff808680fe at kdb_backtrace+0x5e >>> #1 0xffffffff80832cb7 at panic+0x187 >>> #2 0xffffffff80a700e3 at ufs_rmdir+0x1c3 >>> #3 0xffffffff80b7d484 at VOP_RMDIR_APV+0x34 >>> #4 0xffffffff808ca32a at kern_rmdirat+0x21a >>> #5 0xffffffff80b17cf0 at amd64_syscall+0x450 >>> #6 0xffffffff80b03427 at Xfast_syscall+0xf7 >> I know this is an old one, but I'm running 10 and I'm still getting this >> problem. >> >> kernel: panic: ufs_dirrem: Bad link count 2 on parent >> kernel: cpuid = 1 >> kernel: KDB: stack backtrace: >> kernel: #0 0xffffffff808e7e90 at kdb_backtrace+0x60 >> kernel: #1 0xffffffff808af975 at panic+0x155 >> kernel: #2 0xffffffff80afe7d7 at ufs_rmdir+0x1d7 >> kernel: #3 0xffffffff80d994f8 at VOP_RMDIR_APV+0x98 >> kernel: #4 0xffffffff80952a68 at kern_rmdirat+0x1b8 >> kernel: #5 0xffffffff80c8f127 at amd64_syscall+0x357 >> kernel: #6 0xffffffff80c7581b at Xfast_syscall+0xfb >> kernel: Uptime: 2h36m59s >> >> Is there a fix or one in the works at all? This also not the first time I've >> had this issue crop up since I've been running 10. I am using ssd hdds if that >> helps. > I don't think there can be a fix in the works until the problem is > understood. Given the present data (i.e., lack of other reports), the > most likely explanation seems to be that your filesystem is corrupt or > your SSD is buggy. A full foreground fsck may be helpful at detecting > latent corruption, though. > > -Ben Kaduk Unfortunately, fsck isn't helping - foreground or otherwise. All it shows on every single fs is inode 4 recovery which doesn't sound quite right. And again, it is only showing during updates to ports being built. I'm investigating further, but it may be just a corrupt file in pkg system. Incidentally, I'm not suggesting an absolute fix for the issue as such, but a better means of handling it rather than crashing the system. The posts on this I've read have suggested as much, but it appears nothing is moving forward. If I discover anything more I'll keep everyone posted :) From owner-freebsd-fs@FreeBSD.ORG Tue Mar 24 09:21: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 27E18485 for ; Tue, 24 Mar 2015 09:21: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 0E4EF6CB for ; Tue, 24 Mar 2015 09:21:18 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2O9LHuI010246 for ; Tue, 24 Mar 2015 09:21:17 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: Tue, 24 Mar 2015 09:21:18 +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: 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, 24 Mar 2015 09:21:18 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198731 --- Comment #6 from Arrigo Marchiori --- (In reply to Pedro F. Giffuni from comment #5) Ciao Pedro, I confirm that disabling the dir_index feature seems to solve the problem. Removing the feature also seems a good idea to me, if it is not a strict requirement for fs compatibility. On the other hand, in case you wish to investigate and debug the problem in the future, feel free to contact me if you think I can be of any help. I leave the choice to you, whether to mark this bug duplicate of bug #191895 or not. Thank you for your time. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Tue Mar 24 11:23:36 2015 Return-Path: Delivered-To: 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 CB863BC3 for ; Tue, 24 Mar 2015 11:23:36 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (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 376EB8A7 for ; Tue, 24 Mar 2015 11:23:36 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id E5BDE16A402 for ; Tue, 24 Mar 2015 12:23:30 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fskDVKxqNZl; Tue, 24 Mar 2015 12:23:19 +0100 (CET) Received: from [192.168.101.198] (unknown [192.168.101.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 76CBD16A405 for ; Tue, 24 Mar 2015 12:23:19 +0100 (CET) Message-ID: <5511492A.5020408@digiware.nl> Date: Tue, 24 Mar 2015 12:23:22 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: fs@freebsd.org Subject: Re: Missing some ZFS values in sysctl output References: <550F45CA.5000302@digiware.nl> In-Reply-To: <550F45CA.5000302@digiware.nl> Content-Type: text/plain; charset=windows-1252 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: Tue, 24 Mar 2015 11:23:36 -0000 On 22-3-2015 23:44, Willem Jan Withagen wrote: > Hoi, > > There is this zfs-snmp script that allows one the graph certain things > from a ZFS setup. > The original uses solaris' kstat, but just about all values are in > Sysctl with FreeBSD. > > However I seem to overlook the values for: > > Original code: > ==== > def zfs_read(oid): > return ('counter', kstat("unix:0:vopstats_zfs:read_bytes") / 1024 % > 2**32) # 32 bit KB counter > > def zfs_readdir(oid): > return ('counter', kstat("unix:0:vopstats_zfs:readdir_bytes") / 1024 > % 2**32) # 32 bit KB counter > > def zfs_write(oid): > return ('counter', kstat("unix:0:vopstats_zfs:write_bytes") / 1024 % > 2**32) # 32 bit KB counter > ======= > > Read and write are available for L2 arc, but for the global values I > seem to miss them. > > Are they really not in ZFS? > And is it possible to add them? Right, Just to answer my own question.... I looked into the illumos code, and it looks like the vopstats are stats that are kept per filesystem-type on solaris, and these are the ZFS variants.... typedef struct vopstats { kstat_named_t nopen; /* VOP_OPEN */ kstat_named_t nclose; /* VOP_CLOSE */ kstat_named_t nread; /* VOP_READ */ kstat_named_t read_bytes; kstat_named_t nwrite; /* VOP_WRITE */ kstat_named_t write_bytes; kstat_named_t nioctl; /* VOP_IOCTL */ kstat_named_t nsetfl; /* VOP_SETFL */ kstat_named_t ngetattr; /* VOP_GETATTR */ kstat_named_t nsetattr; /* VOP_SETATTR */ kstat_named_t naccess; /* VOP_ACCESS */ kstat_named_t nlookup; /* VOP_LOOKUP */ kstat_named_t ncreate; /* VOP_CREATE */ kstat_named_t nremove; /* VOP_REMOVE */ kstat_named_t nlink; /* VOP_LINK */ kstat_named_t nrename; /* VOP_RENAME */ kstat_named_t nmkdir; /* VOP_MKDIR */ kstat_named_t nrmdir; /* VOP_RMDIR */ kstat_named_t nreaddir; /* VOP_READDIR */ kstat_named_t readdir_bytes; kstat_named_t nsymlink; /* VOP_SYMLINK */ kstat_named_t nreadlink; /* VOP_READLINK */ kstat_named_t nfsync; /* VOP_FSYNC */ kstat_named_t ninactive; /* VOP_INACTIVE */ kstat_named_t nfid; /* VOP_FID */ kstat_named_t nrwlock; /* VOP_RWLOCK */ kstat_named_t nrwunlock; /* VOP_RWUNLOCK */ kstat_named_t nseek; /* VOP_SEEK */ kstat_named_t ncmp; /* VOP_CMP */ kstat_named_t nfrlock; /* VOP_FRLOCK */ kstat_named_t nspace; /* VOP_SPACE */ kstat_named_t nrealvp; /* VOP_REALVP */ kstat_named_t ngetpage; /* VOP_GETPAGE */ kstat_named_t nputpage; /* VOP_PUTPAGE */ kstat_named_t nmap; /* VOP_MAP */ kstat_named_t naddmap; /* VOP_ADDMAP */ kstat_named_t ndelmap; /* VOP_DELMAP */ kstat_named_t npoll; /* VOP_POLL */ kstat_named_t ndump; /* VOP_DUMP */ kstat_named_t npathconf; /* VOP_PATHCONF */ kstat_named_t npageio; /* VOP_PAGEIO */ kstat_named_t ndumpctl; /* VOP_DUMPCTL */ kstat_named_t ndispose; /* VOP_DISPOSE */ kstat_named_t nsetsecattr; /* VOP_SETSECATTR */ kstat_named_t ngetsecattr; /* VOP_GETSECATTR */ kstat_named_t nshrlock; /* VOP_SHRLOCK */ kstat_named_t nvnevent; /* VOP_VNEVENT */ kstat_named_t nreqzcbuf; /* VOP_REQZCBUF */ kstat_named_t nretzcbuf; /* VOP_RETZCBUF */ } vopstats_t; As far as I can tell we do not have these structures in vnode.{c,h} and as such do not keep tracks of these statistics. Nothing equal to this jumps out from the sysctl-tree. But I happily stand corrected. Tinkering this in just the ZFS code would be a serious undertaking. At least for me. And all this just to some snmp-stats. --WjW From owner-freebsd-fs@FreeBSD.ORG Tue Mar 24 12:47: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 670124BB; Tue, 24 Mar 2015 12:47:59 +0000 (UTC) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (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 0404514E; Tue, 24 Mar 2015 12:47:59 +0000 (UTC) Received: by labe2 with SMTP id e2so83046273lab.3; Tue, 24 Mar 2015 05:47:57 -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=565uwVTFgxeSridYSjb0oWSFVtBcCGFO8eQQNF+PswM=; b=YWvGzBhHlGJfAO8WN/mYpGhpU47XbBW+nnBCu5WaP2evkR1VfXeRW8sc/lwVrFrENn AqIRu9+Ht6XU2KxygwFpOvFfDsNJ58HBsdNCmIbUeWZkUHNKtTHmglZ+iTuMVNfoMuzA hQcMdF6yWwu5DU0WU9jwrY/g471OeKW8zRb3p1+bodgpoH34cz+tv8dpAnFK1ULMKf3C G7RIJb9JGB6W/r56ikPzo5AX88aGmvgFUFQqt3Wdny0F8Et8HsmQC9un+Ldp1r3xGO8j UKEKc6gfy6uR0C7KbS0t+qyfZj8ig8j83NbWftqx44cHuM2nWRDEho85FLcxQlJqKRXQ dSUQ== MIME-Version: 1.0 X-Received: by 10.152.5.225 with SMTP id v1mr3586964lav.76.1427201277103; Tue, 24 Mar 2015 05:47:57 -0700 (PDT) Received: by 10.25.24.161 with HTTP; Tue, 24 Mar 2015 05:47:57 -0700 (PDT) In-Reply-To: References: Date: Tue, 24 Mar 2015 18:17:57 +0530 Message-ID: Subject: Re: Zoned Commands ZBC/ZAC, Shingled SMR drives, ZFS From: Shehbaz Jaffer To: grarpamp Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-fs@freebsd.org, freebsd-hardware@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, 24 Mar 2015 12:47:59 -0000 Hi, I was wondering what cost advantage do SMR drive provide as compared to normal CMR drive? 8TB SMR drive - $ 260 3TB CMR (Conventional Magnetic Recording drive) - $ 105 Is the 8TB SMR drive that you mentioned in another post on this mailing list host or drive managed? I was curious to know why freeBSD community /others should invest into supporting SMR drive? Is the price predicted to go down further in the future? Is there any other advantage that SMR drive provide that CMR drives dont? Thanks! On Fri, Mar 13, 2015 at 2:49 AM, grarpamp wrote: > Here is a performance review of the ST8000AS0002 non-SED > "drive managed" model (caveat your actual expected usage). > http://www.storagereview.com/seagate_archive_hdd_review_8tb > You can also find these drives inside the STDT8000100 external > USB unit for a bit more at $300. > _______________________________________________ > 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" > -- Shehbaz Jaffer MTS | Advanced Technology Group | NetApp From owner-freebsd-fs@FreeBSD.ORG Tue Mar 24 14:21:43 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 C74FA345 for ; Tue, 24 Mar 2015 14:21:43 +0000 (UTC) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 69CB7EA2 for ; Tue, 24 Mar 2015 14:21:42 +0000 (UTC) X-AuditID: 1209190e-f79a76d000000d1b-4a-551171c25d96 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id FD.E6.03355.2C171155; Tue, 24 Mar 2015 10:16:34 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t2OEGX5d017675; Tue, 24 Mar 2015 10:16:34 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2OEGU1t023778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Mar 2015 10:16:32 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t2OEGU3p025118; Tue, 24 Mar 2015 10:16:30 -0400 (EDT) Date: Tue, 24 Mar 2015 10:16:30 -0400 (EDT) From: Benjamin Kaduk To: Da Rock Subject: Re: Delete a directory, crash the system In-Reply-To: <5510B995.8060307@herveybayaustralia.com.au> Message-ID: References: <551007DD.5020109@herveybayaustralia.com.au> <5510B995.8060307@herveybayaustralia.com.au> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixCmqrXuoUDDUYEmLvMWxxz/ZLL7/fMHs wOQx49N8Fo/XGxeyBzBFcdmkpOZklqUW6dslcGVs+vKOteAJe8Wsaz9ZGhh72boYOTkkBEwk tty7xwRhi0lcuLceKM7FISSwmElixYSdjBDORkaJOdNmsIBUCQkcYpL4c0EQItHAKPH61kWw USwC2hKNX96yg9hsAioSM99sBIuLCBhJzL/yHGgFBwezgJTEnbUVIGFhAUOJdScawWZyClhK zJjzH8zmFXCUaFnRxwQx/xuzxLQp/xhBEqICOhKr90+BKhKUODnzCZjNLKAlsXz6NpYJjIKz kKRmIUktYGRaxSibklulm5uYmVOcmqxbnJyYl5dapGusl5tZopeaUrqJERyqknw7GL8eVDrE KMDBqMTDG7BEIFSINbGsuDL3EKMkB5OSKO90J8FQIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8 wipAOd6UxMqq1KJ8mJQ0B4uSOO+mH3whQgLpiSWp2ampBalFMFkZDg4lCV7+AqBGwaLU9NSK tMycEoQ0EwcnyHAeoOHpIDW8xQWJucWZ6RD5U4y6HHem/F/EJMSSl5+XKiXOKwBSJABSlFGa BzcHlmJeMYoDvSUMNASoigeYnuAmvQJawgS05Fw+H8iSkkSElFQDY+VR+5Bvv6RlSs9IK1/i 9X68qmX6e44p+3+87Xlso6N7+se1S/PmnKm/VGLzZB1H2NF14s6tARmXo//O+GHzoeKD2aXO FAGmxja7tR4XNG7KT9p95Mkh5xrj7/7XS/lkHZqi5nrUp7I1Bto+YNW7ypehzbCPK7u69ve0 12mrjobn5uzwkD3EoMRSnJFoqMVcVJwIAHm1gkwMAwAA 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, 24 Mar 2015 14:21:44 -0000 On Mon, 23 Mar 2015, Da Rock wrote: > Unfortunately, fsck isn't helping - foreground or otherwise. All it shows on > every single fs is inode 4 recovery which doesn't sound quite right. And Have you posted the exact output in a previous message (could you send a link)? > again, it is only showing during updates to ports being built. I'm Er, what is only showing up? The panics? Surely you are not only running fsck while building ports... > investigating further, but it may be just a corrupt file in pkg system. > > Incidentally, I'm not suggesting an absolute fix for the issue as such, but a > better means of handling it rather than crashing the system. The posts on this Understood. But, there will always be some types of error which are truly unrecoverable, and there is no real option other than to panic. (Which is not to say that your situation is necessarily one of them.) > If I discover anything more I'll keep everyone posted :) Thanks, Ben From owner-freebsd-fs@FreeBSD.ORG Tue Mar 24 16:39:10 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 E7D66AD6; Tue, 24 Mar 2015 16:39:10 +0000 (UTC) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::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 BD19514B; Tue, 24 Mar 2015 16:39:10 +0000 (UTC) Received: by igcxg11 with SMTP id xg11so2457566igc.0; Tue, 24 Mar 2015 09:39:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hi8pnwP+E9NouwOQ7VfOhnIKniyZXAfHati/05gcF2Y=; b=w413WuaYx5zqIZ86zXT21cEW9ohurug1BtD6Js6OHO/MmhkgaMyQ/G7HCrSqfoOkfL vlwQnZCbDvuu+QS76LMnBeMSQwB9jDtEl0QguyOJNYEGECHlowJGTk7M6MqpBst2Vlfi 0drzKChOYM4uYQiCgMfIjoNIts+liZtufvkdQAMc+oe+bU/Rs2613J3FFEmHtv0cjzEJ 6KtYsO1HhJtlATDLO42UrGHD7M/eSV4ajm0SHJ92cFVT2t2cBV6gf/8MXlc2m+ZGGMyb 0eQfx66iGK/jkiWgX6qHDPaqUhAFY4m5Un5lKW33Q1IaVSwjxaQQDiBS7G/MzgZ2n2Sf krjw== MIME-Version: 1.0 X-Received: by 10.107.12.150 with SMTP id 22mr7694507iom.71.1427215150085; Tue, 24 Mar 2015 09:39:10 -0700 (PDT) Received: by 10.107.132.85 with HTTP; Tue, 24 Mar 2015 09:39:09 -0700 (PDT) In-Reply-To: References: Date: Tue, 24 Mar 2015 16:39:09 +0000 Message-ID: Subject: Re: Zoned Commands ZBC/ZAC, Shingled SMR drives, ZFS From: Tom Evans To: Shehbaz Jaffer Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD FS , grarpamp , freebsd-hardware@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, 24 Mar 2015 16:39:11 -0000 On Tue, Mar 24, 2015 at 12:47 PM, Shehbaz Jaffer wrote: > Hi, > > I was wondering what cost advantage do SMR drive provide as compared to > normal CMR drive? > > 8TB SMR drive - $ 260 > 3TB CMR (Conventional Magnetic Recording drive) - $ 105 > Purchase price is not irrelevant, but the key benefits are increased capacity per disk, and reduced power usage per disk and (multiplied by the increase in capacity) per TB. In other words, they disks consume less power, you need fewer of them, maybe allowing you to run fewer servers. Of course, you also need a mainly read only workload. The RAID rebuild test from the linked review is *scary*. I wouldn't use these in ZFS raidz without plenty of disaster recovery testing - how long does it take to re-silver the pool when you lose a disk and what is the performance characteristics of the pool whilst it is doing so. Cheers Tom From owner-freebsd-fs@FreeBSD.ORG Tue Mar 24 17:11: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 D96AFB9A; Tue, 24 Mar 2015 17:11:01 +0000 (UTC) Received: from smtp.libraryvideo.com (smtp.libraryvideo.com [144.202.216.43]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A0289839; Tue, 24 Mar 2015 17:11:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.libraryvideo.com (Postfix) with ESMTP id 55E3722F349; Tue, 24 Mar 2015 13:05:49 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at libraryvideo.com Received: from smtp.libraryvideo.com ([127.0.0.1]) by localhost (smtp.libraryvideo.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id SqYA46JtexQ0; Tue, 24 Mar 2015 13:05:45 -0400 (EDT) Received: from heimdall.safarimontage.com (heimdall.safarimontage.com [172.20.10.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.libraryvideo.com (Postfix) with ESMTPS id 20EF435F3CB; Tue, 24 Mar 2015 13:05:45 -0400 (EDT) Received: from VALKYRIE.lvc.com (172.20.1.74) by heimdall.safarimontage.com (172.20.10.21) with Microsoft SMTP Server (TLS) id 14.0.722.0; Tue, 24 Mar 2015 13:05:44 -0400 Received: from LOKI.lvc.com ([fe80::d5b5:77e5:625d:d205]) by valkyrie.lvc.com ([fe80::716a:53e0:bf7d:632f%10]) with mapi id 14.02.0328.009; Tue, 24 Mar 2015 13:05:45 -0400 From: Dale Kline To: 'Tom Evans' , Shehbaz Jaffer Subject: RE: Zoned Commands ZBC/ZAC, Shingled SMR drives, ZFS Thread-Topic: Zoned Commands ZBC/ZAC, Shingled SMR drives, ZFS Thread-Index: AQHQXQo064rMisN8t0yr6P74JAyzDJ0r6nqAgABAmYD//8NzkA== Date: Tue, 24 Mar 2015 17:05:45 +0000 Message-ID: <02F3A553C174554DA1D5EC7CEE9BDDD7011BC3E42B@loki.lvc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.1.113] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: FreeBSD FS , grarpamp , "freebsd-hardware@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, 24 Mar 2015 17:11:02 -0000 READ THE DOCUMENTATION THOROUGHLY on these SMR drives. There are serious = WRITE restrictions on these drives because of the overlapping (shingled) tr= acks. I have read over several times and am still not sure of all of the c= aveats. As Tom states below, they are to be used mainly in "WRITE ONCE, = READ MANY" environments. -----Original Message----- From: owner-freebsd-hardware@freebsd.org [mailto:owner-freebsd-hardware@fre= ebsd.org] On Behalf Of Tom Evans Sent: Tuesday, March 24, 2015 12:39 PM To: Shehbaz Jaffer Cc: FreeBSD FS; grarpamp; freebsd-hardware@freebsd.org Subject: Re: Zoned Commands ZBC/ZAC, Shingled SMR drives, ZFS On Tue, Mar 24, 2015 at 12:47 PM, Shehbaz Jaffer wrote: > Hi, > > I was wondering what cost advantage do SMR drive provide as compared=20 > to normal CMR drive? > > 8TB SMR drive - $ 260 > 3TB CMR (Conventional Magnetic Recording drive) - $ 105 > Purchase price is not irrelevant, but the key benefits are increased capaci= ty per disk, and reduced power usage per disk and (multiplied by the increa= se in capacity) per TB. In other words, they disks consume less power, you = need fewer of them, maybe allowing you to run fewer servers. Of course, you also need a mainly read only workload. The RAID rebuild test= from the linked review is *scary*. I wouldn't use these in ZFS raidz witho= ut plenty of disaster recovery testing - how long does it take to re-silver= the pool when you lose a disk and what is the performance characteristics = of the pool whilst it is doing so. Cheers Tom _______________________________________________ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/= listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Tue Mar 24 17:49:58 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 9C383972; Tue, 24 Mar 2015 17:49:58 +0000 (UTC) Received: from mx1.internetx.com (mx1.internetx.com [62.116.129.39]) by mx1.freebsd.org (Postfix) with ESMTP id 51FC7C65; Tue, 24 Mar 2015 17:49:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mx1.internetx.com (Postfix) with ESMTP id E18E51472008; Tue, 24 Mar 2015 18:42:31 +0100 (CET) X-Virus-Scanned: InterNetX GmbH amavisd-new at ix-mailer.internetx.de Received: from mx1.internetx.com ([62.116.129.39]) by localhost (ix-mailer.internetx.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Y+3ZjW-9Z1m; Tue, 24 Mar 2015 18:42:29 +0100 (CET) Received: from [192.168.100.26] (pizza.internetx.de [62.116.129.3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.internetx.com (Postfix) with ESMTPSA id 931E51472001; Tue, 24 Mar 2015 18:42:29 +0100 (CET) Message-ID: <5511A204.7020705@internetx.com> Date: Tue, 24 Mar 2015 18:42:28 +0100 From: InterNetX - Juergen Gotteswinter Reply-To: jg@internetx.com User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: FreeBSD FS , "freebsd-hardware@freebsd.org" Subject: Re: Zoned Commands ZBC/ZAC, Shingled SMR drives, ZFS References: <02F3A553C174554DA1D5EC7CEE9BDDD7011BC3E42B@loki.lvc.com> In-Reply-To: <02F3A553C174554DA1D5EC7CEE9BDDD7011BC3E42B@loki.lvc.com> Content-Type: text/plain; charset=windows-1252 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: Tue, 24 Mar 2015 17:49:58 -0000 The HGST He8 HDDs completed its rebuild in 19 hours and 46 minutes. The Seagate Archive HDDs completed their rebuild in 57 hours and 13 minutes this is ... a feature. right? Am 24.03.2015 um 18:05 schrieb Dale Kline: > READ THE DOCUMENTATION THOROUGHLY on these SMR drives. There are serious WRITE restrictions on these drives because of the overlapping (shingled) tracks. I have read over several times and am still not sure of all of the caveats. As Tom states below, they are to be used mainly in "WRITE ONCE, READ MANY" environments. > > -----Original Message----- > From: owner-freebsd-hardware@freebsd.org [mailto:owner-freebsd-hardware@freebsd.org] On Behalf Of Tom Evans > Sent: Tuesday, March 24, 2015 12:39 PM > To: Shehbaz Jaffer > Cc: FreeBSD FS; grarpamp; freebsd-hardware@freebsd.org > Subject: Re: Zoned Commands ZBC/ZAC, Shingled SMR drives, ZFS > > On Tue, Mar 24, 2015 at 12:47 PM, Shehbaz Jaffer wrote: >> Hi, >> >> I was wondering what cost advantage do SMR drive provide as compared >> to normal CMR drive? >> >> 8TB SMR drive - $ 260 >> 3TB CMR (Conventional Magnetic Recording drive) - $ 105 >> > > Purchase price is not irrelevant, but the key benefits are increased capacity per disk, and reduced power usage per disk and (multiplied by the increase in capacity) per TB. In other words, they disks consume less power, you need fewer of them, maybe allowing you to run fewer servers. > > Of course, you also need a mainly read only workload. The RAID rebuild test from the linked review is *scary*. I wouldn't use these in ZFS raidz without plenty of disaster recovery testing - how long does it take to re-silver the pool when you lose a disk and what is the performance characteristics of the pool whilst it is doing so. > > Cheers > > Tom > _______________________________________________ > freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware > To unsubscribe, send any mail to "freebsd-hardware-unsubscribe@freebsd.org" > _______________________________________________ > 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 24 18: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 DB825466; Tue, 24 Mar 2015 18:39:55 +0000 (UTC) Received: from mx2.paymentallianceintl.com (mx2.paymentallianceintl.com [216.26.158.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx2.paymentallianceintl.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9D92D306; Tue, 24 Mar 2015 18:39:55 +0000 (UTC) Received: from PAIMAIL.pai.local (paimail.pai.local [10.10.0.153]) by mx2.paymentallianceintl.com (8.15.1/8.15.1) with ESMTPS id t2OIDBCl096129 (version=TLSv1 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 24 Mar 2015 14:13:12 -0400 (EDT) (envelope-from mikej@paymentallianceintl.com) Received: from PAIMAILDR.pai.local (10.10.0.152) by PAIMAIL.pai.local (10.10.0.153) with Microsoft SMTP Server (TLS) id 8.3.389.2; Tue, 24 Mar 2015 14:13:11 -0400 Received: from PAIMAIL.pai.local ([::1]) by PAIMAILDR.pai.local ([fe80::35a4:605f:51ed:a2d6%16]) with mapi; Tue, 24 Mar 2015 14:13:11 -0400 From: Michael Jung To: "jg@internetx.com" , FreeBSD FS , "freebsd-hardware@freebsd.org" Date: Tue, 24 Mar 2015 14:13:10 -0400 Subject: RE: Zoned Commands ZBC/ZAC, Shingled SMR drives, ZFS Thread-Topic: Zoned Commands ZBC/ZAC, Shingled SMR drives, ZFS Thread-Index: AdBmWwGQRs1X7LpzTVmOB7fdF9smMQAAssjw Message-ID: <9C91F97841BC4347910F206618BAA3BB096D453FB6@PAIMAIL.pai.local> References: <02F3A553C174554DA1D5EC7CEE9BDDD7011BC3E42B@loki.lvc.com> <5511A204.7020705@internetx.com> In-Reply-To: <5511A204.7020705@internetx.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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, 24 Mar 2015 18:39:56 -0000 I understand there to be three different types of SMR drives: Device manage= d, Host aware and Host managed.=20 It is my belief that only 'Device managed' drives are shipping which any file system can use, but the file system has no mechanisms to=20 leverage or control the drives behavior hence they are not good candidates= =20 for any RAID like system. 'host aware' or 'host managed' SMR drives open the real possibilities for u= se under ZFS and other file systems. =20 I found these links of interest. Tim Feldman - Host-Aware SMR - OpenZFS Dev Summit 2014 https://www.youtube.com/watch?v=3Db1yqjV8qemU http://open-zfs.org/w/images/2/2a/Host-Aware_SMR-Tim_Feldman.pdf http://www.snia.org/sites/default/files/Dunn-Feldman_SNIA_Tutorial_Shingled= _Magnetic_Recording-r7_Final.pdf --mikej -----Original Message----- From: owner-freebsd-fs@freebsd.org [mailto:owner-freebsd-fs@freebsd.org] On= Behalf Of InterNetX - Juergen Gotteswinter Sent: Tuesday, March 24, 2015 1:42 PM To: FreeBSD FS; freebsd-hardware@freebsd.org Subject: Re: Zoned Commands ZBC/ZAC, Shingled SMR drives, ZFS The HGST He8 HDDs completed its rebuild in 19 hours and 46 minutes. The Seagate Archive HDDs completed their rebuild in 57 hours and 13 minutes this is ... a feature. right? Am 24.03.2015 um 18:05 schrieb Dale Kline: > READ THE DOCUMENTATION THOROUGHLY on these SMR drives. There are seriou= s WRITE restrictions on these drives because of the overlapping (shingled) = tracks. I have read over several times and am still not sure of all of the= caveats. As Tom states below, they are to be used mainly in "WRITE ONCE,= READ MANY" environments. >=20 > -----Original Message----- > From: owner-freebsd-hardware@freebsd.org [mailto:owner-freebsd-hardware@f= reebsd.org] On Behalf Of Tom Evans > Sent: Tuesday, March 24, 2015 12:39 PM > To: Shehbaz Jaffer > Cc: FreeBSD FS; grarpamp; freebsd-hardware@freebsd.org > Subject: Re: Zoned Commands ZBC/ZAC, Shingled SMR drives, ZFS >=20 > On Tue, Mar 24, 2015 at 12:47 PM, Shehbaz Jaffer wrote: >> Hi, >> >> I was wondering what cost advantage do SMR drive provide as compared=20 >> to normal CMR drive? >> >> 8TB SMR drive - $ 260 >> 3TB CMR (Conventional Magnetic Recording drive) - $ 105 >> >=20 > Purchase price is not irrelevant, but the key benefits are increased capa= city per disk, and reduced power usage per disk and (multiplied by the incr= ease in capacity) per TB. In other words, they disks consume less power, yo= u need fewer of them, maybe allowing you to run fewer servers. >=20 > Of course, you also need a mainly read only workload. The RAID rebuild te= st from the linked review is *scary*. I wouldn't use these in ZFS raidz wit= hout plenty of disaster recovery testing - how long does it take to re-silv= er the pool when you lose a disk and what is the performance characteristic= s of the pool whilst it is doing so. >=20 > Cheers >=20 > Tom > _______________________________________________ > freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailma= n/listinfo/freebsd-hardware > To unsubscribe, send any mail to "freebsd-hardware-unsubscribe@freebsd.or= g" > _______________________________________________ > 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" >=20 _______________________________________________ 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" =0A= GoPai.com | Facebook.com/PaymentAlliance =20 CONFIDENTIALITY NOTE: This message is intended only for the use of the individual or entity to whom it is addressed and may=20 contain information that is privileged, confidential, and=20 exempt from disclosure under applicable law. If the reader=20 of this message is not the intended recipient, you are hereby=20 notified that any dissemination, distribution or copying=20 of this communication is strictly prohibited. If you have=20 received this transmission in error, please notify us by=20 telephone at (502) 212-4001 or notify us at PAI , Dept. 99,=20 6060 Dutchmans Lane, Suite 320, Louisville, KY 40205 From owner-freebsd-fs@FreeBSD.ORG Tue Mar 24 18:42:57 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 E432C5E0; Tue, 24 Mar 2015 18:42:57 +0000 (UTC) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (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 5FE593E9; Tue, 24 Mar 2015 18:42:57 +0000 (UTC) Received: by labto5 with SMTP id to5so1506144lab.0; Tue, 24 Mar 2015 11:42:55 -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=TY0C2Xx0HM1qbvMwUs+jukvesqds5EE0yq931hz4dsQ=; b=LyEfDLNn+Cx96/GF+z9l43w/EtQQRZvPqYlJZ0GVwO88Dz/s7XwfTpN+cIbPGoWOmr RLclw9LOiqrzwX+w5uPnzvSW/z0fy8BXsBzxA7KKUUwKdOCoBPbwWJtZ5vNopmH2KAnU 0FfEhZedZuR5SwKePJxjLQqo2k2DMOS1s/+uaMHsPAjMdaKQi/9/yNimYmRC2MbpYF8x P1Y1bmfz0GMFjyZJoNAtMVyaUI2LbIs/DUpiMlLu+yW4uzQ8Syx7MtjsIzTyvZRyS7tp kU9f2w2tZ0clVrVHyNG9GwfBxtHTb1icOko8wFB4g1fVGO50Zub3aAcaM+9og41gm+1J shUA== MIME-Version: 1.0 X-Received: by 10.112.85.10 with SMTP id d10mr2572926lbz.62.1427222575349; Tue, 24 Mar 2015 11:42:55 -0700 (PDT) Received: by 10.25.24.161 with HTTP; Tue, 24 Mar 2015 11:42:55 -0700 (PDT) In-Reply-To: <9C91F97841BC4347910F206618BAA3BB096D453FB6@PAIMAIL.pai.local> References: <02F3A553C174554DA1D5EC7CEE9BDDD7011BC3E42B@loki.lvc.com> <5511A204.7020705@internetx.com> <9C91F97841BC4347910F206618BAA3BB096D453FB6@PAIMAIL.pai.local> Date: Wed, 25 Mar 2015 00:12:55 +0530 Message-ID: Subject: Re: Zoned Commands ZBC/ZAC, Shingled SMR drives, ZFS From: Shehbaz Jaffer To: Michael Jung Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD FS , "freebsd-hardware@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, 24 Mar 2015 18:42:58 -0000 > 'host aware' or 'host managed' SMR drives open the real possibilities for use under ZFS and other file systems. Agreed. Probably RAID is not the way to go then. In host managed SMR drives one could use other form of resiliency (Erasure Codes) rather than RAID. We do not rebuild the whole disk but probably just a zone of a SMR drive in case of errors. From owner-freebsd-fs@FreeBSD.ORG Tue Mar 24 20:04:39 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 A764D42E for ; Tue, 24 Mar 2015 20:04:39 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8D01BECF for ; Tue, 24 Mar 2015 20:04:39 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [12.229.62.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 937C1E3C5; Tue, 24 Mar 2015 13:04:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1427227473; x=1427241873; bh=08hzttS+LQhexw2DTvT6cXo15b5dZDwDLnOcKCW2eLI=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=X6cZavaF+oD+GDNGTTJY5dUk0Yl0sEMS7LjK9emMXEvUrQBBu7n6YWNFdHpakcH3i oAbQPiXqqHMYTGCN4hxvLdyox+XTnFzOynN9I20Ccw4U8sBVU3zQfUgGRdDRS3bPNn 4Or1s9coooZaK9GraxZdEbFXv4An5Aii3dzrg21A= Message-ID: <5511C351.2020107@delphij.net> Date: Tue, 24 Mar 2015 13:04:33 -0700 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: Zaphod Beeblebrox , freebsd-fs Subject: Re: What does it mean when zdb -R x:xxx:xxx:g crashes? References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 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: Tue, 24 Mar 2015 20:04:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/24/14 11:40, Zaphod Beeblebrox wrote: > So... another barrier in figuring out my zfs problem is that zdb > crashes when asked to print the gang block header: > > [1:97:397]root@virtual:/vr1/tmp/diag> zdb -AAA -R vr2 > 0:94048dc9000:24000:g Found vdev type: raidz Assertion failed: > (zio->io_error == 0 || (zio->io_flags & ZIO_FLAG_CANFAIL)), file > /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c, > > line 3297. > Abort trap (core dumped) > > Now... this trace looks odd to me: there are no bookmarks in the > filesystem... neither are there snapshots for this specific > filesystem. This is normal, it's part of traverse_visitbp(). What was zio->io_error? Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.2 (FreeBSD) iQIcBAEBCgAGBQJVEcNOAAoJEJW2GBstM+nsxGwP/1GboLzYYM2t11UxqeZzfkgL fB77BZNKmPKVFwRVLvSk4A61a/KnnTFV9KL301zoUcPVl5lZM8vOCtqzxOpgXUnj 85GeYhAUmudV/DIRCgvXKLxPZerx+hJlQf+bMhT0Q2s9uOslxaY0Gt09u2BsKVj1 xnw6B0TLffgcpReUzuArhTxWogwwImYXkScncZhDTMaUtf9MfPgEnEuCtBRdc26z Lhq5BunQyyghC3pQDxAskH0guNsi8NrEFGrcKyerLV34BiOt4pOTy165Es7hhisA o9HZkq2WxtX9Qx8CiwXi+BJkscEuNUnC7jGTG/eL+WYVtZ8qrBToN/SsD7BN1gu+ M3lgX+otKYT9FUROJVd8X3Lm5hcGycJzPRi2QzuWyqMBzU8KPRcSPPbi+t1uQXgN /JkiOVjC6npwf2paGe7h3+cV7Amh+oKoY0IOt2veXQ5pB6x+DuwFvk/MlNn+2hH/ I01Q2I0ZiiRG1/M4jT5mFaPnH6rz4UMcJb1livXj6F0BrHK0o2wDllmMBQxreIFD 126cz3VyCzLvw+0Nn2vlhg2Jpf/k2HbtcO4A1PmgbwIkyuXI0CX6Hk2dbwhdGbkN vEoJS5Tn8/kl7J0aI/GVdeiGWnm8m1Y0NYv8G2ZwLMowQ71ZxqryZp/IzinLZsDK xO9zZh3Gjvz7TYS6zyAw =qen3 -----END PGP SIGNATURE----- From owner-freebsd-fs@FreeBSD.ORG Tue Mar 24 21:02:52 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 D1449724; Tue, 24 Mar 2015 21:02:52 +0000 (UTC) Received: from gw.catspoiler.org (cl-1657.chi-02.us.sixxs.net [IPv6:2001:4978:f:678::2]) (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 63F90802; Tue, 24 Mar 2015 21:02:52 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id t2OL2f3Y044175; Tue, 24 Mar 2015 13:02:45 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201503242102.t2OL2f3Y044175@gw.catspoiler.org> Date: Tue, 24 Mar 2015 14:02:41 -0700 (PDT) From: Don Lewis Subject: Re: Zoned Commands ZBC/ZAC, Shingled SMR drives, ZFS To: jg@internetx.com In-Reply-To: <5511A204.7020705@internetx.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-fs@FreeBSD.org, freebsd-hardware@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, 24 Mar 2015 21:02:52 -0000 On 24 Mar, InterNetX - Juergen Gotteswinter wrote: > The HGST He8 HDDs completed its rebuild in 19 hours and 46 minutes. The > Seagate Archive HDDs completed their rebuild in 57 hours and 13 minutes > > this is ... a feature. right? Looks like the HGST He8 drives cost about $600 though ... The He10 is SMR. From owner-freebsd-fs@FreeBSD.ORG Tue Mar 24 21:33:03 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 1957EC94 for ; Tue, 24 Mar 2015 21:33:03 +0000 (UTC) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) (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 B9294BFA for ; Tue, 24 Mar 2015 21:33:01 +0000 (UTC) Received: from laptop2.herveybayaustralia.com.au (laptop2.herveybayaustralia.com.au [192.168.0.185]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id A5F01620A6; Wed, 25 Mar 2015 07:32:56 +1000 (EST) Message-ID: <5511D807.3040606@herveybayaustralia.com.au> Date: Wed, 25 Mar 2015 07:32:55 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Benjamin Kaduk Subject: Re: Delete a directory, crash the system References: <551007DD.5020109@herveybayaustralia.com.au> <5510B995.8060307@herveybayaustralia.com.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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, 24 Mar 2015 21:33:03 -0000 On 03/25/15 00:16, Benjamin Kaduk wrote: > On Mon, 23 Mar 2015, Da Rock wrote: > >> Unfortunately, fsck isn't helping - foreground or otherwise. All it shows on >> every single fs is inode 4 recovery which doesn't sound quite right. And > Have you posted the exact output in a previous message (could you send a > link)? Not precisely, but the message is just a flash and there is no copying of it. Anyway, inode 4 is the .sujournal file as expected; this means there is an issue with the softupdates. Could this be narrowing it down (the OP to this was also in this age of enlightenment, SU came in with 8.x didn't it?)? > >> again, it is only showing during updates to ports being built. I'm > Er, what is only showing up? The panics? > Surely you are not only running fsck while building ports... Yes, the panics. Sorry, I thought that was obvious seeing as the alternative is impossible :) > >> investigating further, but it may be just a corrupt file in pkg system. >> >> Incidentally, I'm not suggesting an absolute fix for the issue as such, but a >> better means of handling it rather than crashing the system. The posts on this > Understood. But, there will always be some types of error which are truly > unrecoverable, and there is no real option other than to panic. (Which is > not to say that your situation is necessarily one of them.) That I get, and given this may be an issue with SU it may well be warranted. What can we do to narrow this down, as obviously one cannot be sitting watching exactly what happens for the hours required while building ports. Your bound to look away for just a second and miss it even if you did try! :D > >> If I discover anything more I'll keep everyone posted :) So I did some fiddling with fsck, fsdb, find and stat; and got nowhere. I ran fsck again and it gave me not much again. It did hint at some files in the ports tree, so I cleaned up the ports tree to fresh install point, ran fsck again and rebooted. So far so good, but I'm keeping my fingers crossed still. This doesn't help the panics - they're still a pita when they happen. It does help me resolve the issue this time though. But initiating this error in testing is damn near impossible. What can we document here as a way to gather data to determine how to resolve this issue? Given my luck with this, its bound to happen again at some point :) From owner-freebsd-fs@FreeBSD.ORG Wed Mar 25 00:44: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 11216B5C; Wed, 25 Mar 2015 00:44:25 +0000 (UTC) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (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 D5E45339; Wed, 25 Mar 2015 00:44:24 +0000 (UTC) Received: by iedm5 with SMTP id m5so11115231ied.3; Tue, 24 Mar 2015 17:44:24 -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=+5x6tBqGTk9Aa8uT2m5/GVVzY/BMEHuykpOmTFP9zJM=; b=NcnRFUQYfk+0fwANuWk/JYdLSqQ34+QD1RuI/KJFbeZNur9NUTxJ3ytvAsjaUbH8C7 O+urcFEJFu7DTNz4UlwjIYlJhH/ks78BJdcz9Ly4Hu9caanesJ78nXhKpVa/YjZtE/JV dDkQqCPWNq1u5jbx8zlyRjZy44MML+iL5QvIwqof5oiCgariH+Lzx6+d0Ez3+5AojbMv kH2dP0+FK0vnD4xtbcb9GC1AxiLOI0LXjtX3ThYGRkz9BedkaczhJ7nqvxO1Bs2cz6Hl IaOJBGdrPDCRa2ABTWvqupSOf+5w84lk4/ZQNYHCT4jRUyzTteMMY4kd/+dtIBFpAllX DLJA== MIME-Version: 1.0 X-Received: by 10.50.97.41 with SMTP id dx9mr25924934igb.1.1427244264024; Tue, 24 Mar 2015 17:44:24 -0700 (PDT) Received: by 10.64.223.170 with HTTP; Tue, 24 Mar 2015 17:44:23 -0700 (PDT) Date: Tue, 24 Mar 2015 16:44:23 -0800 Message-ID: Subject: Re: Zoned Commands ZBC/ZAC, Shingled SMR drives, ZFS From: Dieter BSD To: freebsd-fs@freebsd.org, freebsd-hardware@freebsd.org Content-Type: text/plain; charset=ISO-8859-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: Wed, 25 Mar 2015 00:44:25 -0000 >> You can also find these drives inside the STDT8000100 external >> USB unit for a bit more at $300. It may or may not be the same. There are stories that it is difficult or impossible to talk directly to the drives in recent USB units without the usb-to-sata bridge. I have yet to find a usb-to-sata bridge that doesn't have problems. > Is the price predicted to go down further in the future? Disk prices were going down nicely until the great flood. Prices took over a year to return to pre-flood levels, and have been dropping *very* slowly since. The M&A activity reduced competition, which doesn't help. Governments can't be bothered to prohibit anticompetitive M&A activity. Increases in capacity per drive have slowed, perhaps due to the same reduction in competition. 3TB drives have been the best value in TB/$ for nearly 4 years. I bought some 3TB drives last month for $84.99 each (with free shipping). At the same TB/$ an 8TB drive should cost $226.64, and a 10TB drive should cost $283.30. The penguins added a new device manipulation library to support ZBC/ZAC. There might be things to learn there (mistakes to avoid?). http://www.zdnet.com/article/hgst-gets-closer-to-shipping-10tb-hdd/ From owner-freebsd-fs@FreeBSD.ORG Wed Mar 25 02:05:54 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 86BD1D4A for ; Wed, 25 Mar 2015 02:05:54 +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 6D926DCB for ; Wed, 25 Mar 2015 02:05:54 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2P25sWm021935 for ; Wed, 25 Mar 2015 02:05:54 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 198789] Panic while mounting an NANDFS filesystem Date: Wed, 25 Mar 2015 02:05:54 +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: 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: Wed, 25 Mar 2015 02:05:54 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198789 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 Wed Mar 25 02:08:00 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 408D9E6C for ; Wed, 25 Mar 2015 02:08:00 +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 271D9DFD for ; Wed, 25 Mar 2015 02:08:00 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2P2800Y023427 for ; Wed, 25 Mar 2015 02:08:00 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 198866] Dump crashes backup over NFS if Files greater than 2GB Date: Wed, 25 Mar 2015 02:07:59 +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: 11.0-CURRENT 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: Wed, 25 Mar 2015 02:08:00 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198866 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 Wed Mar 25 04:25:32 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 A72DCE3A; Wed, 25 Mar 2015 04:25:32 +0000 (UTC) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 16968E6E; Wed, 25 Mar 2015 04:25:31 +0000 (UTC) X-AuditID: 12074423-f79536d000000e74-a1-551238b30a25 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 71.73.03700.4B832155; Wed, 25 Mar 2015 00:25:24 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t2P4PNQT028681; Wed, 25 Mar 2015 00:25:23 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2P4PKBU012344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Mar 2015 00:25:22 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t2P4PJ3O011985; Wed, 25 Mar 2015 00:25:19 -0400 (EDT) Date: Wed, 25 Mar 2015 00:25:19 -0400 (EDT) From: Benjamin Kaduk To: Da Rock Subject: Re: Delete a directory, crash the system In-Reply-To: <5511D807.3040606@herveybayaustralia.com.au> Message-ID: References: <551007DD.5020109@herveybayaustralia.com.au> <5510B995.8060307@herveybayaustralia.com.au> <5511D807.3040606@herveybayaustralia.com.au> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrEIsWRmVeSWpSXmKPExsUixCmqrLvFQijUYGITi8Wxxz/ZLL7/fMFs seGsvAOzx4xP81k8Xm9cyB7AFMVlk5Kak1mWWqRvl8CVMfXFSsaCBumK5d+2MTUwThbtYuTk kBAwkTg5awEbhC0mceHeeiCbi0NIYDGTROP6k0wQzkZGid2717BAOIeYJHatng/lNDBKTLz6 AMjh4GAR0JZY80UDZBSbgIrEzDcbwcaKCBhJzL/ynAnEZhYwkGh91MUKYgsLGEqsO9HIAmJz ClhKPFr7AszmFXCUmD1pJtT82ywSXz/MA0uICuhIrN4/BapIUOLkzCcsEEO1JJZP38YygVFw FpLULCSpBYxMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3TN9HIzS/RSU0o3MYKClt1FeQfjn4NK hxgFOBiVeHh/SAiFCrEmlhVX5h5ilORgUhLlPaEOFOJLyk+pzEgszogvKs1JLT7EKMHBrCTC awBSzpuSWFmVWpQPk5LmYFES5930gy9ESCA9sSQ1OzW1ILUIJivDwaEkwfvEHKhRsCg1PbUi LTOnBCHNxMEJMpwHaPgDkBre4oLE3OLMdIj8KUZFKXHeZSAJAZBERmkeXC8sqbxiFAd6RZh3 L0gVDzAhwXW/AhrMBDT4XD4fyOCSRISUVANjJNOCMxrL3QNOW2t8OHNJ/uGFC0o3nwYJzp6v VTStzVHRkDWeI9TtT+zkI3/2PL+m3d30TWVfN7tdaCXTh4J3FZNO358R7RDVt3mN87Pkgwrc Nt9mnN+ZzqeluHFOkWaX9d6yglv/QzNrHpxVPCmj7uq8VPr9VnbruVIblhZP6Zz3I2i+Xk+t EktxRqKhFnNRcSIAydq8UAUDAAA= Cc: freebsd-fs@freebsd.org, mckusick@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, 25 Mar 2015 04:25:32 -0000 On Tue, 24 Mar 2015, Da Rock wrote: > On 03/25/15 00:16, Benjamin Kaduk wrote: > > On Mon, 23 Mar 2015, Da Rock wrote: > > > > > Unfortunately, fsck isn't helping - foreground or otherwise. All it shows > > > on > > > every single fs is inode 4 recovery which doesn't sound quite right. And > > Have you posted the exact output in a previous message (could you send a > > link)? > Not precisely, but the message is just a flash and there is no copying of it. > Anyway, inode 4 is the .sujournal file as expected; this means there is an > issue with the softupdates. Could this be narrowing it down (the OP to this > was also in this age of enlightenment, SU came in with 8.x didn't it?)? Ah, SU+J could be quite relevant. Soft-update journalling was enabled by default for a period of time, but I believe it was disabled because there were some scenarios where it was destabilizing. CC-ing Kirk to improve on my lousy memory. Do you remember what version was used to install the system in question (i.e., create the filesystem in question)? Please show the output of 'tunefs -p ' > > > again, it is only showing during updates to ports being built. I'm > > Er, what is only showing up? The panics? > > Surely you are not only running fsck while building ports... > Yes, the panics. > > Sorry, I thought that was obvious seeing as the alternative is impossible :) > > > > > investigating further, but it may be just a corrupt file in pkg system. > > > > > > Incidentally, I'm not suggesting an absolute fix for the issue as such, > > > but a > > > better means of handling it rather than crashing the system. The posts on > > > this > > Understood. But, there will always be some types of error which are truly > > unrecoverable, and there is no real option other than to panic. (Which is > > not to say that your situation is necessarily one of them.) > That I get, and given this may be an issue with SU it may well be warranted. > What can we do to narrow this down, as obviously one cannot be sitting > watching exactly what happens for the hours required while building ports. > Your bound to look away for just a second and miss it even if you did try! :D > > > > > If I discover anything more I'll keep everyone posted :) > So I did some fiddling with fsck, fsdb, find and stat; and got nowhere. I ran > fsck again and it gave me not much again. It did hint at some files in the > ports tree, so I cleaned up the ports tree to fresh install point, ran fsck > again and rebooted. So far so good, but I'm keeping my fingers crossed still. It is probably important to note that 'fsck -F' and saying 'no' to "USE JOURNAL?" is the most relevant fsck invocation. > This doesn't help the panics - they're still a pita when they happen. It does > help me resolve the issue this time though. But initiating this error in > testing is damn near impossible. What can we document here as a way to gather > data to determine how to resolve this issue? Given my luck with this, its > bound to happen again at some point :) I think actual diagnostic is beyond my expertise/time committment at the moment. I suspect that using tunefs to disable softupdate journalling will be a workaround, if that is what you are really interested. I'll let Kirk decide if he wants to debug more, but the answer may well be "no" if you're not running the latest ufs from -current. -Ben From owner-freebsd-fs@FreeBSD.ORG Wed Mar 25 09:25:07 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 6EBD0C6; Wed, 25 Mar 2015 09:25:07 +0000 (UTC) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) (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 C1B28E69; Wed, 25 Mar 2015 09:25:06 +0000 (UTC) Received: from laptop2.herveybayaustralia.com.au (laptop2.herveybayaustralia.com.au [192.168.0.185]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id 61E15620A1; Wed, 25 Mar 2015 19:24:55 +1000 (EST) Message-ID: <55127EE6.2010506@herveybayaustralia.com.au> Date: Wed, 25 Mar 2015 19:24:54 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Benjamin Kaduk Subject: Re: Delete a directory, crash the system References: <551007DD.5020109@herveybayaustralia.com.au> <5510B995.8060307@herveybayaustralia.com.au> <5511D807.3040606@herveybayaustralia.com.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, mckusick@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, 25 Mar 2015 09:25:07 -0000 On 03/25/15 14:25, Benjamin Kaduk wrote: > On Tue, 24 Mar 2015, Da Rock wrote: > >> On 03/25/15 00:16, Benjamin Kaduk wrote: >>> On Mon, 23 Mar 2015, Da Rock wrote: >>> >>>> Unfortunately, fsck isn't helping - foreground or otherwise. All it shows >>>> on >>>> every single fs is inode 4 recovery which doesn't sound quite right. And >>> Have you posted the exact output in a previous message (could you send a >>> link)? >> Not precisely, but the message is just a flash and there is no copying of it. >> Anyway, inode 4 is the .sujournal file as expected; this means there is an >> issue with the softupdates. Could this be narrowing it down (the OP to this >> was also in this age of enlightenment, SU came in with 8.x didn't it?)? > Ah, SU+J could be quite relevant. Soft-update journalling was enabled by > default for a period of time, but I believe it was disabled because there > were some scenarios where it was destabilizing. CC-ing Kirk to improve on > my lousy memory. Hmmm... not sure about that. This was set by a fresh install at the time and I haven't fiddled with that - I have set trim though (I think). To verify, I just checked my fresh 10.1 and it has the same settings, so I don't think they're disabled yet... > > Do you remember what version was used to install the system in question > (i.e., create the filesystem in question)? Version of what exactly? Do you mean the OS or the utilities for filesystem ops? The filesystem was originally setup at install (I start with a clean system when I install freebsd - exceptions happen of course, but thats the rule. Makes it easier... they are just workstations after all) so I wouldn't remember or discover exactly what utils were used. Install was using bsdinstall as per FBSD10 disk. > Please show the output of > 'tunefs -p ' root: tunefs: POSIX.1e ACLs: (-a) disabled tunefs: NFSv4 ACLs: (-N) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: soft update journaling: (-j) enabled tunefs: gjournal: (-J) disabled tunefs: trim: (-t) enabled tunefs: maximum blocks per file in a cylinder group: (-e) 4096 tunefs: average file size: (-f) 16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: space to hold for metadata blocks: (-k) 5240 tunefs: optimization preference: (-o) time tunefs: volume label: (-L) All the others are about the same - variations mainly in space variables due to size. > >>>> again, it is only showing during updates to ports being built. I'm >>> Er, what is only showing up? The panics? >>> Surely you are not only running fsck while building ports... >> Yes, the panics. >> >> Sorry, I thought that was obvious seeing as the alternative is impossible :) >>>> investigating further, but it may be just a corrupt file in pkg system. >>>> >>>> Incidentally, I'm not suggesting an absolute fix for the issue as such, >>>> but a >>>> better means of handling it rather than crashing the system. The posts on >>>> this >>> Understood. But, there will always be some types of error which are truly >>> unrecoverable, and there is no real option other than to panic. (Which is >>> not to say that your situation is necessarily one of them.) >> That I get, and given this may be an issue with SU it may well be warranted. >> What can we do to narrow this down, as obviously one cannot be sitting >> watching exactly what happens for the hours required while building ports. >> Your bound to look away for just a second and miss it even if you did try! :D >>>> If I discover anything more I'll keep everyone posted :) >> So I did some fiddling with fsck, fsdb, find and stat; and got nowhere. I ran >> fsck again and it gave me not much again. It did hint at some files in the >> ports tree, so I cleaned up the ports tree to fresh install point, ran fsck >> again and rebooted. So far so good, but I'm keeping my fingers crossed still. > It is probably important to note that 'fsck -F' and saying 'no' to "USE > JOURNAL?" is the most relevant fsck invocation. Ok. I only use fsck in single user mode, as its only really of use to me there and something is usually broken if I'm using it :) so -F is usually implied there. No to use journal - good to know, I'll use that next time then when it happens. > >> This doesn't help the panics - they're still a pita when they happen. It does >> help me resolve the issue this time though. But initiating this error in >> testing is damn near impossible. What can we document here as a way to gather >> data to determine how to resolve this issue? Given my luck with this, its >> bound to happen again at some point :) > I think actual diagnostic is beyond my expertise/time committment at the > moment. I suspect that using tunefs to disable softupdate journalling > will be a workaround, if that is what you are really interested. Don't know. Might be SU+J or maybe a pkgng fault in managing ports. Might just wing it - might be helpful to the project after all :) (could erk some of my users though :P) > > I'll let Kirk decide if he wants to debug more, but the answer may well be > "no" if you're not running the latest ufs from -current. > > -Ben From owner-freebsd-fs@FreeBSD.ORG Wed Mar 25 17:12: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 DEE68563 for ; Wed, 25 Mar 2015 17:12:11 +0000 (UTC) Received: from chez.mckusick.com (chez.mckusick.com [IPv6:2001:5a8:4:7e72:4a5b:39ff:fe12:452]) (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 BB84A64B for ; Wed, 25 Mar 2015 17:12:11 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id t2PHC1R8090290; Wed, 25 Mar 2015 10:12:01 -0700 (PDT) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201503251712.t2PHC1R8090290@chez.mckusick.com> To: Benjamin Kaduk Subject: Re: Delete a directory, crash the system In-reply-to: Date: Wed, 25 Mar 2015 10:12:01 -0700 From: Kirk McKusick 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, 25 Mar 2015 17:12:12 -0000 > Date: Wed, 25 Mar 2015 00:25:19 -0400 (EDT) > From: Benjamin Kaduk > To: Da Rock > Subject: Re: Delete a directory, crash the system > Cc: freebsd-fs@freebsd.org, mckusick@freebsd.org > > On Tue, 24 Mar 2015, Da Rock wrote: > >> On 03/25/15 00:16, Benjamin Kaduk wrote: >> Not precisely, but the message is just a flash and there is no copying of it. >> Anyway, inode 4 is the .sujournal file as expected; this means there is an >> issue with the softupdates. Could this be narrowing it down (the OP to this >> was also in this age of enlightenment, SU came in with 8.x didn't it?)? > > Ah, SU+J could be quite relevant. Soft-update journalling was enabled by > default for a period of time, but I believe it was disabled because there > were some scenarios where it was destabilizing. CC-ing Kirk to improve on > my lousy memory. As far as I know SU+J is still on by default. > Do you remember what version was used to install the system in question > (i.e., create the filesystem in question)? Please show the output of > 'tunefs -p ' > >> So I did some fiddling with fsck, fsdb, find and stat; and got nowhere. I ran >> fsck again and it gave me not much again. It did hint at some files in the >> ports tree, so I cleaned up the ports tree to fresh install point, ran fsck >> again and rebooted. So far so good, but I'm keeping my fingers crossed still. > > It is probably important to note that 'fsck -F' and saying 'no' to "USE > JOURNAL?" is the most relevant fsck invocation. > >> This doesn't help the panics - they're still a pita when they happen. It does >> help me resolve the issue this time though. But initiating this error in >> testing is damn near impossible. What can we document here as a way to gather >> data to determine how to resolve this issue? Given my luck with this, its >> bound to happen again at some point :) > > I think actual diagnostic is beyond my expertise/time committment at the > moment. I suspect that using tunefs to disable softupdate journalling > will be a workaround, if that is what you are really interested. > > I'll let Kirk decide if he wants to debug more, but the answer may well be > "no" if you're not running the latest ufs from -current. > > -Ben The suggestion to disable journalling is a good one. Journalling fixes only consistency errors that it knows about and cannot handle media errors. The sorts of panics you are getting are usually caused by media errors. So disabling journally and checking all metadata after crashes (which is what fsck does) should minimize your problems. Kirk McKusick From owner-freebsd-fs@FreeBSD.ORG Thu Mar 26 17:39:26 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 3243A610 for ; Thu, 26 Mar 2015 17:39:26 +0000 (UTC) Received: from fallback6.mail.ru (fallback6.mail.ru [94.100.181.147]) by mx1.freebsd.org (Postfix) with ESMTP id 82C0CD1F for ; Thu, 26 Mar 2015 17:39:25 +0000 (UTC) Received: from f146.i.mail.ru (f146.i.mail.ru [94.100.178.198]) by fallback6.mail.ru (mPOP.Fallback_MX) with ESMTP id 78AE9360AF2 for ; Thu, 26 Mar 2015 20:27:41 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=inbox.ru; s=mail; h=Content-Type:Message-ID:Reply-To:Date:MIME-Version:Subject:To:From; bh=E6zo3UE36cqRl9GVuP/G0FU8ASE5+ijSTMV0jRQ0JnE=; b=IUw7X9l2T7hzV8T4UpNav5NT1M3jDcRLmb4d2zYtZSACdRv3wshE+9RlH2g0Q79ks87xWXVxGpNGh7uFJz2XHfxFTq11zrFdtaRz8lOvwt/6/47oPQFTG0gdgfBOqF2SqdGHwAUHavjRvS1DDEjip+YXLQ2QwiWJTaLTFIBa1T0=; Received: from [77.232.155.125] (ident=mail) by f146.i.mail.ru with local (envelope-from ) id 1YbBZ6-000157-R5 for freebsd-fs@freebsd.org; Thu, 26 Mar 2015 20:27:33 +0300 Received: from [77.232.155.125] by e.mail.ru with HTTP; Thu, 26 Mar 2015 20:27:32 +0300 From: =?UTF-8?B?YXJtb25pYQ==?= To: freebsd-fs@freebsd.org Subject: =?UTF-8?B?WkZTIG91dCBvZiBzd2FwIHNwYWNl?= MIME-Version: 1.0 X-Mailer: Mail.Ru Mailer 1.0 X-Originating-IP: [77.232.155.125] Date: Thu, 26 Mar 2015 20:27:32 +0300 Reply-To: =?UTF-8?B?YXJtb25pYQ==?= X-Priority: 3 (Normal) Message-ID: <1427390852.239634101@f146.i.mail.ru> X-Mras: Ok X-Spam: undefined Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 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: Thu, 26 Mar 2015 17:39:26 -0000 IEhlbGxvLiBQbGVhc2UgaGVscCAuIEkgbWlycm9yIFpGUyA5LjMgLCBhZnRlciBhbiBhY3RpdmUg aXQgYnkgdXNpbmcgbXlzcWwgcmVhZCBcIHdyaXRlIGZyb20gYW4gZXh0ZXJuYWwgc2NyaXB0IHNv bWV0aGluZyBicm9rZW4uIFRoZSBvcGVyYXRpbmcgc3lzdGVtIGlzIG5vdCBsb2FkZWQgYXQgdGhl IHRpbWUgb2YgIk1vdW50IGxvY2FsIGZpbGVzeXN0ZW1zIgoKcG9vbCBjb25zaXN0cyBvZiBhIG1p cnJvciAocmFpZCAxICkgKyBob3Qgc3dhcCwgemZzIHBhcnRpdGlvbnMgb24gYSBzZXBhcmF0ZSAu Cgp6cG9vbCBpbXBvcnQgLWYgLVIgL3RtcCB6cm9vdCBmcmVlemVzCgp0cnkgdG8gaW1wb3J0IGEg cG9vbCBmcm9tIGEgTGl2ZUNEICgxMC4xKSAtPiB6cG9vbCBpbXBvcnQgLWYgLVIgLyB0bXAgenJv b3Qgb3V0IGFzIGluIGRlZXAgdGhvdWdodCBhbmQgdGhlbiB3cm90ZSBzb21ldGhpbmcgbGlrZQoK cGlkIDk5MjE3IChzaCksIHVpZCAwLCB3YXMga2lsbGVkOiBvdXQgb2Ygc3dhcCBzcGFjZQpwaWQg ODk2IChzc2gpLCB1aWQgMCwgd2FzIGtpbGxlZDogb3V0IG9mIHN3YXAgc3BhY2UKCnpwb29sIG1h ZGUgb2YgMiBkaXNrcyB0byBHUFQgYW5kIG9uZSBhcyBob3Qtc3dhcC4KCsKgIHpwb29sIHN0YXR1 cyAtdgrCoMKgIHBvb2w6IHpyb290CsKgIHN0YXRlOiBPTkxJTkUKwqDCoCBzY2FuOiBub25lIHJl cXVlc3RlZApjb25maWc6CgrCoMKgwqDCoMKgwqDCoMKgIE5BTUUgU1RBVEUgUkVBRCBXUklURSBD S1NVTQrCoMKgwqDCoMKgwqDCoMKgIHpyb290IE9OTElORSAwIDAgMArCoMKgwqDCoMKgwqDCoMKg wqDCoCBtaXJyb3ItT05MSU5FIDAgMCAwIDAKwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGdwdCAv IGRpc2swIE9OTElORSAwIDAgMArCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgZ3B0IC8gZGlzazEg T05MSU5FIDAgMCAwCsKgwqDCoMKgwqDCoMKgwqAgc3BhcmVzCsKgwqDCoMKgwqDCoMKgwqDCoMKg IGdwdCAvIGRpc2syIEFWQUlMCgplcnJvcnM6IE5vIGtub3duIGRhdGEgZXJyb3JzCgpPbiB0aGUg c2VydmVyIDQwOTYgcmFtLCB6ZnMgZGF0YXNldHMgYXJlIGRpdmlkZWQgbGlrZSB0aGlzOgoKenJv b3QgNTcuOEcgMjEyRyAxNzBNIC8KenJvb3QgLyB0bXAgMTguMk0gMjEyRyAxOC4yTSAvIHRtcAp6 cm9vdCAvIHVzciAxNS40RyAyMTJHIDQwOU0gLyB1c3IKenJvb3QgLyB1c3IgLyBob21lIDYuNTRH IDIxMkcgNi41NEcgLyB1c3IgLyBob21lCnpyb290IC8gdXNyIC8gbG9jYWwgMy43OEcgMjEyRyAz Ljc4RyAvIHVzciAvIGxvY2FsCnpyb290IC8gdXNyIC8gb2JqIDQzMksgMjEyRyA0MzJLIC8gdXNy IC8gb2JqCnpyb290IC8gdXNyIC8gcG9ydHMgMi42MUcgMjEyRyAxLjY5RyAvIHVzciAvIHBvcnRz Cnpyb290IC8gdXNyIC8gcG9ydHMgLyBkaXN0ZmlsZXMgODE1TSAyMTJHIDgxNU0gLyB1c3IgLyBw b3J0cyAvIGRpc3RmaWxlcwp6cm9vdCAvIHVzciAvIHBvcnRzIC8gcGFja2FnZXMgMTI2TSAyMTJH IDEyNk0gLyB1c3IgLyBwb3J0cyAvIHBhY2thZ2VzCnpyb290IC8gdXNyIC8gc3JjIDIuMDhHIDIx MkcgMi4wOEcgLyB1c3IgLyBzcmMKenJvb3QgLyB2YXIgNDEuOUcgMjEyRyAxOTRNIC8gdmFyCnpy b290IC8gdmFyIC8gYmFja3VwcyAxNDdNIDIxMkcgMTQ3TSAvIHZhciAvIGJhY2t1cHMKenJvb3Qg LyB2YXIgLyBjcmFzaCAyMjRLIDIxMkcgMjI0SyAvIHZhciAvIGNyYXNoCnpyb290IC8gdmFyIC8g ZGIgNDEuNkcgMjEyRyAzMzFNIC8gdmFyIC8gZGIKenJvb3QgLyB2YXIgLyBkYiAvIG15c3FsIDQx LjJHIDIxMkcgNTMuNk0gLyB2YXIgLyBkYiAvIG15c3FsCnpyb290IC8gdmFyIC8gZGIgLyBteXNx bCAvIGJpbGxpbmcgMzcuOEcgMjEyRyAzNy44RyAvIHZhciAvIGRiIC8gbXlzcWwgLyBiaWxsaW5n Cnpyb290IC8gdmFyIC8gZGIgLyBteXNxbCAvIGliZGF0YSAzLjA1RyAyMTJHIDMuMDVHIC8gdmFy IC8gZGIgLyBteXNxbCAvIGliZGF0YQp6cm9vdCAvIHZhciAvIGRiIC8gbXlzcWwgLyBsb2dzIDIz ME0gMjEyRyAyMzBNIC8gdmFyIC8gZGIgLyBteXNxbCAvIGxvZ3MKenJvb3QgLyB2YXIgLyBkYiAv IHBrZyA5My4wTSAyMTJHIDkzLjBNIC8gdmFyIC8gZGIgLyBwa2cKenJvb3QgLyB2YXIgLyBlbXB0 eSAyMTZLIDIxMkcgMjE2SyAvIHZhciAvIGVtcHR5Cnpyb290IC8gdmFyIC8gbG9nIDM5LjJNIDIx MkcgMzkuMk0gLyB2YXIgLyBsb2cKenJvb3QgLyB2YXIgLyBtYWlsIDIxNksgMjEyRyAyMTZLIC8g dmFyIC8gbWFpbAp6cm9vdCAvIHZhciAvIHJ1biA0NTJLIDIxMkcgNDUySyAvIHZhciAvIHJ1bgp6 cm9vdCAvIHZhciAvIHRtcCA0NzZLIDIxMkcgNDc2SyAvIHZhciAvIHRtcAoKSSB0cmllZCB0byBt b3VudCBzZXBhcmF0ZWx5IG1vdW50IC10IHpmcyB6cm9vdC92YXIvZGIvbXlzcWwvYmlsbGluZ8Kg CgpQbGVhc2Ugc2VlIHNjcmVlbnNob3QKCmh0dHA6Ly9zMTcucG9zdGltZy5vcmcvYW00bnV3OXIz L2RzZy5qcGcKCk5vdyBJIGRpZCB6cG9vbCBpbXBvcnQgLWYgenJvb3QgYW5kIHpwb29sIHNjcnVi IHpyb290LCBJcyBhbHJlYWR5IDExIHBlcmNlbnQgb2YgMTEgZ2lnYWJ5dGVzIG9mIDEwNiAsIGJ1 dCBJIGRvIG5vdCB0aGluayBpdCB3aWxsIGhlbHAgLiAKClNjcnViIHNob3dzIGhhdmUgMzI3ICUg MzQ4IGdpZ2FieXRlcyBmcm9tIDEwNiBnaWdhYnl0ZXMgYW5kIHNjYW4gaXMgc2xvdywgbm8gZXN0 aW1hdGVkIHRpbWUuCgpQbGVhc2UgaGVscCBjb2xsZWFndWVz From owner-freebsd-fs@FreeBSD.ORG Fri Mar 27 19:10: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 9F797892 for ; Fri, 27 Mar 2015 19:10:48 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0098.outbound.protection.outlook.com [157.56.111.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 404F86EA for ; Fri, 27 Mar 2015 19:10:47 +0000 (UTC) Received: from BY2PR01CA0044.prod.exchangelabs.com (10.255.242.34) by BLUPR01MB180.prod.exchangelabs.com (10.242.201.17) with Microsoft SMTP Server (TLS) id 15.1.118.21; Fri, 27 Mar 2015 18:56:13 +0000 Received: from BN1AFFO11FD040.protection.gbl (2a01:111:f400:7c10::132) by BY2PR01CA0044.outlook.office365.com (2a01:111:e400:2c76::34) with Microsoft SMTP Server (TLS) id 15.1.125.19 via Frontend Transport; Fri, 27 Mar 2015 18:56:12 +0000 Received: from brdc-edge-1.merge.com ([199.127.41.37]) by BN1AFFO11FD040.mail.protection.outlook.com ([10.58.52.251]) with Microsoft SMTP Server (TLS) id 15.1.130.10 via Frontend Transport; Fri, 27 Mar 2015 18:56:11 +0000 Received: from BRDC-CAS-WS2.network.internal (10.244.10.30) by brdc-edge-1.merge.com (199.127.41.37) with Microsoft SMTP Server (TLS) id 14.3.210.2; Fri, 27 Mar 2015 13:55:52 -0500 Received: from BRDC-MBX-1.network.internal ([fe80::85d7:7611:9dbd:57b1]) by BRDC-CAS-WS2.network.internal ([::1]) with mapi id 14.03.0210.002; Fri, 27 Mar 2015 13:56:10 -0500 From: Claude Morin To: "freebsd-fs@FreeBSD.org" Subject: error in https://wiki.freebsd.org/HAST Thread-Topic: error in https://wiki.freebsd.org/HAST Thread-Index: AdBov6kEzppYmHbvS4SNixP5RkJfLw== Date: Fri, 27 Mar 2015 18:56:09 +0000 Message-ID: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.5.3] MIME-Version: 1.0 X-EOPAttributedMessage: 0 Received-SPF: Pass (protection.outlook.com: domain of Merge.com designates 199.127.41.37 as permitted sender) receiver=protection.outlook.com; client-ip=199.127.41.37; helo=brdc-edge-1.merge.com; Authentication-Results: spf=pass (sender IP is 199.127.41.37) smtp.mailfrom=Claude.Morin@Merge.com; FreeBSD.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:199.127.41.37; CTRY:US; IPV:NLI; EFV:NLI; BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(438002)(199003)(189002)(71364002)(106466001)(84326002)(5250100002)(229853001)(110136001)(86362001)(46102003)(19580395003)(55846006)(54356999)(92566002)(19580405001)(2501003)(2351001)(16236675004)(107886001)(62966003)(2656002)(102836002)(87936001)(450100001)(512934002)(16796002)(77156002)(33656002)(50986999)(19625215002)(2920100001)(2900100001)(2930100002)(7099025); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR01MB180; H:brdc-edge-1.merge.com; FPR:; SPF:Pass; MLV:ovrnspm; A:1; MX:1; PTR:brdc-edge-1.merge.com; LANG:en; X-OriginatorOrg: merge.com X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR01MB180; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(5002010)(5005006); SRVR:BLUPR01MB180; BCL:0; PCL:0; RULEID:; SRVR:BLUPR01MB180; X-Forefront-PRVS: 0528942FD8 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Mar 2015 18:56:11.9600 (UTC) X-MS-Exchange-CrossTenant-Id: 0358aef9-a426-4c03-be7a-b4c41990b0ef X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=0358aef9-a426-4c03-be7a-b4c41990b0ef; Ip=[199.127.41.37]; Helo=[brdc-edge-1.merge.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR01MB180 Content-Type: text/plain; charset="iso-8859-1" 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: Fri, 27 Mar 2015 19:10:48 -0000 I note that the last edit to that page occurred more than three years ago, = so I realize the following may not be helpful :-). =A7 "Replication modes" states: Currently only the first replication mode described below is supporte= d... However the second mode is the only implemented mode: * The ordering of the three modes is 1) memsync, 2) fullsync, 3) asyn= c. * The first and third entries finish with "...currently not implement= ed." * The second entry finishes with "...is the default." May I suggest the following? Currently only the "fullsync" replication mode described below is sup= ported... Kind regards, Claude Morin | Senior Systems Engineer | Merge Healthcare | 905.364.8033 | = Claude.Morin@merge.com From owner-freebsd-fs@FreeBSD.ORG Fri Mar 27 20:57:10 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 ADD22A52; Fri, 27 Mar 2015 20:57:10 +0000 (UTC) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (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 3FC0F63F; Fri, 27 Mar 2015 20:57:10 +0000 (UTC) Received: by wiaa2 with SMTP id a2so46902954wia.0; Fri, 27 Mar 2015 13:57: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 :content-type:content-transfer-encoding; bh=iCyvXgsqub+pq79CCi4sabBy0JgyZ76LZkvRyrl1PX8=; b=O1HjpK3BnBmCDPDp+DdnklS7PTPu4aHaWOTFdXG3UVKgbayw3qkGuAqagW7LaO0eEi pMFmpWm1OWnmTJiXWRQ5xx8pdvxIBy/IImW2ShfU6W6Hw9yMKRnGdz6kFwVyD88BLzud 6UypCB259UztJk4LgSWEA2K49UkIavi57yzkHqlAA1HX/KQUIW/bsCL9csHRwyPFXV2v FwgZ6p1qrovq11EdP78QNS+iENpxSoBEqsVXTqKtQMfVo0nvPv3Ob/Bjgb/ITAuT4N6M NNPxcn0rzZR7mV3gLZBVGRvNm8sa7g+TaBcKZyb6bO9zARBkT4h5lugEJnXJnMKPY4if jGPQ== X-Received: by 10.180.89.163 with SMTP id bp3mr1141313wib.88.1427489828595; Fri, 27 Mar 2015 13:57:08 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([134.249.139.101]) by mx.google.com with ESMTPSA id bd1sm5001614wib.13.2015.03.27.13.57.07 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Mar 2015 13:57:07 -0700 (PDT) Sender: Alexander Motin Message-ID: <5515C421.4040703@FreeBSD.org> Date: Fri, 27 Mar 2015 22:57: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: freebsd-fs@FreeBSD.org, "freebsd-hackers@freebsd.org" Subject: MAXBSIZE increase 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: Fri, 27 Mar 2015 20:57:10 -0000 Hi. Experimenting with NFS and ZFS I found an inter-operation issue: ZFS by default uses block of 128KB, while FreeBSD NFS (both client and server) is limited to 64KB requests by the value of MAXBSIZE. On file rewrite that limitation makes ZFS to do slow read-modify-write cycles for every write operation, instead of just writing the new data. Trivial iozone test show major difference between initial write and rewrite speeds because of this issue. Looking through the sources I've found and in r280347 fixed number of improper MAXBSIZE use cases in device drivers. After that I see no any reason why MAXBSIZE can not be increased to at least 128KB to match ZFS default (ZFS now supports block up to 1MB, but that is not default and so far rare). I've made a test build and also successfully created UFS file system with 128KB block -- not sure it is needed, but seems it survives this change well too. Is there anything I am missing, or it is safe to rise this limit now? -- Alexander Motin From owner-freebsd-fs@FreeBSD.ORG Sat Mar 28 02:45: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 AAAB0F83; Sat, 28 Mar 2015 02:45:07 +0000 (UTC) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 6CFB5D51; Sat, 28 Mar 2015 02:45:07 +0000 (UTC) Received: from c211-30-166-197.carlnfd1.nsw.optusnet.com.au (c211-30-166-197.carlnfd1.nsw.optusnet.com.au [211.30.166.197]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 8E0C5428F24; Sat, 28 Mar 2015 13:44:58 +1100 (AEDT) Date: Sat, 28 Mar 2015 13:44:57 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Alexander Motin Subject: Re: MAXBSIZE increase In-Reply-To: <5515C421.4040703@FreeBSD.org> Message-ID: <20150328111733.L963@besplex.bde.org> References: <5515C421.4040703@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=ZuzUdbLG c=1 sm=1 tr=0 a=KA6XNC2GZCFrdESI5ZmdjQ==:117 a=PO7r1zJSAAAA:8 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=K_dCTBWPffNRIZAgkwQA:9 a=v5_RuTisAHe7God6:21 a=T73ABXJZ4VF9rtWC:21 a=CjuIK1q_8ugA:10 Cc: freebsd-fs@freebsd.org, "freebsd-hackers@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, 28 Mar 2015 02:45:07 -0000 > Experimenting with NFS and ZFS I found an inter-operation issue: ZFS by > default uses block of 128KB, while FreeBSD NFS (both client and server) > is limited to 64KB requests by the value of MAXBSIZE. On file rewrite > that limitation makes ZFS to do slow read-modify-write cycles for every > write operation, instead of just writing the new data. Trivial iozone > test show major difference between initial write and rewrite speeds > because of this issue. > > Looking through the sources I've found and in r280347 fixed number of > improper MAXBSIZE use cases in device drivers. After that I see no any > reason why MAXBSIZE can not be increased to at least 128KB to match ZFS > default (ZFS now supports block up to 1MB, but that is not default and > so far rare). I've made a test build and also successfully created UFS > file system with 128KB block -- not sure it is needed, but seems it > survives this change well too. > > Is there anything I am missing, or it is safe to rise this limit now? I see the following minor problems: - static and dynamic allocation of MAXBSIZE bytes would be more wasteful than before. - boot blocks used to do static allocation of MAXBSIZE bytes. Now they just do ffs's sanity check that the block size is less that that. A block size larger than this is not necessarily invalid, but just unsupported by the running instance of the buffer cache layer (so unsupported by the running instance of ffs too). Another or the same OS may have a larger MAXBSIZE, and the user may have broken portability by actually using this to create a file system that cannot be read by OS's with the historical MAXBSIZE. This check is bogus for boot blocks, since they don't use the buffer cache layer. ufsread.c uses a sort of anti-buffer-cache to avoid problems but give extreme slowness. It uses a virtual block size of 4K and does i/o 4K at a time with no caching. The buffer must not cross a 64K boundary on x86, and the MI code states this requirement for all arches. In i386/boot2, dmadat is 64K-aligned so the virtual buffer size could be up to 64K, except dmadat is used for 3 other buffers and only 4K is used for the data buffer. The data structure for this is: X /* Buffers that must not span a 64k boundary. */ X struct dmadat { X char blkbuf[VBLKSIZE]; /* filesystem blocks */ X char indbuf[VBLKSIZE]; /* indir blocks */ X char sbbuf[SBLOCKSIZE]; /* superblock */ X char secbuf[DEV_BSIZE]; /* for MBR/disklabel */ X }; X static struct dmadat *dmadat; I don't like the FreeBSD boot code, and use my version of biosboot if possible. I expanded its buffers and improved its caching a year or 2 ago. Old versions have 2 buffers of size MAXBSIZE in commented- out code since this doesn't work, especially when written in C. The commented-out code also sets a size of 4K for one of these buffers. This last worked, for the default ffs block size only, in about 1990 (this code is from Mach). The old code actually uses 3 buffers of size 8K, corresponding to 3 of the 4 buffers in dmadat. This broke about 15 years ago when the default and normal ffs block size was increased to 16K. I fixed this by allocating all of the buffers in asm. From start.S: X ENTRY(disklabel) X . = EXT(boot1) + 0x200 + 0*276 + 1*0x200 X X .globl EXT(buf) X .set EXT(buf), EXT(boot1) + 0x20000 X .globl EXT(iobuf) X .set EXT(iobuf), EXT(boot1) + 0x30000 X .globl EXT(mapbuf) X .set EXT(mapbuf), EXT(boot1) + 0x40000 boot1 is loaded at a 64K boundary and overlaid with boot2, the same as in the -current boot2. The above bits off 64K pieces of the heap for all large data structures. boot2 only (64K?) for dmadat instead, using hackish C code. Then I improved the caching. biosboot was using my old code which did caching mainly for floppies, since old systems were too slow to keep up with reading even floppies 1 512-block at a time. It used a read-ahead buffer of size 18*512 = 9K to optimize for floppies up to size 1440K. This worked OK for old hard disks with the old default ffs block size of 8K too. But it gives much the same anti-caching as -current's virtual 4K buffers when the ffs block size is 16K or larger. I didn't expand the cache to a large one on the heap, but just changed it to 32*512 = 16K to work well with my default ffs block size of 16K (32K is pessimal for my old disk), and fixed some alignment problems (the old code attempts to align on track boundaries but tracks don't exist for modern hard disks, and the alignment needs to be to ffs block boundaries else 16K-blocks would be split every time in the 16K "cache". Summary for the boot blocks: they seem to be unaffected by increasing MAXBSIZE, but their anti-cache works even better for fragmenting larger blocks. - the buffer cache is still optimized for i386 with BKVASIZE = 8K. 64-bit systems don't need the complications and pessimizations to fit in i386's limited kva, but have them anyway. When the default ffs block size was doubled to 16K, BKVASIZE was doubled to match, but the tuning wasn't doubled to match. This reduced the effective number of buffers by a factor of 2. This pessimization was mostly unnoticable, since memory sizes grew by more than a factor of 2 and and nbuf grew by about a factor of 2. But increasing (nbuf*BKVASIZE) much more isn't possible on i386 since it reaches a kva limit. Then when ffs's default block size was doubled to 32K, BKVASIZE wasn't even doubled to match. If anyone actually uses the doubled MAXBSIZE, then BKVASIZE will be mistuned by another factor of 2. They probably shouldn't do that. A block size of 64K already works poorly in ffs. Relative to a block size of 32K, It mainly doubles the size for metadata i/o without making much difference for data i/o, since data i/o is clustered. An fs block size equal to MAXPHYS also makes clustering useless, by limiting the maximum number of blocks per cluster to 1. That is better than the ratio of 4/32 in ufsread and 9/{8,16,32} in old biosboot, but still silly. Large fs block sizes (where "large" is about 2K) are only good when clustering doesn't work and the disk doesn't like small blocks. This may be the case for ffs on newer hard disks. Metdata is not clustered for ffs. My old hard disks like any size larger than 16K, but my not so old hard disks prefer 32K or above. nfs for zfs will actually use the new MAXBSIZE. I don't like it using a hard-coded size. It gives buffer cache fragmentation. The new MAXBSIZE will non-accidentally match the fs block size for zfs, but even the old MAXBSIZE doesn't match the usual fs block size for any file system. - cd9660 mount uses MAXBSIZE for a sanity check. It can only support block sizes up to that, but there must be an fs limit. It should probably use min(CD9660_MAXBSIZE, MAXBSIZE). - similarly in msdosfs, except I'm sure that there is an fs limit of 64K. Microsoft specifies that the limit is 32K, but 64K works in FreeBSD and perhaps even in Microsoft OS's. - similarly in ffs, except the ffs limit is historically identical to MAXBSIZE. I think it goes the other way -- MAXBSIZE = 64K is the historical ffs limit, and the buffer cache has to support that. Perhaps ffs should remain at its historical limit. The lower limit is still local in ffs. It is named MINBSIZE. Its value is 4K in -current but 512 in my version. ffs has no fundamental limit at either 4K or 64K, and can support any size supported by the hardware after fixing some bugs involving assumptions that the superblock fits in an ffs block. - many file systems use MAXBSIZE to limit the read-ahead for cluster_read(). This seems wrong. cluster_read() has a natural limit of geom's virtual "best" i/o size (normally MAXPHYS). The decision about the amount of read-ahead should be left to the clustering code if possible. But it is unclear what this should be. The clustering code gets this wrong anyway. It has sysctls vfs.read_max (default 64) and vfs.write_behind (default 1). The units for these are broken. They are fs-blocks. A read-ahead of 64 fs-blocks of size 512 is too different from a read-ahead of 64 fs-blocks of size MAXBSIZE whatever the latter is. My version uses a read-ahead scaled in 512-blocks (default 256 blocks = MAXPHYS bytes). The default read-ahead shouldn't vary much with either MAXPHYS, MAXBSIZE or the fs block size, but should vary with the device (don't read-ahead 64 large fs blocks on a floppy disk device, as asked for by -current's read_max ...). - ffs utilities like fsck are broken by limiting themselves to the buffer cache limit of MAXBSIZE, like the boot blocks but with less reason since they don't have space constraints and not being limited by the current OS is more useful. Unless MAXBSIZE = 64K is considered to be a private ffs that escaped. Then the ffs code should spell it FFS_MAXBSIZE or 64K. Bruce From owner-freebsd-fs@FreeBSD.ORG Sat Mar 28 12:22:39 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 08018A10 for ; Sat, 28 Mar 2015 12:22:39 +0000 (UTC) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) (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 A71FBC7F for ; Sat, 28 Mar 2015 12:22:37 +0000 (UTC) Received: from [192.168.0.183] (laptop1.herveybayaustralia.com.au [192.168.0.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id BF91C620B2; Sat, 28 Mar 2015 22:22:27 +1000 (EST) Message-ID: <55169D02.8090107@herveybayaustralia.com.au> Date: Sat, 28 Mar 2015 22:22:26 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Kirk McKusick , Benjamin Kaduk Subject: Re: Delete a directory, crash the system References: <201503251712.t2PHC1R8090290@chez.mckusick.com> In-Reply-To: <201503251712.t2PHC1R8090290@chez.mckusick.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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, 28 Mar 2015 12:22:39 -0000 On 26/03/2015 03:12, Kirk McKusick wrote: >> Date: Wed, 25 Mar 2015 00:25:19 -0400 (EDT) >> From: Benjamin Kaduk >> To: Da Rock >> Subject: Re: Delete a directory, crash the system >> Cc: freebsd-fs@freebsd.org, mckusick@freebsd.org >> >> On Tue, 24 Mar 2015, Da Rock wrote: >> >>> On 03/25/15 00:16, Benjamin Kaduk wrote: >>> Not precisely, but the message is just a flash and there is no copying of it. >>> Anyway, inode 4 is the .sujournal file as expected; this means there is an >>> issue with the softupdates. Could this be narrowing it down (the OP to this >>> was also in this age of enlightenment, SU came in with 8.x didn't it?)? >> Ah, SU+J could be quite relevant. Soft-update journalling was enabled by >> default for a period of time, but I believe it was disabled because there >> were some scenarios where it was destabilizing. CC-ing Kirk to improve on >> my lousy memory. > As far as I know SU+J is still on by default. > >> Do you remember what version was used to install the system in question >> (i.e., create the filesystem in question)? Please show the output of >> 'tunefs -p ' >> >>> So I did some fiddling with fsck, fsdb, find and stat; and got nowhere. I ran >>> fsck again and it gave me not much again. It did hint at some files in the >>> ports tree, so I cleaned up the ports tree to fresh install point, ran fsck >>> again and rebooted. So far so good, but I'm keeping my fingers crossed still. >> It is probably important to note that 'fsck -F' and saying 'no' to "USE >> JOURNAL?" is the most relevant fsck invocation. >> >>> This doesn't help the panics - they're still a pita when they happen. It does >>> help me resolve the issue this time though. But initiating this error in >>> testing is damn near impossible. What can we document here as a way to gather >>> data to determine how to resolve this issue? Given my luck with this, its >>> bound to happen again at some point :) >> I think actual diagnostic is beyond my expertise/time committment at the >> moment. I suspect that using tunefs to disable softupdate journalling >> will be a workaround, if that is what you are really interested. >> >> I'll let Kirk decide if he wants to debug more, but the answer may well be >> "no" if you're not running the latest ufs from -current. >> >> -Ben > The suggestion to disable journalling is a good one. Journalling fixes > only consistency errors that it knows about and cannot handle media errors. > The sorts of panics you are getting are usually caused by media errors. > So disabling journally and checking all metadata after crashes (which is > what fsck does) should minimize your problems. So my only option for journal is gjournal (slow) or zfs (memory hog) to maintain consistency; is that it? Incidentally, why keep SU+J on as default then? Wouldn't this be considered a bug still, then? From owner-freebsd-fs@FreeBSD.ORG Sat Mar 28 12:58:30 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 6C1A11F5; Sat, 28 Mar 2015 12:58:30 +0000 (UTC) Received: from puchar.net (puchar.net [188.252.31.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E5812FA5; Sat, 28 Mar 2015 12:58:29 +0000 (UTC) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.14.9/8.14.9) with ESMTP id t2SCwIfu082572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 28 Mar 2015 13:58:19 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from laptop.wojtek.intra (localhost [127.0.0.1]) by laptop.wojtek.intra (8.14.9/8.14.9) with ESMTP id t2SCwEfB000824; Sat, 28 Mar 2015 13:58:14 +0100 (CET) (envelope-from wojtek@puchar.net) Received: from localhost (wojtek@localhost) by laptop.wojtek.intra (8.14.9/8.14.9/Submit) with ESMTP id t2SCw9VZ000821; Sat, 28 Mar 2015 13:58:09 +0100 (CET) (envelope-from wojtek@puchar.net) X-Authentication-Warning: laptop.wojtek.intra: wojtek owned process doing -bs Date: Sat, 28 Mar 2015 13:58:09 +0100 (CET) From: Wojciech Puchar X-X-Sender: wojtek@laptop.wojtek.intra To: Alexander Motin Subject: Re: MAXBSIZE increase In-Reply-To: <5515C421.4040703@FreeBSD.org> Message-ID: References: <5515C421.4040703@FreeBSD.org> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (puchar.net [10.0.1.1]); Sat, 28 Mar 2015 13:58:20 +0100 (CET) Cc: freebsd-fs@FreeBSD.org, "freebsd-hackers@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, 28 Mar 2015 12:58:30 -0000 i routinely put options MAXPHYS=2097152 on my servers. no problems, except MUCH enhanced performance on large files. with UFS. SOME SSDs (few) doesn't work properly with >1MB requests. no idea about ZFS. with NFS do not ever expect good performance with it's sync mode. if you like to take a risk add vfs.nfsd.async=1 to sysctl.conf unless your NFS clients depend on forced syncs, the risk is actually no higher that running normal UFS filesystem locally. And performance is excellent. From owner-freebsd-fs@FreeBSD.ORG Sat Mar 28 17:13:21 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 BCF82247; Sat, 28 Mar 2015 17:13:21 +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 2DF39C43; Sat, 28 Mar 2015 17:13:21 +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 t2SHDFZ8056343 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 28 Mar 2015 19:13:15 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t2SHDFZ8056343 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t2SHDFlN056342; Sat, 28 Mar 2015 19:13:15 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 28 Mar 2015 19:13:15 +0200 From: Konstantin Belousov To: Alexander Motin Subject: Re: MAXBSIZE increase Message-ID: <20150328171315.GU2379@kib.kiev.ua> References: <5515C421.4040703@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5515C421.4040703@FreeBSD.org> 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, "freebsd-hackers@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, 28 Mar 2015 17:13:21 -0000 On Fri, Mar 27, 2015 at 10:57:05PM +0200, Alexander Motin wrote: > Hi. > > Experimenting with NFS and ZFS I found an inter-operation issue: ZFS by > default uses block of 128KB, while FreeBSD NFS (both client and server) > is limited to 64KB requests by the value of MAXBSIZE. On file rewrite > that limitation makes ZFS to do slow read-modify-write cycles for every > write operation, instead of just writing the new data. Trivial iozone > test show major difference between initial write and rewrite speeds > because of this issue. > > Looking through the sources I've found and in r280347 fixed number of > improper MAXBSIZE use cases in device drivers. After that I see no any > reason why MAXBSIZE can not be increased to at least 128KB to match ZFS > default (ZFS now supports block up to 1MB, but that is not default and > so far rare). I've made a test build and also successfully created UFS > file system with 128KB block -- not sure it is needed, but seems it > survives this change well too. > > Is there anything I am missing, or it is safe to rise this limit now? This post is useless after the Bruce explanation, but I still want to highlidht the most important point from that long story: increasing MAXBSIZE without tuning other buffer cache parameters would dis-balance the buffer cache. Allowing bigger buffers increases fragmentation, while limiting the total number of buffers. Also, it changes the tuning for runtime limits for amount of io in flight, see hi/lo runningspace initialization. From owner-freebsd-fs@FreeBSD.ORG Sat Mar 28 17:21:01 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 E78CB6B5; Sat, 28 Mar 2015 17:21:01 +0000 (UTC) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (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 88900D23; Sat, 28 Mar 2015 17:21:01 +0000 (UTC) Received: by wgdm6 with SMTP id m6so129733833wgd.2; Sat, 28 Mar 2015 10:21:00 -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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=1LxlOfOLUxU2KEooV0UB8p7GkDjYuebqp2Yl3dKx37E=; b=czemo3O70ZFPTpIKvn+HKdDo5xE7le6R/OtWrqe+kss7sZuLBmnI+RjH9nDbu5DoQz TSR9cs3Z9+MdJ/jtoYjjWfgAoueN5oUCiLJhyekhiVjf60g9Yw04eLOGiis7+1TbS/FN AB5ZQLJ2GgOhbiB2iIQcUdvU4EijvmRzQkgKFuVciE2nxQGH5Anpc0mdguqwSfdHEEIu ky6tXk67LEBNVHjIKqYeeGX4YGyxWicIj4eZwfQYXVGiPwr05T1QSnaDOxZR0uZmljfV DwDVWTkMMaQ4nj8AExPYw83ILWSKvqVaIqp3UEwCqniKjBjUsez4ydRVFpzmW2Ny3R4e es6Q== X-Received: by 10.194.185.68 with SMTP id fa4mr46456489wjc.111.1427563260021; Sat, 28 Mar 2015 10:21:00 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([134.249.139.101]) by mx.google.com with ESMTPSA id ga8sm7884714wib.11.2015.03.28.10.20.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 28 Mar 2015 10:20:59 -0700 (PDT) Sender: Alexander Motin Message-ID: <5516E2F9.20205@FreeBSD.org> Date: Sat, 28 Mar 2015 19:20:57 +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: Konstantin Belousov Subject: Re: MAXBSIZE increase References: <5515C421.4040703@FreeBSD.org> <20150328171315.GU2379@kib.kiev.ua> In-Reply-To: <20150328171315.GU2379@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, "freebsd-hackers@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, 28 Mar 2015 17:21:02 -0000 On 28.03.2015 19:13, Konstantin Belousov wrote: > On Fri, Mar 27, 2015 at 10:57:05PM +0200, Alexander Motin wrote: >> Experimenting with NFS and ZFS I found an inter-operation issue: ZFS by >> default uses block of 128KB, while FreeBSD NFS (both client and server) >> is limited to 64KB requests by the value of MAXBSIZE. On file rewrite >> that limitation makes ZFS to do slow read-modify-write cycles for every >> write operation, instead of just writing the new data. Trivial iozone >> test show major difference between initial write and rewrite speeds >> because of this issue. >> >> Looking through the sources I've found and in r280347 fixed number of >> improper MAXBSIZE use cases in device drivers. After that I see no any >> reason why MAXBSIZE can not be increased to at least 128KB to match ZFS >> default (ZFS now supports block up to 1MB, but that is not default and >> so far rare). I've made a test build and also successfully created UFS >> file system with 128KB block -- not sure it is needed, but seems it >> survives this change well too. >> >> Is there anything I am missing, or it is safe to rise this limit now? > > This post is useless after the Bruce explanation, but I still want to > highlidht the most important point from that long story: > > increasing MAXBSIZE without tuning other buffer cache parameters > would dis-balance the buffer cache. Allowing bigger buffers increases > fragmentation, while limiting the total number of buffers. Also, it > changes the tuning for runtime limits for amount of io in flight, see > hi/lo runningspace initialization. I would be happy if somebody with more skills in buffer cache brought some order into that area, hopefully once and forever. -- Alexander Motin From owner-freebsd-fs@FreeBSD.ORG Sat Mar 28 17:38:00 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 2CE0BE67 for ; Sat, 28 Mar 2015 17:38:00 +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 127ABE48 for ; Sat, 28 Mar 2015 17:38:00 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2SHbx7D070832 for ; Sat, 28 Mar 2015 17:37:59 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 198789] Panic while mounting an NANDFS filesystem Date: Sat, 28 Mar 2015 17:38:00 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: stefan.berndt@imoriath.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2015 17:38:00 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198789 --- Comment #1 from Stefan Berndt --- After some research i figured something out. Seems the used buffers are moved from in-core to not-in-core. The function "getblk" in src/sys/kern/vfs_bio.c (line 3064-3308) now needs to create a new buffer instead of using a existing in-core-buffer. This requires an correct set sector size in line 3230, but it is 0. Index: src/sys/fs/nandfs/nandfs_subr.c =================================================================== --- src/sys/fs/nandfs/nandfs_subr.c (revision 280320) +++ src/sys/fs/nandfs/nandfs_subr.c (working copy) @@ -210,6 +210,9 @@ DPRINTF(BLOCK, ("%s: vp:%p lbn:%#jx\n", __func__, NTOV(node), blocknr)); + if (node->nn_vnode->v_bufobj.bo_bsize == 0) + node->nn_vnode->v_bufobj.bo_bsize = 512; + error = bread(NTOV(node), blocknr, node->nn_nandfsdev->nd_blocksize, cred, bpp); This does the job, it is now working, but i don't belive it's the right way to do this. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Sat Mar 28 20:23:09 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 7F4005A6 for ; Sat, 28 Mar 2015 20:23:09 +0000 (UTC) Received: from smtp45.i.mail.ru (smtp45.i.mail.ru [94.100.177.105]) (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 005652E3 for ; Sat, 28 Mar 2015 20:23:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail2; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=Fuul2+PZd6Yxnmr/0HE3h+9HegLMUGsOLU8bOysiS7A=; b=fAqsoa6/XV+RcFYqTcOu6kv3+FJMyqmjscnBcCd7yLLvnzRqPnRS7rJtP9RioKsZDI3COso8GFhjVs85zQ4a4LipJ1VLqOKMBbl6KUve/phkaSg8YmOUlrobriLv/FakFYTEDrfr0C4SerAxU+AX2EVsA9PBYTXfzvYOKgDpgUY=; Received: from [79.172.119.174] (port=63434 helo=[192.168.0.160]) by smtp45.i.mail.ru with esmtpa (envelope-from ) id 1YbxFu-00066z-8p for freebsd-fs@freebsd.org; Sat, 28 Mar 2015 23:22:59 +0300 Message-ID: <55170D9C.1070107@artem.ru> Date: Sat, 28 Mar 2015 23:22:52 +0300 From: Artem Kuchin User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Little research how rm -rf and tar kill server Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok 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, 28 Mar 2015 20:23:09 -0000 I had a freebsd 9 server updated via buildkernel/buildworld last time in june 2014 and everything was fine. The server had 100+ web sites apache only, mysql database (40+ databases), imap server. 2x2TB seagate disks in geom mirror config, SU+J UFS. Every night incremental or full backup was done into tar.gz (gtar -czf) It never generated any problems. Sometimes i had to delete full sites with tone of files using rm -rf and it never caused any problem too. In february 2015 i migrated to a new server. Hardware. CPU is the same (some xeon 4 core + HT), ram is the same 32GB, disks now 2x3TB TOSHIBA, same geom mirror, same SU+J USF Freebsd is now 10-STABLE (updated via buildkernel/buildworld) I changed fronend to NGINX and it now serves all static files, back end is still Apache, switch fro mysql to MariaDB (it seems a lot faster) And in the first week i discovered two things: 1) untaring (tar -xf) a backup from tar.gz overloads the server 2) rm -rf overloads the server How overload looks like: Here is typical picture or normal operation: TOP: last pid: 60506; load averages: 1.10, 0.93, 0.86 up 30+16:00:32 18:25:22 563 processes: 2 running, 560 sleeping, 1 stopped CPU: 13.0% user, 0.0% nice, 2.4% system, 0.2% interrupt, 84.3% idle Mem: 2034M Active, 25G Inact, 3412M Wired, 20M Cache, 1656M Buf, 943M Free Swap: 4096M Total, 51M Used, 4045M Free, 1% Inuse systat -io /0% /10 /20 /30 /40 /50 /60 /70 /80 /90 /100 ada0 MB/s tps|XXXXXX ada1 MB/s tps|XXXXX mysql: show processlist 26 connection all in "sleep" (many request are executed, but hard to catch, too fast) Now, when i started tar -xf backup.tgz after about 5 minutes number of processed rise to 800, many in ufs state, mysql show processlist show about 200 requests in opening tables state, sysstat -io show tps over 1000 sites which use mysql stop responding, static sites work but slow, ssh loging takes very login time. I used pv to limit tgz reading bandwidth to 5MB/sec - did not help, the end of the world just started a little later. Then i accidentally did sync from shell and situation became better. So, i run the same untar command and added a script in parallel which did sync every 120 seconds - all problems went away. This is VERY strange, because man 2 sync says sync is done every 30 seconds anyway. Apparently not. Now, next i did cp -Rp a huge tree with tons of files - no such problems like with untar now i rm -rf test1 test1 has 4 levels of subdirs with tons reltivelly small files. Here is what i get after 3 minutes systat -io /0% /10 /20 /30 /40 /50 /60 /70 /80 /90 /100 ada0 MB/sXXXX tps|XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX298.54 ada1 MB/sXXXX tps|XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX298.94 top last pid: 69540; load averages: 2.48, 1.48, 1.16 up 30+16:55:02 19:19:52 767 processes: 2 running, 764 sleeping, 1 stopped CPU: 0.9% user, 0.0% nice, 0.3% system, 0.2% interrupt, 98.6% idle Mem: 8129M Active, 14G Inact, 3548M Wired, 333M Cache, 1655M Buf, 5722M Free Swap: 4096M Total, 51M Used, 4045M Free, 1% Inuse mysql show processlist 205 rows in opening table creating table Web servers are dead. I CTRL-C rm command sync took 230 seconds did not help, now 1000 processes, over 300 stuck sql requests killall -TERM httpd wait, not help sync 200 seconds mysql query queue is empty sysstat jumpt to 1000 then return to idle restart httpd everything is ok TEST 2 for rm rm -rf test1 sync every 60 seconds in parallel All the same problem, sync every 60 s did not help. TEST 3 for rm /usr/bin/nice -n20 rm -rf test1 All the same TEST 4 for rm /usr/bin/nice -n20 rm -rf test1 fsync every 60 seconds in parallel All the same So, questions and thoughts: 1) Why i had no problem such this in fbsd 9? I think the reason for the problem is in kernel, not in hardware or mariadb+nginx because server load did not increase at all, even decreases a little. 2) I consider it a sever bug, because even normal used (and i have plenty of them using ssh) can eventually do rm -rf and kill all sites. Which means there are must be some way to limit io usage per user Artem From owner-freebsd-fs@FreeBSD.ORG Sat Mar 28 21:41:19 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 67958A3 for ; Sat, 28 Mar 2015 21:41:19 +0000 (UTC) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) (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 24934D98 for ; Sat, 28 Mar 2015 21:41:18 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.9/8.14.9) with ESMTP id t2SLfGgo044831 for ; Sat, 28 Mar 2015 17:41:16 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.9/8.14.4/Submit) id t2SLfGWl044828; Sat, 28 Mar 2015 17:41:16 -0400 (EDT) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21783.8188.747673.152040@hergotha.csail.mit.edu> Date: Sat, 28 Mar 2015 17:41:16 -0400 From: Garrett Wollman To: freebsd-fs@freebsd.org Subject: Serious overflow/signedness issue in NFS server 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 (hergotha.csail.mit.edu [127.0.0.1]); Sat, 28 Mar 2015 17:41:16 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED, HEADER_FROM_DIFFERENT_DOMAINS autolearn=disabled version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on hergotha.csail.mit.edu 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, 28 Mar 2015 21:41:19 -0000 Yesterday I upgraded my production NFS servers to 10.1 from 9.3. Very quickly, my users ran into the kernel RPC's buffer space throttling mechanism. Besides having a stupidly low and arbitrary hard-coded limit, this code also has overflow bugs which which were exposed by the switch to clang as the system compiler. Please have a look at for what I think is going to be the fix, and if you have a FreeBSD phabricator account, please sign on as a reviewer. I'm sure there are other lingering overflow bugs in this code. -GAWollman From owner-freebsd-fs@FreeBSD.ORG Sat Mar 28 22:02: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 C4BAE5DF for ; Sat, 28 Mar 2015 22:02:23 +0000 (UTC) Received: from chez.mckusick.com (chez.mckusick.com [IPv6:2001:5a8:4:7e72:4a5b:39ff:fe12:452]) (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 A5BACFB8 for ; Sat, 28 Mar 2015 22:02:23 +0000 (UTC) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.3/8.14.3) with ESMTP id t2SM2KAn056827; Sat, 28 Mar 2015 15:02:20 -0700 (PDT) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201503282202.t2SM2KAn056827@chez.mckusick.com> To: Da Rock Subject: Re: Delete a directory, crash the system In-reply-to: <55169D02.8090107@herveybayaustralia.com.au> Date: Sat, 28 Mar 2015 15:02:20 -0700 From: Kirk McKusick 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, 28 Mar 2015 22:02:23 -0000 > Date: Sat, 28 Mar 2015 22:22:26 +1000 > From: Da Rock > To: Kirk McKusick , Benjamin Kaduk > CC: freebsd-fs@freebsd.org > Subject: Re: Delete a directory, crash the system > X-ASK-Info: Message Queued (2015/03/28 05:22:36) > X-ASK-Info: Confirmed by User (2015/03/28 14:35:33) > > On 26/03/2015 03:12, Kirk McKusick wrote: > >> The suggestion to disable journalling is a good one. Journalling fixes >> only consistency errors that it knows about and cannot handle media errors. >> The sorts of panics you are getting are usually caused by media errors. >> So disabling journally and checking all metadata after crashes (which is >> what fsck does) should minimize your problems. > > So my only option for journal is gjournal (slow) or zfs (memory hog) to > maintain consistency; is that it? Incidentally, why keep SU+J on as > default then? Wouldn't this be considered a bug still, then? SU without journaling will maintain consistency. It is just that you will need to run fsck after a crash. That is the way FFS has been since it was written in 1982 and will allow you to recover from media errors which it appears your system is suffering from. SU+J is just a faster way of restarting but only works when you do not have media errors. Kirk McKusick From owner-freebsd-fs@FreeBSD.ORG Sat Mar 28 22:24:33 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 687E5AE5 for ; Sat, 28 Mar 2015 22:24:33 +0000 (UTC) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) (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 1C08E1E1 for ; Sat, 28 Mar 2015 22:24:32 +0000 (UTC) Received: from laptop2.herveybayaustralia.com.au (laptop2.herveybayaustralia.com.au [192.168.0.185]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id 33D6A620A0; Sun, 29 Mar 2015 08:24:27 +1000 (EST) Message-ID: <55172A18.70601@herveybayaustralia.com.au> Date: Sun, 29 Mar 2015 08:24:24 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Kirk McKusick Subject: Re: Delete a directory, crash the system References: <201503282202.t2SM2KAn056827@chez.mckusick.com> In-Reply-To: <201503282202.t2SM2KAn056827@chez.mckusick.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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, 28 Mar 2015 22:24:33 -0000 On 03/29/15 08:02, Kirk McKusick wrote: >> Date: Sat, 28 Mar 2015 22:22:26 +1000 >> From: Da Rock >> To: Kirk McKusick , Benjamin Kaduk >> CC: freebsd-fs@freebsd.org >> Subject: Re: Delete a directory, crash the system >> X-ASK-Info: Message Queued (2015/03/28 05:22:36) >> X-ASK-Info: Confirmed by User (2015/03/28 14:35:33) >> >> On 26/03/2015 03:12, Kirk McKusick wrote: >> >>> The suggestion to disable journalling is a good one. Journalling fixes >>> only consistency errors that it knows about and cannot handle media errors. >>> The sorts of panics you are getting are usually caused by media errors. >>> So disabling journally and checking all metadata after crashes (which is >>> what fsck does) should minimize your problems. >> So my only option for journal is gjournal (slow) or zfs (memory hog) to >> maintain consistency; is that it? Incidentally, why keep SU+J on as >> default then? Wouldn't this be considered a bug still, then? > SU without journaling will maintain consistency. It is just that you > will need to run fsck after a crash. That is the way FFS has been since > it was written in 1982 and will allow you to recover from media errors > which it appears your system is suffering from. SU+J is just a faster > way of restarting but only works when you do not have media errors. I guess the point I'm driving at is that on a server this may be an ok solution, but if you have workstations/desktops with users who don't know how to do this properly, that is why the journalling is an important feature. So its not just about faster restarts, but a simple reboot/boot and everything is basically ok for them. If there is any issue a system squawk at the sysadmin will then allow them to come in at some point to run a proper check. But in this case, we have a system which effectively crashes if there is a problem. So thats why I mentioned the only other journal type fs' in freebsd, because in this scenario a journal is required and it appears these are the only alternative that don't create such a catastrophic effect. Having made my point, what could be done about it - and what can I do to help? Would drive details provide data required to pick up the solution?