From owner-freebsd-fs@FreeBSD.ORG Mon Sep 15 08:00:10 2014 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C0DCAE4A for ; Mon, 15 Sep 2014 08:00:10 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 A3A33AF8 for ; Mon, 15 Sep 2014 08:00:10 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s8F80AO3091341 for ; Mon, 15 Sep 2014 08:00:10 GMT (envelope-from bugzilla-noreply@freebsd.org) Message-Id: <201409150800.s8F80AO3091341@kenobi.freebsd.org> From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [FreeBSD Bugzilla] Commit Needs MFC MIME-Version: 1.0 X-Bugzilla-Type: whine X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated Date: Mon, 15 Sep 2014 08:00:10 +0000 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 08:00:10 -0000 Hi, You have a bug in the "Needs MFC" state which has not been touched in 7 or more days. This email serves as a reminder that you may want to MFC this bug or marked it as completed. In the event you have a longer MFC timeout you may update this bug with a comment and I won't remind you again for 7 days. This reminder is only sent on Mondays. Please file a bug about concerns you may have. This search was scheduled by eadler@FreeBSD.org. (5 bugs) Bug 133174: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=133174 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-fs@FreeBSD.org Status: Needs MFC Resolution: Summary: [msdosfs] [patch] msdosfs must support multibyte international characters in file names Bug 136470: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=136470 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-fs@FreeBSD.org Status: Needs MFC Resolution: Summary: [nfs] Cannot mount / in read-only, over NFS Bug 139651: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=139651 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-fs@FreeBSD.org Status: Needs MFC Resolution: Summary: [nfs] mount(8): read-only remount of NFS volume does not work Bug 144447: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=144447 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-fs@FreeBSD.org Status: Needs MFC Resolution: Summary: [zfs] sharenfs fsunshare() & fsshare_main() non functional Bug 155411: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=155411 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-fs@FreeBSD.org Status: Needs MFC Resolution: Summary: [regression] [8.2-release] [tmpfs]: mount: tmpfs : No space left on device From owner-freebsd-fs@FreeBSD.ORG Tue Sep 16 13:12:18 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 481D5966 for ; Tue, 16 Sep 2014 13:12:18 +0000 (UTC) Received: from mx2.paymentallianceintl.com (mx2.paymentallianceintl.com [216.26.158.171]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx2.paymentallianceintl.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 10A80BE7 for ; Tue, 16 Sep 2014 13:12:17 +0000 (UTC) Received: from firewall.mikej.com (162-230-214-65.lightspeed.lsvlky.sbcglobal.net [162.230.214.65]) by mx2.paymentallianceintl.com (8.14.5/8.13.8) with ESMTP id s8GDC9JZ029960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 16 Sep 2014 09:12:09 -0400 (EDT) (envelope-from mikej@mikej.com) Received: from mail.mikej.com ([192.168.6.63]) by firewall.mikej.com (8.14.9/8.14.9) with ESMTP id s8GDBl7V039494 for ; Tue, 16 Sep 2014 09:12:08 -0400 (EDT) (envelope-from mikej@mikej.com) X-Authentication-Warning: firewall.mikej.com: Host [192.168.6.63] claimed to be mail.mikej.com MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 16 Sep 2014 09:11:47 -0400 From: Michael Jung To: freebsd-fs@freebsd.org Subject: Candidate ZFS ARC patch does not cleaning apply to HEAD r271671 Message-ID: X-Sender: mikej@mikej.com User-Agent: Roundcube Webmail/1.0.2 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 13:12:18 -0000 Note: no problems patching/compiling/running against 10-stable r271671+other revs Original patch source: https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147286&action=edit Downloaded patch applied: http://216.26.158.189/zfs-candidate/zfs-candidate.patch Errors: http://216.26.158.189/zfs-candidate/patch.error http://216.26.158.189/zfs-candidate/arc.c.rej http://216.26.158.189/zfs-candidate/kmem.h.rej http://216.26.158.189/zfs-candidate/vm_pageout.c.rej Regards, Michael Jung From owner-freebsd-fs@FreeBSD.ORG Tue Sep 16 13:31:29 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 699B095C for ; Tue, 16 Sep 2014 13:31:29 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 2CE0ED62 for ; Tue, 16 Sep 2014 13:31:28 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 9FF1820E7088E; Tue, 16 Sep 2014 13:31:26 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: * X-Spam-Status: No, score=2.0 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1, NORMAL_HTTP_TO_IP, RDNS_DYNAMIC autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id 5E10220E70886; Tue, 16 Sep 2014 13:31:21 +0000 (UTC) Message-ID: From: "Steven Hartland" To: "Michael Jung" , References: Subject: Re: Candidate ZFS ARC patch does not cleaning apply to HEAD r271671 Date: Tue, 16 Sep 2014 14:31:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 13:31:29 -0000 That patch is against stable/10 not head The additional changes it adds aren't ideal, the latest version which should be used at this time against head is: ARC reclaim refactor (against head) https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147070 Additional discussions on this can be found on the illumos list subject: ZFS Write Throttle Dirty Data Limit Interation with Free Memory ----- Original Message ----- From: "Michael Jung" To: Sent: Tuesday, September 16, 2014 2:11 PM Subject: Candidate ZFS ARC patch does not cleaning apply to HEAD r271671 > Note: no problems patching/compiling/running against 10-stable > r271671+other revs > > Original patch source: > > https://bugs.freebsd.org/bugzilla/attachment.cgi?id=147286&action=edit > > Downloaded patch applied: > > http://216.26.158.189/zfs-candidate/zfs-candidate.patch > > Errors: > > http://216.26.158.189/zfs-candidate/patch.error > http://216.26.158.189/zfs-candidate/arc.c.rej > http://216.26.158.189/zfs-candidate/kmem.h.rej > http://216.26.158.189/zfs-candidate/vm_pageout.c.rej > > Regards, > > Michael Jung > > > > > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Tue Sep 16 16:50:53 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D1E82473 for ; Tue, 16 Sep 2014 16:50:53 +0000 (UTC) Received: from fs.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "NewFS.denninger.net", Issuer "NewFS.denninger.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7B0D6B1D for ; Tue, 16 Sep 2014 16:50:53 +0000 (UTC) Received: from [192.168.1.40] (localhost [127.0.0.1]) by fs.denninger.net (8.14.9/8.14.8) with ESMTP id s8GGopc5017070 for ; Tue, 16 Sep 2014 11:50:51 -0500 (CDT) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (TLS/SSL) [192.168.1.40] by Spamblock-sys (LOCAL/AUTH); Tue Sep 16 11:50:51 2014 Message-ID: <54186A60.7050209@denninger.net> Date: Tue, 16 Sep 2014 11:50:40 -0500 From: Karl Denninger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Re: Candidate ZFS ARC patch does not cleaning apply to HEAD r271671 References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010208010108000704090202" X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 16:50:53 -0000 This is a cryptographically signed message in MIME format. --------------ms010208010108000704090202 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable In addition the candidate "head" patch does not include resizing of the=20 dirty write buffers to prevent slamming the system's VM into paging. It = does fix a number of other problems. There is a candidate against STABLE that incorporates Steve's patch and=20 those further changes; the entire thread (long!) discussing it is here:=20 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D187594 Adding the write-buffer resizing against head would be very easy; there=20 is open debate on whether it's the right thing to do or not but doing so = has a materially-positive impact on performance for my systems. On 9/16/2014 8:31 AM, Steven Hartland wrote: > That patch is against stable/10 not head > > The additional changes it adds aren't ideal, the latest version which > should be used at this time against head is: > ARC reclaim refactor (against head)=20 > https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D147070 > > Additional discussions on this can be found on the illumos list subject= : > ZFS Write Throttle Dirty Data Limit Interation with Free Memory > > ----- Original Message ----- From: "Michael Jung" > To: > Sent: Tuesday, September 16, 2014 2:11 PM > Subject: Candidate ZFS ARC patch does not cleaning apply to HEAD r27167= 1 > > >> Note: no problems patching/compiling/running against 10-stable=20 >> r271671+other revs >> >> Original patch source: >> >> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D147286&action=3D= edit >> >> Downloaded patch applied: >> >> http://216.26.158.189/zfs-candidate/zfs-candidate.patch >> >> Errors: >> >> http://216.26.158.189/zfs-candidate/patch.error >> http://216.26.158.189/zfs-candidate/arc.c.rej >> http://216.26.158.189/zfs-candidate/kmem.h.rej >> http://216.26.158.189/zfs-candidate/vm_pageout.c.rej >> >> Regards, >> >> Michael Jung >> >> >> >> >> >> _______________________________________________ >> freebsd-fs@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-fs >> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > > > %SPAMBLOCK-SYS: Matched [@freebsd.org+], message ok --=20 Karl Denninger karl@denninger.net /The Market Ticker/ --------------ms010208010108000704090202 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFTzCC BUswggQzoAMCAQICAQgwDQYJKoZIhvcNAQEFBQAwgZ0xCzAJBgNVBAYTAlVTMRAwDgYDVQQI EwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkqhkiG9w0BCQEWIGN1c3Rv bWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0MB4XDTEzMDgyNDE5MDM0NFoXDTE4MDgyMzE5 MDM0NFowWzELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExFzAVBgNVBAMTDkthcmwg RGVubmluZ2VyMSEwHwYJKoZIhvcNAQkBFhJrYXJsQGRlbm5pbmdlci5uZXQwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQC5n2KBrBmG22nVntVdvgKCB9UcnapNThrW1L+dq6th d9l4mj+qYMUpJ+8I0rTbY1dn21IXQBoBQmy8t1doKwmTdQ59F0FwZEPt/fGbRgBKVt3Quf6W 6n7kRk9MG6gdD7V9vPpFV41e+5MWYtqGWY3ScDP8SyYLjL/Xgr+5KFKkDfuubK8DeNqdLniV jHo/vqmIgO+6NgzPGPgmbutzFQXlxUqjiNAAKzF2+Tkddi+WKABrcc/EqnBb0X8GdqcIamO5 SyVmuM+7Zdns7D9pcV16zMMQ8LfNFQCDvbCuuQKMDg2F22x5ekYXpwjqTyfjcHBkWC8vFNoY 5aFMdyiN/Kkz0/kduP2ekYOgkRqcShfLEcG9SQ4LQZgqjMpTjSOGzBr3tOvVn5LkSJSHW2Z8 Q0dxSkvFG2/lsOWFbwQeeZSaBi5vRZCYCOf5tRd1+E93FyQfpt4vsrXshIAk7IK7f0qXvxP4 GDli5PKIEubD2Bn+gp3vB/DkfKySh5NBHVB+OPCoXRUWBkQxme65wBO02OZZt0k8Iq0i4Rci WV6z+lQHqDKtaVGgMsHn6PoeYhjf5Al5SP+U3imTjF2aCca1iDB5JOccX04MNljvifXgcbJN nkMgrzmm1ZgJ1PLur/ADWPlnz45quOhHg1TfUCLfI/DzgG7Z6u+oy4siQuFr9QT0MQIDAQAB o4HWMIHTMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgWgMAsGA1UdDwQEAwIF4DAsBglg hkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFHw4 +LnuALyLA5Cgy7T5ZAX1WzKPMB8GA1UdIwQYMBaAFF3U3hpBZq40HB5VM7B44/gmXiI0MDgG CWCGSAGG+EIBAwQrFilodHRwczovL2N1ZGFzeXN0ZW1zLm5ldDoxMTQ0My9yZXZva2VkLmNy bDANBgkqhkiG9w0BAQUFAAOCAQEAZ0L4tQbBd0hd4wuw/YVqEBDDXJ54q2AoqQAmsOlnoxLO 31ehM/LvrTIP4yK2u1VmXtUumQ4Ao15JFM+xmwqtEGsh70RRrfVBAGd7KOZ3GB39FP2TgN/c L5fJKVxOqvEnW6cL9QtvUlcM3hXg8kDv60OB+LIcSE/P3/s+0tEpWPjxm3LHVE7JmPbZIcJ1 YMoZvHh0NSjY5D0HZlwtbDO7pDz9sZf1QEOgjH828fhtborkaHaUI46pmrMjiBnY6ujXMcWD pxtikki0zY22nrxfTs5xDWGxyrc/cmucjxClJF6+OYVUSaZhiiHfa9Pr+41okLgsRB0AmNwE f6ItY3TI8DGCBQowggUGAgEBMIGjMIGdMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxvcmlk YTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRwwGgYD VQQDExNDdWRhIFN5c3RlbXMgTExDIENBMS8wLQYJKoZIhvcNAQkBFiBjdXN0b21lci1zZXJ2 aWNlQGN1ZGFzeXN0ZW1zLm5ldAIBCDAJBgUrDgMCGgUAoIICOzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA5MTYxNjUwNDBaMCMGCSqGSIb3DQEJBDEW BBTd2R+kDazvBbOclB7PWD3p/sXmxjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG0BgkrBgEEAYI3EAQxgaYwgaMwgZ0xCzAJBgNV BAYTAlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoT EEN1ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkq hkiG9w0BCQEWIGN1c3RvbWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0AgEIMIG2BgsqhkiG 9w0BCRACCzGBpqCBozCBnTELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExEjAQBgNV BAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExMQzEcMBoGA1UEAxMTQ3Vk YSBTeXN0ZW1zIExMQyBDQTEvMC0GCSqGSIb3DQEJARYgY3VzdG9tZXItc2VydmljZUBjdWRh c3lzdGVtcy5uZXQCAQgwDQYJKoZIhvcNAQEBBQAEggIAdlTIc5GvAdLS94G2e0C3V2xfQgIh aqNDQYlCbz20vQLQvltVx7Fe9OuzopBtvgjyf2NkobdPX21EGvv+BUfuwyrmNRJvKZjW/z8t kJ1FxeHxh+gYLzWhcJR6hoGNEanqW4riPj9pg6KW76tnrT6l8BpoMAUIu8CiZxDrWlFezpvv TQWlYDcKboaTPaDBA7lX2Oj3Uz/MgyrGkme/qhWt3roKRnYEclY+JowAoIBuhwt/I8o98YgG ztDNLWsvpf82iNRD6RXn3likcW+Kennl5ohxUq2qm1a38rq8FjeHqMbHhmm8+0BjdY/XKaBg 3nTgW5Ed/jrSza9wI6KEGZfABRSAhXGt4TndoPOPr7i6r48XO1w8+vCflrS3giqCVU5mtUQt 7WyepGqeBng0Jc458mwxku2EJb77uZrQiqc/6b7CfbPZ3SUBK5WtHM8T38gk7X5r5TirlLoF +NJPi5sdxXMnCtF4xMcEmdMW+7sgVdObklMXLm6gzrFiZGBly7e969Bzjg06KGAgEDiAxKqN cR1+hegdbYqkCO5LARoNtjVGbJUVEuESey9ct0WJUlV9miIWWfhljXTgRGFqqhg9kU/rZzTu Tj3F6/zBZr2CT9NEmf9hhUubb7dQvYVP2BBa9dnkRwUxi1LWUD2piLaoaDUvuw1876pz87H4 ftx53YAAAAAAAAA= --------------ms010208010108000704090202-- From owner-freebsd-fs@FreeBSD.ORG Tue Sep 16 16:55:23 2014 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 87A595A9 for ; Tue, 16 Sep 2014 16:55:23 +0000 (UTC) Received: from smtp-int-m.obspm.fr (smtp-int-m.obspm.fr [145.238.187.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.obspm.fr", Issuer "TERENA SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1FE2EB6A for ; Tue, 16 Sep 2014 16:55:22 +0000 (UTC) Received: from pcjas.obspm.fr (pcjas.obspm.fr [145.238.184.233]) by smtp-int-m.obspm.fr (8.14.4/8.14.4/SIO Observatoire de Paris - 07/2009) with ESMTP id s8GGtBtr007370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 16 Sep 2014 18:55:12 +0200 Date: Tue, 16 Sep 2014 18:55:11 +0200 From: Albert Shih To: freebsd-fs@FreeBSD.org Subject: Big problem with zfs.... Message-ID: <20140916165511.GA89818@pcjas.obspm.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.23 (2014-03-12) X-Miltered: at smtp-int-m.obspm.fr with ID 54186B6F.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 54186B6F.000/145.238.184.233/pcjas.obspm.fr/pcjas.obspm.fr/ X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 16:55:23 -0000 Hi everyone. I got a very big problem with ZFS and FreeBSD 10-p9. I want to attach a new disk array on my server so I shutdown it and attach the disk array. After that the boot go to kernel panic when the ZFS is started. So I dettach the disk array so the on the hardware the server is exactly in the same condition as before. But event that I can boot it. I still got the kernel panic. If I disable the zfs in the rc.conf I can boot the server. But if I launch zfs with /etc/rc.d/zfs onestart zpool import zpool import -N I got this kind of message on the console panic : solaris assert : sm->sm_space == total (0x315b7e6800 == 0x315b7e5600), file : /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/space_map.c, line:549 cpuid=20 Any help would be very appreciated..... Regards. JAS -- Albert SHIH DIO bâtiment 15 Observatoire de Paris 5 Place Jules Janssen 92195 Meudon Cedex France Téléphone : +33 1 45 07 76 26/+33 6 86 69 95 71 xmpp: jas@obspm.fr Heure local/Local time: mar 16 sep 2014 18:48:53 CEST From owner-freebsd-fs@FreeBSD.ORG Tue Sep 16 17:12:51 2014 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CAB73FDB for ; Tue, 16 Sep 2014 17:12:51 +0000 (UTC) Received: from smtp-int-m.obspm.fr (smtp-int-m.obspm.fr [145.238.187.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.obspm.fr", Issuer "TERENA SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 622D7DCE for ; Tue, 16 Sep 2014 17:12:50 +0000 (UTC) Received: from pcjas.obspm.fr (pcjas.obspm.fr [145.238.184.233]) by smtp-int-m.obspm.fr (8.14.4/8.14.4/SIO Observatoire de Paris - 07/2009) with ESMTP id s8GHClVE025460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 16 Sep 2014 19:12:48 +0200 Date: Tue, 16 Sep 2014 19:12:47 +0200 From: Albert Shih To: freebsd-fs@FreeBSD.org Subject: Re: Big problem with zfs.... Message-ID: <20140916171247.GB89818@pcjas.obspm.fr> References: <20140916165511.GA89818@pcjas.obspm.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20140916165511.GA89818@pcjas.obspm.fr> User-Agent: Mutt/1.5.23 (2014-03-12) X-Miltered: at smtp-int-m.obspm.fr with ID 54186F8F.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 54186F8F.000/145.238.184.233/pcjas.obspm.fr/pcjas.obspm.fr/ X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 17:12:51 -0000 Le 16/09/2014 à 18:55:11+0200, Albert Shih a écrit > Hi everyone. > > I got a very big problem with ZFS and FreeBSD 10-p9. > > I want to attach a new disk array on my server so I shutdown it and attach > the disk array. After that the boot go to kernel panic when the ZFS is > started. > > So I dettach the disk array so the on the hardware the server is exactly in > the same condition as before. > > But event that I can boot it. I still got the kernel panic. If I disable > the zfs in the rc.conf I can boot the server. But if I launch zfs with > > /etc/rc.d/zfs onestart > zpool import > zpool import -N > > I got this kind of message on the console > > panic : solaris assert : sm->sm_space == total (0x315b7e6800 == 0x315b7e5600), file : /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/space_map.c, > line:549 > cpuid=20 > here de dump message : Panic String: solaris assert: sm->sm_space == total (0x315b7e6800 == 0x315b7e5600), file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/space_map.c, line: 549 Dump Parity: 390813757 Bounds: 0 Dump Status: good I try to disable the zfs a the boot (everything is fine), and try to use zdb and launch zdb -c tank_name, and event that make the kernel panic. Any clue ? Hardware problem ? Regards. JAS -- Albert SHIH DIO bâtiment 15 Observatoire de Paris 5 Place Jules Janssen 92195 Meudon Cedex France Téléphone : +33 1 45 07 76 26/+33 6 86 69 95 71 xmpp: jas@obspm.fr Heure local/Local time: mar 16 sep 2014 19:11:29 CEST From owner-freebsd-fs@FreeBSD.ORG Tue Sep 16 19:29:23 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 085D59CC for ; Tue, 16 Sep 2014 19:29:23 +0000 (UTC) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B5AFBF93 for ; Tue, 16 Sep 2014 19:29:22 +0000 (UTC) Received: by mail-qc0-f175.google.com with SMTP id w7so543507qcr.6 for ; Tue, 16 Sep 2014 12:29:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayphoto.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=RgDs7l9+X/aX7VkauR/rc8QMqwuOwCNNj+1/DSMXKi0=; b=jjbRYEAuFavvGw+d/yFHDQHQTBsNVWXH1FS599Jt8Q8ABxKNiKQqQ3npHjmjmKkcHV Oc4ihKyC5pBz+vGwECh4yCLeJ2jWqtgUE6kwjTxiAzLPL9K12msvUr7iSOMxMlweta1z Du4wumm8W4r3sejTx8ju3sKwaFAALuG6aAbxY= 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:from:date :message-id:subject:to:cc:content-type; bh=RgDs7l9+X/aX7VkauR/rc8QMqwuOwCNNj+1/DSMXKi0=; b=KFAOaYKdM1CGXHcvHrxFWWsc6ewPFzKEQgwbKdJjRlZYcTWYKS781BIPCr9i+Ui+VD jfYuy+DUASYuOXq5+5HR/jiA7PnSUM/To/Fs7KOZviCXccvKtbk8FBGkfw57Q6rhzxwU PeiDq5504ZQ6bRFR+e9J/KoBKGiT+AgpaLcmhzuRVPjfwXSc1gMZGosBBVL/K9d5ZHp7 ux6IUPaEn7N77iL/kDpvp4IJv4OCiKgOg60Pmbv59RRz+dlb42+UwUbwvWaiQ5Fh2wGq SyRD4BbCshbLOUOZzuFpfcSIijgEnxYcHsEmW+B/j8T7lLgvFcEUVHm4Ams168pZC+/R jT5Q== X-Gm-Message-State: ALoCoQlgKxB3XmZCv8XahuFxD6zoNC/prENFsoTFhDl1J/Tk0/nLOhG1rHlWrcDxzfzyuEqOYFw8 X-Received: by 10.140.37.9 with SMTP id q9mr51668764qgq.40.1410895761737; Tue, 16 Sep 2014 12:29:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.86.230 with HTTP; Tue, 16 Sep 2014 12:29:01 -0700 (PDT) In-Reply-To: <20140916171247.GB89818@pcjas.obspm.fr> References: <20140916165511.GA89818@pcjas.obspm.fr> <20140916171247.GB89818@pcjas.obspm.fr> From: Mike Carlson Date: Tue, 16 Sep 2014 12:29:01 -0700 Message-ID: Subject: Re: Big problem with zfs.... To: Albert Shih Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 19:29:23 -0000 For obvious reasons, I am very interested in the forensic details of your panic. Please keep the mailing list in the loop, and if possible, provide a backtrace on the captured kernel panic. Mike C On Tue, Sep 16, 2014 at 10:12 AM, Albert Shih wrote: > Le 16/09/2014 =C3=A0 18:55:11+0200, Albert Shih a =C3=A9crit > > Hi everyone. > > > > I got a very big problem with ZFS and FreeBSD 10-p9. > > > > I want to attach a new disk array on my server so I shutdown it and > attach > > the disk array. After that the boot go to kernel panic when the ZFS is > > started. > > > > So I dettach the disk array so the on the hardware the server is exactl= y > in > > the same condition as before. > > > > But event that I can boot it. I still got the kernel panic. If I disabl= e > > the zfs in the rc.conf I can boot the server. But if I launch zfs with > > > > /etc/rc.d/zfs onestart > > zpool import > > zpool import -N > > > > I got this kind of message on the console > > > > panic : solaris assert : sm->sm_space =3D=3D total (0x315b7e6800 =3D=3D > 0x315b7e5600), file : > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs= /space_map.c, > > line:549 > > cpuid=3D20 > > > > here de dump message : > > Panic String: solaris assert: sm->sm_space =3D=3D total (0x315b7e6800 = =3D=3D > 0x315b7e5600), file: > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs= /space_map.c, > line: 549 > Dump Parity: 390813757 > Bounds: 0 > Dump Status: good > > I try to disable the zfs a the boot (everything is fine), and try to use > zdb and launch zdb -c tank_name, and event that make the kernel panic. > > Any clue ? Hardware problem ? > > Regards. > > JAS > -- > Albert SHIH > DIO b=C3=A2timent 15 > Observatoire de Paris > 5 Place Jules Janssen > 92195 Meudon Cedex > France > T=C3=A9l=C3=A9phone : +33 1 45 07 76 26/+33 6 86 69 95 71 > xmpp: jas@obspm.fr > Heure local/Local time: > mar 16 sep 2014 19:11:29 CEST > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Tue Sep 16 22:51:17 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0184AEEF for ; Tue, 16 Sep 2014 22:51:16 +0000 (UTC) Received: from smtp-int-m.obspm.fr (smtp-int-m.obspm.fr [145.238.187.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.obspm.fr", Issuer "TERENA SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9F6EA998 for ; Tue, 16 Sep 2014 22:51:16 +0000 (UTC) Received: from pcjas.obspm.fr (pcjas.obspm.fr [145.238.184.233]) by smtp-int-m.obspm.fr (8.14.4/8.14.4/SIO Observatoire de Paris - 07/2009) with ESMTP id s8GMp4tn008083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 17 Sep 2014 00:51:05 +0200 Date: Wed, 17 Sep 2014 00:51:04 +0200 From: Albert Shih To: Mike Carlson Subject: Re: Big problem with zfs.... Message-ID: <20140916225104.GA76997@pcjas.obspm.fr> References: <20140916165511.GA89818@pcjas.obspm.fr> <20140916171247.GB89818@pcjas.obspm.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Miltered: at smtp-int-m.obspm.fr with ID 5418BED8.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5418BED8.000/145.238.184.233/pcjas.obspm.fr/pcjas.obspm.fr/ Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 22:51:17 -0000 Le 16/09/2014 à 12:29:01-0700, Mike Carlson a écrit > For obvious reasons, I am very interested in the forensic details of your > panic. But I don't have lot of time this server is in production. So tomorrow I don't have to choice to erase everything. > > Please keep the mailing list in the loop, and if possible, provide a backtrace > on the captured kernel panic. Well...I'm not very good about that... But is it what you want ? 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 conditions. 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"... Unread portion of the kernel message buffer: panic: solaris assert: sm->sm_space == total (0x315b7e6800 == 0x315b7e5600), file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/space_map.c, line: 549 cpuid = 21 KDB: stack backtrace: #0 0xffffffff808e7e90 at kdb_backtrace+0x60 #1 0xffffffff808af975 at panic+0x155 #2 0xffffffff81b6b23f at assfail3+0x2f #3 0xffffffff81a809e2 at space_map_sync+0x362 #4 0xffffffff81a69802 at metaslab_sync+0x522 #5 0xffffffff81a8686b at vdev_sync+0xcb #6 0xffffffff81a78afb at spa_sync+0x5db #7 0xffffffff81a81925 at txg_sync_thread+0x375 #8 0xffffffff80881a4a at fork_exit+0x9a #9 0xffffffff80c75a5e at fork_trampoline+0xe Uptime: 3m57s Dumping 4358 out of 131004 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% Reading symbols from /boot/kernel/ums.ko.symbols...done. Loaded symbols for /boot/kernel/ums.ko.symbols Reading symbols from /boot/kernel/zfs.ko.symbols...done. Loaded symbols for /boot/kernel/zfs.ko.symbols Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. Loaded symbols for /boot/kernel/opensolaris.ko.symbols #0 doadump (textdump=) at pcpu.h:219 219 __asm("movq %%gs:%1,%0" : "=r" (td) (kgdb) backtrace #0 doadump (textdump=) at pcpu.h:219 #1 0xffffffff808af5f0 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0xffffffff808af9b4 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:754 #3 0xffffffff81b6b23f in assfail3 (a=, lv=, op=, rv=, f=, l=) at /usr/src/sys/modules/opensolaris/../../cddl/compat/opensolaris/kern/opensolaris_cmn_err.c:91 #4 0xffffffff81a809e2 in space_map_sync (sm=, maptype=, smo=, os=0xfffff805ee015400, tx=0xfffff80051685c00) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/space_map.c:549 #5 0xffffffff81a69802 in metaslab_sync (msp=0xfffff8052905f700, txg=4084081) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/metaslab.c:1157 #6 0xffffffff81a8686b in vdev_sync (vd=0xfffff80051ba2000, txg=4084081) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c:2255 #7 0xffffffff81a78afb in spa_sync (spa=, txg=) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:6426 #8 0xffffffff81a81925 in txg_sync_thread (arg=0xfffff8005197c000) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/txg.c:515 #9 0xffffffff80881a4a in fork_exit (callout=0xffffffff81a815b0 , arg=0xfffff8005197c000, frame=0xfffffe2022757ac0) at /usr/src/sys/kern/kern_fork.c:995 #10 0xffffffff80c75a5e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:606 #11 0x0000000000000000 in ?? () Current language: auto; currently minimal (kgdb) > > Mike C > > On Tue, Sep 16, 2014 at 10:12 AM, Albert Shih wrote: > >  Le 16/09/2014 à 18:55:11+0200, Albert Shih a écrit > > Hi everyone. > > > > I got a very big problem with ZFS and FreeBSD 10-p9. > > > > I want to attach a new disk array on my server so I shutdown it and > attach > > the disk array. After that the boot go to kernel panic when the ZFS is > > started. > > > > So I dettach the disk array so the on the hardware the server is exactly > in > > the same condition as before. > > > > But event that I can boot it. I still got the kernel panic. If I disable > > the zfs in the rc.conf I can boot the server. But if I launch zfs with > > > >   /etc/rc.d/zfs onestart > >   zpool import > >   zpool import -N > > > > I got this kind of message on the console > > > > panic : solaris assert : sm->sm_space == total (0x315b7e6800 == > 0x315b7e5600), file : /usr/src/sys/modules/zfs/../../cddl/contrib/ > opensolaris/uts/common/fs/zfs/space_map.c, > > line:549 > > cpuid=20 > > > > here de dump message : > >   Panic String: solaris assert: sm->sm_space == total (0x315b7e6800 == > 0x315b7e5600), file: /usr/src/sys/modules/zfs/../../cddl/contrib/ > opensolaris/uts/common/fs/zfs/space_map.c, line: 549 >   Dump Parity: 390813757 >   Bounds: 0 >   Dump Status: good > > I try to disable the zfs a the boot (everything is fine), and try to use > zdb and launch zdb -c tank_name, and event that make the kernel panic. > > Any clue ? Hardware problem ? > > Regards. > > JAS > -- > Albert SHIH > DIO bâtiment 15 > Observatoire de Paris > 5 Place Jules Janssen > 92195 Meudon Cedex > France > Téléphone : +33 1 45 07 76 26/+33 6 86 69 95 71 > xmpp: jas@obspm.fr > Heure local/Local time: > mar 16 sep 2014 19:11:29 CEST > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > > -- Albert SHIH DIO bâtiment 15 Observatoire de Paris 5 Place Jules Janssen 92195 Meudon Cedex France Téléphone : +33 1 45 07 76 26/+33 6 86 69 95 71 xmpp: jas@obspm.fr Heure local/Local time: mer 17 sep 2014 00:48:22 CEST From owner-freebsd-fs@FreeBSD.ORG Wed Sep 17 10:36:35 2014 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CBFB8630 for ; Wed, 17 Sep 2014 10:36:35 +0000 (UTC) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.24]) (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 5C905B1E for ; Wed, 17 Sep 2014 10:36:35 +0000 (UTC) Received: from [87.79.198.18] (helo=fabiankeil.de) by smtprelay01.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1XUCb4-0000fu-O6 for freebsd-fs@FreeBSD.org; Wed, 17 Sep 2014 12:36:27 +0200 Date: Wed, 17 Sep 2014 12:36:30 +0200 From: Fabian Keil To: Subject: General protection fault after setting vfs.zfs.vdev.aggregation_limit above SPA_MAXBLOCKSIZE Message-ID: <3e120694.116e4008@fabiankeil.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/z5ih3lfyzX0li78VDDYUBRP"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 10:36:35 -0000 --Sig_/z5ih3lfyzX0li78VDDYUBRP Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable For testing purposes I reduced vfs.zfs.vdev.aggregation_limit to 32768 and later on set it "back" to 128000 followed by 132768 (not remembering the default and being to lazy to look it up). A couple of seconds after the last change I got the following panic: fk@r500 /usr/crash $kgdb kernel.1/kernel.symbols vmcore.1 [...] Unread portion of the kernel message buffer: [24663]=20 [24663]=20 [24663] Fatal trap 9: general protection fault while in kernel mode [24663] cpuid =3D 0; apic id =3D 00 [24663] instruction pointer =3D 0x20:0xffffffff810ec708 [24663] stack pointer =3D 0x28:0xfffffe0094e77340 [24663] frame pointer =3D 0x28:0xfffffe0094e77350 [24663] code segment =3D base 0x0, limit 0xfffff, type 0x1b [24663] =3D DPL 0, pres 1, long 1, def32 0, gran 1 [24663] processor eflags =3D interrupt enabled, resume, IOPL =3D 0 [24663] current process =3D 11715 (rsync) [24663] Uptime: 6h51m3s [24663] Dumping 317 out of 1973 MB:..6%..11%..21%..31%..41%..51%..61%..71%.= .81%..91% [...] Loaded symbols for /usr/crash/kernel.1/geom_gate.ko.symbols #0 doadump (textdump=3D1) at pcpu.h:219 219 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump (textdump=3D1) at pcpu.h:219 #1 0xffffffff8059799d in kern_reboot (howto=3D260) at /usr/src/sys/kern/ke= rn_shutdown.c:447 #2 0xffffffff80597ef0 in panic (fmt=3D) at /usr/src/s= ys/kern/kern_shutdown.c:746 #3 0xffffffff8030ef57 in db_panic (addr=3D, have_addr= =3D-10592, count=3D0, modif=3D0x0) at /usr/src/sys/ddb/db_command.c:482 #4 0xffffffff8030eb6d in db_command (cmd_table=3D0x0) at /usr/src/sys/ddb/= db_command.c:449 #5 0xffffffff8030e8e4 in db_command_loop () at /usr/src/sys/ddb/db_command= .c:502 #6 0xffffffff80311340 in db_trap (type=3D, code=3D0) = at /usr/src/sys/ddb/db_main.c:231 #7 0xffffffff805d7da1 in kdb_trap (type=3D9, code=3D0, tf=3D) at /usr/src/sys/kern/subr_kdb.c:654 #8 0xffffffff8085b83c in trap_fatal (frame=3D0xfffffe0094e77290, eva=3D) at /usr/src/sys/amd64/amd64/trap.c:861 #9 0xffffffff8085b4de in trap (frame=3D) at /usr/src/= sys/amd64/amd64/trap.c:201 #10 0xffffffff8083f552 in calltrap () at /usr/src/sys/amd64/amd64/exception= .S:231 #11 0xffffffff810ec708 in list_prev (list=3D0xffffffff81223038, object=3D0x= 5345413a317652ac) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/os/li= st.c:183 #12 0xffffffff810f9d7e in arc_evict (state=3D0xffffffff81222d00, spa=3D0, b= ytes=3D131072, recycle=3D, type=3DARC_BUFC_DATA) at /u= sr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:2037 #13 0xffffffff810f8695 in arc_get_data_buf (buf=3D0xfffff8006e6f43a8) at /u= sr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:2865 #14 0xffffffff810f88d6 in arc_loan_buf (spa=3D, size= =3D131072) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c= :1544 #15 0xffffffff8110bb61 in dmu_request_arcbuf (handle=3D, size=3D0) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu= .c:1299 #16 0xffffffff8119d390 in zfs_freebsd_write (ap=3D) at= /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:989 #17 0xffffffff808ea0f5 in VOP_WRITE_APV (vop=3D, a=3D<= value optimized out>) at vnode_if.c:997 #18 0xffffffff80663c89 in vn_write (fp=3D0xfffff8005bf4c320, uio=3D0xfffffe= 0094e77ab0, active_cred=3D, flags=3D160, td=3D0x3e26) = at vnode_if.h:413 #19 0xffffffff8065fa1b in vn_io_fault (fp=3D0xfffff8005bf4c320, uio=3D0xfff= ffe0094e77ab0, active_cred=3D0x5345413a317652ac, flags=3D0, td=3D0x3e26) at= /usr/src/sys/kern/vfs_vnops.c:1150 #20 0xffffffff805f31f7 in dofilewrite (td=3D0xfffff8006ec64920, fd=3D3, fp= =3D0xfffff8005bf4c320, auio=3D0xfffffe0094e77ab0, offset=3D, flags=3D0) at file.h:299 #21 0xffffffff805f2f28 in kern_writev (td=3D0xfffff8006ec64920, fd=3D3, aui= o=3D0xfffffe0094e77ab0) at /usr/src/sys/kern/sys_generic.c:467 #22 0xffffffff805f2eb3 in sys_write (td=3D, uap=3D) at /usr/src/sys/kern/sys_generic.c:382 #23 0xffffffff8085c2db in amd64_syscall (td=3D0xfffff8006ec64920, traced=3D= 0) at subr_syscall.c:133 #24 0xffffffff8083f83b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exce= ption.S:390 #25 0x0000000800e0840a in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) f 11 #11 0xffffffff810ec708 in list_prev (list=3D0xffffffff81223038, object=3D0x= 5345413a317652ac) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/os/li= st.c:183 183 list_node_t *node =3D list_d2l(list, object); (kgdb) p *list $1 =3D {list_size =3D 216, list_offset =3D 160, list_head =3D {list_next = =3D 0xfffff80059681328, list_prev =3D 0xfffff80058a53328}} (kgdb) p *(arc_buf_hdr_t *)object Cannot access memory at address 0x5345413a317652ac The system is FreeBSD 11.0-CURRENT based on r271610. Assuming this was actually caused by the vfs.zfs.vdev.aggregation_limit modification I'm unlikely to run into it again, but I'm wondering if it is the expected and intended behaviour. Fabian --Sig_/z5ih3lfyzX0li78VDDYUBRP Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlQZZC0ACgkQBYqIVf93VJ1yBACgu6ix9PicQYculHevqF24UKnM c8MAmwTBgCfdPlLlcIEJz7eK4jT4Bq4b =qHOZ -----END PGP SIGNATURE----- --Sig_/z5ih3lfyzX0li78VDDYUBRP-- From owner-freebsd-fs@FreeBSD.ORG Thu Sep 18 20:55:33 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B3F0A363 for ; Thu, 18 Sep 2014 20:55:33 +0000 (UTC) Received: from relay.exonetric.net (relay0.exonetric.net [178.250.72.161]) by mx1.freebsd.org (Postfix) with ESMTP id 815332ED for ; Thu, 18 Sep 2014 20:55:32 +0000 (UTC) Received: from [192.168.10.204] (186.211.187.81.in-addr.arpa [81.187.211.186]) by relay.exonetric.net (Postfix) with ESMTPSA id 7B09F273D8 for ; Thu, 18 Sep 2014 21:48:42 +0100 (BST) From: Mark Blackman Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: either gptzfsboot or zfsloader hangs during boot after kernel and pool upgrade Message-Id: <6F3D0C72-D774-4B1F-8A5F-25CD1C55EBE0@exonetric.com> Date: Thu, 18 Sep 2014 21:48:41 +0100 To: freebsd-fs@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 20:55:33 -0000 Hi, I=92ve filed https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D193758 = on the subject topic, but thought I would publicise the issue here too. Short story: following a zpool upgrade on a FreeBSD 8.4 system, the = system now freezes very early in boot process. Regards, Mark Blackman From owner-freebsd-fs@FreeBSD.ORG Fri Sep 19 08:32:14 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 79DDFC3B for ; Fri, 19 Sep 2014 08:32:14 +0000 (UTC) Received: from smtp-int-m.obspm.fr (smtp-int-m.obspm.fr [145.238.187.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.obspm.fr", Issuer "TERENA SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0F109C3B for ; Fri, 19 Sep 2014 08:32:13 +0000 (UTC) Received: from pcjas.obspm.fr (pcjas.obspm.fr [145.238.184.233]) by smtp-int-m.obspm.fr (8.14.4/8.14.4/SIO Observatoire de Paris - 07/2009) with ESMTP id s8J8W3vE008122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 19 Sep 2014 10:32:04 +0200 Date: Fri, 19 Sep 2014 10:32:41 +0200 From: Albert Shih To: Mike Carlson Subject: Re: Big problem with zfs.... Message-ID: <20140919083241.GA3353@pcjas.obspm.fr> References: <20140916165511.GA89818@pcjas.obspm.fr> <20140916171247.GB89818@pcjas.obspm.fr> <20140916225104.GA76997@pcjas.obspm.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20140916225104.GA76997@pcjas.obspm.fr> User-Agent: Mutt/1.5.23 (2014-03-12) X-Miltered: at smtp-int-m.obspm.fr with ID 541BEA03.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 541BEA03.000/145.238.184.233/pcjas.obspm.fr/pcjas.obspm.fr/ Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 08:32:14 -0000 Le 17/09/2014 à 00:51:04+0200, Albert Shih a écrit > Le 16/09/2014 à 12:29:01-0700, Mike Carlson a écrit So no one as any clue ? > > For obvious reasons, I am very interested in the forensic details of your > > panic. > > But I don't have lot of time this server is in production. So tomorrow I don't have to choice > to erase everything. In fact I manage to restart all service in a new disk array. So I'm going to keep this fail zpool under zdb So here what I did : 1/ Boot with live-cd of openindiana --> no succes the OS don't seem to find the device, all disk are always in « noconfigured » status. 2/ Boot with lice-cd of FreeBSD 11 --> Almost the same thing as with FreeBSD 10, the only difference is I don't get a kernel panic but just a Abort kernel trap. 3/ Put the disk array on some other FreeBSD 10 server --> same result kernel panic. 4/ Destroy /boot/zfs/zfs.cache, after that I'm able to start zfs without mounting the bad-zpool. So now because I can use the new disk array I restart all my service, and I launch in a screen the zdb -cbveL pool still....580 hours...before completed...:-( Regards. JAS -- Albert SHIH DIO bâtiment 15 Observatoire de Paris 5 Place Jules Janssen 92195 Meudon Cedex France Téléphone : +33 1 45 07 76 26/+33 6 86 69 95 71 xmpp: jas@obspm.fr Heure local/Local time: ven 19 sep 2014 10:27:20 CEST From owner-freebsd-fs@FreeBSD.ORG Fri Sep 19 09:59:37 2014 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DFBA0B52 for ; Fri, 19 Sep 2014 09:59:37 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 CE5ED9E0 for ; Fri, 19 Sep 2014 09:59:37 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s8J9xbwO028358 for ; Fri, 19 Sep 2014 09:59:37 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201409190959.s8J9xbwO028358@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-fs@FreeBSD.org Subject: Problem reports for freebsd-fs@FreeBSD.org that need special attention X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 Date: Fri, 19 Sep 2014 09:59:37 +0000 Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 09:59:38 -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 ----------------+-----------+------------------------------------------------- Needs MFC | 133174 | [msdosfs] [patch] msdosfs must support multibyt Needs MFC | 136470 | [nfs] Cannot mount / in read-only, over NFS Needs MFC | 139651 | [nfs] mount(8): read-only remount of NFS volume Needs MFC | 144447 | [zfs] sharenfs fsunshare() & fsshare_main() non Needs MFC | 155411 | [regression] [8.2-release] [tmpfs]: mount: tmpf 5 problems total for which you should take action. From owner-freebsd-fs@FreeBSD.ORG Fri Sep 19 16:47:10 2014 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2EDA6A4D for ; Fri, 19 Sep 2014 16:47:10 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 0D6E1CD8 for ; Fri, 19 Sep 2014 16:47:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id s8JGl9ZC074859 for ; Fri, 19 Sep 2014 16:47:09 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s8JGl9OS074858 for freebsd-fs@FreeBSD.org; Fri, 19 Sep 2014 16:47:09 GMT (envelope-from bdrewery) Received: (qmail 21822 invoked from network); 19 Sep 2014 11:47:03 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 19 Sep 2014 11:47:03 -0500 Message-ID: <541C5E01.9050609@FreeBSD.org> Date: Fri, 19 Sep 2014 11:46:57 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: FreeBSD FS Subject: ZFS deadlock in zfs_lookup/zfs_dirent_lock on head r271170 OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AovFtsMAopsf2pnHgGh8EofEDRv3pS57s" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 16:47:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --AovFtsMAopsf2pnHgGh8EofEDRv3pS57s Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable rename is: https://people.freebsd.org/~bdrewery/rename.c All files are in the same mountpoint. > # ps uaxwww|egrep "(rm|rename)" > root 96901 0.0 0.0 12300 1948 2 D+ 11:01AM 0:00.00 rm -= rf /poudriere/data/.m/exp-head-commit-test-devel/ref/.p/cleaning/deps/py2= 7-PasteScript-1.7.5_2 > root 96903 0.0 0.0 8196 1912 2 D+ 11:01AM 0:00.00 rena= me /poudriere/data/.m/exp-head-commit-test-devel/ref/.p/deps/py27-PasteDe= ploy-1.5.0_1 /poudriere/data/.m/exp-head-commit-test-devel/ref/.p/cleanin= g/deps/py27-PasteDeploy-1.5.0_1 > root 3720 0.0 0.0 8196 1912 3 D+ 11:05AM 0:00.00 ./re= name /poudriere/data/.m/exp-head-commit-test-devel/ref/.p/deps/py27-Paste= Deploy-1.5.0_1 /poudriere/data/.m/exp-head-commit-test-devel/ref/.p/clean= ing/deps/py27-PasteDeploy-1.5.0_1 >=20 > # procstat -kka|egrep "(96901|96903|3720)" > 3720 100969 rename - mi_switch+0x179 sleepq_s= witch+0x152 sleepq_wait+0x43 _cv_wait+0x1da zfs_dirent_lock+0x212 zfs_dir= look+0x1b0 zfs_lookup+0x223 zfs_freebsd_lookup+0x91 VOP_CACHEDLOOKUP_APV+= 0xf1 vfs_cache_lookup+0xd6 VOP_LOOKUP_APV+0xf1 lookup+0x5ad namei+0x4e4 k= ern_renameat+0x95 filemon_wrapper_rename+0x19 amd64_syscall+0x25a Xfast_s= yscall+0xfb > 96901 101213 rm - mi_switch+0x179 sleepq_s= witch+0x152 sleepq_wait+0x43 sleeplk+0x14a __lockmgr_args+0x862 vop_stdlo= ck+0x3c VOP_LOCK1_APV+0xfc _vn_lock+0xaa zfs_lookup+0x462 zfs_freebsd_loo= kup+0x91 VOP_CACHEDLOOKUP_APV+0xf1 vfs_cache_lookup+0xd6 VOP_LOOKUP_APV+0= xf1 lookup+0x5ad namei+0x4e4 kern_statat_vnhook+0xae sys_fstatat+0x2c amd= 64_syscall+0x25a > 96903 101290 rename - mi_switch+0x179 sleepq_s= witch+0x152 sleepq_wait+0x43 sleeplk+0x14a __lockmgr_args+0xea1 vop_stdlo= ck+0x3c VOP_LOCK1_APV+0xfc _vn_lock+0xaa vputx+0x232 zfs_rename_unlock+0x= 78 zfs_freebsd_rename+0xfbb VOP_RENAME_APV+0xfc kern_renameat+0x3ef filem= on_wrapper_rename+0x19 amd64_syscall+0x25a Xfast_syscall+0xfb >=20 > # procstat -kka|grep zfs > 0 100698 kernel zfs_vn_rele_task mi_switch+0x179 sleepq_s= witch+0x152 sleepq_wait+0x43 _sleep+0x366 taskqueue_thread_loop+0xc8 fork= _exit+0x84 fork_trampoline+0xe > 3 100159 zfskern arc_reclaim_thre mi_switch+0x179 sleepq_s= witch+0x152 sleepq_timedwait+0x43 _cv_timedwait_sbt+0x200 arc_reclaim_thr= ead+0x2de fork_exit+0x84 fork_trampoline+0xe > 3 100160 zfskern l2arc_feed_threa mi_switch+0x179 sleepq_s= witch+0x152 sleepq_timedwait+0x43 _cv_timedwait_sbt+0x200 l2arc_feed_thre= ad+0x1d8 fork_exit+0x84 fork_trampoline+0xe > 3 100681 zfskern trim zroot mi_switch+0x179 sleepq_s= witch+0x152 sleepq_timedwait+0x43 _cv_timedwait_sbt+0x200 trim_thread+0x9= e fork_exit+0x84 fork_trampoline+0xe > 3 100715 zfskern txg_thread_enter mi_switch+0x179 sleepq_s= witch+0x152 sleepq_wait+0x43 _cv_wait+0x1da txg_thread_wait+0x9b txg_quie= sce_thread+0x420 fork_exit+0x84 fork_trampoline+0xe > 3 100716 zfskern txg_thread_enter mi_switch+0x179 sleepq_s= witch+0x152 sleepq_wait+0x43 _cv_wait+0x1da zio_wait+0x9b dsl_pool_sync+0= x35c spa_sync+0x530 txg_sync_thread+0x24d fork_exit+0x84 fork_trampoline+= 0xe > 3720 100969 rename - mi_switch+0x179 sleepq_s= witch+0x152 sleepq_wait+0x43 _cv_wait+0x1da zfs_dirent_lock+0x212 zfs_dir= look+0x1b0 zfs_lookup+0x223 zfs_freebsd_lookup+0x91 VOP_CACHEDLOOKUP_APV+= 0xf1 vfs_cache_lookup+0xd6 VOP_LOOKUP_APV+0xf1 lookup+0x5ad namei+0x4e4 k= ern_renameat+0x95 filemon_wrapper_rename+0x19 amd64_syscall+0x25a Xfast_s= yscall+0xfb > 96901 101213 rm - mi_switch+0x179 sleepq_s= witch+0x152 sleepq_wait+0x43 sleeplk+0x14a __lockmgr_args+0x862 vop_stdlo= ck+0x3c VOP_LOCK1_APV+0xfc _vn_lock+0xaa zfs_lookup+0x462 zfs_freebsd_loo= kup+0x91 VOP_CACHEDLOOKUP_APV+0xf1 vfs_cache_lookup+0xd6 VOP_LOOKUP_APV+0= xf1 lookup+0x5ad namei+0x4e4 kern_statat_vnhook+0xae sys_fstatat+0x2c amd= 64_syscall+0x25a > 96903 101290 rename - mi_switch+0x179 sleepq_s= witch+0x152 sleepq_wait+0x43 sleeplk+0x14a __lockmgr_args+0xea1 vop_stdlo= ck+0x3c VOP_LOCK1_APV+0xfc _vn_lock+0xaa vputx+0x232 zfs_rename_unlock+0x= 78 zfs_freebsd_rename+0xfbb VOP_RENAME_APV+0xfc kern_renameat+0x3ef filem= on_wrapper_rename+0x19 amd64_syscall+0x25a Xfast_syscall+0xfb --=20 Regards, Bryan Drewery --AovFtsMAopsf2pnHgGh8EofEDRv3pS57s Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJUHF4BAAoJEDXXcbtuRpfPVR0IAIcZ4BjwbiTR8swchS0kRyIl ih7vIFncj1bsNOKJAv0myReNWKdBBuCpsUgqxdygf75K9vCVQvzF+lIpVACMrekq O+ilOptnxYGLtTA8xjaIJLomcgp9u6xGVnDUhzPM9azAURVlvb9ARTPLqtrEA3vc T/NpQyRGNlr9/Ysc+amEvpaBaHsaG2lvQRT20A7hyNamtF3j8LP2qCjxnEMnD2lm YFXpbknGDaJmW9foGPPzAqW4+d8e7/kbDfyUo7Zo71NXSaAzu0aAuvIHoWfyEgPC w0ji2+G/pOtgEqjHWRYR+XxVcYWqh1GW6717wbVuhgwbg9c4Cl4/+OJjCcRdqr8= =HxW9 -----END PGP SIGNATURE----- --AovFtsMAopsf2pnHgGh8EofEDRv3pS57s-- From owner-freebsd-fs@FreeBSD.ORG Fri Sep 19 17:14:19 2014 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 95F09E6A for ; Fri, 19 Sep 2014 17:14:19 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 76EA2F64 for ; Fri, 19 Sep 2014 17:14:19 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s8JHEJ6c090948 for ; Fri, 19 Sep 2014 17:14:19 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 155411] [regression] [8.2-release] [tmpfs]: mount: tmpfs : No space left on device Date: Fri, 19 Sep 2014 17:14:19 +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: 8.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: bdrewery@FreeBSD.org X-Bugzilla-Status: Issue Resolved X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 17:14:19 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=155411 Bryan Drewery changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs MFC |Issue Resolved CC| |bdrewery@FreeBSD.org Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Fri Sep 19 20:36:07 2014 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D1F1A795 for ; Fri, 19 Sep 2014 20:36:07 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 B0744840 for ; Fri, 19 Sep 2014 20:36:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id s8JKa7nn053942 for ; Fri, 19 Sep 2014 20:36:07 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s8JKa73T053941 for freebsd-fs@FreeBSD.org; Fri, 19 Sep 2014 20:36:07 GMT (envelope-from bdrewery) Received: (qmail 40702 invoked from network); 19 Sep 2014 15:36:05 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 19 Sep 2014 15:36:05 -0500 Message-ID: <541C93AE.60906@FreeBSD.org> Date: Fri, 19 Sep 2014 15:35:58 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: FreeBSD FS Subject: Re: ZFS deadlock in zfs_lookup/zfs_dirent_lock on head r271170 References: <541C5E01.9050609@FreeBSD.org> In-Reply-To: <541C5E01.9050609@FreeBSD.org> OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nvEVGjCo5XphTDeI2mjQ0QPTSD130KL7C" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 20:36:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nvEVGjCo5XphTDeI2mjQ0QPTSD130KL7C Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 9/19/2014 11:46 AM, Bryan Drewery wrote: > rename is: https://people.freebsd.org/~bdrewery/rename.c >=20 > All files are in the same mountpoint. >=20 >> # ps uaxwww|egrep "(rm|rename)" >> root 96901 0.0 0.0 12300 1948 2 D+ 11:01AM 0:00.00 rm = -rf /poudriere/data/.m/exp-head-commit-test-devel/ref/.p/cleaning/deps/py= 27-PasteScript-1.7.5_2 >> root 96903 0.0 0.0 8196 1912 2 D+ 11:01AM 0:00.00 ren= ame /poudriere/data/.m/exp-head-commit-test-devel/ref/.p/deps/py27-PasteD= eploy-1.5.0_1 /poudriere/data/.m/exp-head-commit-test-devel/ref/.p/cleani= ng/deps/py27-PasteDeploy-1.5.0_1 >> root 3720 0.0 0.0 8196 1912 3 D+ 11:05AM 0:00.00 ./r= ename /poudriere/data/.m/exp-head-commit-test-devel/ref/.p/deps/py27-Past= eDeploy-1.5.0_1 /poudriere/data/.m/exp-head-commit-test-devel/ref/.p/clea= ning/deps/py27-PasteDeploy-1.5.0_1 >> >> # procstat -kka|egrep "(96901|96903|3720)" >> 3720 100969 rename - mi_switch+0x179 sleepq_= switch+0x152 sleepq_wait+0x43 _cv_wait+0x1da zfs_dirent_lock+0x212 zfs_di= rlook+0x1b0 zfs_lookup+0x223 zfs_freebsd_lookup+0x91 VOP_CACHEDLOOKUP_APV= +0xf1 vfs_cache_lookup+0xd6 VOP_LOOKUP_APV+0xf1 lookup+0x5ad namei+0x4e4 = kern_renameat+0x95 filemon_wrapper_rename+0x19 amd64_syscall+0x25a Xfast_= syscall+0xfb >> 96901 101213 rm - mi_switch+0x179 sleepq_= switch+0x152 sleepq_wait+0x43 sleeplk+0x14a __lockmgr_args+0x862 vop_stdl= ock+0x3c VOP_LOCK1_APV+0xfc _vn_lock+0xaa zfs_lookup+0x462 zfs_freebsd_lo= okup+0x91 VOP_CACHEDLOOKUP_APV+0xf1 vfs_cache_lookup+0xd6 VOP_LOOKUP_APV+= 0xf1 lookup+0x5ad namei+0x4e4 kern_statat_vnhook+0xae sys_fstatat+0x2c am= d64_syscall+0x25a >> 96903 101290 rename - mi_switch+0x179 sleepq_= switch+0x152 sleepq_wait+0x43 sleeplk+0x14a __lockmgr_args+0xea1 vop_stdl= ock+0x3c VOP_LOCK1_APV+0xfc _vn_lock+0xaa vputx+0x232 zfs_rename_unlock+0= x78 zfs_freebsd_rename+0xfbb VOP_RENAME_APV+0xfc kern_renameat+0x3ef file= mon_wrapper_rename+0x19 amd64_syscall+0x25a Xfast_syscall+0xfb >> >> # procstat -kka|grep zfs >> 0 100698 kernel zfs_vn_rele_task mi_switch+0x179 sleepq_= switch+0x152 sleepq_wait+0x43 _sleep+0x366 taskqueue_thread_loop+0xc8 for= k_exit+0x84 fork_trampoline+0xe >> 3 100159 zfskern arc_reclaim_thre mi_switch+0x179 sleepq_= switch+0x152 sleepq_timedwait+0x43 _cv_timedwait_sbt+0x200 arc_reclaim_th= read+0x2de fork_exit+0x84 fork_trampoline+0xe >> 3 100160 zfskern l2arc_feed_threa mi_switch+0x179 sleepq_= switch+0x152 sleepq_timedwait+0x43 _cv_timedwait_sbt+0x200 l2arc_feed_thr= ead+0x1d8 fork_exit+0x84 fork_trampoline+0xe >> 3 100681 zfskern trim zroot mi_switch+0x179 sleepq_= switch+0x152 sleepq_timedwait+0x43 _cv_timedwait_sbt+0x200 trim_thread+0x= 9e fork_exit+0x84 fork_trampoline+0xe >> 3 100715 zfskern txg_thread_enter mi_switch+0x179 sleepq_= switch+0x152 sleepq_wait+0x43 _cv_wait+0x1da txg_thread_wait+0x9b txg_qui= esce_thread+0x420 fork_exit+0x84 fork_trampoline+0xe >> 3 100716 zfskern txg_thread_enter mi_switch+0x179 sleepq_= switch+0x152 sleepq_wait+0x43 _cv_wait+0x1da zio_wait+0x9b dsl_pool_sync+= 0x35c spa_sync+0x530 txg_sync_thread+0x24d fork_exit+0x84 fork_trampoline= +0xe >> 3720 100969 rename - mi_switch+0x179 sleepq_= switch+0x152 sleepq_wait+0x43 _cv_wait+0x1da zfs_dirent_lock+0x212 zfs_di= rlook+0x1b0 zfs_lookup+0x223 zfs_freebsd_lookup+0x91 VOP_CACHEDLOOKUP_APV= +0xf1 vfs_cache_lookup+0xd6 VOP_LOOKUP_APV+0xf1 lookup+0x5ad namei+0x4e4 = kern_renameat+0x95 filemon_wrapper_rename+0x19 amd64_syscall+0x25a Xfast_= syscall+0xfb >> 96901 101213 rm - mi_switch+0x179 sleepq_= switch+0x152 sleepq_wait+0x43 sleeplk+0x14a __lockmgr_args+0x862 vop_stdl= ock+0x3c VOP_LOCK1_APV+0xfc _vn_lock+0xaa zfs_lookup+0x462 zfs_freebsd_lo= okup+0x91 VOP_CACHEDLOOKUP_APV+0xf1 vfs_cache_lookup+0xd6 VOP_LOOKUP_APV+= 0xf1 lookup+0x5ad namei+0x4e4 kern_statat_vnhook+0xae sys_fstatat+0x2c am= d64_syscall+0x25a >> 96903 101290 rename - mi_switch+0x179 sleepq_= switch+0x152 sleepq_wait+0x43 sleeplk+0x14a __lockmgr_args+0xea1 vop_stdl= ock+0x3c VOP_LOCK1_APV+0xfc _vn_lock+0xaa vputx+0x232 zfs_rename_unlock+0= x78 zfs_freebsd_rename+0xfbb VOP_RENAME_APV+0xfc kern_renameat+0x3ef file= mon_wrapper_rename+0x19 amd64_syscall+0x25a Xfast_syscall+0xfb >=20 >=20 >=20 PID 96903 / TID 101290: zfs_rename takes dirent_lock. It then calls zfs_rename_lock, which then is stuck in vrele() PID 3720 / TID 100969: zfs_dirlook waits on zfs_dirent_lock. PID 96901 I think can be ignored, it was fallout and ran 4 minutes after the deadlock. Some info from gdb the vnode stuck in vrele() follows. I'm not sure where to look from here due to it being 'SHARED' with no pid/tid owning i= t. > (kgdb) backtrace > #0 sched_switch (td=3D0xfffff80834e36490, newtd=3D, flags=3D) at /usr/src/sys/kern/sched_ule.c:1932 > #1 0xffffffff80929379 in mi_switch (flags=3D260, newtd=3D0x0) at /usr/= src/sys/kern/kern_synch.c:493 > #2 0xffffffff80966af2 in sleepq_switch (wchan=3D,= pri=3D) at /usr/src/sys/kern/subr_sleepqueue.c:552 > #3 0xffffffff80966953 in sleepq_wait (wchan=3D0xfffff8090c3259a0, pri=3D= 96) at /usr/src/sys/kern/subr_sleepqueue.c:631 > #4 0xffffffff808fdf3a in sleeplk (lk=3D, flags=3D= , ilk=3D, wmesg=3D, pri=3D, > timo=3D) at /usr/src/sys/kern/kern_lock.c:225 > #5 0xffffffff808fd601 in __lockmgr_args (lk=3D0xfffff8090c3259a0, flag= s=3D, ilk=3D0xfffff8090c3259d0, wmesg=3D, pri=3D, > timo=3D, file=3D0xffffffff80fcd0e8 "/usr/src/s= ys/kern/vfs_subr.c", line=3D2248) at /usr/src/sys/kern/kern_lock.c:939 > #6 0xffffffff809be27c in vop_stdlock (ap=3D) at l= ockmgr.h:98 > #7 0xffffffff80e5b75c in VOP_LOCK1_APV (vop=3D, a= =3D) at vnode_if.c:2082 > #8 0xffffffff809ddbca in _vn_lock (vp=3D0xfffff8090c325938, flags=3D, file=3D0xffffffff80fcd0e8 "/usr/src/sys/kern/vfs_sub= r.c", line=3D2248) at vnode_if.h:859 > #9 0xffffffff809ce662 in vputx (vp=3D0xfffff8090c325938, func=3D1) at = /usr/src/sys/kern/vfs_subr.c:2248 > #10 0xffffffff81e99b28 in zfs_rename_unlock (zlpp=3D0xfffffe12484b8758)= at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:3= 630 > #11 0xffffffff81e969bb in zfs_freebsd_rename (ap=3D) at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c= :4067 > #12 0xffffffff80e5ac1c in VOP_RENAME_APV (vop=3D, = a=3D) at vnode_if.c:1544 > #13 0xffffffff809dadcf in kern_renameat (td=3D, ol= dfd=3D, old=3D, newfd=3D, new=3D, > pathseg=3D) at vnode_if.h:636 > #14 0xffffffff820c5ab9 in filemon_wrapper_rename (td=3D0x0, uap=3D0xfff= ffe12484b8b80) at filemon_wrapper.c:326 > #15 0xffffffff80d38b6a in amd64_syscall (td=3D0xfffff80834e36490, trace= d=3D0) at subr_syscall.c:133 > #16 0xffffffff80d1a44b in Xfast_syscall () at /usr/src/sys/amd64/amd64/= exception.S:390 > #17 0x000000080088df9a in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) vprint 0xfffff8090c325938 > 0xfffff8090c325938: tag zfs, type VDIR > usecount 1, writecount 0, refcount 2 mountedhere 0x0 > flags () > lock type zfs: SHARED (count 2) with exclusive waiters pending > mount /poudriere/data/.m/exp-head-commit-test-devel/ref from zroot/= poudriere/jails/exp-head-commit-test-devel-ref > (kgdb) p *(struct vnode*)0xfffff8090c325938 > $22 =3D {v_tag =3D 0xffffffff81f0f8ff "zfs", v_op =3D 0xffffffff81f24b5= 0, v_data =3D 0xfffff809b8612a10, v_mount =3D 0xfffff8014c262660, v_nmntv= nodes =3D {tqe_next =3D 0xfffff8095e9aa760, > tqe_prev =3D 0xfffff80aa43d7780}, v_un =3D {vu_mount =3D 0x0, vu_so= cket =3D 0x0, vu_cdev =3D 0x0, vu_fifoinfo =3D 0x0}, v_hashlist =3D {le_n= ext =3D 0x0, le_prev =3D 0x0}, v_cache_src =3D { > lh_first =3D 0x0}, v_cache_dst =3D {tqh_first =3D 0xfffff80ac9c3531= 0, tqh_last =3D 0xfffff80ac9c35330}, v_cache_dd =3D 0xfffff80ac9c35310, v= _lock =3D {lock_object =3D { > lo_name =3D 0xffffffff81f0f8ff "zfs", lo_flags =3D 117112832, lo_= data =3D 0, lo_witness =3D 0xfffffe0000b28780}, lk_lock =3D 21, lk_exslpf= ail =3D 0, lk_timo =3D 51, lk_pri =3D 96}, v_interlock =3D { > lock_object =3D {lo_name =3D 0xffffffff80fc4bc6 "vnode interlock", = lo_flags =3D 16973824, lo_data =3D 0, lo_witness =3D 0xfffffe0000b1e500},= mtx_lock =3D 4}, v_vnlock =3D 0xfffff8090c3259a0, > v_actfreelist =3D {tqe_next =3D 0xfffff80a5421f1d8, tqe_prev =3D 0xff= fff8095e9aa820}, v_bufobj =3D {bo_lock =3D {lock_object =3D {lo_name =3D = 0xffffffff80fcd144 "bufobj interlock", > lo_flags =3D 86179840, lo_data =3D 0, lo_witness =3D 0xfffffe00= 00b26580}, rw_lock =3D 1}, bo_ops =3D 0xffffffff814ab900, bo_object =3D 0= x0, bo_synclist =3D {le_next =3D 0x0, le_prev =3D 0x0}, > bo_private =3D 0xfffff8090c325938, __bo_vnode =3D 0xfffff8090c32593= 8, bo_clean =3D {bv_hd =3D {tqh_first =3D 0x0, tqh_last =3D 0xfffff8090c3= 25a58}, bv_root =3D {pt_root =3D 0}, bv_cnt =3D 0}, > bo_dirty =3D {bv_hd =3D {tqh_first =3D 0x0, tqh_last =3D 0xfffff809= 0c325a78}, bv_root =3D {pt_root =3D 0}, bv_cnt =3D 0}, bo_numoutput =3D 0= , bo_flag =3D 0, bo_bsize =3D 131072}, v_pollinfo =3D 0x0, > v_label =3D 0x0, v_lockf =3D 0x0, v_rl =3D {rl_waiters =3D {tqh_first= =3D 0x0, tqh_last =3D 0xfffff8090c325ac0}, rl_currdep =3D 0x0}, v_cstart= =3D 0, v_lasta =3D 0, v_lastw =3D 0, v_clen =3D 0, > v_holdcnt =3D 2, v_usecount =3D 1, v_iflag =3D 512, v_vflag =3D 0, v_= writecount =3D 0, v_hash =3D 151794265, v_type =3D VDIR} --=20 Regards, Bryan Drewery --nvEVGjCo5XphTDeI2mjQ0QPTSD130KL7C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJUHJOuAAoJEDXXcbtuRpfPwEMH/AuNhw92TtrDsKCjmzuuBv0s uH37y0Fk1e7LSB4dChTeyH00bO+yEK9YKD3bSNqlr7PJY/nEZwBbulwYHPpYi4PN /HE7ykx0ZHrLAetuifQCXaZWHz15T40F5xmKduFgXC0F4Q0B9T3WV/r/dgxBNlGg lIbnJh7Nw0diOBQHtbCL0imQQMvsnr3koz7dRn29FrXikWbVB/4iMbBqBWU9KXV/ osNpeAMBhX69tLdf3zHVL3o7iFAInjLKovQgGgo8HdjUB5bigitBQ4meTL0Y0JI2 cba5zKcB2JvCa2DeoE3yynmqS6G2U3QtXMFPcUPjJFpObdQ63nLeyTdXGtUiP1A= =McIQ -----END PGP SIGNATURE----- --nvEVGjCo5XphTDeI2mjQ0QPTSD130KL7C-- From owner-freebsd-fs@FreeBSD.ORG Fri Sep 19 20:51:26 2014 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D1BCCB3C for ; Fri, 19 Sep 2014 20:51:26 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 B3A3A9EC for ; Fri, 19 Sep 2014 20:51:26 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id s8JKpQhg060162 for ; Fri, 19 Sep 2014 20:51:26 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id s8JKpQlA060161 for freebsd-fs@FreeBSD.org; Fri, 19 Sep 2014 20:51:26 GMT (envelope-from bdrewery) Received: (qmail 30170 invoked from network); 19 Sep 2014 15:51:25 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 19 Sep 2014 15:51:25 -0500 Message-ID: <541C9746.5020606@FreeBSD.org> Date: Fri, 19 Sep 2014 15:51:18 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: FreeBSD FS Subject: Re: ZFS deadlock in zfs_freebsd_lookup/zfs_freebsd_rename on head r271170 References: <541C5E01.9050609@FreeBSD.org> <541C93AE.60906@FreeBSD.org> In-Reply-To: <541C93AE.60906@FreeBSD.org> OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Ed7oGQgwKD5u9WmSs78TFlrUaXm7aV2tC" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 20:51:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Ed7oGQgwKD5u9WmSs78TFlrUaXm7aV2tC Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 9/19/2014 3:35 PM, Bryan Drewery wrote: > On 9/19/2014 11:46 AM, Bryan Drewery wrote: >> rename is: https://people.freebsd.org/~bdrewery/rename.c >> >> All files are in the same mountpoint. >> >>> # ps uaxwww|egrep "(rm|rename)" >>> root 96901 0.0 0.0 12300 1948 2 D+ 11:01AM 0:00.00 rm= -rf /poudriere/data/.m/exp-head-commit-test-devel/ref/.p/cleaning/deps/p= y27-PasteScript-1.7.5_2 >>> root 96903 0.0 0.0 8196 1912 2 D+ 11:01AM 0:00.00 re= name /poudriere/data/.m/exp-head-commit-test-devel/ref/.p/deps/py27-Paste= Deploy-1.5.0_1 /poudriere/data/.m/exp-head-commit-test-devel/ref/.p/clean= ing/deps/py27-PasteDeploy-1.5.0_1 >>> root 3720 0.0 0.0 8196 1912 3 D+ 11:05AM 0:00.00 ./= rename /poudriere/data/.m/exp-head-commit-test-devel/ref/.p/deps/py27-Pas= teDeploy-1.5.0_1 /poudriere/data/.m/exp-head-commit-test-devel/ref/.p/cle= aning/deps/py27-PasteDeploy-1.5.0_1 >>> >>> # procstat -kka|egrep "(96901|96903|3720)" >>> 3720 100969 rename - mi_switch+0x179 sleepq= _switch+0x152 sleepq_wait+0x43 _cv_wait+0x1da zfs_dirent_lock+0x212 zfs_d= irlook+0x1b0 zfs_lookup+0x223 zfs_freebsd_lookup+0x91 VOP_CACHEDLOOKUP_AP= V+0xf1 vfs_cache_lookup+0xd6 VOP_LOOKUP_APV+0xf1 lookup+0x5ad namei+0x4e4= kern_renameat+0x95 filemon_wrapper_rename+0x19 amd64_syscall+0x25a Xfast= _syscall+0xfb >>> 96901 101213 rm - mi_switch+0x179 sleepq= _switch+0x152 sleepq_wait+0x43 sleeplk+0x14a __lockmgr_args+0x862 vop_std= lock+0x3c VOP_LOCK1_APV+0xfc _vn_lock+0xaa zfs_lookup+0x462 zfs_freebsd_l= ookup+0x91 VOP_CACHEDLOOKUP_APV+0xf1 vfs_cache_lookup+0xd6 VOP_LOOKUP_APV= +0xf1 lookup+0x5ad namei+0x4e4 kern_statat_vnhook+0xae sys_fstatat+0x2c a= md64_syscall+0x25a >>> 96903 101290 rename - mi_switch+0x179 sleepq= _switch+0x152 sleepq_wait+0x43 sleeplk+0x14a __lockmgr_args+0xea1 vop_std= lock+0x3c VOP_LOCK1_APV+0xfc _vn_lock+0xaa vputx+0x232 zfs_rename_unlock+= 0x78 zfs_freebsd_rename+0xfbb VOP_RENAME_APV+0xfc kern_renameat+0x3ef fil= emon_wrapper_rename+0x19 amd64_syscall+0x25a Xfast_syscall+0xfb >>> >>> # procstat -kka|grep zfs >>> 0 100698 kernel zfs_vn_rele_task mi_switch+0x179 sleepq= _switch+0x152 sleepq_wait+0x43 _sleep+0x366 taskqueue_thread_loop+0xc8 fo= rk_exit+0x84 fork_trampoline+0xe >>> 3 100159 zfskern arc_reclaim_thre mi_switch+0x179 sleepq= _switch+0x152 sleepq_timedwait+0x43 _cv_timedwait_sbt+0x200 arc_reclaim_t= hread+0x2de fork_exit+0x84 fork_trampoline+0xe >>> 3 100160 zfskern l2arc_feed_threa mi_switch+0x179 sleepq= _switch+0x152 sleepq_timedwait+0x43 _cv_timedwait_sbt+0x200 l2arc_feed_th= read+0x1d8 fork_exit+0x84 fork_trampoline+0xe >>> 3 100681 zfskern trim zroot mi_switch+0x179 sleepq= _switch+0x152 sleepq_timedwait+0x43 _cv_timedwait_sbt+0x200 trim_thread+0= x9e fork_exit+0x84 fork_trampoline+0xe >>> 3 100715 zfskern txg_thread_enter mi_switch+0x179 sleepq= _switch+0x152 sleepq_wait+0x43 _cv_wait+0x1da txg_thread_wait+0x9b txg_qu= iesce_thread+0x420 fork_exit+0x84 fork_trampoline+0xe >>> 3 100716 zfskern txg_thread_enter mi_switch+0x179 sleepq= _switch+0x152 sleepq_wait+0x43 _cv_wait+0x1da zio_wait+0x9b dsl_pool_sync= +0x35c spa_sync+0x530 txg_sync_thread+0x24d fork_exit+0x84 fork_trampolin= e+0xe >>> 3720 100969 rename - mi_switch+0x179 sleepq= _switch+0x152 sleepq_wait+0x43 _cv_wait+0x1da zfs_dirent_lock+0x212 zfs_d= irlook+0x1b0 zfs_lookup+0x223 zfs_freebsd_lookup+0x91 VOP_CACHEDLOOKUP_AP= V+0xf1 vfs_cache_lookup+0xd6 VOP_LOOKUP_APV+0xf1 lookup+0x5ad namei+0x4e4= kern_renameat+0x95 filemon_wrapper_rename+0x19 amd64_syscall+0x25a Xfast= _syscall+0xfb >>> 96901 101213 rm - mi_switch+0x179 sleepq= _switch+0x152 sleepq_wait+0x43 sleeplk+0x14a __lockmgr_args+0x862 vop_std= lock+0x3c VOP_LOCK1_APV+0xfc _vn_lock+0xaa zfs_lookup+0x462 zfs_freebsd_l= ookup+0x91 VOP_CACHEDLOOKUP_APV+0xf1 vfs_cache_lookup+0xd6 VOP_LOOKUP_APV= +0xf1 lookup+0x5ad namei+0x4e4 kern_statat_vnhook+0xae sys_fstatat+0x2c a= md64_syscall+0x25a >>> 96903 101290 rename - mi_switch+0x179 sleepq= _switch+0x152 sleepq_wait+0x43 sleeplk+0x14a __lockmgr_args+0xea1 vop_std= lock+0x3c VOP_LOCK1_APV+0xfc _vn_lock+0xaa vputx+0x232 zfs_rename_unlock+= 0x78 zfs_freebsd_rename+0xfbb VOP_RENAME_APV+0xfc kern_renameat+0x3ef fil= emon_wrapper_rename+0x19 amd64_syscall+0x25a Xfast_syscall+0xfb >> >> >> >=20 > PID 96903 / TID 101290: zfs_rename takes dirent_lock. It then calls > zfs_rename_lock, which then is stuck in vrele() >=20 > PID 3720 / TID 100969: zfs_dirlook waits on zfs_dirent_lock. >=20 > PID 96901 I think can be ignored, it was fallout and ran 4 minutes afte= r > the deadlock. Oops, that is all wrong. PID 3720 can be ignored. This is not related to zfs_dirent_lock. I will look at the core a bit later to determine which vnodes each thread has locked and are waiting on. I need to run out at the moment. --=20 Regards, Bryan Drewery --Ed7oGQgwKD5u9WmSs78TFlrUaXm7aV2tC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iQEcBAEBAgAGBQJUHJdGAAoJEDXXcbtuRpfPvToH/1DKwLOxtXS4Sx1mecW2e6sT tBxrn0NzegQaqehZjti5pfjeWgwHKNZCZkmV1E4FmNTj41Z1NmxQDpsCLg24WcnF eu3JpVE6KrjSdIuNCiPYVbrVUl+wrP9CRcjqXCAROgvB6ouDngUXynay/kr9Ao1q 1THN5/3WTRnQeJTDWPtLU3JKTk7J4kkSEN9CS9PgR9qUQ1pBm5Id8QKJtymBfU8h zHnrxUCXWqZss47bQnQSW17+R+Dkz6ej5mxw8x20/aMg3YJDrTEfjrA8h4oD2B1/ rzVIfUPmvTzPcnAUuxjGyd+JcKOIjDX+pwTHNE5yNYSnZHZsdejoxDnRlUEM6kg= =q3ex -----END PGP SIGNATURE----- --Ed7oGQgwKD5u9WmSs78TFlrUaXm7aV2tC--