From owner-freebsd-fs@FreeBSD.ORG Sun Apr 29 03:54:12 2012 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 469A91065673 for ; Sun, 29 Apr 2012 03:54:12 +0000 (UTC) (envelope-from rsimmons0@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id EE0FE8FC12 for ; Sun, 29 Apr 2012 03:54:11 +0000 (UTC) Received: by vbmv11 with SMTP id v11so1833534vbm.13 for ; Sat, 28 Apr 2012 20:54:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=gwE1Xl/ZBLEap+t1OAsUywEVLXwLbV01B5c3ruiGNAw=; b=nhKCoaWBkTgrFsS2T4R5g91m6QuQp1SLFxivAeCk9Qoh6fKFGlO4Kwbg50Y/cKqrNt SLC0PGm6wAjK8SQrvQzrtH2syeB7ZTpIxnxmWHtV0BV7ZXOF/CWCSm3D/KCLC3W1d4Po IZoBdj0NBYtxmYTgrjssHpQt7e7nyyCxZL+sPTJfqysWX9eCFbcz/X0UCb4e+vCe+cM1 Zjosa02EpSjqkgzy6SNi6EBLJSxn/NeAKYSqpdOvJ6gNxZFDJ491EDTEEWk/WkF1p+5F 8GM2rnz4P0GANH4abM0Tg94wW+aXX+ekKUrPISPz2K1qVgrgonp19eIf7c60j9y8JSvb e3aA== MIME-Version: 1.0 Received: by 10.220.108.16 with SMTP id d16mr16765561vcp.51.1335671645142; Sat, 28 Apr 2012 20:54:05 -0700 (PDT) Received: by 10.52.66.239 with HTTP; Sat, 28 Apr 2012 20:54:05 -0700 (PDT) Date: Sat, 28 Apr 2012 23:54:05 -0400 Message-ID: From: Robert Simmons To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: NFSv4 Questions 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, 29 Apr 2012 03:54:12 -0000 I've been digging and digging to find sources to clarify the exports(5) man page with no luck. What I have read differs from what I see on my server. From the man page examples section: V4: / -sec=krb5:krb5i:krb5p -network 131.104.48 -mask 255.255.255.0 Now, here is what I have put as an experiment to try to understand what's happening here (my /etc/exports): V4: / -sec=krb5 -network 192.168.1 -mask 255.255.255.0 / In this case, -sec=krb5 is totally ignored. I can mount / using sys. If I use this: V4: / / -sec=krb5 It requires proper kerberos authentication. My next question is can I reject NFSv3/v2 clients/connections? Third question is: how can I disable rpcbind? It seems that the following does not work in rc.conf: rpcbind_enable="NO" When I'm running NFSv4 rpcbind is not needed, but it seems that mountd always starts rpcbind no matter what I do: /etc/rc.d/rpcbind stop is the only way to do it, and that is only after boot, or mountd starting. From owner-freebsd-fs@FreeBSD.ORG Sun Apr 29 13:10:01 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 044BB106566B for ; Sun, 29 Apr 2012 13:10:01 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id AB52E8FC0C for ; Sun, 29 Apr 2012 13:10:00 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAFM8nU+DaFvO/2dsb2JhbABEhWitNoIJAQEBAwEBAQEgKyALBRYOCgICDRkCKQEJJgYIBwQBHASHZwULpi2SDIEviV2EfoEYBJNPgi+BEY8xgwSBQA X-IronPort-AV: E=Sophos;i="4.75,501,1330923600"; d="scan'208";a="167117240" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 29 Apr 2012 09:10:00 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 0B522B40E7; Sun, 29 Apr 2012 09:10:00 -0400 (EDT) Date: Sun, 29 Apr 2012 09:09:59 -0400 (EDT) From: Rick Macklem To: Robert Simmons Message-ID: <310519099.96451.1335704999990.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org Subject: Re: NFSv4 Questions 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, 29 Apr 2012 13:10:01 -0000 Robert Simmons wrote: > I've been digging and digging to find sources to clarify the > exports(5) man page with no luck. What I have read differs from what > I see on my server. From the man page examples section: > > V4: / -sec=krb5:krb5i:krb5p -network 131.104.48 -mask 255.255.255.0 > > Now, here is what I have put as an experiment to try to understand > what's happening here (my /etc/exports): > > V4: / -sec=krb5 -network 192.168.1 -mask 255.255.255.0 > / > > In this case, -sec=krb5 is totally ignored. I can mount / using sys. > The "-sec=krb5" restriction applies to state related operations that don't use file handles. The FreeBSD mount doesn't do any of those, so it is the options on the second line "/" that control whether or not the mount succeeds. With the above exports, the first Open of a file should fail when attempted via auth_sys, at least for the FreeBSD client. (The FreeBSD client doesn't try and establish state via SetClientID until the first Open. Some other clients do so at mount time.) I know this is ugly, but I thought it would be confusing to have the semantics of the other export lines (like "/") different for NFSv4 than NFSv2,3. For NFSv2,3 all RPCs involve a file handle, so they can be associated with a server volume. For NFSv4, this is not the case, since some state related operations (SetClientID/SetClientIDConfirm/Renew and maybe a couple of others) do not use a file handle and, as such, can't be associated with an exported volume. I put the options in the "V4:" for those, since I couldn't think of where else to put them. > If I use this: > > V4: / > / -sec=krb5 > > It requires proper kerberos authentication. > Yep, as explained above. If you really want to restrict NFSv4 use to kerberos, then you should put the "-sec=krb5" on the V4: line and all lines exporting volumes. For example: V4: / -sec=krb5 / -sec=krb5 > My next question is can I reject NFSv3/v2 clients/connections? > sysctl vfs.nfsd.server_min_nfsvers=4 > Third question is: how can I disable rpcbind? It seems that the > following does not work in rc.conf: > rpcbind_enable="NO" > When I'm running NFSv4 rpcbind is not needed, but it seems that mountd > always starts rpcbind no matter what I do: > /etc/rc.d/rpcbind stop > is the only way to do it, and that is only after boot, or mountd > starting. > _ Yea, I suppose there should be a -nfsv4-only option on mountd, so it knows that it only needs to do exports and doesn't need rpcbind. Since you are probably the first person wanting an NFSv4 only server, I hadn't thought to do this. I'll put it on my "to do" list. Thanks for the comments, rick > ______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Sun Apr 29 15:46:09 2012 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 047E2106566B for ; Sun, 29 Apr 2012 15:46:09 +0000 (UTC) (envelope-from rsimmons0@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id AE3818FC12 for ; Sun, 29 Apr 2012 15:46:08 +0000 (UTC) Received: by vcmm1 with SMTP id m1so2030253vcm.13 for ; Sun, 29 Apr 2012 08:46:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ipJ2z+Um8zThi8M8SejwmseeHkSEpXX43T4tyM6Bp1Y=; b=Kc8yA+a8m+XJ046GGNpOCXnC31bznHxOhAjPhNLNzZG31Q+hYdwVQ2lUZ6kIihJHjZ 4E4wpE9FJmDi8YxyV8pCed1QfLiFMA4gam0sV6aIarDWw1HpnsN8SLTBMajHD8iZrS/Y TCz9BS4g1rCg5t98kYcl5BS6agmnbsqn5matxnh1LHFb/ZaC5Y4INMBdR2BATA+Az20+ Zb8IIe2qarksIlELBNAF/Narqg2/UbSRsNWyMqJSVp/5KeGpROwD1/38OPZgCfNkbM8Q n/JEq4iyLcLoy5FRsJ9ChKrLtdI2tY3P++hGL7RlX9ZW9TAGMXavLvOSzIJeTF0pqpyo N71Q== MIME-Version: 1.0 Received: by 10.220.156.10 with SMTP id u10mr18762794vcw.20.1335714367964; Sun, 29 Apr 2012 08:46:07 -0700 (PDT) Received: by 10.52.66.239 with HTTP; Sun, 29 Apr 2012 08:46:07 -0700 (PDT) In-Reply-To: <310519099.96451.1335704999990.JavaMail.root@erie.cs.uoguelph.ca> References: <310519099.96451.1335704999990.JavaMail.root@erie.cs.uoguelph.ca> Date: Sun, 29 Apr 2012 11:46:07 -0400 Message-ID: From: Robert Simmons To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: NFSv4 Questions 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, 29 Apr 2012 15:46:09 -0000 On Sun, Apr 29, 2012 at 9:09 AM, Rick Macklem wrote: > Robert Simmons wrote: >> I've been digging and digging to find sources to clarify the >> exports(5) man page with no luck. What I have read differs from what >> I see on my server. From the man page examples section: >> >> V4: / -sec=krb5:krb5i:krb5p -network 131.104.48 -mask 255.255.255.0 >> >> Now, here is what I have put as an experiment to try to understand >> what's happening here (my /etc/exports): >> >> V4: / -sec=krb5 -network 192.168.1 -mask 255.255.255.0 >> / >> >> In this case, -sec=krb5 is totally ignored. I can mount / using sys. >> > The "-sec=krb5" restriction applies to state related operations that don't > use file handles. > The FreeBSD mount doesn't do any of those, so it is the options on the second line > "/" that control whether or not the mount succeeds. > > With the above exports, the first Open of a file should fail when attempted via auth_sys, > at least for the FreeBSD client. (The FreeBSD client doesn't try and establish > state via SetClientID until the first Open. Some other clients do so at mount time.) > > I know this is ugly, but I thought it would be confusing to have the semantics > of the other export lines (like "/") different for NFSv4 than NFSv2,3. For NFSv2,3 > all RPCs involve a file handle, so they can be associated with a server volume. > For NFSv4, this is not the case, since some state related operations > (SetClientID/SetClientIDConfirm/Renew and maybe a couple of others) do not use > a file handle and, as such, can't be associated with an exported volume. I put > the options in the "V4:" for those, since I couldn't think of where else to put > them. I think a rewrite of exports(5) might help out quite a lot. Especially if the EXAMPLES section was scrapped entirely and replaced with a set of examples each one more granular in explaining one feature or use case instead of lumping all of it into explaining one huge export file. Since I'm working on setting up a pair of NFS servers with a set of clients, I volunteer. May I contact you offlist if I have questions? >> If I use this: >> >> V4: / >> / -sec=krb5 >> >> It requires proper kerberos authentication. >> > Yep, as explained above. If you really want to restrict NFSv4 use to kerberos, > then you should put the "-sec=krb5" on the V4: line and all lines exporting > volumes. For example: > V4: / -sec=krb5 > / -sec=krb5 Got it. >> My next question is can I reject NFSv3/v2 clients/connections? >> > sysctl vfs.nfsd.server_min_nfsvers=4 Perfect. >> Third question is: how can I disable rpcbind? It seems that the >> following does not work in rc.conf: >> rpcbind_enable="NO" >> When I'm running NFSv4 rpcbind is not needed, but it seems that mountd >> always starts rpcbind no matter what I do: >> /etc/rc.d/rpcbind stop >> is the only way to do it, and that is only after boot, or mountd >> starting. >> _ > Yea, I suppose there should be a -nfsv4-only option on mountd, so it > knows that it only needs to do exports and doesn't need rpcbind. > Since you are probably the first person wanting an NFSv4 only server, > I hadn't thought to do this. I'll put it on my "to do" list. If I may, perhaps a switch in /etc/rc.conf: nfsv4_only="YES" This would set the -nfsv4-only switch you mention for mountd, and it would set vfs.nfsd.server_min_nfsvers=4 This would be exactly what I'm looking for. Thanks for your help! From owner-freebsd-fs@FreeBSD.ORG Sun Apr 29 16:46:24 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C5C08106566C; Sun, 29 Apr 2012 16:46:24 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 5C6838FC0C; Sun, 29 Apr 2012 16:46:24 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id q3TGkN6K017922; Sun, 29 Apr 2012 18:46:23 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q3TGkNjB017921; Sun, 29 Apr 2012 18:46:23 +0200 (CEST) (envelope-from marius) Date: Sun, 29 Apr 2012 18:46:23 +0200 From: Marius Strobl To: Andriy Gapon Message-ID: <20120429164623.GG68446@alchemy.franken.de> References: <4F8999D2.1080902@FreeBSD.org> <20120422212102.GA66855@alchemy.franken.de> <4F9A6180.8090500@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F9A6180.8090500@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-fs@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool 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, 29 Apr 2012 16:46:24 -0000 On Fri, Apr 27, 2012 at 12:06:08PM +0300, Andriy Gapon wrote: > on 23/04/2012 00:21 Marius Strobl said the following: > > On Sat, Apr 14, 2012 at 06:37:54PM +0300, Andriy Gapon wrote: > [snip] > >> I am particularly interested in reviews of my attempt to make ZFS boot support > >> arch-independent. The arches, of course, would have to add some code to make > >> use of that support. Currently I only enabled it for x86. > >> > > > > I can't say much about these patches as a whole as they are rather > > big and I'm not aware of all the details of ZFS. However, one bit that > > makes the current implementation x86-specific is zfs_dev_init(). If > > you could move it to the MD part in the course of these patches that > > would be great. > > I have arranged this in my WIP version of the patch, which I hope to share soon. > Need to work out some unrelated details. > > > If you could also take the second patch in PR 165025 > > into account, which I plan to commit once the issue with the current > > ofw_disk.c are properly solved, that would be great. > > Thank you for the heads up. > Since I also hope to commit my patch rather soon, I would also appreciate if you > keep my changes in mind :-) > In fact, I would like to ask you if it would make sense to postpone the patch > from the PR until my patch is committed. That should make some things easier to > do (e.g. MD zfs_dev_init), but on the other hand some things would become different. > Either way, one of the patches would have to be rebased on top of the other. > Given that you certainly have a well better knowledge of ZFS, it would be great if we could do it the other way around, i.e. commit the sparc64 support first and then your patch after adapting whatever you have in mind with things becoming different. In other words, I'm basically ready to commit the following patch. As for zfs_dev_init() this just wraps it in #if defined(__amd64__) || defined(__i386__) in zfs.c for now. http://people.freebsd.org/~marius/boot_zfs_sparc64.diff Marius From owner-freebsd-fs@FreeBSD.ORG Sun Apr 29 20:36:05 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1C51D106566C for ; Sun, 29 Apr 2012 20:36:05 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id C74D98FC0A for ; Sun, 29 Apr 2012 20:36:04 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAFSlnU+DaFvO/2dsb2JhbABEhWitOIIJAQEBAwEBAQEgKyALBRYOCgICDRkCKQEJJgYIBwQBHASHZwULpn+SA4EviV2EfoEYBJNPgi+BEY8xgwSBQA X-IronPort-AV: E=Sophos;i="4.75,501,1330923600"; d="scan'208";a="170016920" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 29 Apr 2012 16:36:03 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id A2631B3F62; Sun, 29 Apr 2012 16:36:03 -0400 (EDT) Date: Sun, 29 Apr 2012 16:36:03 -0400 (EDT) From: Rick Macklem To: Robert Simmons Message-ID: <1494135294.103829.1335731763653.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org Subject: Re: NFSv4 Questions 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, 29 Apr 2012 20:36:05 -0000 Robert Simmons wrote: > On Sun, Apr 29, 2012 at 9:09 AM, Rick Macklem > wrote: > > Robert Simmons wrote: > >> I've been digging and digging to find sources to clarify the > >> exports(5) man page with no luck. What I have read differs from > >> what > >> I see on my server. From the man page examples section: > >> > >> V4: / -sec=krb5:krb5i:krb5p -network 131.104.48 -mask 255.255.255.0 > >> > >> Now, here is what I have put as an experiment to try to understand > >> what's happening here (my /etc/exports): > >> > >> V4: / -sec=krb5 -network 192.168.1 -mask 255.255.255.0 > >> / > >> > >> In this case, -sec=krb5 is totally ignored. I can mount / using > >> sys. > >> > > The "-sec=krb5" restriction applies to state related operations that > > don't > > use file handles. > > The FreeBSD mount doesn't do any of those, so it is the options on > > the second line > > "/" that control whether or not the mount succeeds. > > > > With the above exports, the first Open of a file should fail when > > attempted via auth_sys, > > at least for the FreeBSD client. (The FreeBSD client doesn't try and > > establish > > state via SetClientID until the first Open. Some other clients do so > > at mount time.) > > > > I know this is ugly, but I thought it would be confusing to have the > > semantics > > of the other export lines (like "/") different for NFSv4 than > > NFSv2,3. For NFSv2,3 > > all RPCs involve a file handle, so they can be associated with a > > server volume. > > For NFSv4, this is not the case, since some state related operations > > (SetClientID/SetClientIDConfirm/Renew and maybe a couple of others) > > do not use > > a file handle and, as such, can't be associated with an exported > > volume. I put > > the options in the "V4:" for those, since I couldn't think of where > > else to put > > them. > > I think a rewrite of exports(5) might help out quite a lot. > Especially if the EXAMPLES section was scrapped entirely and replaced > with a set of examples each one more granular in explaining one > feature or use case instead of lumping all of it into explaining one > huge export file. > > Since I'm working on setting up a pair of NFS servers with a set of > clients, I volunteer. May I contact you offlist if I have questions? > Sure. However, I'd suggest that you get others to review it as well, since I kinda know how it works and won't spot "missing bits", although I should be able to catch most inaccuracies. Also, be sure to check "man nfsv4" and maybe reference it (it is currently in the See Also list, but that might not be strong enough). > >> If I use this: > >> > >> V4: / > >> / -sec=krb5 > >> > >> It requires proper kerberos authentication. > >> > > Yep, as explained above. If you really want to restrict NFSv4 use to > > kerberos, > > then you should put the "-sec=krb5" on the V4: line and all lines > > exporting > > volumes. For example: > > V4: / -sec=krb5 > > / -sec=krb5 > > Got it. > > >> My next question is can I reject NFSv3/v2 clients/connections? > >> > > sysctl vfs.nfsd.server_min_nfsvers=4 > > Perfect. > > >> Third question is: how can I disable rpcbind? It seems that the > >> following does not work in rc.conf: > >> rpcbind_enable="NO" > >> When I'm running NFSv4 rpcbind is not needed, but it seems that > >> mountd > >> always starts rpcbind no matter what I do: > >> /etc/rc.d/rpcbind stop > >> is the only way to do it, and that is only after boot, or mountd > >> starting. > >> _ > > Yea, I suppose there should be a -nfsv4-only option on mountd, so it > > knows that it only needs to do exports and doesn't need rpcbind. > > Since you are probably the first person wanting an NFSv4 only > > server, > > I hadn't thought to do this. I'll put it on my "to do" list. > > If I may, perhaps a switch in /etc/rc.conf: > nfsv4_only="YES" > I might call it nfsv4_server_only, but sounds like a good suggestion. > This would set the -nfsv4-only switch you mention for mountd, and it > would set vfs.nfsd.server_min_nfsvers=4 > It could also be used by /etc/rc.d/mountd to indicate "don't force rpcbind". Have fun with it, rick > This would be exactly what I'm looking for. > > Thanks for your help! > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Sun Apr 29 21:23:55 2012 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 DFC32106564A for ; Sun, 29 Apr 2012 21:23:55 +0000 (UTC) (envelope-from rsimmons0@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8EFC38FC0A for ; Sun, 29 Apr 2012 21:23:55 +0000 (UTC) Received: by vbmv11 with SMTP id v11so2161339vbm.13 for ; Sun, 29 Apr 2012 14:23:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=TBPtd2HDc2FsVEQ5ga1bRyebigBaVIopG9tF3NajrQ4=; b=BqJZmlbUpdSKMAUtDmqPvFglE0aWcUPUx90ToiKMmBWyhJhrkQNej6LrV6iN670UHR oDgfWl6S65SrPvd4CqhcJDCy2QS3ED15UKon+lHnvdenk1r3Tz/y53DxMmBEpbSkDzYO 5Bd0w9T1MniSe/+i/AuuoOIDDlRYqOkqacfA2pRbVyRd/eoEqXokBstoCa4v3aTrqUek d7pagD+C0NzdFwOHumeXyNERTjXcHT2P4Zma3Dzo95zNrTVc1L5yf7R9ggqAzrR0nrn9 feG20ErkURfxww6ikgV4yU+FH5F8nxQeHFjqZuLVsqzp+PdSKzCjmyuZ86BCmksMefJO Yh4Q== MIME-Version: 1.0 Received: by 10.52.67.133 with SMTP id n5mr16597865vdt.124.1335734634806; Sun, 29 Apr 2012 14:23:54 -0700 (PDT) Received: by 10.52.66.239 with HTTP; Sun, 29 Apr 2012 14:23:54 -0700 (PDT) In-Reply-To: <1494135294.103829.1335731763653.JavaMail.root@erie.cs.uoguelph.ca> References: <1494135294.103829.1335731763653.JavaMail.root@erie.cs.uoguelph.ca> Date: Sun, 29 Apr 2012 17:23:54 -0400 Message-ID: From: Robert Simmons To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: NFSv4 Questions 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, 29 Apr 2012 21:23:56 -0000 On Sun, Apr 29, 2012 at 4:36 PM, Rick Macklem wrote: > Robert Simmons wrote: >> On Sun, Apr 29, 2012 at 9:09 AM, Rick Macklem >> wrote: >> > Robert Simmons wrote: >> >> I've been digging and digging to find sources to clarify the >> >> exports(5) man page with no luck. What I have read differs from >> >> what >> >> I see on my server. From the man page examples section: >> >> >> >> V4: / -sec=krb5:krb5i:krb5p -network 131.104.48 -mask 255.255.255.0 >> >> >> >> Now, here is what I have put as an experiment to try to understand >> >> what's happening here (my /etc/exports): >> >> >> >> V4: / -sec=krb5 -network 192.168.1 -mask 255.255.255.0 >> >> / >> >> >> >> In this case, -sec=krb5 is totally ignored. I can mount / using >> >> sys. >> >> >> > The "-sec=krb5" restriction applies to state related operations that >> > don't >> > use file handles. >> > The FreeBSD mount doesn't do any of those, so it is the options on >> > the second line >> > "/" that control whether or not the mount succeeds. >> > >> > With the above exports, the first Open of a file should fail when >> > attempted via auth_sys, >> > at least for the FreeBSD client. (The FreeBSD client doesn't try and >> > establish >> > state via SetClientID until the first Open. Some other clients do so >> > at mount time.) >> > >> > I know this is ugly, but I thought it would be confusing to have the >> > semantics >> > of the other export lines (like "/") different for NFSv4 than >> > NFSv2,3. For NFSv2,3 >> > all RPCs involve a file handle, so they can be associated with a >> > server volume. >> > For NFSv4, this is not the case, since some state related operations >> > (SetClientID/SetClientIDConfirm/Renew and maybe a couple of others) >> > do not use >> > a file handle and, as such, can't be associated with an exported >> > volume. I put >> > the options in the "V4:" for those, since I couldn't think of where >> > else to put >> > them. >> >> I think a rewrite of exports(5) might help out quite a lot. >> Especially if the EXAMPLES section was scrapped entirely and replaced >> with a set of examples each one more granular in explaining one >> feature or use case instead of lumping all of it into explaining one >> huge export file. >> >> Since I'm working on setting up a pair of NFS servers with a set of >> clients, I volunteer. May I contact you offlist if I have questions? >> > Sure. However, I'd suggest that you get others to review it as well, since > I kinda know how it works and won't spot "missing bits", although I should > be able to catch most inaccuracies. > > Also, be sure to check "man nfsv4" and maybe reference it (it is currently > in the See Also list, but that might not be strong enough). Understood. >> >> If I use this: >> >> >> >> V4: / >> >> / -sec=krb5 >> >> >> >> It requires proper kerberos authentication. >> >> >> > Yep, as explained above. If you really want to restrict NFSv4 use to >> > kerberos, >> > then you should put the "-sec=krb5" on the V4: line and all lines >> > exporting >> > volumes. For example: >> > V4: / -sec=krb5 >> > / -sec=krb5 >> >> Got it. >> >> >> My next question is can I reject NFSv3/v2 clients/connections? >> >> >> > sysctl vfs.nfsd.server_min_nfsvers=4 >> >> Perfect. >> >> >> Third question is: how can I disable rpcbind? It seems that the >> >> following does not work in rc.conf: >> >> rpcbind_enable="NO" >> >> When I'm running NFSv4 rpcbind is not needed, but it seems that >> >> mountd >> >> always starts rpcbind no matter what I do: >> >> /etc/rc.d/rpcbind stop >> >> is the only way to do it, and that is only after boot, or mountd >> >> starting. >> >> _ >> > Yea, I suppose there should be a -nfsv4-only option on mountd, so it >> > knows that it only needs to do exports and doesn't need rpcbind. >> > Since you are probably the first person wanting an NFSv4 only >> > server, >> > I hadn't thought to do this. I'll put it on my "to do" list. >> >> If I may, perhaps a switch in /etc/rc.conf: >> nfsv4_only="YES" >> > I might call it nfsv4_server_only, but sounds like a good suggestion. > >> This would set the -nfsv4-only switch you mention for mountd, and it >> would set vfs.nfsd.server_min_nfsvers=4 >> > It could also be used by /etc/rc.d/mountd to indicate "don't force rpcbind". > > Have fun with it, rick Another thing to note about the behavior of mountd and the instructions in nfsv4(4): The three recommended lines to add to rc.conf are: nfs_server_enable="YES" nfsv4_server_enable="YES" nfsuserd_enable="YES" With only these three, if you change something in /etc/exports and want to kick mountd to have it reread the file, you get the following error: Cannot 'restart' mountd. Set mountd_enable to YES in /etc/rc.conf or use 'onerestart' instead of 'restart'. Would there be a drawback to suggesting setting mountd_enable in man page to avoid this? In other words, is there a reason this is setup this way? From owner-freebsd-fs@FreeBSD.ORG Sun Apr 29 22:55:50 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4531D106566B for ; Sun, 29 Apr 2012 22:55:50 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id D0E648FC08 for ; Sun, 29 Apr 2012 22:55:49 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAMrGnU+DaFvO/2dsb2JhbABEhWitOIIJAQEBBAEBASArIAsFFg4KAgINGQIpAQkmBggHBAEcBIdsC6Z+kX+BL4ldhH6BGASTT4IvgRGPMYMEgUA X-IronPort-AV: E=Sophos;i="4.75,502,1330923600"; d="scan'208";a="167153896" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 29 Apr 2012 18:55:32 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 5303BB3EB3; Sun, 29 Apr 2012 18:55:32 -0400 (EDT) Date: Sun, 29 Apr 2012 18:55:32 -0400 (EDT) From: Rick Macklem To: Robert Simmons Message-ID: <393972009.105652.1335740132289.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-fs@freebsd.org Subject: Re: NFSv4 Questions 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, 29 Apr 2012 22:55:50 -0000 Robert Simmons wrote: > On Sun, Apr 29, 2012 at 4:36 PM, Rick Macklem > wrote: > > Robert Simmons wrote: > >> On Sun, Apr 29, 2012 at 9:09 AM, Rick Macklem > >> > >> wrote: > >> > Robert Simmons wrote: > >> >> I've been digging and digging to find sources to clarify the > >> >> exports(5) man page with no luck. What I have read differs from > >> >> what > >> >> I see on my server. From the man page examples section: > >> >> > >> >> V4: / -sec=krb5:krb5i:krb5p -network 131.104.48 -mask > >> >> 255.255.255.0 > >> >> > >> >> Now, here is what I have put as an experiment to try to > >> >> understand > >> >> what's happening here (my /etc/exports): > >> >> > >> >> V4: / -sec=krb5 -network 192.168.1 -mask 255.255.255.0 > >> >> / > >> >> > >> >> In this case, -sec=krb5 is totally ignored. I can mount / using > >> >> sys. > >> >> > >> > The "-sec=krb5" restriction applies to state related operations > >> > that > >> > don't > >> > use file handles. > >> > The FreeBSD mount doesn't do any of those, so it is the options > >> > on > >> > the second line > >> > "/" that control whether or not the mount succeeds. > >> > > >> > With the above exports, the first Open of a file should fail when > >> > attempted via auth_sys, > >> > at least for the FreeBSD client. (The FreeBSD client doesn't try > >> > and > >> > establish > >> > state via SetClientID until the first Open. Some other clients do > >> > so > >> > at mount time.) > >> > > >> > I know this is ugly, but I thought it would be confusing to have > >> > the > >> > semantics > >> > of the other export lines (like "/") different for NFSv4 than > >> > NFSv2,3. For NFSv2,3 > >> > all RPCs involve a file handle, so they can be associated with a > >> > server volume. > >> > For NFSv4, this is not the case, since some state related > >> > operations > >> > (SetClientID/SetClientIDConfirm/Renew and maybe a couple of > >> > others) > >> > do not use > >> > a file handle and, as such, can't be associated with an exported > >> > volume. I put > >> > the options in the "V4:" for those, since I couldn't think of > >> > where > >> > else to put > >> > them. > >> > >> I think a rewrite of exports(5) might help out quite a lot. > >> Especially if the EXAMPLES section was scrapped entirely and > >> replaced > >> with a set of examples each one more granular in explaining one > >> feature or use case instead of lumping all of it into explaining > >> one > >> huge export file. > >> > >> Since I'm working on setting up a pair of NFS servers with a set of > >> clients, I volunteer. May I contact you offlist if I have > >> questions? > >> > > Sure. However, I'd suggest that you get others to review it as well, > > since > > I kinda know how it works and won't spot "missing bits", although I > > should > > be able to catch most inaccuracies. > > > > Also, be sure to check "man nfsv4" and maybe reference it (it is > > currently > > in the See Also list, but that might not be strong enough). > > Understood. > > >> >> If I use this: > >> >> > >> >> V4: / > >> >> / -sec=krb5 > >> >> > >> >> It requires proper kerberos authentication. > >> >> > >> > Yep, as explained above. If you really want to restrict NFSv4 use > >> > to > >> > kerberos, > >> > then you should put the "-sec=krb5" on the V4: line and all lines > >> > exporting > >> > volumes. For example: > >> > V4: / -sec=krb5 > >> > / -sec=krb5 > >> > >> Got it. > >> > >> >> My next question is can I reject NFSv3/v2 clients/connections? > >> >> > >> > sysctl vfs.nfsd.server_min_nfsvers=4 > >> > >> Perfect. > >> > >> >> Third question is: how can I disable rpcbind? It seems that the > >> >> following does not work in rc.conf: > >> >> rpcbind_enable="NO" > >> >> When I'm running NFSv4 rpcbind is not needed, but it seems that > >> >> mountd > >> >> always starts rpcbind no matter what I do: > >> >> /etc/rc.d/rpcbind stop > >> >> is the only way to do it, and that is only after boot, or mountd > >> >> starting. > >> >> _ > >> > Yea, I suppose there should be a -nfsv4-only option on mountd, so > >> > it > >> > knows that it only needs to do exports and doesn't need rpcbind. > >> > Since you are probably the first person wanting an NFSv4 only > >> > server, > >> > I hadn't thought to do this. I'll put it on my "to do" list. > >> > >> If I may, perhaps a switch in /etc/rc.conf: > >> nfsv4_only="YES" > >> > > I might call it nfsv4_server_only, but sounds like a good > > suggestion. > > > >> This would set the -nfsv4-only switch you mention for mountd, and > >> it > >> would set vfs.nfsd.server_min_nfsvers=4 > >> > > It could also be used by /etc/rc.d/mountd to indicate "don't force > > rpcbind". > > > > Have fun with it, rick > > Another thing to note about the behavior of mountd and the > instructions in nfsv4(4): > The three recommended lines to add to rc.conf are: > nfs_server_enable="YES" > nfsv4_server_enable="YES" > nfsuserd_enable="YES" > > With only these three, if you change something in /etc/exports and > want to kick mountd to have it reread the file, you get the following > error: > Cannot 'restart' mountd. Set mountd_enable to YES in /etc/rc.conf or > use 'onerestart' instead of 'restart'. > > Would there be a drawback to suggesting setting mountd_enable in man > page to avoid this? In other words, is there a reason this is setup > this way? Nope. Adding mountd_enable="YES" would be fine, as far as I know. (I never use the scripts to kill/restart stuff.) rick > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Mon Apr 30 06:40:26 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DFBE510657AC for ; Mon, 30 Apr 2012 06:40:26 +0000 (UTC) (envelope-from petri@helenius.fi) Received: from mail.secroom.net (r083.secroom.net [193.19.137.83]) by mx1.freebsd.org (Postfix) with ESMTP id 98B878FC16 for ; Mon, 30 Apr 2012 06:40:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.secroom.net (Postfix) with ESMTP id E41695C2D for ; Mon, 30 Apr 2012 06:40:25 +0000 (UTC) X-Virus-Scanned: amavisd-new at example.com Received: from mail.secroom.net ([127.0.0.1]) by localhost (mail.secroom.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGGQnIQijxCb for ; Mon, 30 Apr 2012 06:40:17 +0000 (UTC) Received: from d194.helenius.fi (d194.helenius.fi [83.150.107.194]) (Authenticated sender: pete) by mail.secroom.net (Postfix) with ESMTPA id 4E75C5C21 for ; Mon, 30 Apr 2012 06:40:17 +0000 (UTC) From: Petri Helenius Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Apr 2012 09:40:20 +0300 Message-Id: <3FE72032-900E-4AB3-9210-D69DC70EEE3B@helenius.fi> To: freebsd-fs@freebsd.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: Kernel panic with bad zpool.cache 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, 30 Apr 2012 06:40:27 -0000 Hi, If the system is booted with bad zpool.cache (in this case having 5 = instead of the 10 disks), is it supposed to degrade gracefully or panic = and go into reboot loop as it did? (just asking before filing a PR) Pete From owner-freebsd-fs@FreeBSD.ORG Mon Apr 30 07:04:31 2012 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 2A466106564A; Mon, 30 Apr 2012 07:04:31 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 3E62A8FC0A; Mon, 30 Apr 2012 07:04:30 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA03219; Mon, 30 Apr 2012 10:04:20 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SOkei-000Ift-3j; Mon, 30 Apr 2012 10:04:20 +0300 Message-ID: <4F9E3971.7090405@FreeBSD.org> Date: Mon, 30 Apr 2012 10:04:17 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120425 Thunderbird/12.0 MIME-Version: 1.0 To: Marius Strobl References: <4F8999D2.1080902@FreeBSD.org> <20120422212102.GA66855@alchemy.franken.de> <4F9A6180.8090500@FreeBSD.org> <20120429164623.GG68446@alchemy.franken.de> In-Reply-To: <20120429164623.GG68446@alchemy.franken.de> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool 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, 30 Apr 2012 07:04:31 -0000 on 29/04/2012 19:46 Marius Strobl said the following: > Given that you certainly have a well better knowledge of ZFS, it > would be great if we could do it the other way around, i.e. commit > the sparc64 support first and then your patch after adapting > whatever you have in mind with things becoming different. In other > words, I'm basically ready to commit the following patch. As for > zfs_dev_init() this just wraps it in #if defined(__amd64__) || > defined(__i386__) in zfs.c for now. > http://people.freebsd.org/~marius/boot_zfs_sparc64.diff OK, let's do it this way. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Mon Apr 30 07:51:30 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3FE43106566B; Mon, 30 Apr 2012 07:51:30 +0000 (UTC) (envelope-from araujo@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 13D828FC18; Mon, 30 Apr 2012 07:51:30 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q3U7pTAi070504; Mon, 30 Apr 2012 07:51:29 GMT (envelope-from araujo@freefall.freebsd.org) Received: (from araujo@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3U7pT1X070495; Mon, 30 Apr 2012 07:51:29 GMT (envelope-from araujo) Date: Mon, 30 Apr 2012 07:51:29 GMT Message-Id: <201204300751.q3U7pT1X070495@freefall.freebsd.org> To: araujo@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: araujo@FreeBSD.org Cc: Subject: Re: kern/167447: zfs rename with forced options to unmount. 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, 30 Apr 2012 07:51:30 -0000 Synopsis: zfs rename with forced options to unmount. Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: araujo Responsible-Changed-When: Mon Apr 30 07:51:29 UTC 2012 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=167447 From owner-freebsd-fs@FreeBSD.ORG Mon Apr 30 11:07:29 2012 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 1663A1065673 for ; Mon, 30 Apr 2012 11:07:29 +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 F2F698FC21 for ; Mon, 30 Apr 2012 11:07:28 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q3UB7S6X053869 for ; Mon, 30 Apr 2012 11:07:28 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3UB7SJB053867 for freebsd-fs@FreeBSD.org; Mon, 30 Apr 2012 11:07:28 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 30 Apr 2012 11:07:28 GMT Message-Id: <201204301107.q3UB7SJB053867@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, 30 Apr 2012 11:07:29 -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 kern/167447 fs zfs rename -f to perform force unmount. o kern/167370 fs [ZFS] - Unnecessary break point on zfs_main.c. o kern/167272 fs [zfs] ZFS Disks reordering causes ZFS to pick the wron o kern/167266 fs [zfs] [nfs] ZFS + new NFS export (sharenfs) leads to N o kern/167260 fs [msdosfs] msdosfs disk was mounted the second time whe o kern/167109 fs [zfs] [panic] zfs diff kernel panic Fatal trap 9: gene o kern/167105 fs [nfs] mount_nfs can not handle source exports wiht mor o kern/167067 fs [zfs] [panic] ZFS panics the server o kern/167066 fs [zfs] ZVOLs not appearing in /dev/zvol o kern/167065 fs [zfs] boot fails when a spare is the boot disk o kern/167048 fs [nfs] [patch] RELEASE-9 crash when using ZFS+NULLFS+NF o kern/166912 fs [ufs] [panic] Panic after converting Softupdates to jo o kern/166851 fs [zfs] [hang] Copying directory from the mounted UFS di o kern/166566 fs [zfs] zfs split renders 2 disk (MBR based) mirror unbo o kern/166477 fs [nfs] NFS data corruption. o kern/165950 fs [ffs] SU+J and fsck problem o kern/165923 fs [nfs] Writing to NFS-backed mmapped files fails if flu o kern/165521 fs [zfs] [hang] livelock on 1 Gig of RAM with zfs when 31 o kern/165392 fs Multiple mkdir/rmdir fails with errno 31 o kern/165087 fs [unionfs] lock violation in unionfs o kern/164472 fs [ufs] fsck -B panics on particular data inconsistency o kern/164370 fs [zfs] zfs destroy for snapshot fails on i386 and sparc o kern/164261 fs [nullfs] [patch] fix panic with NFS served from NULLFS o kern/164256 fs [zfs] device entry for volume is not created after zfs o kern/164184 fs [ufs] [panic] Kernel panic with ufs_makeinode o kern/163801 fs [md] [request] allow mfsBSD legacy installed in 'swap' o kern/163770 fs [zfs] [hang] LOR between zfs&syncer + vnlru leading to o kern/163501 fs [nfs] NFS exporting a dir and a subdir in that dir to o kern/162944 fs [coda] Coda file system module looks broken in 9.0 o kern/162860 fs [zfs] Cannot share ZFS filesystem to hosts with a hyph o kern/162751 fs [zfs] [panic] kernel panics during file operations o kern/162591 fs [nullfs] cross-filesystem nullfs does not work as expe o kern/162519 fs [zfs] "zpool import" relies on buggy realpath() behavi o kern/162362 fs [snapshots] [panic] ufs with snapshot(s) panics when g o kern/162083 fs [zfs] [panic] zfs unmount -f pool o kern/161968 fs [zfs] [hang] renaming snapshot with -r including a zvo o kern/161897 fs [zfs] [patch] zfs partition probing causing long delay o kern/161864 fs [ufs] removing journaling from UFS partition fails on o bin/161807 fs [patch] add option for explicitly specifying metadata o kern/161579 fs [smbfs] FreeBSD sometimes panics when an smb share is o kern/161533 fs [zfs] [panic] zfs receive panic: system ioctl returnin o kern/161511 fs [unionfs] Filesystem deadlocks when using multiple uni o kern/161438 fs [zfs] [panic] recursed on non-recursive spa_namespace_ o kern/161424 fs [nullfs] __getcwd() calls fail when used on nullfs mou o kern/161280 fs [zfs] Stack overflow in gptzfsboot o kern/161205 fs [nfs] [pfsync] [regression] [build] Bug report freebsd o kern/161169 fs [zfs] [panic] ZFS causes kernel panic in dbuf_dirty o kern/161112 fs [ufs] [lor] filesystem LOR in FreeBSD 9.0-BETA3 o kern/160893 fs [zfs] [panic] 9.0-BETA2 kernel panic o kern/160860 fs [ufs] Random UFS root filesystem corruption with SU+J o kern/160801 fs [zfs] zfsboot on 8.2-RELEASE fails to boot from root-o o kern/160790 fs [fusefs] [panic] VPUTX: negative ref count with FUSE o kern/160777 fs [zfs] [hang] RAID-Z3 causes fatal hang upon scrub/impo o kern/160706 fs [zfs] zfs bootloader fails when a non-root vdev exists o kern/160591 fs [zfs] Fail to boot on zfs root with degraded raidz2 [r o kern/160410 fs [smbfs] [hang] smbfs hangs when transferring large fil o kern/160283 fs [zfs] [patch] 'zfs list' does abort in make_dataset_ha o kern/159930 fs [ufs] [panic] kernel core o kern/159402 fs [zfs][loader] symlinks cause I/O errors o kern/159357 fs [zfs] ZFS MAXNAMELEN macro has confusing name (off-by- o kern/159356 fs [zfs] [patch] ZFS NAME_ERR_DISKLIKE check is Solaris-s o kern/159351 fs [nfs] [patch] - divide by zero in mountnfs() o kern/159251 fs [zfs] [request]: add FLETCHER4 as DEDUP hash option o kern/159077 fs [zfs] Can't cd .. with latest zfs version o kern/159048 fs [smbfs] smb mount corrupts large files o kern/159045 fs [zfs] [hang] ZFS scrub freezes system o kern/158839 fs [zfs] ZFS Bootloader Fails if there is a Dead Disk o kern/158802 fs amd(8) ICMP storm and unkillable process. o kern/158231 fs [nullfs] panic on unmounting nullfs mounted over ufs o f kern/157929 fs [nfs] NFS slow read o kern/157399 fs [zfs] trouble with: mdconfig force delete && zfs strip o kern/157179 fs [zfs] zfs/dbuf.c: panic: solaris assert: arc_buf_remov o kern/156797 fs [zfs] [panic] Double panic with FreeBSD 9-CURRENT and o kern/156781 fs [zfs] zfs is losing the snapshot directory, p kern/156545 fs [ufs] mv could break UFS on SMP systems o kern/156193 fs [ufs] [hang] UFS snapshot hangs && deadlocks processes o kern/156039 fs [nullfs] [unionfs] nullfs + unionfs do not compose, re o kern/155615 fs [zfs] zfs v28 broken on sparc64 -current o kern/155587 fs [zfs] [panic] kernel panic with zfs p kern/155411 fs [regression] [8.2-release] [tmpfs]: mount: tmpfs : No o kern/155199 fs [ext2fs] ext3fs mounted as ext2fs gives I/O errors o bin/155104 fs [zfs][patch] use /dev prefix by default when importing o kern/154930 fs [zfs] cannot delete/unlink file from full volume -> EN o kern/154828 fs [msdosfs] Unable to create directories on external USB o kern/154491 fs [smbfs] smb_co_lock: recursive lock for object 1 p kern/154228 fs [md] md getting stuck in wdrain state o kern/153996 fs [zfs] zfs root mount error while kernel is not located o kern/153753 fs [zfs] ZFS v15 - grammatical error when attempting to u o kern/153716 fs [zfs] zpool scrub time remaining is incorrect o kern/153695 fs [patch] [zfs] Booting from zpool created on 4k-sector o kern/153680 fs [xfs] 8.1 failing to mount XFS partitions o kern/153520 fs [zfs] Boot from GPT ZFS root on HP BL460c G1 unstable o kern/153418 fs [zfs] [panic] Kernel Panic occurred writing to zfs vol o kern/153351 fs [zfs] locking directories/files in ZFS o bin/153258 fs [patch][zfs] creating ZVOLs requires `refreservation' s kern/153173 fs [zfs] booting from a gzip-compressed dataset doesn't w o kern/153126 fs [zfs] vdev failure, zpool=peegel type=vdev.too_small o kern/152022 fs [nfs] nfs service hangs with linux client [regression] o kern/151942 fs [zfs] panic during ls(1) zfs snapshot directory o kern/151905 fs [zfs] page fault under load in /sbin/zfs o bin/151713 fs [patch] Bug in growfs(8) with respect to 32-bit overfl o kern/151648 fs [zfs] disk wait bug o kern/151629 fs [fs] [patch] Skip empty directory entries during name o kern/151330 fs [zfs] will unshare all zfs filesystem after execute a o kern/151326 fs [nfs] nfs exports fail if netgroups contain duplicate o kern/151251 fs [ufs] Can not create files on filesystem with heavy us o kern/151226 fs [zfs] can't delete zfs snapshot o kern/151111 fs [zfs] vnodes leakage during zfs unmount o kern/150503 fs [zfs] ZFS disks are UNAVAIL and corrupted after reboot o kern/150501 fs [zfs] ZFS vdev failure vdev.bad_label on amd64 o kern/150390 fs [zfs] zfs deadlock when arcmsr reports drive faulted o kern/150336 fs [nfs] mountd/nfsd became confused; refused to reload n o kern/149208 fs mksnap_ffs(8) hang/deadlock o kern/149173 fs [patch] [zfs] make OpenSolaris installa o kern/149015 fs [zfs] [patch] misc fixes for ZFS code to build on Glib o kern/149014 fs [zfs] [patch] declarations in ZFS libraries/utilities o kern/149013 fs [zfs] [patch] make ZFS makefiles use the libraries fro o kern/148504 fs [zfs] ZFS' zpool does not allow replacing drives to be o kern/148490 fs [zfs]: zpool attach - resilver bidirectionally, and re o kern/148368 fs [zfs] ZFS hanging forever on 8.1-PRERELEASE o kern/148138 fs [zfs] zfs raidz pool commands freeze o kern/147903 fs [zfs] [panic] Kernel panics on faulty zfs device o kern/147881 fs [zfs] [patch] ZFS "sharenfs" doesn't allow different " o kern/147560 fs [zfs] [boot] Booting 8.1-PRERELEASE raidz system take o kern/147420 fs [ufs] [panic] ufs_dirbad, nullfs, jail panic (corrupt o kern/146941 fs [zfs] [panic] Kernel Double Fault - Happens constantly o kern/146786 fs [zfs] zpool import hangs with checksum errors o kern/146708 fs [ufs] [panic] Kernel panic in softdep_disk_write_compl o kern/146528 fs [zfs] Severe memory leak in ZFS on i386 o kern/146502 fs [nfs] FreeBSD 8 NFS Client Connection to Server s kern/145712 fs [zfs] cannot offline two drives in a raidz2 configurat o kern/145411 fs [xfs] [panic] Kernel panics shortly after mounting an f bin/145309 fs bsdlabel: Editing disk label invalidates the whole dev o kern/145272 fs [zfs] [panic] Panic during boot when accessing zfs on o kern/145246 fs [ufs] dirhash in 7.3 gratuitously frees hashes when it o kern/145238 fs [zfs] [panic] kernel panic on zpool clear tank o kern/145229 fs [zfs] Vast differences in ZFS ARC behavior between 8.0 o kern/145189 fs [nfs] nfsd performs abysmally under load o kern/144929 fs [ufs] [lor] vfs_bio.c + ufs_dirhash.c p kern/144447 fs [zfs] sharenfs fsunshare() & fsshare_main() non functi o kern/144416 fs [panic] Kernel panic on online filesystem optimization s kern/144415 fs [zfs] [panic] kernel panics on boot after zfs crash o kern/144234 fs [zfs] Cannot boot machine with recent gptzfsboot code o kern/143825 fs [nfs] [panic] Kernel panic on NFS client o bin/143572 fs [zfs] zpool(1): [patch] The verbose output from iostat o kern/143212 fs [nfs] NFSv4 client strange work ... o kern/143184 fs [zfs] [lor] zfs/bufwait LOR o kern/142878 fs [zfs] [vfs] lock order reversal o kern/142597 fs [ext2fs] ext2fs does not work on filesystems with real o kern/142489 fs [zfs] [lor] allproc/zfs LOR o kern/142466 fs Update 7.2 -> 8.0 on Raid 1 ends with screwed raid [re o kern/142306 fs [zfs] [panic] ZFS drive (from OSX Leopard) causes two o kern/142068 fs [ufs] BSD labels are got deleted spontaneously o kern/141897 fs [msdosfs] [panic] Kernel panic. msdofs: file name leng o kern/141463 fs [nfs] [panic] Frequent kernel panics after upgrade fro o kern/141305 fs [zfs] FreeBSD ZFS+sendfile severe performance issues ( o kern/141091 fs [patch] [nullfs] fix panics with DIAGNOSTIC enabled o kern/141086 fs [nfs] [panic] panic("nfs: bioread, not dir") on FreeBS o kern/141010 fs [zfs] "zfs scrub" fails when backed by files in UFS2 o kern/140888 fs [zfs] boot fail from zfs root while the pool resilveri o kern/140661 fs [zfs] [patch] /boot/loader fails to work on a GPT/ZFS- o kern/140640 fs [zfs] snapshot crash 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 p 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/138662 fs [panic] ffs_blkfree: freeing free block o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138202 fs mount_msdosfs(1) see only 2Gb 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 p kern/136470 fs [nfs] Cannot mount / in read-only, over NFS 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/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag 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/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/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file 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/127787 fs [lor] [ufs] Three LORs: vfslock/devfs/vfslock, ufs/vfs o bin/127270 fs fsck_msdosfs(8) may crash if BytesPerSec is zero 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 o kern/125895 fs [ffs] [panic] kernel: panic: ffs_blkfree: freeing free s kern/125738 fs [zfs] [request] SHA256 acceleration in ZFS 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/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F 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 kern/118318 fs [nfs] NFS server hangs under special circumstances o bin/118249 fs [ufs] mv(1): moving a directory changes its mtime o kern/118126 fs [nfs] [patch] Poor NFS server write performance o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N o kern/117954 fs [ufs] dirhash on very large directories blocks the mac o bin/117315 fs [smbfs] mount_smbfs(8) and related options can't mount 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 conf/116931 fs lack of fsck_cd9660 prevents mounting iso images with o kern/116583 fs [ffs] [hang] System freezes for short time when using 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 bin/107829 fs [2TB] fdisk(8): invalid boundary checking in fdisk / w o kern/106107 fs [ufs] left-over fsck_snapshot after unfinished backgro 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 s bin/97498 fs [request] newfs(8) has no option to clear the first 12 o kern/97377 fs [ntfs] [patch] syntax cleanup for ntfs_ihash.c o kern/95222 fs [cd9660] File sections on ISO9660 level 3 CDs ignored o kern/94849 fs [ufs] rename on UFS filesystem is not atomic o bin/94810 fs fsck(8) incorrectly reports 'file system marked clean' 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 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/88555 fs [panic] ffs_blkfree: freeing free frag on AMD 64 o kern/88266 fs [smbfs] smbfs does not implement UIO_NOCOPY and sendfi o bin/87966 fs [patch] newfs(8): introduce -A flag for newfs to enabl 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 bin/85494 fs fsck_ffs: unchecked use of cg_inosused macro etc. o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi o bin/74779 fs Background-fsck checks one filesystem twice and omits 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 bin/70600 fs fsck(8) throws files away when it can't grow lost+foun 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/36566 fs [smbfs] System reboot with dead smb mount and umount o bin/27687 fs fsck(8) wrapper is not properly passing options to fsc o kern/18874 fs [2TB] 32bit NFS servers export wrong negative values t 275 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Apr 30 21:07:29 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 52C54106566B for ; Mon, 30 Apr 2012 21:07:29 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by mx1.freebsd.org (Postfix) with ESMTP id DA1658FC0C for ; Mon, 30 Apr 2012 21:07:28 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-251-180.belrs5.nsw.optusnet.com.au [220.239.251.180]) by mail17.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q3UL7Kw5028258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 1 May 2012 07:07:21 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.5/8.14.4) with ESMTP id q3UL7C2j050448; Tue, 1 May 2012 07:07:12 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.5/8.14.5/Submit) id q3UL7CkK050447; Tue, 1 May 2012 07:07:12 +1000 (EST) (envelope-from peter) Date: Tue, 1 May 2012 07:07:11 +1000 From: Peter Jeremy To: freebsd-fs@freebsd.org Message-ID: <20120430210711.GA50280@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Subject: ZFS with multiple boot/root pools 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, 30 Apr 2012 21:07:29 -0000 --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I have boot/root on one ZFS pool and for recovery purposes keep a second ZFS boot/root pool in case the first one becomes unbootable. My problem is that: 1) A zpool must be imported to be bootable 2) Most ZFS root filesystems have absolute mountpoints specified 3) /etc/rc.d/zfs automounts all imported ZFS filesytems results in double mounts of various filesystems. Can anyone suggest a way to configure a zpool or set of filesystems so that they will only be mounted if the root filesystem is within the zpool. I looked at the "zfs mount -a" in /etc/rc.d/zfs but there doesn't appear to be a suitable alternative. A variant that mounted all automount filesystems within a specified list of zpools would work but doesn't exist. Any other suggestions? How do other people handle this? --=20 Peter Jeremy --tKW2IUtsqtDRztdT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk+e/v8ACgkQ/opHv/APuIcxzgCfeyI1iBHFlaTFnL+Kfg/RBxsO A/sAn33+kgwe53QIIbtWMN6f6khVb+Mj =hNw9 -----END PGP SIGNATURE----- --tKW2IUtsqtDRztdT-- From owner-freebsd-fs@FreeBSD.ORG Mon Apr 30 22:14:34 2012 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 083B8106566B for ; Mon, 30 Apr 2012 22:14:34 +0000 (UTC) (envelope-from bryan@shatow.net) Received: from secure.xzibition.com (secure.xzibition.com [173.160.118.92]) by mx1.freebsd.org (Postfix) with ESMTP id 8D1618FC0A for ; Mon, 30 Apr 2012 22:14:33 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sweb; b=hpqujM snM6XmJyAZ8XAEfB44X64SWOyrj7uho8EzJX19nxitJg1e5oTWeZu+NtbhnLSksJ kNMvK8zkgtMh858v6VvVvbs7Q4aTPVcLNAXJzeDzvA2Mf4CRnJUuog49J/tmTUcq nPtD5xPKoG8SzhqsI8dbAh7/6ifWH5RHo4yUk= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sweb; bh=z4zByR/GxzWF HPPlTkhXo0xOuytfxwfY0bcKv3ydRW4=; b=Vj0jZD8RA9MoGhTcFOuCAd+1xYOY 0ov7pvrJYpP+9kOU6Yl7T02EJKVC7o5QucW8IvGDE3s9HwWNq4vqEgGr23klNKbA zSqv0wdMy0GyFszmfS90DrzO4Yju5Q5CmxTfF2Q9/sTNcqJNt/IPnbTS0Pt5Y/y6 urEYBdDloM2nZ+g= Received: (qmail 49474 invoked from network); 30 Apr 2012 17:14:30 -0500 Received: from unknown (HELO ?192.168.0.107?) (bryan@shatow.net@74.94.87.209) by sweb.xzibition.com with ESMTPA; 30 Apr 2012 17:14:30 -0500 Message-ID: <4F9F0EC6.1060802@shatow.net> Date: Mon, 30 Apr 2012 17:14:30 -0500 From: Bryan Drewery User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Peter Jeremy References: <20120430210711.GA50280@server.vk2pj.dyndns.org> In-Reply-To: <20120430210711.GA50280@server.vk2pj.dyndns.org> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: ZFS with multiple boot/root pools 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, 30 Apr 2012 22:14:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/30/2012 04:07 PM, Peter Jeremy wrote: > I have boot/root on one ZFS pool and for recovery purposes keep a > second ZFS boot/root pool in case the first one becomes > unbootable. > > My problem is that: 1) A zpool must be imported to be bootable 2) > Most ZFS root filesystems have absolute mountpoints specified 3) > /etc/rc.d/zfs automounts all imported ZFS filesytems results in > double mounts of various filesystems. > > Can anyone suggest a way to configure a zpool or set of > filesystems so that they will only be mounted if the root > filesystem is within the zpool. > > I looked at the "zfs mount -a" in /etc/rc.d/zfs but there doesn't > appear to be a suitable alternative. A variant that mounted all > automount filesystems within a specified list of zpools would work > but doesn't exist. > > Any other suggestions? How do other people handle this? > 'zfs set canmount=noauto' on all of your non-active datasets. This will stop 'zfs mount -a' (/etc/rc.d/zfs) from mounting them. This propery is *not* inherited, so you do need to set it on *all* of them if you have set a specific mountpoint. There's also a port sysutils/beadm for managing multiple boot environments. Support for having children datasets in the environment is still a work in progress. See also: http://forums.freebsd.org/showthread.php?t=31662 Regards, Bryan Drewery -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPnw7DAAoJEG54KsA8mwz5C4gP/1++l+ZvCnCAP8aeSDisCwy+ 8iJCTmt3ClIu2MD9ZC3Zow+vuz8R6ykjNK+wCmLNLQJ7NP0HF+tPqZWapXLPMiA+ pcke5Y6gjW3KfhoYgcjZxuKLKo+NMCa1wNCcfymratPg9JomD7/d7ULKDLaZLuFv vUcfWw59+d8yMPA6gamW+V9mVt1RlEwI2PLttwbfbw/fj3khdfAtAVYvjG2MztLQ 3vk6Y9WJ4NwU2gQ9XU1vKJ9xQY2TdSnZFEimMSgT4LIHbFk65CgW3NB87gu7JLn4 +ZVc5Ymsbf/2iABbRMzsutBSbllnVmAx20cJ2lFxMeNy+pgp2QBcM9cSiigzXF2t T+rsjhQh5+wV/60rx532uncs81arCg/ZQOEiub/BtfD5LQuezlqmDUnPIgaUmANn VAXPkVZ3x0ZXfzRxBI35Q4QecH+8j5gJJauEyAKLqMwKGJx7K+3gx4dUdERADE77 b/fBCW05XBTX8/drAwG+K2Qmp8rTCyv2VTgnbh2/VWbiBrHRVqfQVKB4bssb2r5r yk1PYroaCm4wBwrWfIOQzKdudR0D9B7sS26coK4E+8w+z5wh8QSIv5eoaQ0tHLLM 8cM9MNrrKQDSmeqQoikhlLwCeREIcxEVy5yU3IXaNWF0jfc9qVFwXmL1JM8GO05A 43g28SxOHZsy9SN299Oj =fqrH -----END PGP SIGNATURE----- From owner-freebsd-fs@FreeBSD.ORG Tue May 1 00:39:57 2012 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 4A0E0106564A for ; Tue, 1 May 2012 00:39:57 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from fallbackmx09.syd.optusnet.com.au (fallbackmx09.syd.optusnet.com.au [211.29.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id CB2CA8FC14 for ; Tue, 1 May 2012 00:39:56 +0000 (UTC) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by fallbackmx09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q410dnhJ000779 for ; Tue, 1 May 2012 10:39:49 +1000 Received: from server.vk2pj.dyndns.org (c220-239-251-180.belrs5.nsw.optusnet.com.au [220.239.251.180]) by mail12.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q410dcOO029708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 May 2012 10:39:41 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.5/8.14.4) with ESMTP id q410db0X072442; Tue, 1 May 2012 10:39:37 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.5/8.14.5/Submit) id q410dbgi072441; Tue, 1 May 2012 10:39:37 +1000 (EST) (envelope-from peter) Date: Tue, 1 May 2012 10:39:37 +1000 From: Peter Jeremy To: Bryan Drewery Message-ID: <20120501003937.GB53691@server.vk2pj.dyndns.org> References: <20120430210711.GA50280@server.vk2pj.dyndns.org> <4F9F0EC6.1060802@shatow.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9amGYk9869ThD9tj" Content-Disposition: inline In-Reply-To: <4F9F0EC6.1060802@shatow.net> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: ZFS with multiple boot/root pools 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, 01 May 2012 00:39:57 -0000 --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Apr-30 17:14:30 -0500, Bryan Drewery wrote: >On 04/30/2012 04:07 PM, Peter Jeremy wrote: >> I have boot/root on one ZFS pool and for recovery purposes keep a=20 >> second ZFS boot/root pool in case the first one becomes >> unbootable. =2E.. >'zfs set canmount=3Dnoauto' on all of your non-active datasets. This >will stop 'zfs mount -a' (/etc/rc.d/zfs) from mounting them. That's OK for preventing filesystems on the secondary boot pool from auto-mounting when booting from the primary pool but doesn't handle booting from the secondary pool - a "zfs mount -a" there will automount all the primary filesystems instead of the wanted secondary ones. That said, this does appear to be the closest to a usable workaround at this time. >There's also a port sysutils/beadm for managing multiple boot >environments. I've noted that there's work being done on boot environments. Whilst this is welcome, it is orthogonal to having multiple boot pools. In particular, boot environments don't handle the situation where [gpt]zfsboot refuses to load the kernel. Whilst there have been some improvements to the ZFS bootloader, it is still unable to handle all ZFS fragmentation results - in which case you need an alternative boot pool. --=20 Peter Jeremy --9amGYk9869ThD9tj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk+fMMkACgkQ/opHv/APuIeAzACgi+WljwQzE+PnJFQ+F1PRiypf TAAAn1Icf74ah/7urKGP+cRs4uAU2JPO =X+5E -----END PGP SIGNATURE----- --9amGYk9869ThD9tj-- From owner-freebsd-fs@FreeBSD.ORG Tue May 1 04:02:16 2012 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 5D9D01065672 for ; Tue, 1 May 2012 04:02:16 +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 1CCC38FC08 for ; Tue, 1 May 2012 04:02:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.jrv.org (Postfix) with ESMTP id C35A56D608F; Mon, 30 Apr 2012 22:46:18 -0500 (CDT) X-Virus-Scanned: amavisd-new at zimbra.housenet.jrv Received: from mail.jrv.org ([127.0.0.1]) by localhost (zimbra.housenet.jrv [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Czy9CW5SdSpi; Mon, 30 Apr 2012 22:46:07 -0500 (CDT) Received: from [10.0.2.15] (adsl-70-243-84-14.dsl.austtx.swbell.net [70.243.84.14]) by mail.jrv.org (Postfix) with ESMTPSA id 407E16D6086; Mon, 30 Apr 2012 22:46:07 -0500 (CDT) Message-ID: <4F9F5C76.3030106@jrv.org> Date: Mon, 30 Apr 2012 22:45:58 -0500 From: "James R. Van Artsdalen" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2.28) Gecko/20120306 Lightning/1.0b2 Thunderbird/3.1.20 MIME-Version: 1.0 To: Peter Jeremy References: <20120430210711.GA50280@server.vk2pj.dyndns.org> <4F9F0EC6.1060802@shatow.net> <20120501003937.GB53691@server.vk2pj.dyndns.org> In-Reply-To: <20120501003937.GB53691@server.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: ZFS with multiple boot/root pools 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, 01 May 2012 04:02:16 -0000 On 4/30/2012 7:39 PM, Peter Jeremy wrote: > That's OK for preventing filesystems on the secondary boot pool from > auto-mounting when booting from the primary pool but doesn't handle > booting from the secondary pool - a "zfs mount -a" there will > automount all the primary filesystems instead of the wanted secondary > ones. Don't do "zfs mount -a" from the secondary pool. Put "zfs_enable=NO" in /etc/rc.conf there, set each filesystem in the second pool to mountpoint=legacy, and list each secondary filesystem in /etc/fstab in the secondary pool. When booting the secondary pool no filesystems are automounted so the main pool is not a problem in that environment. When booting the main pool no filesystem from the secondary pool is automounted since all of those have mountpoint=legacy. I always use /boot from the secondary pool and select environments by setting 'vfs.root.mountfrom="zfs:POOL/ROOTFS"' in /boot/loader.conf on the secondary pool. That's OK since the secondary pool easily rebuilt if necessary and it solves the problem of booting my main pool. The main pool is many disks in RAIDZ vdevs and the BIOS cannot address them all for booting. But the secondary pool is a single MIRROR vdev and one dev in that vdev is on the hosts' standard SATA connector and can always be entirely read via INT 13h. From owner-freebsd-fs@FreeBSD.ORG Tue May 1 04:11:18 2012 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 93889106566B; Tue, 1 May 2012 04:11:18 +0000 (UTC) (envelope-from araujo@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 66B638FC08; Tue, 1 May 2012 04:11:18 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q414BIpN019660; Tue, 1 May 2012 04:11:18 GMT (envelope-from araujo@freefall.freebsd.org) Received: (from araujo@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q414BIIY019651; Tue, 1 May 2012 04:11:18 GMT (envelope-from araujo) Date: Tue, 1 May 2012 04:11:18 GMT Message-Id: <201205010411.q414BIIY019651@freefall.freebsd.org> To: araujo@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: araujo@FreeBSD.org Cc: Subject: Re: kern/167467: [ZFS] improve zdb(8) manpage and 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: Tue, 01 May 2012 04:11:18 -0000 Synopsis: [ZFS] improve zdb(8) manpage and help. Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: araujo Responsible-Changed-When: Tue May 1 04:11:17 UTC 2012 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=167467 From owner-freebsd-fs@FreeBSD.ORG Tue May 1 04:50:13 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 68B38106564A for ; Tue, 1 May 2012 04:50:13 +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 533338FC12 for ; Tue, 1 May 2012 04:50:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q414oD2l052572 for ; Tue, 1 May 2012 04:50:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q414oD6C052571; Tue, 1 May 2012 04:50:13 GMT (envelope-from gnats) Date: Tue, 1 May 2012 04:50:13 GMT Message-Id: <201205010450.q414oD6C052571@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Garrett Wollman Cc: Subject: Re: kern/167467: [ZFS] improve zdb(8) manpage and help. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Garrett Wollman List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 04:50:13 -0000 The following reply was made to PR kern/167467; it has been noted by GNATS. From: Garrett Wollman To: araujo@freebsd.org Cc: freebsd-gnats-submit@freebsd.org Subject: Re: kern/167467: [ZFS] improve zdb(8) manpage and help. Date: Tue, 1 May 2012 00:47:17 -0400 (EDT) In article you write: >-.Ar pool >+\fBzdb\fR [-CumdibcsDvhLXFPA] [-e [-p \fIpath\fR...]] [-t \fItxg\fR] >+ \fIpoolname\fR [\fIobject\fR ...] >+ >+.P Please don't mix doc macros and non-semantic troff markup. Either convert the whole page to hideous man macros, explicit font changes, and all the rest, or do it properly. -GAWollman From owner-freebsd-fs@FreeBSD.ORG Tue May 1 04:58:19 2012 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 44096106564A; Tue, 1 May 2012 04:58:19 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id EDFB48FC12; Tue, 1 May 2012 04:58:18 +0000 (UTC) Received: by iahk25 with SMTP id k25so7058324iah.13 for ; Mon, 30 Apr 2012 21:58:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ImDxj8II2+OBHZdKFGEKZn+jmpewU1tx5eLuAxDku8M=; b=r4/FQ3ozsPDVHwmexHNoPyQWUvr2RQYAjoiF++6O4Wmo0Jhqk0zAiMoT/tCP4NmOAE 41mgzD2UKYyq+BDHMdmIp08hMZD30ISxP/G8HVhVh72qNWe/gxinVUFOa/VnFFxQ7tzh UTkyoMh7elF8sqs0X5LUt3Hd201ZiaNfVqEGn6hfDtA7ckoWmVdFH72XxVKoXmYsto2n k7wX9tMhAIudarrm/lyhRtHycP/gVEH1LEK0yz1empCJnEWIVug/7XuT6wwnYgC57Y8W dV1zTPCvdvqk3KJiwsdljNL8Y+MqwPte0DlqvcS/H6Jn7md8ZqOmAwlf194WojK+NTm/ FSlQ== MIME-Version: 1.0 Received: by 10.42.122.76 with SMTP id m12mr5192731icr.38.1335848298157; Mon, 30 Apr 2012 21:58:18 -0700 (PDT) Received: by 10.231.170.68 with HTTP; Mon, 30 Apr 2012 21:58:18 -0700 (PDT) In-Reply-To: <201205010447.q414lHSi045448@hergotha.csail.mit.edu> References: <201205010447.q414lHSi045448@hergotha.csail.mit.edu> Date: Tue, 1 May 2012 12:58:18 +0800 Message-ID: From: Marcelo Araujo To: Garrett Wollman Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org, freebsd-gnats-submit@freebsd.org Subject: Re: kern/167467: [ZFS] improve zdb(8) manpage and help. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: araujo@FreeBSD.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 04:58:19 -0000 2012/5/1 Garrett Wollman > In article 201205010406.q4146XI7041779@red.freebsd.org> you write: > >-.Ar pool > >+\fBzdb\fR [-CumdibcsDvhLXFPA] [-e [-p \fIpath\fR...]] [-t \fItxg\fR] > >+ \fIpoolname\fR [\fIobject\fR ...] > >+ > >+.P > > Please don't mix doc macros and non-semantic troff markup. Either > convert the whole page to hideous man macros, explicit font changes, > and all the rest, or do it properly. > > -GAWollman > I=92m gonna convert it properly and send another patch, however is painful = to convert man pages to FreeBSD style. --=20 Marcelo Araujo araujo@FreeBSD.org From owner-freebsd-fs@FreeBSD.ORG Tue May 1 05:00:29 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9D5BA106566B for ; Tue, 1 May 2012 05:00:29 +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 6A44F8FC08 for ; Tue, 1 May 2012 05:00:29 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q4150TZa060817 for ; Tue, 1 May 2012 05:00:29 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q4150TUt060814; Tue, 1 May 2012 05:00:29 GMT (envelope-from gnats) Date: Tue, 1 May 2012 05:00:29 GMT Message-Id: <201205010500.q4150TUt060814@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Marcelo Araujo Cc: Subject: Re: kern/167467: [ZFS] improve zdb(8) manpage and help. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Marcelo Araujo List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 05:00:29 -0000 The following reply was made to PR kern/167467; it has been noted by GNATS. From: Marcelo Araujo To: Garrett Wollman Cc: freebsd-gnats-submit@freebsd.org, freebsd-fs@freebsd.org Subject: Re: kern/167467: [ZFS] improve zdb(8) manpage and help. Date: Tue, 1 May 2012 12:58:18 +0800 --bcaec5396b1649169a04bef26b46 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 2012/5/1 Garrett Wollman > In article 201205010406.q4146XI7041779@red.freebsd.org> you write: > >-.Ar pool > >+\fBzdb\fR [-CumdibcsDvhLXFPA] [-e [-p \fIpath\fR...]] [-t \fItxg\fR] > >+ \fIpoolname\fR [\fIobject\fR ...] > >+ > >+.P > > Please don't mix doc macros and non-semantic troff markup. Either > convert the whole page to hideous man macros, explicit font changes, > and all the rest, or do it properly. > > -GAWollman > I=92m gonna convert it properly and send another patch, however is painful = to convert man pages to FreeBSD style. --=20 Marcelo Araujo araujo@FreeBSD.org --bcaec5396b1649169a04bef26b46 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

2012/5/1 Garrett Wollman <= wollman@hergotha.csail.mit.edu>
In article <mit.lcs.mail.freebsd-bugs/201205010406.q4146XI7041779@red.freebsd.org> you write:
>-.Ar pool
>+\fBzdb\fR [-CumdibcsDvhLXFPA] [-e [-p \fIpath\fR...]] [-t \fItxg\fR] >+ =A0 =A0\fIpoolname\fR [\fIobject\fR ...]
>+
>+.P

Please don't mix doc macros and non-semantic troff markup. =A0Either convert the whole page to hideous man macros, explicit font changes,
and all the rest, or do it properly.

-GAWollman

I=92m gonna convert it properly and send another pat= ch, however is painful to convert man pages to FreeBSD style.

--
Marcelo Araujo
araujo@FreeBSD.org
--bcaec5396b1649169a04bef26b46-- From owner-freebsd-fs@FreeBSD.ORG Tue May 1 05:17:35 2012 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 D183C10664A1 for ; Tue, 1 May 2012 05:16:41 +0000 (UTC) (envelope-from clutton0@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 586BD8FC08 for ; Tue, 1 May 2012 05:16:41 +0000 (UTC) Received: by weyt57 with SMTP id t57so2814627wey.13 for ; Mon, 30 Apr 2012 22:16:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer; bh=wn46lChK6WqV5fMB+9JzZmh0fMBcMu8+ekyQk3N6Ccg=; b=VVbCGTD399XZ0qsJBZnbJY1pxqbmVkEkE7NH6NI+pVckfj6Ef/wLQ7TE8Akkf9Hm0k OO2JRGxHjVj9a2u2O/d2HHuyJPArh/j+qJeb/Dy4UYT51h22H0ccSXr+qN4lsP3ZvPuA v4khIRoYxpLUbjmOkU3rZplTaz+eM1mjzgYm9zyfsYjj0RZtReN/QrL7+ZzHx/9OQK0i 5qLwVYQ49Lf44x9y33owu9KHLm1wincWgTKpKxNbWgkoceC7fbDopNvVSzdcmrhVw/Yj DiQJ5albfvvnNvYN9sO5y4NTGgctjH1l8EebITv0Utlp6UIBqyd6bW3IWGahX7wq22DH mZKw== Received: by 10.180.79.135 with SMTP id j7mr2223663wix.19.1335849399075; Mon, 30 Apr 2012 22:16:39 -0700 (PDT) Received: from [192.168.0.2] ([46.119.33.29]) by mx.google.com with ESMTPS id w10sm53307867wiy.3.2012.04.30.22.16.37 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Apr 2012 22:16:38 -0700 (PDT) From: clutton To: Robert Simmons In-Reply-To: References: <1494135294.103829.1335731763653.JavaMail.root@erie.cs.uoguelph.ca> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-TBq+IJIXWfx87wjwlQDC" Date: Tue, 01 May 2012 08:15:29 +0300 Message-ID: <1335849329.2363.10.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-fs@freebsd.org Subject: Re: NFSv4 Questions amd 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, 01 May 2012 05:17:35 -0000 --=-TBq+IJIXWfx87wjwlQDC Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable All your thought was interesting. I also had all those problem (exports, rpcbind, sysctl). But now, I work with third version, because I need working amd(8). Does anyone has suggestion how make it work with nfsv4? On Sun, 2012-04-29 at 17:23 -0400, Robert Simmons wrote: > On Sun, Apr 29, 2012 at 4:36 PM, Rick Macklem wrot= e: > > Robert Simmons wrote: > >> On Sun, Apr 29, 2012 at 9:09 AM, Rick Macklem > >> wrote: > >> > Robert Simmons wrote: > >> >> I've been digging and digging to find sources to clarify the > >> >> exports(5) man page with no luck. What I have read differs from > >> >> what > >> >> I see on my server. From the man page examples section: > >> >> > >> >> V4: / -sec=3Dkrb5:krb5i:krb5p -network 131.104.48 -mask 255.255.255= .0 > >> >> > >> >> Now, here is what I have put as an experiment to try to understand > >> >> what's happening here (my /etc/exports): > >> >> > >> >> V4: / -sec=3Dkrb5 -network 192.168.1 -mask 255.255.255.0 > >> >> / > >> >> > >> >> In this case, -sec=3Dkrb5 is totally ignored. I can mount / using > >> >> sys. > >> >> > >> > The "-sec=3Dkrb5" restriction applies to state related operations th= at > >> > don't > >> > use file handles. > >> > The FreeBSD mount doesn't do any of those, so it is the options on > >> > the second line > >> > "/" that control whether or not the mount succeeds. > >> > > >> > With the above exports, the first Open of a file should fail when > >> > attempted via auth_sys, > >> > at least for the FreeBSD client. (The FreeBSD client doesn't try and > >> > establish > >> > state via SetClientID until the first Open. Some other clients do so > >> > at mount time.) > >> > > >> > I know this is ugly, but I thought it would be confusing to have the > >> > semantics > >> > of the other export lines (like "/") different for NFSv4 than > >> > NFSv2,3. For NFSv2,3 > >> > all RPCs involve a file handle, so they can be associated with a > >> > server volume. > >> > For NFSv4, this is not the case, since some state related operations > >> > (SetClientID/SetClientIDConfirm/Renew and maybe a couple of others) > >> > do not use > >> > a file handle and, as such, can't be associated with an exported > >> > volume. I put > >> > the options in the "V4:" for those, since I couldn't think of where > >> > else to put > >> > them. > >> > >> I think a rewrite of exports(5) might help out quite a lot. > >> Especially if the EXAMPLES section was scrapped entirely and replaced > >> with a set of examples each one more granular in explaining one > >> feature or use case instead of lumping all of it into explaining one > >> huge export file. > >> > >> Since I'm working on setting up a pair of NFS servers with a set of > >> clients, I volunteer. May I contact you offlist if I have questions? > >> > > Sure. However, I'd suggest that you get others to review it as well, si= nce > > I kinda know how it works and won't spot "missing bits", although I sho= uld > > be able to catch most inaccuracies. > > > > Also, be sure to check "man nfsv4" and maybe reference it (it is curren= tly > > in the See Also list, but that might not be strong enough). >=20 > Understood. >=20 > >> >> If I use this: > >> >> > >> >> V4: / > >> >> / -sec=3Dkrb5 > >> >> > >> >> It requires proper kerberos authentication. > >> >> > >> > Yep, as explained above. If you really want to restrict NFSv4 use to > >> > kerberos, > >> > then you should put the "-sec=3Dkrb5" on the V4: line and all lines > >> > exporting > >> > volumes. For example: > >> > V4: / -sec=3Dkrb5 > >> > / -sec=3Dkrb5 > >> > >> Got it. > >> > >> >> My next question is can I reject NFSv3/v2 clients/connections? > >> >> > >> > sysctl vfs.nfsd.server_min_nfsvers=3D4 > >> > >> Perfect. > >> > >> >> Third question is: how can I disable rpcbind? It seems that the > >> >> following does not work in rc.conf: > >> >> rpcbind_enable=3D"NO" > >> >> When I'm running NFSv4 rpcbind is not needed, but it seems that > >> >> mountd > >> >> always starts rpcbind no matter what I do: > >> >> /etc/rc.d/rpcbind stop > >> >> is the only way to do it, and that is only after boot, or mountd > >> >> starting. > >> >> _ > >> > Yea, I suppose there should be a -nfsv4-only option on mountd, so it > >> > knows that it only needs to do exports and doesn't need rpcbind. > >> > Since you are probably the first person wanting an NFSv4 only > >> > server, > >> > I hadn't thought to do this. I'll put it on my "to do" list. > >> > >> If I may, perhaps a switch in /etc/rc.conf: > >> nfsv4_only=3D"YES" > >> > > I might call it nfsv4_server_only, but sounds like a good suggestion. > > > >> This would set the -nfsv4-only switch you mention for mountd, and it > >> would set vfs.nfsd.server_min_nfsvers=3D4 > >> > > It could also be used by /etc/rc.d/mountd to indicate "don't force rpcb= ind". > > > > Have fun with it, rick >=20 > Another thing to note about the behavior of mountd and the > instructions in nfsv4(4): > The three recommended lines to add to rc.conf are: > nfs_server_enable=3D"YES" > nfsv4_server_enable=3D"YES" > nfsuserd_enable=3D"YES" >=20 > With only these three, if you change something in /etc/exports and > want to kick mountd to have it reread the file, you get the following > error: > Cannot 'restart' mountd. Set mountd_enable to YES in /etc/rc.conf or > use 'onerestart' instead of 'restart'. >=20 > Would there be a drawback to suggesting setting mountd_enable in man > page to avoid this? In other words, is there a reason this is setup > this way? > _______________________________________________ > 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" --=-TBq+IJIXWfx87wjwlQDC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAABAgAGBQJPn3FxAAoJEKC15pvo+84RGMkH+gNyjp1nEj14r04Ff/dkfbBm M+hjEXJ8p0IpcK5F7M8QOTrlB46wpLAcMZcgvUk8z05DdESmnZfZNre97j3HshWm sa2a5y75lGTvRdUaJsxlhq34ViJZpECrqSgS7JUWQGcba8EPkzBm/z7fcKbEha+M iNIF1CYLeVZunewL+4QSHNplvrNWGZQFmdz7b+ducdLHx1V9OIGWNv20j7737T2x 3Up+NdgVzWZUjls6kSRc/Of6DdinM6CGMBm0tcCg1HcsSWJFJvV7JWEt8Sm9qGAk naoOZ+HEM1I5UgErH+OdbEW2MTr9IQn+8T5dwJGfjo1HyzBE5Ntg+cu9/kA9KII= =5PXH -----END PGP SIGNATURE----- --=-TBq+IJIXWfx87wjwlQDC-- From owner-freebsd-fs@FreeBSD.ORG Tue May 1 05:17:36 2012 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 61D0B10664C5 for ; Tue, 1 May 2012 05:16:43 +0000 (UTC) (envelope-from clutton0@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id A20E48FC0C for ; Tue, 1 May 2012 05:16:42 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id t57so2814627wey.13 for ; Mon, 30 Apr 2012 22:16:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer; bh=9mGGcUB4EqXEV9v7+injTjJX7qYUshXs4jtmkFCjhvs=; b=didfuNFQzY5x6WGZghYyVO/hBEI+Dxnjxx/HC4O+MGx+9mOkeThUdlEKyGtdULHSIw 9HLqIoiTg0+p/s2lEpLuiUIrCir6jQPPNIHCO7qsgnFGNTKUZ8biIMiEu0or6CP9qHBi vQSUsuGcKV7Hyys1xV+2vGmflbQe1qSIYVhZiDZ/pYOsRR1dPSk7VeGbhJ9/KDSUFTZE 4VtIdbLUr/qjh7FVBqF7xtCYTCSJGf7oSvtO8X3vhpEc4qlJ3GtktQl6x7q2oDhyXNhx zDtjYiPtRWBybH9c+H5CLu3Bq69c3B+kFJ3cLxvuowMva23R0ocrMjjDa7VQL0RgZaf9 wK5w== Received: by 10.216.138.135 with SMTP id a7mr14563847wej.19.1335849402273; Mon, 30 Apr 2012 22:16:42 -0700 (PDT) Received: from [192.168.0.2] ([46.119.33.29]) by mx.google.com with ESMTPS id u9sm33506331wix.0.2012.04.30.22.16.40 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Apr 2012 22:16:41 -0700 (PDT) From: clutton To: Robert Simmons In-Reply-To: References: <1494135294.103829.1335731763653.JavaMail.root@erie.cs.uoguelph.ca> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-YbQfHZzraNpi6wTVKqPn" Date: Tue, 01 May 2012 08:16:29 +0300 Message-ID: <1335849389.2363.11.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-fs@freebsd.org Subject: Re: NFSv4 Questions amd 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, 01 May 2012 05:17:36 -0000 --=-YbQfHZzraNpi6wTVKqPn Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable All your thoughts were interesting. I also had all those problems (exports, rpcbind, sysctl). But now, I work with third version, because I need working amd(8). Does anyone has suggestion how make it work with nfsv4? On Sun, 2012-04-29 at 17:23 -0400, Robert Simmons wrote: > On Sun, Apr 29, 2012 at 4:36 PM, Rick Macklem wrot= e: > > Robert Simmons wrote: > >> On Sun, Apr 29, 2012 at 9:09 AM, Rick Macklem > >> wrote: > >> > Robert Simmons wrote: > >> >> I've been digging and digging to find sources to clarify the > >> >> exports(5) man page with no luck. What I have read differs from > >> >> what > >> >> I see on my server. From the man page examples section: > >> >> > >> >> V4: / -sec=3Dkrb5:krb5i:krb5p -network 131.104.48 -mask 255.255.255= .0 > >> >> > >> >> Now, here is what I have put as an experiment to try to understand > >> >> what's happening here (my /etc/exports): > >> >> > >> >> V4: / -sec=3Dkrb5 -network 192.168.1 -mask 255.255.255.0 > >> >> / > >> >> > >> >> In this case, -sec=3Dkrb5 is totally ignored. I can mount / using > >> >> sys. > >> >> > >> > The "-sec=3Dkrb5" restriction applies to state related operations th= at > >> > don't > >> > use file handles. > >> > The FreeBSD mount doesn't do any of those, so it is the options on > >> > the second line > >> > "/" that control whether or not the mount succeeds. > >> > > >> > With the above exports, the first Open of a file should fail when > >> > attempted via auth_sys, > >> > at least for the FreeBSD client. (The FreeBSD client doesn't try and > >> > establish > >> > state via SetClientID until the first Open. Some other clients do so > >> > at mount time.) > >> > > >> > I know this is ugly, but I thought it would be confusing to have the > >> > semantics > >> > of the other export lines (like "/") different for NFSv4 than > >> > NFSv2,3. For NFSv2,3 > >> > all RPCs involve a file handle, so they can be associated with a > >> > server volume. > >> > For NFSv4, this is not the case, since some state related operations > >> > (SetClientID/SetClientIDConfirm/Renew and maybe a couple of others) > >> > do not use > >> > a file handle and, as such, can't be associated with an exported > >> > volume. I put > >> > the options in the "V4:" for those, since I couldn't think of where > >> > else to put > >> > them. > >> > >> I think a rewrite of exports(5) might help out quite a lot. > >> Especially if the EXAMPLES section was scrapped entirely and replaced > >> with a set of examples each one more granular in explaining one > >> feature or use case instead of lumping all of it into explaining one > >> huge export file. > >> > >> Since I'm working on setting up a pair of NFS servers with a set of > >> clients, I volunteer. May I contact you offlist if I have questions? > >> > > Sure. However, I'd suggest that you get others to review it as well, si= nce > > I kinda know how it works and won't spot "missing bits", although I sho= uld > > be able to catch most inaccuracies. > > > > Also, be sure to check "man nfsv4" and maybe reference it (it is curren= tly > > in the See Also list, but that might not be strong enough). >=20 > Understood. >=20 > >> >> If I use this: > >> >> > >> >> V4: / > >> >> / -sec=3Dkrb5 > >> >> > >> >> It requires proper kerberos authentication. > >> >> > >> > Yep, as explained above. If you really want to restrict NFSv4 use to > >> > kerberos, > >> > then you should put the "-sec=3Dkrb5" on the V4: line and all lines > >> > exporting > >> > volumes. For example: > >> > V4: / -sec=3Dkrb5 > >> > / -sec=3Dkrb5 > >> > >> Got it. > >> > >> >> My next question is can I reject NFSv3/v2 clients/connections? > >> >> > >> > sysctl vfs.nfsd.server_min_nfsvers=3D4 > >> > >> Perfect. > >> > >> >> Third question is: how can I disable rpcbind? It seems that the > >> >> following does not work in rc.conf: > >> >> rpcbind_enable=3D"NO" > >> >> When I'm running NFSv4 rpcbind is not needed, but it seems that > >> >> mountd > >> >> always starts rpcbind no matter what I do: > >> >> /etc/rc.d/rpcbind stop > >> >> is the only way to do it, and that is only after boot, or mountd > >> >> starting. > >> >> _ > >> > Yea, I suppose there should be a -nfsv4-only option on mountd, so it > >> > knows that it only needs to do exports and doesn't need rpcbind. > >> > Since you are probably the first person wanting an NFSv4 only > >> > server, > >> > I hadn't thought to do this. I'll put it on my "to do" list. > >> > >> If I may, perhaps a switch in /etc/rc.conf: > >> nfsv4_only=3D"YES" > >> > > I might call it nfsv4_server_only, but sounds like a good suggestion. > > > >> This would set the -nfsv4-only switch you mention for mountd, and it > >> would set vfs.nfsd.server_min_nfsvers=3D4 > >> > > It could also be used by /etc/rc.d/mountd to indicate "don't force rpcb= ind". > > > > Have fun with it, rick >=20 > Another thing to note about the behavior of mountd and the > instructions in nfsv4(4): > The three recommended lines to add to rc.conf are: > nfs_server_enable=3D"YES" > nfsv4_server_enable=3D"YES" > nfsuserd_enable=3D"YES" >=20 > With only these three, if you change something in /etc/exports and > want to kick mountd to have it reread the file, you get the following > error: > Cannot 'restart' mountd. Set mountd_enable to YES in /etc/rc.conf or > use 'onerestart' instead of 'restart'. >=20 > Would there be a drawback to suggesting setting mountd_enable in man > page to avoid this? In other words, is there a reason this is setup > this way? > _______________________________________________ > 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" --=-YbQfHZzraNpi6wTVKqPn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAABAgAGBQJPn3GtAAoJEKC15pvo+84RM5AIAJXRrPRJNEpbXgZnUXStQeEJ k6wPzgEX6z5srFAi7JEc0sLVjmtnHvo/Xj+MvfyDQ1mVXTNk/bDKluiReQVRqVm3 b4Ir0fJKQ/Zd+Oh0irSkvCfufynJ5kQlttI4VhO4otSx1CRfX2pkgxMwU2kTE0We lgZahRUPvNrDwj32WHUMeGr30P+f2M0iQH2oC5npoEiLtL3rVxlExlE9K0diTZpi aK3CyNQvXsaWJ1eBn1kffTyudg5eYVnvVkc+vaCubXVpjqx2o0pbSJV3kIRjR32C NCubke0NuJYl2XQK8ZI0Y7s3WbpzCJqIBrvmxkPrepWa75WRmz0A5pl9xY+C+gM= =5CR2 -----END PGP SIGNATURE----- --=-YbQfHZzraNpi6wTVKqPn-- From owner-freebsd-fs@FreeBSD.ORG Tue May 1 06:00:30 2012 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 C512B1065670 for ; Tue, 1 May 2012 06:00:30 +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 A4D178FC18 for ; Tue, 1 May 2012 06:00:30 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q4160UMu015716 for ; Tue, 1 May 2012 06:00:30 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q4160U9r015712; Tue, 1 May 2012 06:00:30 GMT (envelope-from gnats) Date: Tue, 1 May 2012 06:00:30 GMT Message-Id: <201205010600.q4160U9r015712@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Marcelo Araujo Cc: Subject: Re: kern/167467: [ZFS] improve zdb(8) manpage and help. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Marcelo Araujo List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 06:00:30 -0000 The following reply was made to PR kern/167467; it has been noted by GNATS. From: Marcelo Araujo To: freebsd-gnats-submit@freebsd.org Cc: Subject: Re: kern/167467: [ZFS] improve zdb(8) manpage and help. Date: Tue, 1 May 2012 13:57:44 +0800 --90e6ba6e8440d6fce304bef33ff8 Content-Type: multipart/alternative; boundary=90e6ba6e8440d6fcd904bef33ff6 --90e6ba6e8440d6fcd904bef33ff6 Content-Type: text/plain; charset=ISO-8859-1 2012/5/1 Garrett Wollman > In article 201205010406.q4146XI7041779@red.freebsd.org> you write: > >-.Ar pool > >+\fBzdb\fR [-CumdibcsDvhLXFPA] [-e [-p \fIpath\fR...]] [-t \fItxg\fR] > >+ \fIpoolname\fR [\fIobject\fR ...] > >+ > >+.P > > Please don't mix doc macros and non-semantic troff markup. Either > convert the whole page to hideous man macros, explicit font changes, > and all the rest, or do it properly. > > Here is the patch without non-semantic troff markup. Use macros instead. -- Marcelo Araujo araujo@FreeBSD.org --90e6ba6e8440d6fcd904bef33ff6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2012/5/1 Garrett Wollman &= lt;woll= man@hergotha.csail.mit.edu>
In article <mit.lcs.mail.freebsd-bugs/201205010406.q4146XI7041779@red.freebsd.org> you write:
>-.Ar pool
>+\fBzdb\fR [-CumdibcsDvhLXFPA] [-e [-p \fIpath\fR...]] [-t \fItxg\fR] >+ =A0 =A0\fIpoolname\fR [\fIobject\fR ...]
>+
>+.P

Please don't mix doc macros and non-semantic troff markup. =A0Either convert the whole page to hideous man macros, explicit font changes,
and all the rest, or do it properly.




--
Marcelo Araujo
araujo@FreeBSD.org
--90e6ba6e8440d6fcd904bef33ff6-- --90e6ba6e8440d6fce304bef33ff8 Content-Type: text/plain; charset=US-ASCII; name="zdb.txt" Content-Disposition: attachment; filename="zdb.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h1ojpb7i0 ZGlmZiAtciBiNDcwYTVkYjQzMGUgY2RkbC9jb250cmliL29wZW5zb2xhcmlzL2NtZC96ZGIvemRi LjgKLS0tIGEvY2RkbC9jb250cmliL29wZW5zb2xhcmlzL2NtZC96ZGIvemRiLjgJTW9uIEFwciAz MCAwNjowMjowMCAyMDEyICswMDAwCisrKyBiL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy9jbWQv emRiL3pkYi44CU1vbiBBcHIgMzAgMTM6MjA6MzggMjAxMiArMDAwMApAQCAtMTgsNTUgKzE4LDQ3 MiBAQAogLlwiIGluZm9ybWF0aW9uOiBQb3J0aW9ucyBDb3B5cmlnaHQgW3l5eXldIFtuYW1lIG9m IGNvcHlyaWdodCBvd25lcl0KIC5cIgogLlwiIENvcHlyaWdodCAoYykgMjAwNCwgU3VuIE1pY3Jv c3lzdGVtcywgSW5jLiBBbGwgUmlnaHRzIFJlc2VydmVkLgorLlwiIENvcHlyaWdodCAyMDEyLCBS aWNoYXJkIExvd2UuCisuXCIgQ29weXJpZ2h0IChjKSAyMDEyLCBNYXJjZWxvIEFyYXVqbyA8YXJh dWpvQEZyZWVCU0Qub3JnPi4KKy5cIiBBbGwgUmlnaHRzIFJlc2VydmVkLgogLlwiCiAuXCIgJEZy ZWVCU0QkCiAuXCIKLS5EZCBOb3ZlbWJlciAyNiwgMjAxMQorLkRkIE1heSAxLCAyMDEyCiAuRHQg WkRCIDgKIC5PcwogLlNoIE5BTUUKIC5ObSB6ZGIKLS5OZCBaRlMgZGVidWdnZXIKKy5OZCBEaXNw bGF5IHpwb29sIGRlYnVnZ2luZyBhbmQgY29uc2lzdGVuY3kgaW5mb3JtYXRpb24KIC5TaCBTWU5P UFNJUwogLk5tCi0uQXIgcG9vbAorLk9wIEZsIEN1bWRpYmNzRHZoTFhGUEEKKy5PcCBGbCBlIE9w IEZsIHAgQXIgcGF0aCBPcCAtdCBBciB0eGcKKy5BciBwb29sbmFtZQorLk9wIEFyIG9iamVjdC4u LgorLlAKKworLk5tCisuT3AgRmwgZGl2UEEKKy5PcCBGbCBlIE9wIEZsIHAgQXIgcGF0aC4uLgor Wy1kaXZQQV0gWy1lIFstcCAuQXIgcGF0aC4uLl1dCisuQXIgZGF0YXNldCBPcCBBciBvYmplY3Qu Li4KKworLlAKKy5ObQorLkZsIG0gT3AgRmwgTFhGUEEgT3AgRmwgdCBBciB0eGcKKy5PcCBGbCBl IE9wIEZsIHAgQXIgcGF0aC4uLgorLkFyIHBvb2xuYW1lCisuT3AgQXIgdmRldiBPcCBBciBtZXRh c2xhYi4uLgorCisuUAorLk5tCisuRmwgUiBPcCBGbCBBCisuT3AgRmwgZSBPcCBGbCBwIEFyIHBh dGguLi4KKy5BciBwb29sbmFtZQorLkFyIHZkZXY6b2Zmc2V0OnNpemVbZmxhZ3NdCisKKy5QCisu Tm0KKy5GbCBTIE9wIEZsIEFQIAorLk9wIEZsIGUgT3AgRmwgcCBBciBwYXRoLi4uCisuQXIgcG9v bG5hbWUKKworLlAKKy5ObQorLkZsIGwKKy5PcCBGbCB1YQorLkFyIGRldmljZQorCisuUAorLk5t CisuRmwgQworLk9wIEZsIEEKKy5PcCBGbCBVIEFyIGNhY2hlCisKIC5TaCBERVNDUklQVElPTgog VGhlCi0uTm0KLWNvbW1hbmQgaXMgdXNlZCBieSBzdXBwb3J0IGVuZ2luZWVycyB0byBkaWFnbm9z ZSBmYWlsdXJlcyBhbmQKLWdhdGhlciBzdGF0aXN0aWNzLiBTaW5jZSB0aGUKLS5UbiBaRlMKLWZp bGUgc3lzdGVtIGlzIGFsd2F5cyBjb25zaXN0ZW50IG9uIGRpc2sgYW5kIGlzIHNlbGYtcmVwYWly aW5nLAotLk5tCi1zaG91bGQgb25seSBiZSBydW4gdW5kZXIgdGhlIGRpcmVjdGlvbiBieSBhIHN1 cHBvcnQgZW5naW5lZXIuCi0uUHAKLUlmIG5vIGFyZ3VtZW50cyBhcmUgc3BlY2lmaWVkLAotLk5t Ci1wZXJmb3JtcyBiYXNpYyBjb25zaXN0ZW5jeSBjaGVja3Mgb24gdGhlIHBvb2wgYW5kIGFzc29j aWF0ZWQgZGF0YXNldHMsIGFuZAotcmVwb3J0IGFueSBwcm9ibGVtcyBkZXRlY3RlZC4KLS5ObQot QW55IG9wdGlvbnMgc3VwcG9ydGVkIGJ5IHRoaXMgY29tbWFuZCBhcmUgaW50ZXJuYWwgdG8gU3Vu IGFuZCBzdWJqZWN0IHRvIGNoYW5nZQotYXQgYW55IHRpbWUuCi0uU2ggRVhJVCBTVEFUVVMKLVRo ZSBmb2xsb3dpbmcgZXhpdCB2YWx1ZXMgYXJlIHJldHVybmVkOgotLkJsIC10YWcgLW9mZnNldCAy biAtd2lkdGggMm4KLS5JdCAwCi1UaGUgcG9vbCBpcyBjb25zaXN0ZW50LgotLkl0IDEKLUFuIGVy cm9yIHdhcyBkZXRlY3RlZC4KLS5JdCAyCi1JbnZhbGlkIGNvbW1hbmQgbGluZSBvcHRpb25zIHdl cmUgc3BlY2lmaWVkLgotLkVsCisuTm0gCit1dGlsaXR5IGRpc3BsYXlzIGluZm9ybWF0aW9uIGFi b3V0IGEgWkZTIHBvb2wgdXNlZnVsIGZvcgorZGVidWdnaW5nIGFuZCBwZXJmb3JtcyBzb21lIGFt b3VudCBvZiBjb25zaXN0ZW5jeSBjaGVja2luZy4gSXQgaXMgYSBub3QgYQorZ2VuZXJhbCBwdXJw b3NlIHRvb2wgYW5kIG9wdGlvbnMgKGFuZCBmYWNpbGl0aWVzKSBtYXkgY2hhbmdlLiBUaGlzIGlz IG5laXRoZXIKK2EgZnNjaygxTSkgbm9yIGFuIGZzZGIoMU0pIHV0aWxpdHkuCisucAorVGhlIG91 dHB1dCBvZiB0aGlzIGNvbW1hbmQgaW4gZ2VuZXJhbCByZWZsZWN0cyB0aGUgb24tZGlzayBzdHJ1 Y3R1cmUgb2YgYSBaRlMKK3Bvb2wsIGFuZCBpcyBpbmhlcmVudGx5IHVuc3RhYmxlLiBUaGUgcHJl Y2lzZSBvdXRwdXQgb2YgbW9zdCBpbnZvY2F0aW9ucyBpcworbm90IGRvY3VtZW50ZWQsIGEga25v d2xlZGdlIG9mIFpGUyBpbnRlcm5hbHMgaXMgYXNzdW1lZC4KKy5wCitXaGVuIG9wZXJhdGluZyBv biBhbiBpbXBvcnRlZCBhbmQgYWN0aXZlIHBvb2wgaXQgaXMgcG9zc2libGUsIHRob3VnaCB1bmxp a2VseSwKK3RoYXQgemRiIG1heSBpbnRlcnByZXQgaW5jb25zaXN0ZW50IHBvb2wgZGF0YSBhbmQg YmVoYXZlIGVycmF0aWNhbGx5LgorLlNoIE9QVElPTlMKK0Rpc3BsYXkgb3B0aW9uczoKKy5zcAor Lm5lIDIKKy5uYQorLkZsIGIKKy5hZAorLnNwIC42CisuUlMgNG4KK0Rpc3BsYXkgc3RhdGlzdGlj cyByZWdhcmRpbmcgdGhlIG51bWJlciwgc2l6ZSAobG9naWNhbCwgcGh5c2ljYWwgYW5kCithbGxv Y2F0ZWQpIGFuZCBkZWR1cGxpY2F0aW9uIG9mIGJsb2Nrcy4KKy5SRQorLnNwCisubmUgMgorLm5h CisuRmwgYworLmFkCisuc3AgLjYKKy5SUyA0bgorVmVyaWZ5IHRoZSBjaGVja3N1bSBvZiBhbGwg bWV0YWRhdGEgYmxvY2tzIHdoaWxlIHByaW50aW5nIGJsb2NrIHN0YXRpc3RpY3MKKyhzZWUgLWIp LgorLnNwCitJZiBzcGVjaWZpZWQgbXVsdGlwbGUgdGltZXMsIHZlcmlmeSB0aGUgY2hlY2tzdW1z IG9mIGFsbCBibG9ja3MuCisuUkUKKy5zcAorLm5lIDIKKy5uYQorLkZsIEMKKy5hZAorLnNwIC42 CisuUlMgNG4KK0Rpc3BsYXkgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGNvbmZpZ3VyYXRpb24uIElm IHNwZWNpZmllZCB3aXRoIG5vIG90aGVyCitvcHRpb25zLCBpbnN0ZWFkIGRpc3BsYXkgaW5mb3Jt YXRpb24gYWJvdXQgdGhlIGNhY2hlIGZpbGUKKygvZXRjL3pmcy96cG9vbC5jYWNoZSkuIFRvIHNw ZWNpZnkgdGhlIGNhY2hlIGZpbGUgdG8gZGlzcGxheSwgc2VlCisuRmwgVQorLlAKK0lmIHNwZWNp ZmllZCBtdWx0aXBsZSB0aW1lcywgYW5kIGEgcG9vbCBuYW1lIGlzIGFsc28gc3BlY2lmaWVkIGRp c3BsYXkgYm90aAordGhlIGNhY2hlZCBjb25maWd1cmF0aW9uIGFuZCB0aGUgb24tZGlzayBjb25m aWd1cmF0aW9uLiAgSWYgc3BlY2lmaWVkIG11bHRpcGxlCit0aW1lcyB3aXRoIC1lIGFsc28gZGlz cGxheSB0aGUgY29uZmlndXJhdGlvbiB0aGF0IHdvdWxkIGJlIHVzZWQgd2VyZSB0aGUKK3Bvb2wg dG8gYmUgaW1wb3J0ZWQuCisuUkUKKy5zcAorLm5lIDIKKy5uYQorLkZsIGQKKy5hZAorLnNwIC42 CisuUlMgNG4KK0Rpc3BsYXkgaW5mb3JtYXRpb24gYWJvdXQgZGF0YXNldHMuIFNwZWNpZmllZCBv bmNlLCBkaXNwbGF5cyBiYXNpYyBkYXRhc2V0CitpbmZvcm1hdGlvbjogSUQsIGNyZWF0ZSB0cmFu c2FjdGlvbiwgc2l6ZSwgYW5kIG9iamVjdCBjb3VudC4KKy5zcAorSWYgc3BlY2lmaWVkIG11bHRp cGxlIHRpbWVzIHByb3ZpZGVzIGdyZWF0ZXIgYW5kIGdyZWF0ZXIgdmVyYm9zaXR5LgorLnNwCitJ ZiBvYmplY3QgSURzIGFyZSBzcGVjaWZpZWQsIGRpc3BsYXkgaW5mb3JtYXRpb24gYWJvdXQgdGhv c2Ugc3BlY2lmaWMgb2JqZWN0cyBvbmx5LgorLlJFCisuc3AKKy5uZSAyCisubmEKKy5GbCBECisu YWQKKy5zcCAuNgorLlJTIDRuCitEaXNwbGF5IGRlZHVwbGljYXRpb24gc3RhdGlzdGljcywgaW5j bHVkaW5nIHRoZSBkZWR1cGxpY2F0aW9uIHJhdGlvIChkZWR1cCksCitjb21wcmVzc2lvbiByYXRp byAoY29tcHJlc3MpLCBpbmZsYXRpb24gZHVlIHRvIHRoZSB6ZnMgY29waWVzIHByb3BlcnR5Ciso Y29waWVzKSwgYW5kIGFuIG92ZXJhbGwgZWZmZWN0aXZlIHJhdGlvIChkZWR1cCAqIGNvbXByZXNz IC8gY29waWVzKS4KKy5zcAorSWYgc3BlY2lmaWVkIHR3aWNlLCBkaXNwbGF5IGEgaGlzdG9ncmFt IG9mIGRlZHVwbGljYXRpb24gc3RhdGlzdGljcywgc2hvd2luZwordGhlIGFsbG9jYXRlZCAocGh5 c2ljYWxseSBwcmVzZW50IG9uIGRpc2spIGFuZCByZWZlcmVuY2VkIChsb2dpY2FsbHkKK3JlZmVy ZW5jZWQgaW4gdGhlIHBvb2wpIGJsb2NrIGNvdW50cyBhbmQgc2l6ZXMgYnkgcmVmZXJlbmNlIGNv dW50LgorLlJFCisuc3AKKy5uZSAyCisubmEKKy5GbCBoCisuYWQKKy5zcCAuNgorLlJTIDRuCitE aXNwbGF5IHBvb2wgaGlzdG9yeSBzaW1pbGFyIHRvIHpwb29sIGhpc3RvcnksIGJ1dCBpbmNsdWRl IGludGVybmFsCitjaGFuZ2VzLCB0cmFuc2FjdGlvbiwgYW5kIGRhdGFzZXQgaW5mb3JtYXRpb24u CisuUkUKKy5zcAorLm5lIDIKKy5uYQorLkZsIGkKKy5hZAorLnNwIC42CisuUlMgNG4KK0Rpc3Bs YXkgaW5mb3JtYXRpb24gYWJvdXQgaW50ZW50IGxvZyAoWklMKSBlbnRyaWVzIHJlbGF0aW5nIHRv IGVhY2gKK2RhdGFzZXQuIElmIHNwZWNpZmllZCBtdWx0aXBsZSB0aW1lcywgZGlzcGxheSBjb3Vu dHMgb2YgZWFjaCBpbnRlbnQgbG9nCit0cmFuc2FjdGlvbiB0eXBlLgorLlJFCisuc3AKKy5uZSAy CisubmEKKy5GbCBsIEFyIGRldmljZQorLmFkCisuc3AgLjYKKy5SUyA0bgorRGlzcGxheSB0aGUg dmRldiBsYWJlbHMgZnJvbSB0aGUgc3BlY2lmaWVkIGRldmljZS4gSWYgdGhlIC11IG9wdGlvbiBp cworYWxzbyBzcGVjaWZpZWQsIGFsc28gZGlzcGxheSB0aGUgdWJlcmJsb2NrcyBvbiB0aGlzIGRl dmljZS4KKy5SRQorLnNwCisubmUgMgorLm5hCisuRmwgTAorLmFkCisuc3AgLjYKKy5SUyA0bgor RGlzYWJsZSBsZWFrIHRyYWNpbmcgYW5kIHRoZSBsb2FkaW5nIG9mIHNwYWNlIG1hcHMuICBCeSBk ZWZhdWx0LCAuTm0KK3ZlcmlmaWVzIHRoYXQgYWxsIG5vbi1mcmVlIGJsb2NrcyBhcmUgcmVmZXJl bmNlZCwgd2hpY2ggY2FuIGJlIHZlcnkgZXhwZW5zaXZlLgorLlJFCisuc3AKKy5uZSAyCisubmEK Ky5GbCBtCisuYWQKKy5zcCAuNgorLlJTIDRuCitEaXNwbGF5IHRoZSBvZmZzZXQsIHNwYWNlbWFw LCBhbmQgZnJlZSBzcGFjZSBvZiBlYWNoIG1ldGFzbGFiLgorV2hlbiBzcGVjaWZpZWQgdHdpY2Us IGFsc28gZGlzcGxheSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgbWF4aW11bSBjb250aWd1b3VzCitm cmVlIHNwYWNlIGFuZCB0aGUgcGVyY2VudGFnZSBvZiBmcmVlIHNwYWNlIGluIGVhY2ggc3BhY2Ug bWFwLiAgV2hlbiBzcGVjaWZpZWQKK3RocmVlIHRpbWVzIGRpc3BsYXkgZXZlcnkgc3BhY2VtYXAg cmVjb3JkLgorLlJFCisuc3AKKy5uZSAyCisubmEKKy5GbCBSIEFyIHBvb2xuYW1lIEFyIHZkZXY6 b2Zmc2V0OnNpemVbZmxhZ3NdCisuYWQKKy5zcCAuNgorLlJTIDRuCitSZWFkIGFuZCBkaXNwbGF5 IGEgYmxvY2sgZnJvbSB0aGUgc3BlY2lmaWVkIGRldmljZS4gQnkgZGVmYXVsdCB0aGUgYmxvY2sg aXMKK2Rpc3BsYXllZCBhcyBhIGhleCBkdW1wLCBidXQgc2VlIHRoZSBkZXNjcmlwdGlvbiBvZiB0 aGUgXCdyXCcgZmxhZywgYmVsb3cuCisuc3AKK1RoZSBibG9jayBpcyBzcGVjaWZpZWQgaW4gdGVy bXMgb2YgYSBjb2xvbi1zZXBhcmF0ZWQgdHVwbGUgLkFyIHZkZXYgKGFuCitpbnRlZ2VyIHZkZXYg aWRlbnRpZmllcikgLkFyIG9mZnNldCAodGhlIG9mZnNldCB3aXRoaW4gdGhlIHZkZXYpIC5BciBz aXplCisodGhlIHNpemUgb2YgdGhlIGJsb2NrIHRvIHJlYWQpIGFuZCwgb3B0aW9uYWxseSwgLkFy IGZsYWdzIChhIHNldCBvZiBmbGFncywKK2Rlc2NyaWJlZCBiZWxvdykuCisuc3AKKy5uZSAyCisu bmEKKy5GbCBiIEFyIG9mZnNldAorLmFkCisuc3AgLjYKKy5SUyA0bgorUHJpbnQgYmxvY2sgcG9p bnRlcgorLlJFCisuc3AKKy5uZSAyCisubmEKKy5GbCBkCisuYWQKKy5zcCAuNgorLlJTIDRuCitE ZWNvbXByZXNzIHRoZSBibG9jaworLlJFCisuc3AKKy5uZSAyCisubmEKKy5GbCBlCisuYWQKKy5z cCAuNgorLlJTIDRuCitCeXRlIHN3YXAgdGhlIGJsb2NrCisuUkUKKy5zcAorLm5lIDIKKy5uYQor LkZsIGcKKy5hZAorLnNwIC42CisuUlMgNG4KK0R1bXAgZ2FuZyBibG9jayBoZWFkZXIKKy5SRQor LnNwCisubmUgMgorLm5hCisuRmwgaQorLmFkCisuc3AgLjYKKy5SUyA0bgorRHVtcCBpbmRpcmVj dCBibG9jaworLlJFCisuc3AKKy5uZSAyCisubmEKKy5GbCByCisuYWQKKy5zcCAuNgorLlJTIDRu CitEdW1wIHJhdyB1bmludGVycHJldGVkIGJsb2NrIGRhdGEKKy5SRQorLlJFCisuc3AKKy5uZSAy CisubmEKKy5GbCBzCisuYWQKKy5zcCAuNgorLlJTIDRuCitSZXBvcnQgc3RhdGlzdGljcyBvbiAu Tm1cJ3MgSS9PLiBEaXNwbGF5IG9wZXJhdGlvbiBjb3VudHMsIGJhbmR3aWR0aCwKK2FuZCBlcnJv ciBjb3VudHMgb2YgSS9PIHRvIHRoZSBwb29sIGZyb20gLk5tLgorLlJFCisuc3AKKy5uZSAyCisu bmEKKy5GbCBTCisuYWQKKy5zcCAuNgorLlJTIDRuCitTaW11bGF0ZSB0aGUgZWZmZWN0cyBvZiBk ZWR1cGxpY2F0aW9uLCBjb25zdHJ1Y3RpbmcgYSBERFQgYW5kIHRoZW4gZGlzcGxheQordGhhdCBE RFQgYXMgd2l0aCAtREQuCisuUkUKKy5zcAorLm5lIDIKKy5uYQorLkZsIHUKKy5hZAorLnNwIC42 CisuUlMgNG4KK0Rpc3BsYXkgdGhlIGN1cnJlbnQgdWJlcmJsb2NrLgorLlJFCisuUAorT3RoZXIg b3B0aW9uczoKKy5zcAorLm5lIDIKKy5uYQorLkZsIEEKKy5hZAorLnNwIC42CisuUlMgNG4KK0Rv IG5vdCBhYm9ydCBzaG91bGQgYW55IGFzc2VydGlvbiBmYWlsLgorLlJFCisuc3AKKy5uZSAyCisu bmEKKy5GbCBBQQorLmFkCisuc3AgLjYKKy5SUyA0bgorRW5hYmxlIHBhbmljIHJlY292ZXJ5LCBj ZXJ0YWluIGVycm9ycyB3aGljaCB3b3VsZCBvdGhlcndpc2UgYmUgZmF0YWwgYXJlCitkZW1vdGVk IHRvIHdhcm5pbmdzLgorLlJFCisuc3AKKy5uZSAyCisubmEKKy5GbCBBQUEKKy5hZAorLnNwIC42 CisuUlMgNG4KK0RvIG5vdCBhYm9ydCBpZiBhc3NlcnRzIGZhaWwgYW5kIGFsc28gZW5hYmxlIHBh bmljIHJlY292ZXJ5LgorLlJFCisuc3AKKy5uZSAyCisubmEKKy5GbCBlIE9wIEZsIHAgQXIgcGF0 aC4uLgorLmFkCisuc3AgLjYKKy5SUyA0bgorT3BlcmF0ZSBvbiBhbiBleHBvcnRlZCBwb29sLCBu b3QgcHJlc2VudCBpbiAvZXRjL3pmcy96cG9vbC5jYWNoZS4gVGhlCistcCBmbGFnIHNwZWNpZmll cyB0aGUgcGF0aCB1bmRlciB3aGljaCBkZXZpY2VzIGFyZSB0byBiZSBzZWFyY2hlZC4KKy5SRQor LnNwCisubmUgMgorLm5hCisuRmwgRgorLmFkCisuc3AgLjYKKy5SUyA0bgorQXR0ZW1wdCB0byBt YWtlIGFuIHVucmVhZGFibGUgcG9vbCByZWFkYWJsZSBieSB0cnlpbmcgcHJvZ3Jlc3NpdmVseSBv bGRlcgordHJhbnNhY3Rpb25zLgorLlJFCisuc3AKKy5uZSAyCisubmEKKy5GbCBQCisuYWQKKy5z cCAuNgorLlJTIDRuCitQcmludCBudW1iZXJzIGluIGFuIHVuc2NhbGVkIGZvcm0gbW9yZSBhbWVu YWJsZSB0byBwYXJzaW5nLCBlZy4gMTAwMDAwMCByYXRoZXIKK3RoYW4gMU0uCisuUkUKKy5zcAor Lm5lIDIKKy5uYQorLkZsIHQgQXIgdHJhbnNhY3Rpb24KKy5hZAorLnNwIC42CisuUlMgNG4KK1Nw ZWNpZnkgdGhlIGhpZ2hlc3QgdHJhbnNhY3Rpb24gdG8gdXNlIHdoZW4gc2VhcmNoaW5nIGZvciB1 YmVyYmxvY2tzLiBTZWUgYWxzbwordGhlIC11IGFuZCAtbCBvcHRpb25zIGZvciBhIG1lYW5zIHRv IHNlZSB0aGUgYXZhaWxhYmxlIHViZXJibG9ja3MKK2FuZCB0aGVpciBhc3NvY2lhdGVkIHRyYW5z YWN0aW9uIG51bWJlcnMuCisuUkUKKy5zcAorLm5lIDIKKy5uYQorLkZsIFUgQXIgY2FjaGVmaWxl CisuYWQKKy5zcCAuNgorLlJTIDRuCitVc2UgYSBjYWNoZSBmaWxlIG90aGVyIHRoYW4gL2V0Yy96 ZnMvenBvb2wuY2FjaGUuIFRoaXMgb3B0aW9uIGlzIG9ubHkKK3ZhbGlkIHdpdGggLUMKKy5SRQor LnNwCisubmUgMgorLm5hCisuRmwgdgorLmFkCisuc3AgLjYKKy5SUyA0bgorRW5hYmxlIHZlcmJv c2l0eS4gU3BlY2lmeSBtdWx0aXBsZSB0aW1lcyBmb3IgaW5jcmVhc2VkIHZlcmJvc2l0eS4KKy5S RQorLnNwCisubmUgMgorLm5hCisuRmwgWAorLmFkCisuc3AgLjYKKy5SUyA0bgorQXR0ZW1wdCBc J2V4dHJlbWVcJyB0cmFuc2FjdGlvbiByZXdpbmQsIHRoYXQgaXMgYXR0ZW1wdCB0aGUgc2FtZSBy ZWNvdmVyeSBhcworLUYgYnV0IHJlYWQgdHJhbnNhY3Rpb25zIG90aGVyd2lzZSBkZWVtZWQgdG9v IG9sZC4KKy5SRQorLlAKK1NwZWNpZnlpbmcgYSBkaXNwbGF5IG9wdGlvbiBtb3JlIHRoYW4gb25j ZSBlbmFibGVzIHZlcmJvc2l0eSBmb3Igb25seSB0aGF0CitvcHRpb24sIHdpdGggbW9yZSBvY2N1 cnJlbmNlcyBlbmFibGluZyBtb3JlIHZlcmJvc2l0eS4KKy5QCitJZiBubyBvcHRpb25zIGFyZSBz cGVjaWZpZWQsIGFsbCBpbmZvcm1hdGlvbiBhYm91dCB0aGUgbmFtZWQgcG9vbCB3aWxsIGJlCitk aXNwbGF5ZWQgYXQgZGVmYXVsdCB2ZXJib3NpdHkuCisuU2ggRVhBTVBMRVMKKy5McAorRXhhbXBs ZSAxOiBEaXNwbGF5IHRoZSBjb25maWd1cmF0aW9uIG9mIGltcG9ydGVkIHBvb2wgJ3Jwb29sJwor LnNwCisuaW4gKzIKKy5uZgorIyB6ZGIgLUMgcnBvb2wKK01PUyBDb25maWd1cmF0aW9uOgorICAg ICAgICB2ZXJzaW9uOiAyOAorICAgICAgICBuYW1lOiAncnBvb2wnCisgLi4uCisuZmkKKy5pbiAt MgorLnNwCisuTHAKK0V4YW1wbGUgMjogRGlzcGxheSBiYXNpYyBkYXRhc2V0IGluZm9ybWF0aW9u IGFib3V0ICdycG9vbCcKKy5zcAorLmluICsyCisubmYKKyMgemRiIC1kIHJwb29sCitEYXRhc2V0 IG1vcyBbTUVUQV0sIElEIDAsIGNyX3R4ZyA0LCAyNi45TSwgMTA1MSBvYmplY3RzCitEYXRhc2V0 IHJwb29sL3N3YXAgW1pWT0xdLCBJRCA1OSwgY3JfdHhnIDM1NiwgNDg2TSwgMiBvYmplY3RzCisg Li4uCisuZmkKKy5pbiAtMgorLnNwCisuTHAKK0V4YW1wbGUgMzogRGlzcGxheSBiYXNpYyBpbmZv cm1hdGlvbiBhYm91dCBvYmplY3QgMCBpbgorJ3Jwb29sL2V4cG9ydC9ob21lJworLnNwCisuaW4g KzIKKy5uZgorIyB6ZGIgLWQgcnBvb2wvZXhwb3J0L2hvbWUgMAorRGF0YXNldCBycG9vbC9leHBv cnQvaG9tZSBbWlBMXSwgSUQgMTM3LCBjcl90eGcgMTU0NiwgMzJLLCA4IG9iamVjdHMKKyAgICBP YmplY3QgIGx2bCAgIGlibGsgICBkYmxrICBkc2l6ZSAgbHNpemUgICAlZnVsbCAgdHlwZQorICAg ICAgICAgMCAgICA3ICAgIDE2SyAgICAxNksgIDE1LjBLICAgIDE2SyAgIDI1LjAwICBETVUgZG5v ZGUKKy5maQorLmluIC0yCisuc3AKKy5McAorRXhhbXBsZSA0OiBEaXNwbGF5IHRoZSBwcmVkaWN0 ZWQgZWZmZWN0IG9mIGVuYWJsaW5nIGRlZHVwbGljYXRpb24gb24gJ3Jwb29sJworLnNwCisuaW4g KzIKKy5uZgorIyB6ZGIgLVMgcnBvb2wKK1NpbXVsYXRlZCBERFQgaGlzdG9ncmFtOgorYnVja2V0 ICAgICAgICAgICAgICBhbGxvY2F0ZWQgICAgICAgICAgICAgICAgICAgICAgIHJlZmVyZW5jZWQg ICAgICAgICAgCitfX19fX18gICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gICBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KK3JlZmNudCAgIGJsb2NrcyAgIExTSVpFICAgUFNJ WkUgICBEU0laRSAgIGJsb2NrcyAgIExTSVpFICAgUFNJWkUgICBEU0laRQorLS0tLS0tICAgLS0t LS0tICAgLS0tLS0gICAtLS0tLSAgIC0tLS0tICAgLS0tLS0tICAgLS0tLS0gICAtLS0tLSAgIC0t LS0tCisgICAgIDEgICAgIDY5NEsgICAyNy4xRyAgIDE1LjBHICAgMTUuMEcgICAgIDY5NEsgICAy Ny4xRyAgIDE1LjBHICAgMTUuMEcKKyAgICAgMiAgICAzNS4wSyAgIDEuMzNHICAgIDY5OU0gICAg Njk5TSAgICA3NC43SyAgIDIuNzlHICAgMS40NUcgICAxLjQ1RworIC4uLgorZGVkdXAgPSAxLjEx LCBjb21wcmVzcyA9IDEuODAsIGNvcGllcyA9IDEuMDAsIGRlZHVwICogY29tcHJlc3MgLyBjb3Bp ZXMgPSAyLjAwCisuZmkKKy5pbiAtMgorLnNwCiAuU2ggU0VFIEFMU08KLS5YciB6ZnMgOCAsCisu WHIgemZzIDgsCiAuWHIgenBvb2wgOAogLlNoIEFVVEhPUlMKIFRoaXMgbWFudWFsIHBhZ2UgaXMg YQogLlhyIG1kb2MgNwotcmVpbXBsZW1lbnRhdGlvbiBvZiB0aGUKK3JlaW1wbGVtZW50YXRpb24g b2YKIC5UbiBPcGVuU29sYXJpcwogbWFudWFsIHBhZ2UKLS5FbSB6ZGIoMU0pICwKKy5FbSB6ZGIo MU0pLAogbW9kaWZpZWQgYW5kIGN1c3RvbWl6ZWQgZm9yCiAuRngKIGFuZCBsaWNlbnNlZCB1bmRl ciB0aGUKZGlmZiAtciBiNDcwYTVkYjQzMGUgY2RkbC9jb250cmliL29wZW5zb2xhcmlzL2NtZC96 ZGIvemRiLmMKLS0tIGEvY2RkbC9jb250cmliL29wZW5zb2xhcmlzL2NtZC96ZGIvemRiLmMJTW9u IEFwciAzMCAwNjowMjowMCAyMDEyICswMDAwCisrKyBiL2NkZGwvY29udHJpYi9vcGVuc29sYXJp cy9jbWQvemRiL3pkYi5jCU1vbiBBcHIgMzAgMTM6MjA6MzggMjAxMiArMDAwMApAQCAtMTAyLDEz ICsxMDIsMTYgQEAKIHVzYWdlKHZvaWQpCiB7CiAJKHZvaWQpIGZwcmludGYoc3RkZXJyLAotCSAg ICAiVXNhZ2U6ICVzIFstQ3VtZGliY3NEdmhMXSBwb29sbmFtZSBbb2JqZWN0Li4uXVxuIgotCSAg ICAiICAgICAgICVzIFstZGl2XSBkYXRhc2V0IFtvYmplY3QuLi5dXG4iCi0JICAgICIgICAgICAg JXMgLW0gWy1MXSBwb29sbmFtZSBbdmRldiBbbWV0YXNsYWIuLi5dXVxuIgotCSAgICAiICAgICAg ICVzIC1SIHBvb2xuYW1lIHZkZXY6b2Zmc2V0OnNpemVbOmZsYWdzXVxuIgotCSAgICAiICAgICAg ICVzIC1TIHBvb2xuYW1lXG4iCi0JICAgICIgICAgICAgJXMgLWwgWy11XSBkZXZpY2VcbiIKLQkg ICAgIiAgICAgICAlcyAtQ1xuXG4iLAorICAgICAgICAgICAgIlVzYWdlOiAlcyBbLUN1bWRpYmNz RHZoTFhGUEFdIFstdCB0eGddIFstZSBbLXAgcGF0aC4uLl1dIgorICAgICAgICAgICAgInBvb2xu YW1lIFtvYmplY3QuLi5dXG4iCisgICAgICAgICAgICAiICAgICAgICVzIFstZGl2UEFdIFstZSAt cCBwYXRoLi4uXSBkYXRhc2V0IFtvYmplY3QuLi5dXG4iCisgICAgICAgICAgICAiICAgICAgICVz IC1tIFstTFhGUEFdIFstdCB0eGddIFstZSBbLXAgcGF0aC4uLl1dIgorICAgICAgICAgICAgInBv b2xuYW1lIFt2ZGV2IFttZXRhc2xhYi4uLl1dXG4iCisgICAgICAgICAgICAiICAgICAgICVzIC1S IFstQV0gWy1lIFstcCBwYXRoLi4uXV0gcG9vbG5hbWUgIgorICAgICAgICAgICAgInZkZXY6b2Zm c2V0OnNpemVbOmZsYWdzXVxuIgorICAgICAgICAgICAgIiAgICAgICAlcyAtUyBbLVBBXSBbLWUg Wy1wIHBhdGguLi5dXSBwb29sbmFtZVxuIgorICAgICAgICAgICAgIiAgICAgICAlcyAtbCBbLXVB XSBkZXZpY2VcbiIKKyAgICAgICAgICAgICIgICAgICAgJXMgLUMgWy1BXSBbLVUgY29uZmlnXVxu XG4iLAogCSAgICBjbWRuYW1lLCBjbWRuYW1lLCBjbWRuYW1lLCBjbWRuYW1lLCBjbWRuYW1lLCBj bWRuYW1lLCBjbWRuYW1lKTsKIAogCSh2b2lkKSBmcHJpbnRmKHN0ZGVyciwgIiAgICBEYXRhc2V0 IG5hbWUgbXVzdCBpbmNsdWRlIGF0IGxlYXN0IG9uZSAiCkBAIC0xNTAsNyArMTUzLDcgQEAKIAkg ICAgImhhcyBhbHRyb290L25vdCBpbiBhIGNhY2hlZmlsZVxuIik7CiAJKHZvaWQpIGZwcmludGYo c3RkZXJyLCAiICAgICAgICAtcCA8cGF0aD4gLS0gdXNlIG9uZSBvciBtb3JlIHdpdGggIgogCSAg ICAiLWUgdG8gc3BlY2lmeSBwYXRoIHRvIHZkZXYgZGlyXG4iKTsKLQkodm9pZCkgZnByaW50Zihz dGRlcnIsICIJLVAgcHJpbnQgbnVtYmVycyBwYXJzYWJsZVxuIik7CisJKHZvaWQpIGZwcmludGYo c3RkZXJyLCAiCS1QIHByaW50IG51bWJlcnMgaW4gcGFyc2VhYmxlIGZvcm1cbiIpOwogCSh2b2lk KSBmcHJpbnRmKHN0ZGVyciwgIiAgICAgICAgLXQgPHR4Zz4gLS0gaGlnaGVzdCB0eGcgdG8gdXNl IHdoZW4gIgogCSAgICAic2VhcmNoaW5nIGZvciB1YmVyYmxvY2tzXG4iKTsKIAkodm9pZCkgZnBy aW50ZihzdGRlcnIsICJTcGVjaWZ5IGFuIG9wdGlvbiBtb3JlIHRoYW4gb25jZSAoZS5nLiAtYmIp ICIK --90e6ba6e8440d6fce304bef33ff8-- From owner-freebsd-fs@FreeBSD.ORG Tue May 1 06:54:16 2012 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 4C3E41065673 for ; Tue, 1 May 2012 06:54:16 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id C453F8FC0C for ; Tue, 1 May 2012 06:54:15 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [IPv6:2001:8b0:151:1:fa1e:dfff:feda:c0bb]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.5/8.14.5) with ESMTP id q416s8Rf079487 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 1 May 2012 07:54:08 +0100 (BST) (envelope-from matthew@FreeBSD.org) X-DKIM: OpenDKIM Filter v2.5.2 smtp.infracaninophile.co.uk q416s8Rf079487 Authentication-Results: smtp.infracaninophile.co.uk/q416s8Rf079487; dkim=none (no signature); dkim-adsp=none Message-ID: <4F9F8888.3030104@FreeBSD.org> Date: Tue, 01 May 2012 07:54:00 +0100 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: Peter Jeremy References: <20120430210711.GA50280@server.vk2pj.dyndns.org> In-Reply-To: <20120430210711.GA50280@server.vk2pj.dyndns.org> X-Enigmail-Version: 1.4.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9895976D0FC0F79BE8893513" X-Virus-Scanned: clamav-milter 0.97.4 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk Cc: freebsd-fs@FreeBSD.org Subject: Re: ZFS with multiple boot/root pools 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, 01 May 2012 06:54:16 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9895976D0FC0F79BE8893513 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 30/04/2012 22:07, Peter Jeremy wrote: > Can anyone suggest a way to configure a zpool or set of filesystems > so that they will only be mounted if the root filesystem is within > the zpool. Not exactly that, but this should suffice. Suppose your two pools are zpool1 and zpool2. You have several ZFSes on each pool, all of which should be set to the default[*] that they are all mounted relative to the top level ZFS -- either zpool1/ or zpool2/ -- so to avoid overlaps, all you need to do is mount the top level ZFS at a unique path. One way of doing this is to set the mountpoints for the top level zpool1/ and zpool2/ to legacy, and create /etc/fstab in each pool like so= : in zpool1/ zpool1 / zfs rw 0 0 zpool2 /ROOT/zpool2 zfs rw 0 0 in zpool2/ zpool2 / zfs rw 0 0 zpool1 /ROOT/zpool1 zfs rw 0 0 Another way of doing this is to realise that the vfs.root.mountfrom property in /boot/loader.conf overrides any internal settings in the zpools. This means that you can set the mountpoint for zpool1/ and zpool2/ to some distinct values, say, /ROOT/zpool1 and /ROOT/zpool2 If vfs.root.mountfrom is set to zfs:zpool1 then that zpool will be mounted as the root filesystem at / and zpool1/usr, zpool1/var etc. etc. will all be mounted in the expected locations relative to that. zpool2 will be mounted at /ROOT/zpool2 as defined in the zpool2 settings. zpool2/usr will be mounted at /ROOT/zpool2/usr etc. etc. To flip to mounting the other zpool at the root, you just need to tell the boot loader to use the other zpool. There is no need to put anything into /etc/fstab in this case. Apart from the wrinkle of having two different zpools, this is essentially how ZFS boot environments work. You should be able to adapt one or other of the various recipes for using boot environments on the net to suit. I have some notes at http://www.infracaninophile.co.uk/articles/install-on-zfs/ but there are several other treatments around. Cheers, Matthew [*] Use 'zfs inherit mountpoint zpool/whatever' to reset to this default behaviour if needed. --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --------------enig9895976D0FC0F79BE8893513 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+fiI8ACgkQ8Mjk52CukIwmYQCgkYaMSEogmR2U+/bNn2g+9JYQ szcAn1mM7HtkkwczHv0YfCU689B74j1Q =Wvtu -----END PGP SIGNATURE----- --------------enig9895976D0FC0F79BE8893513-- From owner-freebsd-fs@FreeBSD.ORG Tue May 1 20:21:29 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CACD7106564A; Tue, 1 May 2012 20:21:29 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 605D48FC0A; Tue, 1 May 2012 20:21:29 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id q41KLSnv048184; Tue, 1 May 2012 22:21:28 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q41KLSbq048183; Tue, 1 May 2012 22:21:28 +0200 (CEST) (envelope-from marius) Date: Tue, 1 May 2012 22:21:28 +0200 From: Marius Strobl To: Andriy Gapon Message-ID: <20120501202128.GD18650@alchemy.franken.de> References: <4F8999D2.1080902@FreeBSD.org> <20120422212102.GA66855@alchemy.franken.de> <4F9A6180.8090500@FreeBSD.org> <20120429164623.GG68446@alchemy.franken.de> <4F9E3971.7090405@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F9E3971.7090405@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-fs@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool 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, 01 May 2012 20:21:29 -0000 On Mon, Apr 30, 2012 at 10:04:17AM +0300, Andriy Gapon wrote: > on 29/04/2012 19:46 Marius Strobl said the following: > > Given that you certainly have a well better knowledge of ZFS, it > > would be great if we could do it the other way around, i.e. commit > > the sparc64 support first and then your patch after adapting > > whatever you have in mind with things becoming different. In other > > words, I'm basically ready to commit the following patch. As for > > zfs_dev_init() this just wraps it in #if defined(__amd64__) || > > defined(__i386__) in zfs.c for now. > > http://people.freebsd.org/~marius/boot_zfs_sparc64.diff > > OK, let's do it this way. > Thanks! Marius From owner-freebsd-fs@FreeBSD.ORG Tue May 1 21:04:29 2012 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 D4F6910657EB for ; Tue, 1 May 2012 21:04:29 +0000 (UTC) (envelope-from simon@optinet.com) Received: from cobra.acceleratedweb.net (cobra-gw.acceleratedweb.net [207.99.79.37]) by mx1.freebsd.org (Postfix) with SMTP id 63D0D8FC12 for ; Tue, 1 May 2012 21:04:29 +0000 (UTC) Received: (qmail 78965 invoked by uid 110); 1 May 2012 20:57:46 -0000 Received: from ool-4571afe7.dyn.optonline.net (HELO desktop1) (simon@optinet.com@69.113.175.231) by cobra.acceleratedweb.net with SMTP; 1 May 2012 20:57:46 -0000 From: "Simon" To: "freebsd-fs@freebsd.org" Date: Tue, 01 May 2012 16:57:40 -0400 Priority: Normal X-Mailer: PMMail 2000 Professional (2.20.2717) For Windows 2000 (5.1.2600;3) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20120501210429.D4F6910657EB@hub.freebsd.org> Subject: Replacing dead drives in ZRAID2 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, 01 May 2012 21:04:29 -0000 Hello, I decided to give ZFS ZRAID2 a shot after getting fed up with some legacy hardware RAID cards that don't properly perform, or at all, patrol-reads + consistency checking. So... I can't seem to figure out the proper way to replace a dead drive in a running system with SCSI+SES enclosure. I tried: zpool detach zroot baddrive camcontrol stop baddrive At this point when I pull the drive out, I get bus reset errors, etc... I will go into details after someone confirms whether the above 2 steps suffice to pull a dead/malfunctioning drive out from SES enclosure or am I missing something? I tried to simulate drive failure by pulling 2 out of 3 ZRAID2 drives. The first drive pull went smoothly. System noticed drive disconnected and stopped using it. The 2nd drive pull resulted in bunch of errors and system froze completely. I can't pull 2 drives out in ZRAID2 system and expect the machine to continue to function? what am I missing :\ PS: I couldn't find dedicated FreeBSD ZFS email list, is there one? Thank you very much! Simon From owner-freebsd-fs@FreeBSD.ORG Tue May 1 21:26:43 2012 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 42C391065674 for ; Tue, 1 May 2012 21:26:43 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id EEDC28FC14 for ; Tue, 1 May 2012 21:26:42 +0000 (UTC) Received: by qabg1 with SMTP id g1so2574328qab.13 for ; Tue, 01 May 2012 14:26:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pP6lmtFLTmDJAyW2fN2CjYelUNNkzTLoUTLRuZSTOMw=; b=lJXPJQUf8vF5YwiozkJ74vbNulOKKYiS4tRpc5EC2Wq3KPlSphK/TGk7+hclvFYTPp GdoRbqU9bNcYA5NHfh6LhLPX09egtNyQ8nfzVmDrYH1I5J0fXPr7832/sMu9l5ELf5Jr aNgPzAfXE2cm5MVdj9Rd1t+K//jxqEDdD3UTs7hyyTjP10q7hoWb+0Y5SBxfFRmFKHxU oeOSQiz6EDQYYhmSdSLFnSQwwj029mZgXvTdImaQusS7M9f0vWNFJWwdYrwBJETI28KD uzpPR0bGUf10NUz+pNppWiYmU73jdloDNX+mhIW6vjjkbm9MYW4y50K5eAdRZaHPetbD 5W3g== MIME-Version: 1.0 Received: by 10.229.135.137 with SMTP id n9mr7095091qct.48.1335907595786; Tue, 01 May 2012 14:26:35 -0700 (PDT) Received: by 10.229.191.82 with HTTP; Tue, 1 May 2012 14:26:35 -0700 (PDT) In-Reply-To: <20120501210429.D4F6910657EB@hub.freebsd.org> References: <20120501210429.D4F6910657EB@hub.freebsd.org> Date: Tue, 1 May 2012 14:26:35 -0700 Message-ID: From: Freddie Cash To: Simon Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-fs@freebsd.org" Subject: Re: Replacing dead drives in ZRAID2 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, 01 May 2012 21:26:43 -0000 On Tue, May 1, 2012 at 1:57 PM, Simon wrote: > I decided to give ZFS ZRAID2 a shot after getting fed up with some legacy > hardware RAID cards that don't properly perform, or at all, patrol-reads + > consistency checking. So... > > I can't seem to figure out the proper way to replace a dead drive in a running > system with SCSI+SES enclosure. I tried: > > zpool detach zroot baddrive > camcontrol stop baddrive You can't detach drives from raidz vdevs. The correct process is: zpool offline zroot zpool replace zroot "zpool detach" is only used for mirror vdevs. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Tue May 1 22:15:36 2012 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 4F8E4106564A for ; Tue, 1 May 2012 22:15:36 +0000 (UTC) (envelope-from simon@optinet.com) Received: from cobra.acceleratedweb.net (cobra-gw.acceleratedweb.net [207.99.79.37]) by mx1.freebsd.org (Postfix) with SMTP id EC3198FC0C for ; Tue, 1 May 2012 22:15:35 +0000 (UTC) Received: (qmail 83259 invoked by uid 110); 1 May 2012 22:15:34 -0000 Received: from ool-4571afe7.dyn.optonline.net (HELO desktop1) (simon@optinet.com@69.113.175.231) by cobra.acceleratedweb.net with SMTP; 1 May 2012 22:15:34 -0000 From: "Simon" To: "Freddie Cash" Date: Tue, 01 May 2012 18:15:28 -0400 Priority: Normal X-Mailer: PMMail 2000 Professional (2.20.2717) For Windows 2000 (5.1.2600;3) In-Reply-To: MIME-Version: 1.0 Message-Id: <20120501221536.4F8E4106564A@hub.freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-fs@freebsd.org" Subject: Re: Replacing dead drives in ZRAID2 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, 01 May 2012 22:15:36 -0000 Sorry, I meant to say zpool offline. After I take the drive out marked as offline, and put it back in, the system spits the following: ahd0: someone reset channel A ahd0: WARNING no command for scb 242 (cmdcmplt) QOUTPOS = 283 >>>>>>>>>>>>>>>>>>>Dumpt Card State Begins>>>>>>>>>>>> ahd0: dumping card state.... followed by a lard amount of data. It then freezes and won't executed any new commands. beta_srv# uname -a FreeBSD beta_srv 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:15:25 UTC 2012 root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 beta_srv# dmesg | grep ses ses0 at ahd0 bus 0 scbus0 target 6 lun 0 ses0: Fixed Processor SCSI-2 device ses0: 3.300MB/s transfers ses0: SAF-TE Compliant Device Thanks, Simon On Tue, 1 May 2012 14:26:35 -0700, Freddie Cash wrote: >On Tue, May 1, 2012 at 1:57 PM, Simon wrote: >> I decided to give ZFS ZRAID2 a shot after getting fed up with some legacy >> hardware RAID cards that don't properly perform, or at all, patrol-reads + >> consistency checking. So... >> >> I can't seem to figure out the proper way to replace a dead drive in a running >> system with SCSI+SES enclosure. I tried: >> >> zpool detach zroot baddrive >> camcontrol stop baddrive >You can't detach drives from raidz vdevs. The correct process is: >zpool offline zroot > > > >zpool replace zroot >"zpool detach" is only used for mirror vdevs. >-- >Freddie Cash >fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Wed May 2 00:57:53 2012 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 4D36E106566C for ; Wed, 2 May 2012 00:57:53 +0000 (UTC) (envelope-from rincebrain@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id F41CE8FC08 for ; Wed, 2 May 2012 00:57:52 +0000 (UTC) Received: by qcsg15 with SMTP id g15so63989qcs.13 for ; Tue, 01 May 2012 17:57:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=g2srQJ+hw436P8vNz8OlysN+0+lCBFJyC13O77uYmNo=; b=SWh8tf6sqBngZNhaLaGo8Jx4AgizGcTfy4mjTvFNqV6Jzvm2t2L+0hTcRM09yQ+03i cwKwna89/K1klg8UmJTXQ8SuZf0dGBmIeLBWQMrTw2+GrRIUzVlUbK4IX3Ezwbwq1h7l SMcQxiy5Wi6MCGf9OeXJShskj/atT4RwBtxuAxX6IfOYQwSVUv4mensi9YbzT2a6YE6K ONDTernkic3nwA4VAUqpHjQZ01w6GxMOKwBZq0ybw/I0Iwn7kIQBa3vDlDRSvrOYutDc GuI6tgDcmpfwDY1GWcgVwquv7Q1UxtEum41GS1BzoslmbLjXS5rCqZFikS/JeqQwiZLI cbdA== MIME-Version: 1.0 Received: by 10.229.134.207 with SMTP id k15mr6869721qct.78.1335920272137; Tue, 01 May 2012 17:57:52 -0700 (PDT) Sender: rincebrain@gmail.com Received: by 10.229.233.10 with HTTP; Tue, 1 May 2012 17:57:52 -0700 (PDT) In-Reply-To: <20120501221536.4F8E4106564A@hub.freebsd.org> References: <20120501221536.4F8E4106564A@hub.freebsd.org> Date: Tue, 1 May 2012 20:57:52 -0400 X-Google-Sender-Auth: X6WkJJaR04lICrkmzg9Betv0zE4 Message-ID: From: Rich To: Simon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-fs@freebsd.org" Subject: Re: Replacing dead drives in ZRAID2 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, 02 May 2012 00:57:53 -0000 What card is this? - Rich On Tue, May 1, 2012 at 6:15 PM, Simon wrote: > > Sorry, I meant to say zpool offline. > > After I take the drive out marked as offline, and put it back in, the sys= tem spits > the following: > > ahd0: someone reset channel A > ahd0: WARNING no command for scb 242 (cmdcmplt) > QOUTPOS =3D 283 > >>>>>>>>>>>>>>>>>>>>Dumpt Card State Begins>>>>>>>>>>>> > ahd0: dumping card state.... followed by a lard amount of data. > > It then freezes and won't executed any new commands. > > beta_srv# uname -a > FreeBSD beta_srv 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan =A03 07:15:2= 5 > UTC 2012 =A0 =A0 root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC= =A0i386 > > beta_srv# dmesg | grep ses > ses0 at ahd0 bus 0 scbus0 target 6 lun 0 > ses0: Fixed Processor SCSI-2 device > ses0: 3.300MB/s transfers > ses0: SAF-TE Compliant Device > > Thanks, > Simon > > On Tue, 1 May 2012 14:26:35 -0700, Freddie Cash wrote: > >>On Tue, May 1, 2012 at 1:57 PM, Simon wrote: >>> I decided to give ZFS ZRAID2 a shot after getting fed up with some lega= cy >>> hardware RAID cards that don't properly perform, or at all, patrol-read= s + >>> consistency checking. So... >>> >>> I can't seem to figure out the proper way to replace a dead drive in a = running >>> system with SCSI+SES enclosure. I tried: >>> >>> zpool detach zroot baddrive >>> camcontrol stop baddrive > >>You can't detach drives from raidz vdevs. =A0The correct process is: > >>zpool offline zroot >> >> >> >>zpool replace zroot > >>"zpool detach" is only used for mirror vdevs. > >>-- >>Freddie Cash >>fjwcash@gmail.com > > > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Wed May 2 01:31:29 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 093C51065670 for ; Wed, 2 May 2012 01:31:29 +0000 (UTC) (envelope-from simon@optinet.com) Received: from cobra.acceleratedweb.net (cobra-gw.acceleratedweb.net [207.99.79.37]) by mx1.freebsd.org (Postfix) with SMTP id A3D108FC08 for ; Wed, 2 May 2012 01:31:28 +0000 (UTC) Received: (qmail 92491 invoked by uid 110); 2 May 2012 01:31:27 -0000 Received: from ool-4571afe7.dyn.optonline.net (HELO desktop1) (simon@optinet.com@69.113.175.231) by cobra.acceleratedweb.net with SMTP; 2 May 2012 01:31:27 -0000 From: "Simon" To: "Rich" Date: Tue, 01 May 2012 21:31:20 -0400 Priority: Normal X-Mailer: PMMail 2000 Professional (2.20.2717) For Windows 2000 (5.1.2600;3) In-Reply-To: MIME-Version: 1.0 Message-Id: <20120502013129.093C51065670@hub.freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-fs@freebsd.org" Subject: Re: Replacing dead drives in ZRAID2 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, 02 May 2012 01:31:29 -0000 ahd0: on board of Super X5DPR-8G2+ motherboard. Also would like to add that when I plug a drive into this running machine, it prints the following, but does not come up under /dev unless I issue reset using camcontrol. ahd0: Someone reset channel A (da0:ahd0:0:0:0): WRITE(10). CDB: 2a 0 1 10 23 f0 0 0 80 0 (da0:ahd0:0:0:0): CAM status: SCSI Status Error (da0:ahd0:0:0:0): SCSI status: Check Condition (da0:ahd0:0:0:0): SCSI sense: UNIT ATTENTION asc:29,1 (Power on occurred) (da0:ahd0:0:0:0): Field Replaceable Unit: 1 -Simon On Tue, 1 May 2012 20:57:52 -0400, Rich wrote: >What card is this? >- Rich >On Tue, May 1, 2012 at 6:15 PM, Simon wrote: >> >> Sorry, I meant to say zpool offline. >> >> After I take the drive out marked as offline, and put it back in, the system spits >> the following: >> >> ahd0: someone reset channel A >> ahd0: WARNING no command for scb 242 (cmdcmplt) >> QOUTPOS = 283 >> >>>>>>>>>>>>>>>>>>>>>Dumpt Card State Begins>>>>>>>>>>>> >> ahd0: dumping card state.... followed by a lard amount of data. >> >> It then freezes and won't executed any new commands. >> >> beta_srv# uname -a >> FreeBSD beta_srv 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:15:25 >> UTC 2012 root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 >> >> beta_srv# dmesg | grep ses >> ses0 at ahd0 bus 0 scbus0 target 6 lun 0 >> ses0: Fixed Processor SCSI-2 device >> ses0: 3.300MB/s transfers >> ses0: SAF-TE Compliant Device >> >> Thanks, >> Simon >> >> On Tue, 1 May 2012 14:26:35 -0700, Freddie Cash wrote: >> >>>On Tue, May 1, 2012 at 1:57 PM, Simon wrote: >>>> I decided to give ZFS ZRAID2 a shot after getting fed up with some legacy >>>> hardware RAID cards that don't properly perform, or at all, patrol-reads + >>>> consistency checking. So... >>>> >>>> I can't seem to figure out the proper way to replace a dead drive in a running >>>> system with SCSI+SES enclosure. I tried: >>>> >>>> zpool detach zroot baddrive >>>> camcontrol stop baddrive >> >>>You can't detach drives from raidz vdevs. The correct process is: >> >>>zpool offline zroot >>> >>> >>> >>>zpool replace zroot >> >>>"zpool detach" is only used for mirror vdevs. >> >>>-- >>>Freddie Cash >>>fjwcash@gmail.com >> >> >> >> _______________________________________________ >> freebsd-fs@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-fs >> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Wed May 2 02:30:10 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5E5D61065674 for ; Wed, 2 May 2012 02:30:10 +0000 (UTC) (envelope-from bryan@shatow.net) Received: from secure.xzibition.com (secure.xzibition.com [173.160.118.92]) by mx1.freebsd.org (Postfix) with ESMTP id F1F558FC0C for ; Wed, 2 May 2012 02:30:09 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:content-type :content-transfer-encoding; q=dns; s=sweb; b=JQ/E1/ZYYVVbm0OX/fR J8GoDOIJsQE+IXiQfadulLcjtTn6ZghnQCNMxA+01QwezzoPvkd/byhXpcIiEeNL AAItObv4Qb0OVN5hQoIuooBPb1Ksz77Tj4XkIK8slqyVUeSbF6YmDfLckOxQNamO 8jFNT+qDOz2WyyCY6H/H3sV0= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:content-type :content-transfer-encoding; s=sweb; bh=b72iolp5SW3ue7BkNkK3gi+VH APkRJxTywIjk8fHvM4=; b=bJlzCK1Iwd/D6XX9GO2jXBwM+jPkABX/1LT06PTXL Yh7NPx5gTLKcl3OiGQRE30CdNFSu/SLhYIIVdS9XM7lPZme4FXlTYcwh1l4w1kjm zAS/odQZq9BHfuRJ0vEaXC222eu8NwZugGa1S1vkd1KEOgXL+Z4sy7PEbqYcs4Rm tM= Received: (qmail 22343 invoked from network); 1 May 2012 21:30:08 -0500 Received: from unknown (HELO ?10.10.1.87?) (bryan@shatow.net@10.10.1.87) by sweb.xzibition.com with ESMTPA; 1 May 2012 21:30:08 -0500 Message-ID: <4FA09C1C.2090306@shatow.net> Date: Tue, 01 May 2012 21:29:48 -0500 From: Bryan Drewery User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org X-Enigmail-Version: 1.4.1 OpenPGP: id=3C9B0CF9; url=http://www.shatow.net/bryan/bryan.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: vermaden Subject: ZFS canmount=on (from noauto) on mounted datasets 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, 02 May 2012 02:30:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 What am I missing here? On 9-RELEASE. I am unable to change 'canmount' from 'noauto' to 'on', on an already-auto-mounted dataset. # mount|grep "/var/log" zroot/ROOT/freebsd90/var/log on /var/log (zfs, local, noatime, noexec, nosuid, nfsv4acls) # zfs get -H -o value mounted zroot/ROOT/freebsd90/var/log yes # zfs get -H -o value canmount zroot/ROOT/freebsd90/var/log noauto # zfs set canmount=on zroot/ROOT/freebsd90/var/log cannot unmount '/var/log': Device busy ^^^^ I don't see any reference in zfs(1M) to 'canmount' causing automatically causing a [re]mount. This is understandable for 'mountpoint' of course. It seems zfs_prop_set() in libzfs_changelist is doing this by calling changelist_prefix(), as long as not using 'noauto', which does a remount. The comments for changelist_prop() indicate it's for changing 'mountpoint', which makes sense. Is this being incorrectly called in zfs_prop_set() for 'canmount=on/off'? The HEAD code looks to be prone to this as well in zfs_prop_set(). Code in question: /* * If the dataset's canmount property is being set to noauto, * then we want to prevent unmounting & remounting it. */ do_prefix = !((prop == ZFS_PROP_CANMOUNT) && (zprop_string_to_index(prop, propval, &idx, ZFS_TYPE_DATASET) == 0) && (idx == ZFS_CANMOUNT_NOAUTO)); if (do_prefix && (ret = changelist_prefix(cl)) != 0) goto error; Regards, Bryan Drewery -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPoJwbAAoJEG54KsA8mwz5qeUP/3QKNRZ2cg2n9uf6+zxf3Shi FQiUqJEiMGJ4UEWFUOpgJM1KIOT4ms9L64v5DozPrlnxVpFiHUEHI2PcOS1GzDue mPX7yTb87OXut263vp5EIYZUo/m03lbVH+Rkd01NTUipgXJWZNF8ShruekjjiPVN tvou0XyigqMScyrJ83DzUE0thpEvsDJ/8AoubhWw3p6SpgRLcdcAeDLVALazQRxB +vILmLtlTH3mBSXWDRLAtALKWJl4ewVDYNP8YhsDVhiCVP7vkc5C3pNyh+cbDHhH h1tKv3mArAiYMxOFHIu9Z/SkO9cfDqH25k2ezv8/x2QOgrqPQumERP3v9g1FxTc5 0KJ+ZkDQTeTiPtmkLDZ+jfl6CelgI9TvOAsR9ftQzeKZHMDWWNg5jpMBkchN3+YC wI3T/ETC581bG+eLIgm2+lBhDnf/cJBdkf6riW2hqvwv2KqjENel4WvQ13fe+n3/ kGRTWV5PrhRIOdMpjhiB4EV357n3HddGVhlt0aTmxQk/XoNxdJZufWU1Chi1+QB9 xsh1jHoce87kOb2TSmrbVROqoCPDng9ZgFV12crlk07MV8fEXRuSFPFA851uR2/P QPc96/0B/YZI1GUvWa8ru921fs0slzVvayM7strgb2jRQCFKvgN6CjalPn9SiMSH EZmhSUImjIOMN2225Wr9 =dxSV -----END PGP SIGNATURE----- From owner-freebsd-fs@FreeBSD.ORG Wed May 2 05:28:21 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 44253106566C; Wed, 2 May 2012 05:28:21 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by mx1.freebsd.org (Postfix) with ESMTP id C7DA28FC0A; Wed, 2 May 2012 05:28:20 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c220-239-251-180.belrs5.nsw.optusnet.com.au [220.239.251.180]) by mail17.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q425SCYs012073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 May 2012 15:28:13 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.5/8.14.4) with ESMTP id q425SBkb079276; Wed, 2 May 2012 15:28:11 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.5/8.14.5/Submit) id q425SBdx079275; Wed, 2 May 2012 15:28:11 +1000 (EST) (envelope-from peter) Date: Wed, 2 May 2012 15:28:11 +1000 From: Peter Jeremy To: Matthew Seaman Message-ID: <20120502052811.GA71211@server.vk2pj.dyndns.org> References: <20120430210711.GA50280@server.vk2pj.dyndns.org> <4F9F8888.3030104@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mP3DRpeJDSE+ciuQ" Content-Disposition: inline In-Reply-To: <4F9F8888.3030104@FreeBSD.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@FreeBSD.org Subject: Re: ZFS with multiple boot/root pools 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, 02 May 2012 05:28:21 -0000 --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-May-01 07:54:00 +0100, Matthew Seaman wrote: >On 30/04/2012 22:07, Peter Jeremy wrote: >> Can anyone suggest a way to configure a zpool or set of filesystems >> so that they will only be mounted if the root filesystem is within >> the zpool. > >Not exactly that, but this should suffice. It sounds good but I can't make it work. >Suppose your two pools are zpool1 and zpool2. You have several ZFSes on >each pool, all of which should be set to the default[*] that they are >all mounted relative to the top level ZFS -- either zpool1/ or zpool2/ >-- so to avoid overlaps, all you need to do is mount the top level ZFS >at a unique path. Yep. To go further, assume there are also zpool{1,2}/var filesystems, one of which should be mounted as /var. The mountpoint for zpool{1,2}/var can be one of: A) legacy This requires an entry in each /etc/fstab for /var B) inherited This depends on the value of mountpoint for zpool{1,2}: a) legacy Same as (A) above. b) inherited The mountpoint will be set to /zpool{1,2}/var c) Set to some arbitrary value, say /foo The mountpoint will be set to /foo/var C) /var This results is two /var filesystems unless one is marked "canmount=3Dno= auto" >One way of doing this is to set the mountpoints for the top level >zpool1/ and zpool2/ to legacy, and create /etc/fstab in each pool like so: > >in zpool1/ > >zpool1 / zfs rw 0 0 >zpool2 /ROOT/zpool2 zfs rw 0 0 Following the breakdown above, this implies I'd also need an entry in /etc/fstab: zpool1/var /var zfs rw 0 0 >Another way of doing this is to realise that the vfs.root.mountfrom >property in /boot/loader.conf overrides any internal settings in the >zpools. This means that you can set the mountpoint for zpool1/ and >zpool2/ to some distinct values, say, /ROOT/zpool1 and /ROOT/zpool2 Whilst this overrides the mountpoint for the root filesystem, it has no effect on other filesystems in the pool. In particular, the mountpoint for zpool1/var remains /zpool1/var and the "zfs mount -a" fails because there's no /zpool1 >If vfs.root.mountfrom is set to zfs:zpool1 then that zpool will be >mounted as the root filesystem at / and zpool1/usr, zpool1/var etc. etc. >will all be mounted in the expected locations relative to that. Unfortunately my experiments on a 10-current box show this doesn't happen. Inheriting a mountpoint means that the filesystem's mountpoint is set to the parent's nominal mountpoint (ie zpool{1,2}), not the actual mountpoint (ie /), with the filesystem name appended. >Apart from the wrinkle of having two different zpools, this is >essentially how ZFS boot environments work. Except that beadm/manageBE does a lot of other juggling to switch between BEs. >http://www.infracaninophile.co.uk/articles/install-on-zfs/ but there are >several other treatments around. I've had a look through those notes and you are still specifying mountpoints for (eg) zroot/ROOT/9.0-RELEASE/usr - which implies you wind up with multiple /usr's mounted. =20 --=20 Peter Jeremy --mP3DRpeJDSE+ciuQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk+gxesACgkQ/opHv/APuIdSSgCguG6ZPZRm+nEBUrPo3rfOdTHa W4MAoL6cp+JytfNKqEwBbPPnaGdqUDc5 =3/GS -----END PGP SIGNATURE----- --mP3DRpeJDSE+ciuQ-- From owner-freebsd-fs@FreeBSD.ORG Wed May 2 06:39:39 2012 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 C75051065676 for ; Wed, 2 May 2012 06:39:39 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nskntmtas03p.mx.bigpond.com (nskntmtas03p.mx.bigpond.com [61.9.168.143]) by mx1.freebsd.org (Postfix) with ESMTP id 6AB798FC15 for ; Wed, 2 May 2012 06:39:39 +0000 (UTC) Received: from nskntotgx03p.mx.bigpond.com ([124.188.161.100]) by nskntmtas03p.mx.bigpond.com with ESMTP id <20120502063937.SLOJ10464.nskntmtas03p.mx.bigpond.com@nskntotgx03p.mx.bigpond.com> for ; Wed, 2 May 2012 06:39:37 +0000 Received: from johnny.reilly.home ([124.188.161.100]) by nskntotgx03p.mx.bigpond.com with ESMTP id <20120502063937.GLIU2714.nskntotgx03p.mx.bigpond.com@johnny.reilly.home> for ; Wed, 2 May 2012 06:39:37 +0000 Date: Wed, 2 May 2012 16:39:27 +1000 From: Andrew Reilly To: freebsd-fs@freebsd.org Message-ID: <20120502063927.GA9559@johnny.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-SIH-MSG-ID: ohw1Etf5TAD0zmQs0WyzOwJxyArnqyN48Z4QX81loRIGTUDCp8DeQ9rEJvdRvN+vxC5OJhqDNGIpaa/jTY3Rs9uK Subject: gpart labels - why arent't some showing up in /dev/gpt/? 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, 02 May 2012 06:39:40 -0000 Hi there, I like being able to label my drives and partitions with gpart, so that I can (putatively) replace drives or move them around or have the new ata drivers move them around for me, and still have fstab find them. So, for example, I have (in fstab): /dev/gpt/root / ufs rw,async,noatime 1 1 Which derives from an appropriate label on ada2p1: Geom name: ada2 modified: false state: OK fwheads: 16 fwsectors: 63 last: 117231374 first: 34 entries: 128 scheme: GPT Providers: 1. Name: ada2p1 Mediasize: 65536 (64k) Sectorsize: 512 Stripesize: 0 Stripeoffset: 17408 Mode: r0w0e0 rawuuid: 356aefc1-92a7-11e1-ae3f-00270e0fb8e9 rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f label: bootme length: 65536 offset: 17408 type: freebsd-boot index: 1 end: 161 start: 34 2. Name: ada2p2 Mediasize: 60022325248 (55G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 131072 Mode: r1w1e2 rawuuid: 9995b354-92a7-11e1-ae3f-00270e0fb8e9 rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b label: root length: 60022325248 offset: 131072 type: freebsd-ufs index: 2 end: 117231359 start: 256 Consumers: 1. Name: ada2 Mediasize: 60022480896 (55G) Sectorsize: 512 Mode: r1w1e3 Back when I first built this computer, I similarly labelled the four freebsd-zfs partitions on my four main spinning disks, with the intention that I could use these names in a non-confusing way in subsequent zpool create commands. This did work *once*, but after using the /dev/gpt/raidz0... names to create a raidz tank, they disappeared from /dev/gpt, and the names that showed up in zpool status output were the long strings of digits from the /dev/gptid/ directory. This week I had to blow my raid array and start from scratch, after zpool scrub proved itself incapable of fixing or removing the corruption that I have mentioned here earlier. Even after clearing the disks of their zpool, the gpt names did not show up under /dev/gpt, so I have had to rebuild my zfs array with old-school partition names, like ada0p1 and so on. This does work, but it seems a bit sub-optimal. Anyone know why the /dev/gpt/label name seems so tempramental, and what might be done to make it behave as I've expected? FWIW here is a gpart list of the first of the raid drives (the other three are essentially the same, but with the label digit incremented): Geom name: ada0 modified: false state: OK fwheads: 16 fwsectors: 63 last: 1953525134 first: 34 entries: 128 scheme: GPT Providers: 1. Name: ada0p1 Mediasize: 1000204851712 (931G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 17408 Mode: r1w1e1 rawuuid: b06b6337-e511-11e0-9d62-00270e0fb8e9 rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b label: raidz1 length: 1000204851712 offset: 17408 type: freebsd-zfs index: 1 end: 1953525134 start: 34 Consumers: 1. Name: ada0 Mediasize: 1000204886016 (931G) Sectorsize: 512 Mode: r1w1e2 and here's the entire contents of /dev/gpt: altroot backup backup3g bootme bootme2 root (no raidz1, etc.) Cheers, -- Andrew From owner-freebsd-fs@FreeBSD.ORG Wed May 2 06:46:30 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EE91A106564A for ; Wed, 2 May 2012 06:46:30 +0000 (UTC) (envelope-from peter.maloney@brockmann-consult.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by mx1.freebsd.org (Postfix) with ESMTP id 95BC68FC0A for ; Wed, 2 May 2012 06:46:30 +0000 (UTC) Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0LgXxN-1Rn8S02P9p-00nwoW; Wed, 02 May 2012 08:46:29 +0200 Message-ID: <4FA0D844.8090105@brockmann-consult.de> Date: Wed, 02 May 2012 08:46:28 +0200 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <20120502063927.GA9559@johnny.reilly.home> In-Reply-To: <20120502063927.GA9559@johnny.reilly.home> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:ATWqpcD8uHz1CnkuuVFUFZpibZhlcg4LRG+Ynj1JF4O ZU2BBp1+kwycUFI6u5lPXVIxwF6DLz6NJxYGUHtpg611VTrq3n vkzghZ+04LlcoSMs5h0FHk30wi1Skx1S4gTAjRUYaTTjPaMLc7 El25P6yEvsTmDCW3SG2uoUijVizMi4gBfTEX9oJbGfZx14PibS e6rM555wEPPwQv+BHkFFxJSoZQtaeWOyzw9ud8f7lYoDHP86X9 wn/w+MJLfMreK6rTnel5qr++nTvwTB6t0DooT9kQ3J0kIg0Gyv oE3aqPbSRmXu+9Z7gtDDjzB3tbf6l8KQ0WCn0Lcy2MOXwyJI1m CZz79l5VgghxEsRCZIS9+qV2dDrMh9aSNt07/tpGe Subject: Re: gpart labels - why arent't some showing up in /dev/gpt/? 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, 02 May 2012 06:46:31 -0000 I have the same problem. Any time you boot off a CD/DVD and use import -f (and then don't export), or I guess use import -f a pool from anywhere, it does that. I don't know any non-zfs causes for the problem. Here are some relevant /boot/loader.conf settings (I don't know how accurate the comments are... I wrote them myself, without fully testing them): # Setting this to 0 will get rid of the /dev/gptid directory and you will see your /dev/gpt directory again if it bugged out and gpt labels disappeared. #kern.geom.label.gptid.enable=0 # Not sure what this does; I assume it means to forget about /dev/gpt/* and probably either show gptid (if not disabled above) or the original device name (eg. da0p2) #kern.geom.label.gpt.enable=0 However, that is a lame workaround, disabling a feature to get another back. I would love to see a good fix. On 05/02/2012 08:39 AM, Andrew Reilly wrote: > Hi there, > > I like being able to label my drives and partitions with gpart, > so that I can (putatively) replace drives or move them around > or have the new ata drivers move them around for me, and still > have fstab find them. > > So, for example, I have (in fstab): > /dev/gpt/root / ufs rw,async,noatime 1 1 > > Which derives from an appropriate label on ada2p1: > Geom name: ada2 > modified: false > state: OK > fwheads: 16 > fwsectors: 63 > last: 117231374 > first: 34 > entries: 128 > scheme: GPT > Providers: > 1. Name: ada2p1 > Mediasize: 65536 (64k) > Sectorsize: 512 > Stripesize: 0 > Stripeoffset: 17408 > Mode: r0w0e0 > rawuuid: 356aefc1-92a7-11e1-ae3f-00270e0fb8e9 > rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f > label: bootme > length: 65536 > offset: 17408 > type: freebsd-boot > index: 1 > end: 161 > start: 34 > 2. Name: ada2p2 > Mediasize: 60022325248 (55G) > Sectorsize: 512 > Stripesize: 0 > Stripeoffset: 131072 > Mode: r1w1e2 > rawuuid: 9995b354-92a7-11e1-ae3f-00270e0fb8e9 > rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b > label: root > length: 60022325248 > offset: 131072 > type: freebsd-ufs > index: 2 > end: 117231359 > start: 256 > Consumers: > 1. Name: ada2 > Mediasize: 60022480896 (55G) > Sectorsize: 512 > Mode: r1w1e3 > > Back when I first built this computer, I similarly labelled the > four freebsd-zfs partitions on my four main spinning disks, with > the intention that I could use these names in a non-confusing > way in subsequent zpool create commands. This did work *once*, > but after using the /dev/gpt/raidz0... names to create a raidz > tank, they disappeared from /dev/gpt, and the names that showed > up in zpool status output were the long strings of digits from > the /dev/gptid/ directory. > > This week I had to blow my raid array and start from scratch, > after zpool scrub proved itself incapable of fixing or removing > the corruption that I have mentioned here earlier. Even after > clearing the disks of their zpool, the gpt names did not show up > under /dev/gpt, so I have had to rebuild my zfs array with > old-school partition names, like ada0p1 and so on. This does > work, but it seems a bit sub-optimal. > > Anyone know why the /dev/gpt/label name seems so tempramental, > and what might be done to make it behave as I've expected? > > FWIW here is a gpart list of the first of the raid drives (the > other three are essentially the same, but with the label digit > incremented): > > Geom name: ada0 > modified: false > state: OK > fwheads: 16 > fwsectors: 63 > last: 1953525134 > first: 34 > entries: 128 > scheme: GPT > Providers: > 1. Name: ada0p1 > Mediasize: 1000204851712 (931G) > Sectorsize: 512 > Stripesize: 0 > Stripeoffset: 17408 > Mode: r1w1e1 > rawuuid: b06b6337-e511-11e0-9d62-00270e0fb8e9 > rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b > label: raidz1 > length: 1000204851712 > offset: 17408 > type: freebsd-zfs > index: 1 > end: 1953525134 > start: 34 > Consumers: > 1. Name: ada0 > Mediasize: 1000204886016 (931G) > Sectorsize: 512 > Mode: r1w1e2 > > and here's the entire contents of /dev/gpt: > altroot backup backup3g bootme bootme2 root > > (no raidz1, etc.) > > Cheers, > -- -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str. 2 21502 Geesthacht Germany Tel: +49 4152 889 300 Fax: +49 4152 889 333 E-mail: peter.maloney@brockmann-consult.de Internet: http://www.brockmann-consult.de -------------------------------------------- From owner-freebsd-fs@FreeBSD.ORG Wed May 2 07:26:11 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BD8B8106564A; Wed, 2 May 2012 07:26:11 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 100878FC08; Wed, 2 May 2012 07:26:10 +0000 (UTC) Received: by bkvi17 with SMTP id i17so274414bkv.13 for ; Wed, 02 May 2012 00:26:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=koMIYi+AdEQIZj15kr2fptCfFHlQAIeMY3uZjvQvhlk=; b=Q6ohRtAciUpjKqgICba3gUtVlnoK9jzJmvB2fMpm6l6Dqo1xOVAVtyp6xssvoKJgMt gnjxAyTMqfb5/fDL9LEikU2EcwfBUPHVtHuSFVraT3beY7DxmCiVAtkJ0HT0JfloVG0a SRdLZN4SrmSD5QjiSdaazRxzgyh9Q0CDCVKlJUSJ4IbOzsVsZA6XYmQYrMS6TxZmdg3K OdABT0PgILrMAxOzGxPeB4kXK++aRJrPxOJCLssqhLeKgGyOSbcMlBENjXf4Ub57rM6w DtTe3qUgAvo9+HTQLkjryk7ZyckSGTsT0dV9CiUciynwuSS6yjeF2K/6H6/E4ZokWAC2 6YqA== MIME-Version: 1.0 Received: by 10.204.152.75 with SMTP id f11mr9384698bkw.136.1335943570095; Wed, 02 May 2012 00:26:10 -0700 (PDT) Received: by 10.204.197.67 with HTTP; Wed, 2 May 2012 00:26:10 -0700 (PDT) In-Reply-To: <20120502052811.GA71211@server.vk2pj.dyndns.org> References: <20120430210711.GA50280@server.vk2pj.dyndns.org> <4F9F8888.3030104@FreeBSD.org> <20120502052811.GA71211@server.vk2pj.dyndns.org> Date: Wed, 2 May 2012 09:26:10 +0200 Message-ID: From: Andreas Nilsson To: Peter Jeremy Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org, Matthew Seaman Subject: Re: ZFS with multiple boot/root pools 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, 02 May 2012 07:26:11 -0000 On Wed, May 2, 2012 at 7:28 AM, Peter Jeremy wrote: > On 2012-May-01 07:54:00 +0100, Matthew Seaman wrote: > >On 30/04/2012 22:07, Peter Jeremy wrote: > >> Can anyone suggest a way to configure a zpool or set of filesystems > >> so that they will only be mounted if the root filesystem is within > >> the zpool. > > > >Not exactly that, but this should suffice. > > It sounds good but I can't make it work. > > >Suppose your two pools are zpool1 and zpool2. You have several ZFSes on > >each pool, all of which should be set to the default[*] that they are > >all mounted relative to the top level ZFS -- either zpool1/ or zpool2/ > >-- so to avoid overlaps, all you need to do is mount the top level ZFS > >at a unique path. > > Yep. To go further, assume there are also zpool{1,2}/var filesystems, > one of which should be mounted as /var. The mountpoint for zpool{1,2}/var > can be one of: > A) legacy > This requires an entry in each /etc/fstab for /var > B) inherited > This depends on the value of mountpoint for zpool{1,2}: > a) legacy > Same as (A) above. > b) inherited > The mountpoint will be set to /zpool{1,2}/var > c) Set to some arbitrary value, say /foo > The mountpoint will be set to /foo/var > C) /var > This results is two /var filesystems unless one is marked > "canmount=noauto" > > >One way of doing this is to set the mountpoints for the top level > >zpool1/ and zpool2/ to legacy, and create /etc/fstab in each pool like so: > > > >in zpool1/ > > > >zpool1 / zfs rw 0 0 > >zpool2 /ROOT/zpool2 zfs rw 0 0 > > Following the breakdown above, this implies I'd also need an entry in > /etc/fstab: > zpool1/var /var zfs rw 0 0 > > >Another way of doing this is to realise that the vfs.root.mountfrom > >property in /boot/loader.conf overrides any internal settings in the > >zpools. This means that you can set the mountpoint for zpool1/ and > >zpool2/ to some distinct values, say, /ROOT/zpool1 and /ROOT/zpool2 > > Whilst this overrides the mountpoint for the root filesystem, it has > no effect on other filesystems in the pool. In particular, the > mountpoint for zpool1/var remains /zpool1/var and the "zfs mount -a" > fails because there's no /zpool1 > > >If vfs.root.mountfrom is set to zfs:zpool1 then that zpool will be > >mounted as the root filesystem at / and zpool1/usr, zpool1/var etc. etc. > >will all be mounted in the expected locations relative to that. > > Unfortunately my experiments on a 10-current box show this doesn't > happen. Inheriting a mountpoint means that the filesystem's > mountpoint is set to the parent's nominal mountpoint (ie zpool{1,2}), > not the actual mountpoint (ie /), with the filesystem name appended. > > >Apart from the wrinkle of having two different zpools, this is > >essentially how ZFS boot environments work. > > Except that beadm/manageBE does a lot of other juggling to switch > between BEs. > > >http://www.infracaninophile.co.uk/articles/install-on-zfs/ but there are > >several other treatments around. > > I've had a look through those notes and you are still specifying > mountpoints for (eg) zroot/ROOT/9.0-RELEASE/usr - which implies you > wind up with multiple /usr's mounted. > > -- > Peter Jeremy > Would it work for you to import the second pool with with the altroot property set? Like zpool import -o altroot=/zpool2 zpool2 /Andreas From owner-freebsd-fs@FreeBSD.ORG Wed May 2 07:50:37 2012 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 86DFD106566C for ; Wed, 2 May 2012 07:50:37 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id E51618FC0A for ; Wed, 2 May 2012 07:50:36 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [IPv6:2001:8b0:151:1:fa1e:dfff:feda:c0bb]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.5/8.14.5) with ESMTP id q427oTkN006781 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 2 May 2012 08:50:29 +0100 (BST) (envelope-from matthew@FreeBSD.org) X-DKIM: OpenDKIM Filter v2.5.2 smtp.infracaninophile.co.uk q427oTkN006781 Authentication-Results: smtp.infracaninophile.co.uk/q427oTkN006781; dkim=none (no signature); dkim-adsp=none Message-ID: <4FA0E73E.3030301@FreeBSD.org> Date: Wed, 02 May 2012 08:50:22 +0100 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: Peter Jeremy References: <20120430210711.GA50280@server.vk2pj.dyndns.org> <4F9F8888.3030104@FreeBSD.org> <20120502052811.GA71211@server.vk2pj.dyndns.org> In-Reply-To: <20120502052811.GA71211@server.vk2pj.dyndns.org> X-Enigmail-Version: 1.4.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB57439A5314CE16F1C25DEDA" X-Virus-Scanned: clamav-milter 0.97.4 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk Cc: freebsd-fs@FreeBSD.org Subject: Re: ZFS with multiple boot/root pools 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, 02 May 2012 07:50:37 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB57439A5314CE16F1C25DEDA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 02/05/2012 06:28, Peter Jeremy wrote: >> Apart from the wrinkle of having two different zpools, this is >> essentially how ZFS boot environments work. > Except that beadm/manageBE does a lot of other juggling to switch > between BEs. It does some other juggling, yes. Mostly to do with snapshotting and cloning and doing the trick to swap the roles of clone and original -- none of which would apply to your case with several zpools. >> >http://www.infracaninophile.co.uk/articles/install-on-zfs/ but there = are >> >several other treatments around. > I've had a look through those notes and you are still specifying > mountpoints for (eg) zroot/ROOT/9.0-RELEASE/usr - which implies you > wind up with multiple /usr's mounted. =20 Yes. That's deliberate, and /usr is treated as a special case, because I want to keep instances /usr/src and /usr/obj paired up with the BE built from them, and it makes things a lot easier if I can mount them early at /usr/src or /usr/obj in order to do the build. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --------------enigB57439A5314CE16F1C25DEDA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+g50UACgkQ8Mjk52CukIz8ugCfcxyHQaTXp6mn1Nshv5vC6HwX lrkAnRiFBB+9bVxCY8ZFBcNBVzG4/+J4 =pLEB -----END PGP SIGNATURE----- --------------enigB57439A5314CE16F1C25DEDA-- From owner-freebsd-fs@FreeBSD.ORG Wed May 2 09:11:42 2012 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 CC479106564A for ; Wed, 2 May 2012 09:11:42 +0000 (UTC) (envelope-from gkontos.mail@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7F4548FC12 for ; Wed, 2 May 2012 09:11:42 +0000 (UTC) Received: by vbmv11 with SMTP id v11so318472vbm.13 for ; Wed, 02 May 2012 02:11:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=8UEKCNN2okic4PX+ZXnhvUJ/NuUsHabelH7cMdAVXdA=; b=AaUqPfTHKDHiQUNN90VnJ7ci3fxTAhEHc0tdYkbKXMKoQl8OjUXgDucLyBhkXPGdpV /97jtroKxDJgRIAX47hIPp3N5NG6xYIdBeNjpi7AJwdolCxl20Lg1YH8a2M98cvl2+z/ QKHRr5bUtK0ZN5zsQgek2QTQSFxUhyTofvz8zCJlQT3xrYYNUhDPNQv9htXlp9LXwryh U+VpmrpT2QMcGSgxpo2BImGBY+OK2WB7w10qrEJxwGR0YmeutHi+cHYIBGTyXWPrGAxL MC0eg405TuiqUxLHMqG4sMjd4jRaLiW4W0Eq0lEXxIQW7yShBzJJzSo25Ez1vVcq5mIK 9icQ== MIME-Version: 1.0 Received: by 10.52.93.203 with SMTP id cw11mr23571642vdb.71.1335949901717; Wed, 02 May 2012 02:11:41 -0700 (PDT) Received: by 10.220.67.199 with HTTP; Wed, 2 May 2012 02:11:41 -0700 (PDT) In-Reply-To: <4FA0D844.8090105@brockmann-consult.de> References: <20120502063927.GA9559@johnny.reilly.home> <4FA0D844.8090105@brockmann-consult.de> Date: Wed, 2 May 2012 12:11:41 +0300 Message-ID: From: George Kontostanos To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: gpart labels - why arent't some showing up in /dev/gpt/? 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, 02 May 2012 09:11:42 -0000 On Wed, May 2, 2012 at 9:46 AM, Peter Maloney wrote: > I have the same problem. Any time you boot off a CD/DVD and use import -f > (and then don't export), or I guess use import -f a pool from anywhere, i= t > does that. I don't know any non-zfs causes for the problem. > > Here are some relevant /boot/loader.conf settings (I don't know how accur= ate > the comments are... I wrote them myself, without fully testing them): > > # Setting this to 0 will get rid of the /dev/gptid directory and you will > see your /dev/gpt directory again if it bugged out and gpt labels > disappeared. > #kern.geom.label.gptid.enable=3D0 > > # Not sure what this does; I assume it means to forget about /dev/gpt/* a= nd > probably either show gptid (if not disabled above) or the original device > name (eg. da0p2) > #kern.geom.label.gpt.enable=3D0 > > > However, that is a lame workaround, disabling a feature to get another ba= ck. > I would love to see a good fix. > > > > On 05/02/2012 08:39 AM, Andrew Reilly wrote: >> >> Hi there, >> >> I like being able to label my drives and partitions with gpart, >> so that I can (putatively) replace drives or move them around >> or have the new ata drivers move them around for me, and still >> have fstab find them. >> >> So, for example, I have (in fstab): >> /dev/gpt/root =A0 =A0 =A0 =A0 =A0 / =A0 =A0 =A0 =A0 =A0 =A0 =A0 ufs =A0 = =A0 rw,async,noatime 1 =A0 =A0 =A01 >> >> Which derives from an appropriate label on ada2p1: >> Geom name: ada2 >> modified: false >> state: OK >> fwheads: 16 >> fwsectors: 63 >> last: 117231374 >> first: 34 >> entries: 128 >> scheme: GPT >> Providers: >> 1. Name: ada2p1 >> =A0 =A0Mediasize: 65536 (64k) >> =A0 =A0Sectorsize: 512 >> =A0 =A0Stripesize: 0 >> =A0 =A0Stripeoffset: 17408 >> =A0 =A0Mode: r0w0e0 >> =A0 =A0rawuuid: 356aefc1-92a7-11e1-ae3f-00270e0fb8e9 >> =A0 =A0rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f >> =A0 =A0label: bootme >> =A0 =A0length: 65536 >> =A0 =A0offset: 17408 >> =A0 =A0type: freebsd-boot >> =A0 =A0index: 1 >> =A0 =A0end: 161 >> =A0 =A0start: 34 >> 2. Name: ada2p2 >> =A0 =A0Mediasize: 60022325248 (55G) >> =A0 =A0Sectorsize: 512 >> =A0 =A0Stripesize: 0 >> =A0 =A0Stripeoffset: 131072 >> =A0 =A0Mode: r1w1e2 >> =A0 =A0rawuuid: 9995b354-92a7-11e1-ae3f-00270e0fb8e9 >> =A0 =A0rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b >> =A0 =A0label: root >> =A0 =A0length: 60022325248 >> =A0 =A0offset: 131072 >> =A0 =A0type: freebsd-ufs >> =A0 =A0index: 2 >> =A0 =A0end: 117231359 >> =A0 =A0start: 256 >> Consumers: >> 1. Name: ada2 >> =A0 =A0Mediasize: 60022480896 (55G) >> =A0 =A0Sectorsize: 512 >> =A0 =A0Mode: r1w1e3 >> >> Back when I first built this computer, I similarly labelled the >> four freebsd-zfs partitions on my four main spinning disks, with >> the intention that I could use these names in a non-confusing >> way in subsequent zpool create commands. =A0This did work *once*, >> but after using the /dev/gpt/raidz0... names to create a raidz >> tank, they disappeared from /dev/gpt, and the names that showed >> up in zpool status output were the long strings of digits from >> the /dev/gptid/ directory. >> >> This week I had to blow my raid array and start from scratch, >> after zpool scrub proved itself incapable of fixing or removing >> the corruption that I have mentioned here earlier. =A0Even after >> clearing the disks of their zpool, the gpt names did not show up >> under /dev/gpt, so I have had to rebuild my zfs array with >> old-school partition names, like ada0p1 and so on. =A0This does >> work, but it seems a bit sub-optimal. >> >> Anyone know why the /dev/gpt/label name seems so tempramental, >> and what might be done to make it behave as I've expected? >> >> FWIW here is a gpart list of the first of the raid drives (the >> other three are essentially the same, but with the label digit >> incremented): >> >> Geom name: ada0 >> modified: false >> state: OK >> fwheads: 16 >> fwsectors: 63 >> last: 1953525134 >> first: 34 >> entries: 128 >> scheme: GPT >> Providers: >> 1. Name: ada0p1 >> =A0 =A0Mediasize: 1000204851712 (931G) >> =A0 =A0Sectorsize: 512 >> =A0 =A0Stripesize: 0 >> =A0 =A0Stripeoffset: 17408 >> =A0 =A0Mode: r1w1e1 >> =A0 =A0rawuuid: b06b6337-e511-11e0-9d62-00270e0fb8e9 >> =A0 =A0rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b >> =A0 =A0label: raidz1 >> =A0 =A0length: 1000204851712 >> =A0 =A0offset: 17408 >> =A0 =A0type: freebsd-zfs >> =A0 =A0index: 1 >> =A0 =A0end: 1953525134 >> =A0 =A0start: 34 >> Consumers: >> 1. Name: ada0 >> =A0 =A0Mediasize: 1000204886016 (931G) >> =A0 =A0Sectorsize: 512 >> =A0 =A0Mode: r1w1e2 >> >> and here's the entire contents of /dev/gpt: >> altroot backup backup3g bootme bootme2 root >> >> (no raidz1, etc.) >> >> Cheers, >> > > > -- > > -------------------------------------------- > Peter Maloney > Brockmann Consult > Max-Planck-Str. 2 > 21502 Geesthacht > Germany > Tel: +49 4152 889 300 > Fax: +49 4152 889 333 > E-mail: peter.maloney@brockmann-consult.de > Internet: http://www.brockmann-consult.de > -------------------------------------------- > > > _______________________________________________ > 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" You can always use: gpart show -l That should display the label. --=20 George Kontostanos Aicom telecoms ltd http://www.aisecure.net From owner-freebsd-fs@FreeBSD.ORG Wed May 2 09:29:08 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 050C4106566B for ; Wed, 2 May 2012 09:29:08 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) by mx1.freebsd.org (Postfix) with ESMTP id 63F868FC16 for ; Wed, 2 May 2012 09:29:07 +0000 (UTC) Received: from ackerman2.upc.es (ackerman2.upc.es [147.83.2.244]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id q429T33e003905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 2 May 2012 11:29:03 +0200 Received: from portgus.lan ([147.83.40.234]) (authenticated bits=0) by ackerman2.upc.es (8.14.4/8.14.4) with ESMTP id q429T2Is030613 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 2 May 2012 11:29:03 +0200 Message-ID: <4FA0FE82.4040600@entel.upc.edu> Date: Wed, 02 May 2012 11:29:38 +0200 From: =?ISO-8859-1?Q?Gustau_P=E9rez_i_Querol?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120422 Thunderbird/12.0 MIME-Version: 1.0 To: Peter Maloney References: <20120502063927.GA9559@johnny.reilly.home> <4FA0D844.8090105@brockmann-consult.de> In-Reply-To: <4FA0D844.8090105@brockmann-consult.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.70 on 147.83.2.244 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dash.upc.es [147.83.2.50]); Wed, 02 May 2012 11:29:04 +0200 (CEST) Cc: freebsd-fs@freebsd.org Subject: Re: gpart labels - why arent't some showing up in /dev/gpt/? 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, 02 May 2012 09:29:08 -0000 Al 02/05/2012 08:46, En/na Peter Maloney ha escrit: > I have the same problem. Any time you boot off a CD/DVD and use import > -f (and then don't export), or I guess use import -f a pool from > anywhere, it does that. I don't know any non-zfs causes for the problem. When doing the import -f, use -d /dev/gpt to force zpool to search for devices in /dev/gpt. That way the import will be done by gpt name, instead of by device name. From owner-freebsd-fs@FreeBSD.ORG Wed May 2 12:03:20 2012 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E16A1065675; Wed, 2 May 2012 12:03:20 +0000 (UTC) (envelope-from sukenwoo@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2B09A8FC24; Wed, 2 May 2012 12:03:20 +0000 (UTC) Received: by obcni5 with SMTP id ni5so1134141obc.13 for ; Wed, 02 May 2012 05:03:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=IawpFNJbS/NJ0RBQ3bkUH/ewp5nDlt9r6LG1RobEaMM=; b=Jdo/Ewx9JClxPa6TwbuCexBooLVJqTe7fY8NI8B8Zlw4tMGEGgJje9+741Ul7UgYth 4VnEDW3yhNNliPfGJGqPjmiBIgh6arHaOMu1oOgPX3uTr3LJuf/Fc4nVEYDp70h2mxlq 1wp79gK/qX1n93TZQiIZSQbqLvmIE4WbPxxwZgEjurBFMQKr4To0iZVckDOT8p6i4/VV Qa7c+nkhNxtj9e0eN2oMXMqgN+8bmzBpSTs8TbX8C5s7fJ7azKljhH5j59R6ERIT6hr8 aSStmcfrMQv7yFwwyH+SjWTYmIVeRDNzVQjEZmw/NtItvcceD+cYz5gYGeMu/ezauaPz lCJA== MIME-Version: 1.0 Received: by 10.60.13.37 with SMTP id e5mr39160668oec.70.1335960199433; Wed, 02 May 2012 05:03:19 -0700 (PDT) Received: by 10.182.49.71 with HTTP; Wed, 2 May 2012 05:03:19 -0700 (PDT) Date: Wed, 2 May 2012 20:03:19 +0800 Message-ID: From: suken woo To: fs@freebsd.org, current@freebsd.org, stable@freebsd.org, questions@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: urgent system suddenly boot failed due to ZFS:i/o error on FreeBSD 8.2 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, 02 May 2012 12:03:20 -0000 hi,lists for some reasons I need restart system but it suddenly boot failed today. here is the error: ZFS: i/o error - all block copies unavailable ZFS: can't read object set for dataset 16 Can't find root filesystem - giving up ZFS:unexcepted object set type 0 ZFS:unexcepted object set type 0 FreeBSD/i386 boot Default: zroot:/boot/kernel/kernel boot: ZFS:unexcepted object set type0 FreeBSD/i386 boot Default: zroot:/boot/kernel/kernel boot: _ any ideas to resolved it? thanks in advance From owner-freebsd-fs@FreeBSD.ORG Wed May 2 12:14:45 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1924E1065672 for ; Wed, 2 May 2012 12:14:45 +0000 (UTC) (envelope-from peter.maloney@brockmann-consult.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by mx1.freebsd.org (Postfix) with ESMTP id 9CDFB8FC0A for ; Wed, 2 May 2012 12:14:44 +0000 (UTC) Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0Mao5W-1Sjz1F2Dk2-00KOzE; Wed, 02 May 2012 14:14:43 +0200 Message-ID: <4FA12533.2080102@brockmann-consult.de> Date: Wed, 02 May 2012 14:14:43 +0200 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:P3vHf50V7542ESGR3w3IqkI4wF1SdiL9hSgJa10x4Xv k+/YVez2eqYDYj/n/QFceRVF9P2Mw+kiomPAUezkYZn+mhEPTN tsKchGiFZZ4K2REM0h/zHiaHOpO0kWLqva8FafHO+aiHXpMp2G bcc/jVAkfx9SVRVW7oxlR7gaud6R1Ygstg7ltYeKIyGVXXzQ0x UNz8z7zsH8C48MCQ0QcUGclIxe5q/GRQIjYaC6JJ9392mt6RCW OZ2kiCzbkvHFXejXwiIHwTRXsaLk0vDAa0EfS4XhFpd8m87hwE tcPzS+L3/jxCVIEOWizh4tWir32d8i/mFpawlpnVFBb8PDF2Sr 9t3dAI9azVDxM/TueGxOjCBg3xRfLuTRNbKPXt4/h Subject: Re: urgent system suddenly boot failed due to ZFS:i/o error on FreeBSD 8.2 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, 02 May 2012 12:14:45 -0000 This happened to me when my root pool had an active hot spare. I later tested it on a virtual machine, and even with non-spare disks added, the system did the same thing. Here is my PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=167065 kern/167065 My solution was to boot on a DVD, and then "zpool detach" the bad disk (which converted the spare to a normal mirror). On 05/02/2012 02:03 PM, suken woo wrote: > hi,lists > for some reasons I need restart system but it suddenly boot failed today. > here is the error: > ZFS: i/o error - all block copies unavailable > ZFS: can't read object set for dataset 16 > Can't find root filesystem - giving up > ZFS:unexcepted object set type 0 > ZFS:unexcepted object set type 0 > > FreeBSD/i386 boot > Default: zroot:/boot/kernel/kernel > boot: > ZFS:unexcepted object set type0 > > FreeBSD/i386 boot > Default: zroot:/boot/kernel/kernel > boot: _ > > any ideas to resolved it? > thanks in advance > _______________________________________________ > 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" -- -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str. 2 21502 Geesthacht Germany Tel: +49 4152 889 300 Fax: +49 4152 889 333 E-mail: peter.maloney@brockmann-consult.de Internet: http://www.brockmann-consult.de -------------------------------------------- From owner-freebsd-fs@FreeBSD.ORG Wed May 2 12:28:25 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6EB181065674 for ; Wed, 2 May 2012 12:28:25 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from lwfs1-cam.cam.lispworks.com (mail.lispworks.com [193.34.186.230]) by mx1.freebsd.org (Postfix) with ESMTP id F38BE8FC17 for ; Wed, 2 May 2012 12:28:24 +0000 (UTC) Received: from higson.cam.lispworks.com (higson [192.168.1.7]) by lwfs1-cam.cam.lispworks.com (8.14.3/8.14.3) with ESMTP id q42CHa6j070594; Wed, 2 May 2012 13:17:36 +0100 (BST) (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com (localhost.localdomain [127.0.0.1]) by higson.cam.lispworks.com (8.14.4) id q42CHast005068; Wed, 2 May 2012 13:17:36 +0100 Received: (from martin@localhost) by higson.cam.lispworks.com (8.14.4/8.14.4/Submit) id q42CHaPl005064; Wed, 2 May 2012 13:17:36 +0100 Date: Wed, 2 May 2012 13:17:36 +0100 Message-Id: <201205021217.q42CHaPl005064@higson.cam.lispworks.com> From: Martin Simmons To: freebsd-fs@freebsd.org In-reply-to: <4FA0E73E.3030301@FreeBSD.org> (message from Matthew Seaman on Wed, 02 May 2012 08:50:22 +0100) References: <20120430210711.GA50280@server.vk2pj.dyndns.org> <4F9F8888.3030104@FreeBSD.org> <20120502052811.GA71211@server.vk2pj.dyndns.org> <4FA0E73E.3030301@FreeBSD.org> Subject: Re: ZFS with multiple boot/root pools 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, 02 May 2012 12:28:25 -0000 >>>>> On Wed, 02 May 2012 08:50:22 +0100, Matthew Seaman said: > > On 02/05/2012 06:28, Peter Jeremy wrote: > > >> >http://www.infracaninophile.co.uk/articles/install-on-zfs/ but there are > >> >several other treatments around. > > > I've had a look through those notes and you are still specifying > > mountpoints for (eg) zroot/ROOT/9.0-RELEASE/usr - which implies you > > wind up with multiple /usr's mounted. > > Yes. That's deliberate, and /usr is treated as a special case, because > I want to keep instances /usr/src and /usr/obj paired up with the BE > built from them, and it makes things a lot easier if I can mount them > early at /usr/src or /usr/obj in order to do the build. It looks like /usr itself isn't a problem because it is never mounted (canmount=off on zroot/ROOT/9.0-RELEASE/usr and zroot/usr), but multiple mounts will happen for /usr/src and /usr/obj. Do you change the mountpoint property of zroot/ROOT/*/usr on the inactive BE's to avoid that? BTW, there is a minor bug in the article (on 8.3 at least): "zpool export zroot" fails to unmount everything because the cwd is in /tmp/zroot/etc at that point. Adding "cd /" beforehand fixes it. __Martin From owner-freebsd-fs@FreeBSD.ORG Wed May 2 12:29:29 2012 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 515E9106566B for ; Wed, 2 May 2012 12:29:29 +0000 (UTC) (envelope-from simon@optinet.com) Received: from cobra.acceleratedweb.net (cobra-gw.acceleratedweb.net [207.99.79.37]) by mx1.freebsd.org (Postfix) with SMTP id E123B8FC18 for ; Wed, 2 May 2012 12:29:28 +0000 (UTC) Received: (qmail 41827 invoked by uid 110); 2 May 2012 12:29:27 -0000 Received: from ool-4571afe7.dyn.optonline.net (HELO desktop1) (simon@optinet.com@69.113.175.231) by cobra.acceleratedweb.net with SMTP; 2 May 2012 12:29:27 -0000 From: "Simon" To: "suken woo" Date: Wed, 02 May 2012 08:29:20 -0400 Priority: Normal X-Mailer: PMMail 2000 Professional (2.20.2717) For Windows 2000 (5.1.2600;3) In-Reply-To: MIME-Version: 1.0 Message-Id: <20120502122929.515E9106566B@hub.freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "fs@freebsd.org" Subject: Re: urgent system suddenly boot failed due to ZFS:i/o error on FreeBSD 8.2 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, 02 May 2012 12:29:29 -0000 I'd boot using liveCD to see what's going on with the zpool, drive detection, and what the other person suggested as far as possible hot-spare issue. -Simon On Wed, 2 May 2012 20:03:19 +0800, suken woo wrote: >hi,lists > for some reasons I need restart system but it suddenly boot failed today. >here is the error: >ZFS: i/o error - all block copies unavailable >ZFS: can't read object set for dataset 16 >Can't find root filesystem - giving up >ZFS:unexcepted object set type 0 >ZFS:unexcepted object set type 0 >FreeBSD/i386 boot >Default: zroot:/boot/kernel/kernel >boot: >ZFS:unexcepted object set type0 >FreeBSD/i386 boot >Default: zroot:/boot/kernel/kernel >boot: _ >any ideas to resolved it? >thanks in advance >_______________________________________________ >freebsd-fs@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-fs >To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Wed May 2 12:43:12 2012 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 E4B03106566B for ; Wed, 2 May 2012 12:43:12 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id 4CE158FC0C for ; Wed, 2 May 2012 12:43:12 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [IPv6:2001:8b0:151:1:fa1e:dfff:feda:c0bb]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.5/8.14.5) with ESMTP id q42Ch8FR011361 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 2 May 2012 13:43:08 +0100 (BST) (envelope-from matthew@FreeBSD.org) X-DKIM: OpenDKIM Filter v2.5.2 smtp.infracaninophile.co.uk q42Ch8FR011361 Authentication-Results: smtp.infracaninophile.co.uk/q42Ch8FR011361; dkim=none (no signature); dkim-adsp=none Message-ID: <4FA12BD4.8080804@FreeBSD.org> Date: Wed, 02 May 2012 13:43:00 +0100 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: Martin Simmons References: <20120430210711.GA50280@server.vk2pj.dyndns.org> <4F9F8888.3030104@FreeBSD.org> <20120502052811.GA71211@server.vk2pj.dyndns.org> <4FA0E73E.3030301@FreeBSD.org> <201205021217.q42CHaPl005064@higson.cam.lispworks.com> In-Reply-To: <201205021217.q42CHaPl005064@higson.cam.lispworks.com> X-Enigmail-Version: 1.4.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig53FEAF80B5D4271C0F3434C7" X-Virus-Scanned: clamav-milter 0.97.4 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk Cc: freebsd-fs@FreeBSD.org Subject: Re: ZFS with multiple boot/root pools 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, 02 May 2012 12:43:13 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig53FEAF80B5D4271C0F3434C7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 02/05/2012 13:17, Martin Simmons wrote: > It looks like /usr itself isn't a problem because it is never mounted > (canmount=3Doff on zroot/ROOT/9.0-RELEASE/usr and zroot/usr), but multi= ple > mounts will happen for /usr/src and /usr/obj. Do you change the mountp= oint > property of zroot/ROOT/*/usr on the inactive BE's to avoid that? Yes, exactly. It's all described in the companion piece to install-on-zf= s: http://www.infracaninophile.co.uk/articles/zfs-update-management/ However, that page is in need of an update: I modified the manageBE script to automate a lot of the actions described there, and I've been intending to look at Bryan Drewery's beadm program as well. > BTW, there is a minor bug in the article (on 8.3 at least): "zpool expo= rt > zroot" fails to unmount everything because the cwd is in /tmp/zroot/etc= at > that point. Adding "cd /" beforehand fixes it. Hmmm.... yes. Fixed, thank you. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey --------------enig53FEAF80B5D4271C0F3434C7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+hK9wACgkQ8Mjk52CukIxNuQCdFDYVWL7Bl6AQ0ShpZ7FD7OqJ 9M8AnRsaF4m2f6Et818ae6WcMmsuFHlm =w5kI -----END PGP SIGNATURE----- --------------enig53FEAF80B5D4271C0F3434C7-- From owner-freebsd-fs@FreeBSD.ORG Wed May 2 13:05:13 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E9D6106564A for ; Wed, 2 May 2012 13:05:13 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id E5C728FC0A for ; Wed, 2 May 2012 13:05:12 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [IPv6:2001:8b0:151:1:fa1e:dfff:feda:c0bb]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.5/8.14.5) with ESMTP id q42D57Jn011737 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 2 May 2012 14:05:08 +0100 (BST) (envelope-from m.seaman@infracaninophile.co.uk) X-DKIM: OpenDKIM Filter v2.5.2 smtp.infracaninophile.co.uk q42D57Jn011737 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infracaninophile.co.uk; s=201001-infracaninophile; t=1335963908; bh=9XI65mnmjgIMEyBZ4ETjGl5OswDbSWr1csW9BU0jL58=; h=Date:From:To:Subject:References:In-Reply-To:Cc:Content-Type: Message-ID:Mime-Version; b=wUgEZBH6z8UdE6jw3UapsLx1mmeiNVAomdD3Anj153TeGNAWVOW53mPK1QNfrnzTB aVaInwTWdZPZI9R6c53cKx0AcnFSGwjjDGPPubOD7KCCqPHtXjNVKes13Ukmq+5Y5Z mBmAoz6VD+zLeBwlXu+xITZ9OhfvgNc4dDRRNWAw= Message-ID: <4FA13103.50304@infracaninophile.co.uk> Date: Wed, 02 May 2012 14:05:07 +0100 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <20120430210711.GA50280@server.vk2pj.dyndns.org> <4F9F8888.3030104@FreeBSD.org> <20120502052811.GA71211@server.vk2pj.dyndns.org> <4FA0E73E.3030301@FreeBSD.org> <201205021217.q42CHaPl005064@higson.cam.lispworks.com> <4FA12BD4.8080804@FreeBSD.org> In-Reply-To: <4FA12BD4.8080804@FreeBSD.org> X-Enigmail-Version: 1.4.1 OpenPGP: id=60AE908C Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig871E99A5E6BCF59DB800783E" X-Virus-Scanned: clamav-milter 0.97.4 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DKIM_ADSP_ALL,DKIM_SIGNED,T_DKIM_INVALID autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk Subject: Re: ZFS with multiple boot/root pools 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, 02 May 2012 13:05:13 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig871E99A5E6BCF59DB800783E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 02/05/2012 13:43, Matthew Seaman wrote: > However, that page is in need of an update: I modified the manageBE > script to automate a lot of the actions described there, and I've been > intending to look at Bryan Drewery's beadm program as well. Ooops. Slawomir Wojciech Wojtczak wrote beadm, Bryan just submitted it to the ports. Apologies. Matthew --=20 Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matthew@infracaninophile.co.uk Kent, CT11 9PW --------------enig871E99A5E6BCF59DB800783E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+hMQMACgkQ8Mjk52CukIxibQCfSBdOk97IWTVyc5qpiu2cMRJC iXUAnA5rdvC79uPkMWH6FMvnoHuZkJHT =MOGS -----END PGP SIGNATURE----- --------------enig871E99A5E6BCF59DB800783E-- From owner-freebsd-fs@FreeBSD.ORG Wed May 2 14:28:38 2012 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 363C0106566B for ; Wed, 2 May 2012 14:28:38 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from lwfs1-cam.cam.lispworks.com (mail.lispworks.com [193.34.186.230]) by mx1.freebsd.org (Postfix) with ESMTP id BA91E8FC14 for ; Wed, 2 May 2012 14:28:37 +0000 (UTC) Received: from higson.cam.lispworks.com (higson [192.168.1.7]) by lwfs1-cam.cam.lispworks.com (8.14.3/8.14.3) with ESMTP id q42ESYDQ082598; Wed, 2 May 2012 15:28:34 +0100 (BST) (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com (localhost.localdomain [127.0.0.1]) by higson.cam.lispworks.com (8.14.4) id q42ESY21006413; Wed, 2 May 2012 15:28:34 +0100 Received: (from martin@localhost) by higson.cam.lispworks.com (8.14.4/8.14.4/Submit) id q42ESY6f006409; Wed, 2 May 2012 15:28:34 +0100 Date: Wed, 2 May 2012 15:28:34 +0100 Message-Id: <201205021428.q42ESY6f006409@higson.cam.lispworks.com> From: Martin Simmons To: freebsd-fs@FreeBSD.org In-reply-to: <4FA12BD4.8080804@FreeBSD.org> (message from Matthew Seaman on Wed, 02 May 2012 13:43:00 +0100) References: <20120430210711.GA50280@server.vk2pj.dyndns.org> <4F9F8888.3030104@FreeBSD.org> <20120502052811.GA71211@server.vk2pj.dyndns.org> <4FA0E73E.3030301@FreeBSD.org> <201205021217.q42CHaPl005064@higson.cam.lispworks.com> <4FA12BD4.8080804@FreeBSD.org> Cc: Subject: Re: ZFS with multiple boot/root pools 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, 02 May 2012 14:28:38 -0000 >>>>> On Wed, 02 May 2012 13:43:00 +0100, Matthew Seaman said: > > Yes, exactly. It's all described in the companion piece to install-on-zfs: > > http://www.infracaninophile.co.uk/articles/zfs-update-management/ Nice work, thanks. __Martin From owner-freebsd-fs@FreeBSD.ORG Wed May 2 15:30:21 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 245A7106566B for ; Wed, 2 May 2012 15:30:21 +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 0DC2A8FC12 for ; Wed, 2 May 2012 15:30:21 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q42FUKpF059232 for ; Wed, 2 May 2012 15:30:20 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q42FUKH1059227; Wed, 2 May 2012 15:30:20 GMT (envelope-from gnats) Date: Wed, 2 May 2012 15:30:20 GMT Message-Id: <201205021530.q42FUKH1059227@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Marcelo Araujo Cc: Subject: Re: kern/167467: [ZFS] improve zdb(8) manpage and help. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Marcelo Araujo List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 15:30:21 -0000 The following reply was made to PR kern/167467; it has been noted by GNATS. From: Marcelo Araujo To: freebsd-gnats-submit@freebsd.org Cc: Subject: Re: kern/167467: [ZFS] improve zdb(8) manpage and help. Date: Wed, 2 May 2012 23:24:28 +0800 --bcaec5299ad98b695c04bf0f48fe Content-Type: multipart/alternative; boundary=bcaec5299ad98b695704bf0f48fc --bcaec5299ad98b695704bf0f48fc Content-Type: text/plain; charset=ISO-8859-1 Here is the final patch, I found some typos on the manpage and I fixed it. -- Marcelo Araujo araujo@FreeBSD.org --bcaec5299ad98b695704bf0f48fc Content-Type: text/html; charset=ISO-8859-1

Here is the final patch, I found some typos on the manpage and I fixed it.

--
Marcelo Araujo
araujo@FreeBSD.org
--bcaec5299ad98b695704bf0f48fc-- --bcaec5299ad98b695c04bf0f48fe Content-Type: text/plain; charset=US-ASCII; name="zdb.txt" Content-Disposition: attachment; filename="zdb.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h1qje3681 ZGlmZiAtciBiNDcwYTVkYjQzMGUgLXIgOWFjM2U3NTA0YmE4IGNkZGwvY29udHJpYi9vcGVuc29s YXJpcy9jbWQvemRiL3pkYi44Ci0tLSBhL2NkZGwvY29udHJpYi9vcGVuc29sYXJpcy9jbWQvemRi L3pkYi44CU1vbiBBcHIgMzAgMDY6MDI6MDAgMjAxMiArMDAwMAorKysgYi9jZGRsL2NvbnRyaWIv b3BlbnNvbGFyaXMvY21kL3pkYi96ZGIuOAlXZWQgTWF5IDAyIDE2OjE3OjU0IDIwMTIgKzA4MDAK QEAgLTE4LDU1ICsxOCw0NzkgQEAKIC5cIiBpbmZvcm1hdGlvbjogUG9ydGlvbnMgQ29weXJpZ2h0 IFt5eXl5XSBbbmFtZSBvZiBjb3B5cmlnaHQgb3duZXJdCiAuXCIKIC5cIiBDb3B5cmlnaHQgKGMp IDIwMDQsIFN1biBNaWNyb3N5c3RlbXMsIEluYy4gQWxsIFJpZ2h0cyBSZXNlcnZlZC4KKy5cIiBD b3B5cmlnaHQgMjAxMiwgUmljaGFyZCBMb3dlLgorLlwiIENvcHlyaWdodCAoYykgMjAxMiwgTWFy Y2VsbyBBcmF1am8gPGFyYXVqb0BGcmVlQlNELm9yZz4uCisuXCIgQWxsIFJpZ2h0cyBSZXNlcnZl ZC4KIC5cIgogLlwiICRGcmVlQlNEJAogLlwiCi0uRGQgTm92ZW1iZXIgMjYsIDIwMTEKKy5EZCBN YXkgMSwgMjAxMgogLkR0IFpEQiA4CiAuT3MKIC5TaCBOQU1FCiAuTm0gemRiCi0uTmQgWkZTIGRl YnVnZ2VyCisuTmQgRGlzcGxheSB6cG9vbCBkZWJ1Z2dpbmcgYW5kIGNvbnNpc3RlbmN5IGluZm9y bWF0aW9uCiAuU2ggU1lOT1BTSVMKIC5ObQotLkFyIHBvb2wKKy5PcCBGbCBDdW1kaWJjc0R2aExY RlBBCisuT3AgRmwgZSBPcCBGbCBwIEFyIHBhdGggT3AgLXQgQXIgdHhnCisuQXIgcG9vbG5hbWUK Ky5PcCBBciBvYmplY3QuLi4KKy5QCisKKy5ObQorLk9wIEZsIGRpdlBBCisuT3AgRmwgZSBPcCBG bCBwIEFyIHBhdGguLi4KK1stZGl2UEFdIFstZSBbLXAgLkFyIHBhdGguLi5dXQorLkFyIGRhdGFz ZXQgT3AgQXIgb2JqZWN0Li4uCisKKy5QCisuTm0KKy5GbCBtIE9wIEZsIExYRlBBIE9wIEZsIHQg QXIgdHhnCisuT3AgRmwgZSBPcCBGbCBwIEFyIHBhdGguLi4KKy5BciBwb29sbmFtZQorLk9wIEFy IHZkZXYgT3AgQXIgbWV0YXNsYWIuLi4KKworLlAKKy5ObQorLkZsIFIgT3AgRmwgQQorLk9wIEZs IGUgT3AgRmwgcCBBciBwYXRoLi4uCisuQXIgcG9vbG5hbWUKKy5BciB2ZGV2Om9mZnNldDpzaXpl WzpmbGFnc10KKworLlAKKy5ObQorLkZsIFMgT3AgRmwgQVAgCisuT3AgRmwgZSBPcCBGbCBwIEFy IHBhdGguLi4KKy5BciBwb29sbmFtZQorCisuUAorLk5tCisuRmwgbAorLk9wIEZsIHVhCisuQXIg ZGV2aWNlCisKKy5QCisuTm0KKy5GbCBDCisuT3AgRmwgQQorLk9wIEZsIFUgQXIgY2FjaGUKKwog LlNoIERFU0NSSVBUSU9OCiBUaGUKLS5ObQotY29tbWFuZCBpcyB1c2VkIGJ5IHN1cHBvcnQgZW5n aW5lZXJzIHRvIGRpYWdub3NlIGZhaWx1cmVzIGFuZAotZ2F0aGVyIHN0YXRpc3RpY3MuIFNpbmNl IHRoZQotLlRuIFpGUwotZmlsZSBzeXN0ZW0gaXMgYWx3YXlzIGNvbnNpc3RlbnQgb24gZGlzayBh bmQgaXMgc2VsZi1yZXBhaXJpbmcsCi0uTm0KLXNob3VsZCBvbmx5IGJlIHJ1biB1bmRlciB0aGUg ZGlyZWN0aW9uIGJ5IGEgc3VwcG9ydCBlbmdpbmVlci4KLS5QcAotSWYgbm8gYXJndW1lbnRzIGFy ZSBzcGVjaWZpZWQsCi0uTm0KLXBlcmZvcm1zIGJhc2ljIGNvbnNpc3RlbmN5IGNoZWNrcyBvbiB0 aGUgcG9vbCBhbmQgYXNzb2NpYXRlZCBkYXRhc2V0cywgYW5kCi1yZXBvcnQgYW55IHByb2JsZW1z IGRldGVjdGVkLgotLk5tCi1Bbnkgb3B0aW9ucyBzdXBwb3J0ZWQgYnkgdGhpcyBjb21tYW5kIGFy ZSBpbnRlcm5hbCB0byBTdW4gYW5kIHN1YmplY3QgdG8gY2hhbmdlCi1hdCBhbnkgdGltZS4KLS5T aCBFWElUIFNUQVRVUwotVGhlIGZvbGxvd2luZyBleGl0IHZhbHVlcyBhcmUgcmV0dXJuZWQ6Ci0u QmwgLXRhZyAtb2Zmc2V0IDJuIC13aWR0aCAybgotLkl0IDAKLVRoZSBwb29sIGlzIGNvbnNpc3Rl bnQuCi0uSXQgMQotQW4gZXJyb3Igd2FzIGRldGVjdGVkLgotLkl0IDIKLUludmFsaWQgY29tbWFu ZCBsaW5lIG9wdGlvbnMgd2VyZSBzcGVjaWZpZWQuCi0uRWwKKy5ObSAKK3V0aWxpdHkgZGlzcGxh eXMgaW5mb3JtYXRpb24gYWJvdXQgYSBaRlMgcG9vbCB1c2VmdWwgZm9yCitkZWJ1Z2dpbmcgYW5k IHBlcmZvcm1zIHNvbWUgYW1vdW50IG9mIGNvbnNpc3RlbmN5IGNoZWNraW5nLiBJdCBpcyBhIG5v dCBhCitnZW5lcmFsIHB1cnBvc2UgdG9vbCBhbmQgb3B0aW9ucyAoYW5kIGZhY2lsaXRpZXMpIG1h eSBjaGFuZ2UuIFRoaXMgaXMgbmVpdGhlcgorYSBmc2NrKDFNKSBub3IgYW4gZnNkYigxTSkgdXRp bGl0eS4KKy5wCitUaGUgb3V0cHV0IG9mIHRoaXMgY29tbWFuZCBpbiBnZW5lcmFsIHJlZmxlY3Rz IHRoZSBvbi1kaXNrIHN0cnVjdHVyZSBvZiBhIFpGUworcG9vbCwgYW5kIGlzIGluaGVyZW50bHkg dW5zdGFibGUuIFRoZSBwcmVjaXNlIG91dHB1dCBvZiBtb3N0IGludm9jYXRpb25zIGlzCitub3Qg ZG9jdW1lbnRlZCwgYSBrbm93bGVkZ2Ugb2YgWkZTIGludGVybmFscyBpcyBhc3N1bWVkLgorLnAK K1doZW4gb3BlcmF0aW5nIG9uIGFuIGltcG9ydGVkIGFuZCBhY3RpdmUgcG9vbCBpdCBpcyBwb3Nz aWJsZSwgdGhvdWdoIHVubGlrZWx5LAordGhhdCB6ZGIgbWF5IGludGVycHJldCBpbmNvbnNpc3Rl bnQgcG9vbCBkYXRhIGFuZCBiZWhhdmUgZXJyYXRpY2FsbHkuCisuU2ggT1BUSU9OUworRGlzcGxh eSBvcHRpb25zOgorLnNwCisubmUgMgorLm5hCisuRmwgYgorLmFkCisuc3AgLjYKKy5SUyA0bgor RGlzcGxheSBzdGF0aXN0aWNzIHJlZ2FyZGluZyB0aGUgbnVtYmVyLCBzaXplIChsb2dpY2FsLCBw aHlzaWNhbCBhbmQKK2FsbG9jYXRlZCkgYW5kIGRlZHVwbGljYXRpb24gb2YgYmxvY2tzLgorLlJF Cisuc3AKKy5uZSAyCisubmEKKy5GbCBjCisuYWQKKy5zcCAuNgorLlJTIDRuCitWZXJpZnkgdGhl IGNoZWNrc3VtIG9mIGFsbCBtZXRhZGF0YSBibG9ja3Mgd2hpbGUgcHJpbnRpbmcgYmxvY2sgc3Rh dGlzdGljcworKHNlZSAtYikuCisuc3AKK0lmIHNwZWNpZmllZCBtdWx0aXBsZSB0aW1lcywgdmVy aWZ5IHRoZSBjaGVja3N1bXMgb2YgYWxsIGJsb2Nrcy4KKy5SRQorLnNwCisubmUgMgorLm5hCisu RmwgQworLmFkCisuc3AgLjYKKy5SUyA0bgorRGlzcGxheSBpbmZvcm1hdGlvbiBhYm91dCB0aGUg Y29uZmlndXJhdGlvbi4gSWYgc3BlY2lmaWVkIHdpdGggbm8gb3RoZXIKK29wdGlvbnMsIGluc3Rl YWQgZGlzcGxheSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgY2FjaGUgZmlsZQorKC9ldGMvemZzL3pw b29sLmNhY2hlKS4gVG8gc3BlY2lmeSB0aGUgY2FjaGUgZmlsZSB0byBkaXNwbGF5LCBzZWUKKy5G bCBVCisuUAorSWYgc3BlY2lmaWVkIG11bHRpcGxlIHRpbWVzLCBhbmQgYSBwb29sIG5hbWUgaXMg YWxzbyBzcGVjaWZpZWQgZGlzcGxheSBib3RoCit0aGUgY2FjaGVkIGNvbmZpZ3VyYXRpb24gYW5k IHRoZSBvbi1kaXNrIGNvbmZpZ3VyYXRpb24uICBJZiBzcGVjaWZpZWQgbXVsdGlwbGUKK3RpbWVz IHdpdGggLWUgYWxzbyBkaXNwbGF5IHRoZSBjb25maWd1cmF0aW9uIHRoYXQgd291bGQgYmUgdXNl ZCB3ZXJlIHRoZQorcG9vbCB0byBiZSBpbXBvcnRlZC4KKy5SRQorLnNwCisubmUgMgorLm5hCisu RmwgZAorLmFkCisuc3AgLjYKKy5SUyA0bgorRGlzcGxheSBpbmZvcm1hdGlvbiBhYm91dCBkYXRh c2V0cy4gU3BlY2lmaWVkIG9uY2UsIGRpc3BsYXlzIGJhc2ljIGRhdGFzZXQKK2luZm9ybWF0aW9u OiBJRCwgY3JlYXRlIHRyYW5zYWN0aW9uLCBzaXplLCBhbmQgb2JqZWN0IGNvdW50LgorLnNwCitJ ZiBzcGVjaWZpZWQgbXVsdGlwbGUgdGltZXMgcHJvdmlkZXMgZ3JlYXRlciBhbmQgZ3JlYXRlciB2 ZXJib3NpdHkuCisuc3AKK0lmIG9iamVjdCBJRHMgYXJlIHNwZWNpZmllZCwgZGlzcGxheSBpbmZv cm1hdGlvbiBhYm91dCB0aG9zZSBzcGVjaWZpYyBvYmplY3RzIG9ubHkuCisuUkUKKy5zcAorLm5l IDIKKy5uYQorLkZsIEQKKy5hZAorLnNwIC42CisuUlMgNG4KK0Rpc3BsYXkgZGVkdXBsaWNhdGlv biBzdGF0aXN0aWNzLCBpbmNsdWRpbmcgdGhlIGRlZHVwbGljYXRpb24gcmF0aW8gKGRlZHVwKSwK K2NvbXByZXNzaW9uIHJhdGlvIChjb21wcmVzcyksIGluZmxhdGlvbiBkdWUgdG8gdGhlIHpmcyBj b3BpZXMgcHJvcGVydHkKKyhjb3BpZXMpLCBhbmQgYW4gb3ZlcmFsbCBlZmZlY3RpdmUgcmF0aW8g KGRlZHVwICogY29tcHJlc3MgLyBjb3BpZXMpLgorLnNwCitJZiBzcGVjaWZpZWQgdHdpY2UsIGRp c3BsYXkgYSBoaXN0b2dyYW0gb2YgZGVkdXBsaWNhdGlvbiBzdGF0aXN0aWNzLCBzaG93aW5nCit0 aGUgYWxsb2NhdGVkIChwaHlzaWNhbGx5IHByZXNlbnQgb24gZGlzaykgYW5kIHJlZmVyZW5jZWQg KGxvZ2ljYWxseQorcmVmZXJlbmNlZCBpbiB0aGUgcG9vbCkgYmxvY2sgY291bnRzIGFuZCBzaXpl cyBieSByZWZlcmVuY2UgY291bnQuCisuUkUKKy5zcAorLm5lIDIKKy5uYQorLkZsIGgKKy5hZAor LnNwIC42CisuUlMgNG4KK0Rpc3BsYXkgcG9vbCBoaXN0b3J5IHNpbWlsYXIgdG8genBvb2wgaGlz dG9yeSwgYnV0IGluY2x1ZGUgaW50ZXJuYWwKK2NoYW5nZXMsIHRyYW5zYWN0aW9uLCBhbmQgZGF0 YXNldCBpbmZvcm1hdGlvbi4KKy5SRQorLnNwCisubmUgMgorLm5hCisuRmwgaQorLmFkCisuc3Ag LjYKKy5SUyA0bgorRGlzcGxheSBpbmZvcm1hdGlvbiBhYm91dCBpbnRlbnQgbG9nIChaSUwpIGVu dHJpZXMgcmVsYXRpbmcgdG8gZWFjaAorZGF0YXNldC4gSWYgc3BlY2lmaWVkIG11bHRpcGxlIHRp bWVzLCBkaXNwbGF5IGNvdW50cyBvZiBlYWNoIGludGVudCBsb2cKK3RyYW5zYWN0aW9uIHR5cGUu CisuUkUKKy5zcAorLm5lIDIKKy5uYQorLkZsIGwgQXIgZGV2aWNlCisuYWQKKy5zcCAuNgorLlJT IDRuCitEaXNwbGF5IHRoZSB2ZGV2IGxhYmVscyBmcm9tIHRoZSBzcGVjaWZpZWQgZGV2aWNlLiBJ ZiB0aGUgLXUgb3B0aW9uIGlzCithbHNvIHNwZWNpZmllZCwgYWxzbyBkaXNwbGF5IHRoZSB1YmVy YmxvY2tzIG9uIHRoaXMgZGV2aWNlLgorLlJFCisuc3AKKy5uZSAyCisubmEKKy5GbCBMCisuYWQK Ky5zcCAuNgorLlJTIDRuCitEaXNhYmxlIGxlYWsgdHJhY2luZyBhbmQgdGhlIGxvYWRpbmcgb2Yg c3BhY2UgbWFwcy4gIEJ5IGRlZmF1bHQsIHpkYiAKK3ZlcmlmaWVzIHRoYXQgYWxsIG5vbi1mcmVl IGJsb2NrcyBhcmUgcmVmZXJlbmNlZCwgd2hpY2ggY2FuIGJlIHZlcnkgZXhwZW5zaXZlLgorLlJF Cisuc3AKKy5uZSAyCisubmEKKy5GbCBtCisuYWQKKy5zcCAuNgorLlJTIDRuCitEaXNwbGF5IHRo ZSBvZmZzZXQsIHNwYWNlbWFwLCBhbmQgZnJlZSBzcGFjZSBvZiBlYWNoIG1ldGFzbGFiLgorV2hl biBzcGVjaWZpZWQgdHdpY2UsIGFsc28gZGlzcGxheSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgbWF4 aW11bSBjb250aWd1b3VzCitmcmVlIHNwYWNlIGFuZCB0aGUgcGVyY2VudGFnZSBvZiBmcmVlIHNw YWNlIGluIGVhY2ggc3BhY2UgbWFwLiAgV2hlbiBzcGVjaWZpZWQKK3RocmVlIHRpbWVzIGRpc3Bs YXkgZXZlcnkgc3BhY2VtYXAgcmVjb3JkLgorLlJFCisuc3AKKy5uZSAyCisubmEKKy5GbCBSIEFy IHBvb2xuYW1lIEFyIHZkZXY6b2Zmc2V0OnNpemVbOmZsYWdzXQorLmFkCisuc3AgLjYKKy5SUyA0 bgorUmVhZCBhbmQgZGlzcGxheSBhIGJsb2NrIGZyb20gdGhlIHNwZWNpZmllZCBkZXZpY2UuIEJ5 IGRlZmF1bHQgdGhlIGJsb2NrIGlzCitkaXNwbGF5ZWQgYXMgYSBoZXggZHVtcCwgYnV0IHNlZSB0 aGUgZGVzY3JpcHRpb24gb2YgdGhlIFwnclwnIGZsYWcsIGJlbG93LgorLnNwCitUaGUgYmxvY2sg aXMgc3BlY2lmaWVkIGluIHRlcm1zIG9mIGEgY29sb24tc2VwYXJhdGVkIHR1cGxlIAorLkFyIHZk ZXYgCisoYW4gaW50ZWdlciB2ZGV2IGlkZW50aWZpZXIpIAorLkFyIG9mZnNldCAKKyh0aGUgb2Zm c2V0IHdpdGhpbiB0aGUgdmRldikKKy5BciBzaXplCisodGhlIHNpemUgb2YgdGhlIGJsb2NrIHRv IHJlYWQpIGFuZCwgb3B0aW9uYWxseSwgCisuQXIgZmxhZ3MgCisoYSBzZXQgb2YgZmxhZ3MsIGRl c2NyaWJlZCBiZWxvdykuCisuc3AKKy5uZSAyCisubmEKKy5pbiArNAorXGZCYlxmUiBcZklvZmZz ZXRcZlIKKy5hZAorLnNwIC42CisuUlMgNG4KK1ByaW50IGJsb2NrIHBvaW50ZXIKKy5SRQorLnNw CisubmUgMgorLm5hCitcZkJkXGZSCisuYWQKKy5zcCAuNgorLlJTIDRuCitEZWNvbXByZXNzIHRo ZSBibG9jaworLlJFCisuc3AKKy5uZSAyCisubmEKK1xmQmVcZlIKKy5hZAorLnNwIC42CisuUlMg NG4KK0J5dGUgc3dhcCB0aGUgYmxvY2sKKy5SRQorLnNwCisubmUgMgorLm5hCitcZkJnXGZSCisu YWQKKy5zcCAuNgorLlJTIDRuCitEdW1wIGdhbmcgYmxvY2sgaGVhZGVyCisuUkUKKy5zcAorLm5l IDIKKy5uYQorXGZCaVxmUgorLmFkCisuc3AgLjYKKy5SUyA0bgorRHVtcCBpbmRpcmVjdCBibG9j aworLlJFCisuc3AKKy5uZSAyCisubmEKK1xmQnJcZlIKKy5hZAorLnNwIC42CisuUlMgNG4KK0R1 bXAgcmF3IHVuaW50ZXJwcmV0ZWQgYmxvY2sgZGF0YQorLlJFCisuUkUKKy5zcAorLm5lIDIKKy5u YQorLmluIC00CisuRmwgcworLmFkCisuc3AgLjYKKy5SUyA0bgorUmVwb3J0IHN0YXRpc3RpY3Mg b24gemRiXCdzIEkvTy4gRGlzcGxheSBvcGVyYXRpb24gY291bnRzLCBiYW5kd2lkdGgsCithbmQg ZXJyb3IgY291bnRzIG9mIEkvTyB0byB0aGUgcG9vbCBmcm9tIHpkYi4KKy5SRQorLnNwCisubmUg MgorLm5hCisuRmwgUworLmFkCisuc3AgLjYKKy5SUyA0bgorU2ltdWxhdGUgdGhlIGVmZmVjdHMg b2YgZGVkdXBsaWNhdGlvbiwgY29uc3RydWN0aW5nIGEgRERUIGFuZCB0aGVuIGRpc3BsYXkKK3Ro YXQgRERUIGFzIHdpdGggLURELgorLlJFCisuc3AKKy5uZSAyCisubmEKKy5GbCB1CisuYWQKKy5z cCAuNgorLlJTIDRuCitEaXNwbGF5IHRoZSBjdXJyZW50IHViZXJibG9jay4KKy5SRQorLlAKK090 aGVyIG9wdGlvbnM6Cisuc3AKKy5uZSAyCisubmEKKy5GbCBBCisuYWQKKy5zcCAuNgorLlJTIDRu CitEbyBub3QgYWJvcnQgc2hvdWxkIGFueSBhc3NlcnRpb24gZmFpbC4KKy5SRQorLnNwCisubmUg MgorLm5hCisuRmwgQUEKKy5hZAorLnNwIC42CisuUlMgNG4KK0VuYWJsZSBwYW5pYyByZWNvdmVy eSwgY2VydGFpbiBlcnJvcnMgd2hpY2ggd291bGQgb3RoZXJ3aXNlIGJlIGZhdGFsIGFyZQorZGVt b3RlZCB0byB3YXJuaW5ncy4KKy5SRQorLnNwCisubmUgMgorLm5hCisuRmwgQUFBCisuYWQKKy5z cCAuNgorLlJTIDRuCitEbyBub3QgYWJvcnQgaWYgYXNzZXJ0cyBmYWlsIGFuZCBhbHNvIGVuYWJs ZSBwYW5pYyByZWNvdmVyeS4KKy5SRQorLnNwCisubmUgMgorLm5hCisuRmwgZSBPcCBGbCBwIEFy IHBhdGguLi4KKy5hZAorLnNwIC42CisuUlMgNG4KK09wZXJhdGUgb24gYW4gZXhwb3J0ZWQgcG9v bCwgbm90IHByZXNlbnQgaW4gL2V0Yy96ZnMvenBvb2wuY2FjaGUuIFRoZQorLXAgZmxhZyBzcGVj aWZpZXMgdGhlIHBhdGggdW5kZXIgd2hpY2ggZGV2aWNlcyBhcmUgdG8gYmUgc2VhcmNoZWQuCisu UkUKKy5zcAorLm5lIDIKKy5uYQorLkZsIEYKKy5hZAorLnNwIC42CisuUlMgNG4KK0F0dGVtcHQg dG8gbWFrZSBhbiB1bnJlYWRhYmxlIHBvb2wgcmVhZGFibGUgYnkgdHJ5aW5nIHByb2dyZXNzaXZl bHkgb2xkZXIKK3RyYW5zYWN0aW9ucy4KKy5SRQorLnNwCisubmUgMgorLm5hCisuRmwgUAorLmFk Cisuc3AgLjYKKy5SUyA0bgorUHJpbnQgbnVtYmVycyBpbiBhbiB1bnNjYWxlZCBmb3JtIG1vcmUg YW1lbmFibGUgdG8gcGFyc2luZywgZWcuIDEwMDAwMDAgcmF0aGVyCit0aGFuIDFNLgorLlJFCisu c3AKKy5uZSAyCisubmEKKy5GbCB0IEFyIHRyYW5zYWN0aW9uCisuYWQKKy5zcCAuNgorLlJTIDRu CitTcGVjaWZ5IHRoZSBoaWdoZXN0IHRyYW5zYWN0aW9uIHRvIHVzZSB3aGVuIHNlYXJjaGluZyBm b3IgdWJlcmJsb2Nrcy4gU2VlIGFsc28KK3RoZSAtdSBhbmQgLWwgb3B0aW9ucyBmb3IgYSBtZWFu cyB0byBzZWUgdGhlIGF2YWlsYWJsZSB1YmVyYmxvY2tzCithbmQgdGhlaXIgYXNzb2NpYXRlZCB0 cmFuc2FjdGlvbiBudW1iZXJzLgorLlJFCisuc3AKKy5uZSAyCisubmEKKy5GbCBVIEFyIGNhY2hl ZmlsZQorLmFkCisuc3AgLjYKKy5SUyA0bgorVXNlIGEgY2FjaGUgZmlsZSBvdGhlciB0aGFuIC9l dGMvemZzL3pwb29sLmNhY2hlLiBUaGlzIG9wdGlvbiBpcyBvbmx5Cit2YWxpZCB3aXRoIC1DCisu UkUKKy5zcAorLm5lIDIKKy5uYQorLkZsIHYKKy5hZAorLnNwIC42CisuUlMgNG4KK0VuYWJsZSB2 ZXJib3NpdHkuIFNwZWNpZnkgbXVsdGlwbGUgdGltZXMgZm9yIGluY3JlYXNlZCB2ZXJib3NpdHku CisuUkUKKy5zcAorLm5lIDIKKy5uYQorLkZsIFgKKy5hZAorLnNwIC42CisuUlMgNG4KK0F0dGVt cHQgXCdleHRyZW1lXCcgdHJhbnNhY3Rpb24gcmV3aW5kLCB0aGF0IGlzIGF0dGVtcHQgdGhlIHNh bWUgcmVjb3ZlcnkgYXMKKy1GIGJ1dCByZWFkIHRyYW5zYWN0aW9ucyBvdGhlcndpc2UgZGVlbWVk IHRvbyBvbGQuCisuUkUKKy5QCitTcGVjaWZ5aW5nIGEgZGlzcGxheSBvcHRpb24gbW9yZSB0aGFu IG9uY2UgZW5hYmxlcyB2ZXJib3NpdHkgZm9yIG9ubHkgdGhhdAorb3B0aW9uLCB3aXRoIG1vcmUg b2NjdXJyZW5jZXMgZW5hYmxpbmcgbW9yZSB2ZXJib3NpdHkuCisuUAorSWYgbm8gb3B0aW9ucyBh cmUgc3BlY2lmaWVkLCBhbGwgaW5mb3JtYXRpb24gYWJvdXQgdGhlIG5hbWVkIHBvb2wgd2lsbCBi ZQorZGlzcGxheWVkIGF0IGRlZmF1bHQgdmVyYm9zaXR5LgorLlNoIEVYQU1QTEVTCisuTHAKK0V4 YW1wbGUgMTogRGlzcGxheSB0aGUgY29uZmlndXJhdGlvbiBvZiBpbXBvcnRlZCBwb29sICdycG9v bCcKKy5zcAorLmluICsyCisubmYKKyMgemRiIC1DIHJwb29sCitNT1MgQ29uZmlndXJhdGlvbjoK KyAgICAgICAgdmVyc2lvbjogMjgKKyAgICAgICAgbmFtZTogJ3Jwb29sJworIC4uLgorLmZpCisu aW4gLTIKKy5zcAorLkxwCitFeGFtcGxlIDI6IERpc3BsYXkgYmFzaWMgZGF0YXNldCBpbmZvcm1h dGlvbiBhYm91dCAncnBvb2wnCisuc3AKKy5pbiArMgorLm5mCisjIHpkYiAtZCBycG9vbAorRGF0 YXNldCBtb3MgW01FVEFdLCBJRCAwLCBjcl90eGcgNCwgMjYuOU0sIDEwNTEgb2JqZWN0cworRGF0 YXNldCBycG9vbC9zd2FwIFtaVk9MXSwgSUQgNTksIGNyX3R4ZyAzNTYsIDQ4Nk0sIDIgb2JqZWN0 cworIC4uLgorLmZpCisuaW4gLTIKKy5zcAorLkxwCitFeGFtcGxlIDM6IERpc3BsYXkgYmFzaWMg aW5mb3JtYXRpb24gYWJvdXQgb2JqZWN0IDAgaW4KKydycG9vbC9leHBvcnQvaG9tZScKKy5zcAor LmluICsyCisubmYKKyMgemRiIC1kIHJwb29sL2V4cG9ydC9ob21lIDAKK0RhdGFzZXQgcnBvb2wv ZXhwb3J0L2hvbWUgW1pQTF0sIElEIDEzNywgY3JfdHhnIDE1NDYsIDMySywgOCBvYmplY3RzCisg ICAgT2JqZWN0ICBsdmwgICBpYmxrICAgZGJsayAgZHNpemUgIGxzaXplICAgJWZ1bGwgIHR5cGUK KyAgICAgICAgIDAgICAgNyAgICAxNksgICAgMTZLICAxNS4wSyAgICAxNksgICAyNS4wMCAgRE1V IGRub2RlCisuZmkKKy5pbiAtMgorLnNwCisuTHAKK0V4YW1wbGUgNDogRGlzcGxheSB0aGUgcHJl ZGljdGVkIGVmZmVjdCBvZiBlbmFibGluZyBkZWR1cGxpY2F0aW9uIG9uICdycG9vbCcKKy5zcAor LmluICsyCisubmYKKyMgemRiIC1TIHJwb29sCitTaW11bGF0ZWQgRERUIGhpc3RvZ3JhbToKK2J1 Y2tldCAgICAgICAgICAgICAgYWxsb2NhdGVkICAgICAgICAgICAgICAgICAgICAgICByZWZlcmVu Y2VkICAgICAgICAgIAorX19fX19fICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fICAg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCityZWZjbnQgICBibG9ja3MgICBMU0laRSAg IFBTSVpFICAgRFNJWkUgICBibG9ja3MgICBMU0laRSAgIFBTSVpFICAgRFNJWkUKKy0tLS0tLSAg IC0tLS0tLSAgIC0tLS0tICAgLS0tLS0gICAtLS0tLSAgIC0tLS0tLSAgIC0tLS0tICAgLS0tLS0g ICAtLS0tLQorICAgICAxICAgICA2OTRLICAgMjcuMUcgICAxNS4wRyAgIDE1LjBHICAgICA2OTRL ICAgMjcuMUcgICAxNS4wRyAgIDE1LjBHCisgICAgIDIgICAgMzUuMEsgICAxLjMzRyAgICA2OTlN ICAgIDY5OU0gICAgNzQuN0sgICAyLjc5RyAgIDEuNDVHICAgMS40NUcKKyAuLi4KK2RlZHVwID0g MS4xMSwgY29tcHJlc3MgPSAxLjgwLCBjb3BpZXMgPSAxLjAwLCBkZWR1cCAqIGNvbXByZXNzIC8g Y29waWVzID0gMi4wMAorLmZpCisuaW4gLTIKKy5zcAogLlNoIFNFRSBBTFNPCi0uWHIgemZzIDgg LAorLlhyIHpmcyA4LAogLlhyIHpwb29sIDgKIC5TaCBBVVRIT1JTCiBUaGlzIG1hbnVhbCBwYWdl IGlzIGEKIC5YciBtZG9jIDcKLXJlaW1wbGVtZW50YXRpb24gb2YgdGhlCityZWltcGxlbWVudGF0 aW9uIG9mCiAuVG4gT3BlblNvbGFyaXMKIG1hbnVhbCBwYWdlCi0uRW0gemRiKDFNKSAsCisuRW0g emRiKDFNKSwKIG1vZGlmaWVkIGFuZCBjdXN0b21pemVkIGZvcgogLkZ4CiBhbmQgbGljZW5zZWQg dW5kZXIgdGhlCmRpZmYgLXIgYjQ3MGE1ZGI0MzBlIC1yIDlhYzNlNzUwNGJhOCBjZGRsL2NvbnRy aWIvb3BlbnNvbGFyaXMvY21kL3pkYi96ZGIuYwotLS0gYS9jZGRsL2NvbnRyaWIvb3BlbnNvbGFy aXMvY21kL3pkYi96ZGIuYwlNb24gQXByIDMwIDA2OjAyOjAwIDIwMTIgKzAwMDAKKysrIGIvY2Rk bC9jb250cmliL29wZW5zb2xhcmlzL2NtZC96ZGIvemRiLmMJV2VkIE1heSAwMiAxNjoxNzo1NCAy MDEyICswODAwCkBAIC0xMDIsMTMgKzEwMiwxNiBAQAogdXNhZ2Uodm9pZCkKIHsKIAkodm9pZCkg ZnByaW50ZihzdGRlcnIsCi0JICAgICJVc2FnZTogJXMgWy1DdW1kaWJjc0R2aExdIHBvb2xuYW1l IFtvYmplY3QuLi5dXG4iCi0JICAgICIgICAgICAgJXMgWy1kaXZdIGRhdGFzZXQgW29iamVjdC4u Ll1cbiIKLQkgICAgIiAgICAgICAlcyAtbSBbLUxdIHBvb2xuYW1lIFt2ZGV2IFttZXRhc2xhYi4u Ll1dXG4iCi0JICAgICIgICAgICAgJXMgLVIgcG9vbG5hbWUgdmRldjpvZmZzZXQ6c2l6ZVs6Zmxh Z3NdXG4iCi0JICAgICIgICAgICAgJXMgLVMgcG9vbG5hbWVcbiIKLQkgICAgIiAgICAgICAlcyAt bCBbLXVdIGRldmljZVxuIgotCSAgICAiICAgICAgICVzIC1DXG5cbiIsCisgICAgICAgICAgICAi VXNhZ2U6ICVzIFstQ3VtZGliY3NEdmhMWEZQQV0gWy10IHR4Z10gWy1lIFstcCBwYXRoLi4uXV0i CisgICAgICAgICAgICAicG9vbG5hbWUgW29iamVjdC4uLl1cbiIKKyAgICAgICAgICAgICIgICAg ICAgJXMgWy1kaXZQQV0gWy1lIC1wIHBhdGguLi5dIGRhdGFzZXQgW29iamVjdC4uLl1cbiIKKyAg ICAgICAgICAgICIgICAgICAgJXMgLW0gWy1MWEZQQV0gWy10IHR4Z10gWy1lIFstcCBwYXRoLi4u XV0iCisgICAgICAgICAgICAicG9vbG5hbWUgW3ZkZXYgW21ldGFzbGFiLi4uXV1cbiIKKyAgICAg ICAgICAgICIgICAgICAgJXMgLVIgWy1BXSBbLWUgWy1wIHBhdGguLi5dXSBwb29sbmFtZSAiCisg ICAgICAgICAgICAidmRldjpvZmZzZXQ6c2l6ZVs6ZmxhZ3NdXG4iCisgICAgICAgICAgICAiICAg ICAgICVzIC1TIFstUEFdIFstZSBbLXAgcGF0aC4uLl1dIHBvb2xuYW1lXG4iCisgICAgICAgICAg ICAiICAgICAgICVzIC1sIFstdUFdIGRldmljZVxuIgorICAgICAgICAgICAgIiAgICAgICAlcyAt QyBbLUFdIFstVSBjb25maWddXG5cbiIsCiAJICAgIGNtZG5hbWUsIGNtZG5hbWUsIGNtZG5hbWUs IGNtZG5hbWUsIGNtZG5hbWUsIGNtZG5hbWUsIGNtZG5hbWUpOwogCiAJKHZvaWQpIGZwcmludGYo c3RkZXJyLCAiICAgIERhdGFzZXQgbmFtZSBtdXN0IGluY2x1ZGUgYXQgbGVhc3Qgb25lICIKQEAg LTE1MCw3ICsxNTMsNyBAQAogCSAgICAiaGFzIGFsdHJvb3Qvbm90IGluIGEgY2FjaGVmaWxlXG4i KTsKIAkodm9pZCkgZnByaW50ZihzdGRlcnIsICIgICAgICAgIC1wIDxwYXRoPiAtLSB1c2Ugb25l IG9yIG1vcmUgd2l0aCAiCiAJICAgICItZSB0byBzcGVjaWZ5IHBhdGggdG8gdmRldiBkaXJcbiIp OwotCSh2b2lkKSBmcHJpbnRmKHN0ZGVyciwgIgktUCBwcmludCBudW1iZXJzIHBhcnNhYmxlXG4i KTsKKwkodm9pZCkgZnByaW50ZihzdGRlcnIsICIJLVAgcHJpbnQgbnVtYmVycyBpbiBwYXJzZWFi bGUgZm9ybVxuIik7CiAJKHZvaWQpIGZwcmludGYoc3RkZXJyLCAiICAgICAgICAtdCA8dHhnPiAt LSBoaWdoZXN0IHR4ZyB0byB1c2Ugd2hlbiAiCiAJICAgICJzZWFyY2hpbmcgZm9yIHViZXJibG9j a3NcbiIpOwogCSh2b2lkKSBmcHJpbnRmKHN0ZGVyciwgIlNwZWNpZnkgYW4gb3B0aW9uIG1vcmUg dGhhbiBvbmNlIChlLmcuIC1iYikgIgo= --bcaec5299ad98b695c04bf0f48fe-- From owner-freebsd-fs@FreeBSD.ORG Wed May 2 16:46:38 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 97562106566B for ; Wed, 2 May 2012 16:46:38 +0000 (UTC) (envelope-from simon@optinet.com) Received: from cobra.acceleratedweb.net (cobra-gw.acceleratedweb.net [207.99.79.37]) by mx1.freebsd.org (Postfix) with SMTP id 236708FC08 for ; Wed, 2 May 2012 16:46:38 +0000 (UTC) Received: (qmail 60229 invoked by uid 110); 2 May 2012 16:46:37 -0000 Received: from ool-4571afe7.dyn.optonline.net (HELO desktop1) (simon@optinet.com@69.113.175.231) by cobra.acceleratedweb.net with SMTP; 2 May 2012 16:46:37 -0000 From: "Simon" To: "freebsd-fs@freebsd.org" Date: Wed, 02 May 2012 12:46:30 -0400 Priority: Normal X-Mailer: PMMail 2000 Professional (2.20.2717) For Windows 2000 (5.1.2600;3) In-Reply-To: <20120502013129.093C51065670@hub.freebsd.org> MIME-Version: 1.0 Message-Id: <20120502164638.97562106566B@hub.freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Replacing dead drives in ZRAID2 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, 02 May 2012 16:46:38 -0000 Am I the only one using this SCSI card and ZFS? does anyone use any type of Adaptec U320 SCSI card? I hardly doubt the behaviour I'm experiencing is strictly related to ahd driver. When I first read about ZFS I've built up high hopes, but now they are slowly fading away. -Simon On Tue, 01 May 2012 21:31:20 -0400, Simon wrote: >ahd0: >on board of Super X5DPR-8G2+ motherboard. >Also would like to add that when I plug a drive into this running machine, it >prints the following, but does not come up under /dev unless I issue reset >using camcontrol. >ahd0: Someone reset channel A >(da0:ahd0:0:0:0): WRITE(10). CDB: 2a 0 1 10 23 f0 0 0 80 0 >(da0:ahd0:0:0:0): CAM status: SCSI Status Error >(da0:ahd0:0:0:0): SCSI status: Check Condition >(da0:ahd0:0:0:0): SCSI sense: UNIT ATTENTION asc:29,1 (Power on occurred) >(da0:ahd0:0:0:0): Field Replaceable Unit: 1 >-Simon >On Tue, 1 May 2012 20:57:52 -0400, Rich wrote: >>What card is this? >>- Rich >>On Tue, May 1, 2012 at 6:15 PM, Simon wrote: >>> >>> Sorry, I meant to say zpool offline. >>> >>> After I take the drive out marked as offline, and put it back in, the system spits >>> the following: >>> >>> ahd0: someone reset channel A >>> ahd0: WARNING no command for scb 242 (cmdcmplt) >>> QOUTPOS = 283 >>> >>>>>>>>>>>>>>>>>>>>>>Dumpt Card State Begins>>>>>>>>>>>> >>> ahd0: dumping card state.... followed by a lard amount of data. >>> >>> It then freezes and won't executed any new commands. >>> >>> beta_srv# uname -a >>> FreeBSD beta_srv 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:15:25 >>> UTC 2012 root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 >>> >>> beta_srv# dmesg | grep ses >>> ses0 at ahd0 bus 0 scbus0 target 6 lun 0 >>> ses0: Fixed Processor SCSI-2 device >>> ses0: 3.300MB/s transfers >>> ses0: SAF-TE Compliant Device >>> >>> Thanks, >>> Simon >>> >>> On Tue, 1 May 2012 14:26:35 -0700, Freddie Cash wrote: >>> >>>>On Tue, May 1, 2012 at 1:57 PM, Simon wrote: >>>>> I decided to give ZFS ZRAID2 a shot after getting fed up with some legacy >>>>> hardware RAID cards that don't properly perform, or at all, patrol-reads + >>>>> consistency checking. So... >>>>> >>>>> I can't seem to figure out the proper way to replace a dead drive in a running >>>>> system with SCSI+SES enclosure. I tried: >>>>> >>>>> zpool detach zroot baddrive >>>>> camcontrol stop baddrive >>> >>>>You can't detach drives from raidz vdevs. The correct process is: >>> >>>>zpool offline zroot >>>> >>>> >>>> >>>>zpool replace zroot >>> >>>>"zpool detach" is only used for mirror vdevs. >>> >>>>-- >>>>Freddie Cash >>>>fjwcash@gmail.com >>> >>> >>> >>> _______________________________________________ >>> freebsd-fs@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-fs >>> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >_______________________________________________ >freebsd-fs@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-fs >To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Wed May 2 16:50:41 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F339D1065672 for ; Wed, 2 May 2012 16:50:41 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id AFB818FC12 for ; Wed, 2 May 2012 16:50:41 +0000 (UTC) Received: by qabg1 with SMTP id g1so3277770qab.13 for ; Wed, 02 May 2012 09:50:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3y2aOaL1tCQXM6p6yH3jL7Bh3fI3mIikP5wI1r40hdY=; b=0Tl0gDP2H8mupSAj916XYyPYZka37UU/kEK9esZ7yJfEv0Gz/FABkqR4ObddTtzIAf HuHkTM8JaluzJBAxZk05goCcLUxJ9bILVNgUcz94W8nk5g01HXQ4/vhy1gMTcpLkT6Hd blpY97hKhe8LeY+2WbKBSOCz7YenHYjyO5u5oSpK7Lohn2JvcT4NUXBacep2zPcuiWNy R4CQB+Bi5gxze6mzjWjIrBTpjF6J28F4a6HOynI+5a7Ne/PlEWXw6/ViLRjf31sy6eJY Skl/F6TCxN+Wn15/B+Wx8qV40fxlOCknRKdsDtIWAtp48ImiqoGsuuxULLMZeBZBc5vb do8g== MIME-Version: 1.0 Received: by 10.224.9.138 with SMTP id l10mr2526486qal.43.1335977441239; Wed, 02 May 2012 09:50:41 -0700 (PDT) Received: by 10.229.191.82 with HTTP; Wed, 2 May 2012 09:50:41 -0700 (PDT) In-Reply-To: <20120502164638.97562106566B@hub.freebsd.org> References: <20120502013129.093C51065670@hub.freebsd.org> <20120502164638.97562106566B@hub.freebsd.org> Date: Wed, 2 May 2012 09:50:41 -0700 Message-ID: From: Freddie Cash To: Simon Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-fs@freebsd.org" Subject: Re: Replacing dead drives in ZRAID2 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, 02 May 2012 16:50:42 -0000 On Wed, May 2, 2012 at 9:46 AM, Simon wrote: > Am I the only one using this SCSI card and ZFS? does anyone use any type of > Adaptec U320 SCSI card? I hardly doubt the behaviour I'm experiencing is strictly > related to ahd driver. Try the following: - format a drive or two using UFS - unplug the drive from the controller - plug it back in Do you get the same errors? If so, it's a driver/controller issue. > When I first read about ZFS I've built up high hopes, but now they are slowly > fading away. You can't expect miracles from ZFS if the underlying hardware has issues. :) -- Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Wed May 2 17:15:07 2012 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6015106566B for ; Wed, 2 May 2012 17:15:07 +0000 (UTC) (envelope-from sukenwoo@gmail.com) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id 4F31A8FC17 for ; Wed, 2 May 2012 17:15:07 +0000 (UTC) Received: by qabg1 with SMTP id g1so3309174qab.13 for ; Wed, 02 May 2012 10:15:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jTg/bXPdrBe6oioFQm8aN+XNVpzCLcwpWsE6bPuP+k8=; b=tz9uIBvrqjrTaN1Oic7x/0VA7UJRaJK7AefUP+igCNilJjVOIVblfam+K/BHb3Mhrs iFC7zPHfGdzXoqYI4i5EGU7ewRZKjBPrmaWXvdCo8WPkpZKzku4QADE6XqJdyukHGka7 mwk6TRXtZJqP9ZDKZpYzqtXT56weEPA1R6qEJPzE8fAcYshZ9KTi+rKZnlbctJsJpb56 OT3onKkTiKts049QKptjZDTteivwHP0nqDNvMXhr3DrfAm6TF/cdJINF9uGp+OmZo21B CrLZJg5T+T2K2QuquE0RVsyUIqNRRApXitTtC21pp+yDo+Hdv0Bt/pRPNA0ddFj4IQXB YjLw== MIME-Version: 1.0 Received: by 10.60.7.200 with SMTP id l8mr33961777oea.52.1335978906408; Wed, 02 May 2012 10:15:06 -0700 (PDT) Received: by 10.182.49.71 with HTTP; Wed, 2 May 2012 10:15:06 -0700 (PDT) In-Reply-To: <4fa128a8.9089e50a.12cb.ffff8b5eSMTPIN_ADDED@mx.google.com> References: <4fa128a8.9089e50a.12cb.ffff8b5eSMTPIN_ADDED@mx.google.com> Date: Thu, 3 May 2012 01:15:06 +0800 Message-ID: From: suken woo To: Simon Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "fs@freebsd.org" Subject: Re: urgent system suddenly boot failed due to ZFS:i/o error on FreeBSD 8.2 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, 02 May 2012 17:15:07 -0000 thanks for you reply Simon. checked zpool is fine and can export and import. 2012/5/2 Simon > > I'd boot using liveCD to see what's going on with the zpool, drive > detection, and > what the other person suggested as far as possible hot-spare issue. > > -Simon > > > On Wed, 2 May 2012 20:03:19 +0800, suken woo wrote: > > >hi,lists > > for some reasons I need restart system but it suddenly boot failed today. > >here is the error: > >ZFS: i/o error - all block copies unavailable > >ZFS: can't read object set for dataset 16 > >Can't find root filesystem - giving up > >ZFS:unexcepted object set type 0 > >ZFS:unexcepted object set type 0 > > > >FreeBSD/i386 boot > >Default: zroot:/boot/kernel/kernel > >boot: > >ZFS:unexcepted object set type0 > > > >FreeBSD/i386 boot > >Default: zroot:/boot/kernel/kernel > >boot: _ > > > >any ideas to resolved it? > >thanks in advance > >_______________________________________________ > >*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*" > > > > -- --wsk From owner-freebsd-fs@FreeBSD.ORG Wed May 2 17:27:25 2012 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 A0BFB106564A for ; Wed, 2 May 2012 17:27:25 +0000 (UTC) (envelope-from simon@optinet.com) Received: from cobra.acceleratedweb.net (cobra-gw.acceleratedweb.net [207.99.79.37]) by mx1.freebsd.org (Postfix) with SMTP id 627468FC15 for ; Wed, 2 May 2012 17:27:25 +0000 (UTC) Received: (qmail 63264 invoked by uid 110); 2 May 2012 17:27:24 -0000 Received: from ool-4571afe7.dyn.optonline.net (HELO desktop1) (simon@optinet.com@69.113.175.231) by cobra.acceleratedweb.net with SMTP; 2 May 2012 17:27:24 -0000 From: "Simon" To: "Freddie Cash" Date: Wed, 02 May 2012 13:27:17 -0400 Priority: Normal X-Mailer: PMMail 2000 Professional (2.20.2717) For Windows 2000 (5.1.2600;3) In-Reply-To: MIME-Version: 1.0 Message-Id: <20120502172725.A0BFB106564A@hub.freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-fs@freebsd.org" Subject: Re: Replacing dead drives in ZRAID2 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, 02 May 2012 17:27:25 -0000 I don't expect miracles from ZFS if hardware is not compatible. However, I did expect for ahd driver and Adaptec U320 to still be fairly common and well aged, thus being compatible, but perhaps that isn't the case. Is there a list of compatible controllers? I do not understand how formatting a drive using UFS would solve my issues. I pulled 2 drives out from functional zraid2 to simulate drive failure and the system froze. Clearly there is an issue using this controller with ZFS in ZRAID setup. It shouldn't matter what I have installed on a drive. When a drive is pulled out of hot-plug enclosure, it should get marked as offline. -Simon On Wed, 2 May 2012 09:50:41 -0700, Freddie Cash wrote: >On Wed, May 2, 2012 at 9:46 AM, Simon wrote: >> Am I the only one using this SCSI card and ZFS? does anyone use any type of >> Adaptec U320 SCSI card? I hardly doubt the behaviour I'm experiencing is strictly >> related to ahd driver. >Try the following: > - format a drive or two using UFS > - unplug the drive from the controller > - plug it back in >Do you get the same errors? If so, it's a driver/controller issue. >> When I first read about ZFS I've built up high hopes, but now they are slowly >> fading away. >You can't expect miracles from ZFS if the underlying hardware has issues. :) >-- >Freddie Cash >fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Wed May 2 17:35:53 2012 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 A3074106566C; Wed, 2 May 2012 17:35:53 +0000 (UTC) (envelope-from araujo@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7790C8FC14; Wed, 2 May 2012 17:35:53 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q42HZr6w081462; Wed, 2 May 2012 17:35:53 GMT (envelope-from araujo@freefall.freebsd.org) Received: (from araujo@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q42HZr4H081458; Wed, 2 May 2012 17:35:53 GMT (envelope-from araujo) Date: Wed, 2 May 2012 17:35:53 GMT Message-Id: <201205021735.q42HZr4H081458@freefall.freebsd.org> To: mharo@freebsd.org, araujo@FreeBSD.org, freebsd-fs@FreeBSD.org From: araujo@FreeBSD.org Cc: Subject: Re: kern/159077: [zfs] Can't cd .. with latest zfs version 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, 02 May 2012 17:35:53 -0000 Synopsis: [zfs] Can't cd .. with latest zfs version State-Changed-From-To: open->feedback State-Changed-By: araujo State-Changed-When: Wed May 2 17:35:52 UTC 2012 State-Changed-Why: Do you still have this issue? THave you tried the solution mentioned by Gary Palmer? Shall we close this PR? http://www.freebsd.org/cgi/query-pr.cgi?pr=159077 From owner-freebsd-fs@FreeBSD.ORG Wed May 2 17:38:46 2012 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 AF5BE106566B; Wed, 2 May 2012 17:38:46 +0000 (UTC) (envelope-from araujo@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8259D8FC0C; Wed, 2 May 2012 17:38:46 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q42HckT9081705; Wed, 2 May 2012 17:38:46 GMT (envelope-from araujo@freefall.freebsd.org) Received: (from araujo@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q42Hck0C081701; Wed, 2 May 2012 17:38:46 GMT (envelope-from araujo) Date: Wed, 2 May 2012 17:38:46 GMT Message-Id: <201205021738.q42Hck0C081701@freefall.freebsd.org> To: maciej.gabryszak@gmail.com, araujo@FreeBSD.org, freebsd-fs@FreeBSD.org From: araujo@FreeBSD.org Cc: Subject: Re: kern/162083: [zfs] [panic] zfs unmount -f pool 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, 02 May 2012 17:38:46 -0000 Synopsis: [zfs] [panic] zfs unmount -f pool State-Changed-From-To: open->feedback State-Changed-By: araujo State-Changed-When: Wed May 2 17:38:46 UTC 2012 State-Changed-Why: Do you still have this problem? I performed some tests on CURRENT and it doesn't happens. http://www.freebsd.org/cgi/query-pr.cgi?pr=162083 From owner-freebsd-fs@FreeBSD.ORG Wed May 2 17:42:13 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7CD541065678; Wed, 2 May 2012 17:42:13 +0000 (UTC) (envelope-from araujo@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 50BDB8FC1B; Wed, 2 May 2012 17:42:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q42HgDbZ089841; Wed, 2 May 2012 17:42:13 GMT (envelope-from araujo@freefall.freebsd.org) Received: (from araujo@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q42HgDCj089837; Wed, 2 May 2012 17:42:13 GMT (envelope-from araujo) Date: Wed, 2 May 2012 17:42:13 GMT Message-Id: <201205021742.q42HgDCj089837@freefall.freebsd.org> To: maciej.gabryszak@gmail.com, araujo@FreeBSD.org, freebsd-fs@FreeBSD.org From: araujo@FreeBSD.org Cc: Subject: Re: kern/162083: [zfs] [panic] zfs unmount -f pool 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, 02 May 2012 17:42:13 -0000 Synopsis: [zfs] [panic] zfs unmount -f pool State-Changed-From-To: feedback->open State-Changed-By: araujo State-Changed-When: Wed May 2 17:42:07 UTC 2012 State-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=162083 From owner-freebsd-fs@FreeBSD.ORG Wed May 2 17:43:40 2012 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 6D23F1065670; Wed, 2 May 2012 17:43:40 +0000 (UTC) (envelope-from araujo@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 406D08FC08; Wed, 2 May 2012 17:43:40 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q42Hhe4d089952; Wed, 2 May 2012 17:43:40 GMT (envelope-from araujo@freefall.freebsd.org) Received: (from araujo@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q42HhePB089948; Wed, 2 May 2012 17:43:40 GMT (envelope-from araujo) Date: Wed, 2 May 2012 17:43:40 GMT Message-Id: <201205021743.q42HhePB089948@freefall.freebsd.org> To: mharo@freebsd.org, araujo@FreeBSD.org, freebsd-fs@FreeBSD.org From: araujo@FreeBSD.org Cc: Subject: Re: kern/159077: [zfs] Can't cd .. with latest zfs version 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, 02 May 2012 17:43:40 -0000 Synopsis: [zfs] Can't cd .. with latest zfs version State-Changed-From-To: feedback->open State-Changed-By: araujo State-Changed-When: Wed May 2 17:42:44 UTC 2012 State-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=159077 From owner-freebsd-fs@FreeBSD.ORG Wed May 2 17:50:54 2012 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 A3FAB106566B for ; Wed, 2 May 2012 17:50:54 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by mx1.freebsd.org (Postfix) with ESMTP id 5E9AC8FC0A for ; Wed, 2 May 2012 17:50:54 +0000 (UTC) Received: by qabj40 with SMTP id j40so862424qab.15 for ; Wed, 02 May 2012 10:50:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lcz/SkE1Ftz2jwTok8evNyf2yj/QE58QfpMdOy1OgGw=; b=HbpkiP4FvQLHMtFfBCs2i6HSO5fjdBgr7mIsHbOLbZ6TqKTzim5N+Qo8Vke7aM4T1n /xMGHuD+EWhfhYBlC+ObMVOz1uDmYbZ4sYEuG+3aTcB9HpISz7YqDp4tJxmxforGa/yZ D6t9MIaqEI1cCeob/sQSJFIfV/nmUY4XLFO91ewCQ90zFY/h7gxYZ0qWDTpcTPEED4ZL TkoZ3hsZeiSGfucTXccFX95/103NuDQF/EpbWcQStu7Y7AKFQQFzMOSGJb6f29VUyvnM vTJVhLKet+a4pBtECKp19oS2RE+jtVdW1LVeCP/g/O5adRwdYViCJhNzDdeMtfLMJQ2h VDLA== MIME-Version: 1.0 Received: by 10.224.178.9 with SMTP id bk9mr17968476qab.98.1335981048662; Wed, 02 May 2012 10:50:48 -0700 (PDT) Received: by 10.229.191.82 with HTTP; Wed, 2 May 2012 10:50:48 -0700 (PDT) In-Reply-To: <4fa16e7d.09d6e00a.5667.3ec7SMTPIN_ADDED@mx.google.com> References: <4fa16e7d.09d6e00a.5667.3ec7SMTPIN_ADDED@mx.google.com> Date: Wed, 2 May 2012 10:50:48 -0700 Message-ID: From: Freddie Cash To: Simon Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-fs@freebsd.org" Subject: Re: Replacing dead drives in ZRAID2 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, 02 May 2012 17:50:54 -0000 On Wed, May 2, 2012 at 10:27 AM, Simon wrote: > I don't expect miracles from ZFS if hardware is not compatible. However, > I did expect for ahd driver and Adaptec U320 to still be fairly common and > well aged, thus being compatible, but perhaps that isn't the case. > > Is there a list of compatible controllers? > > I do not understand how formatting a drive using UFS would solve my > issues. I pulled 2 drives out from functional zraid2 to simulate drive > failure and the system froze. Clearly there is an issue using this controller with > ZFS in ZRAID setup. It shouldn't matter what I have installed on a drive. > When a drive is pulled out of hot-plug enclosure, it should get marked as > offline. Until you format drives with something other than ZFS and test removing/plugging in a drive, you cannot say for certain that it's a ZFS issue. The error messages shown all come from ahd which is way below ZFS. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Wed May 2 20:39:49 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D263E106566B for ; Wed, 2 May 2012 20:39:49 +0000 (UTC) (envelope-from simon@optinet.com) Received: from cobra.acceleratedweb.net (cobra-gw.acceleratedweb.net [207.99.79.37]) by mx1.freebsd.org (Postfix) with SMTP id 8CD1D8FC12 for ; Wed, 2 May 2012 20:39:49 +0000 (UTC) Received: (qmail 75863 invoked by uid 110); 2 May 2012 20:39:48 -0000 Received: from ool-4571afe7.dyn.optonline.net (HELO desktop1) (simon@optinet.com@69.113.175.231) by cobra.acceleratedweb.net with SMTP; 2 May 2012 20:39:48 -0000 From: "Simon" To: "Freddie Cash" Date: Wed, 02 May 2012 16:39:48 -0400 Priority: Normal X-Mailer: PMMail 2000 Professional (2.20.2717) For Windows 2000 (5.1.2600;3) In-Reply-To: MIME-Version: 1.0 Message-Id: <20120502203949.D263E106566B@hub.freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-fs@freebsd.org" Subject: Re: Replacing dead drives in ZRAID2 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, 02 May 2012 20:39:49 -0000 I'm not saying it is ZFS. What I am saying is that I have setup ZRAID2 using 3x U320 SCSI drives connected to SAF-TE backplane connected to Adaptec 7902 controller. When I pull 2 out of 3 drives out, the system freezes where no new requests are being processed and the ahb driver starts throwing a fit. Is this normal/expected behaviour? I cannot pull drives out from hotswappable enclosure to simulate drive failure? if so, what would happen if a drive did fail while inside the enclosure? what would be different? I cannot trust RAID setup where I cannot pull/disconnect a drive and expect the system to continue to run smoothly. BTW, I'm not sure if this matters or not but I'm setting up ZRAID2 using GPT partitions as shown here: http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/9.0-RELEASE Can someone confirm whether or not I can use Adaptec 7902 with ZRAID? -Simon On Wed, 2 May 2012 10:50:48 -0700, Freddie Cash wrote: >On Wed, May 2, 2012 at 10:27 AM, Simon wrote: >> I don't expect miracles from ZFS if hardware is not compatible. However, >> I did expect for ahd driver and Adaptec U320 to still be fairly common and >> well aged, thus being compatible, but perhaps that isn't the case. >> >> Is there a list of compatible controllers? >> >> I do not understand how formatting a drive using UFS would solve my >> issues. I pulled 2 drives out from functional zraid2 to simulate drive >> failure and the system froze. Clearly there is an issue using this controller with >> ZFS in ZRAID setup. It shouldn't matter what I have installed on a drive. >> When a drive is pulled out of hot-plug enclosure, it should get marked as >> offline. >Until you format drives with something other than ZFS and test >removing/plugging in a drive, you cannot say for certain that it's a >ZFS issue. The error messages shown all come from ahd which is way >below ZFS. >-- >Freddie Cash >fjwcash@gmail.com From owner-freebsd-fs@FreeBSD.ORG Wed May 2 21:05:09 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EF8D3106566B for ; Wed, 2 May 2012 21:05:09 +0000 (UTC) (envelope-from feld@feld.me) Received: from feld.me (unknown [IPv6:2607:f4e0:100:300::2]) by mx1.freebsd.org (Postfix) with ESMTP id B79098FC08 for ; Wed, 2 May 2012 21:05:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=In-Reply-To:Message-Id:From:Mime-Version:Date:References:Subject:To:Content-Type; bh=CebYRHN7troiwYy5MAdxZpCmhlERb0ny5aoJB5ub0A8=; b=MFhZ90Whk/9FMPTvd3SiBIvkm7ZbvOAkSI5IaYHtExa4gn1TEvGdfatBN1Pgw69NpYD9EwIBm1r263rg2NSk7pHsuyqJujFemfCMSBtrSGXw/72JLjnLD2qmTuGbgn20; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by feld.me with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SPgjU-000PoY-HF for freebsd-fs@freebsd.org; Wed, 02 May 2012 16:05:09 -0500 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpa id 1335992702-30163-30162/5/45; Wed, 2 May 2012 21:05:02 +0000 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-fs@freebsd.org References: <20120501210429.D4F6910657EB@hub.freebsd.org> Date: Wed, 2 May 2012 16:05:01 -0500 Mime-Version: 1.0 From: Mark Felder Message-Id: In-Reply-To: <20120501210429.D4F6910657EB@hub.freebsd.org> User-Agent: Opera Mail/11.62 (FreeBSD) X-SA-Score: -1.5 Subject: Re: Replacing dead drives in ZRAID2 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, 02 May 2012 21:05:10 -0000 First of all, you're testing on decade old SCSI hardware that probably hasn't seen any serious use on a newer FreeBSD install in a very, very long time. Secondly, I'm confused about the concept of a "3 drive RAIDZ2". How is that even possible? Two drives have to be parity, so the last drive is... the entire dataset? Why aren't you just doing a 3-way mirror? And finally yes, you can just yank drives in a ZFS array to simulate a failure. After reinsertion you have to manually add them back to the pool, but it certainly works. From owner-freebsd-fs@FreeBSD.ORG Wed May 2 21:18:23 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B88001065672 for ; Wed, 2 May 2012 21:18:23 +0000 (UTC) (envelope-from rincebrain@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6B8E48FC14 for ; Wed, 2 May 2012 21:18:23 +0000 (UTC) Received: by vcmm1 with SMTP id m1so1070271vcm.13 for ; Wed, 02 May 2012 14:18:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=h+cWEsm1/ONIvLxmx/NVepeqII38IZAkvDIbAufrTug=; b=Koeq3yiWjRDMDTILja4uJlTyO7UQ9jvZtS82hlyhGHdFH3t7uISvBpCYbQkENgOKFF VCg7BmDveEhgt/tCkGaFdD6gT7ufBQdpiZ7YYM5YwksFEHZtkbfQqD5s+GczNF83q0Z+ +fEukNYoAyq+ClAdoyl7olEL0Tc2nBsLVt13cMHD5rXQLA6L/nZ3QktnIwagmf8dFDt0 +OFJC3Jsuw3gLU9gyOi+tHnNqkDptSSp61ycJcPRx72l1FBXT6ixLgYcJQpey8F/HUKV EE8+A7gQXuRqC1rnZOiwcAl2jo9SfzZr8Z1OFo6m6/D0dUA7FyQ9qCqHk2H+gTa8BCbj ZUWg== MIME-Version: 1.0 Received: by 10.52.172.172 with SMTP id bd12mr772620vdc.69.1335993502850; Wed, 02 May 2012 14:18:22 -0700 (PDT) Sender: rincebrain@gmail.com Received: by 10.220.117.81 with HTTP; Wed, 2 May 2012 14:18:22 -0700 (PDT) In-Reply-To: References: <20120501210429.D4F6910657EB@hub.freebsd.org> Date: Wed, 2 May 2012 17:18:22 -0400 X-Google-Sender-Auth: a7oCXPQyHam6v9bWoe4oLYEK77s Message-ID: From: Rich To: Mark Felder Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org Subject: Re: Replacing dead drives in ZRAID2 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, 02 May 2012 21:18:23 -0000 It's perfectly possible to do a 3-way RAID-Z2 - just not useful, AFAIK. Also, Simon, I think the disconnect between you and the mailing list is that you are observing bad behavior of the system when you remove the drives, and you think this is a ZFS problem. This is not a ZFS problem - if the underlying storage driver (ahd) freezes up and stops handling requests (which is what it sounds like you're describing here), there's not much ZFS can do about it. - Rich On Wed, May 2, 2012 at 5:05 PM, Mark Felder wrote: > First of all, you're testing on decade old SCSI hardware that probably > hasn't seen any serious use on a newer FreeBSD install in a very, very long > time. > > Secondly, I'm confused about the concept of a "3 drive RAIDZ2". How is that > even possible? Two drives have to be parity, so the last drive is... the > entire dataset? Why aren't you just doing a 3-way mirror? > > And finally yes, you can just yank drives in a ZFS array to simulate a > failure. After reinsertion you have to manually add them back to the pool, > but it certainly works. > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Wed May 2 22:06:09 2012 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 D7A60106579A for ; Wed, 2 May 2012 22:06:09 +0000 (UTC) (envelope-from simon@optinet.com) Received: from cobra.acceleratedweb.net (cobra-gw.acceleratedweb.net [207.99.79.37]) by mx1.freebsd.org (Postfix) with SMTP id 78BDE8FC16 for ; Wed, 2 May 2012 22:06:09 +0000 (UTC) Received: (qmail 82674 invoked by uid 110); 2 May 2012 22:06:03 -0000 Received: from ool-4571afe7.dyn.optonline.net (HELO desktop1) (simon@optinet.com@69.113.175.231) by cobra.acceleratedweb.net with SMTP; 2 May 2012 22:06:03 -0000 From: "Simon" To: "Rich" Date: Wed, 02 May 2012 18:06:04 -0400 Priority: Normal X-Mailer: PMMail 2000 Professional (2.20.2717) For Windows 2000 (5.1.2600;3) In-Reply-To: MIME-Version: 1.0 Message-Id: <20120502220609.D7A60106579A@hub.freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-fs@freebsd.org" Subject: Re: Replacing dead drives in ZRAID2 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, 02 May 2012 22:06:09 -0000 I'm trying to figure out why it's not working with ahd driver. It's beginning to look more and more as if I shouldn't use ZFS with ahd driver. That's why I asked for someone to confirm whether or not the two can be used together. It also seems that everyone moved on to SAS/SATA technology, albeit it's hard to believe. There are few machine I have from early 2007, so 5 years old, that have the same controller onboard. So while u320 is a decade old technology, many servers been built using it in 2006+ Unless someone can confirm otherwise, I will assume ahd and ZFS do not work well together when it comes to dying/swapping drives. Having said the above, is there any FreeBSD RAID software I can use with ahb driver that won't give me same issues I'm experiencing with ahd and ZFS? vinum? gmirror? Can I expect them to work better with ahd given ahd cannot handle pulling of working drives out of SAF-TE aware enclosure? Thank you, Simon On Wed, 2 May 2012 17:18:22 -0400, Rich wrote: >It's perfectly possible to do a 3-way RAID-Z2 - just not useful, AFAIK. >Also, Simon, I think the disconnect between you and the mailing list >is that you are observing bad behavior of the system when you remove >the drives, and you think this is a ZFS problem. This is not a ZFS >problem - if the underlying storage driver (ahd) freezes up and stops >handling requests (which is what it sounds like you're describing >here), there's not much ZFS can do about it. >- Rich >On Wed, May 2, 2012 at 5:05 PM, Mark Felder wrote: >> First of all, you're testing on decade old SCSI hardware that probably >> hasn't seen any serious use on a newer FreeBSD install in a very, very long >> time. >> >> Secondly, I'm confused about the concept of a "3 drive RAIDZ2". How is that >> even possible? Two drives have to be parity, so the last drive is... the >> entire dataset? Why aren't you just doing a 3-way mirror? >> >> And finally yes, you can just yank drives in a ZFS array to simulate a >> failure. After reinsertion you have to manually add them back to the pool, >> but it certainly works. >> >> _______________________________________________ >> freebsd-fs@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-fs >> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >_______________________________________________ >freebsd-fs@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-fs >To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Wed May 2 22:21:23 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DE0EA1065811 for ; Wed, 2 May 2012 22:21:22 +0000 (UTC) (envelope-from feld@feld.me) Received: from feld.me (unknown [IPv6:2607:f4e0:100:300::2]) by mx1.freebsd.org (Postfix) with ESMTP id 80E688FC16 for ; Wed, 2 May 2012 22:21:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=In-Reply-To:Message-Id:From:Mime-Version:Date:References:Subject:To:Content-Type; bh=9w3Y+Bw1em2b+oXB28rEcTRz+QDfSjusgdRiPQNIvww=; b=rphEwpSth45N7aYnu/3OIiYF3k4jPI8HNkGZSWbcTUqL0h7RSXXHNW5yj9N4prUFLB4CkiGjO4n+ZkBxzp6iJodaPj+X0LbWq11RD4TgsPaFDMnF8hBGhb4jso8P8obm; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by feld.me with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SPhvF-0002CJ-Di for freebsd-fs@freebsd.org; Wed, 02 May 2012 17:21:22 -0500 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpa id 1335997275-30163-30162/5/47; Wed, 2 May 2012 22:21:15 +0000 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-fs@freebsd.org References: <20120501210429.D4F6910657EB@hub.freebsd.org> <20120502220609.D7A60106579A@hub.freebsd.org> Date: Wed, 2 May 2012 17:21:14 -0500 Mime-Version: 1.0 From: Mark Felder Message-Id: In-Reply-To: <20120502220609.D7A60106579A@hub.freebsd.org> User-Agent: Opera Mail/11.62 (FreeBSD) X-SA-Score: -1.5 Subject: Re: Replacing dead drives in ZRAID2 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, 02 May 2012 22:21:24 -0000 On Wed, 02 May 2012 17:06:04 -0500, wrote: > > Having said the above, is there any FreeBSD RAID software I can use with > ahb driver that won't give me same issues I'm experiencing with ahd and > ZFS? > vinum? gmirror? Can I expect them to work better with ahd given ahd > cannot > handle pulling of working drives out of SAF-TE aware enclosure? We're pretty sure it's not the /RAID Software/ and that it's a driver issue. I don't think with your version of FreeBSD that you can do *any* hot swapping of drives with that controller. Ask the maintainer of the ahd driver to take a look -- he might be able to provide a patch. From owner-freebsd-fs@FreeBSD.ORG Wed May 2 22:34:14 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EC0E71065670 for ; Wed, 2 May 2012 22:34:14 +0000 (UTC) (envelope-from simon@optinet.com) Received: from cobra.acceleratedweb.net (cobra-gw.acceleratedweb.net [207.99.79.37]) by mx1.freebsd.org (Postfix) with SMTP id 5F9EE8FC0C for ; Wed, 2 May 2012 22:34:14 +0000 (UTC) Received: (qmail 84238 invoked by uid 110); 2 May 2012 22:34:13 -0000 Received: from ool-4571afe7.dyn.optonline.net (HELO desktop1) (simon@optinet.com@69.113.175.231) by cobra.acceleratedweb.net with SMTP; 2 May 2012 22:34:13 -0000 From: "Simon" To: "freebsd-fs@freebsd.org" , "Mark Felder" Date: Wed, 02 May 2012 18:34:15 -0400 Priority: Normal X-Mailer: PMMail 2000 Professional (2.20.2717) For Windows 2000 (5.1.2600;3) In-Reply-To: MIME-Version: 1.0 Message-Id: <20120502223414.EC0E71065670@hub.freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Replacing dead drives in ZRAID2 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, 02 May 2012 22:34:15 -0000 Thank you Mark, that's what I thought, too. My major concern is the failure of drives, not so much the hot-swapping. I can live with taking the machine offline, replacing the drive(s), and booting up. Yanking the drives out from live system is the only way I can simulate a hard failure. Without this working, I cannot be sure the system will remain running should a drive go bad. I'm not sure how the system would handle this given ahd cannot handle pulling of hot drives out. I will try to get in touch with the driver maintainer. Thanks again! -Simon On Wed, 2 May 2012 17:21:14 -0500, Mark Felder wrote: >On Wed, 02 May 2012 17:06:04 -0500, wrote: >> >> Having said the above, is there any FreeBSD RAID software I can use with >> ahb driver that won't give me same issues I'm experiencing with ahd and >> ZFS? >> vinum? gmirror? Can I expect them to work better with ahd given ahd >> cannot >> handle pulling of working drives out of SAF-TE aware enclosure? >We're pretty sure it's not the /RAID Software/ and that it's a driver >issue. I don't think with your version of FreeBSD that you can do *any* >hot swapping of drives with that controller. >Ask the maintainer of the ahd driver to take a look -- he might be able to >provide a patch. >_______________________________________________ >freebsd-fs@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-fs >To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Wed May 2 23:24:29 2012 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 D014F106564A for ; Wed, 2 May 2012 23:24:29 +0000 (UTC) (envelope-from daryl@isletech.net) Received: from lagoon.isletech.net (lagoon.isletech.net [64.235.98.66]) by mx1.freebsd.org (Postfix) with ESMTP id 9E8A98FC17 for ; Wed, 2 May 2012 23:24:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=isletech.net; s=isle; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=+fieIefAd6G7mugpGnm310j/ZRPZOMWI1h9wgypdgUg=; b=mOBcR6StZKqScwqqYnqJeg/YR/Itv0Ct1IBf6qEW8+vTSGNEWJOm+r492pNSP3uPMLg5GHH3PqdnKh/Ky/rKNQ==; Received: from 24-212-254-9.cable.teksavvy.com ([24.212.254.9]:51563 helo=mac.home.isletech.net) by lagoon.isletech.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SPidM-0009lH-Vw for freebsd-fs@freebsd.org; Wed, 02 May 2012 19:06:57 -0400 Message-ID: <4FA1BE10.3010200@isletech.net> Date: Wed, 02 May 2012 19:06:56 -0400 From: Daryl Richards User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <20120502223414.EC0E71065670@hub.freebsd.org> In-Reply-To: <20120502223414.EC0E71065670@hub.freebsd.org> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: Replacing dead drives in ZRAID2 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, 02 May 2012 23:24:29 -0000 On 12-05-02 6:34 PM, Simon wrote: > Thank you Mark, that's what I thought, too. My major concern is the failure > of drives, not so much the hot-swapping. I can live with taking the machine > offline, replacing the drive(s), and booting up. Yanking the drives out from live > system is the only way I can simulate a hard failure. Without this working, I > cannot be sure the system will remain running should a drive go bad. I'm > not sure how the system would handle this given ahd cannot handle pulling > of hot drives out. I will try to get in touch with the driver maintainer. > > Thanks again! > -Simon One way to simulate a "failure" with ZFS is to use dd to write trash data to the underlying drive, and then scrub it to detect the errors and have it correct itself. -- Daryl Richards Isle Technical Services Inc. From owner-freebsd-fs@FreeBSD.ORG Wed May 2 23:33:12 2012 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 4194B1065675 for ; Wed, 2 May 2012 23:33:12 +0000 (UTC) (envelope-from simon@optinet.com) Received: from cobra.acceleratedweb.net (cobra-gw.acceleratedweb.net [207.99.79.37]) by mx1.freebsd.org (Postfix) with SMTP id D0B0F8FC12 for ; Wed, 2 May 2012 23:33:11 +0000 (UTC) Received: (qmail 86976 invoked by uid 110); 2 May 2012 23:33:05 -0000 Received: from ool-4571afe7.dyn.optonline.net (HELO desktop1) (simon@optinet.com@69.113.175.231) by cobra.acceleratedweb.net with SMTP; 2 May 2012 23:33:05 -0000 From: "Simon" To: "freebsd-fs@freebsd.org" , "Daryl Richards" Date: Wed, 02 May 2012 19:33:07 -0400 Priority: Normal X-Mailer: PMMail 2000 Professional (2.20.2717) For Windows 2000 (5.1.2600;3) In-Reply-To: <4FA1BE10.3010200@isletech.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <20120502233312.4194B1065675@hub.freebsd.org> Cc: Subject: Re: Replacing dead drives in ZRAID2 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, 02 May 2012 23:33:12 -0000 On Wed, 02 May 2012 19:06:56 -0400, Daryl Richards wrote: >One way to simulate a "failure" with ZFS is to use dd to write trash data to the > underlying drive, and then scrub it to detect the errors and have it correct itself. Sure, but to me this is a soft failure: the drive is still powered-on, spinning, responding, etc... this works fine. I was trying to simulate hard failure, drive power failure, motor broke, ECB burnt, etc... with hardware RAID I would just yank the drive out. -Simon From owner-freebsd-fs@FreeBSD.ORG Thu May 3 00:02:48 2012 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 95ECD1065672 for ; Thu, 3 May 2012 00:02:48 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id 2EFDE8FC08 for ; Thu, 3 May 2012 00:02:48 +0000 (UTC) Received: (qmail 32069 invoked by uid 0); 2 May 2012 23:56:07 -0000 Received: from smtp.bway.net (216.220.96.25) by xena.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 2 May 2012 23:56:07 -0000 Received: (qmail 32060 invoked by uid 90); 2 May 2012 23:56:07 -0000 Received: from unknown (HELO ?10.3.2.41?) (spork@96.57.144.66) by smtp.bway.net with (AES128-SHA encrypted) SMTP; 2 May 2012 23:56:07 -0000 References: <20120502063927.GA9559@johnny.reilly.home> <4FA0D844.8090105@brockmann-consult.de> <4FA0FE82.4040600@entel.upc.edu> In-Reply-To: <4FA0FE82.4040600@entel.upc.edu> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 Message-Id: Content-Transfer-Encoding: quoted-printable From: Charles Sprickman Date: Wed, 2 May 2012 19:56:06 -0400 To: =?iso-8859-1?Q?Gustau_P=E9rez_i_Querol?= X-Mailer: Apple Mail (2.1084) Cc: freebsd-fs@freebsd.org Subject: Re: gpart labels - why arent't some showing up in /dev/gpt/? 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, 03 May 2012 00:02:48 -0000 On May 2, 2012, at 5:29 AM, Gustau P=E9rez i Querol wrote: > Al 02/05/2012 08:46, En/na Peter Maloney ha escrit: >> I have the same problem. Any time you boot off a CD/DVD and use = import -f (and then don't export), or I guess use import -f a pool from = anywhere, it does that. I don't know any non-zfs causes for the problem. >=20 > When doing the import -f, use -d /dev/gpt to force zpool to search = for devices in /dev/gpt. That way the import will be done by gpt name, = instead of by device name. This would be an awesome addition to the zfs wiki or zpool manpage. How did you figure this out? Charles > _______________________________________________ > 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" -- Charles Sprickman NetEng/SysAdmin Bway.net - New York's Best Internet www.bway.net spork@bway.net - 212.655.9344 From owner-freebsd-fs@FreeBSD.ORG Thu May 3 09:29:02 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AAEBA106564A for ; Thu, 3 May 2012 09:29:02 +0000 (UTC) (envelope-from mark@tuxis.nl) Received: from smtp.tuxis.nl (smtp.tuxis.nl [IPv6:2a03:7900:2:0:31:3:104:34]) by mx1.freebsd.org (Postfix) with ESMTP id 3E6DA8FC0C for ; Thu, 3 May 2012 09:29:02 +0000 (UTC) Received: from [2a03:7900:2:0:31:3:104:46] (port=55267 helo=go.tuxis.net) by smtp.tuxis.nl with esmtp (Exim 4.71) (envelope-from ) id 1SPsLL-0004Vg-EI for freebsd-fs@freebsd.org; Thu, 03 May 2012 11:28:59 +0200 Received: from localhost (localhost [127.0.0.1]) by go.tuxis.net (Postfix) with ESMTP id F148320D70 for ; Thu, 3 May 2012 11:28:48 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at www.hyperdesktop.nl Received: from go.tuxis.net ([127.0.0.1]) by localhost (go.tuxis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2wPn4Gdwn2X for ; Thu, 3 May 2012 11:28:46 +0200 (CEST) Received: from www.hyperdesktop.nl (unknown [IPv6:::1]) by go.tuxis.net (Postfix) with ESMTP id CAE1020D52 for ; Thu, 3 May 2012 11:28:46 +0200 (CEST) Message-ID: <1336037326.4fa24fceaad26@www.hyperdesktop.nl> Date: Thu, 03 May 2012 11:28:46 +0200 From: Mark Schouten To: Volodymyr Kostyrko MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced by Group-Office 3.7.42 In-Reply-To: <1334658183.4f8d4487c729f@www.hyperdesktop.nl> References: <1334658183.4f8d4487c729f@www.hyperdesktop.nl> X-Mailer: Group-Office 3.7.42 X-Priority: 3 (Normal) Cc: "freebsd-fs@freebsd.org" Subject: Re: ZFS and disk usage 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, 03 May 2012 09:29:02 -0000 Hi, Op Dinsdag, 17-04-2012 om 12:23 schreef Mark Schouten= : > The box is running a production environment now, so I can't real= ly fool around with it. It will be migrated soon though, which will give= me some time to experiment. >=20 > Thanks a bunch for the help= ! Ok, so I tested this and this seems to work. I'll let the blo= gger know that his manual contains errors. :) Thank= s! --=20 Dit bericht is verzonden via https://www.hyperdes= ktop.nl/. Alles, overal! Mark Schouten | Tuxis Internet Engine= ering KvK: 09218193 | http://www.tuxis.nl/ T: 0318 200208 | info= @tuxis.nl M: 06 53463918 | mark@tuxis.nl From owner-freebsd-fs@FreeBSD.ORG Thu May 3 11:33:26 2012 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 253041065670 for ; Thu, 3 May 2012 11:33:26 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id DD91A8FC0A for ; Thu, 3 May 2012 11:33:25 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:5188:feac:1539:f0f6]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 01A384AC2D for ; Thu, 3 May 2012 15:33:24 +0400 (MSK) Date: Thu, 3 May 2012 15:33:17 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1144029025.20120503153317@serebryakov.spb.ru> To: freebsd-fs@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Is here any plans to support effective (not write-all-blocks-as-from-userland) vop_allocate() for UFS and ZFS? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 11:33:26 -0000 Hello, Freebsd-fs. It seems to be very straightforward for UFS/FFS, isn't it? I could try to do this, but only if nobody works on it right now. -- // Black Lion AKA Lev Serebryakov From owner-freebsd-fs@FreeBSD.ORG Thu May 3 12:43:41 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2FB3C106566B for ; Thu, 3 May 2012 12:43:41 +0000 (UTC) (envelope-from daniel@digsys.bg) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.3.230]) by mx1.freebsd.org (Postfix) with ESMTP id 8BAFB8FC08 for ; Thu, 3 May 2012 12:43:40 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.5/8.14.5) with ESMTP id q43CMZ6T019390 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 3 May 2012 15:22:36 +0300 (EEST) (envelope-from daniel@digsys.bg) Message-ID: <4FA2788B.2000703@digsys.bg> Date: Thu, 03 May 2012 15:22:35 +0300 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.4) Gecko/20120501 Thunderbird/10.0.4 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <20120502223414.EC0E71065670@hub.freebsd.org> In-Reply-To: <20120502223414.EC0E71065670@hub.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Replacing dead drives in ZRAID2 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, 03 May 2012 12:43:41 -0000 Simon, ZFS is known to put much more stress on hardware than UFS (in typical usage) and any flaky hardware setup very quickly breaks up. When I started playing with ZFS, I was dismayed that few drives that were otherwise perfectly OK and never, ever showed any indication of malfunction did show errors with ZFS. Same with controllers. Just don't panic :) ZFS is very reliable otherwise, sometimes in the 'magical' realm (but of course, don't ever imagine things, when it comes to your data). My guess is, that you simulated the failing drives by pulling them out too quickly. That is, if the Adaptec controller or rather the drives doesn't fully support hot-swap you may need to do things more 'safely', by waiting a bit between pulls, doing scsi bus reset (and waiting for it to enumerate again), rescans etc. One can sometimes hot-swap even non-hot swappable SATA this way :) Sometimes.. Have you tried repeating this experiment? Daniel On 03.05.12 01:34, Simon wrote: > Thank you Mark, that's what I thought, too. My major concern is the failure > of drives, not so much the hot-swapping. I can live with taking the machine > offline, replacing the drive(s), and booting up. Yanking the drives out from live > system is the only way I can simulate a hard failure. Without this working, I > cannot be sure the system will remain running should a drive go bad. I'm > not sure how the system would handle this given ahd cannot handle pulling > of hot drives out. I will try to get in touch with the driver maintainer. > > Thanks again! > -Simon > > On Wed, 2 May 2012 17:21:14 -0500, Mark Felder wrote: > >> On Wed, 02 May 2012 17:06:04 -0500, wrote: >>> Having said the above, is there any FreeBSD RAID software I can use with >>> ahb driver that won't give me same issues I'm experiencing with ahd and >>> ZFS? >>> vinum? gmirror? Can I expect them to work better with ahd given ahd >>> cannot >>> handle pulling of working drives out of SAF-TE aware enclosure? >> We're pretty sure it's not the /RAID Software/ and that it's a driver >> issue. I don't think with your version of FreeBSD that you can do *any* >> hot swapping of drives with that controller. >> Ask the maintainer of the ahd driver to take a look -- he might be able to >> provide a patch. >> _______________________________________________ >> freebsd-fs@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-fs >> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Thu May 3 15:02:59 2012 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 6E451106564A; Thu, 3 May 2012 15:02:59 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5287C8FC12; Thu, 3 May 2012 15:02:58 +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 SAA02851; Thu, 03 May 2012 18:02:52 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4FA29E1B.7040005@FreeBSD.org> Date: Thu, 03 May 2012 18:02:51 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120428 Thunderbird/12.0 MIME-Version: 1.0 To: Marius Strobl , Gavin Mu , John Baldwin References: <4F8999D2.1080902@FreeBSD.org> <20120422212102.GA66855@alchemy.franken.de> <4F9A6180.8090500@FreeBSD.org> <20120429164623.GG68446@alchemy.franken.de> <4F9E3971.7090405@FreeBSD.org> <20120501202128.GD18650@alchemy.franken.de> In-Reply-To: <20120501202128.GD18650@alchemy.franken.de> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool 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, 03 May 2012 15:02:59 -0000 Here's the latest version of the patches: http://people.freebsd.org/~avg/zfsboot.patches.4.diff John, the first of the patches implements the approach that we previously discussed. All arguments are passed starting at a fixed offset that should provide enough space for extending argument list. The first of the extended arguments should be a size of the arguments (including the size field). Then it's easy to write something like: struct xargs { uint32_t size; ... }; ... struct xargs xargs; xargs.size = sizeof(xargs); ... __exec(..., xargs); Marius, Gavin, patch 1f94d9a is my attempt of adapting your sparc64 ZFS code to my larger changes in patch ae5a9c6. I have the patches separate to facilitate the review. They should be committed together. I have only compile-tested the sparc64/ofw part, so it could have some grave bugs or omissions. Could you please review and/or test this patch? I will greatly appreciate any discussion, suggestions, help. I again invite everyone else to take part in the review and testing. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu May 3 15:23:57 2012 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 27C4D1065673; Thu, 3 May 2012 15:23:57 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 0D5C78FC1D; Thu, 3 May 2012 15:23:55 +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 SAA03020; Thu, 03 May 2012 18:23:52 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4FA2A307.2090108@FreeBSD.org> Date: Thu, 03 May 2012 18:23:51 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120428 Thunderbird/12.0 MIME-Version: 1.0 To: Marius Strobl , Gavin Mu , John Baldwin References: <4F8999D2.1080902@FreeBSD.org> <20120422212102.GA66855@alchemy.franken.de> <4F9A6180.8090500@FreeBSD.org> <20120429164623.GG68446@alchemy.franken.de> <4F9E3971.7090405@FreeBSD.org> <20120501202128.GD18650@alchemy.franken.de> <4FA29E1B.7040005@FreeBSD.org> In-Reply-To: <4FA29E1B.7040005@FreeBSD.org> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool 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, 03 May 2012 15:23:57 -0000 on 03/05/2012 18:02 Andriy Gapon said the following: > > Here's the latest version of the patches: > http://people.freebsd.org/~avg/zfsboot.patches.4.diff I've found a couple of problems in the previous version, so here's another one: http://people.freebsd.org/~avg/zfsboot.patches.5.diff The important change is in the first patch (__exec args). > John, > the first of the patches implements the approach that we previously discussed. > All arguments are passed starting at a fixed offset that should provide enough > space for extending argument list. The first of the extended arguments should be > a size of the arguments (including the size field). Then it's easy to write > something like: > struct xargs > { > uint32_t size; > ... > }; > ... > struct xargs xargs; > xargs.size = sizeof(xargs); > ... > __exec(..., xargs); > > > Marius, Gavin, > patch 1f94d9a is my attempt of adapting your sparc64 ZFS code to my larger changes > in patch ae5a9c6. I have the patches separate to facilitate the review. They > should be committed together. I have only compile-tested the sparc64/ofw part, so > it could have some grave bugs or omissions. > Could you please review and/or test this patch? > I will greatly appreciate any discussion, suggestions, help. > > I again invite everyone else to take part in the review and testing. > -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Thu May 3 22:50:34 2012 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 390BA106566C for ; Thu, 3 May 2012 22:50:34 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nskntmtas02p.mx.bigpond.com (nskntmtas02p.mx.bigpond.com [61.9.168.140]) by mx1.freebsd.org (Postfix) with ESMTP id CC6358FC0C for ; Thu, 3 May 2012 22:50:33 +0000 (UTC) Received: from nskntcmgw09p ([61.9.169.169]) by nskntmtas02p.mx.bigpond.com with ESMTP id <20120503225027.GVYQ24575.nskntmtas02p.mx.bigpond.com@nskntcmgw09p>; Thu, 3 May 2012 22:50:27 +0000 Received: from johnny.reilly.home ([124.188.162.192]) by nskntcmgw09p with BigPond Outbound id 5aqS1j00G49NTNc01aqSTB; Thu, 03 May 2012 22:50:27 +0000 X-Authority-Analysis: v=2.0 cv=Lam+G0ji c=1 sm=1 a=E3UA96qjU4/DKYBP5EH6OA==:17 a=z1TLwsU0kBEA:10 a=zX61To6fwxcA:10 a=kj9zAlcOel0A:10 a=fymICWX_wfrnZ7_I4q8A:9 a=CjuIK1q_8ugA:10 a=E3UA96qjU4/DKYBP5EH6OA==:117 Date: Fri, 4 May 2012 08:50:26 +1000 From: Andrew Reilly To: George Kontostanos Message-ID: <20120503225026.GA26284@johnny.reilly.home> References: <20120502063927.GA9559@johnny.reilly.home> <4FA0D844.8090105@brockmann-consult.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-fs@freebsd.org Subject: Re: gpart labels - why arent't some showing up in /dev/gpt/? 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, 03 May 2012 22:50:34 -0000 On Wed, May 02, 2012 at 12:11:41PM +0300, George Kontostanos wrote: > You can always use: gpart show -l > > That should display the label. Or gpart list, for more verbose output. Neither of those helps with commands that require arguments that are device names under /dev, though (such as mount or zpool create), which I where my problem lies. Perhaps I explained it poorly, sorry. Cheers, -- Andrew From owner-freebsd-fs@FreeBSD.ORG Thu May 3 22:52:41 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 630C3106566C for ; Thu, 3 May 2012 22:52:41 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nskntmtas01p.mx.bigpond.com (nskntmtas01p.mx.bigpond.com [61.9.168.137]) by mx1.freebsd.org (Postfix) with ESMTP id DB1908FC0C for ; Thu, 3 May 2012 22:52:40 +0000 (UTC) Received: from nskntcmgw06p ([61.9.169.166]) by nskntmtas01p.mx.bigpond.com with ESMTP id <20120503225239.QVOG25972.nskntmtas01p.mx.bigpond.com@nskntcmgw06p>; Thu, 3 May 2012 22:52:39 +0000 Received: from johnny.reilly.home ([124.188.162.192]) by nskntcmgw06p with BigPond Outbound id 5ase1j00849NTNc01aseQ6; Thu, 03 May 2012 22:52:39 +0000 X-Authority-Analysis: v=2.0 cv=MaHuSuDf c=1 sm=1 a=E3UA96qjU4/DKYBP5EH6OA==:17 a=z1TLwsU0kBEA:10 a=zX61To6fwxcA:10 a=8nJEP1OIZ-IA:10 a=Iv6oGRHAcW35ojyYhosA:9 a=wPNLvfGTeEIA:10 a=E3UA96qjU4/DKYBP5EH6OA==:117 Date: Fri, 4 May 2012 08:52:38 +1000 From: Andrew Reilly To: Gustau =?iso-8859-1?Q?P=E9rez?= i Querol Message-ID: <20120503225238.GB26284@johnny.reilly.home> References: <20120502063927.GA9559@johnny.reilly.home> <4FA0D844.8090105@brockmann-consult.de> <4FA0FE82.4040600@entel.upc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4FA0FE82.4040600@entel.upc.edu> User-Agent: Mutt/1.4.2.3i Cc: freebsd-fs@freebsd.org Subject: Re: gpart labels - why arent't some showing up in /dev/gpt/? 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, 03 May 2012 22:52:41 -0000 On Wed, May 02, 2012 at 11:29:38AM +0200, Gustau Pérez i Querol wrote: > Al 02/05/2012 08:46, En/na Peter Maloney ha escrit: > >I have the same problem. Any time you boot off a CD/DVD and use import > >-f (and then don't export), or I guess use import -f a pool from > >anywhere, it does that. I don't know any non-zfs causes for the problem. > > When doing the import -f, use -d /dev/gpt to force zpool to search > for devices in /dev/gpt. That way the import will be done by gpt name, > instead of by device name. I'm not sure that would work if the /dev/gpt directory doesn't list the devices by gpt label at all? In my case, even if that helps with import, it doesn't seem to help with zpool create, because that doesn't take a -d option. It just wants device names. Cheers, -- Andrew From owner-freebsd-fs@FreeBSD.ORG Thu May 3 23:22:55 2012 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 A9933106564A for ; Thu, 3 May 2012 23:22:55 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nschwmtas05p.mx.bigpond.com (nschwmtas05p.mx.bigpond.com [61.9.189.149]) by mx1.freebsd.org (Postfix) with ESMTP id 435408FC16 for ; Thu, 3 May 2012 23:22:55 +0000 (UTC) Received: from nschwcmgw08p ([61.9.190.168]) by nschwmtas05p.mx.bigpond.com with ESMTP id <20120503232253.PAOI2821.nschwmtas05p.mx.bigpond.com@nschwcmgw08p>; Thu, 3 May 2012 23:22:53 +0000 Received: from johnny.reilly.home ([124.188.162.192]) by nschwcmgw08p with BigPond Outbound id 5bNs1j00H49NTNc01bNsNF; Thu, 03 May 2012 23:22:53 +0000 X-Authority-Analysis: v=2.0 cv=IJWA+3TG c=1 sm=1 a=E3UA96qjU4/DKYBP5EH6OA==:17 a=z1TLwsU0kBEA:10 a=zX61To6fwxcA:10 a=8nJEP1OIZ-IA:10 a=mEHxMtioXnnVHlxQzgwA:9 a=wPNLvfGTeEIA:10 a=E3UA96qjU4/DKYBP5EH6OA==:117 Date: Fri, 4 May 2012 09:22:52 +1000 From: Andrew Reilly To: Gustau =?iso-8859-1?Q?P=E9rez?= i Querol Message-ID: <20120503232252.GC26284@johnny.reilly.home> References: <20120502063927.GA9559@johnny.reilly.home> <4FA0D844.8090105@brockmann-consult.de> <4FA0FE82.4040600@entel.upc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4FA0FE82.4040600@entel.upc.edu> User-Agent: Mutt/1.4.2.3i Cc: freebsd-fs@freebsd.org Subject: Re: gpart labels - why arent't some showing up in /dev/gpt/? 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, 03 May 2012 23:22:55 -0000 On Wed, May 02, 2012 at 11:29:38AM +0200, Gustau Pérez i Querol wrote: > Al 02/05/2012 08:46, En/na Peter Maloney ha escrit: > >I have the same problem. Any time you boot off a CD/DVD and use import > >-f (and then don't export), or I guess use import -f a pool from > >anywhere, it does that. I don't know any non-zfs causes for the problem. > > When doing the import -f, use -d /dev/gpt to force zpool to search > for devices in /dev/gpt. That way the import will be done by gpt name, > instead of by device name. I've just read the manpage on that option again, and I don't think that it would help, even if it was available. I had previously been able to refer to gpt entries as paths from /dev, without it. I.e., zpool create raidz tank gpt/zraid1 gpt/zraid2 ... etc. My problem at the moment is that the /dev/gpt/zraid1 etc entries aren't there at all, and zpool create complains about exactly that problem. It's not a question of using -d /dev/gpt to short-cut the path name. Cheers, -- Andrew From owner-freebsd-fs@FreeBSD.ORG Fri May 4 00:14:40 2012 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2CD57106566B; Fri, 4 May 2012 00:14:40 +0000 (UTC) (envelope-from araujo@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0114A8FC08; Fri, 4 May 2012 00:14:40 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q440EdwC039775; Fri, 4 May 2012 00:14:39 GMT (envelope-from araujo@freefall.freebsd.org) Received: (from araujo@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q440EdPV039771; Fri, 4 May 2012 00:14:39 GMT (envelope-from araujo) Date: Fri, 4 May 2012 00:14:39 GMT Message-Id: <201205040014.q440EdPV039771@freefall.freebsd.org> To: maciej.gabryszak@gmail.com, araujo@FreeBSD.org, freebsd-fs@FreeBSD.org From: araujo@FreeBSD.org Cc: Subject: Re: kern/162083: [zfs] [panic] zfs unmount -f pool 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, 04 May 2012 00:14:40 -0000 Synopsis: [zfs] [panic] zfs unmount -f pool State-Changed-From-To: open->closed State-Changed-By: araujo State-Changed-When: Fri May 4 00:14:39 UTC 2012 State-Changed-Why: I sent some emails to Maciej and he told me that reinstalled the system with FreeBSD 9.0-CURRENT and the problem disappeared. So, he also said that I could close this pr. http://www.freebsd.org/cgi/query-pr.cgi?pr=162083 From owner-freebsd-fs@FreeBSD.ORG Fri May 4 01:51:18 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 821) id C61FF1065673; Fri, 4 May 2012 01:51:18 +0000 (UTC) Date: Fri, 4 May 2012 01:51:18 +0000 From: John To: freebsd-fs@FreeBSD.org Message-ID: <20120504015118.GA42954@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: ZFS zfs_freebsd_* routines and ASSERT( ... | SAVENAME) usage 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, 04 May 2012 01:51:18 -0000 Hi Folks, I've been trying to trace down namei buffer usage. In the ZFS code in sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c there are the zfs_freebsd_*() routines. Many of them contain code similar to the following: ASSERT(cnp->cn_flags & SAVENAME); However, zfs_freebsd_lookup() does not. Later, in zfs_lookup() there is this comment: /* Translate errors and add SAVENAME when needed. */ and this code: if (cnp->cn_flags & ISLASTCN) { switch (nameiop) { case CREATE: case RENAME: if (error == ENOENT) { error = EJUSTRETURN; cnp->cn_flags |= SAVENAME; break; } /* FALLTHROUGH */ case DELETE: if (error == 0) cnp->cn_flags |= SAVENAME; break; } } Can someone with more knowledge of the ZFS code shed some light on what is happening here? Why does ZFS need SAVENAME in these instances. Also, maybe I'm missing some logic, would it read more clearly with "error == ENOENT || error == 0" in an isolated CREATE and RENAME case (without the fall through)? I appreciate any pointers. Thanks, John From owner-freebsd-fs@FreeBSD.ORG Fri May 4 02:32:47 2012 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 422EB106566B for ; Fri, 4 May 2012 02:32:47 +0000 (UTC) (envelope-from sukenwoo@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0248A8FC08 for ; Fri, 4 May 2012 02:32:46 +0000 (UTC) Received: by obcni5 with SMTP id ni5so4210384obc.13 for ; Thu, 03 May 2012 19:32:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aC2hgDiDjBuJXOMFvow4yzIxGeCdPLY/x/DT++TWuqk=; b=y/27JoX+z62dHWUEAbKTq7OFM8zVCkupN1BUmCK0d7UvGk5i7yOfzz0rYTspREP8Q3 wT7u28AHSsDCqpSI5FxPQipRr7Bbi8M+FzfbON9WlHYVNvzXoONb5Lc7cjyfdS9wKM8x 8ZL4ibG2IKoqC3ZA7+AzLX4AIviw05Bc6XK+xkPQriDJ+WPSVSsi95HQ/3bgWkITNuKw 6FpzpgXnfu9Ao5+ltWcH4wkdpklWsAjviYVUTCrIKE6cJ6IO9OdnpSvmFix4UcKl/oy5 QiXXHsVCdy88XUuYiNIzkNGPgK2v4QxmKCm/ftzxuIzJbeGazFz4zOiAmzDVm5Tg37/v hagA== MIME-Version: 1.0 Received: by 10.182.44.74 with SMTP id c10mr5765668obm.43.1336098766234; Thu, 03 May 2012 19:32:46 -0700 (PDT) Received: by 10.182.49.71 with HTTP; Thu, 3 May 2012 19:32:46 -0700 (PDT) In-Reply-To: References: <4fa128a8.9089e50a.12cb.ffff8b5eSMTPIN_ADDED@mx.google.com> Date: Fri, 4 May 2012 10:32:46 +0800 Message-ID: From: suken woo To: Simon , peter.maloney@brockmann-consult.de Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "fs@freebsd.org" Subject: Re: urgent system suddenly boot failed due to ZFS:i/o error on FreeBSD 8.2 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, 04 May 2012 02:32:47 -0000 Peter, in my situation, my zpool created under a RAID5 disk array controller mfid0 and without spare disk settings. Is't the disk fault issue?and how to resolve? thanks >This happened to me when my root pool had an active hot spare. I later >tested it on a virtual machine, and even with non-spare disks added, the >system did the same thing. >Here is my PR: >http://www.freebsd.org/cgi/query-pr.cgi?pr=167065 >kern/167065 >My solution was to boot on a DVD, and then "zpool detach" the bad disk >(which converted the spare to a normal mirror). >On 05/02/2012 02:03 PM, suken woo wrote: > hi,lists > for some reasons I need restart system but it suddenly boot failed today. > here is the error: > ZFS: i/o error - all block copies unavailable > ZFS: can't read object set for dataset 16 > Can't find root filesystem - giving up > ZFS:unexcepted object set type 0 > ZFS:unexcepted object set type 0 > > FreeBSD/i386 boot > Default: zroot:/boot/kernel/kernel > boot: > ZFS:unexcepted object set type0 > > FreeBSD/i386 boot > Default: zroot:/boot/kernel/kernel > boot: _ > > any ideas to resolved it? > thanks in advance > _______________________________________________ > 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" -- -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str. 2 21502 Geesthacht Germany Tel: +49 4152 889 300 Fax: +49 4152 889 333 E-mail: peter.maloney@brockmann-consult.de Internet: http://www.brockmann-consult.de -------------------------------------------- From owner-freebsd-fs@FreeBSD.ORG Fri May 4 06:59:38 2012 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 024581065672 for ; Fri, 4 May 2012 06:59:38 +0000 (UTC) (envelope-from peter.maloney@brockmann-consult.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.freebsd.org (Postfix) with ESMTP id 9DDDA8FC14 for ; Fri, 4 May 2012 06:59:37 +0000 (UTC) Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0Lc2Qz-1Rj82l3gbV-00jzrO; Fri, 04 May 2012 08:59:35 +0200 Message-ID: <4FA37E55.7060708@brockmann-consult.de> Date: Fri, 04 May 2012 08:59:33 +0200 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: suken woo References: <4fa128a8.9089e50a.12cb.ffff8b5eSMTPIN_ADDED@mx.google.com> In-Reply-To: X-Provags-ID: V02:K0:3vwGtql/faRFYpxd+NjFau7tU/GalYtLtfBFIc+u4t7 ULvLVsvWLzBTih/49vijaZb9uhQJYFOt0uXkv5fnm0ZowOaRHj M1x5dJ2D7H/dHFE282uLTJnCUyxwGH5HbxPsjIG03pCFLQ4Vke 6jq0VzSn1HRLSRV1SiXcq7xR4wg3vYmQyTes3byHstBVZwQaHR uBsp9R4Y4T37yZfpVPqi5myFEXF/gqfD3IiaER/sFU2QfvtZcR P1AEyMt87zMXivYhJgzSXjn4YjXZx3qc5DJML5voVBEM7dl63y OXRW+i1AgJR8Kq26bmyzOEXI4D+f6A+fkg7h+NDpVInFgUK0MU Xu76Ieo9R/rRyylXnOR5kuT6OdDj+Q7OO8etqrBqt Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "fs@freebsd.org" Subject: Re: urgent system suddenly boot failed due to ZFS:i/o error on FreeBSD 8.2 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, 04 May 2012 06:59:38 -0000 Boot off of the FreeBSD DVD and do the following: select FixIt (option 4 I think) select CD/DVD (brings you to a shell) (option 2 I think) type: # kldload /mnt2/boot/kernel/opensolaris.ko # kldload /mnt2/boot/kernel/zfs.ko warning: this will make any gpt/ labels in your zpool status turn into ugliness that looks like this: gptid/44b52f4d-5d75-11e1-b476-080027e5bb66) # import -f -o altroot=/z -o cachefile=/tmp/zpool.cache zroot If you don't use altroot above, the pool will be mounted on top of what is mounted from the cd, and everything will stop working. in another thread, using -d was suggested to prevent the gptid problem, but I have not tested it: # import -f -d /dev/gpt -o altroot=/z -o cachefile=/tmp/zpool.cache zroot Copy the cache file (this fixes many boots that say "ZFS: i/o error - all block copies unavailable", but I have not seen the "ZFS:unexcepted object set type 0" error except with my hot spare, so might not work) # cp /tmp/zpool.cache /z/boot/zfs/zpool.cache Then type: # zpool status and take a camera shot, or send it on the network, etc. to paste it into an email, so we can see it. eg. you could try sending it to another server: # zpool status > /tmp/status.txt # scp /tmp/status.txt user@server:~/ Then install the bootloader again... if you don't remember how, this guess might be wrong, but here is what I do on my system: figure out what index the boot slice is: # gpart show da0 then in the following, replace the 1 with the index of your boot slice: # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0 # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da1 (... for each boot disk) Then reboot WITHOUT exporting the pool, and see if it is fixed. If not, send your email with the status.txt. On 05/04/2012 04:32 AM, suken woo wrote: > Peter, in my situation, my zpool created under a RAID5 disk array controller mfid0 and without spare disk settings. Is't the disk fault issue?and how to resolve? > thanks > >This happened to me when my root pool had an active hot spare. I later > >tested it on a virtual machine, and even with non-spare disks added, the > >system did the same thing. > > >Here is my PR: > >http://www.freebsd.org/cgi/query-pr.cgi?pr=167065 > > >kern/167065 > > >My solution was to boot on a DVD, and then "zpool detach" the bad disk > >(which converted the spare to a normal mirror). > > > >On 05/02/2012 02:03 PM, suken woo wrote: > > hi,lists > > for some reasons I need restart system but it suddenly boot failed today. > > here is the error: > > ZFS: i/o error - all block copies unavailable > > ZFS: can't read object set for dataset 16 > > Can't find root filesystem - giving up > > ZFS:unexcepted object set type 0 > > ZFS:unexcepted object set type 0 > > > > FreeBSD/i386 boot > > Default: zroot:/boot/kernel/kernel > > boot: > > ZFS:unexcepted object set type0 > > > > FreeBSD/i386 boot > > Default: zroot:/boot/kernel/kernel > > boot: _ > > > > any ideas to resolved it? > > thanks in advance > > _______________________________________________ > > 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 " > > > -- > > -------------------------------------------- > Peter Maloney > Brockmann Consult > Max-Planck-Str. 2 > 21502 Geesthacht > Germany > Tel: +49 4152 889 300 > Fax: +49 4152 889 333 > E-mail:peter.maloney@brockmann-consult.de > Internet:http://www.brockmann-consult.de > -------------------------------------------- -- -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str. 2 21502 Geesthacht Germany Tel: +49 4152 889 300 Fax: +49 4152 889 333 E-mail: peter.maloney@brockmann-consult.de Internet: http://www.brockmann-consult.de -------------------------------------------- From owner-freebsd-fs@FreeBSD.ORG Fri May 4 07:25:18 2012 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 EFCE31065670 for ; Fri, 4 May 2012 07:25:18 +0000 (UTC) (envelope-from peter.maloney@brockmann-consult.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.freebsd.org (Postfix) with ESMTP id 98C618FC0C for ; Fri, 4 May 2012 07:25:18 +0000 (UTC) Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0LtBoV-1S1A3v2TZD-012Kpi; Fri, 04 May 2012 09:25:12 +0200 Message-ID: <4FA38458.3040801@brockmann-consult.de> Date: Fri, 04 May 2012 09:25:12 +0200 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Andrew Reilly References: <20120502063927.GA9559@johnny.reilly.home> <4FA0D844.8090105@brockmann-consult.de> <4FA0FE82.4040600@entel.upc.edu> <20120503232252.GC26284@johnny.reilly.home> In-Reply-To: <20120503232252.GC26284@johnny.reilly.home> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V02:K0:Bt2ttNx3PZQ2d9CUi4lCqi0B+LTqk4jPH+NrWLsE6TC tMvzsbU0GTV8daEDKfSTlF7gf2/Cdge8hCbLGWJUvXGCKSkaEb hp8miEq162yjLXLBjcRxFuSEiyp1XjbgVU6RfURAKHsvuPT4pt vNn/NOXqT5fHO4hdztYURjHnmIw+OOr77210XTjAJKbuj2Z/rI AaYgL0gI6HX6lxjzKZPulFuP6Mjx9fnb7cHYCYPEhAVzqWmhca VHDAiOcDNzrh+Mc3bygL7Z+lWa3EeqB97Kmpn5RtCr6hMtXH47 mtT/RtC4kYLUM0m3oBhXc1NsfV+cMIxNpgUCwBcB53kB8dkiIT 9qSo7hsPz2IKM03ttk69j70ATlEV8hdka6hFjc8ls Cc: freebsd-fs@freebsd.org Subject: Re: gpart labels - why arent't some showing up in /dev/gpt/? 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, 04 May 2012 07:25:19 -0000 On 05/04/2012 01:22 AM, Andrew Reilly wrote: > On Wed, May 02, 2012 at 11:29:38AM +0200, Gustau Pérez i Querol wrote: >> Al 02/05/2012 08:46, En/na Peter Maloney ha escrit: >>> I have the same problem. Any time you boot off a CD/DVD and use import >>> -f (and then don't export), or I guess use import -f a pool from >>> anywhere, it does that. I don't know any non-zfs causes for the problem. >> When doing the import -f, use -d /dev/gpt to force zpool to search >> for devices in /dev/gpt. That way the import will be done by gpt name, >> instead of by device name. > I've just read the manpage on that option again, and I don't > think that it would help, even if it was available. Let's test that then, shall we? Here is an old VM I have, where one slice lost its gpt label. ================== part 1: previously lost label on non-root disk ================== # zpool status test2 pool: test2 state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM test2 ONLINE 0 0 0 gptid/44b52f4d-5d75-11e1-b476-080027e5bb66 ONLINE 0 0 0 # zdb ... test2: version: 28 name: 'test2' state: 0 txg: 4 pool_guid: 16644836222594068864 hostid: 871222403 hostname: 'bczfsvm1test.bc.local' vdev_children: 1 vdev_tree: type: 'root' id: 0 guid: 16644836222594068864 create_txg: 4 children[0]: type: 'disk' id: 0 guid: 1497402725988130066 path: '/dev/da3p1' phys_path: '/dev/da3p1' whole_disk: 1 metaslab_array: 30 metaslab_shift: 22 ashift: 9 asize: 729284608 is_log: 0 create_txg: 4 ... da3 is wrong (another pool uses da3, and gpart show da3 shows "no such geom")... so now I try to figure out which disk it really is: # dd if=/dev/gptid/44b52f4d-5d75-11e1-b476-080027e5bb66 of=/dev/null bs=1M count=5000 >/dev/null 2>&1 & # gstat here are the high load ones: L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 0 600 600 76798 1.0 0 0 0.0 60.1| da4 0 601 601 76924 1.1 0 0 0.0 66.4| da4p1 0 601 601 76924 1.2 0 0 0.0 70.6| gptid/44b52f4d-5d75-11e1-b476-080027e5bb66 # gpart show da4 => 34 41942973 da4 GPT (20G) 34 1433600 1 freebsd-zfs (700M) 1433634 40509373 - free - (19G) # gpart show -l da4 => 34 41942973 da4 GPT (20G) 34 1433600 1 (null) (700M) 1433634 40509373 - free - (19G) (Strange... I thought usually when this happens, the label still shows in gpart) # ls /dev/gpt root0 root1 swap0 swap1 # shutdown -r now # zpool import -f -d /dev/gpt test2 cannot import 'test2': no such pool available # gpart modify -i 1 -l test2d1 da4 da4p1 modified # ls /dev/gpt (expecting not to see it here... never works this way, but maybe rescan or reboot will work; I don't know how to make it 'retaste' the partitions other than gpart delete and create) root0 root1 swap0 swap1 # camcontrol rescan 0 Re-scan of bus 0 was successful # ls /dev/gpt (not sure what to expect here) root0 root1 swap0 swap1 # shutdown -r now # ls /dev/gpt/ root0 root1 swap0 swap1 test2d1 # zpool import test2 # zpool status test2 pool: test2 state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM test2 ONLINE 0 0 0 gptid/44b52f4d-5d75-11e1-b476-080027e5bb66 ONLINE 0 0 0 # shutdown -r now # zpool import -d /dev/gpt test2 # zpool status test2 # zpool status test2 config: NAME STATE READ WRITE CKSUM test2 ONLINE 0 0 0 gpt/test2d1 ONLINE 0 0 0 # zdb ... test2: version: 28 name: 'test2' state: 0 txg: 24635 pool_guid: 16644836222594068864 hostid: 871222403 hostname: 'bczfsvm1test.bc.local' vdev_children: 1 vdev_tree: type: 'root' id: 0 guid: 16644836222594068864 children[0]: type: 'disk' id: 0 guid: 1497402725988130066 path: '/dev/gpt/test2d1' phys_path: '/dev/gpt/test2d1' whole_disk: 1 metaslab_array: 30 metaslab_shift: 22 ashift: 9 asize: 729284608 is_log: 0 create_txg: 4 ... # zpool export test2 # zpool import test2 # zpool status test2 config: NAME STATE READ WRITE CKSUM test2 ONLINE 0 0 0 gpt/test2d1 ONLINE 0 0 0 ================== part 2: root disk ================== # zpool status zroot config: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 gpt/root0 ONLINE 0 0 0 gpt/root1 ONLINE 0 0 0 # shutdown -r boot on DVD (to break it, just to prove that the fix works) # kldload /mnt2/boot/kernel/opensolaris.ko # kldload /mnt2/boot/kernel/zfs.ko # ls /dev/gpt root0 root1 swap0 swap1 test2d1 # zpool import -f zroot # zpool status zpool: not found (oops... forgot to use altroot, so the booted fixit system is broken now... oh well, just remove DVD and reset) # zpool status zroot config: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 da0p3 ONLINE 0 0 0 da2p3 ONLINE 0 0 0 (strange... usually you get gptid stuff instead of device names) # ls /dev/gpt swap0 swap1 test2d1 # shutdown -r now boot DVD again (to fix it) # kldload /mnt2/boot/kernel/opensolaris.ko # kldload /mnt2/boot/kernel/zfs.ko # ls /dev/gpt root0 root1 swap0 swap1 test2d1 # zpool import -f -d /dev/gpt -o altroot=/z zroot # zpool status config: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 gpt/root0 ONLINE 0 0 0 gpt/root1 ONLINE 0 0 0 Remove DVD and boot # zpool status zroot pool: zroot state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 gpt/root0 ONLINE 0 0 0 gpt/root1 ONLINE 0 0 0 So, it seems to work... but not if you do it in the wrong order. You need to set the label again, and boot without the pool imported before /gpt/ exists. Then you need to use -d. And thank you Gustau Pérez i Querol! I didn't know about -d. > I had > previously been able to refer to gpt entries as paths from /dev, > without it. I.e., zpool create raidz tank gpt/zraid1 gpt/zraid2 > ... etc. My problem at the moment is that the /dev/gpt/zraid1 > etc entries aren't there at all, and zpool create complains > about exactly that problem. It's not a question of using -d > /dev/gpt to short-cut the path name. > > Cheers, > -- -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str. 2 21502 Geesthacht Germany Tel: +49 4152 889 300 Fax: +49 4152 889 333 E-mail: peter.maloney@brockmann-consult.de Internet: http://www.brockmann-consult.de -------------------------------------------- From owner-freebsd-fs@FreeBSD.ORG Fri May 4 07:37:44 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B87F2106564A for ; Fri, 4 May 2012 07:37:44 +0000 (UTC) (envelope-from peter.maloney@brockmann-consult.de) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by mx1.freebsd.org (Postfix) with ESMTP id 5A0B38FC08 for ; Fri, 4 May 2012 07:37:44 +0000 (UTC) Received: from [10.3.0.26] ([141.4.215.32]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0LbgPT-1RjUU80bXP-00kVaP; Fri, 04 May 2012 09:37:43 +0200 Message-ID: <4FA38746.5070903@brockmann-consult.de> Date: Fri, 04 May 2012 09:37:42 +0200 From: Peter Maloney User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <20120502063927.GA9559@johnny.reilly.home> <4FA0D844.8090105@brockmann-consult.de> <4FA0FE82.4040600@entel.upc.edu> <20120503232252.GC26284@johnny.reilly.home> <4FA38458.3040801@brockmann-consult.de> In-Reply-To: <4FA38458.3040801@brockmann-consult.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V02:K0:wLINu+zGd5Um1/nmkCdzhm0WxqZRBl7ntUpdP936wZP 7MbvqIi7mAXQZkLpLMeZ5dUOnuYJoqOl3T+DMbh9thYGPm9H6j ZwppT8XAj93Ie8AbkZ62HqlPvwDMc+99q/Q6gb2k+Plpb+E+Ej 96t7cUTEVHYNpeDR+cICGeusDnk3i81fnp69ftHO6ug9+WYTsY +WcY6LnWK/htlMtUsk28zIB2cF0+PehrhlMDAT5n9R8LeXkvxX X5JeTkhJYbwwfRC+PjuDP/p1XbFsx4YCGdmN6UPubMpAI1kWwm 82kPBYFmRJkJSiwVLCv0AQpeOl6AcOmWV81hbnFgPJ7Lm485Gh ThL73WDPjBgKGp4KjXRMOQ0I6nP+3SGcN968P4O2h Subject: Re: gpart labels - why arent't some showing up in /dev/gpt/? 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, 04 May 2012 07:37:44 -0000 Added one line below (forgot to add an export before a reboot) On 05/04/2012 09:25 AM, Peter Maloney wrote: > On 05/04/2012 01:22 AM, Andrew Reilly wrote: >> On Wed, May 02, 2012 at 11:29:38AM +0200, Gustau Pérez i Querol wrote: >>> Al 02/05/2012 08:46, En/na Peter Maloney ha escrit: >>>> I have the same problem. Any time you boot off a CD/DVD and use import >>>> -f (and then don't export), or I guess use import -f a pool from >>>> anywhere, it does that. I don't know any non-zfs causes for the >>>> problem. >>> When doing the import -f, use -d /dev/gpt to force zpool to search >>> for devices in /dev/gpt. That way the import will be done by gpt name, >>> instead of by device name. >> I've just read the manpage on that option again, and I don't >> think that it would help, even if it was available. > Let's test that then, shall we? > > Here is an old VM I have, where one slice lost its gpt label. > > ================== > part 1: previously lost label on non-root disk > ================== > > # zpool status test2 > pool: test2 > state: ONLINE > scan: none requested > config: > > NAME STATE READ > WRITE CKSUM > test2 ONLINE > 0 0 0 > gptid/44b52f4d-5d75-11e1-b476-080027e5bb66 ONLINE > 0 0 0 > > # zdb > ... > test2: > version: 28 > name: 'test2' > state: 0 > txg: 4 > pool_guid: 16644836222594068864 > hostid: 871222403 > hostname: 'bczfsvm1test.bc.local' > vdev_children: 1 > vdev_tree: > type: 'root' > id: 0 > guid: 16644836222594068864 > create_txg: 4 > children[0]: > type: 'disk' > id: 0 > guid: 1497402725988130066 > path: '/dev/da3p1' > phys_path: '/dev/da3p1' > whole_disk: 1 > metaslab_array: 30 > metaslab_shift: 22 > ashift: 9 > asize: 729284608 > is_log: 0 > create_txg: 4 > > ... > > > da3 is wrong (another pool uses da3, and gpart show da3 shows "no such > geom")... so now I try to figure out which disk it really is: > > # dd if=/dev/gptid/44b52f4d-5d75-11e1-b476-080027e5bb66 of=/dev/null > bs=1M count=5000 >/dev/null 2>&1 & > # gstat > > here are the high load ones: > L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name > 0 600 600 76798 1.0 0 0 0.0 60.1| da4 > 0 601 601 76924 1.1 0 0 0.0 66.4| da4p1 > 0 601 601 76924 1.2 0 0 0.0 70.6| > gptid/44b52f4d-5d75-11e1-b476-080027e5bb66 > > # gpart show da4 > => 34 41942973 da4 GPT (20G) > 34 1433600 1 freebsd-zfs (700M) > 1433634 40509373 - free - (19G) > > # gpart show -l da4 > => 34 41942973 da4 GPT (20G) > 34 1433600 1 (null) (700M) > 1433634 40509373 - free - (19G) > > (Strange... I thought usually when this happens, the label still shows > in gpart) > > # ls /dev/gpt > root0 root1 swap0 swap1 > > # shutdown -r now > > # zpool import -f -d /dev/gpt test2 > cannot import 'test2': no such pool available > > # gpart modify -i 1 -l test2d1 da4 > da4p1 modified > # ls /dev/gpt (expecting not to see it here... never works this way, > but maybe rescan or reboot will work; I don't know how to make it > 'retaste' the partitions other than gpart delete and create) > root0 root1 swap0 swap1 > # camcontrol rescan 0 > Re-scan of bus 0 was successful > # ls /dev/gpt (not sure what to expect here) > root0 root1 swap0 swap1 > > # shutdown -r now > > # ls /dev/gpt/ > root0 root1 swap0 swap1 test2d1 > > # zpool import test2 > # zpool status test2 > pool: test2 > state: ONLINE > scan: none requested > config: > > NAME STATE READ > WRITE CKSUM > test2 ONLINE > 0 0 0 > gptid/44b52f4d-5d75-11e1-b476-080027e5bb66 ONLINE > 0 0 0 > I think at this point I forgot an export in the previous email: # zpool export test2 > # shutdown -r now > > # zpool import -d /dev/gpt test2 > # zpool status test2 > config: > > NAME STATE READ WRITE CKSUM > test2 ONLINE 0 0 0 > gpt/test2d1 ONLINE 0 0 0 > > # zdb > ... > test2: > version: 28 > name: 'test2' > state: 0 > txg: 24635 > pool_guid: 16644836222594068864 > hostid: 871222403 > hostname: 'bczfsvm1test.bc.local' > vdev_children: 1 > vdev_tree: > type: 'root' > id: 0 > guid: 16644836222594068864 > children[0]: > type: 'disk' > id: 0 > guid: 1497402725988130066 > path: '/dev/gpt/test2d1' > phys_path: '/dev/gpt/test2d1' > whole_disk: 1 > metaslab_array: 30 > metaslab_shift: 22 > ashift: 9 > asize: 729284608 > is_log: 0 > create_txg: 4 > ... > > > # zpool export test2 > # zpool import test2 > # zpool status test2 > config: > > NAME STATE READ WRITE CKSUM > test2 ONLINE 0 0 0 > gpt/test2d1 ONLINE 0 0 0 > > ================== > part 2: root disk > ================== > > # zpool status zroot > config: > > NAME STATE READ WRITE CKSUM > zroot ONLINE 0 0 0 > mirror-0 ONLINE 0 0 0 > gpt/root0 ONLINE 0 0 0 > gpt/root1 ONLINE 0 0 0 > > # shutdown -r > > boot on DVD (to break it, just to prove that the fix works) > # kldload /mnt2/boot/kernel/opensolaris.ko > # kldload /mnt2/boot/kernel/zfs.ko > # ls /dev/gpt > root0 root1 swap0 swap1 test2d1 > # zpool import -f zroot > # zpool status > zpool: not found > (oops... forgot to use altroot, so the booted fixit system is broken > now... oh well, just remove DVD and reset) > > # zpool status zroot > config: > > NAME STATE READ WRITE CKSUM > zroot ONLINE 0 0 0 > mirror-0 ONLINE 0 0 0 > da0p3 ONLINE 0 0 0 > da2p3 ONLINE 0 0 0 > > (strange... usually you get gptid stuff instead of device names) > > # ls /dev/gpt > swap0 swap1 test2d1 > > # shutdown -r now > > boot DVD again (to fix it) > # kldload /mnt2/boot/kernel/opensolaris.ko > # kldload /mnt2/boot/kernel/zfs.ko > # ls /dev/gpt > root0 root1 swap0 swap1 test2d1 > # zpool import -f -d /dev/gpt -o altroot=/z zroot > # zpool status > config: > > NAME STATE READ WRITE CKSUM > zroot ONLINE 0 0 0 > mirror-0 ONLINE 0 0 0 > gpt/root0 ONLINE 0 0 0 > gpt/root1 ONLINE 0 0 0 > > Remove DVD and boot > > # zpool status zroot > pool: zroot > state: ONLINE > scan: none requested > config: > > NAME STATE READ WRITE CKSUM > zroot ONLINE 0 0 0 > mirror-0 ONLINE 0 0 0 > gpt/root0 ONLINE 0 0 0 > gpt/root1 ONLINE 0 0 0 > > > So, it seems to work... but not if you do it in the wrong order. You > need to set the label again, and boot without the pool imported before > /gpt/ exists. Then you need to use -d. > > And thank you Gustau Pérez i Querol! I didn't know about -d. > >> I had >> previously been able to refer to gpt entries as paths from /dev, >> without it. I.e., zpool create raidz tank gpt/zraid1 gpt/zraid2 >> ... etc. My problem at the moment is that the /dev/gpt/zraid1 >> etc entries aren't there at all, and zpool create complains >> about exactly that problem. It's not a question of using -d >> /dev/gpt to short-cut the path name. >> >> Cheers, >> > > -- -------------------------------------------- Peter Maloney Brockmann Consult Max-Planck-Str. 2 21502 Geesthacht Germany Tel: +49 4152 889 300 Fax: +49 4152 889 333 E-mail: peter.maloney@brockmann-consult.de Internet: http://www.brockmann-consult.de -------------------------------------------- From owner-freebsd-fs@FreeBSD.ORG Fri May 4 09:13:49 2012 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20ACA1065673 for ; Fri, 4 May 2012 09:13:49 +0000 (UTC) (envelope-from sukenwoo@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 685198FC17 for ; Fri, 4 May 2012 09:13:48 +0000 (UTC) Received: by obcni5 with SMTP id ni5so4781112obc.13 for ; Fri, 04 May 2012 02:13:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EWAUzJdT/GLc6JjsOR7ToC9uYJcghIV+4cbYnsnp9O4=; b=I0AU/eYdrlfC2KexbVNi218iWXcJpigJ+rmw/bqk4ggk7+ZmFSANElATVRoWp8DsO0 uULqVIdQFlsi6EF476VM1hG0XaV/1ovH9f1NasgdOCgc/tHCRWjlEXFI5NsREezvD2Jp ardvWDVYyvnDgVaaZ+86Us7p7DYmNCrUzK1tuqzr70ALkpFGLUKNjbHV6Xt23lZ9X5zB JHsqE/awYNKbO3VoYO2B1TmkNaIa42E7k7I4WZRpZNGPPaYqzgu42gxUj5fAY9kcbubK pOpeSdukRtPWKIPuHrp1HA/WuLcUPb6GpxXv9pTr11EeIITL8RPRqeHz7aKFndhtNb4d 5hhA== MIME-Version: 1.0 Received: by 10.60.171.176 with SMTP id av16mr1140880oec.62.1336122827748; Fri, 04 May 2012 02:13:47 -0700 (PDT) Received: by 10.182.49.71 with HTTP; Fri, 4 May 2012 02:13:47 -0700 (PDT) In-Reply-To: <4FA37E55.7060708@brockmann-consult.de> References: <4fa128a8.9089e50a.12cb.ffff8b5eSMTPIN_ADDED@mx.google.com> <4FA37E55.7060708@brockmann-consult.de> Date: Fri, 4 May 2012 17:13:47 +0800 Message-ID: From: suken woo To: Peter Maloney Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "fs@freebsd.org" Subject: Re: urgent system suddenly boot failed due to ZFS:i/o error on FreeBSD 8.2 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, 04 May 2012 09:13:49 -0000 Thank you very much,Peter. I would like to have a try later and post any results =E5=9C=A8 2012=E5=B9=B45=E6=9C=884=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94=EF= =BC=8CPeter Maloney =E5=86=99=E9=81=93=EF=BC=9A > Boot off of the FreeBSD DVD and do the following: > > select FixIt (option 4 I think) > select CD/DVD (brings you to a shell) (option 2 I think) > > type: > # kldload /mnt2/boot/kernel/opensolaris.ko > # kldload /mnt2/boot/kernel/zfs.ko > > warning: this will make any gpt/ labels in your zpool status turn into > ugliness that looks like this: gptid/44b52f4d-5d75-11e1-b476-080027e5bb66= ) > # import -f -o altroot=3D/z -o cachefile=3D/tmp/zpool.cache zroot > > If you don't use altroot above, the pool will be mounted on top of what i= s > mounted from the cd, and everything will stop working. > > in another thread, using -d was suggested to prevent the gptid problem, > but I have not tested it: > # import -f -d /dev/gpt -o altroot=3D/z -o cachefile=3D/tmp/zpool.cac= he > zroot > > Copy the cache file (this fixes many boots that say "ZFS: i/o error - all > block copies unavailable", but I have not seen the "ZFS:unexcepted object > set type 0" error except with my hot spare, so might not work) > # cp /tmp/zpool.cache /z/boot/zfs/zpool.cache > > Then type: > # zpool status > > and take a camera shot, or send it on the network, etc. to paste it into > an email, so we can see it. > > eg. you could try sending it to another server: > > # zpool status > /tmp/status.txt > # scp /tmp/status.txt user@server:~/ > > Then install the bootloader again... if you don't remember how, this gues= s > might be wrong, but here is what I do on my system: > figure out what index the boot slice is: > # gpart show da0 > then in the following, replace the 1 with the index of your boot slic= e: > # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0 > # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da1 > (... for each boot disk) > > > Then reboot WITHOUT exporting the pool, and see if it is fixed. If not, > send your email with the status.txt. > > > On 05/04/2012 04:32 AM, suken woo wrote: > > Peter, in my situation, my zpool created under a RAID5 disk array control= ler mfid0 and without spare disk settings. Is't the disk fault issue?and ho= w to resolve? > > thanks > > >This happened to me when my root pool had an active hot spare. I later > >tested it on a virtual machine, and even with non-spare disks added, the > >system did the same thing. > > >Here is my PR: > >http://www.freebsd.org/cgi/query-pr.cgi?pr=3D167065 > > >kern/167065 > > >My solution was to boot on a DVD, and then "zpool detach" the bad disk > >(which converted the spare to a normal mirror). > > > >On 05/02/2012 02:03 PM, suken woo wrote: > > hi,lists > > for some reasons I need restart system but it suddenly boot failed t= oday. > > here is the error: > > ZFS: i/o error - all block copies unavailable > > ZFS: can't read object set for dataset 16 > > Can't find root filesystem - giving up > > ZFS:unexcepted object set type 0 > > ZFS:unexcepted object set type 0 > > > > FreeBSD/i386 boot > > Default: zroot:/boot/kernel/kernel > > boot: > > ZFS:unexcepted object set type0 > > > > FreeBSD/i386 boot > > Default: zroot:/boot/kernel/kernel > > boot: _ > > > > any ideas to resolved it? > > thanks in advance > > _______________________________________________ > > 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 " > > > -- > > -------------------------------------------- > Peter Maloney > Brockmann Consult > Max-Planck-Str. 2 > 21502 Geesthacht > Germany > Tel: +49 4152 889 300 > Fax: +49 4152 889 333 > E-mail: peter.maloney@brockmann-consult.de > Internet: http://www.brockmann-consult.de > -------------------------------------------- > > > > -- > > -------------------------------------------- > Peter Maloney > Brockmann Consult > Max-Planck-Str. 2 > 21502 Geesthacht > Germany > Tel: +49 4152 889 300 > Fax: +49 4152 889 333 > E-mail: peter.maloney@brockmann-consult.de > Internet: http://www.brockmann-consult.de > -------------------------------------------- > > --=20 --wsk From owner-freebsd-fs@FreeBSD.ORG Fri May 4 15:06:00 2012 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 AE0DE10657C0; Fri, 4 May 2012 15:06:00 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8384F8FC08; Fri, 4 May 2012 15:06:00 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id EB599B93B; Fri, 4 May 2012 11:05:59 -0400 (EDT) From: John Baldwin To: freebsd-fs@freebsd.org, lev@freebsd.org Date: Fri, 4 May 2012 08:10:14 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <1144029025.20120503153317@serebryakov.spb.ru> In-Reply-To: <1144029025.20120503153317@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201205040810.14268.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 04 May 2012 11:06:00 -0400 (EDT) Cc: Subject: Re: Is here any plans to support effective (not write-all-blocks-as-from-userland) vop_allocate() for UFS 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, 04 May 2012 15:06:00 -0000 On Thursday, May 03, 2012 7:33:17 am Lev Serebryakov wrote: > Hello, Freebsd-fs. > > It seems to be very straightforward for UFS/FFS, isn't it? > I could try to do this, but only if nobody works on it right now. Go for it. I don't think anyone else is working on it currently. -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Fri May 4 15:35:00 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C70C71065672; Fri, 4 May 2012 15:35:00 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 92E898FC16; Fri, 4 May 2012 15:35:00 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id F138AB948; Fri, 4 May 2012 11:34:59 -0400 (EDT) From: John Baldwin To: Andriy Gapon Date: Fri, 4 May 2012 11:25:14 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <4F8999D2.1080902@FreeBSD.org> <4FA29E1B.7040005@FreeBSD.org> <4FA2A307.2090108@FreeBSD.org> In-Reply-To: <4FA2A307.2090108@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201205041125.15155.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 04 May 2012 11:35:00 -0400 (EDT) Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, Gavin Mu , Marius Strobl Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool 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, 04 May 2012 15:35:00 -0000 On Thursday, May 03, 2012 11:23:51 am Andriy Gapon wrote: > on 03/05/2012 18:02 Andriy Gapon said the following: > > > > Here's the latest version of the patches: > > http://people.freebsd.org/~avg/zfsboot.patches.4.diff > > I've found a couple of problems in the previous version, so here's another one: > http://people.freebsd.org/~avg/zfsboot.patches.5.diff > The important change is in the first patch (__exec args). A few comments/suggestions on the args bits: - Please move the type of the 'kargs' struct into the new header and give it a type name. Don't add the LOADER_ZFS_SUPPORT #ifdef's however or the new size field (see below). - Add #ifndef LOCORE guards to the new header around the structure so it can be used in assembly as well as C. - Move BI_SIZE and ARGOFF into the header as constants. - Add a CTASSERT() in loader/main.c that BI_SIZE == sizeof(struct bootinfo) - Add a KA_SIZE for sizeof(struct kargs) with a CTASSERT. Use it in this instruction: + addl 0x1c(%esp),%ecx # Add size of variable args in place of the 0x1c - Don't add the new 'size' field to the end of the 'struct kargs'. Instead add a comment saying that if KARGS_FLAGS_EXT is set, then a structure will be present at (kargs + 1) that has a int size as its first member. Maybe create a 'struct kargs_ext' that looks like this: struct kargs_ext { uint32_t size; char data[0]; }; - Use 'zargs = (struct zfs_boot_args)(kargs + 1)' in loader/main.c. - Change the ARGADJ line in btxcsu to be this: .set ARGADJ,0x1000 - ARGOFF - If you are adventurous, you could even add a new constant ARGSPACE or some such with an appropriate comment in the new header that you use to replace the 0x1000 in btx.S and in the definition of ARGADJ. Hope that isn't too much, but I do think this will help make things even more understandable. -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Fri May 4 17:28:04 2012 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 583DB106564A; Fri, 4 May 2012 17:28:04 +0000 (UTC) (envelope-from etnapierala@googlemail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id A6FDB8FC17; Fri, 4 May 2012 17:28:03 +0000 (UTC) Received: by wgbds12 with SMTP id ds12so2921755wgb.31 for ; Fri, 04 May 2012 10:28:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=I5Fhz4ONvk2E6gF2SoTd2B9ltQDT34UFJe0LESBoVf0=; b=ZicwgjiQ8RSR1YEaRFfDasqzAL8DOISTcvm3LYthGj3Xoe0i7jqPU7uauaMC0WT4Ap lFclQsszaguGi1oR3/hapCaq/L00blDZTcuMtnh19uNMdbd5qk5jjWNOVMBwTYy/H0c0 I3eyhDVcabvRj0fN7tBv304e7ai0D4aM+29QzGpMjD8uEbvzWn1tgKoGMXCo4b5sNhvs uKK7e9R+XU4t0lREinc8dDC9KKLH4uVVbquanRrLtj843RW+ryhHdiRAP5wYgT6mYoxm yRlb19Ns4WuNHjlGw5m2bSoLxqCNUFnH7VQM1UKf2IRjKMYAKDcRiYFvg1geBDkdDJKC Nsww== Received: by 10.180.83.38 with SMTP id n6mr14937252wiy.4.1336152482527; Fri, 04 May 2012 10:28:02 -0700 (PDT) Received: from apn-95-41-156-159.dynamic.gprs.plus.pl (apn-95-41-156-159.dynamic.gprs.plus.pl. [95.41.156.159]) by mx.google.com with ESMTPS id gd4sm17052840wib.6.2012.05.04.10.27.56 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 May 2012 10:28:00 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-2 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <4F78C33D.7080708@FreeBSD.org> Date: Fri, 4 May 2012 12:21:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <429AC809-E1CE-4107-8FF2-19FD3C7D58BF@FreeBSD.org> References: <4F78C33D.7080708@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1257) Cc: freebsd-fs@FreeBSD.org Subject: Re: ls NFSv4 is not perfect 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, 04 May 2012 17:28:04 -0000 Wiadomo=B6=E6 napisana przez Andriy Gapon w dniu 1 kwi 2012, o godz. = 23:06: > It seems that aclmode() function in bin/ls/print.c caches ACL support = properties > of a filesystem. Unfortunately this optimization doesn't always work. > An example: a UFS directory unionfs-mounted over ZFS directory. Files = that > reside in ZFS and are not shadowed by UFS do have ACL_NFS4 stuff, = files in UFS > don't have it. > An example of ls -l behavior in this case: > -rw-r--r-- 1 mrtg mrtg 3881 1 Apr 06:55 corevoltages-year.png > -rw-r--r-- 1 mrtg mrtg 5605 1 Apr 06:55 userload-year.png > -rw-r--r-- 1 mrtg mrtg 2782 1 Apr 06:55 uptime-year.png > ls: /var/www/stats/mrtg/cpufreq.old: Operation not supported > -rw-r--r-- 1 mrtg mrtg 61200 1 Apr 23:00 cpufreq.old > ls: /var/www/stats/mrtg/irqrate.old: Operation not supported > -rw-r--r-- 1 mrtg mrtg 55538 1 Apr 23:00 irqrate.old > ls: /var/www/stats/mrtg/cpuload.old: Operation not supported > -rw-r--r-- 1 mrtg mrtg 58826 1 Apr 23:00 cpuload.old > ls: /var/www/stats/mrtg/cpuload2.old: Operation not supported >=20 > The older files are in ZFS, the newer are in UFS. > ktrace, just in case: > CALL __acl_get_link(0x7fffffffc180,ACL_TYPE_NFS4,0x801186000) > NAMI "/var/www/stats/mrtg/uptime.html" > RET __acl_get_link 0 > CALL write(0x1,0x8010be000,0x3b) > ... > CALL __acl_get_link(0x7fffffffc180,ACL_TYPE_NFS4,0x801186000) > NAMI "/var/www/stats/mrtg/xxx" > RET __acl_get_link -1 errno 45 Operation not supported >=20 > Not sure what's the best approach here. > Maybe just silence this particular error code? Situation is more complicated than that - there is an optimization in ls(1) that makes it assume that a given filesystem supports only one ACL brand, either POSIX.1e or NFS4, and it's determined using the first file ls(1) will find. So, in situation above, you'll get POSIX ACLs for some files and ENOTSUPP for others, _or_ ENOTSUPP for some files and NFS4 ACLs for others, depending on sorting order. Same assumption is found in several other tools, such as cp(1). I think we should leave it as it is - this ENOTSUPP _is_ an error; silencing it would result in ls(1) indicating different permissions that are actually being enforced. --=20 If you cut off my head, what would I say? Me and my head, or me and my = body? From owner-freebsd-fs@FreeBSD.ORG Fri May 4 19:43:03 2012 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 51D32106564A; Fri, 4 May 2012 19:43:03 +0000 (UTC) (envelope-from merlyn@stonehenge.com) Received: from gw17.lax01.mailroute.net (lax-gw17.mailroute.net [199.89.0.117]) by mx1.freebsd.org (Postfix) with ESMTP id 2E32F8FC0C; Fri, 4 May 2012 19:43:03 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by gw17.lax01.mailroute.net (Postfix) with ESMTP id B8D3566608C; Fri, 4 May 2012 19:34:47 +0000 (GMT) X-Virus-Scanned: by MailRoute Received: from gw17.lax01.mailroute.net ([199.89.0.117]) by localhost (gw17.lax01.mailroute.net.mailroute.net [127.0.0.1]) (mroute_mailscanner, port 10026) with LMTP id 5OHUo9zEXZpN; Fri, 4 May 2012 19:34:45 +0000 (GMT) Received: from red.stonehenge.com (red.stonehenge.com [208.79.95.2]) by gw17.lax01.mailroute.net (Postfix) with ESMTP id DEE21666515; Fri, 4 May 2012 19:34:45 +0000 (GMT) Received: by red.stonehenge.com (Postfix, from userid 1001) id DA4692B78; Fri, 4 May 2012 12:34:45 -0700 (PDT) From: merlyn@stonehenge.com (Randal L. Schwartz) To: vermaden References: x-mayan-date: Long count = 12.19.19.6.9; tzolkin = 7 Muluc; haab = 12 Uo Date: Fri, 04 May 2012 12:34:45 -0700 In-Reply-To: (vermaden@interia.pl's message of "Fri, 27 Apr 2012 01:08:33 +0200 (CEST)") Message-ID: <86ipgbg2p6.fsf@red.stonehenge.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-fs@FreeBSD.org, freebsd-questions@freebsd.org Subject: Re: HOWTO: FreeBSD ZFS Madness (Boot Environments) 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, 04 May 2012 19:43:03 -0000 >>>>> "vermaden" == vermaden writes: vermaden> I have just created new HOWTO [1] on how to use Boot Environments on vermaden> FreeBSD with new created utility *beadm* that I put on vermaden> SourceForge [2]. I have zfs-on-root using the classical documentation (everything under zpool, possibly with some sub-mounts, but I've left those out lately). Is there a way to transition my system to a form that beadm expects? I tried just running it, and it's upset that zpool/ROOT doesn't exist. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion From owner-freebsd-fs@FreeBSD.ORG Fri May 4 21:37:02 2012 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 AD6A3106566C; Fri, 4 May 2012 21:37:02 +0000 (UTC) (envelope-from vermaden@interia.pl) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.208]) by mx1.freebsd.org (Postfix) with ESMTP id 64FDE8FC0C; Fri, 4 May 2012 21:37:02 +0000 (UTC) Date: Fri, 04 May 2012 23:37:01 +0200 From: vermaden To: "Randal L. Schwartz" X-Mailer: interia.pl/pf09 In-Reply-To: <86ipgbg2p6.fsf@red.stonehenge.com> References: <86ipgbg2p6.fsf@red.stonehenge.com> Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1336167421; bh=/rcYKFSJMbRw2x6L3CccyMg3xtW4VA4Yv1y95HhrWpQ=; h=Date:From:Subject:To:Cc:X-Mailer:In-Reply-To:References: Message-Id:MIME-Version:Content-Type:Content-Transfer-Encoding; b=F3nWlAaKeSAJwYDGGanCPCfpaDYJwBkGr22ajDI9wkgVel6sjJyTgUQieEevIZMAm 9taNdRoxc/6MmAqcpcHoqX6aIrV5XRr5/Uf/CkwHP4JFfbol+ZJmK1/k+p4BITobqr 2Se5Dreh2PHCAbJetMqH+xQorr/cNvOj3ENK7rEQ= Cc: freebsd-fs@FreeBSD.org, freebsd-questions@freebsd.org Subject: Re: HOWTO: FreeBSD ZFS Madness (Boot Environments) 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, 04 May 2012 21:37:02 -0000 > I have zfs-on-root using the classical documentation (everything under > zpool, possibly with some sub-mounts, but I've left those out lately). >=20 > Is there a way to transition my system to a form that beadm expects? > I tried just running it, and it's upset that zpool/ROOT doesn't exist. Hi, I would suggest using something like that: # zfs create -o mountpoint=3Dnone zpool/ROOT # zfs snapshot zpool@be # zfs clone zpool@be zpool/ROOT/default # fetch https://github.com/vermaden/beadm/blob/master/beadm # chmod +x beadm # ./beadm list # ./beadm activate default # reboot Be sure to use the latest *beadm* from one of these: https://raw.github.com/vermaden/beadm/master/beadm https://sourceforge.net/projects/beadm/ Let me know how these instructions work, especially if You got any errors o= r an unbootable system. It would be best if You would test this zpool root to sys/ROOT/be transitio= n under VirtualBox for 100% safety ;) Regards, vermaden --=20 ... From owner-freebsd-fs@FreeBSD.ORG Fri May 4 22:02:03 2012 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 3A917106564A; Fri, 4 May 2012 22:02:03 +0000 (UTC) (envelope-from merlyn@stonehenge.com) Received: from gw16.lax01.mailroute.net (lax-gw16.mailroute.net [199.89.0.116]) by mx1.freebsd.org (Postfix) with ESMTP id 19AC48FC1A; Fri, 4 May 2012 22:02:03 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by gw16.lax01.mailroute.net (Postfix) with ESMTP id F1FE55BC325; Fri, 4 May 2012 21:57:42 +0000 (GMT) X-Virus-Scanned: by MailRoute Received: from gw16.lax01.mailroute.net ([199.89.0.116]) by localhost (gw16.lax01.mailroute.net.mailroute.net [127.0.0.1]) (mroute_mailscanner, port 10026) with LMTP id 33wcWSFHg_Wp; Fri, 4 May 2012 21:57:41 +0000 (GMT) Received: from red.stonehenge.com (red.stonehenge.com [208.79.95.2]) by gw16.lax01.mailroute.net (Postfix) with ESMTP id CEA235BC2FB; Fri, 4 May 2012 21:57:41 +0000 (GMT) Received: by red.stonehenge.com (Postfix, from userid 1001) id BB06D218E; Fri, 4 May 2012 14:57:41 -0700 (PDT) From: merlyn@stonehenge.com (Randal L. Schwartz) To: vermaden References: <86ipgbg2p6.fsf@red.stonehenge.com> x-mayan-date: Long count = 12.19.19.6.9; tzolkin = 7 Muluc; haab = 12 Uo Date: Fri, 04 May 2012 14:57:41 -0700 In-Reply-To: (vermaden@interia.pl's message of "Fri, 04 May 2012 23:37:01 +0200") Message-ID: <86d36jzk16.fsf@red.stonehenge.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-fs@FreeBSD.org, freebsd-questions@freebsd.org Subject: Re: HOWTO: FreeBSD ZFS Madness (Boot Environments) 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, 04 May 2012 22:02:03 -0000 >>>>> "vermaden" == vermaden writes: vermaden> # fetch https://github.com/vermaden/beadm/blob/master/beadm Heh. That's HTML. I think you want fetch https://raw.github.com/vermaden/beadm/master/beadm vermaden> # chmod +x beadm vermaden> # ./beadm list vermaden> # ./beadm activate default vermaden> # reboot vermaden> Be sure to use the latest *beadm* from one of these: vermaden> https://raw.github.com/vermaden/beadm/master/beadm vermaden> https://sourceforge.net/projects/beadm/ vermaden> Let me know how these instructions work, especially if You got vermaden> any errors or an unbootable system. Oh, that worked perfectly, except for an error message during the create. and after reboot, "zfs set mountpoint=none zroot" would also seem to clean that up. vermaden> It would be best if You would test this zpool root to sys/ROOT/be transition under VirtualBox for 100% safety ;) vermaden> Regards, vermaden> vermaden vermaden> -- vermaden> ... vermaden> _______________________________________________ vermaden> freebsd-questions@freebsd.org mailing list vermaden> http://lists.freebsd.org/mailman/listinfo/freebsd-questions vermaden> To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion From owner-freebsd-fs@FreeBSD.ORG Fri May 4 22:07:05 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 402CF106566C; Fri, 4 May 2012 22:07:05 +0000 (UTC) (envelope-from merlyn@stonehenge.com) Received: from gw15.lax01.mailroute.net (lax-gw15.mailroute.net [199.89.0.115]) by mx1.freebsd.org (Postfix) with ESMTP id 1D9F18FC1B; Fri, 4 May 2012 22:07:04 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by gw15.lax01.mailroute.net (Postfix) with ESMTP id D7B3FE3639A; Fri, 4 May 2012 22:00:37 +0000 (GMT) X-Virus-Scanned: by MailRoute Received: from gw15.lax01.mailroute.net ([199.89.0.115]) by localhost (gw15.lax01.mailroute.net.mailroute.net [127.0.0.1]) (mroute_mailscanner, port 10026) with LMTP id AHoKguArczOA; Fri, 4 May 2012 22:00:36 +0000 (GMT) Received: from red.stonehenge.com (red.stonehenge.com [208.79.95.2]) by gw15.lax01.mailroute.net (Postfix) with ESMTP id D1D35E3639C; Fri, 4 May 2012 22:00:36 +0000 (GMT) Received: by red.stonehenge.com (Postfix, from userid 1001) id 97B832193; Fri, 4 May 2012 15:00:35 -0700 (PDT) From: merlyn@stonehenge.com (Randal L. Schwartz) To: vermaden References: <86ipgbg2p6.fsf@red.stonehenge.com> <86d36jzk16.fsf@red.stonehenge.com> x-mayan-date: Long count = 12.19.19.6.9; tzolkin = 7 Muluc; haab = 12 Uo Date: Fri, 04 May 2012 15:00:35 -0700 In-Reply-To: <86d36jzk16.fsf@red.stonehenge.com> (Randal L. Schwartz's message of "Fri, 04 May 2012 14:57:41 -0700") Message-ID: <867gwrzjwc.fsf@red.stonehenge.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-fs@FreeBSD.org, freebsd-questions@freebsd.org Subject: Re: HOWTO: FreeBSD ZFS Madness (Boot Environments) 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, 04 May 2012 22:07:05 -0000 >>>>> "Randal" == Randal L Schwartz writes: >>>>> "vermaden" == vermaden writes: vermaden> # fetch https://github.com/vermaden/beadm/blob/master/beadm Randal> and after reboot, "zfs set mountpoint=none zroot" would also seem to Randal> clean that up. Oh wait, it looks like zroot is still holding 1.04G of data... will that ever go away? Shouldn't all the data be in the /ROOT/xxx items? -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion From owner-freebsd-fs@FreeBSD.ORG Fri May 4 22:10:10 2012 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 AA7CC106567A; Fri, 4 May 2012 22:10:10 +0000 (UTC) (envelope-from merlyn@stonehenge.com) Received: from gw17.lax01.mailroute.net (lax-gw17.mailroute.net [199.89.0.117]) by mx1.freebsd.org (Postfix) with ESMTP id 87CF98FC17; Fri, 4 May 2012 22:10:10 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by gw17.lax01.mailroute.net (Postfix) with ESMTP id 425BF666684; Fri, 4 May 2012 22:10:08 +0000 (GMT) X-Virus-Scanned: by MailRoute Received: from gw17.lax01.mailroute.net ([199.89.0.117]) by localhost (gw17.lax01.mailroute.net.mailroute.net [127.0.0.1]) (mroute_mailscanner, port 10026) with LMTP id BRqkHKPFBkhv; Fri, 4 May 2012 22:10:06 +0000 (GMT) Received: from red.stonehenge.com (red.stonehenge.com [208.79.95.2]) by gw17.lax01.mailroute.net (Postfix) with ESMTP id BADEF6665C9; Fri, 4 May 2012 22:10:06 +0000 (GMT) Received: by red.stonehenge.com (Postfix, from userid 1001) id 91C1721A9; Fri, 4 May 2012 15:10:05 -0700 (PDT) From: merlyn@stonehenge.com (Randal L. Schwartz) To: vermaden References: <86ipgbg2p6.fsf@red.stonehenge.com> <86d36jzk16.fsf@red.stonehenge.com> <867gwrzjwc.fsf@red.stonehenge.com> x-mayan-date: Long count = 12.19.19.6.9; tzolkin = 7 Muluc; haab = 12 Uo Date: Fri, 04 May 2012 15:10:05 -0700 In-Reply-To: <867gwrzjwc.fsf@red.stonehenge.com> (Randal L. Schwartz's message of "Fri, 04 May 2012 15:00:35 -0700") Message-ID: <86397fzjgi.fsf@red.stonehenge.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-fs@FreeBSD.org, freebsd-questions@freebsd.org Subject: Re: HOWTO: FreeBSD ZFS Madness (Boot Environments) 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, 04 May 2012 22:10:10 -0000 >>>>> "Randal" == Randal L Schwartz writes: Randal> Oh wait, it looks like zroot is still holding 1.04G of data... will Randal> that ever go away? Shouldn't all the data be in the /ROOT/xxx Randal> items? And worse, the things from the readme don't work: locohost# ./beadm create upgrade cannot create 'zroot/ROOT/upgrade': invalid property '' cannot open 'zroot/ROOT/upgrade': dataset does not exist Created successfully So, no joy on this yet. This is FreeBSD 8.2. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion From owner-freebsd-fs@FreeBSD.ORG Fri May 4 22:25:01 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0B33D1065674; Fri, 4 May 2012 22:25:01 +0000 (UTC) (envelope-from merlyn@stonehenge.com) Received: from gw16.lax01.mailroute.net (lax-gw16.mailroute.net [199.89.0.116]) by mx1.freebsd.org (Postfix) with ESMTP id D93BE8FC08; Fri, 4 May 2012 22:25:00 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by gw16.lax01.mailroute.net (Postfix) with ESMTP id B558E5BC317; Fri, 4 May 2012 22:25:00 +0000 (GMT) X-Virus-Scanned: by MailRoute Received: from gw16.lax01.mailroute.net ([199.89.0.116]) by localhost (gw16.lax01.mailroute.net.mailroute.net [127.0.0.1]) (mroute_mailscanner, port 10026) with LMTP id iGEpolCKZ-1S; Fri, 4 May 2012 22:24:59 +0000 (GMT) Received: from red.stonehenge.com (red.stonehenge.com [208.79.95.2]) by gw16.lax01.mailroute.net (Postfix) with ESMTP id B80885BC254; Fri, 4 May 2012 22:24:59 +0000 (GMT) Received: by red.stonehenge.com (Postfix, from userid 1001) id B222E21DF; Fri, 4 May 2012 15:24:59 -0700 (PDT) From: merlyn@stonehenge.com (Randal L. Schwartz) To: vermaden References: <86ipgbg2p6.fsf@red.stonehenge.com> <86d36jzk16.fsf@red.stonehenge.com> <867gwrzjwc.fsf@red.stonehenge.com> <86397fzjgi.fsf@red.stonehenge.com> x-mayan-date: Long count = 12.19.19.6.9; tzolkin = 7 Muluc; haab = 12 Uo Date: Fri, 04 May 2012 15:24:59 -0700 In-Reply-To: <86397fzjgi.fsf@red.stonehenge.com> (Randal L. Schwartz's message of "Fri, 04 May 2012 15:10:05 -0700") Message-ID: <86y5p7y478.fsf@red.stonehenge.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-fs@FreeBSD.org, freebsd-questions@freebsd.org Subject: Re: HOWTO: FreeBSD ZFS Madness (Boot Environments) 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, 04 May 2012 22:25:01 -0000 >>>>> "Randal" == Randal L Schwartz writes: Randal> This is FreeBSD 8.2. And no difference on 8.3 :( Should there have been a "promote" in there somewhere? It looks like the boot env is still dependent on the very old zroot. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion From owner-freebsd-fs@FreeBSD.ORG Fri May 4 23:40:47 2012 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 A91C91065672 for ; Fri, 4 May 2012 23:40:47 +0000 (UTC) (envelope-from bryan@shatow.net) Received: from secure.xzibition.com (secure.xzibition.com [173.160.118.92]) by mx1.freebsd.org (Postfix) with ESMTP id 4B7638FC12 for ; Fri, 4 May 2012 23:40:47 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sweb; b=pTo8fR QJmn0G0OckzJzNNrSDgx50l8QSOAihqPVip8NlVdCJdiLBeKX+7EgQ35I+4NXUhn QosW7BJpHEz+EztB7ioAXtmVbZkb44PRPlixEdZSIg2kZigMMHjdGOcezNTu3AXC NVEPajz3nlTXhuwFFbtZG7EXaiasHHD4ft1eE= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sweb; bh=HtRNMoIBZynV 0ESgW9J8XWViirbIUmwuz7ZoSHctMhU=; b=YMD55onfnFcdRKLbflTzRHj+7O8L +5B4cGBmHC4FzGA76EyvGxHlMtadZqkTVtOqSYwIRbssgVyqv2osCXjh/LpPQzdA I/93t5Nob9UjahaiFoctrryqZUnpiIt1NyK5bHhNEZbYO/ddhZ4KeeWGqbiPUijQ UgzqjVwnR6jwB3Q= Received: (qmail 52421 invoked from network); 4 May 2012 18:40:39 -0500 Received: from unknown (HELO ?10.10.1.87?) (bryan@shatow.net@10.10.1.87) by sweb.xzibition.com with ESMTPA; 4 May 2012 18:40:39 -0500 Message-ID: <4FA468F5.5020302@shatow.net> Date: Fri, 04 May 2012 18:40:37 -0500 From: Bryan Drewery User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Randal L. Schwartz" References: <86ipgbg2p6.fsf@red.stonehenge.com> <86d36jzk16.fsf@red.stonehenge.com> <867gwrzjwc.fsf@red.stonehenge.com> <86397fzjgi.fsf@red.stonehenge.com> In-Reply-To: <86397fzjgi.fsf@red.stonehenge.com> X-Enigmail-Version: 1.4.1 OpenPGP: id=3C9B0CF9; url=http://www.shatow.net/bryan/bryan.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, vermaden , freebsd-questions@freebsd.org Subject: Re: HOWTO: FreeBSD ZFS Madness (Boot Environments) 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, 04 May 2012 23:40:47 -0000 On 5/4/2012 5:10 PM, Randal L. Schwartz wrote: >>>>>> "Randal" == Randal L Schwartz writes: > > Randal> Oh wait, it looks like zroot is still holding 1.04G of data... will > Randal> that ever go away? Shouldn't all the data be in the /ROOT/xxx > Randal> items? > > And worse, the things from the readme don't work: > > locohost# ./beadm create upgrade > cannot create 'zroot/ROOT/upgrade': invalid property '' > cannot open 'zroot/ROOT/upgrade': dataset does not exist > Created successfully > > So, no joy on this yet. > > This is FreeBSD 8.2. > Hi, Those errors will be fixed in the next release, out in the next day or so. Still testing it. If you want to help test, it's out on vermaden's github right now. An updated port will be available soon as well. Regards, Bryan Drewery From owner-freebsd-fs@FreeBSD.ORG Sat May 5 06:19:19 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E91CE106564A; Sat, 5 May 2012 06:19:19 +0000 (UTC) (envelope-from vermaden@interia.pl) Received: from smtpo.poczta.interia.pl (smtpo.poczta.interia.pl [217.74.65.208]) by mx1.freebsd.org (Postfix) with ESMTP id 992E88FC0C; Sat, 5 May 2012 06:19:19 +0000 (UTC) Date: Sat, 05 May 2012 08:19:11 +0200 From: vermaden To: "Randal L. Schwartz" X-Mailer: interia.pl/pf09 In-Reply-To: <86y5p7y478.fsf@red.stonehenge.com> References: <86ipgbg2p6.fsf@red.stonehenge.com> <86d36jzk16.fsf@red.stonehenge.com> <867gwrzjwc.fsf@red.stonehenge.com> <86397fzjgi.fsf@red.stonehenge.com> <86y5p7y478.fsf@red.stonehenge.com> Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interia.pl; s=biztos; t=1336198752; bh=ELWlNuaKv6qUCefZMYhpd+3kaDYMW+4fuFIxYHPNiuI=; h=Date:From:Subject:To:Cc:X-Mailer:In-Reply-To:References: Message-Id:MIME-Version:Content-Type:Content-Transfer-Encoding; b=KYkkF0Y4PMIMK9cxSUonc9dwZy2XW7zhb2+JNZRzTJPZDHwKt8vbzVtWOeCq/VDjG Q24ylYfzmrIIDubW3OSj9DP3VrjS4ILugsi7D/84hEL3NjTl9OmyWBqyzqJ1e/3kPJ ncILyzoqK813fjNbs0YoPJsv/yh1TVUPfD/LkXHY= Cc: freebsd-fs@FreeBSD.org, freebsd-questions@freebsd.org Subject: Re: HOWTO: FreeBSD ZFS Madness (Boot Environments) 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, 05 May 2012 06:19:20 -0000 > And no difference on 8.3 :( >=20 > Should there have been a "promote" in there somewhere? It looks like > the boot env is still dependent on the very old zroot. Hi, I have just recreated from scratch Your zroot root setup under VirtualBox and tested it deeply. There was an interesting BUG in the *beadm* utility, or maybe it is a BUG in sh(1), I do not have that good knowledge of POSIX/sh(1) standards. To the point, check these two code snippets, they should do EXACLY the same, logic is the same, the differece is only the syntax. snippet 1: [ ${MOUNT} -eq 0 ] && { zfs set mountpoint=3D${TMPMNT} ${POOL}/ROOT/${2} zfs mount ${POOL}/ROOT/${2} } || { TMPMNT=3D${MOUNT} } snippet 2: if [ ${MOUNT} -eq 0 ]; then zfs set mountpoint=3D${TMPMNT} ${POOL}/ROOT/${2} zfs mount ${POOL}/ROOT/${2} else TMPMNT=3D${MOUNT} fi But unfortunately, it comes out that its not the same ... [ ${MOUNT} -eq 0 ] && { zfs set mountpoint=3D${TMPMNT} ${POOL}/ROOT/${2} zfs mount ${POOL}/ROOT/${2} # IF THIS LINE ABOVE FAILS (NOT RETURN 0) THEN # TMPMNT=3D${MOUNT} BELOW WILL BE EXECUTED } || { TMPMNT=3D${MOUNT} } The sollution can be put command that will always work (return 0 on exit) like that: [ ${MOUNT} -eq 0 ] && { zfs set mountpoint=3D${TMPMNT} ${POOL}/ROOT/${2} zfs mount ${POOL}/ROOT/${2} echo 1> /dev/null 2> /dev/null } || { TMPMNT=3D${MOUNT} } ... or to rewrite it under if/then/else which I did for the whole *beadm* utility and I no longer use || and && syntax, anywhere. As for Your problems, this worked for me on this VirtualBox test environment. # zfs promote zroot # zfs rollback zpool@be # zfs set mountpoint=3D/mnt zroot [ set vfs.root.mountfrom=3D"zfs:zroot" in /mnt/boot/loader.conf ] # zpool set bootfs=3Dzroot zroot # zfs set mountpoint=3Dnone zroot # reboot These above should bring back to the start point before You entered my instructions to try *beadm* and BEs. After reboot ... # zfs destroy -R zroot/ROOT # zfs create -o mountpoint=3Dnone zroot/ROOT # zfs send zpool@be | zfs recv zroot/ROOT/be # fetch https://raw.github.com/vermaden/beadm/master/beadm # chmod +x beadm # ./beadm list # ./beadm activate be # reboot Now You should have a working system with boot environments. Both GitHub and SourceForce have the latest fixed *beadm* version. Regards, vermaden --=20 ... From owner-freebsd-fs@FreeBSD.ORG Sat May 5 09:31:27 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A4D66106566B; Sat, 5 May 2012 09:31:27 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 8665E8FC0A; Sat, 5 May 2012 09:31:26 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA18068; Sat, 05 May 2012 12:31:25 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SQbKm-000A2o-J0; Sat, 05 May 2012 12:31:24 +0300 Message-ID: <4FA4F36A.6030903@FreeBSD.org> Date: Sat, 05 May 2012 12:31:22 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120425 Thunderbird/12.0 MIME-Version: 1.0 To: John Baldwin References: <4F8999D2.1080902@FreeBSD.org> <4FA29E1B.7040005@FreeBSD.org> <4FA2A307.2090108@FreeBSD.org> <201205041125.15155.jhb@freebsd.org> In-Reply-To: <201205041125.15155.jhb@freebsd.org> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool 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, 05 May 2012 09:31:27 -0000 on 04/05/2012 18:25 John Baldwin said the following: > On Thursday, May 03, 2012 11:23:51 am Andriy Gapon wrote: >> on 03/05/2012 18:02 Andriy Gapon said the following: >>> >>> Here's the latest version of the patches: >>> http://people.freebsd.org/~avg/zfsboot.patches.4.diff >> >> I've found a couple of problems in the previous version, so here's another one: >> http://people.freebsd.org/~avg/zfsboot.patches.5.diff >> The important change is in the first patch (__exec args). > > A few comments/suggestions on the args bits: John, these are excellent suggestions! Thank you! Some comments: > - Please move the type of the 'kargs' struct into the new header and > give it a type name. Don't add the LOADER_ZFS_SUPPORT #ifdef's > however or the new size field (see below). Done. I've named the header and the struct "bootargs". > - Add #ifndef LOCORE guards to the new header around the structure so > it can be used in assembly as well as C. Done. I have had to go into a few btx makefiles and add a necessary include path and -DLOCORE to make the header usable from asm. > - Move BI_SIZE and ARGOFF into the header as constants. Done. > - Add a CTASSERT() in loader/main.c that BI_SIZE == sizeof(struct bootinfo) I have added a definition of CTASSERT to boostrap.h as it was not available for sys/boot and there were two local definitions of the macro in individual files. However the assertion would fail right now. The backward-compatible value of BI_SIZE (72 == 0x48) covers only part of the fields in struct bootinfo, those up to the following comment: /* Items below only from advanced bootloader */ I am a little bit hesitant: should I increase BI_SIZE to cover the whole struct bootinfo or should I compare BI_SIZE to offsetof bi_kernend? > - Add a KA_SIZE for sizeof(struct kargs) with a CTASSERT. Use it in this > instruction: Done. > + addl 0x1c(%esp),%ecx # Add size of variable args > > in place of the 0x1c Done. Plus some more. > - Don't add the new 'size' field to the end of the 'struct kargs'. Instead > add a comment saying that if KARGS_FLAGS_EXT is set, then a structure will > be present at (kargs + 1) that has a int size as its first member. Done. > Maybe > create a 'struct kargs_ext' that looks like this: > > struct kargs_ext { > uint32_t size; > char data[0]; > }; I've decided to skip on this. > - Use 'zargs = (struct zfs_boot_args)(kargs + 1)' in loader/main.c. > - Change the ARGADJ line in btxcsu to be this: > > .set ARGADJ,0x1000 - ARGOFF I've decided to define ARGADJ in the new common header, then I've had to rename btxcsu.s to .S, so that the preprocessing is executed for it. > - If you are adventurous, you could even add a new constant ARGSPACE or some > such with an appropriate comment in the new header that you use to replace > the 0x1000 in btx.S and in the definition of ARGADJ. Done. > Hope that isn't too much, but I do think this will help make things even more > understandable. > I will send the new patch shortly. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Sat May 5 09:53:11 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 03D14106564A; Sat, 5 May 2012 09:53:11 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id DC7258FC18; Sat, 5 May 2012 09:53:09 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA18187; Sat, 05 May 2012 12:53:08 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SQbfo-000A3q-B1; Sat, 05 May 2012 12:53:08 +0300 Message-ID: <4FA4F883.2060008@FreeBSD.org> Date: Sat, 05 May 2012 12:53:07 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120425 Thunderbird/12.0 MIME-Version: 1.0 To: John Baldwin References: <4F8999D2.1080902@FreeBSD.org> <4FA29E1B.7040005@FreeBSD.org> <4FA2A307.2090108@FreeBSD.org> <201205041125.15155.jhb@freebsd.org> <4FA4F36A.6030903@FreeBSD.org> In-Reply-To: <4FA4F36A.6030903@FreeBSD.org> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool 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, 05 May 2012 09:53:11 -0000 on 05/05/2012 12:31 Andriy Gapon said the following: > on 04/05/2012 18:25 John Baldwin said the following: >> On Thursday, May 03, 2012 11:23:51 am Andriy Gapon wrote: >>> on 03/05/2012 18:02 Andriy Gapon said the following: >>>> >>>> Here's the latest version of the patches: >>>> http://people.freebsd.org/~avg/zfsboot.patches.4.diff >>> >>> I've found a couple of problems in the previous version, so here's another one: >>> http://people.freebsd.org/~avg/zfsboot.patches.5.diff >>> The important change is in the first patch (__exec args). >> >> A few comments/suggestions on the args bits: > > John, > > these are excellent suggestions! Thank you! The new patchset: http://people.freebsd.org/~avg/zfsboot.patches.7.diff > Some comments: > >> - Please move the type of the 'kargs' struct into the new header and >> give it a type name. Don't add the LOADER_ZFS_SUPPORT #ifdef's >> however or the new size field (see below). > > Done. I've named the header and the struct "bootargs". > >> - Add #ifndef LOCORE guards to the new header around the structure so >> it can be used in assembly as well as C. > > Done. I have had to go into a few btx makefiles and add a necessary include > path and -DLOCORE to make the header usable from asm. > >> - Move BI_SIZE and ARGOFF into the header as constants. > > Done. > >> - Add a CTASSERT() in loader/main.c that BI_SIZE == sizeof(struct bootinfo) > > I have added a definition of CTASSERT to boostrap.h as it was not available for > sys/boot and there were two local definitions of the macro in individual files. > > However the assertion would fail right now. > The backward-compatible value of BI_SIZE (72 == 0x48) covers only part of the > fields in struct bootinfo, those up to the following comment: > /* Items below only from advanced bootloader */ > > I am a little bit hesitant: should I increase BI_SIZE to cover the whole struct > bootinfo or should I compare BI_SIZE to offsetof bi_kernend? > >> - Add a KA_SIZE for sizeof(struct kargs) with a CTASSERT. Use it in this >> instruction: > > Done. > >> + addl 0x1c(%esp),%ecx # Add size of variable args >> >> in place of the 0x1c > > Done. Plus some more. > >> - Don't add the new 'size' field to the end of the 'struct kargs'. Instead >> add a comment saying that if KARGS_FLAGS_EXT is set, then a structure will >> be present at (kargs + 1) that has a int size as its first member. > > Done. > >> Maybe >> create a 'struct kargs_ext' that looks like this: >> >> struct kargs_ext { >> uint32_t size; >> char data[0]; >> }; > > I've decided to skip on this. > >> - Use 'zargs = (struct zfs_boot_args)(kargs + 1)' in loader/main.c. >> - Change the ARGADJ line in btxcsu to be this: >> >> .set ARGADJ,0x1000 - ARGOFF > > I've decided to define ARGADJ in the new common header, then I've had to rename > btxcsu.s to .S, so that the preprocessing is executed for it. > >> - If you are adventurous, you could even add a new constant ARGSPACE or some >> such with an appropriate comment in the new header that you use to replace >> the 0x1000 in btx.S and in the definition of ARGADJ. > > Done. > >> Hope that isn't too much, but I do think this will help make things even more >> understandable. >> > > I will send the new patch shortly. > -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Sat May 5 10:49:54 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 14CA71065673; Sat, 5 May 2012 10:49:54 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail06.syd.optusnet.com.au (mail06.syd.optusnet.com.au [211.29.132.187]) by mx1.freebsd.org (Postfix) with ESMTP id 2825F8FC0A; Sat, 5 May 2012 10:49:52 +0000 (UTC) Received: from c122-106-171-232.carlnfd1.nsw.optusnet.com.au (c122-106-171-232.carlnfd1.nsw.optusnet.com.au [122.106.171.232]) by mail06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q45Anl8v023129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 May 2012 20:49:49 +1000 Date: Sat, 5 May 2012 20:49:47 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Andriy Gapon In-Reply-To: <4FA4F36A.6030903@FreeBSD.org> Message-ID: <20120505194459.D1295@besplex.bde.org> References: <4F8999D2.1080902@FreeBSD.org> <4FA29E1B.7040005@FreeBSD.org> <4FA2A307.2090108@FreeBSD.org> <201205041125.15155.jhb@freebsd.org> <4FA4F36A.6030903@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: [review request] zfsboot/zfsloader: support accessing filesystems within a pool 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, 05 May 2012 10:49:54 -0000 On Sat, 5 May 2012, Andriy Gapon wrote: > on 04/05/2012 18:25 John Baldwin said the following: >> On Thursday, May 03, 2012 11:23:51 am Andriy Gapon wrote: >>> on 03/05/2012 18:02 Andriy Gapon said the following: >>>> >>>> Here's the latest version of the patches: >>>> http://people.freebsd.org/~avg/zfsboot.patches.4.diff >>> >>> I've found a couple of problems in the previous version, so here's another one: >>> http://people.freebsd.org/~avg/zfsboot.patches.5.diff >>> The important change is in the first patch (__exec args). >> >> A few comments/suggestions on the args bits: > > John, > > these are excellent suggestions! Thank you! > Some comments: >> - Add #ifndef LOCORE guards to the new header around the structure so >> it can be used in assembly as well as C. > > Done. I have had to go into a few btx makefiles and add a necessary include > path and -DLOCORE to make the header usable from asm. Ugh, why not use genassym, as is done for all old uses of this header in locore.s, at least on i386 (5% of the i386 genassym.c is for this). >> - Move BI_SIZE and ARGOFF into the header as constants. > > Done. > >> - Add a CTASSERT() in loader/main.c that BI_SIZE == sizeof(struct bootinfo) Ugh, BI_SIZE was already used in locore.s. It wasn't the size of the struct, but was the offset of the field that gives the size. No CTASSERT() was needed -- the size is whatever it is, as given by sizeof() on the struct at the time of compilation of the utility that initializes the struct. It was a feature that sizeof() and offsetof() can't be used in asm so they must be translated in genassym and no macros are needed in the header (the size was fully dynamic, so the asm code only needs the offsetof() values). Of course, you could use CTASSERT()s to check that the struct layout didn't get broken. The old code just assumes that the struct is packed by the programmer and that the arch's struct packing conventions don't change, so that for example BI_SIZE = offsetof(struct bootinfo, bi_size) never changes. genassym is hard to use in boot programs, but the old design was that boot programs shouldn't use bootinfo in asm and should just use the target bootinfo.h at compile time (whatever time the target is compiled). Anyway, LOCORE means "for use in locore.[sS]", so other uses of it, e.g. in boot programs, are bogus. > > I have added a definition of CTASSERT to boostrap.h as it was not available for > sys/boot and there were two local definitions of the macro in individual files. > > However the assertion would fail right now. > The backward-compatible value of BI_SIZE (72 == 0x48) covers only part of the This isn't backwards compatible. BI_SIZE was decimal 48 (covers everything up to the bi_size field). > fields in struct bootinfo, those up to the following comment: > /* Items below only from advanced bootloader */ > I am a little bit hesitant: should I increase BI_SIZE to cover the whole struct > bootinfo or should I compare BI_SIZE to offsetof bi_kernend? Neither. BI_SIZE shouldn't exist. It defeats the bi_size field. >> Maybe >> create a 'struct kargs_ext' that looks like this: >> >> struct kargs_ext { >> uint32_t size; >> char data[0]; >> }; > > I've decided to skip on this. Use KNF indentation and KNF field prefixes (ka_) if you add it :-). Generic field names like `size' and `data' need prefixes more than mos. The old struct was: % #define N_BIOS_GEOM 8 % ... % /* % * A zero bootinfo field often means that there is no info available. % * Flags are used to indicate the validity of fields where zero is a % * normal value. % */ % struct bootinfo { % u_int32_t bi_version; % u_int32_t bi_kernelname; /* represents a char * */ % u_int32_t bi_nfs_diskless; /* struct nfs_diskless * */ % /* End of fields that are always present. */ The original size was apparently 12. % #define bi_endcommon bi_n_bios_used Another style difference. The magic 12 is essentially given by this macro. This macro is a pseudo-field, like the ones for the copyable and zeroable regions in struct proc. Its name is in lower case. % u_int32_t bi_n_bios_used; % u_int32_t bi_bios_geom[N_BIOS_GEOM]; The struct was broken in 1994 by adding the above 2 fields without providing any way to distinguish it from the old struct. % u_int32_t bi_size; % u_int8_t bi_memsizes_valid; % u_int8_t bi_bios_dev; /* bootdev BIOS unit number */ % u_int8_t bi_pad[2]; % u_int32_t bi_basemem; % u_int32_t bi_extmem; % u_int32_t bi_symtab; /* struct symtab * */ % u_int32_t bi_esymtab; /* struct symtab * */ The above 8 fields were added in 1995 (together with fixing style bugs like no prefixes for the old field names). Now the struct is determined by its size according to the bi_size field, and the bi_version field is not really used (it's much easier to add stuff to the end than to support multiple versions). This gives a range of old sizes/versions: 12: ~1993 (FreeBSD-1) 48: ~1994 (FreeBSD-1 and/or 2) 0x48: FreeBSD-2 post-1995 But these old sizes are uninteresting since only boot loaders from before 1993-1995 support only the above fields, and these loaders can't boot current kernels. % /* Items below only from advanced bootloader */ % u_int32_t bi_kernend; /* end of kernel space */ % u_int32_t bi_envp; /* environment */ % u_int32_t bi_modulep; /* preloaded modules */ Added in 1998. Still uninteresting, since boot loaders newer than that are needed to boot current kernels (mainly for elf). % uint64_t bi_hcdp; /* DIG64 HCDP table */ % uint64_t bi_fpswa; /* FPSWA interface */ % uint64_t bi_systab; /* pa of EFI system table */ % uint64_t bi_memmap; /* pa of EFI memory map */ % uint64_t bi_memmap_size; /* size of EFI memory map */ % uint64_t bi_memdesc_size; /* sizeof EFI memory desc */ % uint32_t bi_memdesc_version; /* EFI memory desc version */ Added in 2010. Are all of these uint64_t types correct? The padding seems to be broken, so that these fields would not work for amd64: we're at offset 0x48 for bi_kernend. The 3 uint32_t's added in 1998 reach 0x54. Then all the uint64_t fields are misaligned on i386, and on amd64 there is unnamed padding before the first of them to align them. But and64 doesn't use bootinfo.h in the kernel, so I think only the i386 version is used on amd64 (in the boot loader), so the misaligned case isn't used. The struct declaration is also broken at the end. The last field is 32 bits, so there is unnamed padding after it on amd64 only. This padding should be explicit, like the padding before the uint64_t fields, or just put the 32-bit field before the 64-bit fields. % }; So apart you could hard-code the size to the 1998 value of 0x54 without losing anything except the buggy 2010 fields. But it shouldn't be hard-coded. Bruce From owner-freebsd-fs@FreeBSD.ORG Sat May 5 13:41:29 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1A99B106566B; Sat, 5 May 2012 13:41:29 +0000 (UTC) (envelope-from merlyn@stonehenge.com) Received: from gw17.lax01.mailroute.net (lax-gw17.mailroute.net [199.89.0.117]) by mx1.freebsd.org (Postfix) with ESMTP id E96178FC0A; Sat, 5 May 2012 13:41:28 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by gw17.lax01.mailroute.net (Postfix) with ESMTP id BA229666661; Sat, 5 May 2012 13:41:27 +0000 (GMT) X-Virus-Scanned: by MailRoute Received: from gw17.lax01.mailroute.net ([199.89.0.117]) by localhost (gw17.lax01.mailroute.net.mailroute.net [127.0.0.1]) (mroute_mailscanner, port 10026) with LMTP id QBERwIDHcH9X; Sat, 5 May 2012 13:41:26 +0000 (GMT) Received: from red.stonehenge.com (red.stonehenge.com [208.79.95.2]) by gw17.lax01.mailroute.net (Postfix) with ESMTP id 462386665F8; Sat, 5 May 2012 13:41:26 +0000 (GMT) Received: by red.stonehenge.com (Postfix, from userid 1001) id 039EB321F; Sat, 5 May 2012 06:41:26 -0700 (PDT) From: merlyn@stonehenge.com (Randal L. Schwartz) To: vermaden References: <86ipgbg2p6.fsf@red.stonehenge.com> <86d36jzk16.fsf@red.stonehenge.com> <867gwrzjwc.fsf@red.stonehenge.com> <86397fzjgi.fsf@red.stonehenge.com> <86y5p7y478.fsf@red.stonehenge.com> x-mayan-date: Long count = 12.19.19.6.10; tzolkin = 8 Oc; haab = 13 Uo Date: Sat, 05 May 2012 06:41:25 -0700 In-Reply-To: (vermaden@interia.pl's message of "Sat, 05 May 2012 08:19:11 +0200") Message-ID: <86d36iycca.fsf@red.stonehenge.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-fs@FreeBSD.org, freebsd-questions@freebsd.org Subject: Re: HOWTO: FreeBSD ZFS Madness (Boot Environments) 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, 05 May 2012 13:41:29 -0000 >>>>> "vermaden" == vermaden writes: vermaden> To the point, check these two code snippets, they should vermaden> do EXACLY the same, logic is the same, the differece is vermaden> only the syntax. vermaden> snippet 1: vermaden> [ ${MOUNT} -eq 0 ] && { vermaden> zfs set mountpoint=${TMPMNT} ${POOL}/ROOT/${2} vermaden> zfs mount ${POOL}/ROOT/${2} vermaden> } || { vermaden> TMPMNT=${MOUNT} vermaden> } vermaden> snippet 2: vermaden> if [ ${MOUNT} -eq 0 ]; then vermaden> zfs set mountpoint=${TMPMNT} ${POOL}/ROOT/${2} vermaden> zfs mount ${POOL}/ROOT/${2} vermaden> else vermaden> TMPMNT=${MOUNT} vermaden> fi No, no and no. I got burned by that about 30 years ago in shell programming. Every time I see someone use that, I shriek just a little bit. vermaden> ... or to rewrite it under if/then/else which I did for the whole vermaden> *beadm* utility and I no longer use || and && syntax, vermaden> anywhere. Good to see you've finally been burned. You'll never make that mistake again. :) vermaden> After reboot ... vermaden> # zfs destroy -R zroot/ROOT vermaden> # zfs create -o mountpoint=none zroot/ROOT vermaden> # zfs send zpool@be | zfs recv zroot/ROOT/be vermaden> # fetch https://raw.github.com/vermaden/beadm/master/beadm vermaden> # chmod +x beadm vermaden> # ./beadm list vermaden> # ./beadm activate be vermaden> # reboot vermaden> Now You should have a working system with boot environments. OK, I'll give that a try. Thanks for being persistent with me. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion