From owner-freebsd-fs@FreeBSD.ORG Sun Nov 22 14:40:25 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F38F4106566B for ; Sun, 22 Nov 2009 14:40:24 +0000 (UTC) (envelope-from fb-fs@psconsult.nl) Received: from mx1.psconsult.nl (psc11.adsl.iaf.nl [80.89.238.138]) by mx1.freebsd.org (Postfix) with ESMTP id 722B18FC1E for ; Sun, 22 Nov 2009 14:40:24 +0000 (UTC) Received: from mx1.psconsult.nl (localhost [80.89.238.138]) by mx1.psconsult.nl (8.14.2/8.14.2) with ESMTP id nAMEPqDh039582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 22 Nov 2009 15:25:57 +0100 (CET) (envelope-from fb-fs@psconsult.nl) Received: (from paul@localhost) by mx1.psconsult.nl (8.14.2/8.14.2/Submit) id nAMEPqBB039581 for freebsd-fs@freebsd.org; Sun, 22 Nov 2009 15:25:52 +0100 (CET) (envelope-from fb-fs@psconsult.nl) Date: Sun, 22 Nov 2009 15:25:52 +0100 From: Paul Schenkeveld To: freebsd-fs@freebsd.org Message-ID: <20091122142552.GA39554@psconsult.nl> Mail-Followup-To: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) Subject: ZFS whole_disk=0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 14:40:25 -0000 Hi, I noticed (on 8.0-RC2 amd64) that zdb always reports whole_disk=0 even when using /dev/ad6 as vdev. How do I tell zpool that my vdev is really a whole disk? Is there a big performace penalty (or other disadvantage) when whole_disk == 0? Regards, Paul Schenkeveld From owner-freebsd-fs@FreeBSD.ORG Sun Nov 22 15:37:23 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A2391065676 for ; Sun, 22 Nov 2009 15:37:23 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.freenix.fr (keltia.freenix.org [IPv6:2001:660:330f:f820:213:72ff:fe15:f44]) by mx1.freebsd.org (Postfix) with ESMTP id EF6B48FC27 for ; Sun, 22 Nov 2009 15:37:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by keltia.freenix.fr (Postfix/TLS) with ESMTP id 0822B10F1 for ; Sun, 22 Nov 2009 16:37:20 +0100 (CET) X-Virus-Scanned: amavisd-new at keltia.freenix.fr Received: from keltia.freenix.fr ([127.0.0.1]) by localhost (keltia.freenix.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgbpm4LMtXoF for ; Sun, 22 Nov 2009 16:37:19 +0100 (CET) Received: from rron.freenix.org (rron.freenix.org [193.56.58.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.freenix.fr (Postfix/TLS) with ESMTPSA id 6490410CC for ; Sun, 22 Nov 2009 16:37:19 +0100 (CET) Date: Sun, 22 Nov 2009 16:36:50 +0100 From: Ollivier Robert To: freebsd-fs@freebsd.org Message-ID: <20091122153650.GA55532@rron.freenix.org> References: <20091122142552.GA39554@psconsult.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20091122142552.GA39554@psconsult.nl> X-Operating-System: MacOS X / Macbook Pro - FreeBSD 7.2 / Dell D820 SMP User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: ZFS whole_disk=0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 15:37:23 -0000 According to Paul Schenkeveld: >Is there a big performace penalty (or other disadvantage) when >whole_disk == 0? None that I know of, Solaris disable the write cache if it is not using the whole disk but FreeBSD does not have this issue. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ From owner-freebsd-fs@FreeBSD.ORG Sun Nov 22 15:42:57 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B023106568F for ; Sun, 22 Nov 2009 15:42:57 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.freenix.fr (keltia.freenix.org [IPv6:2001:660:330f:f820:213:72ff:fe15:f44]) by mx1.freebsd.org (Postfix) with ESMTP id 3CA808FC12 for ; Sun, 22 Nov 2009 15:42:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by keltia.freenix.fr (Postfix/TLS) with ESMTP id 450D239B7D for ; Sun, 22 Nov 2009 16:42:56 +0100 (CET) X-Virus-Scanned: amavisd-new at keltia.freenix.fr Received: from keltia.freenix.fr ([127.0.0.1]) by localhost (keltia.freenix.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vH+gQmvAPO4Z for ; Sun, 22 Nov 2009 16:42:55 +0100 (CET) Received: from rron.freenix.org (rron.freenix.org [193.56.58.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.freenix.fr (Postfix/TLS) with ESMTPSA id BBDD039B64 for ; Sun, 22 Nov 2009 16:42:55 +0100 (CET) Date: Sun, 22 Nov 2009 16:42:28 +0100 From: Ollivier Robert To: freebsd-fs@freebsd.org Message-ID: <20091122154228.GB55532@rron.freenix.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-Operating-System: MacOS X / Macbook Pro - FreeBSD 7.2 / Dell D820 SMP User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: 7.2 dies in zfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 15:42:57 -0000 According to Randy Bush: >i think the issue is how to tune for zfs > >i386 with 4G of RAM I've given up on ZFS on i386. Whatever tuning you could do is only delaying the inevitable. Even with lots of RAM, it will panic. I'd love being proven wrong as I also hav a 4 GB i386 with ZFS and it panics regularely. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ From owner-freebsd-fs@FreeBSD.ORG Sun Nov 22 16:15:45 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25495106566B for ; Sun, 22 Nov 2009 16:15:45 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.freenix.fr (keltia.freenix.org [IPv6:2001:660:330f:f820:213:72ff:fe15:f44]) by mx1.freebsd.org (Postfix) with ESMTP id B41FB8FC16 for ; Sun, 22 Nov 2009 16:15:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by keltia.freenix.fr (Postfix/TLS) with ESMTP id AB7E210F1; Sun, 22 Nov 2009 17:15:43 +0100 (CET) X-Virus-Scanned: amavisd-new at keltia.freenix.fr Received: from keltia.freenix.fr ([127.0.0.1]) by localhost (keltia.freenix.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbzmnrZI6wHr; Sun, 22 Nov 2009 17:15:43 +0100 (CET) Received: from rron.freenix.org (rron.freenix.org [193.56.58.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.freenix.fr (Postfix/TLS) with ESMTPSA id 4314310CC; Sun, 22 Nov 2009 17:15:43 +0100 (CET) Date: Sun, 22 Nov 2009 17:15:16 +0100 From: Ollivier Robert To: freebsd-fs@freebsd.org, Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <20091122161516.GC55532@rron.freenix.org> References: <772532900-1257123963-cardhu_decombobulator_blackberry.rim.net-1402739480-@bda715.bisx.prod.on.blackberry> <4AEEBD4B.1050407@quip.cz> <4AEEDB3B.5020600@quip.cz> <4AF46CA9.1040904@quip.cz> <9bbcef730911061101h5356d2acob2ac8791afe112@mail.gmail.com> <4AF5D611.7060408@quip.cz> <9bbcef730911071242m5ad91720xcccb7586c6848ffd@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <9bbcef730911071242m5ad91720xcccb7586c6848ffd@mail.gmail.com> X-Operating-System: MacOS X / Macbook Pro - FreeBSD 7.2 / Dell D820 SMP User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: Re: Performance issues with 8.0 ZFS and sendfile/lighttpd X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 16:15:45 -0000 According to Ivan Voras: >I'm not very familiar with this layer but since it uses struct buf and >the ZFS doesn't use bufcache, this is probably one of the things that >is bypassed, though it would be nice if it weren't since this code From what I understand from IRC, Kip is working on fixing ZFS with respect to struct buf (and also help with the ARC vs VM issues). -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ From owner-freebsd-fs@FreeBSD.ORG Sun Nov 22 19:47:06 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E54EA1065672 for ; Sun, 22 Nov 2009 19:47:06 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id C858C8FC13 for ; Sun, 22 Nov 2009 19:47:06 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NCIOm-000DXE-RO; Sun, 22 Nov 2009 19:47:04 +0000 Received: from host-40-47.meeting.ietf.org.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 3EE262C3292B; Mon, 23 Nov 2009 04:47:04 +0900 (JST) Date: Mon, 23 Nov 2009 04:47:03 +0900 Message-ID: From: Randy Bush To: Ollivier Robert In-Reply-To: <20091122154228.GB55532@rron.freenix.org> References: <20091122154228.GB55532@rron.freenix.org> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-fs@freebsd.org Subject: Re: 7.2 dies in zfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 19:47:07 -0000 > I've given up on ZFS on i386. Whatever tuning you could do is only > delaying the inevitable. Even with lots of RAM, it will panic. I'd > love being proven wrong as I also hav a 4 GB i386 with ZFS and it > panics regularely. i am not sure one can not tune it to stay up. it's just not clear how. and that is the critical point. on a 4g i386 with moderate+ load, my current parms are vm.kmem_size=1500M vm.kmem_size_max=2G vfs.zfs.arc_min=120M vfs.zfs.arc_max=900M vfs.zfs.prefetch_disable=1 and it's up over two days, wooo wooo! i suspect that i will next lower arc max. randy From owner-freebsd-fs@FreeBSD.ORG Sun Nov 22 23:33:13 2009 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE3CA106566B; Sun, 22 Nov 2009 23:33:13 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A44738FC17; Sun, 22 Nov 2009 23:33:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nAMNXDh1037451; Sun, 22 Nov 2009 23:33:13 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nAMNXD4A037447; Sun, 22 Nov 2009 23:33:13 GMT (envelope-from linimon) Date: Sun, 22 Nov 2009 23:33:13 GMT Message-Id: <200911222333.nAMNXD4A037447@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-sparc64@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: sparc64/140797: [nfs] [panic] panic on 8.0-RC3/sparc64 as an NFS server X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 23:33:13 -0000 Old Synopsis: Panic on 8.0-RC3/sparc64 as an NFS server New Synopsis: [nfs] [panic] panic on 8.0-RC3/sparc64 as an NFS server Responsible-Changed-From-To: freebsd-sparc64->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Sun Nov 22 23:32:50 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=140797 From owner-freebsd-fs@FreeBSD.ORG Mon Nov 23 02:05:07 2009 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D62F41065676 for ; Mon, 23 Nov 2009 02:05:07 +0000 (UTC) (envelope-from lists@mschuette.name) Received: from mail.asta.uni-potsdam.de (mail.asta.uni-potsdam.de [IPv6:2001:638:807:3a:20d:56ff:fefd:1183]) by mx1.freebsd.org (Postfix) with ESMTP id C8EEB8FC0A for ; Mon, 23 Nov 2009 02:05:06 +0000 (UTC) Received: from localhost (mail.asta.uni-potsdam.de [141.89.58.198]) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id F14A910E742 for ; Mon, 23 Nov 2009 03:05:04 +0100 (CET) X-Virus-Scanned: on mail at asta.uni-potsdam.de Received: from mail.asta.uni-potsdam.de ([141.89.58.198]) by localhost (mail.asta.uni-potsdam.de [141.89.58.198]) (amavisd-new, port 10024) with ESMTP id Ri+pWqw8CIOy for ; Mon, 23 Nov 2009 03:04:36 +0100 (CET) Received: from dagny.mschuette.name (cl-485.dus-01.de.sixxs.net [IPv6:2a01:198:200:1e4::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Martin Schuette", Issuer "AStA-CA" (verified OK)) by mail.asta.uni-potsdam.de (Postfix) with ESMTPSA id 40C1010E5A5 for ; Mon, 23 Nov 2009 03:04:34 +0100 (CET) Message-ID: <4B09EDB2.7020002@mschuette.name> Date: Mon, 23 Nov 2009 03:04:34 +0100 From: =?UTF-8?B?TWFydGluIFNjaMO8dHRl?= User-Agent: Thunderbird 2.0.0.23 (X11/20090908) MIME-Version: 1.0 To: freebsd-fs@FreeBSD.org X-Enigmail-Version: 0.95.7 Content-Type: multipart/mixed; boundary="------------000506000805020303080601" Cc: Subject: [nullfs] [panic] null with unref'ed lowervp X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 02:05:08 -0000 This is a multi-part message in MIME format. --------------000506000805020303080601 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hello, my server recently had the kernel panic "null with unref'ed lowervp" in null_subr.c:null_checkvp(). I am not sure whether I should open a PR for it. The system is a SMP machine with SCSI RAID (asr), it runs several jails and uses multiple null mounts between partitions, because there is not enough disk space (~90% usage). uname -a: FreeBSD trinity.asta.uni-potsdam.de 7.2-RELEASE FreeBSD 7.2-RELEASE #3: Tue May 12 18:53:06 CEST 2009 root@trinity.asta.uni-potsdam.de:/usr/obj/usr/src/sys/ASTA i386 Kernel is compiled with: options INVARIANT_SUPPORT options INVARIANTS options DIAGNOSTIC Among the few occurances I was not able to observe a pattern or reproduce the error (two crashes happened at 8am which is a cronjob time, but not one with particulary high load). I am also going to add new disks any time now in order to reduce the number of null mounts, so I do not expect to see this error again. I append three gdb backtraces, in case anyone finds them useful. -- Martin Schütte --------------000506000805020303080601 Content-Type: text/plain; name="backtrace2.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="backtrace2.txt" W3Jvb3RAdHJpbml0eV0gL3Vzci9vYmovdXNyL3NyYy9zeXMvQVNUQSMgY2F0IC9hcmNoaXYv Y3Jhc2gvaW5mby4yICYmIGtnZGIga2VybmVsLmRlYnVnIC9hcmNoaXYvY3Jhc2gvdm1jb3Jl LjIKRHVtcCBoZWFkZXIgZnJvbSBkZXZpY2UgL2Rldi9kYTBzMWIKICBBcmNoaXRlY3R1cmU6 IGkzODYKICBBcmNoaXRlY3R1cmUgVmVyc2lvbjogMgogIER1bXAgTGVuZ3RoOiAzNTQxODkz MTJCICgzMzcgTUIpCiAgQmxvY2tzaXplOiA1MTIKICBEdW1wdGltZTogRnJpIE9jdCAxNiAw ODowMDowNSAyMDA5CiAgSG9zdG5hbWU6IHRyaW5pdHkuYXN0YS51bmktcG90c2RhbS5kZQog IE1hZ2ljOiBGcmVlQlNEIEtlcm5lbCBEdW1wCiAgVmVyc2lvbiBTdHJpbmc6IEZyZWVCU0Qg Ny4yLVJFTEVBU0UgIzM6IFR1ZSBNYXkgMTIgMTg6NTM6MDYgQ0VTVCAyMDA5CiAgICByb290 QHRyaW5pdHkuYXN0YS51bmktcG90c2RhbS5kZTovdXNyL29iai91c3Ivc3JjL3N5cy9BU1RB CiAgUGFuaWMgU3RyaW5nOiBudWxsIHdpdGggdW5yZWYnZWQgbG93ZXJ2cAogIER1bXAgUGFy aXR5OiAzODcwMDAzNzIzCiAgQm91bmRzOiAyCiAgRHVtcCBTdGF0dXM6IGdvb2QKR05VIGdk YiA2LjEuMSBbRnJlZUJTRF0KQ29weXJpZ2h0IDIwMDQgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0 aW9uLCBJbmMuCkdEQiBpcyBmcmVlIHNvZnR3YXJlLCBjb3ZlcmVkIGJ5IHRoZSBHTlUgR2Vu ZXJhbCBQdWJsaWMgTGljZW5zZSwgYW5kIHlvdSBhcmUKd2VsY29tZSB0byBjaGFuZ2UgaXQg YW5kL29yIGRpc3RyaWJ1dGUgY29waWVzIG9mIGl0IHVuZGVyIGNlcnRhaW4gY29uZGl0aW9u cy4KVHlwZSAic2hvdyBjb3B5aW5nIiB0byBzZWUgdGhlIGNvbmRpdGlvbnMuClRoZXJlIGlz IGFic29sdXRlbHkgbm8gd2FycmFudHkgZm9yIEdEQi4gIFR5cGUgInNob3cgd2FycmFudHki IGZvciBkZXRhaWxzLgpUaGlzIEdEQiB3YXMgY29uZmlndXJlZCBhcyAiaTM4Ni1tYXJjZWwt ZnJlZWJzZCIuLi4KClVucmVhZCBwb3J0aW9uIG9mIHRoZSBrZXJuZWwgbWVzc2FnZSBidWZm ZXI6CnZwID0gMHhjYWJkMDAwMCwgdW5yZWYnZWQgbG93ZXJ2cAogZGVhZGMwZGUgZGVhZGMw ZGUgZGVhZGMwZGUgYzcwZmIyYTAgZGVhZGMwZGUgZGVhZGMwZGUgZGVhZGMwZGUgYzcwZmIy YTAKcGFuaWM6IG51bGwgd2l0aCB1bnJlZidlZCBsb3dlcnZwCmNwdWlkID0gMgpVcHRpbWU6 IDMxZDRoMjhtNDVzClBoeXNpY2FsIG1lbW9yeTogMzQ0NyBNQgpEdW1waW5nIDMzNyBNQjog MzIyIDMwNiAyOTAgMjc0IDI1OCAyNDIgMjI2IDIxMCAxOTQgMTc4IDE2MiAxNDYgMTMwIDEx NCA5OCA4MiA2NiA1MCAzNCAxOCAyCgpSZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJu ZWwvYWNjZl9odHRwLmtvLi4uUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL2Fj Y2ZfaHR0cC5rby5zeW1ib2xzLi4uZG9uZS4KZG9uZS4KTG9hZGVkIHN5bWJvbHMgZm9yIC9i b290L2tlcm5lbC9hY2NmX2h0dHAua28KUmVhZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2Vy bmVsL2FjcGkua28uLi5SZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvYWNwaS5r by5zeW1ib2xzLi4uZG9uZS4KZG9uZS4KTG9hZGVkIHN5bWJvbHMgZm9yIC9ib290L2tlcm5l bC9hY3BpLmtvClJlYWRpbmcgc3ltYm9scyBmcm9tIC9ib290L2tlcm5lbC9udWxsZnMua28u Li5SZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvbnVsbGZzLmtvLnN5bWJvbHMu Li5kb25lLgpkb25lLgpMb2FkZWQgc3ltYm9scyBmb3IgL2Jvb3Qva2VybmVsL251bGxmcy5r bwojMCAgZG9hZHVtcCAoKSBhdCBwY3B1Lmg6MTk2CjE5NiAgICAgICAgICAgICBfX2FzbSBf X3ZvbGF0aWxlKCJtb3ZsICUlZnM6MCwlMCIgOiAiPXIiICh0ZCkpOwooa2dkYikgYnQKIzAg IGRvYWR1bXAgKCkgYXQgcGNwdS5oOjE5NgojMSAgMHhjMDU3YmEwYyBpbiBib290IChob3d0 bz0yNjApIGF0IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fc2h1dGRvd24uYzo0MTgKIzIgIDB4 YzA1N2JjYWMgaW4gcGFuaWMgKGZtdD1WYXJpYWJsZSAiZm10IiBpcyBub3QgYXZhaWxhYmxl LgopIGF0IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fc2h1dGRvd24uYzo1NzQKIzMgIDB4Yzcw Zjg2ZjMgaW4gbnVsbF9jaGVja3ZwICh2cD1WYXJpYWJsZSAidnAiIGlzIG5vdCBhdmFpbGFi bGUuCikgYXQgL3Vzci9zcmMvc3lzL21vZHVsZXMvbnVsbGZzLy4uLy4uL2ZzL251bGxmcy9u dWxsX3N1YnIuYzozMzcKIzQgIDB4YzcwZjk1NTcgaW4gbnVsbF9sb2NrIChhcD0weGViMTJj OTk0KSBhdCAvdXNyL3NyYy9zeXMvbW9kdWxlcy9udWxsZnMvLi4vLi4vZnMvbnVsbGZzL251 bGxfdm5vcHMuYzo1MzEKIzUgIDB4YzA3ZDBhMzUgaW4gVk9QX0xPQ0sxX0FQViAodm9wPTB4 YzcwZmI0YzAsIGE9MHhlYjEyYzk5NCkgYXQgdm5vZGVfaWYuYzoxNjE4CiM2ICAweGMwNjA1 YmRlIGluIF92bl9sb2NrICh2cD0weGNhYmQwMDAwLCBmbGFncz04MTk0LCB0ZD0weGM2ZjUy ZDIwLCBmaWxlPTB4YzA4MGI4OTMgIi91c3Ivc3JjL3N5cy9rZXJuL3Zmc19zdWJyLmMiLCBs aW5lPTIxNTkpCiAgICBhdCB2bm9kZV9pZi5oOjg1MQojNyAgMHhjMDVmYTBlZSBpbiB2cmVs ZSAodnA9MHhjYWJkMDAwMCkgYXQgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX3N1YnIuYzoyMTU5 CiM4ICAweGMwNWYwNWZlIGluIG5hbWVpIChuZHA9MHhlYjEyY2I3YykgYXQgL3Vzci9zcmMv c3lzL2tlcm4vdmZzX2xvb2t1cC5jOjIwMgojOSAgMHhjMDYwNTU3MiBpbiB2bl9vcGVuX2Ny ZWQgKG5kcD0weGViMTJjYjdjLCBmbGFncD0weGViMTJjYzc4LCBjbW9kZT0wLCBjcmVkPTB4 YzcxN2Y2MDAsIGZwPTB4YzcwNzQ0YzApCiAgICBhdCAvdXNyL3NyYy9zeXMva2Vybi92ZnNf dm5vcHMuYzoxODgKIzEwIDB4YzA2MDU3ZjMgaW4gdm5fb3BlbiAobmRwPTB4ZWIxMmNiN2Ms IGZsYWdwPTB4ZWIxMmNjNzgsIGNtb2RlPTAsIGZwPTB4YzcwNzQ0YzApIGF0IC91c3Ivc3Jj L3N5cy9rZXJuL3Zmc192bm9wcy5jOjk0CiMxMSAweGMwNjA0NmIzIGluIGtlcm5fb3BlbiAo dGQ9MHhjNmY1MmQyMCwgcGF0aD0weGJmYmZhNzUwIDxBZGRyZXNzIDB4YmZiZmE3NTAgb3V0 IG9mIGJvdW5kcz4sIHBhdGhzZWc9VUlPX1VTRVJTUEFDRSwgZmxhZ3M9MywKICAgIG1vZGU9 MCkgYXQgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX3N5c2NhbGxzLmM6MTA0MgojMTIgMHhjMDYw NGJhMCBpbiBvcGVuICh0ZD0weGM2ZjUyZDIwLCB1YXA9MHhlYjEyY2NmYykgYXQgL3Vzci9z cmMvc3lzL2tlcm4vdmZzX3N5c2NhbGxzLmM6MTAwOQojMTMgMHhjMDdiYTcwMyBpbiBzeXNj YWxsIChmcmFtZT0weGViMTJjZDM4KSBhdCAvdXNyL3NyYy9zeXMvaTM4Ni9pMzg2L3RyYXAu YzoxMDkwCiMxNCAweGMwNzlmZDgwIGluIFhpbnQweDgwX3N5c2NhbGwgKCkgYXQgL3Vzci9z cmMvc3lzL2kzODYvaTM4Ni9leGNlcHRpb24uczoyNTUKIzE1IDB4MDAwMDAwMzMgaW4gPz8g KCkKUHJldmlvdXMgZnJhbWUgaW5uZXIgdG8gdGhpcyBmcmFtZSAoY29ycnVwdCBzdGFjaz8p Cg== --------------000506000805020303080601 Content-Type: text/plain; name="backtrace3.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="backtrace3.txt" PSBpbmZvID0KRHVtcCBoZWFkZXIgZnJvbSBkZXZpY2UgL2Rldi9kYTBzMWIKICBBcmNoaXRl Y3R1cmU6IGkzODYKICBBcmNoaXRlY3R1cmUgVmVyc2lvbjogMgogIER1bXAgTGVuZ3RoOiAz NjIxNDM3NDRCICgzNDUgTUIpCiAgQmxvY2tzaXplOiA1MTIKICBEdW1wdGltZTogU3VuIE9j dCAyNSAwODowMDoxNiAyMDA5CiAgSG9zdG5hbWU6IHRyaW5pdHkuYXN0YS51bmktcG90c2Rh bS5kZQogIE1hZ2ljOiBGcmVlQlNEIEtlcm5lbCBEdW1wCiAgVmVyc2lvbiBTdHJpbmc6IEZy ZWVCU0QgNy4yLVJFTEVBU0UgIzM6IFR1ZSBNYXkgMTIgMTg6NTM6MDYgQ0VTVCAyMDA5CiAg ICByb290QHRyaW5pdHkuYXN0YS51bmktcG90c2RhbS5kZTovdXNyL29iai91c3Ivc3JjL3N5 cy9BU1RBCiAgUGFuaWMgU3RyaW5nOiBudWxsIHdpdGggdW5yZWYnZWQgbG93ZXJ2cAogIER1 bXAgUGFyaXR5OiAyMjAxNDI3OTc5CiAgQm91bmRzOiAzCiAgRHVtcCBTdGF0dXM6IGdvb2QK Cj0ga2dkYiA9ClVucmVhZCBwb3J0aW9uIG9mIHRoZSBrZXJuZWwgbWVzc2FnZSBidWZmZXI6 CnZwID0gMHhjN2YxNzAwMCwgdW5yZWYnZWQgbG93ZXJ2cAogZGVhZGMwZGUgZGVhZGMwZGUg ZGVhZGMwZGUgYzcwZTYyYTAgMWZmZmZmIDAgMCAwCnBhbmljOiBudWxsIHdpdGggdW5yZWYn ZWQgbG93ZXJ2cApjcHVpZCA9IDEKVXB0aW1lOiA5ZDBoNThtMTNzClBoeXNpY2FsIG1lbW9y eTogMzQ0NyBNQgpEdW1waW5nIDM0NSBNQjogMzMwIDMxNCAyOTggMjgyIDI2NiAyNTAgMjM0 IDIxOCAyMDIgMTg2IDE3MCAxNTQgMTM4IDEyMiAxMDYgOTAgNzQgNTggNDIgMjYgMTAKCihr Z2RiKSBidAojMCAgZG9hZHVtcCAoKSBhdCBwY3B1Lmg6MTk2CiMxICAweGMwNTdiYTBjIGlu IGJvb3QgKGhvd3RvPTI2MCkgYXQgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9zaHV0ZG93bi5j OjQxOAojMiAgMHhjMDU3YmNhYyBpbiBwYW5pYyAoZm10PVZhcmlhYmxlICJmbXQiIGlzIG5v dCBhdmFpbGFibGUuCikgYXQgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9zaHV0ZG93bi5jOjU3 NAojMyAgMHhjNzBlMzZmMyBpbiBudWxsX2NoZWNrdnAgKHZwPVZhcmlhYmxlICJ2cCIgaXMg bm90IGF2YWlsYWJsZS4KKSBhdCAvdXNyL3NyYy9zeXMvbW9kdWxlcy9udWxsZnMvLi4vLi4v ZnMvbnVsbGZzL251bGxfc3Vici5jOjMzNwojNCAgMHhjNzBlNDU1NyBpbiBudWxsX2xvY2sg KGFwPTB4ZWJjMGZiMjApIGF0IC91c3Ivc3JjL3N5cy9tb2R1bGVzL251bGxmcy8uLi8uLi9m cy9udWxsZnMvbnVsbF92bm9wcy5jOjUzMQojNSAgMHhjMDdkMGEzNSBpbiBWT1BfTE9DSzFf QVBWICh2b3A9MHhjNzBlNjRjMCwgYT0weGViYzBmYjIwKSBhdCB2bm9kZV9pZi5jOjE2MTgK IzYgIDB4YzA2MDViZGUgaW4gX3ZuX2xvY2sgKHZwPTB4YzdmMTcwMDAsIGZsYWdzPTgxOTQs IHRkPTB4Y2E1ZmZhZjAsIGZpbGU9MHhjMDgwYjg5MyAiL3Vzci9zcmMvc3lzL2tlcm4vdmZz X3N1YnIuYyIsIGxpbmU9MjE1OSkKICAgIGF0IHZub2RlX2lmLmg6ODUxCiM3ICAweGMwNWZh MGVlIGluIHZyZWxlICh2cD0weGM3ZjE3MDAwKSBhdCAvdXNyL3NyYy9zeXMva2Vybi92ZnNf c3Vici5jOjIxNTkKIzggIDB4YzA2MDA0Y2EgaW4ga2Vybl9yZW5hbWUgKHRkPTB4Y2E1ZmZh ZjAsIGZyb209MHgyODcwMTliMCA8QWRkcmVzcyAweDI4NzAxOWIwIG91dCBvZiBib3VuZHM+ LAogICAgdG89MHgyODcwMWEyMCA8QWRkcmVzcyAweDI4NzAxYTIwIG91dCBvZiBib3VuZHM+ LCBwYXRoc2VnPVVJT19VU0VSU1BBQ0UpIGF0IC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19zeXNj YWxscy5jOjM0MjgKIzkgIDB4YzA2MDA1ODkgaW4gcmVuYW1lICh0ZD0weGNhNWZmYWYwLCB1 YXA9MHhlYmMwZmNmYykgYXQgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX3N5c2NhbGxzLmM6MzMx OQojMTAgMHhjMDdiYTcwMyBpbiBzeXNjYWxsIChmcmFtZT0weGViYzBmZDM4KSBhdCAvdXNy L3NyYy9zeXMvaTM4Ni9pMzg2L3RyYXAuYzoxMDkwCiMxMSAweGMwNzlmZDgwIGluIFhpbnQw eDgwX3N5c2NhbGwgKCkgYXQgL3Vzci9zcmMvc3lzL2kzODYvaTM4Ni9leGNlcHRpb24uczoy NTUKIzEyIDB4MDAwMDAwMzMgaW4gPz8gKCkKUHJldmlvdXMgZnJhbWUgaW5uZXIgdG8gdGhp cyBmcmFtZSAoY29ycnVwdCBzdGFjaz8pCgo= --------------000506000805020303080601 Content-Type: text/plain; name="backtrace4.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="backtrace4.txt" PSBpbmZvID0KRHVtcCBoZWFkZXIgZnJvbSBkZXZpY2UgL2Rldi9kYTBzMWIKICBBcmNoaXRl Y3R1cmU6IGkzODYKICBBcmNoaXRlY3R1cmUgVmVyc2lvbjogMgogIER1bXAgTGVuZ3RoOiAz NjU1MTQ3NTJCICgzNDggTUIpCiAgQmxvY2tzaXplOiA1MTIKICBEdW1wdGltZTogVHVlIE5v diAxNyAyMjo0ODoxMiAyMDA5CiAgSG9zdG5hbWU6IHRyaW5pdHkuYXN0YS51bmktcG90c2Rh bS5kZQogIE1hZ2ljOiBGcmVlQlNEIEtlcm5lbCBEdW1wCiAgVmVyc2lvbiBTdHJpbmc6IEZy ZWVCU0QgNy4yLVJFTEVBU0UgIzM6IFR1ZSBNYXkgMTIgMTg6NTM6MDYgQ0VTVCAyMDA5CiAg ICByb290QHRyaW5pdHkuYXN0YS51bmktcG90c2RhbS5kZTovdXNyL29iai91c3Ivc3JjL3N5 cy9BU1RBCiAgUGFuaWMgU3RyaW5nOiBudWxsIHdpdGggdW5yZWYnZWQgbG93ZXJ2cAogIER1 bXAgUGFyaXR5OiA1MjcwODA0NTgKICBCb3VuZHM6IDQKICBEdW1wIFN0YXR1czogZ29vZAoK PSBrZ2RiID0KVW5yZWFkIHBvcnRpb24gb2YgdGhlIGtlcm5lbCBtZXNzYWdlIGJ1ZmZlcjoK dnAgPSAweGM4ZTYwMjI4LCB1bnJlZidlZCBsb3dlcnZwCiBkZWFkYzBkZSBkZWFkYzBkZSBk ZWFkYzBkZSBjNzEzYjJhMCBkZWFkYzBkZSBkZWFkYzBkZSBkZWFkYzBkZSBjMDg0ZTFhMApw YW5pYzogbnVsbCB3aXRoIHVucmVmJ2VkIGxvd2VydnAKY3B1aWQgPSAwClVwdGltZTogMjNk MTRoNDVtNThzClBoeXNpY2FsIG1lbW9yeTogMzQ0NyBNQgpEdW1waW5nIDM0OCBNQjogMzMz IDMxNyAzMDEgMjg1IDI2OSAyNTMgMjM3IDIyMSAyMDUgMTg5IDE3MyAxNTcgMTQxIDEyNSAx MDkgOTMgNzcgNjEgNDUgMjkgMTMKCihrZ2RiKSBidAojMCAgZG9hZHVtcCAoKSBhdCBwY3B1 Lmg6MTk2CiMxICAweGMwNTdiYTBjIGluIGJvb3QgKGhvd3RvPTI2MCkgYXQgL3Vzci9zcmMv c3lzL2tlcm4va2Vybl9zaHV0ZG93bi5jOjQxOAojMiAgMHhjMDU3YmNhYyBpbiBwYW5pYyAo Zm10PVZhcmlhYmxlICJmbXQiIGlzIG5vdCBhdmFpbGFibGUuCikgYXQgL3Vzci9zcmMvc3lz L2tlcm4va2Vybl9zaHV0ZG93bi5jOjU3NAojMyAgMHhjNzEzODZmMyBpbiBudWxsX2NoZWNr dnAgKHZwPVZhcmlhYmxlICJ2cCIgaXMgbm90IGF2YWlsYWJsZS4KKSBhdCAvdXNyL3NyYy9z eXMvbW9kdWxlcy9udWxsZnMvLi4vLi4vZnMvbnVsbGZzL251bGxfc3Vici5jOjMzNwojNCAg MHhjNzEzOTU1NyBpbiBudWxsX2xvY2sgKGFwPTB4ZWI1YWY5OTQpIGF0IC91c3Ivc3JjL3N5 cy9tb2R1bGVzL251bGxmcy8uLi8uLi9mcy9udWxsZnMvbnVsbF92bm9wcy5jOjUzMQojNSAg MHhjMDdkMGEzNSBpbiBWT1BfTE9DSzFfQVBWICh2b3A9MHhjNzEzYjRjMCwgYT0weGViNWFm OTk0KSBhdCB2bm9kZV9pZi5jOjE2MTgKIzYgIDB4YzA2MDViZGUgaW4gX3ZuX2xvY2sgKHZw PTB4YzhlNjAyMjgsIGZsYWdzPTgxOTQsIHRkPTB4YzhlODc0NjAsIGZpbGU9MHhjMDgwYjg5 MyAiL3Vzci9zcmMvc3lzL2tlcm4vdmZzX3N1YnIuYyIsIGxpbmU9MjE1OSkKICAgIGF0IHZu b2RlX2lmLmg6ODUxCiM3ICAweGMwNWZhMGVlIGluIHZyZWxlICh2cD0weGM4ZTYwMjI4KSBh dCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfc3Vici5jOjIxNTkKIzggIDB4YzA1ZjA1ZmUgaW4g bmFtZWkgKG5kcD0weGViNWFmYjdjKSBhdCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfbG9va3Vw LmM6MjAyCiM5ICAweGMwNjA1NTcyIGluIHZuX29wZW5fY3JlZCAobmRwPTB4ZWI1YWZiN2Ms IGZsYWdwPTB4ZWI1YWZjNzgsIGNtb2RlPTAsIGNyZWQ9MHhjNzZjMjEwMCwgZnA9MHhjZDI4 YTZkNCkKICAgIGF0IC91c3Ivc3JjL3N5cy9rZXJuL3Zmc192bm9wcy5jOjE4OAojMTAgMHhj MDYwNTdmMyBpbiB2bl9vcGVuIChuZHA9MHhlYjVhZmI3YywgZmxhZ3A9MHhlYjVhZmM3OCwg Y21vZGU9MCwgZnA9MHhjZDI4YTZkNCkgYXQgL3Vzci9zcmMvc3lzL2tlcm4vdmZzX3Zub3Bz LmM6OTQKIzExIDB4YzA2MDQ2YjMgaW4ga2Vybl9vcGVuICh0ZD0weGM4ZTg3NDYwLCBwYXRo PTB4YmZiZmE4ZjAgPEFkZHJlc3MgMHhiZmJmYThmMCBvdXQgb2YgYm91bmRzPiwgcGF0aHNl Zz1VSU9fVVNFUlNQQUNFLCBmbGFncz0zLAogICAgbW9kZT0wKSBhdCAvdXNyL3NyYy9zeXMv a2Vybi92ZnNfc3lzY2FsbHMuYzoxMDQyCiMxMiAweGMwNjA0YmEwIGluIG9wZW4gKHRkPTB4 YzhlODc0NjAsIHVhcD0weGViNWFmY2ZjKSBhdCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfc3lz Y2FsbHMuYzoxMDA5CiMxMyAweGMwN2JhNzAzIGluIHN5c2NhbGwgKGZyYW1lPTB4ZWI1YWZk MzgpIGF0IC91c3Ivc3JjL3N5cy9pMzg2L2kzODYvdHJhcC5jOjEwOTAKIzE0IDB4YzA3OWZk ODAgaW4gWGludDB4ODBfc3lzY2FsbCAoKSBhdCAvdXNyL3NyYy9zeXMvaTM4Ni9pMzg2L2V4 Y2VwdGlvbi5zOjI1NQojMTUgMHgwMDAwMDAzMyBpbiA/PyAoKQpQcmV2aW91cyBmcmFtZSBp bm5lciB0byB0aGlzIGZyYW1lIChjb3JydXB0IHN0YWNrPykK --------------000506000805020303080601-- From owner-freebsd-fs@FreeBSD.ORG Mon Nov 23 02:36:22 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 757E4106566B for ; Mon, 23 Nov 2009 02:36:22 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by mx1.freebsd.org (Postfix) with ESMTP id 249818FC1E for ; Mon, 23 Nov 2009 02:36:21 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 9so1128139qwb.7 for ; Sun, 22 Nov 2009 18:36:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:x-mailer :x-priority:message-id:to:cc:subject:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=UHa0QN2sNGmWS1sT/3Nd5uf4yybeSvv2+k9gocI4L08=; b=u/ZYeVBdOzOUYmb98Tg00E9Qhz/weu3M5rqDxNlvNRuq+/t6+JZUqsOZKeolD8W6l5 ZCwRDda4e22fxtPCHoc3BYb0OG8osMpbWFWarxWEfHcs2MBtmrjT5OjsxUEx+28iFmeD 51ZxJ9i60bKDrn0Dk+5Sr5fK68Y8TFEYK0sZ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:x-mailer:x-priority:message-id:to:cc:subject :in-reply-to:references:mime-version:content-type :content-transfer-encoding; b=P5dhus8xtcjDi4cXo5X10HGb2mSpZ8ClwxKCnpFtxVAKN+MuIADDWQJhRNAT6lQdzQ IxU3ow3lyipg8PdOCWlfApFb2YwlM37js5JZlyNbH87ZeD8s7o6tjtz+lvb14g9ea+s3 ot4w7AXCtx7qeRXkl77WgS+j5ap2c4zVogKRg= Received: by 10.224.36.161 with SMTP id t33mr2157260qad.346.1258943781477; Sun, 22 Nov 2009 18:36:21 -0800 (PST) Received: from blackcell.5p.local (ppp-21.118.dialinfree.com [209.172.21.118]) by mx.google.com with ESMTPS id 20sm1899735qyk.5.2009.11.22.18.36.17 (version=SSLv3 cipher=OTHER); Sun, 22 Nov 2009 18:36:19 -0800 (PST) Sender: "J. Hellenthal" Date: Sun, 22 Nov 2009 21:36:18 -0500 From: jhell X-Mailer: The Bat! (v4.0.24) Professional X-Priority: 3 (Normal) Message-ID: <917839072.20091122213618@DataIX.net> To: Randy Bush In-Reply-To: References: <20091122154228.GB55532@rron.freenix.org> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re[2]: 7.2 dies in zfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 02:36:22 -0000 =0D=0ASunday, November 22, 2009, 2:47:03 PM, Randy wrote: >> I've given up on ZFS on i386. Whatever tuning you could do is only >> delaying the inevitable. Even with lots of RAM, it will panic. I'd >> love being proven wrong as I also hav a 4 GB i386 with ZFS and it >> panics regularely. > i am not sure one can not tune it to stay up. it's just not clear how. > and that is the critical point. > on a 4g i386 with moderate+ load, my current parms are > vm.kmem_size=3D1500M > vm.kmem_size_max=3D2G > vfs.zfs.arc_min=3D120M > vfs.zfs.arc_max=3D900M > vfs.zfs.prefetch_disable=3D1 > and it's up over two days, wooo wooo! > i suspect that i will next lower arc max. 7.2-STABLE --- arc_min & arc_max AFAIR are auto tuned on boot by values that dont come to mind right now. Have you tried just leaving these for the system to tune.... On my i386 running 7.2-STABLE with 1G RAM 1800MHz with two 7200RPM drives I dual boot with Win7 & FreeBSD not that it makes a difference. My large drive carries FreeBSD, ZFS only with two slices of my second drive one for the ZFS cache and one for the ZIL. kmem_size is 512M and max is 768M & I dont disable the prefetch... Kernel config invludes KVA_PAGES=3D512 along with no other kernel tuning. Seems no matter what I do with this machine I can not get it to crash whatsoever. I have stress tested it with unixbench, iozone & dd(1). This machines uptime during long periods of not having to boot into (Windows for Work) purposes is around 13 days or so. ;-) I could not be more pleased other than I would like some faster write speeds when doing inbound xfers from a personal fileserver but this I just blame on lack of better hardware. Best of Luck. PS: If you go too low on arc_* you are going to inhibit your write speeds dramaticly while trying to save your memory for other purposes. --=20 Sunday, November 22, 2009 9:18:42 PM jhell From owner-freebsd-fs@FreeBSD.ORG Mon Nov 23 02:37:01 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A537510656C2 for ; Mon, 23 Nov 2009 02:37:01 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-qy0-f176.google.com (mail-qy0-f176.google.com [209.85.221.176]) by mx1.freebsd.org (Postfix) with ESMTP id 59CAF8FC0A for ; Mon, 23 Nov 2009 02:37:01 +0000 (UTC) Received: by qyk6 with SMTP id 6so2467389qyk.3 for ; Sun, 22 Nov 2009 18:37:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:x-mailer :x-priority:message-id:to:cc:subject:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=UHa0QN2sNGmWS1sT/3Nd5uf4yybeSvv2+k9gocI4L08=; b=RzOWLelgPUc2wBdLProMO3cbhHdj8czG9y0+a+NaAsJPUZ4LQUEu1Wo5HLudALP9Eh gbTCM/UqrzdLzY3KzycbJxKzEhfJHkO36SqFpZGkpoHreIm5XG7m5nxwM6t/4so9iGwL fRTYIg3UxQ7XFXQ/0mYYph2z1QPwjLQeZ8Rrs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:x-mailer:x-priority:message-id:to:cc:subject :in-reply-to:references:mime-version:content-type :content-transfer-encoding; b=qWTD7H/+B7ttd9uHzy/Z7LyPe0mhc9pKui/4awr+5kSfxHbZGJajM2eSahFzoTz5RD iXb6xi86NJrwKZAOHwMCgsTAbOWzg7ZkSdCEA9O6cFEs2Nb1o5LsFSDMKrLGLpLzU6wH uk7kiEXoSDc6RjTcQOhTavZ+PVWyXJ7+7+QRM= Received: by 10.224.35.130 with SMTP id p2mr2178034qad.114.1258943820606; Sun, 22 Nov 2009 18:37:00 -0800 (PST) Received: from blackcell.5p.local (ppp-21.118.dialinfree.com [209.172.21.118]) by mx.google.com with ESMTPS id 23sm1107776qyk.15.2009.11.22.18.36.55 (version=SSLv3 cipher=OTHER); Sun, 22 Nov 2009 18:36:59 -0800 (PST) Sender: "J. Hellenthal" Date: Sun, 22 Nov 2009 21:36:55 -0500 From: jhell X-Mailer: The Bat! (v4.0.24) Professional X-Priority: 3 (Normal) Message-ID: <1710337060.20091122213655@DataIX.net> To: Randy Bush In-Reply-To: References: <20091122154228.GB55532@rron.freenix.org> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re[2]: 7.2 dies in zfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 02:37:01 -0000 =0D=0ASunday, November 22, 2009, 2:47:03 PM, Randy wrote: >> I've given up on ZFS on i386. Whatever tuning you could do is only >> delaying the inevitable. Even with lots of RAM, it will panic. I'd >> love being proven wrong as I also hav a 4 GB i386 with ZFS and it >> panics regularely. > i am not sure one can not tune it to stay up. it's just not clear how. > and that is the critical point. > on a 4g i386 with moderate+ load, my current parms are > vm.kmem_size=3D1500M > vm.kmem_size_max=3D2G > vfs.zfs.arc_min=3D120M > vfs.zfs.arc_max=3D900M > vfs.zfs.prefetch_disable=3D1 > and it's up over two days, wooo wooo! > i suspect that i will next lower arc max. 7.2-STABLE --- arc_min & arc_max AFAIR are auto tuned on boot by values that dont come to mind right now. Have you tried just leaving these for the system to tune.... On my i386 running 7.2-STABLE with 1G RAM 1800MHz with two 7200RPM drives I dual boot with Win7 & FreeBSD not that it makes a difference. My large drive carries FreeBSD, ZFS only with two slices of my second drive one for the ZFS cache and one for the ZIL. kmem_size is 512M and max is 768M & I dont disable the prefetch... Kernel config invludes KVA_PAGES=3D512 along with no other kernel tuning. Seems no matter what I do with this machine I can not get it to crash whatsoever. I have stress tested it with unixbench, iozone & dd(1). This machines uptime during long periods of not having to boot into (Windows for Work) purposes is around 13 days or so. ;-) I could not be more pleased other than I would like some faster write speeds when doing inbound xfers from a personal fileserver but this I just blame on lack of better hardware. Best of Luck. PS: If you go too low on arc_* you are going to inhibit your write speeds dramaticly while trying to save your memory for other purposes. --=20 Sunday, November 22, 2009 9:18:42 PM jhell From owner-freebsd-fs@FreeBSD.ORG Mon Nov 23 09:57:33 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 053A31065670 for ; Mon, 23 Nov 2009 09:57:32 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.freenix.fr (keltia.freenix.org [IPv6:2001:660:330f:f820:213:72ff:fe15:f44]) by mx1.freebsd.org (Postfix) with ESMTP id 2FD758FC16 for ; Mon, 23 Nov 2009 09:57:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by keltia.freenix.fr (Postfix/TLS) with ESMTP id B205039C1A for ; Mon, 23 Nov 2009 10:57:30 +0100 (CET) X-Virus-Scanned: amavisd-new at keltia.freenix.fr Received: from keltia.freenix.fr ([127.0.0.1]) by localhost (keltia.freenix.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ONx4Af86pVi for ; Mon, 23 Nov 2009 10:57:30 +0100 (CET) Received: from roberto-al.eurocontrol.fr (aran.keltia.net [88.191.250.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.freenix.fr (Postfix/TLS) with ESMTPSA id 3A33139B11 for ; Mon, 23 Nov 2009 10:57:30 +0100 (CET) Date: Mon, 23 Nov 2009 10:56:45 +0100 From: Ollivier Robert To: freebsd-fs@freebsd.org Message-ID: <20091123095645.GA61769@roberto-al.eurocontrol.fr> References: <20091122154228.GB55532@rron.freenix.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-Operating-System: MacOS X / Macbook Pro - FreeBSD 7.2 / Dell D820 SMP User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: 7.2 dies in zfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 09:57:33 -0000 According to Randy Bush: >i suspect that i will next lower arc max. The machine generally survives a buildworld and will panic later on a simple "svn update". There is not real pattern... -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ From owner-freebsd-fs@FreeBSD.ORG Mon Nov 23 11:06:53 2009 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7782E10656A6 for ; Mon, 23 Nov 2009 11:06:53 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 426FF8FC20 for ; Mon, 23 Nov 2009 11:06:53 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nANB6rsT070111 for ; Mon, 23 Nov 2009 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nANB6qIn070109 for freebsd-fs@FreeBSD.org; Mon, 23 Nov 2009 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 23 Nov 2009 11:06:52 GMT Message-Id: <200911231106.nANB6qIn070109@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-fs@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 11:06:53 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o sparc/140797 fs [nfs] [panic] panic on 8.0-RC3/sparc64 as an NFS serve o kern/140682 fs [netgraph] [panic] random panic in netgraph o kern/140661 fs [zfs] /boot/loader fails to work on a GPT/ZFS-only sys o kern/140640 fs [zfs] snapshot crash o kern/140433 fs [zfs] [panic] panic while replaying ZIL after crash o kern/140134 fs [msdosfs] write and fsck destroy filesystem integrity o kern/140068 fs [smbfs] [patch] smbfs does not allow semicolon in file o kern/139725 fs [zfs] zdb(1) dumps core on i386 when examining zpool c o kern/139715 fs [zfs] vfs.numvnodes leak on busy zfs o bin/139651 fs [nfs] mount(8): read-only remount of NFS volume does n o kern/139597 fs [patch] [tmpfs] tmpfs initializes va_gen but doesn't u o kern/139564 fs [zfs] [panic] 8.0-RC1 - Fatal trap 12 at end of shutdo o kern/139407 fs [smbfs] [panic] smb mount causes system crash if remot o kern/139363 fs [nfs] diskless root nfs mount from non FreeBSD server o kern/138790 fs [zfs] ZFS ceases caching when mem demand is high o kern/138524 fs [msdosfs] disks and usb flashes/cards with Russian lab o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138367 fs [tmpfs] [panic] 'panic: Assertion pages > 0 failed' wh o kern/138202 fs mount_msdosfs(1) see only 2Gb o kern/138109 fs [extfs] [patch] Minor cleanups to the sys/gnu/fs/ext2f f kern/137037 fs [zfs] [hang] zfs rollback on root causes FreeBSD to fr o kern/136968 fs [ufs] [lor] ufs/bufwait/ufs (open) o kern/136945 fs [ufs] [lor] filedesc structure/ufs (poll) o kern/136944 fs [ffs] [lor] bufwait/snaplk (fsync) o kern/136873 fs [ntfs] Missing directories/files on NTFS volume o kern/136865 fs [nfs] [patch] NFS exports atomic and on-the-fly atomic o kern/136470 fs [nfs] Cannot mount / in read-only, over NFS o kern/135594 fs [zfs] Single dataset unresponsive with Samba o kern/135546 fs [zfs] zfs.ko module doesn't ignore zpool.cache filenam o kern/135469 fs [ufs] [panic] kernel crash on md operation in ufs_dirb o kern/135050 fs [zfs] ZFS clears/hides disk errors on reboot o kern/134491 fs [zfs] Hot spares are rather cold... o kern/133980 fs [panic] [ffs] panic: ffs_valloc: dup alloc o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis o kern/133614 fs [panic] panic: ffs_truncate: read-only filesystem o kern/133174 fs [msdosfs] [patch] msdosfs must support utf-encoded int f kern/133150 fs [zfs] Page fault with ZFS on 7.1-RELEASE/amd64 while w o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132597 fs [tmpfs] [panic] tmpfs-related panic while interrupting o kern/132397 fs reboot causes filesystem corruption (failure to sync b o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132237 fs [msdosfs] msdosfs has problems to read MSDOS Floppy o kern/132145 fs [panic] File System Hard Crashes o kern/131995 fs [nfs] Failure to mount NFSv4 server o kern/131441 fs [unionfs] [nullfs] unionfs and/or nullfs not combineab o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131342 fs [nfs] mounting/unmounting of disks causes NFS to fail o bin/131341 fs makefs: error "Bad file descriptor" on the mount poin o kern/130979 fs [smbfs] [panic] boot/kernel/smbfs.ko o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130229 fs [iconv] usermount fails on fs that need iconv o kern/130210 fs [nullfs] Error by check nullfs o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129488 fs [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) o kern/129059 fs [zfs] [patch] ZFS bootloader whitelistable via WITHOUT f kern/128829 fs smbd(8) causes periodic panic on 7-RELEASE o kern/127659 fs [tmpfs] tmpfs memory leak o kern/127420 fs [gjournal] [panic] Journal overflow on gmirrored gjour o kern/127029 fs [panic] mount(8): trying to mount a write protected zi o kern/126287 fs [ufs] [panic] Kernel panics while mounting an UFS file s kern/125738 fs [zfs] [request] SHA256 acceleration in ZFS p kern/124621 fs [ext3] [patch] Cannot mount ext2fs partition f bin/124424 fs [zfs] zfs(8): zfs list -r shows strange snapshots' siz o kern/123939 fs [msdosfs] corrupts new files o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121898 fs [nullfs] pwd(1)/getcwd(2) fails with Permission denied o bin/121779 fs [ufs] snapinfo(8) (and related tools?) only work for t o bin/121366 fs [zfs] [patch] Automatic disk scrubbing from periodic(8 o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha f kern/120991 fs [panic] [fs] [snapshot] System crashes when manipulati o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F f kern/119735 fs [zfs] geli + ZFS + samba starting on boot panics 7.0-B o kern/118912 fs [2tb] disk sizing/geometry problem with large array o kern/118713 fs [minidump] [patch] Display media size required for a k o bin/118249 fs mv(1): moving a directory changes its mtime o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N o bin/117315 fs [smbfs] mount_smbfs(8) and related options can't mount o kern/117314 fs [ntfs] Long-filename only NTFS fs'es cause kernel pani o kern/117158 fs [zfs] zpool scrub causes panic if geli vdevs detach on o bin/116980 fs [msdosfs] [patch] mount_msdosfs(8) resets some flags f o kern/116913 fs [ffs] [panic] ffs_blkfree: freeing free block p kern/116608 fs [msdosfs] [patch] msdosfs fails to check mount options o kern/116583 fs [ffs] [hang] System freezes for short time when using o kern/116170 fs [panic] Kernel panic when mounting /tmp o kern/115645 fs [snapshots] [panic] lockmgr: thread 0xc4c00d80, not ex o bin/115361 fs [zfs] mount(8) gets into a state where it won't set/un o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/113852 fs [smbfs] smbfs does not properly implement DFS referral o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/111843 fs [msdosfs] Long Names of files are incorrectly created o kern/111782 fs [ufs] dump(8) fails horribly for large filesystems s bin/111146 fs [2tb] fsck(8) fails on 6T filesystem o kern/109024 fs [msdosfs] mount_msdosfs: msdosfs_iconv: Operation not o kern/109010 fs [msdosfs] can't mv directory within fat32 file system o bin/107829 fs [2TB] fdisk(8): invalid boundary checking in fdisk / w o kern/106030 fs [ufs] [panic] panic in ufs from geom when a dead disk o kern/104406 fs [ufs] Processes get stuck in "ufs" state under persist o kern/104133 fs [ext2fs] EXT2FS module corrupts EXT2/3 filesystems o kern/103035 fs [ntfs] Directories in NTFS mounted disc images appear o kern/101324 fs [smbfs] smbfs sometimes not case sensitive when it's s o kern/99290 fs [ntfs] mount_ntfs ignorant of cluster sizes o kern/97377 fs [ntfs] [patch] syntax cleanup for ntfs_ihash.c o kern/95222 fs [iso9660] File sections on ISO9660 level 3 CDs ignored o kern/94849 fs [ufs] rename on UFS filesystem is not atomic o kern/94769 fs [ufs] Multiple file deletions on multi-snapshotted fil o kern/94733 fs [smbfs] smbfs may cause double unlock o kern/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/92272 fs [ffs] [hang] Filling a filesystem while creating a sna f kern/91568 fs [ufs] [panic] writing to UFS/softupdates DVD media in o kern/91134 fs [smbfs] [patch] Preserve access and modification time a kern/90815 fs [smbfs] [patch] SMBFS with character conversions somet o kern/88657 fs [smbfs] windows client hang when browsing a samba shar o kern/88266 fs [smbfs] smbfs does not implement UIO_NOCOPY and sendfi o kern/87859 fs [smbfs] System reboot while umount smbfs. o kern/86587 fs [msdosfs] rm -r /PATH fails with lots of small files o kern/85326 fs [smbfs] [panic] saving a file via samba to an overquot o kern/84589 fs [2TB] 5.4-STABLE unresponsive during background fsck 2 o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi o kern/73484 fs [ntfs] Kernel panic when doing `ls` from the client si o bin/73019 fs [ufs] fsck_ufs(8) cannot alloc 607016868 bytes for ino o kern/71774 fs [ntfs] NTFS cannot "see" files on a WinXP filesystem o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po o kern/65920 fs [nwfs] Mounted Netware filesystem behaves strange o kern/65901 fs [smbfs] [patch] smbfs fails fsx write/truncate-down/tr o kern/61503 fs [smbfs] mount_smbfs does not work as non-root o kern/55617 fs [smbfs] Accessing an nsmb-mounted drive via a smb expo o kern/51685 fs [hang] Unbounded inode allocation causes kernel to loc o kern/51583 fs [nullfs] [patch] allow to work with devices and socket o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o kern/18874 fs [2TB] 32bit NFS servers export wrong negative values t 139 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Nov 23 15:40:56 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A9711065692 for ; Mon, 23 Nov 2009 15:40:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1C98A8FC12 for ; Mon, 23 Nov 2009 15:40:56 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id C182B46B2C; Mon, 23 Nov 2009 10:40:55 -0500 (EST) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 190F18A01B; Mon, 23 Nov 2009 10:40:55 -0500 (EST) From: John Baldwin To: freebsd-fs@freebsd.org Date: Mon, 23 Nov 2009 10:18:40 -0500 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911231018.40815.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 23 Nov 2009 10:40:55 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Subject: Re: Current gptzfsboot limitations X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 15:40:56 -0000 On Friday 20 November 2009 7:46:54 pm Matt Reimer wrote: > I've been analyzing gptzfsboot to see what its limitations are. I > think it should now work fine for a healthy pool with any number of > disks, with any type of vdev, whether single disk, stripe, mirror, > raidz or raidz2. > > But there are currently several limitations (likely in loader.zfs > too), mostly due to the limited amount of memory available (< 640KB) > and the simple memory allocators used (a simple malloc() and > zfs_alloc_temp()). > > 1. gptzfsboot might fail to read compressed files on raidz/raidz2 > pools. The reason is that the temporary buffer used for I/O > (zfs_temp_buf in zfsimpl.c) is 128KB by default, but a 128KB > compressed block will require a 128KB buffer to be allocated before > the I/O is done, leaving nothing for the raidz code further on. The > fix would be to make more the temporary buffer larger, but for some > reason it's not as simple as just changing the TEMP_SIZE define > (possibly a stack overflow results; more debugging needed). > Workaround: don't enable compression on your root filesystem (aka > bootfs). > > 2. gptzfsboot might fail to reconstruct a file that is read from a > degraded raidz/raidz2 pool, or if the file is corrupt somehow (i.e. > the pool is healthy but the checksums don't match). The reason again > is that the temporary buffer gets exhausted. I think this will only > happen in the case where more than one physical block is corrupt or > unreadable. The fix has several aspects: 1) make the temporary buffer > much larger, perhaps larger than 640KB; 2) change > zfssubr.c:vdev_raidz_read() to reuse the temp buffers it allocates > when possible; and 3) either restructure > zfssubr.c:vdev_raidz_reconstruct_pq() to only allocate its temporary > buffers once per I/O, or use a malloc that has free() implemented. > Workaround: repair your pool somehow (e.g. pxeboot) so one or no disks > are bad. > > 3. gptzfsboot might fail to boot from a degraded pool that has one or > more drives marked offline, removed, or faulted. The reason is that > vdev_probe() assumes that all vdevs are healthy, regardless of their > true state. gptzfsboot then will read from an offline/removed/faulted > vdev as if it were healthy, likely resulting in failed checksums, > resulting in the recovery code path being run in vdev_raidz_read(), > possibly leading to zfs_temp_buf exhaustion as in #2 above. > > A partial patch for #3 is attached, but it is inadequate because it > only reads a vdev's status from the first device's (in BIOS order) > vdev_label, with the result that if the first device is marked > offline, gptzfsboot won't see this because only the other devices' > vdev_labels will indicate that the first device is offline. (Since > after a device is offlined no further writes will be made to the > device, its vdev_label is not updated to reflect that it's offline.) > To complete the patch it would be necessary to set each leaf vdev's > status from the newest vdev_label rather than from the first > vdev_label seen. > > I think I've also hit a stack overflow a couple of times while debugging. > > I don't know enough about the gptzfsboot/loader.zfs environment to > know whether the heap size could be easily enlarged, or whether there > is room for a real malloc() with free(). loader(8) seems to use the > malloc() in libstand. Can anyone shed some light on the memory > limitations and possible solutions? > > I won't be able to spend much more time on this, but I wanted to pass > on what I've learned in case someone else has the time and boot fu to > take it the next step. One issue is that disk transfers need to happen in the lower 1MB due to BIOS limitations. The loader uses a bounce buffer (in biosdisk.c in libi386) to make this work ok. The loader uses memory > 1MB for malloc(). You could probably change zfsboot to do that as well if not already. Just note that drvread() has to bounce buffer requests in that case. The text + data + bss + stack is all in the lower 640k and there's not much you can do about that. The stack grows down from 640k, and the boot program text + data starts at 64k with the bss following. Hmm, drvread() might already be bounce buffering since boot2 has to do so since it copies the loader up to memory > 1MB as well. You might need to use memory > 2MB for zfsboot's malloc() so that the loader can be copied up to 1MB. It looks like you could patch malloc() in zfsboot.c to use 4*1024*1024 as heap_next and maybe 64*1024*1024 as heap_end (this assumes all machines that boot ZFS have at least 64MB of RAM, which is probably safe). -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Mon Nov 23 20:10:09 2009 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FB471065676 for ; Mon, 23 Nov 2009 20:10:09 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F2D458FC12 for ; Mon, 23 Nov 2009 20:10:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nANKA8Zh089414 for ; Mon, 23 Nov 2009 20:10:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nANKA8Ib089404; Mon, 23 Nov 2009 20:10:08 GMT (envelope-from gnats) Date: Mon, 23 Nov 2009 20:10:08 GMT Message-Id: <200911232010.nANKA8Ib089404@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Marius Strobl Cc: Subject: Re: sparc64/140797: Panic on 8.0-RC3/sparc64 as an NFS server X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Marius Strobl List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 20:10:09 -0000 The following reply was made to PR sparc64/140797; it has been noted by GNATS. From: Marius Strobl To: bug-followup@FreeBSD.org, Greg Lewis Cc: Subject: Re: sparc64/140797: Panic on 8.0-RC3/sparc64 as an NFS server Date: Mon, 23 Nov 2009 20:49:13 +0100 Could you please test whether r199274/r199284 fix this problem? http://svn.freebsd.org/viewvc/base/head/sys/nfsserver/nfs_fha.c?r1=195202&r2=199284&diff_format=u --- head/sys/nfsserver/nfs_fha.c 2009/06/30 19:03:27 195202 +++ head/sys/nfsserver/nfs_fha.c 2009/11/15 03:09:50 199284 @@ -206,7 +206,7 @@ if (error) goto out; - i->fh = *(const u_int64_t *)(fh.fh_generic.fh_fid.fid_data); + bcopy(fh.fh_generic.fh_fid.fid_data, &i->fh, sizeof(i->fh)); /* Content ourselves with zero offset for all but reads. */ if (procnum != NFSPROC_READ) From owner-freebsd-fs@FreeBSD.ORG Mon Nov 23 22:04:32 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8394C1065692 for ; Mon, 23 Nov 2009 22:04:32 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from mail-pz0-f185.google.com (mail-pz0-f185.google.com [209.85.222.185]) by mx1.freebsd.org (Postfix) with ESMTP id 5302E8FC0A for ; Mon, 23 Nov 2009 22:04:31 +0000 (UTC) Received: by pzk15 with SMTP id 15so4075585pzk.3 for ; Mon, 23 Nov 2009 14:04:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rYgSuIh/1OipdJ2BouPSbvIzzM4YUvzU1d4CPftlVL4=; b=fsyVk32lrpUj4AWElX2zcDjwI0kmU2Vokm8b31d3lTe8u+ubOow6gDwFlRxCrO0KAy tr3tdgoKrRBj+mdQiw92LhiGWqLFniRyUgCvjKhS7uH6Bykm49cLSlkH5cT0A3ZI7iTp xazEkYO3v8Z5Bby/fIA5jDKPIpgtIBqjF9PTc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tteNRIoo6rJ0qkthCldPwKE9wtpDR6SEKmEZLGBjQihMslTkM9T4JZKRCsvTbAi0Nj NC8WKJBq9DcHDYVI3Jlp2257cNTaIghrpFM0CsR95N+S00NfkFZnfOYbfKUGHwoBouri QV4BHhfykai8ZHu6VMYfeANAKcT1JncSgCHzg= MIME-Version: 1.0 Received: by 10.142.248.2 with SMTP id v2mr574889wfh.177.1259013870703; Mon, 23 Nov 2009 14:04:30 -0800 (PST) In-Reply-To: <200911231018.40815.jhb@freebsd.org> References: <200911231018.40815.jhb@freebsd.org> Date: Mon, 23 Nov 2009 14:04:30 -0800 Message-ID: From: Matt Reimer To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: Current gptzfsboot limitations X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 22:04:32 -0000 On Mon, Nov 23, 2009 at 7:18 AM, John Baldwin wrote: > On Friday 20 November 2009 7:46:54 pm Matt Reimer wrote: >> I've been analyzing gptzfsboot to see what its limitations are. I >> think it should now work fine for a healthy pool with any number of >> disks, with any type of vdev, whether single disk, stripe, mirror, >> raidz or raidz2. >> >> But there are currently several limitations (likely in loader.zfs >> too), mostly due to the limited amount of memory available (< 640KB) >> and the simple memory allocators used (a simple malloc() and >> zfs_alloc_temp()). ... >> >> I think I've also hit a stack overflow a couple of times while debugging= . >> >> I don't know enough about the gptzfsboot/loader.zfs environment to >> know whether the heap size could be easily enlarged, or whether there >> is room for a real malloc() with free(). loader(8) seems to use the >> malloc() in libstand. Can anyone shed some light on the memory >> limitations and possible solutions? >> >> I won't be able to spend much more time on this, but I wanted to pass >> on what I've learned in case someone else has the time and boot fu to >> take it the next step. > > One issue is that disk transfers need to happen in the lower 1MB due to B= IOS > limitations. =A0The loader uses a bounce buffer (in biosdisk.c in libi386= ) to > make this work ok. =A0The loader uses memory > 1MB for malloc(). =A0You c= ould > probably change zfsboot to do that as well if not already. =A0Just note t= hat > drvread() has to bounce buffer requests in that case. =A0The text + data = + bss > + stack is all in the lower 640k and there's not much you can do about th= at. > The stack grows down from 640k, and the boot program text + data starts a= t > 64k with the bss following. Ah, the stack growing down from 640k explains a problem I was seeing where a memcpy() to a temp buf would restart gptzfsboot--it must have been overwriting the stack. > Hmm, drvread() might already be bounce buffering > since boot2 has to do so since it copies the loader up to memory > 1MB as > well. Looks like it's already bounce buffering. All the I/O drvread does is to statically allocated char arrays, and the data is copied when necessary, e.g. in vdev_read(): if (drvread(dsk, dmadat->rdbuf, lba, nb)) return -1; memcpy(p, dmadat->rdbuf, nb * DEV_BSIZE); >=A0You might need to use memory > 2MB for zfsboot's malloc() so that the > loader can be copied up to 1MB. =A0It looks like you could patch malloc()= in > zfsboot.c to use 4*1024*1024 as heap_next and maybe 64*1024*1024 as heap_= end > (this assumes all machines that boot ZFS have at least 64MB of RAM, which= is > probably safe). So are the page tables etc. already configured such that RAM above 1MB is ready to use in gptzfsboot? (I'm not familiar with the details of how virtual memory is handled on i386.) Thanks for your help John. Matt From owner-freebsd-fs@FreeBSD.ORG Tue Nov 24 05:10:03 2009 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73F701065670 for ; Tue, 24 Nov 2009 05:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 631818FC08 for ; Tue, 24 Nov 2009 05:10:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nAO5A2Z9046202 for ; Tue, 24 Nov 2009 05:10:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nAO5A2h7046201; Tue, 24 Nov 2009 05:10:02 GMT (envelope-from gnats) Date: Tue, 24 Nov 2009 05:10:02 GMT Message-Id: <200911240510.nAO5A2h7046201@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Greg Lewis Cc: Subject: Re: sparc64/140797: Panic on 8.0-RC3/sparc64 as an NFS server X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Greg Lewis List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 05:10:03 -0000 The following reply was made to PR sparc64/140797; it has been noted by GNATS. From: Greg Lewis To: Marius Strobl Cc: bug-followup@FreeBSD.org, Greg Lewis Subject: Re: sparc64/140797: Panic on 8.0-RC3/sparc64 as an NFS server Date: Mon, 23 Nov 2009 21:05:33 -0800 On Mon, Nov 23, 2009 at 08:49:13PM +0100, Marius Strobl wrote: > Could you please test whether r199274/r199284 fix this problem? > > http://svn.freebsd.org/viewvc/base/head/sys/nfsserver/nfs_fha.c?r1=195202&r2=199284&diff_format=u > > --- head/sys/nfsserver/nfs_fha.c 2009/06/30 19:03:27 195202 > +++ head/sys/nfsserver/nfs_fha.c 2009/11/15 03:09:50 199284 > @@ -206,7 +206,7 @@ > if (error) > goto out; > > - i->fh = *(const u_int64_t *)(fh.fh_generic.fh_fid.fid_data); > + bcopy(fh.fh_generic.fh_fid.fid_data, &i->fh, sizeof(i->fh)); > > /* Content ourselves with zero offset for all but reads. */ > if (procnum != NFSPROC_READ) Thanks Marius! I'll give it a try as soon as I can and let you know. -- Greg Lewis Email : glewis@eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis@FreeBSD.org From owner-freebsd-fs@FreeBSD.ORG Tue Nov 24 11:30:05 2009 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 433F21065670 for ; Tue, 24 Nov 2009 11:30:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1813E8FC13 for ; Tue, 24 Nov 2009 11:30:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nAOBU4d0005446 for ; Tue, 24 Nov 2009 11:30:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nAOBU4LB005443; Tue, 24 Nov 2009 11:30:04 GMT (envelope-from gnats) Date: Tue, 24 Nov 2009 11:30:04 GMT Message-Id: <200911241130.nAOBU4LB005443@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Kenneth Schmidt Cc: Subject: Re: amd64/140661: /boot/loader fails to work on a GPT/ZFS-only system on both 8.0-RC2 and RC3 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kenneth Schmidt List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 11:30:05 -0000 The following reply was made to PR kern/140661; it has been noted by GNATS. From: Kenneth Schmidt To: Scot Hetzel Cc: freebsd-gnats-submit@freebsd.org Subject: Re: amd64/140661: /boot/loader fails to work on a GPT/ZFS-only system on both 8.0-RC2 and RC3 Date: Tue, 24 Nov 2009 11:51:06 +0100 --Apple-Mail-4--567691600 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Nov 18, 2009, at 21:57 , Scot Hetzel wrote: > Make sure you have LOADER_ZFS_SUPPORT in your /etc/src.conf: > > dv8t01# cat /etc/src.conf > LOADER_ZFS_SUPPORT=YES Ah! I also have LOADER_TFTP_SUPPORT=YES. Removing that, and everything works. I don't know why I didn't think of that in the first place, but maybe this is either a bug, or something that should be warned about when building loader(8)? /Kenneth --Apple-Mail-4--567691600 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFhDCCBYAw ggRooAMCAQICBEWGxzAwDQYJKoZIhvcNAQEFBQAwMTELMAkGA1UEBhMCREsxDDAKBgNVBAoTA1RE QzEUMBIGA1UEAxMLVERDIE9DRVMgQ0EwHhcNMDkwMjI4MTQxOTIyWhcNMTEwMjI4MTQ0OTIyWjCB gzELMAkGA1UEBhMCREsxKTAnBgNVBAoTIEluZ2VuIG9yZ2FuaXNhdG9yaXNrIHRpbGtueXRuaW5n MUkwIgYDVQQDExtLZW5uZXRoIFZlc3RlcmdhYXJkIFNjaG1pZHQwIwYDVQQFExxQSUQ6OTIwOC0y MDAyLTItNTgwODg3NjMzMzU1MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQChydTclnkISEut 5C7KkSZGmnFJiZFbs0+5xibIPGIVQTMsYkngAMEp+BXZu4vCJoIQIETg65tmf5uyhhikAiTdkj5U IX/7prCH5OS7wARyN2ZIOOsapf4h1vrbP6Q1DO9VZ6dcAL7H7Xem8O7Vk6fRwCwPSjjz0fF+Sk1D rLcRFQIDAQABo4ICzzCCAsswDgYDVR0PAQH/BAQDAgP4MCsGA1UdEAQkMCKADzIwMDkwMjI4MTQx OTIyWoEPMjAxMTAyMjgxNDQ5MjJaMIIBNwYDVR0gBIIBLjCCASowggEmBgoqgVCBKQEBAQEDMIIB FjAvBggrBgEFBQcCARYjaHR0cDovL3d3dy5jZXJ0aWZpa2F0LmRrL3JlcG9zaXRvcnkwgeIGCCsG AQUFBwICMIHVMAoWA1REQzADAgEBGoHGRm9yIGFudmVuZGVsc2UgYWYgY2VydGlmaWthdGV0IGfm bGRlciBPQ0VTIHZpbGvlciwgQ1BTIG9nIE9DRVMgQ1AsIGRlciBrYW4gaGVudGVzIGZyYSB3d3cu Y2VydGlmaWthdC5kay9yZXBvc2l0b3J5LiBCZW3mcmssIGF0IFREQyBlZnRlciB2aWxr5XJlbmUg aGFyIGV0IGJlZ3LmbnNldCBhbnN2YXIgaWZ0LiBwcm9mZXNzaW9uZWxsZSBwYXJ0ZXIuMEEGCCsG AQUFBwEBBDUwMzAxBggrBgEFBQcwAYYlaHR0cDovL29jc3AuY2VydGlmaWthdC5kay9vY3NwL3N0 YXR1czAhBgNVHREEGjAYgRZrdnNAYmluYXJ5c29sdXRpb25zLmRrMIGEBgNVHR8EfTB7MEugSaBH pEUwQzELMAkGA1UEBhMCREsxDDAKBgNVBAoTA1REQzEUMBIGA1UEAxMLVERDIE9DRVMgQ0ExEDAO BgNVBAMTB0NSTDM2MzgwLKAqoCiGJmh0dHA6Ly9jcmwub2Nlcy5jZXJ0aWZpa2F0LmRrL29jZXMu Y3JsMB8GA1UdIwQYMBaAFGC1hexWZH4SGSdnHVAVS3OuO/kSMB0GA1UdDgQWBBSG3wHOpKtm3LBy KmG/ORvrZernijAJBgNVHRMEAjAAMBkGCSqGSIb2fQdBAAQMMAobBFY3LjEDAgOoMA0GCSqGSIb3 DQEBBQUAA4IBAQCHp88nKSvx92/pb8exl7vBpU+UtweGEvag2EEuIrQMUsPetXxQTIZ4w1a3Si9z 79TEMbK7xURcGagyuf6BfKfKOGKSK5fLO/iwgf/6I2GmN3RKkg8wEFkb+qGLcQ8cuGQa+XASjlNn NgVfuQ8R7iIFGaZ+C/IHdQAHCbfJFQCw2G+HMdw0jHVXzibdvKp1yemmgqluyDvOPmck1j9ZnEW/ 3xlcSBwWHO2WO16Z8Jg04OHs+ijdCB5NrbmzbuxbBp1U8YD3hItz3WZIF19BoLhDYiOV2lEJi7O/ D1lByQLJf7SL6qMPISwWCrIGdR4d1MpK31Ch9Tso8ty305habYI8MYIB1TCCAdECAQEwOTAxMQsw CQYDVQQGEwJESzEMMAoGA1UEChMDVERDMRQwEgYDVQQDEwtUREMgT0NFUyBDQQIERYbHMDAJBgUr DgMCGgUAoIHzMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA5MTEy NDEwNTEwNlowIwYJKoZIhvcNAQkEMRYEFAAQNleLsRFOTb2BMQeL8Nxu6moxMEgGCSsGAQQBgjcQ BDE7MDkwMTELMAkGA1UEBhMCREsxDDAKBgNVBAoTA1REQzEUMBIGA1UEAxMLVERDIE9DRVMgQ0EC BEWGxzAwSgYLKoZIhvcNAQkQAgsxO6A5MDExCzAJBgNVBAYTAkRLMQwwCgYDVQQKEwNUREMxFDAS BgNVBAMTC1REQyBPQ0VTIENBAgRFhscwMA0GCSqGSIb3DQEBAQUABIGAEVe5Zay1Jc1Uxk8Vx0cz N+4TTtTpnFTQvT1FarRhACvDaDMBH93i0+PIc2sVJ6oyJLF5tbMsJI7BW4G8pomddCnwIsvAlzPr K4kQIk1yXGESEwiVUVPfVDXSpq0y7M/8wI0Q1SZtkCMTTs/QQ3qV77DVLwxYrZ5b102u0H+DOikA AAAAAAA= --Apple-Mail-4--567691600-- From owner-freebsd-fs@FreeBSD.ORG Tue Nov 24 11:50:49 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BF05106568D for ; Tue, 24 Nov 2009 11:50:49 +0000 (UTC) (envelope-from james-freebsd-fs2@jrv.org) Received: from mail.jrv.org (rrcs-24-73-246-106.sw.biz.rr.com [24.73.246.106]) by mx1.freebsd.org (Postfix) with ESMTP id 144D08FC19 for ; Tue, 24 Nov 2009 11:50:48 +0000 (UTC) Received: from kremvax.housenet.jrv (kremvax.housenet.jrv [192.168.3.124]) by mail.jrv.org (8.14.3/8.14.3) with ESMTP id nAOBokvi067213; Tue, 24 Nov 2009 05:50:47 -0600 (CST) (envelope-from james-freebsd-fs2@jrv.org) Authentication-Results: mail.jrv.org; domainkeys=pass (testing) header.from=james-freebsd-fs2@jrv.org DomainKey-Signature: a=rsa-sha1; s=enigma; d=jrv.org; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=HttyUu2lSmOafSAs+F48jiataCVpuG4FuovuKsutjJMib6zw7PxpJUgRHVA8MPO0T VEbn2JkGStcRAANxfy6+bUZK/WW8reoJ1x9sU1kL6X5r5KZLWdyPnMXMdJJsgADvHW3 zmb0Zu+t/MW/n1LizK1o5oP7exbwu+YLb82EiRk= Message-ID: <4B0BC896.8030808@jrv.org> Date: Tue, 24 Nov 2009 05:50:46 -0600 From: "James R. Van Artsdalen" User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs Subject: Re: Current gptzfsboot limitations X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 11:50:49 -0000 I assume that *zfsboot requires that /boot and /boot/kernel be in the boot filesystem and not filesystems of their own. A man page probably ought to say this or someone will be tempted to "zfs create pool/boot/kernel" so they can roll back undesirable kernel installs. From owner-freebsd-fs@FreeBSD.ORG Tue Nov 24 12:47:35 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3224C106568F for ; Tue, 24 Nov 2009 12:47:35 +0000 (UTC) (envelope-from se@freebsd.org) Received: from smtp143.mail.ukl.yahoo.com (smtp143.mail.ukl.yahoo.com [77.238.184.74]) by mx1.freebsd.org (Postfix) with SMTP id 9D91B8FC17 for ; Tue, 24 Nov 2009 12:47:34 +0000 (UTC) Received: (qmail 37761 invoked from network); 24 Nov 2009 12:47:33 -0000 Received: from xdsl-81-173-156-74.netcologne.de (se@81.173.156.74 with plain) by smtp143.mail.ukl.yahoo.com with SMTP; 24 Nov 2009 12:47:33 +0000 GMT X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. X-YMail-OSG: 7rNlRx0VM1nIDgNOPuAQF8XeAc9KlEyB0lAyh8_vNbR.n6T7z3Nvlm5DzhUcwzNcstjisNO6Ctu9aIwL6DjOt_tfMYOAcHyKmUwkoT2oQ_fh9.eggigmkkO8nTB8dN_ztsp6p0fl.6jWxrQOdo8S2_9PK.TYmLPCMbbKet1u6DPR3KfkfXfBWejB7Qm_IivYMclnXJ1eyKCLm_Pim37KRG41eAfrbx8Zs9rd743ProKMJj_u_k.3Uxt7WOEKyyiu X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B0BD5E7.3050604@freebsd.org> Date: Tue, 24 Nov 2009 13:47:35 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.4pre) Gecko/20090915 Lightning/1.0pre Thunderbird/3.0b4 MIME-Version: 1.0 To: Ollivier Robert References: <20091122154228.GB55532@rron.freenix.org> In-Reply-To: <20091122154228.GB55532@rron.freenix.org> X-Enigmail-Version: 0.97b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: 7.2 dies in zfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 12:47:35 -0000 On 22.11.2009 16:42, Ollivier Robert wrote: > According to Randy Bush: >> i think the issue is how to tune for zfs >> >> i386 with 4G of RAM > > I've given up on ZFS on i386. Whatever tuning you could do is only > delaying the inevitable. Even with lots of RAM, it will panic. I'd > love being proven wrong as I also hav a 4 GB i386 with ZFS and it panics > regularely. If your i386 based system has much RAM (2GB or more), than you should definitely increase KVA_PAGES. Not doing so will lead to panics, not in spite of but exactly because of the large RAM. I have been using ZFS on i386 since it became available, first for testing and soon as only file-system (with UFS boot, initially, now switching over to gptzfsboot). Systems range from Pentium-3 to AMD64x2 and I see no problems even under significant load. The following is the complete contents of /boot/loader.conf on my home server with 512MB RAM (the maximum supported on this P3/733 based SFF box) and a single 320MB IDE drive: zfs_load="YES" vfs.root.mountfrom="zfs:gk" vfs.zfs.arc_max="80000000" vm.kmem_size="350000000" The box is a mail gateway with spam-filter, IMAP server, web-server, SMB and NFS server for media applications (incl. storage backend for a networked digital TV receiver). It has only 280 days of uptime, since it took a reboot to upgrade kernel and world when ZFS version 13 had been committed to 8-current (previous uptime was at least as long). With 4GB of RAM you need to raise KVA_PAGES or you'll run into a panic. Perhaps, the default of 256 should be raised to 512? The cost of KVA_PAGES=512 is 1MB of RAM allocated to the kernel page table and 1GB less maximum user process size ... Sun specifically mentions, that ZFS makes assumptions that are easily valid on 64bit architectures, but not so easy to meet on 32bit systems. But for moderate load, ZFS can run on a 512MB P3 with good reliability and the known advantages from an admin POV. Regards, STefan From owner-freebsd-fs@FreeBSD.ORG Tue Nov 24 13:24:05 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 267A61065670 for ; Tue, 24 Nov 2009 13:24:05 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-bw0-f220.google.com (mail-bw0-f220.google.com [209.85.218.220]) by mx1.freebsd.org (Postfix) with ESMTP id A2AF38FC22 for ; Tue, 24 Nov 2009 13:24:04 +0000 (UTC) Received: by bwz20 with SMTP id 20so4934770bwz.14 for ; Tue, 24 Nov 2009 05:24:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=KGM0/rYR5Pxvp7O5gCD4/nEOQi8Tg9dhsAmnD/i3niI=; b=o3OcuxPAo1yd46V9AGomJvmYt9s7Sc9LOkqTt1P0kFneNWlzBLFIiyyjOzVg16X4L4 zpNOGeJoOjt7JCp1rsXKQabl8JBZd+hBbuUauygI5FJ6YkZN0d5HsmGEwq1CKjX0Mzb7 bADZqF8ANj5kCNhWMsxOee/qSJfnMqEshVuB0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; b=OqvjYO1YsTrh3rVsiwwpZbicnykk3vde607PR/hadCvSj4ISfSXAh+7XV2GMQI9l+g h5BMpmTVQ/u2KMvw3QKPHA9YsJUMjnUFn2ybsc373lfbA20zcMWr0dQ6D+/iaN+ycGQm ZByB5tF7NjF7Vtpe7ZkkIphhFlElXF/71qnn8= Received: by 10.204.33.194 with SMTP id i2mr6125257bkd.146.1259069043506; Tue, 24 Nov 2009 05:24:03 -0800 (PST) Received: from localhost (lan-78-157-90-54.vln.skynet.lt [78.157.90.54]) by mx.google.com with ESMTPS id z15sm7194246fkz.6.2009.11.24.05.24.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Nov 2009 05:24:02 -0800 (PST) Date: Tue, 24 Nov 2009 15:23:57 +0200 From: Gleb Kurtsou To: Martin =?utf-8?Q?Sch=C3=BCtte?= Message-ID: <20091124132357.GA1941@tops.skynet.lt> References: <4B09EDB2.7020002@mschuette.name> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4B09EDB2.7020002@mschuette.name> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-fs@FreeBSD.org Subject: Re: [nullfs] [panic] null with unref'ed lowervp X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 13:24:05 -0000 --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit On (23/11/2009 03:04), Martin Schütte wrote: > Hello, > my server recently had the kernel panic "null with unref'ed lowervp" in > null_subr.c:null_checkvp(). > I am not sure whether I should open a PR for it. > > The system is a SMP machine with SCSI RAID (asr), it runs several jails > and uses multiple null mounts between partitions, because there is not > enough disk space (~90% usage). > > uname -a: > FreeBSD trinity.asta.uni-potsdam.de 7.2-RELEASE > FreeBSD 7.2-RELEASE #3: Tue May 12 18:53:06 CEST 2009 > root@trinity.asta.uni-potsdam.de:/usr/obj/usr/src/sys/ASTA i386 > > Kernel is compiled with: > options INVARIANT_SUPPORT > options INVARIANTS > options DIAGNOSTIC In my understanding null_checkvp assumptions doesn't hold in null_lock and null_unlock. So I'd suggest you running without DIAGNOSTIC or try attached patch instead. > Among the few occurances I was not able to observe a pattern or > reproduce the error (two crashes happened at 8am which is a cronjob > time, but not one with particulary high load). > I am also going to add new disks any time now in order to reduce the > number of null mounts, so I do not expect to see this error again. > > I append three gdb backtraces, in case anyone finds them useful. > > -- > Martin Schütte --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename="nullfs-checkvp.patch.txt" diff --git a/sys/fs/nullfs/null_vnops.c b/sys/fs/nullfs/null_vnops.c index a028b63..4c0679f 100644 --- a/sys/fs/nullfs/null_vnops.c +++ b/sys/fs/nullfs/null_vnops.c @@ -553,7 +553,7 @@ null_lock(struct vop_lock1_args *ap) * lock as ffs has special lock considerations in it's * vop lock. */ - if (nn != NULL && (lvp = NULLVPTOLOWERVP(vp)) != NULL) { + if (nn != NULL && (lvp = nn->null_lowervp) != NULL) { VI_LOCK_FLAGS(lvp, MTX_DUPOK); VI_UNLOCK(vp); /* @@ -622,7 +622,7 @@ null_unlock(struct vop_unlock_args *ap) mtxlkflag = 2; } nn = VTONULL(vp); - if (nn != NULL && (lvp = NULLVPTOLOWERVP(vp)) != NULL) { + if (nn != NULL && (lvp = nn->null_lowervp) != NULL) { VI_LOCK_FLAGS(lvp, MTX_DUPOK); flags |= LK_INTERLOCK; vholdl(lvp); --CE+1k2dSO48ffgeK-- From owner-freebsd-fs@FreeBSD.ORG Tue Nov 24 14:24:36 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1CD7106566B for ; Tue, 24 Nov 2009 14:24:36 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.freenix.fr (keltia.freenix.org [IPv6:2001:660:330f:f820:213:72ff:fe15:f44]) by mx1.freebsd.org (Postfix) with ESMTP id 7F9418FC0C for ; Tue, 24 Nov 2009 14:24:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by keltia.freenix.fr (Postfix/TLS) with ESMTP id 694D739AE2 for ; Tue, 24 Nov 2009 15:24:35 +0100 (CET) X-Virus-Scanned: amavisd-new at keltia.freenix.fr Received: from keltia.freenix.fr ([127.0.0.1]) by localhost (keltia.freenix.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTh+xlthdiBv for ; Tue, 24 Nov 2009 15:24:35 +0100 (CET) Received: from roberto-al.eurocontrol.fr (aran.keltia.net [88.191.250.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.freenix.fr (Postfix/TLS) with ESMTPSA id DAD4839A2B for ; Tue, 24 Nov 2009 15:24:34 +0100 (CET) Date: Tue, 24 Nov 2009 15:24:07 +0100 From: Ollivier Robert To: freebsd-fs@freebsd.org Message-ID: <20091124142407.GD81894@roberto-al.eurocontrol.fr> References: <20091122154228.GB55532@rron.freenix.org> <4B0BD5E7.3050604@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <4B0BD5E7.3050604@freebsd.org> X-Operating-System: MacOS X / Macbook Pro - FreeBSD 7.2 / Dell D820 SMP User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: 7.2 dies in zfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 14:24:37 -0000 According to Stefan Esser: >If your i386 based system has much RAM (2GB or more), than you >should definitely increase KVA_PAGES. Not doing so will lead to >panics, not in spite of but exactly because of the large RAM. I have uppped KVA_PAGES of course but this is reducing the amount of memory available to processes. If you define KVA_PAGES to 2GB for example, every process will be able to use only the remaining 2 GB for their own memory so there is a trade off there. >I have been using ZFS on i386 since it became available, first for >testing and soon as only file-system (with UFS boot, initially, now >switching over to gptzfsboot). Systems range from Pentium-3 to >AMD64x2 and I see no problems even under significant load. I've found that load is not a factor (if one defines load as many concurrent processes). The machine is mostly idle and I've seen panics coming from a "cvs update" or a "svn up". There are I/O intensive but not that much whereas the same machine can survive a buildworld just fine. The machine I have is a dual Xeon @2.8 GHz with 4 GB of RAM and 200 GB of disk. /boot/loader.conf ----- #-- limits kern.maxdsiz="1024M" kern.maxssiz="256M" kern.dfldsiz="1024M" kern.dflssiz="128M" #-- vm tuning vm.kmem_size="1024M" vm.kmem_size_max="1224M" vfs.zfs.arc_max="128M" vfs.zfs.prefetch_disable=1 ----- options KVA_PAGES=384 # 1.5GB of KVA -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ From owner-freebsd-fs@FreeBSD.ORG Tue Nov 24 18:18:25 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 195611065694 for ; Tue, 24 Nov 2009 18:18:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id CA2098FC2B for ; Tue, 24 Nov 2009 18:18:24 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 612B046B2C; Tue, 24 Nov 2009 13:18:24 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 768D28A01D; Tue, 24 Nov 2009 13:18:23 -0500 (EST) From: John Baldwin To: Matt Reimer Date: Tue, 24 Nov 2009 11:43:24 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20091103; KDE/4.3.1; amd64; ; ) References: <200911231018.40815.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200911241143.24034.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 24 Nov 2009 13:18:23 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-fs@freebsd.org Subject: Re: Current gptzfsboot limitations X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 18:18:25 -0000 On Monday 23 November 2009 5:04:30 pm Matt Reimer wrote: > On Mon, Nov 23, 2009 at 7:18 AM, John Baldwin wrote: > > On Friday 20 November 2009 7:46:54 pm Matt Reimer wrote: > >> I've been analyzing gptzfsboot to see what its limitations are. I > >> think it should now work fine for a healthy pool with any number of > >> disks, with any type of vdev, whether single disk, stripe, mirror, > >> raidz or raidz2. > >> > >> But there are currently several limitations (likely in loader.zfs > >> too), mostly due to the limited amount of memory available (< 640KB) > >> and the simple memory allocators used (a simple malloc() and > >> zfs_alloc_temp()). > ... > >> > >> I think I've also hit a stack overflow a couple of times while debugging. > >> > >> I don't know enough about the gptzfsboot/loader.zfs environment to > >> know whether the heap size could be easily enlarged, or whether there > >> is room for a real malloc() with free(). loader(8) seems to use the > >> malloc() in libstand. Can anyone shed some light on the memory > >> limitations and possible solutions? > >> > >> I won't be able to spend much more time on this, but I wanted to pass > >> on what I've learned in case someone else has the time and boot fu to > >> take it the next step. > > > > One issue is that disk transfers need to happen in the lower 1MB due to BIOS > > limitations. The loader uses a bounce buffer (in biosdisk.c in libi386) to > > make this work ok. The loader uses memory > 1MB for malloc(). You could > > probably change zfsboot to do that as well if not already. Just note that > > drvread() has to bounce buffer requests in that case. The text + data + bss > > + stack is all in the lower 640k and there's not much you can do about that. > > The stack grows down from 640k, and the boot program text + data starts at > > 64k with the bss following. > > Ah, the stack growing down from 640k explains a problem I was seeing > where a memcpy() to a temp buf would restart gptzfsboot--it must have > been overwriting the stack. > > > Hmm, drvread() might already be bounce buffering > > since boot2 has to do so since it copies the loader up to memory > 1MB as > > well. > > Looks like it's already bounce buffering. All the I/O drvread does is > to statically allocated char arrays, and the data is copied when > necessary, e.g. in vdev_read(): > > if (drvread(dsk, dmadat->rdbuf, lba, nb)) > return -1; > memcpy(p, dmadat->rdbuf, nb * DEV_BSIZE); > > > > You might need to use memory > 2MB for zfsboot's malloc() so that the > > loader can be copied up to 1MB. It looks like you could patch malloc() in > > zfsboot.c to use 4*1024*1024 as heap_next and maybe 64*1024*1024 as heap_end > > (this assumes all machines that boot ZFS have at least 64MB of RAM, which is > > probably safe). > > So are the page tables etc. already configured such that RAM above 1MB > is ready to use in gptzfsboot? (I'm not familiar with the details of > how virtual memory is handled on i386.) > > Thanks for your help John. Paging is not enabled in the boot loader. Instead, the loader runs in a 32-bit flat mode (but with an offset of 0xa000). Simply changing the constants for heap_start and heap_end should be sufficient. -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Tue Nov 24 18:50:03 2009 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8EA61065676 for ; Tue, 24 Nov 2009 18:50:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7F8718FC1D for ; Tue, 24 Nov 2009 18:50:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nAOIo3h9088505 for ; Tue, 24 Nov 2009 18:50:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nAOIo3El088504; Tue, 24 Nov 2009 18:50:03 GMT (envelope-from gnats) Date: Tue, 24 Nov 2009 18:50:03 GMT Message-Id: <200911241850.nAOIo3El088504@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Baginski Darren Cc: Subject: Re: kern/139715: [zfs] vfs.numvnodes leak on busy zfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Baginski Darren List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 18:50:03 -0000 The following reply was made to PR kern/139715; it has been noted by GNATS. From: Baginski Darren To: bug-followup@freebsd.org Cc: Subject: Re: kern/139715: [zfs] vfs.numvnodes leak on busy zfs Date: Tue, 24 Nov 2009 21:48:06 +0300 Same issue on FreeBSD zfs-tsts073 8.0-PRERELEASE FreeBSD 8.0-PRERELEASE #8: Mon Nov 23 16:04:14 UTC 2009 root@zfs-tsts073:/usr/obj/usr/src/sys/GENERIC amd64 From owner-freebsd-fs@FreeBSD.ORG Wed Nov 25 00:28:05 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2111106568B for ; Wed, 25 Nov 2009 00:28:05 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from mail-pz0-f185.google.com (mail-pz0-f185.google.com [209.85.222.185]) by mx1.freebsd.org (Postfix) with ESMTP id BA1098FC16 for ; Wed, 25 Nov 2009 00:28:05 +0000 (UTC) Received: by pzk15 with SMTP id 15so4985037pzk.3 for ; Tue, 24 Nov 2009 16:28:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=+g4gVcr/PHcSBjl0LhGfq0+D9Naaar8YDnE4bqDqaNE=; b=djBH4DjFm9a9eNQyShn1VpLzZ2TP5eRi5RZyvSk9xr5163gcI3+30R5K9ZOMt2Higv 7nZkIc7sIP3tirl4HTLtRSdbCGMLdfQmnHap1Eo4xG0tBqKT49JQwjS0xBOuhM7TSldz 5NrzTDf1pg5n0KAprU6szyyaXpiGZilmd5kqc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wcTJW8UXYo6xMdm00BmEYan3vn6G7W81vBnvrTKmrGZd1aWbq25dy8VMVcqxA+UUof cosf3VQMgRQ21113x5RtxiHko9t/5gFF0wVdeqFwT/JMAzp2K22EXAGUot1I2U+xAnNm ik2N4UEbPCVCq0qRphdeABivgU87XQZz2eN08= MIME-Version: 1.0 Received: by 10.142.121.10 with SMTP id t10mr166720wfc.308.1259108885364; Tue, 24 Nov 2009 16:28:05 -0800 (PST) In-Reply-To: <4B0BC896.8030808@jrv.org> References: <4B0BC896.8030808@jrv.org> Date: Tue, 24 Nov 2009 16:28:05 -0800 Message-ID: From: Matt Reimer To: "James R. Van Artsdalen" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs Subject: Re: Current gptzfsboot limitations X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 00:28:06 -0000 On Tue, Nov 24, 2009 at 3:50 AM, James R. Van Artsdalen wrote: > I assume that *zfsboot requires that /boot and /boot/kernel be in the > boot filesystem and not filesystems of their own. > > A man page probably ought to say this or someone will be tempted to "zfs > create pool/boot/kernel" so they can roll back undesirable kernel installs. gptzfsboot (and I'm pretty sure zfsboot too) uses the first pool it finds. It opens the pool, gets the 'bootfs' property (i.e. the one set with "zpool set bootfs=tank/ROOT tank") and retrieves loader(8) from that filesystem. You can boot from any filesystem in the pool. Matt From owner-freebsd-fs@FreeBSD.ORG Wed Nov 25 03:40:05 2009 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7435C106566C; Wed, 25 Nov 2009 03:40:05 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4B0078FC12; Wed, 25 Nov 2009 03:40:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nAP3e5Z8052282; Wed, 25 Nov 2009 03:40:05 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nAP3e5ud052278; Wed, 25 Nov 2009 03:40:05 GMT (envelope-from linimon) Date: Wed, 25 Nov 2009 03:40:05 GMT Message-Id: <200911250340.nAP3e5ud052278@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/140853: [nfs] [patch] NFSv2 remove calls fail to send error replies (memory leak!) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 03:40:05 -0000 Old Synopsis: NFSv2 remove calls fail to send error replies (memory leak!) New Synopsis: [nfs] [patch] NFSv2 remove calls fail to send error replies (memory leak!) Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Wed Nov 25 03:39:42 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=140853 From owner-freebsd-fs@FreeBSD.ORG Wed Nov 25 06:00:15 2009 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0161A1065676 for ; Wed, 25 Nov 2009 06:00:15 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E51B58FC08 for ; Wed, 25 Nov 2009 06:00:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nAP60EZS077104 for ; Wed, 25 Nov 2009 06:00:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nAP60EgI077102; Wed, 25 Nov 2009 06:00:14 GMT (envelope-from gnats) Date: Wed, 25 Nov 2009 06:00:14 GMT Message-Id: <200911250600.nAP60EgI077102@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Greg Lewis Cc: Subject: Re: sparc64/140797: Panic on 8.0-RC3/sparc64 as an NFS server X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Greg Lewis List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 06:00:15 -0000 The following reply was made to PR sparc64/140797; it has been noted by GNATS. From: Greg Lewis To: Marius Strobl Cc: bug-followup@FreeBSD.org, Greg Lewis Subject: Re: sparc64/140797: Panic on 8.0-RC3/sparc64 as an NFS server Date: Tue, 24 Nov 2009 21:53:56 -0800 G'day Marius, On Mon, Nov 23, 2009 at 08:49:13PM +0100, Marius Strobl wrote: > Could you please test whether r199274/r199284 fix this problem? > > http://svn.freebsd.org/viewvc/base/head/sys/nfsserver/nfs_fha.c?r1=195202&r2=199284&diff_format=u > > --- head/sys/nfsserver/nfs_fha.c 2009/06/30 19:03:27 195202 > +++ head/sys/nfsserver/nfs_fha.c 2009/11/15 03:09:50 199284 > @@ -206,7 +206,7 @@ > if (error) > goto out; > > - i->fh = *(const u_int64_t *)(fh.fh_generic.fh_fid.fid_data); > + bcopy(fh.fh_generic.fh_fid.fid_data, &i->fh, sizeof(i->fh)); > > /* Content ourselves with zero offset for all but reads. */ > if (procnum != NFSPROC_READ) Yes, this fixes it! Thanks. Sorry for not finding that myself. I realise it may be too late to get this into the release. It might be worth an ERRATA notice if so. -- Greg Lewis Email : glewis@eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis@FreeBSD.org From owner-freebsd-fs@FreeBSD.ORG Wed Nov 25 09:52:27 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CCA61065692 for ; Wed, 25 Nov 2009 09:52:27 +0000 (UTC) (envelope-from se@freebsd.org) Received: from smtp136.mail.ukl.yahoo.com (smtp136.mail.ukl.yahoo.com [77.238.184.67]) by mx1.freebsd.org (Postfix) with SMTP id BC9138FC1E for ; Wed, 25 Nov 2009 09:52:26 +0000 (UTC) Received: (qmail 59695 invoked from network); 25 Nov 2009 09:52:25 -0000 Received: from xdsl-81-173-145-38.netcologne.de (se@81.173.145.38 with plain) by smtp136.mail.ukl.yahoo.com with SMTP; 25 Nov 2009 09:52:25 +0000 GMT X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. X-YMail-OSG: to9XTlkVM1l9VRGKh5q_Y3deRkCFAPFca0OPjC0GoV7P5jWc8VToJb6ubMyq731BvCKNJccWvshIlGmrpB5Knqstgzd0AwkY6B4dHyfwHemCj56Hw7drxdGkoV8Jbj12gGc4C7mqhDJn1PQHIL5SVvNf5qDW_4_prYFKngxCVGO.UAvVueYyoL_B9v2mpqjFbZzpLsqMiovOcl5Znus.bd54MjUoQeZ3TaRk9sOElk40zc1FI2GUEU3UlPTInlfj X-Yahoo-Newman-Property: ymail-3 Message-ID: <4B0CFE5B.8050504@freebsd.org> Date: Wed, 25 Nov 2009 10:52:27 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.4pre) Gecko/20090915 Lightning/1.0pre Thunderbird/3.0b4 MIME-Version: 1.0 To: Ollivier Robert References: <20091122154228.GB55532@rron.freenix.org> <4B0BD5E7.3050604@freebsd.org> <20091124142407.GD81894@roberto-al.eurocontrol.fr> In-Reply-To: <20091124142407.GD81894@roberto-al.eurocontrol.fr> X-Enigmail-Version: 0.97b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: 7.2 dies in zfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 09:52:27 -0000 Am 24.11.2009 15:24, schrieb Ollivier Robert: > According to Stefan Esser: >> If your i386 based system has much RAM (2GB or more), than you >> should definitely increase KVA_PAGES. Not doing so will lead to >> panics, not in spite of but exactly because of the large RAM. > > I have uppped KVA_PAGES of course but this is reducing the amount of > memory available to processes. If you define KVA_PAGES to 2GB for > example, every process will be able to use only the remaining 2 GB for > their own memory so there is a trade off there. Yes, I had mentioned that (256 -> 512 means 2MB RAM instead of 1MB spent on the kernel page table and 2GB rather than 3GB user process size; and AFAIK, the limit on the user process size has been the reason for not raising KVA_PAGES to 512 by default). Maybe you can estimate the amount of kernel memory required by measurement of kmem statistics without ZFS and adding about twice the ARC cache limit you want to impose. (The ARC can grow beyond arc_max, IIRC because this is just the high water mark where the cache is aggressively flushed and also because meta data is not taken into account by this limit.) E.g., if your system reports a vm.kvm_free of 100MB, you may be able to fit in an ARC of 50MB. >> I have been using ZFS on i386 since it became available, first for >> testing and soon as only file-system (with UFS boot, initially, now >> switching over to gptzfsboot). Systems range from Pentium-3 to >> AMD64x2 and I see no problems even under significant load. > > I've found that load is not a factor (if one defines load as many > concurrent processes). The machine is mostly idle and I've seen panics > coming from a "cvs update" or a "svn up". There are I/O intensive but > not that much whereas the same machine can survive a buildworld just fine. > > The machine I have is a dual Xeon @2.8 GHz with 4 GB of RAM and 200 GB > of disk. > > /boot/loader.conf > ----- > #-- limits > kern.maxdsiz="1024M" > kern.maxssiz="256M" > kern.dfldsiz="1024M" > kern.dflssiz="128M" > > #-- vm tuning > vm.kmem_size="1024M" > vm.kmem_size_max="1224M" > vfs.zfs.arc_max="128M" > vfs.zfs.prefetch_disable=1 > ----- > > options KVA_PAGES=384 # 1.5GB of KVA Well, my example was for the 512MB P3, which I use because of its power efficiency (less than 30W idle power drawn). My home workstation is an AMD x2 with 2GB RAM, 3*1TB disk (RAIDZ1), and with KVA_PAGES=512 and the following tunables set: kern.maxssiz="128M" vfs.root.mountfrom="zfs:raid1" # Specify root partition vm.kmem_size="1500M" # Sets the size of kernel memory (bytes) vm.kmem_size_max="2G" # Sets the size of kernel memory (bytes) zfs_load="YES" The ARC size is not limited, currently, and auto-sizes to some 950MB. But I have tried arc_max limits down to 200MB to study the impact. The system is absolutely reliable (with regard to ZFS, but haunted by LORs). I'm using a kernel with INVARIANTS and full WITNESS, since I want to understand lock-ups apparently caused by the combination of Atheros WLAN and SMP (sometimes accompanied by LORs). It survives not only CVS and SVN updates, but also other operations that made ZFS panic before I raised KVA_PAGES to its current value. Maybe, defaults for kmem_size and kmem_size_max would suffice, I have not tried them for a while. But KVA_PAGES=512 is essential for my system with 2GB RAM, guess this is even more true for your box with 4GB. Regards, STefan From owner-freebsd-fs@FreeBSD.ORG Wed Nov 25 13:42:05 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EF6C106566C; Wed, 25 Nov 2009 13:42:05 +0000 (UTC) (envelope-from sarawgi.aditya@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id E23208FC0C; Wed, 25 Nov 2009 13:42:04 +0000 (UTC) Received: by pxi12 with SMTP id 12so5612377pxi.3 for ; Wed, 25 Nov 2009 05:42:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:mime-version:content-type:content-disposition:user-agent; bh=Mn/s/be89Zn2vxp8m+vkYhGJTcrU6/asBbiJhc1AGPo=; b=lqv1lrr22vsbYq48JffGJ1cqzUgehBqjWyeWlyahDP4JogV9NYbaB+H5TOG5sfG82p ZbLygBEMOSofHuHWOC5/pEypD0S9isZBo/rw2Z9o8eE9TJPf3Y1+ZZ4MWLJm/OjRyOoj 54bhFHreN8wDTDUx2k468bPszlXYhG8qVoZNw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:mime-version:content-type :content-disposition:user-agent; b=xBTXBX6hkS687lzJ8CaWEt/23M4bzd67+XBENNs8j3un87E2UIzEbdvWxX98MTaEd3 jt5IAnBwJjm9QrJJPSj/NzRZg7/JYlMiFn2vxR60mGRqmxzOMKR87g7YwNQTRf1sEnr1 XCA8Ht86PxmoBimJMClXDceCHLHVD8LKjY3Js= Received: by 10.115.100.4 with SMTP id c4mr15641139wam.13.1259156524478; Wed, 25 Nov 2009 05:42:04 -0800 (PST) Received: from ([111.125.238.47]) by mx.google.com with ESMTPS id 22sm3931268pxi.6.2009.11.25.05.42.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 25 Nov 2009 05:42:03 -0800 (PST) Date: Wed, 25 Nov 2009 19:12:23 +0000 From: Aditya Sarawgi To: freebsd-fs@freebsd.org Message-ID: <4b0d342b.161bf30a.56fa.fffff5ed@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: lulf@freebsd.org Subject: ext2fs locks help X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 13:42:05 -0000 Hi, I am experiencing a strange problem with some locks I have applied to ext2fs. Here's what is happening 636 static daddr_t 637 ext2_alloccg(struct inode *ip, int cg, daddr_t bpref, int size) 638 { 639 struct m_ext2fs *fs; 640 struct buf *bp; 641 struct ext2mount *ump; 642 int error, bno, start, end, loc; 643 char *bbp; 644 /* XXX ondisk32 */ 645 mtx_assert(EXT2_MTX(ip->i_ump), MA_OWNED); 646 fs = ip->i_e2fs; 647 ump = ip->i_ump; 648 if (fs->e2fs_gd[cg].ext2bgd_nbfree == 0) 649 return (0); 650 EXT2_UNLOCK(ump); /* snip */ 712 EXT2_LOCK(ump); I have added a mutex to ext2mount for protecting fs similar to what ffs does. Now the problem is that system always panics at line 650 saying that panic: lock (sleep mutex) EXT2FS not locked @ /usr/src/sys/modules/ext2fs/../../fs/ext2fs/ext2_alloc.c:650 the assertion at 645 never fails and the system always panic at 650 only. I also tried commenting line 650, the system panics saying that trying to recurse a non-recursive lock @ line 712. So the lock is getting lost in between. Is this due to some other process unlocking the system ? -- Aditya Sarawgi From owner-freebsd-fs@FreeBSD.ORG Wed Nov 25 19:30:04 2009 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 067C61065676 for ; Wed, 25 Nov 2009 19:30:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D0BBA8FC1F for ; Wed, 25 Nov 2009 19:30:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nAPJU31I009912 for ; Wed, 25 Nov 2009 19:30:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nAPJU3sc009905; Wed, 25 Nov 2009 19:30:03 GMT (envelope-from gnats) Date: Wed, 25 Nov 2009 19:30:03 GMT Message-Id: <200911251930.nAPJU3sc009905@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Marius Strobl Cc: Subject: Re: sparc64/140797: Panic on 8.0-RC3/sparc64 as an NFS server X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Marius Strobl List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 19:30:04 -0000 The following reply was made to PR sparc64/140797; it has been noted by GNATS. From: Marius Strobl To: marcel@FreeBSD.org Cc: bug-followup@FreeBSD.org, Greg Lewis , Greg Lewis Subject: Re: sparc64/140797: Panic on 8.0-RC3/sparc64 as an NFS server Date: Wed, 25 Nov 2009 20:28:14 +0100 On Tue, Nov 24, 2009 at 09:53:56PM -0800, Greg Lewis wrote: > G'day Marius, > > On Mon, Nov 23, 2009 at 08:49:13PM +0100, Marius Strobl wrote: > > Could you please test whether r199274/r199284 fix this problem? > > > > http://svn.freebsd.org/viewvc/base/head/sys/nfsserver/nfs_fha.c?r1=195202&r2=199284&diff_format=u > > > > --- head/sys/nfsserver/nfs_fha.c 2009/06/30 19:03:27 195202 > > +++ head/sys/nfsserver/nfs_fha.c 2009/11/15 03:09:50 199284 > > @@ -206,7 +206,7 @@ > > if (error) > > goto out; > > > > - i->fh = *(const u_int64_t *)(fh.fh_generic.fh_fid.fid_data); > > + bcopy(fh.fh_generic.fh_fid.fid_data, &i->fh, sizeof(i->fh)); > > > > /* Content ourselves with zero offset for all but reads. */ > > if (procnum != NFSPROC_READ) > > Yes, this fixes it! Thanks. Sorry for not finding that myself. > > I realise it may be too late to get this into the release. It might be > worth an ERRATA notice if so. > Marcel, do you have any such plans? Marius From owner-freebsd-fs@FreeBSD.ORG Wed Nov 25 22:20:03 2009 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2728106566C for ; Wed, 25 Nov 2009 22:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 76E078FC0A for ; Wed, 25 Nov 2009 22:20:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nAPMK3G5057767 for ; Wed, 25 Nov 2009 22:20:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nAPMK3ER057766; Wed, 25 Nov 2009 22:20:03 GMT (envelope-from gnats) Date: Wed, 25 Nov 2009 22:20:03 GMT Message-Id: <200911252220.nAPMK3ER057766@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Marcel Moolenaar Cc: Subject: Re: sparc64/140797: Panic on 8.0-RC3/sparc64 as an NFS server X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Marcel Moolenaar List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 22:20:03 -0000 The following reply was made to PR sparc64/140797; it has been noted by GNATS. From: Marcel Moolenaar To: Marius Strobl Cc: "marcel@FreeBSD.org" , "bug-followup@FreeBSD.org" , Greg Lewis , Greg Lewis Subject: Re: sparc64/140797: Panic on 8.0-RC3/sparc64 as an NFS server Date: Wed, 25 Nov 2009 13:15:35 -0800 No, no plans. I only wanted to go as far as putting in in -stable -- which I did. FYI -- Marcel (Mobile) On Nov 25, 2009, at 11:28 AM, Marius Strobl wrote: > On Tue, Nov 24, 2009 at 09:53:56PM -0800, Greg Lewis wrote: >> G'day Marius, >> >> On Mon, Nov 23, 2009 at 08:49:13PM +0100, Marius Strobl wrote: >>> Could you please test whether r199274/r199284 fix this problem? >>> >>> http://svn.freebsd.org/viewvc/base/head/sys/nfsserver/nfs_fha.c?r1=195202&r2=199284&diff_format=u >>> >>> --- head/sys/nfsserver/nfs_fha.c 2009/06/30 19:03:27 195202 >>> +++ head/sys/nfsserver/nfs_fha.c 2009/11/15 03:09:50 199284 >>> @@ -206,7 +206,7 @@ >>> if (error) >>> goto out; >>> >>> - i->fh = *(const u_int64_t *)(fh.fh_generic.fh_fid.fid_data); >>> + bcopy(fh.fh_generic.fh_fid.fid_data, &i->fh, sizeof(i->fh)); >>> >>> /* Content ourselves with zero offset for all but reads. */ >>> if (procnum != NFSPROC_READ) >> >> Yes, this fixes it! Thanks. Sorry for not finding that myself. >> >> I realise it may be too late to get this into the release. It >> might be >> worth an ERRATA notice if so. >> > > Marcel, do you have any such plans? > > Marius > From owner-freebsd-fs@FreeBSD.ORG Thu Nov 26 08:09:13 2009 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B4391065670; Thu, 26 Nov 2009 08:09:13 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D5B0C8FC08; Thu, 26 Nov 2009 08:09:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nAQ89ClA099490; Thu, 26 Nov 2009 08:09:12 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nAQ89CcA099486; Thu, 26 Nov 2009 08:09:12 GMT (envelope-from linimon) Date: Thu, 26 Nov 2009 08:09:12 GMT Message-Id: <200911260809.nAQ89CcA099486@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/140888: [zfs] boot fail from zfs root while the pool resilvering X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 08:09:13 -0000 Old Synopsis: boot fail from zfs root while the pool resilvering New Synopsis: [zfs] boot fail from zfs root while the pool resilvering Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Thu Nov 26 08:08:58 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=140888 From owner-freebsd-fs@FreeBSD.ORG Thu Nov 26 10:01:04 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4FF6106566B for ; Thu, 26 Nov 2009 10:01:04 +0000 (UTC) (envelope-from james-freebsd-fs2@jrv.org) Received: from mail.jrv.org (adsl-70-243-84-13.dsl.austtx.swbell.net [70.243.84.13]) by mx1.freebsd.org (Postfix) with ESMTP id 767598FC12 for ; Thu, 26 Nov 2009 10:01:03 +0000 (UTC) Received: from kremvax.housenet.jrv (kremvax.housenet.jrv [192.168.3.124]) by mail.jrv.org (8.14.3/8.14.3) with ESMTP id nAQA12lD098993 for ; Thu, 26 Nov 2009 04:01:03 -0600 (CST) (envelope-from james-freebsd-fs2@jrv.org) Authentication-Results: mail.jrv.org; domainkeys=pass (testing) header.from=james-freebsd-fs2@jrv.org DomainKey-Signature: a=rsa-sha1; s=enigma; d=jrv.org; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding; b=ZYUHr3c0wZgkojRAHxdoLIJUynlXnM2tHX3byovZ4QkXtJ2ite+fozPIHElOFws/u hMTSYzsxG2lSCIZmC28bk4tZmulcSxsmiwk8hFoCXX3d8MGmJTe6PPzgv8kQmZ5DccM +9vA4fEt04Kp0LyXY8lm6yAkACzGmrC2WmTfydM= Message-ID: <4B0E51DE.1090707@jrv.org> Date: Thu, 26 Nov 2009 04:01:02 -0600 From: "James R. Van Artsdalen" User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: freebsd-fs Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: kernel update svn 195757->199260, zpool.cache prevents boot X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 10:01:04 -0000 I upgraded a ZFS system from svn 195757 to 199260 and it would not boot. Booting from UFS reported a corrupt pool with many faulted devices and vdevs. It turns out that the pool was fine and that zpool.cache was the problem: it was depending on the drive names being immutable but they changed between svn 195757 and 199260 for me (and will for many or most people 7.2->8.0 using the new AHCI driver) Why not have GEOM record the ZFS GUID of each leaf dev when GEOM "tastes" the drive (similar to the way GEOM does that for UFS today), and then use the GUID field from zpool.cache to find the disk instead of the PATH field? I don't see that ever failing. From owner-freebsd-fs@FreeBSD.ORG Thu Nov 26 11:30:06 2009 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5BC6106568F for ; Thu, 26 Nov 2009 11:30:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9685C8FC15 for ; Thu, 26 Nov 2009 11:30:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nAQBU6sa077051 for ; Thu, 26 Nov 2009 11:30:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nAQBU65B077048; Thu, 26 Nov 2009 11:30:06 GMT (envelope-from gnats) Date: Thu, 26 Nov 2009 11:30:06 GMT Message-Id: <200911261130.nAQBU65B077048@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: kot@softlynx.ru Cc: Subject: Re: kern/140888: [zfs] boot fail from zfs root while the pool resilvering X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kot@softlynx.ru List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 11:30:06 -0000 The following reply was made to PR kern/140888; it has been noted by GNATS. From: kot@softlynx.ru To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/140888: [zfs] boot fail from zfs root while the pool resilvering Date: Thu, 26 Nov 2009 14:02:12 +0300 (MSK) I found, that it keep fail booting if has at least one device not ONLINE and pool state DEGRADED. For instance [root@livecd8:/]# zpool status pool: tank0 state: DEGRADED scrub: none requested config: NAME STATE READ WRITE CKSUM tank0 DEGRADED 0 0 0 raidz1 DEGRADED 0 0 0 replacing DEGRADED 0 0 0 12996219703647995136 UNAVAIL 0 298 0 was /dev/gpt/QM00002 gpt/SN023432 ONLINE 0 0 0 gpt/SN091234 ONLINE 0 0 0 errors: No known data errors considered as degraded even it has replace gpt/QM00002 with new gpt/SN023432. Detaching UNAVAIL component turns pool to ONLINE state back. [root@livecd8:/]# zpool detach tank0 12996219703647995136 [root@livecd8:/]# zpool status pool: tank0 state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank0 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 gpt/SN023432 ONLINE 0 0 0 gpt/SN091234 ONLINE 0 0 0 errors: No known data errors This case lets to boot from tank0. It also keeps booting fine in case of component is manually turns to OFFLINE state in any combination, for instance like [root@fresh-inst:~]# zpool status pool: tank0 state: DEGRADED status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scrub: none requested config: NAME STATE READ WRITE CKSUM tank0 DEGRADED 0 0 0 raidz1 DEGRADED 0 0 0 gpt/SN023432 ONLINE 0 0 0 gpt/SN091234 OFFLINE 0 921 0 errors: No known data errors From owner-freebsd-fs@FreeBSD.ORG Thu Nov 26 12:19:27 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 616221065676 for ; Thu, 26 Nov 2009 12:19:27 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 8649C8FC08 for ; Thu, 26 Nov 2009 12:19:25 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA01876; Thu, 26 Nov 2009 14:19:18 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B0E7246.8090102@icyb.net.ua> Date: Thu, 26 Nov 2009 14:19:18 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: "James R. Van Artsdalen" References: <4B0E51DE.1090707@jrv.org> In-Reply-To: <4B0E51DE.1090707@jrv.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs Subject: Re: kernel update svn 195757->199260, zpool.cache prevents boot X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 12:19:27 -0000 on 26/11/2009 12:01 James R. Van Artsdalen said the following: > I upgraded a ZFS system from svn 195757 to 199260 and it would not > boot. Booting from UFS reported a corrupt pool with many faulted > devices and vdevs. > > It turns out that the pool was fine and that zpool.cache was the > problem: it was depending on the drive names being immutable but they > changed between svn 195757 and 199260 for me (and will for many or most > people 7.2->8.0 using the new AHCI driver) > > Why not have GEOM record the ZFS GUID of each leaf dev when GEOM > "tastes" the drive (similar to the way GEOM does that for UFS today), > and then use the GUID field from zpool.cache to find the disk instead of > the PATH field? I don't see that ever failing. Hmm, I thought that FreeBSD ZFS already did something like that. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu Nov 26 18:34:09 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38005106566C for ; Thu, 26 Nov 2009 18:34:09 +0000 (UTC) (envelope-from gcorcoran@rcn.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id ED20B8FC12 for ; Thu, 26 Nov 2009 18:34:08 +0000 (UTC) Received: from mr02.lnh.mail.rcn.net ([207.172.157.22]) by smtp02.lnh.mail.rcn.net with ESMTP; 26 Nov 2009 13:34:08 -0500 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr02.lnh.mail.rcn.net (MOS 3.10.7-GA) with ESMTP id QIM34484; Thu, 26 Nov 2009 13:34:08 -0500 (EST) X-Auth-ID: gcorcoran Received: from 216-164-180-100.c3-0.tlg-ubr8.atw-tlg.pa.cable.rcn.com (HELO [10.56.78.161]) ([216.164.180.100]) by smtp01.lnh.mail.rcn.net with ESMTP; 26 Nov 2009 13:34:08 -0500 Message-ID: <4B0ECA97.4060904@rcn.com> Date: Thu, 26 Nov 2009 13:36:07 -0500 From: Gary Corcoran User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Junkmail-Whitelist: YES (by domain whitelist at mr02.lnh.mail.rcn.net) Subject: Upgrading OS and ZFS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 18:34:09 -0000 I have a server consisting of a mirrored pair of UFS disks containing the OS, which is 7.0-CURRENT-200705, and a raidz zpool, with ZFS version 6. I want to upgrade the OS to 8.0-RELEASE, and upgrade the zpool. Since I don't have any important data on the OS disks, I plan to just do a fresh install of 8.0 on the UFS disk(s). My concern is how to do the upgrades without losing any zfs data. I believe I just need to do the following steps. Please advise if this will safely do the zpool upgrade, or whether a different sequence of actions is required to ensure I don't lose any ZFS data. 1. zpool export poolname 2. install FreeBSD 8.0 3. zpool import poolname 4. zpool upgrade poolname Is it really that easy? Thanks, Gary From owner-freebsd-fs@FreeBSD.ORG Thu Nov 26 19:09:57 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9B07106568B for ; Thu, 26 Nov 2009 19:09:57 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.freenix.fr (keltia.freenix.org [IPv6:2001:660:330f:f820:213:72ff:fe15:f44]) by mx1.freebsd.org (Postfix) with ESMTP id 68F1C8FC2B for ; Thu, 26 Nov 2009 19:09:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by keltia.freenix.fr (Postfix/TLS) with ESMTP id 64D5039C04 for ; Thu, 26 Nov 2009 20:09:56 +0100 (CET) X-Virus-Scanned: amavisd-new at keltia.freenix.fr Received: from keltia.freenix.fr ([127.0.0.1]) by localhost (keltia.freenix.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id modMIR4TdTXT for ; Thu, 26 Nov 2009 20:09:22 +0100 (CET) Received: from rron.freenix.org (rron.freenix.org [193.56.58.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.freenix.fr (Postfix/TLS) with ESMTPSA id 3122339C14 for ; Thu, 26 Nov 2009 20:09:21 +0100 (CET) Date: Thu, 26 Nov 2009 20:08:50 +0100 From: Ollivier Robert To: freebsd-fs@freebsd.org Message-ID: <20091126190849.GA67045@rron.freenix.org> References: <4B0ECA97.4060904@rcn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <4B0ECA97.4060904@rcn.com> X-Operating-System: MacOS X / Macbook Pro - FreeBSD 7.2 / Dell D820 SMP User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: Upgrading OS and ZFS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 19:09:57 -0000 According to Gary Corcoran: >1. zpool export poolname >2. install FreeBSD 8.0 >3. zpool import poolname >4. zpool upgrade poolname > >Is it really that easy? Except from the fact that you need to have backups anyway, yes, it should be that easy. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ From owner-freebsd-fs@FreeBSD.ORG Thu Nov 26 19:30:09 2009 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B06E0106566C for ; Thu, 26 Nov 2009 19:30:09 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 84B098FC16 for ; Thu, 26 Nov 2009 19:30:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nAQJU9p9094863 for ; Thu, 26 Nov 2009 19:30:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nAQJU9k7094860; Thu, 26 Nov 2009 19:30:09 GMT (envelope-from gnats) Date: Thu, 26 Nov 2009 19:30:09 GMT Message-Id: <200911261930.nAQJU9k7094860@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Vyacheslav Bocharov Cc: Subject: Re: kern/140682: [netgraph] [panic] random panic in netgraph X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vyacheslav Bocharov List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 19:30:09 -0000 The following reply was made to PR kern/140682; it has been noted by GNATS. From: Vyacheslav Bocharov To: bug-followup@FreeBSD.org, adeepv@gmail.com Cc: Subject: Re: kern/140682: [netgraph] [panic] random panic in netgraph Date: Thu, 26 Nov 2009 20:50:41 +0200 Please, change responsible to freebsd-net -- Vyacheslav mailto:adeepv@gmail.com From owner-freebsd-fs@FreeBSD.ORG Thu Nov 26 21:42:58 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFFF6106568B for ; Thu, 26 Nov 2009 21:42:58 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-gx0-f218.google.com (mail-gx0-f218.google.com [209.85.217.218]) by mx1.freebsd.org (Postfix) with ESMTP id 01BA98FC0C for ; Thu, 26 Nov 2009 21:42:57 +0000 (UTC) Received: by gxk10 with SMTP id 10so880913gxk.3 for ; Thu, 26 Nov 2009 13:42:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.101.184.5 with SMTP id l5mr110199anp.88.1259271776464; Thu, 26 Nov 2009 13:42:56 -0800 (PST) In-Reply-To: <20091126190849.GA67045@rron.freenix.org> References: <4B0ECA97.4060904@rcn.com> <20091126190849.GA67045@rron.freenix.org> Date: Thu, 26 Nov 2009 22:42:56 +0100 Message-ID: <367b2c980911261342q205d91aex9670a8510544fe8c@mail.gmail.com> From: Olivier Smedts To: Ollivier Robert Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org Subject: Re: Upgrading OS and ZFS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 21:42:58 -0000 2009/11/26 Ollivier Robert : > According to Gary Corcoran: >> >> 1. zpool export poolname >> 2. install FreeBSD 8.0 >> 3. zpool import poolname >> 4. zpool upgrade poolname Don't forget to zfs upgrade after zpool upgrade. >> >> Is it really that easy? > > Except from the fact that you need to have backups anyway, yes, it should be > that easy. > > -- > Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- > roberto@keltia.freenix.fr > In memoriam to Ondine : http://ondine.keltia.net/ > > _______________________________________________ > 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" > -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." From owner-freebsd-fs@FreeBSD.ORG Fri Nov 27 01:35:38 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 170571065679 for ; Fri, 27 Nov 2009 01:35:38 +0000 (UTC) (envelope-from gcorcoran@rcn.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id CDFDD8FC0C for ; Fri, 27 Nov 2009 01:35:37 +0000 (UTC) Received: from mr02.lnh.mail.rcn.net ([207.172.157.22]) by smtp02.lnh.mail.rcn.net with ESMTP; 26 Nov 2009 20:35:37 -0500 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr02.lnh.mail.rcn.net (MOS 3.10.7-GA) with ESMTP id QIM49222; Thu, 26 Nov 2009 20:34:43 -0500 (EST) X-Auth-ID: gcorcoran Received: from 216-164-180-100.c3-0.tlg-ubr8.atw-tlg.pa.cable.rcn.com (HELO [10.56.78.161]) ([216.164.180.100]) by smtp01.lnh.mail.rcn.net with ESMTP; 26 Nov 2009 20:34:43 -0500 Message-ID: <4B0F2D29.1020505@rcn.com> Date: Thu, 26 Nov 2009 20:36:41 -0500 From: Gary Corcoran User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <4B0ECA97.4060904@rcn.com> <20091126190849.GA67045@rron.freenix.org> In-Reply-To: <20091126190849.GA67045@rron.freenix.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Junkmail-Whitelist: YES (by domain whitelist at mr02.lnh.mail.rcn.net) Subject: Re: Upgrading OS and ZFS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 01:35:38 -0000 Ollivier Robert wrote: > According to Gary Corcoran: >> 1. zpool export poolname >> 2. install FreeBSD 8.0 >> 3. zpool import poolname >> 4. zpool upgrade poolname >> >> Is it really that easy? > > Except from the fact that you need to have backups anyway, yes, it > should be that easy. I do have a backup, just in case, but really want to avoid having to use it if I can. Thanks for the confirmation. Gary From owner-freebsd-fs@FreeBSD.ORG Fri Nov 27 01:40:30 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16051106566C for ; Fri, 27 Nov 2009 01:40:30 +0000 (UTC) (envelope-from gcorcoran@rcn.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id C56618FC19 for ; Fri, 27 Nov 2009 01:40:29 +0000 (UTC) Received: from mr02.lnh.mail.rcn.net ([207.172.157.22]) by smtp02.lnh.mail.rcn.net with ESMTP; 26 Nov 2009 20:40:29 -0500 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr02.lnh.mail.rcn.net (MOS 3.10.7-GA) with ESMTP id QIM49437; Thu, 26 Nov 2009 20:39:44 -0500 (EST) X-Auth-ID: gcorcoran Received: from 216-164-180-100.c3-0.tlg-ubr8.atw-tlg.pa.cable.rcn.com (HELO [10.56.78.161]) ([216.164.180.100]) by smtp01.lnh.mail.rcn.net with ESMTP; 26 Nov 2009 20:39:45 -0500 Message-ID: <4B0F2E58.4000203@rcn.com> Date: Thu, 26 Nov 2009 20:41:44 -0500 From: Gary Corcoran User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <4B0ECA97.4060904@rcn.com> <20091126190849.GA67045@rron.freenix.org> <367b2c980911261342q205d91aex9670a8510544fe8c@mail.gmail.com> In-Reply-To: <367b2c980911261342q205d91aex9670a8510544fe8c@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Junkmail-Whitelist: YES (by domain whitelist at mr02.lnh.mail.rcn.net) Subject: Re: Upgrading OS and ZFS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 01:40:30 -0000 Olivier Smedts wrote: > 2009/11/26 Ollivier Robert : >> According to Gary Corcoran: >>> 1. zpool export poolname >>> 2. install FreeBSD 8.0 >>> 3. zpool import poolname >>> 4. zpool upgrade poolname > > Don't forget to zfs upgrade after zpool upgrade. Thanks. I wasn't aware of "zfs upgrade". The command doesn't exist in the old version of zfs I am currently running. Gary > >>> Is it really that easy? >> Except from the fact that you need to have backups anyway, yes, it should be >> that easy. From owner-freebsd-fs@FreeBSD.ORG Sat Nov 28 22:22:29 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8AC7D106566C for ; Sat, 28 Nov 2009 22:22:29 +0000 (UTC) (envelope-from morganw@chemikals.org) Received: from warped.bluecherry.net (unknown [IPv6:2001:440:eeee:fffb::2]) by mx1.freebsd.org (Postfix) with ESMTP id 318B58FC15 for ; Sat, 28 Nov 2009 22:22:29 +0000 (UTC) Received: from volatile.chemikals.org (adsl-67-211-219.shv.bellsouth.net [98.67.211.219]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by warped.bluecherry.net (Postfix) with ESMTPSA id C271A9883311 for ; Sat, 28 Nov 2009 16:22:27 -0600 (CST) Received: from localhost (morganw@localhost [127.0.0.1]) by volatile.chemikals.org (8.14.3/8.14.3) with ESMTP id nASMMPlf020396 for ; Sat, 28 Nov 2009 16:22:25 -0600 (CST) (envelope-from morganw@chemikals.org) Date: Sat, 28 Nov 2009 16:22:24 -0600 (CST) From: Wes Morgan To: freebsd-fs@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Virus-Scanned: clamav-milter 0.95.2 at warped X-Virus-Status: Clean Subject: raidz configuration X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 22:22:29 -0000 Simple question: 8 devices in a raidz2 or 4 devices in a raidz x 2 Same net storage, but, if my understanding of raidz is correct, higher throughput on the raidz x 2, and obviously higher MTTDL for the raidz2. Maybe throw in a hot spare and what do you think? Pros and cons anyone?