From owner-freebsd-fs@freebsd.org Sun Jan 24 20:51:27 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9F4647654 for ; Sun, 24 Jan 2016 20:51:27 +0000 (UTC) (envelope-from zebekias@gmail.com) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5C913198B for ; Sun, 24 Jan 2016 20:51:27 +0000 (UTC) (envelope-from zebekias@gmail.com) Received: by mail-qg0-x22d.google.com with SMTP id b35so95353020qge.0 for ; Sun, 24 Jan 2016 12:51:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:mime-version:subject :message-id:date:to; bh=K6lg8T5ZfwGrrn2lAThDnkKj1cxoPjTouojFFz3ZzRs=; b=eqwNlZlWSBeYWFd0I/dQ9ZjWNXaotOW4RuN/yZd606vzD7TDxDaGfJEr11092IYaUZ i6BVgpTvFf/iI2GGBJ8AdlbGjXtmOb1FExxcbCuWPScDtZ57OiCVSjo0+A0mcW73cB9P 6LLbrOSKpWLZ5eapqgunyxyggfKW7pVyoMDXdoAoX3KDQ9VL/q71RFLxiK1NFM8rMqhP FJZtXw7KxMZZNgcsdSmpm6r9gwIz8KhYDJB+X4qJxl7v/qZM1VxdWGnK3zqmfvVuDynm nam7fCXcsQfJZNXO+eSAe/FHIwzKUd2DL4XRuETiX10pZ2bEm080n6V+SGKi4q623hnG F0sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :mime-version:subject:message-id:date:to; bh=K6lg8T5ZfwGrrn2lAThDnkKj1cxoPjTouojFFz3ZzRs=; b=SjMWhC9MaHSdtGF8NhcZbapsKoURKf3telSwCxEpyoRupjUt5lvpT3xR8zEjV885hD hG1y7bYb75WQvHU3Nt2DAWaXOuu1Gedyd17CnYDjfURT6bnZPiGht76QzYAcYkCI7Rgs kifeZe6ecn1iL4f2c1C1N0q7lZ2qCcHceNp6Gwfg43UFs3YbBSe7MUdIp4ZnkIBO0Y54 /Jhk1EhPTpzd6jalOPPbMCLYCkHX2DEn7xKBADne/CS6RbQZRbFVFo/l+ypMdt6yrA+2 pErCb9mg2LsYUFMQAKjjDtnh6BMmUZUtTblhfocthxA/BYYlBd6R/OdfS+f4OfFExNG6 rp+Q== X-Gm-Message-State: AG10YOQFpjjud9f+z3u51O7pql2arJ7OsqfK2Pv5ENal6j7kMwAIvmOVRDS8+KxHlaLHkA== X-Received: by 10.140.31.197 with SMTP id f63mr17118368qgf.12.1453668686461; Sun, 24 Jan 2016 12:51:26 -0800 (PST) Received: from [192.168.1.101] (static-71-246-239-3.washdc.fios.verizon.net. [71.246.239.3]) by smtp.gmail.com with ESMTPSA id t187sm7419788qht.39.2016.01.24.12.51.24 for (version=TLSv1/SSLv3 cipher=OTHER); Sun, 24 Jan 2016 12:51:25 -0800 (PST) From: Kiriakos Georgiou Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: zfs - reboot after panic Message-Id: Date: Sun, 24 Jan 2016 15:51:24 -0500 To: freebsd-fs@freebsd.org X-Mailer: iPad Mail (13D15) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 20:51:27 -0000 Hello, I've been happily running a FreeBSD 10.1 fileserver (updated regularly via f= reebsd-update) with ZFS zvols served out via iscsi. Total RAM is 8G. For 2-= 3 months I regularly successfully run some heavy duty checksuming via unison= (it's kind of like rsync, but does bidirectional syncing). I recently upda= ted the OS to 10.1-RELEASE-p26, and soon after I started to consistently get= kernel panics when I run unison to sync certain files across my VMs: reboot after panic: I/O to pool 'zdata' appears to be hung on vdev guid ....= First I thought a bug must have been introduced, but after some googling I s= et my vfs.zfs.arc_max to 4G (50% of my ram) and hammered zfs via a massive u= nison sync. I monitored memory via top. ARC grew quickly to 4096M and stay= ed there. Free memory would slowly drop all the way to just under 1G but th= en it'd suddenly jump to over 2G, then slowly go down to 1G and jump to 2G a= gain so on. I suspect it was a RAM starvation issue that is now resolved by= tuning the ARC max. I've no idea why it started happening. I just wanted t= o share it with you. Does the "fix" make sense? Thanks, Kiriakos= From owner-freebsd-fs@freebsd.org Sun Jan 24 21:01:08 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 285A37B58 for ; Sun, 24 Jan 2016 21:01:08 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 075971F7F for ; Sun, 24 Jan 2016 21:01:08 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0OL01hJ036435 for ; Sun, 24 Jan 2016 21:01:07 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201601242101.u0OL01hJ036435@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 Date: Sun, 24 Jan 2016 21:01:07 +0000 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 21:01:08 -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 ------------+-----------+--------------------------------------------------- New | 203492 | mount_unionfs -o below causes panic 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 4 problems total for which you should take action. From owner-freebsd-fs@freebsd.org Mon Jan 25 08:26:20 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9D5CD7376 for ; Mon, 25 Jan 2016 08:26:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8E6636C4 for ; Mon, 25 Jan 2016 08:26:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0P8QJfO065786 for ; Mon, 25 Jan 2016 08:26:20 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 206521] Can't decrypt disks on ZFS+Geli installation after order of devices changed Date: Mon, 25 Jan 2016 08:26:19 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org 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: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 08:26:20 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206521 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Tue Jan 26 06:09:05 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BE7B5A468F1 for ; Tue, 26 Jan 2016 06:09:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AE7CBBD3 for ; Tue, 26 Jan 2016 06:09:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0Q695e4087962 for ; Tue, 26 Jan 2016 06:09:05 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 206634] "panic: ncllock1" from FreeBSD client after NFSv4 server was taken offline and brought back to life; lots of spam about "protocol prob err=10006" Date: Tue, 26 Jan 2016 06:09:05 +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 Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org 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: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 06:09:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206634 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Tue Jan 26 16:17:50 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 81A7CA46950 for ; Tue, 26 Jan 2016 16:17:50 +0000 (UTC) (envelope-from marieheleneka@gmail.com) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::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 0ECF3EA7 for ; Tue, 26 Jan 2016 16:17:50 +0000 (UTC) (envelope-from marieheleneka@gmail.com) Received: by mail-wm0-x235.google.com with SMTP id n5so138965449wmn.0 for ; Tue, 26 Jan 2016 08:17:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=rsG5crRDxjmfTZF0iRSMNfPORJs5fxDmrhDRIsZb0Mk=; b=MhwhuaGmgBu5+lfQ84MtuFqhFSI0EwElNE4aVcK5eMW3vbKH9M6Db7j7s88q2ClNef eyQDx6TdEe43jSbMm5V7og+fCcdgK90J0MsMz6A9hw02LOvNnmFGwJktdGLLCSLEvnJl GagV9EkitNt0MF38fmkOJP9Wd3bFP6MQgIw8N5WhX8h0+RlSSqC2kvGkGanpdAESzXJs KtnbNmUaA9/zwNxgVVhXycViUjxPdTfub5n+1tDG/RxtvVV0GK1pfe3OCYM6isi8imQj iVGlp8BdX+uJ47i0OooiHAmsWz3Yi2iksvVrx3QHlSOHm9gcvsobPg3M8JL52fHcgN5C 8qBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=rsG5crRDxjmfTZF0iRSMNfPORJs5fxDmrhDRIsZb0Mk=; b=BXWpaEUCZZ0yWn13AQqMUNr2qOGoiWBFV3iwqHNWwXNhRcLsE1cNc0r6lH0zkKMvy8 40yxrwi5/twKa1Yq44dwxUPB1kTF0tu+uNFCMDczoGQugTwVHaU7x+Y4JUUmDVbALFMu F8MqD0Od+T3d4KSpKaz6VcBeqZmmmYhJKV5bIwF0EXOLu7Rld5w943/seUzT6kk/dPaa wJBXoXahYd/JOfEyxUE87ZmprojoG7FlQhJy+RtYsziT7B/gdL6rcN5tEbWZlxsdxYFe 8KQjCDusBKlJNMjYe05pnaw5UTkuqkECpa5Jd5ylqPlJTdQCKB4bSPQqjhj2FG2SRfuR BAng== X-Gm-Message-State: AG10YORpod8yxzuSXtPiDVaKhWWzxZhPZwfEEJvM8dPp228vXLgla5c4nm5tQ+QhZgYCtrP86K+6KklyDoKNWA== X-Received: by 10.28.180.193 with SMTP id d184mr23930572wmf.64.1453825068564; Tue, 26 Jan 2016 08:17:48 -0800 (PST) MIME-Version: 1.0 From: Marie Helene Kvello-Aune Date: Tue, 26 Jan 2016 16:17:38 +0000 Message-ID: Subject: ZFS bug: zpool expandz says 16.0E, clearly wrong To: freebsd-fs@freebsd.org Content-Type: multipart/mixed; boundary=001a114acd30c720e0052a3f062a X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 16:17:50 -0000 --001a114acd30c720e0052a3f062a Content-Type: text/plain; charset=UTF-8 I've stumbled across a curiosity with my zpool. The command 'zpool list' states that the EXPANDZ property/value is 16.0E. This is clearly incorrect. :) The pool consist of a single RaidZ2 vdev of 6 drives, and two cache drives. No log device. Executing 'zpool list -v' shows that each member of the RaidZ2 has an 'EXPANDZ' value of '-', as expected. But the RaidZ2 itself, and the pool, has a EXPANDZ value of 16.0E. Each member of the RaidZ2 vdev is a GELI encrypted partition. # uname -a FreeBSD saturn 10.3-PRERELEASE FreeBSD 10.3-PRERELEASE #1 r294289: Mon Jan 18 21:22:41 CET 2016 root@saturn:/usr/obj/usr/src/sys/GENERIC amd64 (It was built from 10-STABLE) Once I discovered this curiosity I started a scrub, which is scheduled to finish in about 7 hours from now. It seems to be done scanning the zpool metadata and haven't repaired anything yet. Output of zpool list, zpool list -v, zpool history and zfs list are attached. Anyone have any idea how to figure out what has happened here? Regards, Marie Helene Kvello-Aune marieheleneka@gmail.com --001a114acd30c720e0052a3f062a Content-Type: text/plain; charset=US-ASCII; name="command_output.txt" Content-Disposition: attachment; filename="command_output.txt" Content-Transfer-Encoding: base64 Content-ID: <1527eb4194e5333e5771> X-Attachment-Id: 1527eb4194e5333e5771 IyB6cG9vbCBsaXN0IHN0b3JhZ2UNCk5BTUUgICAgICBTSVpFICBBTExPQyAgIEZSRUUgIEVYUEFO RFNaICAgRlJBRyAgICBDQVAgIERFRFVQICBIRUFMVEggIEFMVFJPT1QNCnN0b3JhZ2UgIDIxLjZU ICA0LjA3VCAgMTcuNlQgICAgIDE2LjBFICAgIDExJSAgICAxOCUgIDEuMDB4ICBPTkxJTkUgIC0N Cg0KIyB6cG9vbCBsaXN0IC12IHN0b3JhZ2UNCk5BTUUgICAgICAgICAgICAgICBTSVpFICBBTExP QyAgIEZSRUUgIEVYUEFORFNaICAgRlJBRyAgICBDQVAgIERFRFVQICBIRUFMVEggIEFMVFJPT1QN CnN0b3JhZ2UgICAgICAgICAgIDIxLjZUICA0LjA3VCAgMTcuNlQgICAgIDE2LjBFICAgIDExJSAg ICAxOCUgIDEuMDB4ICBPTkxJTkUgIC0NCiAgcmFpZHoyICAgICAgICAgIDIxLjZUICA0LjA3VCAg MTcuNlQgICAgIDE2LjBFICAgIDExJSAgICAxOCUNCiAgICBncHQvQmF5MS5lbGkgICAgICAtICAg ICAgLSAgICAgIC0gICAgICAgICAtICAgICAgLSAgICAgIC0NCiAgICBncHQvQmF5Mi5lbGkgICAg ICAtICAgICAgLSAgICAgIC0gICAgICAgICAtICAgICAgLSAgICAgIC0NCiAgICBncHQvQmF5My5l bGkgICAgICAtICAgICAgLSAgICAgIC0gICAgICAgICAtICAgICAgLSAgICAgIC0NCiAgICBncHQv QmF5NC5lbGkgICAgICAtICAgICAgLSAgICAgIC0gICAgICAgICAtICAgICAgLSAgICAgIC0NCiAg ICBncHQvQmF5NS5lbGkgICAgICAtICAgICAgLSAgICAgIC0gICAgICAgICAtICAgICAgLSAgICAg IC0NCiAgICBncHQvQmF5Ni5lbGkgICAgICAtICAgICAgLSAgICAgIC0gICAgICAgICAtICAgICAg LSAgICAgIC0NCmNhY2hlICAgICAgICAgICAgICAgICAtICAgICAgLSAgICAgIC0gICAgICAgICAt ICAgICAgLSAgICAgIC0NCiAgZ3B0L2NhY2hlMC5lbGkgIDguMDBHICA3Ljk4RyAgMTUuNE0gICAg ICAgICAtICAgICAwJSAgICA5OSUNCiAgZ3B0L2NhY2hlMS5lbGkgIDguMDBHICA3Ljk4RyAgMTYu M00gICAgICAgICAtICAgICAwJSAgICA5OSUNCg0KDQojIHpwb29sIGhpc3Rvcnkgc3RvcmFnZQ0K SGlzdG9yeSBmb3IgJ3N0b3JhZ2UnOg0KMjAxNS0xMi0yNi4xNjoxNDo0MyB6cG9vbCBjcmVhdGUg c3RvcmFnZSByYWlkejIgL2Rldi9ncHQvQmF5MSAvZGV2L2dwdC9CYXkyIC9kZXYvZ3B0L0JheTMg L2Rldi9ncHQvQmF5NCAvZGV2L2dwdC9CYXk1IC9kZXYvZ3B0L0JheTYgY2FjaGUgL2Rldi9ncHQv Y2FjaGUwIC9kZXYvZ3B0L2NhY2hlMQ0KMjAxNS0xMi0yNi4xNjozMDo0MCB6ZnMgY3JlYXRlIHN0 b3JhZ2UvamFpbHMNCjIwMTUtMTItMjYuMTY6MzA6NDcgemZzIGNyZWF0ZSBzdG9yYWdlL2lTQ1NJ DQoyMDE1LTEyLTI2LjE2OjMwOjUxIHpmcyBjcmVhdGUgc3RvcmFnZS9DSUZTDQoyMDE1LTEyLTI2 LjE2OjMxOjA0IHpmcyBjcmVhdGUgc3RvcmFnZS9DSUZTL2JpbGRlcg0KMjAxNS0xMi0zMC4wMDox NzoyMyB6cG9vbCBvZmZsaW5lIHN0b3JhZ2UgZ3B0L0JheTENCjIwMTUtMTItMzAuMDA6MjA6Mzkg enBvb2wgcmVwbGFjZSBzdG9yYWdlIGdwdC9CYXkxIGdwdC9CYXkxLmVsaQ0KMjAxNS0xMi0zMC4w MDoyMTowMCB6cG9vbCBvZmZsaW5lIHN0b3JhZ2UgZ3B0L0JheTINCjIwMTUtMTItMzAuMDA6MjE6 MDUgenBvb2wgb2ZmbGluZSBzdG9yYWdlIGdwdC9CYXkzDQoyMDE1LTEyLTMwLjAwOjIxOjI4IHpw b29sIHJlcGxhY2Ugc3RvcmFnZSBncHQvQmF5MiBncHQvQmF5Mi5lbGkNCjIwMTUtMTItMzAuMDA6 MjE6MzQgenBvb2wgcmVwbGFjZSBzdG9yYWdlIGdwdC9CYXkzIGdwdC9CYXkzLmVsaQ0KMjAxNS0x Mi0zMC4wMDoyMTo0NiB6cG9vbCBvZmZsaW5lIHN0b3JhZ2UgZ3B0L0JheTQNCjIwMTUtMTItMzAu MDA6MjE6NTIgenBvb2wgb2ZmbGluZSBzdG9yYWdlIGdwdC9CYXk1DQoyMDE1LTEyLTMwLjAwOjIy OjExIHpwb29sIHJlcGxhY2Ugc3RvcmFnZSBncHQvQmF5NCBncHQvQmF5NC5lbGkNCjIwMTUtMTIt MzAuMDA6MjI6MTYgenBvb2wgcmVwbGFjZSBzdG9yYWdlIGdwdC9CYXk1IGdwdC9CYXk1LmVsaQ0K MjAxNS0xMi0zMC4wMDoyMjoyOSB6cG9vbCBvZmZsaW5lIHN0b3JhZ2UgZ3B0L0JheTYNCjIwMTUt MTItMzAuMDA6MjI6MzQgenBvb2wgcmVwbGFjZSBzdG9yYWdlIGdwdC9CYXk2IGdwdC9CYXk2LmVs aQ0KMjAxNS0xMi0zMC4wMDoyNDowMCB6cG9vbCByZW1vdmUgc3RvcmFnZSBncHQvY2FjaGUwDQoy MDE1LTEyLTMwLjAwOjI0OjA1IHpwb29sIHJlbW92ZSBzdG9yYWdlIGdwdC9jYWNoZTENCjIwMTUt MTItMzAuMDA6MjU6NTEgenBvb2wgZXhwb3J0IHN0b3JhZ2UNCjIwMTUtMTItMzAuMDA6MjY6MDMg enBvb2wgaW1wb3J0IHN0b3JhZ2UNCjIwMTUtMTItMzAuMDA6MjY6MDggenBvb2wgYWRkIHN0b3Jh Z2UgY2FjaGUgZ3B0L2NhY2hlMC5lbGkNCjIwMTUtMTItMzAuMDA6MjY6MTQgenBvb2wgYWRkIHN0 b3JhZ2UgY2FjaGUgZ3B0L2NhY2hlMS5lbGkNCjIwMTUtMTItMzAuMDA6MjY6NTcgenBvb2wgcmVt b3ZlIHN0b3JhZ2UgZ3B0L2NhY2hlMC5lbGkNCjIwMTUtMTItMzAuMDA6Mjc6MDIgenBvb2wgcmVt b3ZlIHN0b3JhZ2UgZ3B0L2NhY2hlMS5lbGkNCjIwMTUtMTItMzAuMDA6Mjc6MzkgenBvb2wgYWRk IHN0b3JhZ2UgY2FjaGUgZ3B0L2NhY2hlMC5lbGkNCjIwMTUtMTItMzAuMDA6Mjc6NDQgenBvb2wg YWRkIHN0b3JhZ2UgY2FjaGUgZ3B0L2NhY2hlMS5lbGkNCjIwMTUtMTItMzAuMDA6MzE6MTggenBv b2wgc2NydWIgc3RvcmFnZQ0KMjAxNS0xMi0zMC4wMDozMTo0OSB6cG9vbCBzY3J1YiBzdG9yYWdl DQoyMDE1LTEyLTMwLjAwOjM2OjAxIHpwb29sIHJlbW92ZSBzdG9yYWdlIGdwdC9jYWNoZTAuZWxp DQoyMDE1LTEyLTMwLjAwOjM2OjA2IHpwb29sIHJlbW92ZSBzdG9yYWdlIGdwdC9jYWNoZTEuZWxp DQoyMDE1LTEyLTMwLjAwOjM3OjA1IHpwb29sIGFkZCBzdG9yYWdlIGNhY2hlIGdwdC9jYWNoZTAu ZWxpIGdwdC9jYWNoZTEuZWxpDQoyMDE1LTEyLTMwLjIzOjIwOjUzIHpmcyBjcmVhdGUgc3RvcmFn ZS9qYWlscy9zYW1iYQ0KMjAxNS0xMi0zMC4yMzoyMjo1OSB6ZnMgc2V0IGNvbXByZXNzPWx6NCBz dG9yYWdlL2phaWxzDQoyMDE1LTEyLTMwLjIzOjIzOjAyIHpmcyBkZXN0cm95IHN0b3JhZ2UvamFp bHMvc2FtYmENCjIwMTUtMTItMzAuMjM6MjM6MTcgemZzIGNyZWF0ZSAtbyBxdW90YT0yZyBzdG9y YWdlL2phaWxzL3NhbWJhDQoyMDE1LTEyLTMwLjIzOjI3OjM4IHpmcyBzZXQgbW91bnRwb2ludD0v dXNyL2phaWxzIHN0b3JhZ2UvamFpbHMNCjIwMTUtMTItMzAuMjM6Mjg6NDMgemZzIHNldCBtb3Vu dHBvaW50PS91c3IvamFpbHMvc2FtYmEvbWVkaWEgc3RvcmFnZS9DSUZTDQoyMDE1LTEyLTMwLjIz OjMxOjU1IHpmcyBzZXQgamFpbGVkPW9uIHN0b3JhZ2UvQ0lGUw0KMjAxNS0xMi0zMC4yMzo0NToz NCB6ZnMgc2V0IG1vdW50cG9pbnQ9L21lZGlhIHN0b3JhZ2UvQ0lGUw0KMjAxNS0xMi0zMS4wMDox MjowNiB6ZnMgc2V0IHF1b3RhPTF0IHN0b3JhZ2UvQ0lGUy9iaWxkZXINCjIwMTYtMDEtMDEuMjM6 MzA6MjQgemZzIGNyZWF0ZSAtbyBtb3VudHBvaW50PW5vbmUgLW8gdm9sbW9kZT1kZXYgc3RvcmFn ZS9iaHl2ZQ0KMjAxNi0wMS0wMS4yMzozMDo0MyB6ZnMgc2V0IGNvbXByZXNzPWx6NCBzdG9yYWdl L2JoeXZlDQoyMDE2LTAxLTAxLjIzOjM0OjE3IHpmcyBjcmVhdGUgLVYgMzJnIC1iIDRrIHN0b3Jh Z2UvYmh5dmUvdGVzdA0KMjAxNi0wMS0wMS4yMzozODowMiB6ZnMgY3JlYXRlIC1vIGNvbXByZXNz PWd6aXAtOSBzdG9yYWdlL0lTTw0KMjAxNi0wMS0wMS4yMzo1Nzo0MiB6ZnMgc2V0IHZtOmNwdT0x IHN0b3JhZ2UvYmh5dmUNCjIwMTYtMDEtMDEuMjM6NTc6NTAgemZzIHNldCB2bTptZW1vcnk9NTEy IHN0b3JhZ2UvYmh5dmUNCjIwMTYtMDEtMDEuMjM6NTg6MzMgemZzIGNyZWF0ZSBzdG9yYWdlL2Jo eXZlL3NtYWxsDQoyMDE2LTAxLTAxLjIzOjU4OjU0IHpmcyByZW5hbWUgc3RvcmFnZS9iaHl2ZS90 ZXN0IHN0b3JhZ2UvYmh5dmUvc21hbGwvdGVzdA0KMjAxNi0wMS0wMS4yMzo1OToxMyB6ZnMgaW5o ZXJpdCB2bTpjcHUgc3RvcmFnZS9iaHl2ZQ0KMjAxNi0wMS0wMS4yMzo1OToxOCB6ZnMgaW5oZXJp dCB2bTptZW1vcnkgc3RvcmFnZS9iaHl2ZQ0KMjAxNi0wMS0wMS4yMzo1OToyNSB6ZnMgc2V0IHZt Om1lbW9yeT01MTIgc3RvcmFnZS9iaHl2ZS9zbWFsbA0KMjAxNi0wMS0wMS4yMzo1OTozMiB6ZnMg c2V0IHZtOmNwdT0xIHN0b3JhZ2UvYmh5dmUvc21hbGwNCjIwMTYtMDEtMDIuMDA6MDA6NDMgemZz IHNldCB2bTppbnRlcmZhY2U6MD10YXAwIHN0b3JhZ2UvYmh5dmUvc21hbGwvdGVzdA0KMjAxNi0w MS0wMi4wMDoyOToxMCB6ZnMgY3JlYXRlIC1WIDE2ZyAtYiA0ayBzdG9yYWdlL2JoeXZlL3NtYWxs L3Rlc3QyDQoyMDE2LTAxLTAyLjAwOjI5OjM0IHpmcyBzZXQgdm06ZW5hYmxlZD1OTyBzdG9yYWdl L2JoeXZlDQoyMDE2LTAxLTAyLjAwOjM0OjMyIHpmcyBzZXQgdm06ZW5hYmxlZD1ZRVMgc3RvcmFn ZS9iaHl2ZS9zbWFsbC90ZXN0DQoyMDE2LTAxLTAyLjAwOjM0OjM3IHpmcyBzZXQgdm06ZW5hYmxl ZD1ZRVMgc3RvcmFnZS9iaHl2ZS9zbWFsbC90ZXN0Mg0KMjAxNi0wMS0wMi4wMDozNDo0OSB6ZnMg Y3JlYXRlIC1WIDE2ZyAtYiA0ayBzdG9yYWdlL2JoeXZlL3NtYWxsL3Rlc3QzDQoyMDE2LTAxLTAy LjAwOjM5OjA3IHpmcyBzZXQgdm06aW50ZXJmYWNlcz0xIHN0b3JhZ2UvYmh5dmUvc21hbGwvdGVz dA0KMjAxNi0wMS0wMi4wMDozOTozMCB6ZnMgaW5oZXJpdCB2bTppbnRlcmZhY2U6MCBzdG9yYWdl L2JoeXZlL3NtYWxsL3Rlc3QNCjIwMTYtMDEtMDIuMDA6Mzk6NDAgemZzIHNldCB2bTppbnRlcmZh Y2VzPXRhcDAgdGFwMSBzdG9yYWdlL2JoeXZlL3NtYWxsL3Rlc3QNCjIwMTYtMDEtMDIuMDI6MDk6 NDMgemZzIHJlbmFtZSBzdG9yYWdlL2JoeXZlL3NtYWxsL3Rlc3Qgc3RvcmFnZS9iaHl2ZS9zbWFs bC90ZXN0MQ0KMjAxNi0wMS0wMy4wNjozOTo0NSB6ZnMgY3JlYXRlIHN0b3JhZ2UvamFpbHMvemFi Yml4DQoyMDE2LTAxLTAzLjA2OjQwOjAyIHpmcyBzZXQgcXVvdGE9OGcgc3RvcmFnZS9qYWlscy96 YWJiaXgNCjIwMTYtMDEtMDMuMDY6NDA6NTMgemZzIHNldCBxdW90YT0xdCBzdG9yYWdlL2phaWxz DQoyMDE2LTAxLTAzLjA2OjQwOjU4IHpmcyBzZXQgcXVvdGE9MTI4ZyBzdG9yYWdlL2phaWxzDQoy MDE2LTAxLTE4LjIyOjA1OjQyIHpmcyBzZXQgcmVjb3Jkc2l6ZT0xbSBzdG9yYWdlL0NJRlMNCjIw MTYtMDEtMTguMjI6MzQ6MTYgemZzIHNldCBjb21wcmVzcz1sejQgc3RvcmFnZS9DSUZTL2JpbGRl cg0KMjAxNi0wMS0xOC4yMjozNDozMyB6ZnMgc2V0IGNvbXByZXNzPW9mZiBzdG9yYWdlL0NJRlMv YmlsZGVyDQoyMDE2LTAxLTE5LjE0OjQ5OjQ1IHpmcyBjcmVhdGUgLW8gcXVvdGE9MjU2ZyAtbyBj b21wcmVzcz1nemlwLTkgc3RvcmFnZS9DSUZTL2Rvd25sb2Fkcw0KMjAxNi0wMS0xOS4xNDo1NDox MyB6ZnMgc2V0IGphaWxlZD1vZmYgc3RvcmFnZS9DSUZTDQoyMDE2LTAxLTE5LjE1OjAwOjA0IHpm cyBzZXQgbW91bnRwb2ludD0vbW50L3N0b3JhZ2Ugc3RvcmFnZQ0KMjAxNi0wMS0xOS4xNTowMDox NSB6ZnMgaW5oZXJpdCBtb3VudHBvaW50IHN0b3JhZ2UvQ0lGUw0KMjAxNi0wMS0yMS4wOToyMDo1 MyB6ZnMgY3JlYXRlIC1vIHF1b3RhPTRnIHN0b3JhZ2UvamFpbHMvYW5zaWJsZQ0KMjAxNi0wMS0y MS4wOToyMzo0MyB6ZnMgcmVuYW1lIHN0b3JhZ2UvamFpbHMvYW5zaWJsZSBzdG9yYWdlL2phaWxz L2Fuc2libGUtbWFzdGVyDQoyMDE2LTAxLTIxLjA5OjI2OjQ2IHpmcyBjcmVhdGUgc3RvcmFnZS9q YWlsZGF0YQ0KMjAxNi0wMS0yMS4wOToyNjo1MSB6ZnMgY3JlYXRlIHN0b3JhZ2UvamFpbGRhdGEv YW5zaWJsZS1tYXN0ZXINCjIwMTYtMDEtMjEuMDk6Mjg6MDMgemZzIHNldCBxdW90YT0xZyBzdG9y YWdlL2phaWxzL2Fuc2libGUtbWFzdGVyDQoyMDE2LTAxLTIxLjA5OjI4OjA4IHpmcyBzZXQgcXVv dGE9NGcgc3RvcmFnZS9qYWlscy9hbnNpYmxlLW1hc3Rlcg0KMjAxNi0wMS0yMS4wOToyODoxNyB6 ZnMgc2V0IHF1b3RhPTRnIHN0b3JhZ2UvamFpbGRhdGEvYW5zaWJsZS1tYXN0ZXINCjIwMTYtMDEt MjEuMTA6MjQ6MTAgemZzIGNyZWF0ZSAtbyBxdW90YT04ZyBzdG9yYWdlL2phaWxzL2dpdGxhYg0K MjAxNi0wMS0yMS4xMDoyNDoyMyB6ZnMgY3JlYXRlIC1vIHF1b3RhPTI1Nmcgc3RvcmFnZS9qYWls ZGF0YS9naXRsYWINCjIwMTYtMDEtMjEuMTA6Mjk6MDAgemZzIGNyZWF0ZSAtbyByZWNvcmRzaXpl PThrIHN0b3JhZ2UvamFpbGRhdGEvZ2l0bGFiL3NxbA0KMjAxNi0wMS0yMS4xMDoyOToxNiB6ZnMg Y3JlYXRlIC1vIHJlY29yZHNpemU9MW0gc3RvcmFnZS9qYWlsZGF0YS9naXRsYWIvZGF0YQ0KMjAx Ni0wMS0yMS4xMjoyMTo1NCB6ZnMgcmVuYW1lIC1mIHN0b3JhZ2UvamFpbHMvZ2l0bGFiIHN0b3Jh Z2UvamFpbHMvZ29ncw0KMjAxNi0wMS0yMS4xMjoyMjowOSB6ZnMgcmVuYW1lIC1mIHN0b3JhZ2Uv amFpbGRhdGEvZ2l0bGFiIHN0b3JhZ2UvamFpbGRhdGEvZ29ncw0KMjAxNi0wMS0yNC4yMzo1Mzox NCB6ZnMgZGVzdHJveSAtciBzdG9yYWdlL2lTQ1NJL21hcmllDQoyMDE2LTAxLTI1LjAwOjAzOjA0 IHpmcyBkZXN0cm95IC1yIHN0b3JhZ2UvaVNDU0kvbWFyaWUNCjIwMTYtMDEtMjUuMDA6MDM6MTkg emZzIGRlc3Ryb3kgLXIgc3RvcmFnZS9pU0NTSS9tYXJpZQ0KMjAxNi0wMS0yNS4wMDozMzowNSB6 ZnMgZGVzdHJveSAtciBzdG9yYWdlL2lTQ1NJL21hcmllDQoyMDE2LTAxLTI1LjAwOjMzOjE3IHpm cyBkZXN0cm95IC1yIHN0b3JhZ2UvaVNDU0kvbWFyaWUNCjIwMTYtMDEtMjUuMTk6NDg6MjMgemZz IHNldCB2b2xtb2RlPWRldiBzdG9yYWdlL2lTQ1NJL21hcmllLzINCjIwMTYtMDEtMjUuMTk6NDg6 NDUgemZzIHJlbmFtZSBzdG9yYWdlL2lTQ1NJL21hcmllLzIgc3RvcmFnZS9pU0NTSS9tYXJpZS8y X3JuDQoyMDE2LTAxLTI1LjE5OjQ4OjUyIHpmcyByZW5hbWUgc3RvcmFnZS9pU0NTSS9tYXJpZS8y X3JuIHN0b3JhZ2UvaVNDU0kvbWFyaWUvMg0KMjAxNi0wMS0yNi4wNDoyNzo0NSB6ZnMgcmVjdiAt dUZ2IHN0b3JhZ2UvaVNDU0kvbWFyaWUNCjIwMTYtMDEtMjYuMTY6NTU6MzUgemZzIHNldCB2b2xt b2RlPWRldiBzdG9yYWdlL2lTQ1NJDQoyMDE2LTAxLTI2LjE2OjU2OjA5IHpwb29sIHNjcnViIHN0 b3JhZ2UNCg0KIyB6ZnMgbGlzdCAtciBzdG9yYWdlDQpOQU1FICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgVVNFRCAgQVZBSUwgIFJFRkVSICBNT1VOVFBPSU5UDQpzdG9yYWdlICAgICAgICAg ICAgICAgICAgICAgICAgICAyLjc4VCAgMTEuMlQgIDEuMjJNICAvbW50L3N0b3JhZ2UNCnN0b3Jh Z2UvQ0lGUyAgICAgICAgICAgICAgICAgICAgICAzMDVHICAxMS4yVCAgIDE5MksgIC9tbnQvc3Rv cmFnZS9DSUZTDQpzdG9yYWdlL0NJRlMvYmlsZGVyICAgICAgICAgICAgICAgMjkyRyAgIDczMkcg ICAyOTJHICAvbW50L3N0b3JhZ2UvQ0lGUy9iaWxkZXINCnN0b3JhZ2UvQ0lGUy9kb3dubG9hZHMg ICAgICAgICAgIDEzLjFHICAgMjQzRyAgMTMuMUcgIC9tbnQvc3RvcmFnZS9DSUZTL2Rvd25sb2Fk cw0Kc3RvcmFnZS9JU08gICAgICAgICAgICAgICAgICAgICAgIDQ3NE0gIDExLjJUICAgNDc0TSAg L21udC9zdG9yYWdlL0lTTw0Kc3RvcmFnZS9iaHl2ZSAgICAgICAgICAgICAgICAgICAgNjguMEcg IDExLjJUICAgMTkySyAgbm9uZQ0Kc3RvcmFnZS9iaHl2ZS9zbWFsbCAgICAgICAgICAgICAgNjgu MEcgIDExLjJUICAgMTkySyAgbm9uZQ0Kc3RvcmFnZS9iaHl2ZS9zbWFsbC90ZXN0MSAgICAgICAg MzQuMEcgIDExLjJUICAgMTI4SyAgLQ0Kc3RvcmFnZS9iaHl2ZS9zbWFsbC90ZXN0MiAgICAgICAg MTcuMEcgIDExLjJUICAgMTI4SyAgLQ0Kc3RvcmFnZS9iaHl2ZS9zbWFsbC90ZXN0MyAgICAgICAg MTcuMEcgIDExLjJUICAgMTI4SyAgLQ0Kc3RvcmFnZS9pU0NTSSAgICAgICAgICAgICAgICAgICAg Mi40MVQgIDExLjJUICAgMTkySyAgL21udC9zdG9yYWdlL2lTQ1NJDQpzdG9yYWdlL2lTQ1NJL21h cmllICAgICAgICAgICAgICAyLjQxVCAgMTEuMlQgICAxOTJLICAvbW50L3N0b3JhZ2UvaVNDU0kv bWFyaWUNCnN0b3JhZ2UvaVNDU0kvbWFyaWUvMSAgICAgICAgICAgIDIuMDlUICAxMS4yVCAgMi4w OVQgIC0NCnN0b3JhZ2UvaVNDU0kvbWFyaWUvMiAgICAgICAgICAgICAzMzJHICAxMS4yVCAgIDMz MUcgIC0NCnN0b3JhZ2UvaVNDU0kvbWFyaWUvMyAgICAgICAgICAgIDM0LjhNICAxMS4yVCAgMzQu Nk0gIC0NCnN0b3JhZ2UvamFpbGRhdGEgICAgICAgICAgICAgICAgICA1MDhNICAxMS4yVCAgIDE5 MksgIC9tbnQvc3RvcmFnZS9qYWlsZGF0YQ0Kc3RvcmFnZS9qYWlsZGF0YS9hbnNpYmxlLW1hc3Rl ciAgIDE5MksgIDQuMDBHICAgMTkySyAgL21udC9zdG9yYWdlL2phaWxkYXRhL2Fuc2libGUtbWFz dGVyDQpzdG9yYWdlL2phaWxkYXRhL2dvZ3MgICAgICAgICAgICAgNTA3TSAgIDI1NkcgICAxOTJL ICAvbW50L3N0b3JhZ2UvamFpbGRhdGEvZ29ncw0Kc3RvcmFnZS9qYWlsZGF0YS9nb2dzL2RhdGEg ICAgICAgIDI4M00gICAyNTZHICAgMjgzTSAgL21udC9zdG9yYWdlL2phaWxkYXRhL2dvZ3MvZGF0 YQ0Kc3RvcmFnZS9qYWlsZGF0YS9nb2dzL3NxbCAgICAgICAgIDIyNU0gICAyNTZHICAgMjI1TSAg L21udC9zdG9yYWdlL2phaWxkYXRhL2dvZ3Mvc3FsDQpzdG9yYWdlL2phaWxzICAgICAgICAgICAg ICAgICAgICAyLjU1RyAgIDEyNUcgICAyMDhLICAvdXNyL2phaWxzDQpzdG9yYWdlL2phaWxzL2Fu c2libGUtbWFzdGVyICAgICAgNDcyTSAgMy41NEcgICA0NzJNICAvdXNyL2phaWxzL2Fuc2libGUt bWFzdGVyDQpzdG9yYWdlL2phaWxzL2dvZ3MgICAgICAgICAgICAgICAgNzUwTSAgNy4yN0cgICA3 NTBNICAvdXNyL2phaWxzL2dvZ3MNCnN0b3JhZ2UvamFpbHMvc2FtYmEgICAgICAgICAgICAgICA2 MzVNICAxLjM4RyAgIDYzNU0gIC91c3IvamFpbHMvc2FtYmENCnN0b3JhZ2UvamFpbHMvemFiYml4 ICAgICAgICAgICAgICA3NThNICA3LjI2RyAgIDc1OE0gIC91c3IvamFpbHMvemFiYml4DQo= --001a114acd30c720e0052a3f062a-- From owner-freebsd-fs@freebsd.org Tue Jan 26 19:22:03 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1A61FA6EC6A for ; Tue, 26 Jan 2016 19:22:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E725DE05 for ; Tue, 26 Jan 2016 19:22:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0QJM2QA005046 for ; Tue, 26 Jan 2016 19:22:02 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 206652] [ext2fs][patch] EXT4: sparse file fixes and mmap optimizations Date: Tue, 26 Jan 2016 19:22:03 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: damjan.jov@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status keywords bug_severity priority component assigned_to reporter cc attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 19:22:03 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206652 Bug ID: 206652 Summary: [ext2fs][patch] EXT4: sparse file fixes and mmap optimizations Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: New Keywords: patch Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: damjan.jov@gmail.com CC: freebsd-fs@FreeBSD.org Created attachment 166156 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D166156&action= =3Dedit fix handling files with sparse blocks before extent's index, and implement = runb in mmap It turns out that the ei_blk on the first struct ext4_extent_index in an EX= T4 file's root extent isn't 0 if the file starts with sparse blocks. This will cause ext4_ext_binsearch_index() to keep passing the "if (lbn < m->ei_blk)" test, moving r to the left, until r < l, then set "path->ep_index =3D l - 1= ;" resulting in garbage data being read from wrong disk blocks since path->ep_index is pointing to before the first element of the array. I've attached a patch that keeps track of the first and last block in each extent as it descends down the extent tree, thus being able to work out that some blocks are sparse earlier, preventing the previous out of range proble= m. Tracking the first and last block in each extent also lets us calculate whe= re sparse extents end better, passing larger values to read ahead in mmap. In ext4_bmapext() I've also started supporting the runb parameter (which is apparently the number of adjacent blocks prior to the block being converted= in the same way that runp is the number of blocks after), which has sped up ra= ndom access to mmaped files. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-fs@freebsd.org Thu Jan 28 00:20:49 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4D2F7A70D7F for ; Thu, 28 Jan 2016 00:20:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 24EC8DA1 for ; Thu, 28 Jan 2016 00:20:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0S0Kn7C047804 for ; Thu, 28 Jan 2016 00:20:49 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 206634] "panic: ncllock1" from FreeBSD client after NFSv4 server was taken offline and brought back to life; lots of spam about "protocol prob err=10006" Date: Thu, 28 Jan 2016 00:20:49 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: rmacklem@uoguelph.ca X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 00:20:49 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206634 rmacklem@uoguelph.ca changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rmacklem@uoguelph.ca --- Comment #1 from rmacklem@uoguelph.ca --- I will take a look at the panic someday, to see if it can be avoided. I will note that 10006 is NFSERR_SERVERFAULT, which is a "catch-all" for "horrible bad things are happening that you want to avoid like the plague". (As such, a panic is probably a good thing to have happen.) NFSv4 servers are not like NFSv3 ones. They are stateful. As such, you need to always unmount all mounts before shutting down/rebooting or similar to the server. If the server crashes, then there is a recovery protocol after the server reboots, but the server must crash/reboot to invoke this. (If a crash/reboot happened, it is too late to figure out what went wrong, because you'd need a packet trace from the point where the server reboots to figure out what happened w.r.t. this recovery protocol. Btw, this recovery protocol is more complex than the entire NFSv3 protocol, so I wouldn't be surprised if the code does have problems.) You said "brought offline". If that didn't mean "reboot" when it came back online, then you definitely would break any NFSv4 mounts badly. The only exception would be a case where the server is offline (due to network shutdown or killing/restarting the nfsd threads or ???) for less than 1-2 minutes (the FreeBSD server uses a 2minute lease duration and that is the upper bound on how long the server can be unavailable without bad things happening). The only use for this I can think of is: - If you were running a kernel without "options NFSD", so the nfsd.ko is loaded. - You wanted to replace the nfsd.ko with one that has been patched. --> You could kill the nfsd threads, kldunload nfsd.ko, kldload the new nfsd.ko and restart the nfsd threads within 1minute. There probably isn't anywhere in the man pages that emphasizes that you can't take an NFSv4 server "offline" without unmounting all the client mounts and this should be fixed. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Thu Jan 28 00:22:31 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DEC93A70EF9 for ; Thu, 28 Jan 2016 00:22:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D0212FF6 for ; Thu, 28 Jan 2016 00:22:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0S0MVFl055453 for ; Thu, 28 Jan 2016 00:22:31 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 206634] "panic: ncllock1" from FreeBSD client after NFSv4 server was taken offline and brought back to life; lots of spam about "protocol prob err=10006" Date: Thu, 28 Jan 2016 00:22:32 +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 Only Me X-Bugzilla-Who: rmacklem@uoguelph.ca X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 00:22:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206634 --- Comment #2 from rmacklem@uoguelph.ca --- Just to clarify, to make the recovery protocol happen, the server must either be rebooted or the nfsd.ko must be unloaded and reloaded. (A network partitioning or stopping/restarting the nfsd threads will not start the recovery protocol.) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Thu Jan 28 10:39:10 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BEE68A70DE1 for ; Thu, 28 Jan 2016 10:39:10 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from cu01176b.smtpx.saremail.com (cu01176b.smtpx.saremail.com [195.16.151.151]) (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 80CD115AE for ; Thu, 28 Jan 2016 10:39:09 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from [172.16.8.186] (izaro.sarenet.es [192.148.167.11]) by proxypop01.sare.net (Postfix) with ESMTPSA id 91E959DDE1E; Thu, 28 Jan 2016 11:29:42 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: ZFS bug: zpool expandz says 16.0E, clearly wrong From: Borja Marcos In-Reply-To: Date: Thu, 28 Jan 2016 11:29:41 +0100 Cc: freebsd-fs@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <0614ACAB-DFF0-4CBE-8AA1-4EAE4668DBA9@sarenet.es> References: To: Marie Helene Kvello-Aune X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 10:39:10 -0000 > On 26 Jan 2016, at 17:17, Marie Helene Kvello-Aune = wrote: >=20 > I've stumbled across a curiosity with my zpool. The command 'zpool = list' > states that the EXPANDZ property/value is 16.0E. This is clearly = incorrect. > :) Or not, maybe your encryption+compression has triggered a Shannon = Singularity! ;) > The pool consist of a single RaidZ2 vdev of 6 drives, and two cache = drives. > No log device. Executing 'zpool list -v' shows that each member of the > RaidZ2 has an 'EXPANDZ' value of '-', as expected. But the RaidZ2 = itself, > and the pool, has a EXPANDZ value of 16.0E. Now, seriously. I=E2=80=99ve seen odd size reports for cache drives = before. Can you try running =E2=80=9Czdb=E2=80=9D and see where the wrong size is reported? Maybe detaching and reattaching the cache drives from the pool might = help, in case something related to the cache drives is creating the confusion. Borja. From owner-freebsd-fs@freebsd.org Thu Jan 28 12:36:33 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B52EAA71800 for ; Thu, 28 Jan 2016 12:36:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9B1BC1756 for ; Thu, 28 Jan 2016 12:36:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0SCaX9I035808 for ; Thu, 28 Jan 2016 12:36:33 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 204764] Filesystem deadlock, process in vodead state Date: Thu, 28 Jan 2016 12:36:33 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: daniel@blodan.se X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 12:36:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D204764 --- Comment #4 from Daniel Ylitalo --- Okay! Got a proc stuck again, however, I'm having trouble understanding "fi= nd the vnode address which caused the hang", how do I know what caused the han= g? Heres all the output I've gatherd so far: procstat -kk -a =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 94614 100627 python2.7 - mi_switch+0x179 sleepq_switch+0x152 sleepq_wait+0x43 _sleep+0x366 vnode_create_vobject+0xe9 ufs_lookup_ino+0xa0 VOP_CACHEDLOOKUP_APV+0x10f vfs_cache_lookup+0xd6 VOP_LOOKUP_APV+0x10f lookup+0x5c2 namei+0x504 kern_statat_vnhook+0xae sys_lstat+0x30 amd64_syscall+0x278 Xfast_syscall+0xfb =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [root@hub-se /usr/obj/usr/src/sys/GENERIC]# kgdb kernel.debug /dev/mem GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Reading symbols from /boot/kernel/aio.ko.symbols...done. Loaded symbols for /boot/kernel/aio.ko.symbols Reading symbols from /boot/kernel/accf_data.ko.symbols...done. Loaded symbols for /boot/kernel/accf_data.ko.symbols Reading symbols from /boot/kernel/accf_http.ko.symbols...done. Loaded symbols for /boot/kernel/accf_http.ko.symbols Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. Loaded symbols for /boot/kernel/fdescfs.ko.symbols Reading symbols from /boot/kernel/nullfs.ko.symbols...done. Loaded symbols for /boot/kernel/nullfs.ko.symbols #0 sched_switch (td=3D0xffffffff81850720, newtd=3D, flags=3D) at /usr/src/sys/kern/sched_ule.c:1945 1945 cpuid =3D PCPU_GET(cpuid); (kgbd) info threads 505 Thread 100627 (PID=3D94614: python2.7) sched_switch (td=3D0xfffff80379b5e940, newtd=3D, flags=3D) at /usr/src/sys/kern/sched_ule.c:1945 (kgdb) thread 505 [Switching to thread 505 (Thread 100627)]#0 sched_switch (td=3D0xfffff80379b5e940, newtd=3D, flags=3D) at /usr/src/sys/kern/sched_ule.c:1945 1945 cpuid =3D PCPU_GET(cpuid); (kgdb) bt #0 sched_switch (td=3D0xfffff80379b5e940, newtd=3D, flags=3D) at /usr/src/sys/kern/sched_ule.c:1945 #1 0xffffffff8094e149 in mi_switch (flags=3D260, newtd=3D0x0) at /usr/src/sys/kern/kern_synch.c:491 #2 0xffffffff8098bb02 in sleepq_switch (wchan=3D, pri=3D) at /usr/src/sys/kern/subr_sleepqueue.c:538 #3 0xffffffff8098b963 in sleepq_wait (wchan=3D0xfffff808cdd41e00, pri=3D84= ) at /usr/src/sys/kern/subr_sleepqueue.c:617 #4 0xffffffff8094da56 in _sleep (ident=3D, lock=3D, priority=3D, wmesg=3D, sbt=3D, pr=3D) at /usr/src/sys/kern/kern_synch.c:255 #5 0xffffffff80be8759 in vnode_create_vobject (vp=3D0xfffff8036ee569c0, isize=3D512, td=3D0xfffff80379b5e940) at /usr/src/sys/vm/vnode_pager.c:120 #6 0xffffffff80bb1010 in ufs_lookup_ino (vdp=3D0xfffff8036ee569c0, vpp=3D0xfffffe0a5bdfd9a8, cnp=3D0xfffffe0a5bdfd9d0, dd_ino=3D0x0) at /usr/src/sys/ufs/ufs/ufs_lookup.c:259 #7 0xffffffff80e791ef in VOP_CACHEDLOOKUP_APV (vop=3D, a=3D) at vnode_if.c:197 #8 0xffffffff809dba26 in vfs_cache_lookup (ap=3D) at vnode_if.h:80 #9 0xffffffff80e7902f in VOP_LOOKUP_APV (vop=3D, a=3D= ) at vnode_if.c:129 #10 0xffffffff809e40c2 in lookup (ndp=3D0xfffffe0a5bdfd948) at vnode_if.h:54 #11 0xffffffff809e3764 in namei (ndp=3D0xfffffe0a5bdfd948) at /usr/src/sys/kern/vfs_lookup.c:302 #12 0xffffffff809f911e in kern_statat_vnhook (td=3D0xfffff80379b5e940, flag=3D, fd=3D-100, path=3D0x8067103d4 , pathseg=3DUIO_USERSPACE, sbp=3D0xfffffe0a5bdfda6= 0, hook=3D0) at /usr/src/sys/kern/vfs_syscalls.c:2298 #13 0xffffffff809f92b0 in sys_lstat (td=3D0x0, uap=3D0xfffffe0a5bdfdb80) at /usr/src/sys/kern/vfs_syscalls.c:2278 #14 0xffffffff80d51b38 in amd64_syscall (td=3D0xfffff80379b5e940, traced=3D= 0) at subr_syscall.c:134 #15 0xffffffff80d359ab in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:396 #16 0x000000080157f8aa in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) I'm letting the server stay stuck until I know how to get the info you need= out of it :) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Thu Jan 28 13:31:05 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1A4AFA70BD9 for ; Thu, 28 Jan 2016 13:31:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0AE401154 for ; Thu, 28 Jan 2016 13:31:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0SDV4rZ026549 for ; Thu, 28 Jan 2016 13:31:04 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 204764] Filesystem deadlock, process in vodead state Date: Thu, 28 Jan 2016 13:31:05 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: kib@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 13:31:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D204764 --- Comment #5 from Konstantin Belousov --- In the frame 5, the argument vp points to the vnode. Also do 'p *td' in th= at frame. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Thu Jan 28 14:49:04 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B8E80A70D18 for ; Thu, 28 Jan 2016 14:49:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A92791AD2 for ; Thu, 28 Jan 2016 14:49:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0SEn4J0033005 for ; Thu, 28 Jan 2016 14:49:04 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 204764] Filesystem deadlock, process in vodead state Date: Thu, 28 Jan 2016 14:49:04 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: daniel@blodan.se X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 14:49:04 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D204764 --- Comment #6 from Daniel Ylitalo --- Sorry, but this is the first time I'm doing any kind of kernel debuging. So I'm supposed to write this after the backtrace? (kgdb) p *0xfffff8036ee569c0 $1 =3D -2130911031 But then the second command fails (kgdb) p *(vp->v_bufobj.bo_object) No symbol "vp" in current context. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Thu Jan 28 15:43:52 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BCEF9A71F4F for ; Thu, 28 Jan 2016 15:43:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AD0AD1D5D for ; Thu, 28 Jan 2016 15:43:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0SFhqP0035472 for ; Thu, 28 Jan 2016 15:43:52 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 204764] Filesystem deadlock, process in vodead state Date: Thu, 28 Jan 2016 15:43:52 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: kib@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 15:43:52 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D204764 --- Comment #7 from Konstantin Belousov --- (In reply to Daniel Ylitalo from comment #6) frame 5 p *vp p *td etc You must use symbols to access data, otherwise gdb cannot deduce types. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Thu Jan 28 15:55:53 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 42BB9A70460 for ; Thu, 28 Jan 2016 15:55:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 321C513D7 for ; Thu, 28 Jan 2016 15:55:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0SFtqFV061874 for ; Thu, 28 Jan 2016 15:55:53 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 204764] Filesystem deadlock, process in vodead state Date: Thu, 28 Jan 2016 15:55:53 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: daniel@blodan.se X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 15:55:53 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D204764 --- Comment #8 from Daniel Ylitalo --- Created attachment 166244 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D166244&action= =3Dedit threads frame output --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Thu Jan 28 15:56:35 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BAEC3A704AB for ; Thu, 28 Jan 2016 15:56:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AB1EA14CD for ; Thu, 28 Jan 2016 15:56:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0SFuZRm063293 for ; Thu, 28 Jan 2016 15:56:35 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 204764] Filesystem deadlock, process in vodead state Date: Thu, 28 Jan 2016 15:56:35 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: daniel@blodan.se X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 15:56:35 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D204764 --- Comment #9 from Daniel Ylitalo --- I've attached the output, let me know if you need something else or if I can reboot without the kernel debugging in place. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Thu Jan 28 16:38:43 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B9698A715EA for ; Thu, 28 Jan 2016 16:38:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A9A131C55 for ; Thu, 28 Jan 2016 16:38:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0SGchA4088834 for ; Thu, 28 Jan 2016 16:38:43 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 204764] Filesystem deadlock, process in vodead state Date: Thu, 28 Jan 2016 16:38:43 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: kib@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 16:38:43 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D204764 --- Comment #10 from Konstantin Belousov --- (In reply to Daniel Ylitalo from comment #9) This is seemngly what I need to start, but I probably would not look closer until some time, most likely tomorrow. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Thu Jan 28 21:29:29 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2B7A1A71995 for ; Thu, 28 Jan 2016 21:29:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1CAA61DE0 for ; Thu, 28 Jan 2016 21:29:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0SLTRBS044696 for ; Thu, 28 Jan 2016 21:29:28 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 204764] Filesystem deadlock, process in vodead state Date: Thu, 28 Jan 2016 21:29:28 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: kib@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 21:29:29 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D204764 --- Comment #11 from Konstantin Belousov --- (In reply to Konstantin Belousov from comment #10) Is there a procstat -kk output somewhere ? I want to see the state of all threads when the problem occurs. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri Jan 29 05:12:22 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0CB4EA70F93 for ; Fri, 29 Jan 2016 05:12:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F20781CF6 for ; Fri, 29 Jan 2016 05:12:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0T5CLQC092345 for ; Fri, 29 Jan 2016 05:12:21 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 206652] [ext2fs][patch] EXT4: sparse file fixes and mmap optimizations Date: Fri, 29 Jan 2016 05:12:21 +0000 X-Bugzilla-Reason: AssignedTo CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org 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: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 05:12:22 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206652 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.= From owner-freebsd-fs@freebsd.org Fri Jan 29 08:34:00 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DCAE8A72DE0 for ; Fri, 29 Jan 2016 08:34:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CD6781ED7 for ; Fri, 29 Jan 2016 08:34:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0T8Y0QB062424 for ; Fri, 29 Jan 2016 08:34:00 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 204764] Filesystem deadlock, process in vodead state Date: Fri, 29 Jan 2016 08:34:00 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: daniel@blodan.se X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 08:34:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D204764 --- Comment #12 from Daniel Ylitalo --- Unfortunately I rebooted the server already, but I still have debug compile= d in so I'll get one for you the next time it happens. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Fri Jan 29 09:51:35 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4B06BA71F8D for ; Fri, 29 Jan 2016 09:51:35 +0000 (UTC) (envelope-from norman@khine.net) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0F1351232 for ; Fri, 29 Jan 2016 09:51:34 +0000 (UTC) (envelope-from norman@khine.net) Received: by mail-vk0-x22a.google.com with SMTP id e6so38914527vkh.2 for ; Fri, 29 Jan 2016 01:51:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=khine-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Ur9xRwZfMmNy5aitXaIfnMCC39GGBDfOahVeaFvCBhQ=; b=Xjim3nMbzawfNo10OOefYTOCTrfJ3z5l+0roirPPe4dfoz8hfSlU6IqacokQ7xjSYh NcfkUuu9/g0ecEie2+jkYref77M6jAvRFoI8bqhsGGppe72Q3YxRiYo4R8iUJsoTX+Vq 8fT52FGJYWS0IHDgAjNat06r2kGKxY9SKhXHucxRbnAbkvpPz7NYbXJyZMqUJxwlWjzs iAH4fv9Ov6oSQFgn2D2TxrHRF8+DtRdmluYfB275iys9FzFIVFl1YU+MDtbn1dM+w+iY 4p/H36tciBCdrJqxtk70/LWMHNvFtKiD/2APId439r+m5Ha2HtBNXGYzet5N3/MZn6yt Cx0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=Ur9xRwZfMmNy5aitXaIfnMCC39GGBDfOahVeaFvCBhQ=; b=dFmJbwNTlialdEAya8Z9l75RKpIqUgIa9VGY46iYy7Q3xCOhjiKwF1zGGoYE/iTSwZ CLFdrNPOXVqBt5U4ZxzNIHCcWEh3JD5yN9aigU0kMZqPqfs7XKiyEIPAVsfgqNmovvDe bdhiO5pezy4EluvDu/9ES+acZmsnzd5Hf2ml2VnExoeDy9mhfXykD7mFhRqTaXVh3Yt5 mWILnbrkgpV1y721Fckg9AB73RexzMI7hRpCqhgHz2BGHmpTj+k3RLOnBbpdNHcYkWdt rzFGV2U2+zSuasTV7ICJ5iQhqplS/oK19ayV4P5qKbe7UMYerpoksZFvKSSMbqfmfBFX oZZw== X-Gm-Message-State: AG10YOTe0Rfi9g1V2IJMAoLqWtrW9aYdwvWvONonIkj1hKZlxDtrd+2axV1N0bRmWyxXpZPzr2oFiJAnmyND1w== MIME-Version: 1.0 X-Received: by 10.31.179.146 with SMTP id c140mr4666290vkf.50.1454061093919; Fri, 29 Jan 2016 01:51:33 -0800 (PST) Received: by 10.31.227.196 with HTTP; Fri, 29 Jan 2016 01:51:33 -0800 (PST) In-Reply-To: References: Date: Fri, 29 Jan 2016 09:51:33 +0000 Message-ID: Subject: Re: Installing FreeBSD 10.2 Root on ZFS using VTOC8 (sparc) From: Norman Khine To: subash , freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 09:51:35 -0000 hello subash, not sure but if you google your error, you get https://forums.freebsd.org/threads/zfs-i-o-error-all-block-copies-unavailable.30209/ and http://serverfault.com/questions/616991/freebsd-10-wont-boot-to-zfs-root-after-power-failure also, direct your questions to , which i have done for you freebsd-fs@freebsd.org as you may get better response On 28 January 2016 at 08:34, subash wrote: > Hello Sir, > > I am trying to install FreeBSD Sparc64 on my machine, I followed the > tutorials to Install FreeBSD Root on ZFS( tutorial link ) > . Only the > changes I made is that instead of using mirror I tried configuring raidz > with four internal disks and added bootloader in all the disks (da0 da1 da2 > da3). Everything was fine while installing but booting after installation > shows the error below:- > > ZFS: i/o error - all block copies unavailable > ZFS: can't read MOS object directory > ZFS: can't find root filesystem > > FreeBSD/sparc64 ZFS enabled bootstrap loader, Revision 1.0 > (root@releng1.nyi.freebsd.org, Wed Nov 12 03:13:59 UTC 2014) > > bootpath="" > > can't load 'kernel' > > I created zpool like this:- > zpool create -f -o altroot=/mnt -O canmount=off zroot raidz da0a da1a da2a > da3a > > here is my bootloader installation:- > > # zpool export zroot # gpart bootcode -p /boot/zfsboot da0 # gpart bootcode -p /boot/zfsboot da1 > # gpart bootcode -p /boot/zfsboot da2 > # gpart bootcode -p /boot/zfsboot da3 > # sysctl kern.geom.debugflags=0x10 kern.geom.debugflags: 0 -> 16 # dd if=/boot/zfsloader of=/dev/da0a bs=512 oseek=1024 conv=notrunc,sync # dd if=/boot/zfsloader of=/dev/da1a bs=512 oseek=1024 conv=notrunc,sync > # dd if=/boot/zfsloader of=/dev/da2a bs=512 oseek=1024 conv=notrunc,sync > # dd if=/boot/zfsloader of=/dev/da3a bs=512 oseek=1024 conv=notrunc,sync > # zpool import -o altroot=/mnt zroot > > Any ideas? > -- %>>> "".join( [ {'*':'@','^':'.'}.get(c,None) or chr(97+(ord(c)-83)%26) for c in ",adym,*)&uzq^zqf" ] ) From owner-freebsd-fs@freebsd.org Fri Jan 29 14:35:17 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A448CA7204D for ; Fri, 29 Jan 2016 14:35:17 +0000 (UTC) (envelope-from zanchey@ucc.gu.uwa.edu.au) Received: from mail-ext-sout1.uwa.edu.au (mail-ext-sout1.uwa.edu.au [130.95.128.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "IronPort Appliance Demo Certificate", Issuer "IronPort Appliance Demo Certificate" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DB74819EA for ; Fri, 29 Jan 2016 14:35:16 +0000 (UTC) (envelope-from zanchey@ucc.gu.uwa.edu.au) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DoBADbd6tW/8+AX4JWCINcgR2IWJ15BpUrGId2AQEBAQEBgQuFAoFMRIgboSmbB4QHhUaCPIZQDIJgC0CBJwWGEwmHCHOIV48mh2eFL449YoFCAYI2XQGIfAEBAQ X-IPAS-Result: A2DoBADbd6tW/8+AX4JWCINcgR2IWJ15BpUrGId2AQEBAQEBgQuFAoFMRIgboSmbB4QHhUaCPIZQDIJgC0CBJwWGEwmHCHOIV48mh2eFL449YoFCAYI2XQGIfAEBAQ X-IronPort-AV: E=Sophos;i="5.22,364,1449504000"; d="scan'208";a="196546648" Received: from f5-new.net.uwa.edu.au (HELO mooneye.ucc.gu.uwa.edu.au) ([130.95.128.207]) by mail-ext-out1.uwa.edu.au with ESMTP/TLS/ADH-AES256-SHA; 29 Jan 2016 22:34:03 +0800 Received: by mooneye.ucc.gu.uwa.edu.au (Postfix, from userid 801) id 2D4553C057; Fri, 29 Jan 2016 22:34:03 +0800 (AWST) Received: from motsugo.ucc.gu.uwa.edu.au (motsugo.ucc.gu.uwa.edu.au [130.95.13.7]) by mooneye.ucc.gu.uwa.edu.au (Postfix) with ESMTP id 023D23C055 for ; Fri, 29 Jan 2016 22:34:03 +0800 (AWST) Received: by motsugo.ucc.gu.uwa.edu.au (Postfix, from userid 11251) id E6F0120083; Fri, 29 Jan 2016 22:34:02 +0800 (AWST) Received: from localhost (localhost [127.0.0.1]) by motsugo.ucc.gu.uwa.edu.au (Postfix) with ESMTP id E223C2003D for ; Fri, 29 Jan 2016 22:34:02 +0800 (AWST) Date: Fri, 29 Jan 2016 22:34:02 +0800 (AWST) From: David Adam To: freebsd-fs@freebsd.org Subject: Poor ZFS+NFSv3 read/write performance and panic Message-ID: User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 14:35:17 -0000 Hi all, We have a FreeBSD 10.2 server sharing some ZFS datasets over NFSv3. It's worked well until recently, but has started to routinely perform exceptionally poorly, eventually panicing in vdev_deadman() (which I understand is a feature). Initally after booting, things are fine, but performance rapidly begins to degrade. Both read and write performance is terrible, with many operations either hanging indefinitely or timing out. When this happens, I can break into DDB and see lots of nfsd process stuck waiting for a lock: Process 784 (nfsd) thread 0xfffff80234795000 (100455) shared lockmgr zfs (zfs) r = 0 (0xfffff8000b91f548) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:2196 and the backtrace looks like this: sched_switch() at sched_switch+0x495/frame 0xfffffe04677740b0 mi_switch() at mi_switch+0x179/frame 0xfffffe04677740f0 turnstile_wait() at turnstile_wait+0x3b2/frame 0xfffffe0467774140 __mtx_lock_sleep() at __mtx_lock_sleep+0x2c0/frame 0xfffffe04677741c0 __mtx_lock_flags() at __mtx_lock_flags+0x102/frame 0xfffffe0467774210 vmem_size() at vmem_size+0x5a/frame 0xfffffe0467774240 arc_reclaim_needed() at arc_reclaim_needed+0xd2/frame 0xfffffe0467774260 arc_get_data_buf() at arc_get_data_buf+0x157/frame 0xfffffe04677742a0 arc_read() at arc_read+0x68b/frame 0xfffffe0467774350 dbuf_read() at dbuf_read+0x7ed/frame 0xfffffe04677743f0 dmu_tx_check_ioerr() at dmu_tx_check_ioerr+0x8b/frame 0xfffffe0467774420 dmu_tx_count_write() at dmu_tx_count_write+0x17e/frame 0xfffffe0467774540 dmu_tx_hold_write() at dmu_tx_hold_write+0xba/frame 0xfffffe0467774580 zfs_freebsd_write() at zfs_freebsd_write+0x55d/frame 0xfffffe04677747b0 VOP_WRITE_APV() at VOP_WRITE_APV+0x193/frame 0xfffffe04677748c0 nfsvno_write() at nfsvno_write+0x13e/frame 0xfffffe0467774970 nfsrvd_write() at nfsrvd_write+0x496/frame 0xfffffe0467774c80 nfsrvd_dorpc() at nfsrvd_dorpc+0x66b/frame 0xfffffe0467774e40 nfssvc_program() at nfssvc_program+0x4e6/frame 0xfffffe0467774ff0 svc_run_internal() at svc_run_internal+0xbb7/frame 0xfffffe0467775180 svc_run() at svc_run+0x1db/frame 0xfffffe04677751f0 nfsrvd_nfsd() at nfsrvd_nfsd+0x1f0/frame 0xfffffe0467775350 nfssvc_nfsd() at nfssvc_nfsd+0x124/frame 0xfffffe0467775970 sys_nfssvc() at sys_nfssvc+0xb7/frame 0xfffffe04677759a0 amd64_syscall() at amd64_syscall+0x278/frame 0xfffffe0467775ab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0467775ab0 Is this likely to be due to bad hardware? I can't see any problems in the SMART data, and `camcontrol tags da0 -v` etc. does not reveal any particularly long queues. Are there other useful things to check? If not, do you have any other ideas? I can make the full DDB information available if that would be helpful. The pool is configured thus: NAME STATE READ WRITE CKSUM space ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 da0 ONLINE 0 0 0 da1 ONLINE 0 0 0 mirror-1 ONLINE 0 0 0 da2 ONLINE 0 0 0 da3 ONLINE 0 0 0 mirror-2 ONLINE 0 0 0 da4 ONLINE 0 0 0 da6 ONLINE 0 0 0 mirror-3 ONLINE 0 0 0 da7 ONLINE 0 0 0 da8 ONLINE 0 0 0 logs mirror-4 ONLINE 0 0 0 gpt/molmol-slog ONLINE 0 0 0 gpt/molmol-slog0 ONLINE 0 0 0 where the da? devices are WD Reds and the SLOG partitions are on Samsung 840s. Many thanks, David Adam zanchey@ucc.gu.uwa.edu.au From owner-freebsd-fs@freebsd.org Fri Jan 29 18:27:58 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CE9BAA72156 for ; Fri, 29 Jan 2016 18:27:58 +0000 (UTC) (envelope-from allan@physics.umn.edu) Received: from mail.physics.umn.edu (smtp.spa.umn.edu [128.101.220.4]) (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 B0B2A1994 for ; Fri, 29 Jan 2016 18:27:58 +0000 (UTC) (envelope-from allan@physics.umn.edu) Received: from peevish.spa.umn.edu ([128.101.220.230]) by mail.physics.umn.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1aPDR2-0004cD-Ks for freebsd-fs@freebsd.org; Fri, 29 Jan 2016 12:06:16 -0600 To: freebsd-fs@freebsd.org From: Graham Allan Subject: quantifying zpool performance with number of vdevs Organization: Physics, University of Minnesota Message-ID: <56ABAA18.90102@physics.umn.edu> Date: Fri, 29 Jan 2016 12:06:16 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 18:27:58 -0000 In many of the storage systems I built to date I was slightly conservative (?) in wanting to keep any one pool confined to a single JBOD chassis. In doing this I've generally been using the Supermicro 45-drive chassis with pools made of 4x (8+2) raidz2, other slots being kept for spares, ZIL and L2ARC. Now I have several servers with 3-4 such chassis, and reliability has also been such that I'd feel more comfortable about spanning chassis, if there was worthwhile performance benefit. Obviously theory says that iops should scale with number of vdevs but it would be nice to try and quantify. Getting relevant data out of iperf seems problematic on machines with 128GB+ RAM - it's hard to blow out the ARC. It does seem like I get possibly more valid-looking results if I set "zfs set primarycache=metadata" on my test dataset - it seems like this should mostly disable the ARC (seems to be borne out by arcstat output, though there could still be L2ARC effects). Wonder if anyone has any thoughts on this, and also on benefits/risks of moving from 40-drive to 80- or 120-drive pools. Graham -- From owner-freebsd-fs@freebsd.org Fri Jan 29 21:11:15 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B088AA72B9A for ; Fri, 29 Jan 2016 21:11:15 +0000 (UTC) (envelope-from paul@kraus-haus.org) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 80A9215A4 for ; Fri, 29 Jan 2016 21:11:15 +0000 (UTC) (envelope-from paul@kraus-haus.org) Received: by mail-qg0-x22e.google.com with SMTP id e32so76191331qgf.3 for ; Fri, 29 Jan 2016 13:11:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kraus-haus-org.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=WKLQoAefjF0I+yHG+cfInW8SrG+2slZmkdnh0WoGv/U=; b=iZTZfJNmwfD2Hox+JoBVWY/khEQRQbBHB4h2XUd64g+fUCY6dYs+WKH0MUJ4L4aTDg ZbZQEUaFSJ7baFFc1NlBhfYBHnheAgqb8ERNYYb7bitnpAIxlgfcun8upC+K0puxb3n5 1BcgnFppBDTDDGxftxrSBglBefXsOluH4UPPCyHLkini2Rwpl0a1BVxcOaVC0UCpbYQu LlqNuPs6DpKhVJvO6Qwxp2CSIBk0wUPVlYcyTRntRDwlwzzLcbiWly3PKtMgTq0LdcQw ZwtQKU4MeS/F8oiacPvoaIATnKgd7f+5XazWzplkF+1vsZunW9I+i+4O4roJ6Q9QGhCY a5tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=WKLQoAefjF0I+yHG+cfInW8SrG+2slZmkdnh0WoGv/U=; b=D2eYKhUvyoxJxbYd9p/Y7mD7K+rDsZX2puqeZPK2JOQbXq4pKbPeBXMt58w5dWcUGC vRB4POCkR++tbIg9ZuoA+0CD2kYnGqvEgmhev8hZ34JQyPT8PGWWqvTTM4gWSkIuQT0O Ni+bF1GTCBDupaWaZQU/jUVsQrh5dBflg5ACu6atoX04NKeTb1GZ7mb3xd8LIRrHKRn1 4Out3c75I/Kn/uI8lLfWDCwQIrROXSJwuU0MsfdmO2egImGpP1oFSBU40vLP/YtPfZyr vyE5pwJImJB/4Ea+7ObGilDcoHdUz9NwC1q/y2UzkfQt7OrRkN1sJvonaYbt5Ssh4DDT FGnQ== X-Gm-Message-State: AG10YOQqALVd/+02QYAM6L8JuKm63xhGtQc5em9Hyzxfd7cebwm/QW0WuvGFzLy5XFwTRw== X-Received: by 10.140.31.197 with SMTP id f63mr13399360qgf.12.1454101874502; Fri, 29 Jan 2016 13:11:14 -0800 (PST) Received: from [192.168.2.138] (pool-100-4-209-221.albyny.fios.verizon.net. [100.4.209.221]) by smtp.gmail.com with ESMTPSA id d188sm6792479qkb.9.2016.01.29.13.11.12 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 29 Jan 2016 13:11:13 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: quantifying zpool performance with number of vdevs From: Paul Kraus In-Reply-To: <56ABAA18.90102@physics.umn.edu> Date: Fri, 29 Jan 2016 16:10:16 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7E3F58C9-94ED-4491-A0FD-7AAB413F2E03@kraus-haus.org> References: <56ABAA18.90102@physics.umn.edu> To: Graham Allan , FreeBSD Filesystems X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 21:11:15 -0000 On Jan 29, 2016, at 13:06, Graham Allan wrote: > In many of the storage systems I built to date I was slightly = conservative (?) in wanting to keep any one pool confined to a single = JBOD chassis. In doing this I've generally been using the Supermicro = 45-drive chassis with pools made of 4x (8+2) raidz2, other slots being = kept for spares, ZIL and L2ARC. > Obviously theory says that iops should scale with number of vdevs but = it would be nice to try and quantify. >=20 > Getting relevant data out of iperf seems problematic on machines with = 128GB+ RAM - it's hard to blow out the ARC. In a pervious life, where I was responsible for over 200 TB of storage = (in 2008, back when that was a lot), I did some testing for both = reliability and performance before committing to a configuration for our = new storage system. It was not FreeBSD but Solaris and we have 5 x J4400 = chassis (each with 24 drives) all dual SAS attached on four HBA ports. This link = https://docs.google.com/spreadsheets/d/13sLzYKkmyi-ceuIlUS2q0oxcmRnTE-BRvB= YHmEJteAY/edit?usp=3Dsharing has some of the performance testing I did. = I did not look at Sequential Read as that was not in our workload, in = hindsight I should have. By limiting the ARC, the entire ARC, to 4 GB I = was able to get reasonable accurate results. The number of vdevs made = very little difference to Sequential Writes, but Random Reads and Writes = scaled very linearly with the number of top level vdevs. Our eventual config was RAIDz2 based because we could not meet the space = requirements with mirrors, especially as we would have to have gone with = 3-way mirrors to get the same MTTDL as with the RAIDz2. The production = pool consisted of 22 top level vdevs, each was a 5-drive RAIDz2 where = each drive was a in a different disk chassis. So all of the drives in = slot 0 and 1 were hot spares, all of the drives in slot 2 made up one = vdev, all of the drives in slot 3 made up one vdev, etc. So we were = striping data across 22 vdevs. During pre-production testing we = completely lost connectivity to 2 of the 5 disk chassis and had no loss = of data or availability. When those chassis came back, they resilvered = and went along their merry way (just as they should). Once the system went live we took hourly snapshots and replicated them = both locally and remotely for backup purposes. We estimated that it = would have taken over 3 weeks to restore all the data from tape if we = had to, and that was unacceptable. The only issue we ran into related to = resilvering after a drive failure. Due to the large number of snapshots = and the ongoing snapshot creation, a resilver could take over a week. -- Paul Kraus paul@kraus-haus.org From owner-freebsd-fs@freebsd.org Fri Jan 29 21:28:30 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 60592A73231 for ; Fri, 29 Jan 2016 21:28:30 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F035C1E83 for ; Fri, 29 Jan 2016 21:28:29 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by mail-wm0-x232.google.com with SMTP id l66so71365492wml.0 for ; Fri, 29 Jan 2016 13:28:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=vdZ+NOWx1J97BASTPyFdgV0ZtX3VEp1fv+wW2NzIpyc=; b=bocQzV89pt6Tcfzp7kEUH6UJFonizlpIeWEG27Dis2ac0PqdyIHB9KKLmznfxpi2pT 2/NZQAEqDi9pBPvEXcm4Q9tqHZ0tdOWqyGbIx7LrLwYwor1m2SNv2NAX3fnHtOxuDEwm yG9fm/y9RoyH/35repuBe2SfVm4CmL9SjIc7QwN/zaME1jQcNli/FbADK2w5SNULLpcj KUCGE0XRAv2/CZHATIb3rSNGbZXMcjnoKCAvV39dsGkKRNcKKYh1Ek2JtBKfh2fEI6Ew 2brVw2bPP+VKYayXfPf386wDRlRki5I0OiJP+TmJ6QVJD9iXrvO7544Gs20guG8EPYEt nTeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=vdZ+NOWx1J97BASTPyFdgV0ZtX3VEp1fv+wW2NzIpyc=; b=N+rw9cg8MTvPgGzTQFsAJ+MrWscQ6eiU+VaTEHtbGck8SYnPRyGdylJlhW+tJLShr+ TMPg5NOjnxwo9muuj3GrzpPrZu30DpRpNOrOagLPTcGjCVFWnoFvTRfkZBvAGfDdccb2 Kl2LLttysE9EF2xoGgOIhB42fB9PJ6L9OQ9iwJ6X1wxYbVpsdUrAHfoRTiOnLYOx+t7V 1cqRnIZnKQf9feJakfafn6+DDpsZa6b6k6+qAWcrOK/LqL86OcaRh9wRd2SAuBy5ZAt/ kwI1xg8FByaS1kaO1KxfWgp516h61EhQ3fYSDvjLOpc8R4BOiLF4FXoAQsgnbdtr1RZi adYQ== X-Gm-Message-State: AG10YOQWBAg8VyaiVLZH5UD3zOO1tZzbgc6xT4xblDXePEml+V/Q29TOi/adQflwbvB6o3cW X-Received: by 10.28.89.69 with SMTP id n66mr11741307wmb.63.1454102908394; Fri, 29 Jan 2016 13:28:28 -0800 (PST) Received: from [10.10.1.58] (liv3d.labs.multiplay.co.uk. [82.69.141.171]) by smtp.gmail.com with ESMTPSA id t76sm9200632wmd.13.2016.01.29.13.28.26 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jan 2016 13:28:27 -0800 (PST) Subject: Re: quantifying zpool performance with number of vdevs To: freebsd-fs@freebsd.org References: <56ABAA18.90102@physics.umn.edu> From: Steven Hartland Message-ID: <56ABD98B.3070808@multiplay.co.uk> Date: Fri, 29 Jan 2016 21:28:43 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56ABAA18.90102@physics.umn.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2016 21:28:30 -0000 Always a good read is: http://blog.delphix.com/matt/2014/06/06/zfs-stripe-width/ On 29/01/2016 18:06, Graham Allan wrote: > In many of the storage systems I built to date I was slightly > conservative (?) in wanting to keep any one pool confined to a single > JBOD chassis. In doing this I've generally been using the Supermicro > 45-drive chassis with pools made of 4x (8+2) raidz2, other slots being > kept for spares, ZIL and L2ARC. > > Now I have several servers with 3-4 such chassis, and reliability has > also been such that I'd feel more comfortable about spanning chassis, > if there was worthwhile performance benefit. > > Obviously theory says that iops should scale with number of vdevs but > it would be nice to try and quantify. > > Getting relevant data out of iperf seems problematic on machines with > 128GB+ RAM - it's hard to blow out the ARC. > > It does seem like I get possibly more valid-looking results if I set > "zfs set primarycache=metadata" on my test dataset - it seems like > this should mostly disable the ARC (seems to be borne out by arcstat > output, though there could still be L2ARC effects). > > Wonder if anyone has any thoughts on this, and also on benefits/risks > of moving from 40-drive to 80- or 120-drive pools. > > Graham From owner-freebsd-fs@freebsd.org Sat Jan 30 08:55:51 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9C23BA7277D for ; Sat, 30 Jan 2016 08:55:51 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (unknown [IPv6:2a00:7540:1::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.norma.perm.ru", Issuer "Vivat-Trade UNIX Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0E7081452 for ; Sat, 30 Jan 2016 08:55:50 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from bsdrookie.norma.com. (PC993577.norma.com [IPv6:fd00::748] (may be forged)) by elf.hq.norma.perm.ru (8.15.2/8.14.9) with ESMTPS id u0U8tiRl029982 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sat, 30 Jan 2016 13:55:45 +0500 (YEKT) (envelope-from emz@norma.perm.ru) From: "Eugene M. Zheganin" Subject: zfs/metaslab debugging mode To: freebsd-fs@freebsd.org Message-ID: <56AC7A8F.4020407@norma.perm.ru> Date: Sat, 30 Jan 2016 13:55:43 +0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (elf.hq.norma.perm.ru [IPv6:fd00::30a]); Sat, 30 Jan 2016 13:55:45 +0500 (YEKT) X-Spam-Status: No hits=-99.8 bayes=0.0472 testhits AWL=-0.710,BAYES_05=-0.5, RDNS_NONE=0.793,SPF_SOFTFAIL=0.665,USER_IN_WHITELIST=-100 autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on elf.hq.norma.perm.ru X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2016 08:55:51 -0000 Hi. Does FreeBSD have a "metaslab debugging mode" for ZFS or something similar ? In Solaris this is a mode (enabled from mdb) when all the space maps are kept in memory, thus saving from a situation when the pool is full/fragmanted (at least partially). Thanks. Eugene. From owner-freebsd-fs@freebsd.org Sat Jan 30 10:42:57 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0179BA72A3F for ; Sat, 30 Jan 2016 10:42:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E6977182 for ; Sat, 30 Jan 2016 10:42:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0UAgt6o099174 for ; Sat, 30 Jan 2016 10:42:56 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 204764] Filesystem deadlock, process in vodead state Date: Sat, 30 Jan 2016 10:42:55 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: kib@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2016 10:42:57 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D204764 --- Comment #13 from Konstantin Belousov --- Created attachment 166295 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D166295&action= =3Dedit Debugging patch I attached the debugging patch to try to see something about code which set= the OBJ_DEAD flag. In fact, I do not expect that this would catch the offender, but we will see. Somebody who wants to help with the bug should apply the patch, reproduce t= he issue and then provide the same information as I already asked, most import= ant is the p *vp and p *bo_object printouts. If I see what I wanted, I would provide further instructions how to proceed. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-fs@freebsd.org Sat Jan 30 21:07:13 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 903E4A72443 for ; Sat, 30 Jan 2016 21:07:13 +0000 (UTC) (envelope-from e.moe@rcn.com) Received: from smtp.rcn.com (smtp-fo.rcn.cmh.synacor.com [69.168.97.80]) (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 5A41EAF1 for ; Sat, 30 Jan 2016 21:07:12 +0000 (UTC) (envelope-from e.moe@rcn.com) X_CMAE_Category: , , X-CNFS-Analysis: v=2.1 cv=QfbGxpvv c=1 sm=1 tr=0 a=kLIaxcRmAfIWWG5Fo3VFTQ==:117 a=kLIaxcRmAfIWWG5Fo3VFTQ==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=Ny8U74PX05CwolajN80A:9 a=QEXdDO2ut3YA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: ZS5tb2VAcmNuLmNvbQ== Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.mail=e.moe@rcn.com; spf=neutral; sender-id=neutral Authentication-Results: smtp01.rcn.cmh.synacor.com header.from=e.moe@rcn.com; sender-id=neutral Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.user=e.moe; auth=pass (PLAIN) Received-SPF: neutral (smtp01.rcn.cmh.synacor.com: 24.148.20.83 is neither permitted nor denied by domain of rcn.com) Received: from [24.148.20.83] ([24.148.20.83:57317] helo=[192.168.1.175]) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.2.43620 r(Platform:3.6.2.0)) with ESMTPSA (cipher=AES256-SHA) id E5/1D-40376-FF52DA65; Sat, 30 Jan 2016 16:07:11 -0500 From: Erik Moe Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: growfs issue? Message-Id: Date: Sat, 30 Jan 2016 15:07:09 -0600 To: freebsd-fs@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Mailer: Apple Mail (2.3096.5) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2016 21:07:13 -0000 I=E2=80=99ve written some scripts to build Freebsd images for a couple = of ARM boards that I own, Rasperry Pi B and Banana Pi. I=E2=80=99ve = been setting growfs_enable=3D=E2=80=9CYES=E2=80=9D in my rc.conf. I = haven=E2=80=99t had any issues until I made a change to how I build the = fstab. Originally I was hard coding device names: /dev/mmcsd0s2a / ufs rw,noatime 1 = 1 /dev/mmcsd0s1 /boot/msdos msdosfs rw,noatime 0 = 0 But switch to using labels so as I added new boards my scripts would be = more robust: /dev/ufs/rootfs / ufs rw,noatime = 1 1 /dev/msdosfs/MSDOSBOOT /boot/msdos msdosfs rw,noatime = 0 0 Since then I=E2=80=99ve had issues on first boot: GEOM_PART: ufs/rootfs was automatically resized. Use `gpart commit ufs/rootfs` to save changes or `gpart undo = ufs/rootfs` to revert them. mmcsd0s2 resized growfs: /dev/ufs/rootfs: Operation not permitted . . . Starting file system checks: =20 /dev/ufs/rootfs: NO WRITE ACCESS /dev/ufs/rootfs: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. Automatic file system check failed; help! ERROR: ABORTING BOOT (sending SIGTERM to parent)! Jan 31 01:16:52 init: /bin/sh on /etc/rc terminated abnormally, going to = single user mode Enter full pathname of shell or RETURN for /bin/sh: # If I drop into single user mode and run "gpart commit ufs/rootfs=E2=80=9D = and reboot the system it comes up fine and the disk is resized: mmcsd0s2 resized mmcsd0s2a resized super-block backups (for fsck_ffs -b #) at: 1994944,ugen0.3: at usbus0 smsc0: on usbus0 smsc0: chip 0xec00, rev. 0002 2493632, 2992320,miibus0: on smsc0 ukphy0: PHY 1 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: on smsc0 ue0: Ethernet address: b8:27:eb:1f:ba:4d 3491008, 3989696, 4488384, 4987072, 5485760, 5984448, 6483136, 6981824, 7480512, 7979200, 8477888, 8976576, 9475264, 9973952, 10472640, 10971328, 11470016, 11968704, 12467392, 12966080, = 13464768, 13963456, 14462144, 14960832, 15459520, 15958208, 16456896, 16955584, 17454272, 17952960, 18451648, 18950336, 19449024, 19947712, 20446400, 20945088, 21443776, 21942464, 22441152, 22939840, 23438528, 23937216, 24435904, 24934592, 25433280, 25931968, 26430656, 26929344, 27428032, 27926720, 28425408, 28924096, 29422784, 29921472, 30420160, 30918848 Does this have something to do with the labels in the fstab? growfs: /dev/ufs/rootfs: Operation not permitted Thanks, Erik