From owner-freebsd-fs@FreeBSD.ORG Sun Dec 6 02:26:00 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28EE7106566B for ; Sun, 6 Dec 2009 02:26:00 +0000 (UTC) (envelope-from josh@multipart-mixed.com) Received: from joshcarter.com (67-207-137-80.slicehost.net [67.207.137.80]) by mx1.freebsd.org (Postfix) with ESMTP id 07E598FC12 for ; Sun, 6 Dec 2009 02:25:59 +0000 (UTC) Received: from [192.168.1.141] (dsl081-096-235.den1.dsl.speakeasy.net [64.81.96.235]) by joshcarter.com (Postfix) with ESMTPSA id AD9ECC862C; Sun, 6 Dec 2009 02:25:58 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Josh Carter In-Reply-To: <20091205191526.GR73250@gremlin.foo.is> Date: Sat, 5 Dec 2009 19:25:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20091205170400.GM73250@gremlin.foo.is> <8555674.871260033069220.JavaMail.root@zimbra> <20091205184112.GP73250@gremlin.foo.is> <5da0588e0912051052p25fb743ele098ed9cb9de8fa0@mail.gmail.com> <20091205190641.GQ73250@gremlin.foo.is> <20091205191526.GR73250@gremlin.foo.is> To: Baldur Gislason X-Mailer: Apple Mail (2.1077) Cc: freebsd-fs@freebsd.org Subject: Re: ZFS and reordering drives 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, 06 Dec 2009 02:26:00 -0000 FWIW, I've hit drive re-ordering problems several times on FreeBSD and = OpenSolaris (most of those due to me doing abusive things to the system = on purpose). In all cases a "zfs export [pool]" and "zfs import [pool]" = fixed the issue. I'm not sure exactly what ZFS is doing, but even across = reboots it appears to remember the configuration it used to see, and = insist on seeing it again. An export/import forces ZFS to forget what it = knows and look at what's on the drives. -Josh From owner-freebsd-fs@FreeBSD.ORG Sun Dec 6 02:36:35 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A845D106566B for ; Sun, 6 Dec 2009 02:36:35 +0000 (UTC) (envelope-from rincebrain@gmail.com) Received: from mail-fx0-f209.google.com (mail-fx0-f209.google.com [209.85.220.209]) by mx1.freebsd.org (Postfix) with ESMTP id 3A23A8FC15 for ; Sun, 6 Dec 2009 02:36:35 +0000 (UTC) Received: by fxm2 with SMTP id 2so1147783fxm.13 for ; Sat, 05 Dec 2009 18:36:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+8tCvYEPggZF5hQvFD4/aohJcLMKfd/nv9+xrOzJlK4=; b=TbRcPBJ4D8+7LcdN3qKfEE7wuTC7jMQttzDkvtLb3hNs4US63o/gcJ38hyqbXoUBCl XXXvFjI7YD+SGOE5VJ1tkmo6vgH0bp6JNJl0Z/5DjkSI5NICJC+b/i4ROVq1OyMsjCEv i7EgnMVuynWRrdpUIWy/ns0+ncG2M3exxeygk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KqmX/G4rST52YDSNfOn9UmSOnbHQ5jwt13qwf8wvU+LkWDa0WSjsOazA+65ahQu8wV Q2Makp+rfCQnTawZnlqvg/l7yEHfjw6gRTDOdtypEmVHH0zucVU487N48ICHXxX64DXp PDsD6CdzYe+n9JEyCQKDStDGn686sMqR6RKho= MIME-Version: 1.0 Received: by 10.239.139.211 with SMTP id u19mr499587hbu.97.1260066994116; Sat, 05 Dec 2009 18:36:34 -0800 (PST) In-Reply-To: References: <20091205170400.GM73250@gremlin.foo.is> <8555674.871260033069220.JavaMail.root@zimbra> <20091205184112.GP73250@gremlin.foo.is> <5da0588e0912051052p25fb743ele098ed9cb9de8fa0@mail.gmail.com> <20091205190641.GQ73250@gremlin.foo.is> <20091205191526.GR73250@gremlin.foo.is> Date: Sat, 5 Dec 2009 21:36:34 -0500 Message-ID: <5da0588e0912051836m28ad14cald32277d94aff7c66@mail.gmail.com> From: Rich To: Josh Carter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: ZFS and reordering drives 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, 06 Dec 2009 02:36:35 -0000 Sure - the problem, as observed above, is no longer reordering (which as someone noted, can be fixed by importing by gpid out of /dev, on FBSD or Solaris), but that one of the drive sizes /shrank/, presumably due to bad blocks. - Rich On Sat, Dec 5, 2009 at 9:25 PM, Josh Carter wrot= e: > FWIW, I've hit drive re-ordering problems several times on FreeBSD and Op= enSolaris (most of those due to me doing abusive things to the system on pu= rpose). In all cases a "zfs export [pool]" and "zfs import [pool]" fixed th= e issue. I'm not sure exactly what ZFS is doing, but even across reboots it= appears to remember the configuration it used to see, and insist on seeing= it again. An export/import forces ZFS to forget what it knows and look at = what's on the drives. > > -Josh > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > --=20 my US geograpy is lousy...lol so's mine and I live here Make no little plans; they have no ma... From owner-freebsd-fs@FreeBSD.ORG Sun Dec 6 11:50:04 2009 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65AC3106566B for ; Sun, 6 Dec 2009 11:50:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 554CE8FC19 for ; Sun, 6 Dec 2009 11:50:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nB6Bo4xE020712 for ; Sun, 6 Dec 2009 11:50:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nB6Bo47v020711; Sun, 6 Dec 2009 11:50:04 GMT (envelope-from gnats) Date: Sun, 6 Dec 2009 11:50:04 GMT Message-Id: <200912061150.nB6Bo47v020711@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Dominik Ernst Cc: Subject: Re: kern/141177: [zfs] fsync() on FIFO causes panic() on zfs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dominik Ernst List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2009 11:50:04 -0000 The following reply was made to PR kern/141177; it has been noted by GNATS. From: Dominik Ernst To: Kostik Belousov Cc: bug-followup@freebsd.org Subject: Re: kern/141177: [zfs] fsync() on FIFO causes panic() on zfs Date: Sun, 6 Dec 2009 12:20:55 +0100 Thanks that seems to work as far as i can tell. On Sat, 5 Dec 2009 01:41:31 +0200 Kostik Belousov wrote: > ZFS explicitely puts VOP_PANIC as fsync vop for fifos. I think > the following patch fixes it. > > diff --git > a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c > b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c index > 7608d76..4f61f5f 100644 --- > a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c +++ > b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c @@ > -5009,7 +5009,7 @@ struct vop_vector zfs_vnodeops = { struct > vop_vector zfs_fifoops = { .vop_default = > &fifo_specops, > - .vop_fsync = VOP_PANIC, > + .vop_fsync = zfs_freebsd_fsync, > .vop_access = zfs_freebsd_access, > .vop_getattr = zfs_freebsd_getattr, > .vop_inactive = zfs_freebsd_inactive, > From owner-freebsd-fs@FreeBSD.ORG Sun Dec 6 12:26:12 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15FDC1065676 for ; Sun, 6 Dec 2009 12:26:12 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id 6B5188FC14 for ; Sun, 6 Dec 2009 12:26:11 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 277A045E35; Sun, 6 Dec 2009 13:26:09 +0100 (CET) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 8517E45C89; Sun, 6 Dec 2009 13:26:03 +0100 (CET) Date: Sun, 6 Dec 2009 13:26:03 +0100 From: Pawel Jakub Dawidek To: Josh Carter Message-ID: <20091206122603.GD2339@garage.freebsd.pl> References: <20091205170400.GM73250@gremlin.foo.is> <8555674.871260033069220.JavaMail.root@zimbra> <20091205184112.GP73250@gremlin.foo.is> <5da0588e0912051052p25fb743ele098ed9cb9de8fa0@mail.gmail.com> <20091205190641.GQ73250@gremlin.foo.is> <20091205191526.GR73250@gremlin.foo.is> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wchHw8dVAp53YPj8" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS and reordering drives 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, 06 Dec 2009 12:26:12 -0000 --wchHw8dVAp53YPj8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 05, 2009 at 07:25:56PM -0700, Josh Carter wrote: > FWIW, I've hit drive re-ordering problems several times on FreeBSD and Op= enSolaris (most of those due to me doing abusive things to the system on pu= rpose). In all cases a "zfs export [pool]" and "zfs import [pool]" fixed th= e issue. I'm not sure exactly what ZFS is doing, but even across reboots it= appears to remember the configuration it used to see, and insist on seeing= it again. An export/import forces ZFS to forget what it knows and look at = what's on the drives. The history of how ZFS on FreeBSD handles drives reordering is a bit long, but to make it short it now does the following: Search component by its name and guid stored in metadata. If guid doesn't match or there is no such device, go through all devices (GEOM providers) in the system and find one with matching guid. This should work this way for a long time now, but there was a small bug, which I fixed yesterday, where guid wasn't checked if name matched. It should work fine now in HEAD. In my opinion in Solaris it is less reliable now than it is in FreeBSD. When Solaris cannot find device by name it tries by its serial number. FreeBSD did that too in the past, but not all devices have serial numbers and sometimes it is hard to tell serial number (what serial number does partition have?). That's why when FreeBSD finds out that device under remembered name has different guid, etc. it will read all devices in the system. This is of course is more expensive than searching by serial number, but this happens were rarely (how often device names change?), so it is better to use more expensive, but more reliable mechanism. When pool is imported in the system, ZFS stores some info about it in /boot/zfs/zpool.cache file (components names too), so after reboot it can quickly decide which pools are imported and which GEOM providers are part of those pools. If there are problems with stored components names, it will fallback to expensive search as described above. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --wchHw8dVAp53YPj8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFLG6LbForvXbEpPzQRAsYWAKCxarCQuk0czbrvERFehpxI5ctmSQCgy7qi SJgcGpK4FFOWGkvvTVFz+ZE= =EKx9 -----END PGP SIGNATURE----- --wchHw8dVAp53YPj8-- From owner-freebsd-fs@FreeBSD.ORG Sun Dec 6 12:47:12 2009 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B146106566B; Sun, 6 Dec 2009 12:47:12 +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 E30A88FC14; Sun, 6 Dec 2009 12:47:11 +0000 (UTC) Received: from kremvax.housenet.jrv (kremvax.housenet.jrv [192.168.3.124]) by mail.jrv.org (8.14.3/8.14.3) with ESMTP id nB6ClAx1086621; Sun, 6 Dec 2009 06:47:10 -0600 (CST) (envelope-from james-freebsd-fs2@jrv.org) Authentication-Results: mail.jrv.org; domainkeys=pass (testing) header.from=james-freebsd-fs2@jrv.org DomainKey-Signature: a=rsa-sha1; s=enigma; d=jrv.org; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=YAC3mN/1xa6gMOIqz7exvQddb3l5GAP0HPlMrnvJpCRMkhMuvunXhQM2EkWqwkI24 r34HlCWcLhBiy6HHOj8vO6/3sXMb+JqBOTGoJFmA/ASKh4lM4zDMdbZ1aUIPatoao2w mJjCY3MQiQjGie8KcqYPGJme3N8QsA3lh6HMYnU= Message-ID: <4B1BA7CE.2050506@jrv.org> Date: Sun, 06 Dec 2009 06:47:10 -0600 From: "James R. Van Artsdalen" User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 References: <20091205170400.GM73250@gremlin.foo.is> <8555674.871260033069220.JavaMail.root@zimbra> <20091205184112.GP73250@gremlin.foo.is> <5da0588e0912051052p25fb743ele098ed9cb9de8fa0@mail.gmail.com> <20091205190641.GQ73250@gremlin.foo.is> <20091205191526.GR73250@gremlin.foo.is> <20091206122603.GD2339@garage.freebsd.pl> In-Reply-To: <20091206122603.GD2339@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs , Pawel Jakub Dawidek Subject: Re: ZFS and reordering drives 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, 06 Dec 2009 12:47:12 -0000 Pawel Jakub Dawidek wrote: > but there was a small > bug, which I fixed yesterday, where guid wasn't checked if name matched. Thanks - that should explain what I and others have seen. If (A) there is a drive name match and a GUID is found on the dev but (B) the expected GUID from zpool.cache doesn't match what's on the dev but (C) another dev is found via GEOM that does have the right GUID: is the drive name updated, at least so that "zpool status" prints the actual dev names and not what was in zpool.cache? From owner-freebsd-fs@FreeBSD.ORG Sun Dec 6 12:52:44 2009 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D55DC106566B for ; Sun, 6 Dec 2009 12:52:44 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id 19C9F8FC12 for ; Sun, 6 Dec 2009 12:52:43 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id D686F45C9F; Sun, 6 Dec 2009 13:52:41 +0100 (CET) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id B037F45685; Sun, 6 Dec 2009 13:52:36 +0100 (CET) Date: Sun, 6 Dec 2009 13:52:37 +0100 From: Pawel Jakub Dawidek To: "James R. Van Artsdalen" Message-ID: <20091206125237.GE2339@garage.freebsd.pl> References: <20091205170400.GM73250@gremlin.foo.is> <8555674.871260033069220.JavaMail.root@zimbra> <20091205184112.GP73250@gremlin.foo.is> <5da0588e0912051052p25fb743ele098ed9cb9de8fa0@mail.gmail.com> <20091205190641.GQ73250@gremlin.foo.is> <20091205191526.GR73250@gremlin.foo.is> <20091206122603.GD2339@garage.freebsd.pl> <4B1BA7CE.2050506@jrv.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="z0eOaCaDLjvTGF2l" Content-Disposition: inline In-Reply-To: <4B1BA7CE.2050506@jrv.org> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs Subject: Re: ZFS and reordering drives 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, 06 Dec 2009 12:52:44 -0000 --z0eOaCaDLjvTGF2l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 06, 2009 at 06:47:10AM -0600, James R. Van Artsdalen wrote: > Pawel Jakub Dawidek wrote: > > but there was a small > > bug, which I fixed yesterday, where guid wasn't checked if name matched. >=20 > Thanks - that should explain what I and others have seen. >=20 > If (A) there is a drive name match and a GUID is found on the dev but > (B) the expected GUID from zpool.cache doesn't match what's on the dev > but (C) another dev is found via GEOM that does have the right GUID: is > the drive name updated, at least so that "zpool status" prints the > actual dev names and not what was in zpool.cache? Yes. Name should be updated in zpool.cache. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --z0eOaCaDLjvTGF2l Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFLG6kUForvXbEpPzQRAov3AJ0eb2zNZGbqIiVvvo3rSxlX0kV0dACg4jUf J4OE0ohmwlSQXB1/gGEIm8s= =vH9h -----END PGP SIGNATURE----- --z0eOaCaDLjvTGF2l-- From owner-freebsd-fs@FreeBSD.ORG Sun Dec 6 13:24:30 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84DB11065670 for ; Sun, 6 Dec 2009 13:24:30 +0000 (UTC) (envelope-from guido@gvr.org) Received: from gvr.gvr.org (gvr-gw.gvr.org [82.95.154.195]) by mx1.freebsd.org (Postfix) with ESMTP id 458FF8FC17 for ; Sun, 6 Dec 2009 13:24:30 +0000 (UTC) Received: by gvr.gvr.org (Postfix, from userid 657) id AACDB42D812; Sun, 6 Dec 2009 13:55:47 +0100 (CET) Date: Sun, 6 Dec 2009 13:55:47 +0100 From: Guido van Rooij To: freebsd-fs@freebsd.org Message-ID: <20091206125547.GA24918@gvr.gvr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Problem with ntfs and media sector size 1024 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, 06 Dec 2009 13:24:30 -0000 I am running 6-stable and cannot mount an NTFS on a disk with a 1024-byte sector size. The disk: beck# geom disk list da1 Geom name: da1 Providers: 1. Name: da1 Mediasize: 500107862016 (466G) Sectorsize: 1024 Mode: r0w0e0 fwsectors: 63 fwheads: 255 beck# fdisk /dev/da1 ******* Working on device /dev/da1 ******* parameters extracted from in-core disklabel are: cylinders=30400 heads=255 sectors/track=63 (16065 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=30400 heads=255 sectors/track=63 (16065 blks/cyl) Media sector size is 1024 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 7 (0x07),(OS/2 HPFS, NTFS, QNX-2 (16 bit) or Advanced UNIX) start 63, size 488375937 (476929 Meg), flag 0 beg: cyl 0/ head 1/ sector 1; end: cyl 1023/ head 254/ sector 63 The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: When I try to mount the ntfs, I get: ntfs_mountfs(): bps: 1024, spc: 4, media: f8, mftrecsz: 246 (1 sects) ntfs_mountfs(): mftcn: 0xc0000|0x3a380d0 ntfs_mountfs(): case-sens., uid: 0, gid: 0, mode: 755 ntfs_vgetex: ino: 0, attr: 0x80:, lkf: 0x2, f: 0x0 ntfs_ntlookup: looking for ntnode 0 ntfs_ntget: get ntnode 0: 0xc7bdc500, usecount: 0 ntfs_ntlookup: ntnode 0: 0xc7bdc500, usecount: 1 ntfs_loadntnode: loading ino: 0 ntfs_loadntnode: read system node ntfs_loadntnode: bn: 3145728 ntfs_procfixups: magic doesn't match: 421f128f != 454c4946 ntfs_loadntnode: BAD MFT RECORD 0 ntfs_vget: CAN'T LOAD ATTRIBUTES FOR INO: 0 ntfs_ntput: rele ntnode 0: 0xc7bdc500, usecount: 1 ntfs_ntput: deallocating ntnode: 0 Note: bn: 3145728 is an additional debug printf I inserted just before the first bread in ntfs_loadntnode(). When I dd this block (using a bs=1k), I get a block with the correct ntfs magic: > dd if=/dev/da1s1 bs=1k skip=3145728 count=1 of=/tmp/1 1+0 records in 1+0 records out 1024 bytes transferred in 0.000735 secs (1393113 bytes/sec) > hexdump /tmp/1 | head -2 0000000 4946 454c 0030 0003 0ef9 0200 0000 0000 0000010 0001 0001 0038 0001 0198 0000 0400 0000 However: > dd if=/dev/da1s1 bs=1k skip=1572864 count=1 of=/tmp/2 1+0 records in 1+0 records out 1024 bytes transferred in 0.000732 secs (1399012 bytes/sec) > hexdump /tmp/2 | head -2 0000000 128f 421f 0b99 36e7 5e54 4062 cb2c ddd0 0000010 bdba 6c0e d690 aa5a d22e 2a30 cea2 b08e Note that this is exactly the wrong magic reported in the line: ntfs_procfixups: magic doesn't match: 421f128f != 454c4946 Note also the 1572864 * 2 = 3145728 I have tried to understand what is going on, and it seems that something is wrong in the following lines: bn = ntfs_cntobn(ntmp->ntm_mftcn) + ntmp->ntm_bpmftrec * ip->i_number; error = bread(ntmp->ntm_devvp, bn, ntfs_bntob(ntmp->ntm_bpmftrec), NOCRED, &bp); In bread, we see that the blocknumber passed is mulitplie by the statfs f_iosize value. I this case that is 4K, however, I think that blocknumbers are 1K in size. That gives a factor 4 though... Anyone with some fs internal clues on what might be wrong? -Guido From owner-freebsd-fs@FreeBSD.ORG Sun Dec 6 19:34:15 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 340B9106566B for ; Sun, 6 Dec 2009 19:34:15 +0000 (UTC) (envelope-from ktouet@gmail.com) Received: from mail-yw0-f194.google.com (mail-yw0-f194.google.com [209.85.211.194]) by mx1.freebsd.org (Postfix) with ESMTP id E8AC68FC0C for ; Sun, 6 Dec 2009 19:34:14 +0000 (UTC) Received: by ywh32 with SMTP id 32so4058062ywh.14 for ; Sun, 06 Dec 2009 11:34:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=sfytCF+f1DSdK2tM51FD3A4XutIDFE5uvVpX3sP6OHQ=; b=pNvmip+XoVqOCizRpLF6fRlPiCJhY2x6sNCiQhvm2ZFTEJLdWI77Wedhyl/auqME3p y0sF3oE8sXNOuAArCMKLSxDMfc2ZZuy3vGd/OTO8omXRy77oQuVUxffXfET4jIasm+F3 nyez0xEsipFAGTvVI+qsK3o37uExfnp04e2ak= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=b//4VDkZ3LQDoO/ZBl6RkDn5/7qZrNsYOYECSnK+1q3xqR5qFGAK3uQqpdn2QqVUxD EXx0Ma/Dlgvowqcjxa/gAgUmcJNs9lTCu2lhg24zI8XJxNqj4PUAATZbS09rKFQwg0Iu 7d3dT+2sbieXRo2H3RU6rNh5UaOQeKPKsENcI= MIME-Version: 1.0 Received: by 10.91.164.30 with SMTP id r30mr9429886ago.95.1260128053659; Sun, 06 Dec 2009 11:34:13 -0800 (PST) Date: Sun, 6 Dec 2009 13:34:13 -0600 Message-ID: <2a5e326f0912061134s79c05e75td77e6874d409c675@mail.gmail.com> From: Kurt Touet To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: zpool create fails on gpart device 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, 06 Dec 2009 19:34:15 -0000 I've been interested in using a gptzfsboot setup on a few of my systems, and thought I'd try it out in a VM first, but I'm blocked at creating a zpool. Here's what I did: - create a new VM with 2 drives (da0 & da1) - install 8.0R amd64 - install subversion from sysinstall & checkout base/head - build & install -current Instead of creating a gptzfsboot install disc, I thought I'd just create the zpool on the second drive, install things to there, and then make the VM boot off the second drive afterwards (and remove the first). I was following the http://blogs.freebsdish.org/lulf/2008/12/16/setting-up-a-zfs-only-system/ guide, and got to this stage: # gpart create -s GPT da1 # gpart add -b 34 -s 128 -t freebsd-boot da1 # gpart add -b 162 -s 5242880 -t freebsd-swap da1 # gpart add -b 5243042 -s 57671485 -t freebsd-zfs da1 # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da1 # gpart show da1 => 34 62914493 da1 GPT (30G) 34 128 1 freebsd-boot (64K) 162 5242880 2 freebsd-swap (2.5G) 5243042 57671485 3 freebsd-zfs (27G) # zpool create data /dev/da1p3 cannot create 'data': permission denied Dec 6 13:30:23 freebase root: ZFS: vdev failure, zpool=data type=vdev.open_failed I believe that this is a zpool related issue because the following then works: # newfs /dev/da1p3 /dev/da1p3: 28159.9MB (57671484 sectors) block size 16384, fragment size 2048 using 154 cylinder groups of 183.72MB, 11758 blks, 23552 inodes. super-block backups (for fsck -b #) at: 160, 376416, 752672, 1128928, 1505184, 1881440, 2257696, 2633952, 3010208, 3386464, 3762720, 4138976, 4515232, 4891488, 5267744, 5644000, 6020256, 6396512, 6772768, 7149024, 7525280, 7901536, 8277792, 8654048, 9030304, 9406560, 9782816, 10159072, 10535328, 10911584, 11287840, 11664096, 12040352, 12416608, 12792864, 13169120, 13545376, 13921632, 14297888, 14674144, 15050400, 15426656, 15802912, 16179168, 16555424, 16931680, 17307936, 17684192, 18060448, 18436704, 18812960, 19189216, 19565472, 19941728, 20317984, 20694240, 21070496, 21446752, 21823008, 22199264, 22575520, 22951776, 23328032, 23704288, 24080544, 24456800, 24833056, 25209312, 25585568, 25961824, 26338080, 26714336, 27090592, 27466848, 27843104, 28219360, 28595616, 28971872, 29348128, 29724384, 30100640, 30476896, 30853152, 31229408, 31605664, 31981920, 32358176, 32734432, 33110688, 33486944, 33863200, 34239456, 34615712, 34991968, 35368224, 35744480, 36120736, 36496992, 36873248, 37249504, 37625760, 38002016, 38378272, 38754528, 39130784, 39507040, 39883296, 40259552, 40635808, 41012064, 41388320, 41764576, 42140832, 42517088, 42893344, 43269600, 43645856, 44022112, 44398368, 44774624, 45150880, 45527136, 45903392, 46279648, 46655904, 47032160, 47408416, 47784672, 48160928, 48537184, 48913440, 49289696, 49665952, 50042208, 50418464, 50794720, 51170976, 51547232, 51923488, 52299744, 52676000, 53052256, 53428512, 53804768, 54181024, 54557280, 54933536, 55309792, 55686048, 56062304, 56438560, 56814816, 57191072, 57567328 # mkdir /test # mount /dev/da1p3 /test # df -h Filesystem Size Used Avail Capacity Mounted on /dev/da0s1a 496M 259M 197M 57% / devfs 1.0K 1.0K 0B 100% /dev /dev/da0s1e 496M 5.1M 451M 1% /tmp /dev/da0s1f 8.8G 3.1G 4.9G 39% /usr /dev/da0s1d 1.9G 1.0M 1.8G 0% /var /dev/da1p3 27G 4.0K 24G 0% /test Any help would be appreciated. Thanks, -kurt From owner-freebsd-fs@FreeBSD.ORG Sun Dec 6 20:15:47 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA151106566C for ; Sun, 6 Dec 2009 20:15:47 +0000 (UTC) (envelope-from guido@gvr.org) Received: from gvr.gvr.org (gvr-gw.gvr.org [82.95.154.195]) by mx1.freebsd.org (Postfix) with ESMTP id 9AC168FC18 for ; Sun, 6 Dec 2009 20:15:47 +0000 (UTC) Received: by gvr.gvr.org (Postfix, from userid 657) id D578442D816; Sun, 6 Dec 2009 21:15:46 +0100 (CET) Date: Sun, 6 Dec 2009 21:15:46 +0100 From: Guido van Rooij To: freebsd-fs@freebsd.org Message-ID: <20091206201546.GA30476@gvr.gvr.org> References: <20091206125547.GA24918@gvr.gvr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091206125547.GA24918@gvr.gvr.org> Subject: Re: Problem with ntfs and media sector size 1024 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, 06 Dec 2009 20:15:47 -0000 On Sun, Dec 06, 2009 at 01:55:47PM +0100, Guido van Rooij wrote: > > When I try to mount the ntfs, I get: > ntfs_mountfs(): bps: 1024, spc: 4, media: f8, mftrecsz: 246 (1 sects) > ntfs_mountfs(): mftcn: 0xc0000|0x3a380d0 > ntfs_mountfs(): case-sens., uid: 0, gid: 0, mode: 755 > ntfs_vgetex: ino: 0, attr: 0x80:, lkf: 0x2, f: 0x0 > ntfs_ntlookup: looking for ntnode 0 > ntfs_ntget: get ntnode 0: 0xc7bdc500, usecount: 0 > ntfs_ntlookup: ntnode 0: 0xc7bdc500, usecount: 1 > ntfs_loadntnode: loading ino: 0 > ntfs_loadntnode: read system node > ntfs_loadntnode: bn: 3145728 > ntfs_procfixups: magic doesn't match: 421f128f != 454c4946 > ntfs_loadntnode: BAD MFT RECORD 0 > ntfs_vget: CAN'T LOAD ATTRIBUTES FOR INO: 0 > ntfs_ntput: rele ntnode 0: 0xc7bdc500, usecount: 1 > ntfs_ntput: deallocating ntnode: 0 > > Note: bn: 3145728 is an additional debug printf I inserted just before the > first bread in ntfs_loadntnode(). > > When I dd this block (using a bs=1k), I get a block with the correct ntfs magic: > > dd if=/dev/da1s1 bs=1k skip=3145728 count=1 of=/tmp/1 > 1+0 records in > 1+0 records out > 1024 bytes transferred in 0.000735 secs (1393113 bytes/sec) > > hexdump /tmp/1 | head -2 > 0000000 4946 454c 0030 0003 0ef9 0200 0000 0000 > 0000010 0001 0001 0038 0001 0198 0000 0400 0000 > > However: > > dd if=/dev/da1s1 bs=1k skip=1572864 count=1 of=/tmp/2 > 1+0 records in > 1+0 records out > 1024 bytes transferred in 0.000732 secs (1399012 bytes/sec) > > hexdump /tmp/2 | head -2 > 0000000 128f 421f 0b99 36e7 5e54 4062 cb2c ddd0 > 0000010 bdba 6c0e d690 aa5a d22e 2a30 cea2 b08e > > Note that this is exactly the wrong magic reported in the line: > ntfs_procfixups: magic doesn't match: 421f128f != 454c4946 > > Note also the 1572864 * 2 = 3145728 > Some additional info: When I force reading the correct blocknr (I just assign bn *= 2), ntfs_procfixups() complains: ntfs_procfixups: bad fixups number: 3 for 1024 bytes block -Guido From owner-freebsd-fs@FreeBSD.ORG Mon Dec 7 07:24:54 2009 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D51FF1065692; Mon, 7 Dec 2009 07:24:54 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id AB9288FC08; Mon, 7 Dec 2009 07:24:54 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nB77Os1w049378; Mon, 7 Dec 2009 07:24:54 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nB77OsB9049374; Mon, 7 Dec 2009 07:24:54 GMT (envelope-from linimon) Date: Mon, 7 Dec 2009 07:24:54 GMT Message-Id: <200912070724.nB77OsB9049374@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/141235: [disklabel] 8.0 no longer provides /dev entries for all disk slices [regression] 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, 07 Dec 2009 07:24:54 -0000 Old Synopsis: 8.0 no longer provides /dev entries for all disk slices New Synopsis: [disklabel] 8.0 no longer provides /dev entries for all disk slices [regression] Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon Dec 7 07:22:03 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). To submitter: does this happen to be a 'dangerously dedicated' disk? http://www.freebsd.org/cgi/query-pr.cgi?pr=141235 From owner-freebsd-fs@FreeBSD.ORG Mon Dec 7 07:36:20 2009 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94FFA106566C; Mon, 7 Dec 2009 07:36:20 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6C0A58FC0C; Mon, 7 Dec 2009 07:36:20 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nB77aKOp080495; Mon, 7 Dec 2009 07:36:20 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nB77aKsK080491; Mon, 7 Dec 2009 07:36:20 GMT (envelope-from linimon) Date: Mon, 7 Dec 2009 07:36:20 GMT Message-Id: <200912070736.nB77aKsK080491@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/141194: [tmpfs] tmpfs treats the size option as mod 2^32 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, 07 Dec 2009 07:36:20 -0000 Old Synopsis: tmpfs treats the size option as mod 2^32 New Synopsis: [tmpfs] tmpfs treats the size option as mod 2^32 Responsible-Changed-From-To: freebsd-i386->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon Dec 7 07:35:10 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=141194 From owner-freebsd-fs@FreeBSD.ORG Mon Dec 7 11:06:54 2009 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34D15106568B for ; Mon, 7 Dec 2009 11:06:54 +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 010278FC15 for ; Mon, 7 Dec 2009 11:06:54 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nB7B6rRR068465 for ; Mon, 7 Dec 2009 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nB7B6rbH068463 for freebsd-fs@FreeBSD.org; Mon, 7 Dec 2009 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 7 Dec 2009 11:06:53 GMT Message-Id: <200912071106.nB7B6rbH068463@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, 07 Dec 2009 11:06:54 -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/141235 fs [disklabel] 8.0 no longer provides /dev entries for al o kern/141194 fs [tmpfs] tmpfs treats the size option as mod 2^32 o kern/141177 fs [zfs] fsync() on FIFO causes panic() on zfs 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/140853 fs [nfs] [patch] NFSv2 remove calls fail to send error re o sparc/140797 fs [nfs] [panic] panic on 8.0-RC3/sparc64 as an NFS serve o kern/140682 fs [netgraph] [panic] random panic in netgraph o kern/140661 fs [zfs] /boot/loader fails to work on a GPT/ZFS-only sys o kern/140640 fs [zfs] snapshot crash o kern/140433 fs [zfs] [panic] panic while replaying ZIL after crash o kern/140134 fs [msdosfs] write and fsck destroy filesystem integrity o kern/140068 fs [smbfs] [patch] smbfs does not allow semicolon in file o kern/139725 fs [zfs] zdb(1) dumps core on i386 when examining zpool c o kern/139715 fs [zfs] vfs.numvnodes leak on busy zfs o bin/139651 fs [nfs] mount(8): read-only remount of NFS volume does n o kern/139597 fs [patch] [tmpfs] tmpfs initializes va_gen but doesn't u o kern/139564 fs [zfs] [panic] 8.0-RC1 - Fatal trap 12 at end of shutdo o kern/139407 fs [smbfs] [panic] smb mount causes system crash if remot o kern/139363 fs [nfs] diskless root nfs mount from non FreeBSD server o kern/138790 fs [zfs] ZFS ceases caching when mem demand is high o kern/138524 fs [msdosfs] disks and usb flashes/cards with Russian lab o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138367 fs [tmpfs] [panic] 'panic: Assertion pages > 0 failed' wh o kern/138202 fs mount_msdosfs(1) see only 2Gb o kern/138109 fs [extfs] [patch] Minor cleanups to the sys/gnu/fs/ext2f f kern/137037 fs [zfs] [hang] zfs rollback on root causes FreeBSD to fr o kern/136968 fs [ufs] [lor] ufs/bufwait/ufs (open) o kern/136945 fs [ufs] [lor] filedesc structure/ufs (poll) o kern/136944 fs [ffs] [lor] bufwait/snaplk (fsync) o kern/136873 fs [ntfs] Missing directories/files on NTFS volume o kern/136865 fs [nfs] [patch] NFS exports atomic and on-the-fly atomic o kern/136470 fs [nfs] Cannot mount / in read-only, over NFS o kern/135594 fs [zfs] Single dataset unresponsive with Samba o kern/135546 fs [zfs] zfs.ko module doesn't ignore zpool.cache filenam o kern/135469 fs [ufs] [panic] kernel crash on md operation in ufs_dirb o kern/135050 fs [zfs] ZFS clears/hides disk errors on reboot o kern/134491 fs [zfs] Hot spares are rather cold... o kern/133980 fs [panic] [ffs] panic: ffs_valloc: dup alloc o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis o kern/133614 fs [panic] panic: ffs_truncate: read-only filesystem o kern/133174 fs [msdosfs] [patch] msdosfs must support utf-encoded int f kern/133150 fs [zfs] Page fault with ZFS on 7.1-RELEASE/amd64 while w o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132597 fs [tmpfs] [panic] tmpfs-related panic while interrupting o kern/132397 fs reboot causes filesystem corruption (failure to sync b o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132237 fs [msdosfs] msdosfs has problems to read MSDOS Floppy o kern/132145 fs [panic] File System Hard Crashes o kern/131995 fs [nfs] Failure to mount NFSv4 server o kern/131441 fs [unionfs] [nullfs] unionfs and/or nullfs not combineab o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131342 fs [nfs] mounting/unmounting of disks causes NFS to fail o bin/131341 fs makefs: error "Bad file descriptor" on the mount poin o kern/130979 fs [smbfs] [panic] boot/kernel/smbfs.ko o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130229 fs [iconv] usermount fails on fs that need iconv o kern/130210 fs [nullfs] Error by check nullfs o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129488 fs [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) o kern/129059 fs [zfs] [patch] ZFS bootloader whitelistable via WITHOUT f kern/128829 fs smbd(8) causes periodic panic on 7-RELEASE o kern/127659 fs [tmpfs] tmpfs memory leak o kern/127420 fs [gjournal] [panic] Journal overflow on gmirrored gjour o kern/127029 fs [panic] mount(8): trying to mount a write protected zi o kern/126287 fs [ufs] [panic] Kernel panics while mounting an UFS file s kern/125738 fs [zfs] [request] SHA256 acceleration in ZFS p kern/124621 fs [ext3] [patch] Cannot mount ext2fs partition f bin/124424 fs [zfs] zfs(8): zfs list -r shows strange snapshots' siz o kern/123939 fs [msdosfs] corrupts new files o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121898 fs [nullfs] pwd(1)/getcwd(2) fails with Permission denied o bin/121779 fs [ufs] snapinfo(8) (and related tools?) only work for t o bin/121366 fs [zfs] [patch] Automatic disk scrubbing from periodic(8 o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha f kern/120991 fs [panic] [fs] [snapshot] System crashes when manipulati o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F f kern/119735 fs [zfs] geli + ZFS + samba starting on boot panics 7.0-B o kern/118912 fs [2tb] disk sizing/geometry problem with large array o kern/118713 fs [minidump] [patch] Display media size required for a k o bin/118249 fs mv(1): moving a directory changes its mtime o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N o bin/117315 fs [smbfs] mount_smbfs(8) and related options can't mount o kern/117314 fs [ntfs] Long-filename only NTFS fs'es cause kernel pani o kern/117158 fs [zfs] zpool scrub causes panic if geli vdevs detach on o bin/116980 fs [msdosfs] [patch] mount_msdosfs(8) resets some flags f o kern/116913 fs [ffs] [panic] ffs_blkfree: freeing free block p kern/116608 fs [msdosfs] [patch] msdosfs fails to check mount options o kern/116583 fs [ffs] [hang] System freezes for short time when using o kern/116170 fs [panic] Kernel panic when mounting /tmp o kern/115645 fs [snapshots] [panic] lockmgr: thread 0xc4c00d80, not ex o bin/115361 fs [zfs] mount(8) gets into a state where it won't set/un o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/113852 fs [smbfs] smbfs does not properly implement DFS referral o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/111843 fs [msdosfs] Long Names of files are incorrectly created o kern/111782 fs [ufs] dump(8) fails horribly for large filesystems s bin/111146 fs [2tb] fsck(8) fails on 6T filesystem o kern/109024 fs [msdosfs] mount_msdosfs: msdosfs_iconv: Operation not o kern/109010 fs [msdosfs] can't mv directory within fat32 file system o bin/107829 fs [2TB] fdisk(8): invalid boundary checking in fdisk / w o kern/106030 fs [ufs] [panic] panic in ufs from geom when a dead disk o kern/104406 fs [ufs] Processes get stuck in "ufs" state under persist o kern/104133 fs [ext2fs] EXT2FS module corrupts EXT2/3 filesystems o kern/103035 fs [ntfs] Directories in NTFS mounted disc images appear o kern/101324 fs [smbfs] smbfs sometimes not case sensitive when it's s o kern/99290 fs [ntfs] mount_ntfs ignorant of cluster sizes o kern/97377 fs [ntfs] [patch] syntax cleanup for ntfs_ihash.c o kern/95222 fs [iso9660] File sections on ISO9660 level 3 CDs ignored o kern/94849 fs [ufs] rename on UFS filesystem is not atomic o kern/94769 fs [ufs] Multiple file deletions on multi-snapshotted fil o kern/94733 fs [smbfs] smbfs may cause double unlock o kern/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/92272 fs [ffs] [hang] Filling a filesystem while creating a sna f kern/91568 fs [ufs] [panic] writing to UFS/softupdates DVD media in o kern/91134 fs [smbfs] [patch] Preserve access and modification time a kern/90815 fs [smbfs] [patch] SMBFS with character conversions somet o kern/88657 fs [smbfs] windows client hang when browsing a samba shar o kern/88266 fs [smbfs] smbfs does not implement UIO_NOCOPY and sendfi o kern/87859 fs [smbfs] System reboot while umount smbfs. o kern/86587 fs [msdosfs] rm -r /PATH fails with lots of small files o kern/85326 fs [smbfs] [panic] saving a file via samba to an overquot o kern/84589 fs [2TB] 5.4-STABLE unresponsive during background fsck 2 o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi o kern/73484 fs [ntfs] Kernel panic when doing `ls` from the client si o bin/73019 fs [ufs] fsck_ufs(8) cannot alloc 607016868 bytes for ino o kern/71774 fs [ntfs] NTFS cannot "see" files on a WinXP filesystem o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po o kern/65920 fs [nwfs] Mounted Netware filesystem behaves strange o kern/65901 fs [smbfs] [patch] smbfs fails fsx write/truncate-down/tr o kern/61503 fs [smbfs] mount_smbfs does not work as non-root o kern/55617 fs [smbfs] Accessing an nsmb-mounted drive via a smb expo o kern/51685 fs [hang] Unbounded inode allocation causes kernel to loc o kern/51583 fs [nullfs] [patch] allow to work with devices and socket o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o kern/18874 fs [2TB] 32bit NFS servers export wrong negative values t 147 problems total. From owner-freebsd-fs@FreeBSD.ORG Mon Dec 7 15:15:58 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10B8B1065694 for ; Mon, 7 Dec 2009 15:15:58 +0000 (UTC) (envelope-from guido@gvr.org) Received: from gvr.gvr.org (gvr-gw.gvr.org [82.95.154.195]) by mx1.freebsd.org (Postfix) with ESMTP id CC01A8FC08 for ; Mon, 7 Dec 2009 15:15:57 +0000 (UTC) Received: by gvr.gvr.org (Postfix, from userid 657) id E68F142D815; Mon, 7 Dec 2009 16:15:56 +0100 (CET) Date: Mon, 7 Dec 2009 16:15:56 +0100 From: Guido van Rooij To: freebsd-fs@freebsd.org Message-ID: <20091207151556.GA45910@gvr.gvr.org> References: <20091206125547.GA24918@gvr.gvr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091206125547.GA24918@gvr.gvr.org> Subject: Re: Problem with ntfs and media sector size 1024 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, 07 Dec 2009 15:15:58 -0000 Fixed with svn commit 200214. -Guido From owner-freebsd-fs@FreeBSD.ORG Mon Dec 7 19:10:57 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54C80106566B for ; Mon, 7 Dec 2009 19:10:57 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id 8A6208FC27 for ; Mon, 7 Dec 2009 19:10:56 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 04A4B45CD8; Mon, 7 Dec 2009 20:10:55 +0100 (CET) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 1548D45C9C; Mon, 7 Dec 2009 20:10:48 +0100 (CET) Date: Mon, 7 Dec 2009 20:10:48 +0100 From: Pawel Jakub Dawidek To: Kurt Touet Message-ID: <20091207191048.GB1795@garage.freebsd.pl> References: <2a5e326f0912061134s79c05e75td77e6874d409c675@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="K8nIJk4ghYZn606h" Content-Disposition: inline In-Reply-To: <2a5e326f0912061134s79c05e75td77e6874d409c675@mail.gmail.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: zpool create fails on gpart device 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, 07 Dec 2009 19:10:57 -0000 --K8nIJk4ghYZn606h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 06, 2009 at 01:34:13PM -0600, Kurt Touet wrote: > I've been interested in using a gptzfsboot setup on a few of my > systems, and thought I'd try it out in a VM first, but I'm blocked at > creating a zpool. Here's what I did: >=20 > - create a new VM with 2 drives (da0 & da1) > - install 8.0R amd64 > - install subversion from sysinstall & checkout base/head > - build & install -current >=20 > Instead of creating a gptzfsboot install disc, I thought I'd just > create the zpool on the second drive, install things to there, and > then make the VM boot off the second drive afterwards (and remove the > first). I was following the > http://blogs.freebsdish.org/lulf/2008/12/16/setting-up-a-zfs-only-system/ > guide, and got to this stage: >=20 > # gpart create -s GPT da1 > # gpart add -b 34 -s 128 -t freebsd-boot da1 > # gpart add -b 162 -s 5242880 -t freebsd-swap da1 > # gpart add -b 5243042 -s 57671485 -t freebsd-zfs da1 > # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da1 >=20 > # gpart show da1 > =3D> 34 62914493 da1 GPT (30G) > 34 128 1 freebsd-boot (64K) > 162 5242880 2 freebsd-swap (2.5G) > 5243042 57671485 3 freebsd-zfs (27G) >=20 > # zpool create data /dev/da1p3 > cannot create 'data': permission denied Can you ktrace this? --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --K8nIJk4ghYZn606h Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFLHVM4ForvXbEpPzQRAiO0AKCF7x/5ewkZUTD3Nop4PnrebRicPgCglMPC J2H1e3Uj6PSND5za7dp5ZW0= =dj34 -----END PGP SIGNATURE----- --K8nIJk4ghYZn606h-- From owner-freebsd-fs@FreeBSD.ORG Mon Dec 7 20:03:11 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DDDC1065693; Mon, 7 Dec 2009 20:03:11 +0000 (UTC) (envelope-from ktouet@gmail.com) Received: from mail-yw0-f194.google.com (mail-yw0-f194.google.com [209.85.211.194]) by mx1.freebsd.org (Postfix) with ESMTP id E84888FC2B; Mon, 7 Dec 2009 20:03:10 +0000 (UTC) Received: by ywh32 with SMTP id 32so5022419ywh.14 for ; Mon, 07 Dec 2009 12:03:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=KHRnevqCseqSyCp8ewv/cnoJSk3tu0nX0Hid8hL2wmQ=; b=qm8nOaVTrATd/S9eTSW6Y4mjLGTAY+NjrTMGqPHGUmeWmzeQ3QKiZKxTCI4KXIaM+y kkTAcMBSp7GZb9odXnvm7EAZyzf2x7ZjEB/VvhY4fS5XH4TLeStksWMhrItFFeEd412R unPuJ7JJYcRiz7A4xKtxI/UiulGy1B3LeT1sw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=rwzVLF68vxraFKvfIIsUZ9pBWyGAGQSaC1QGW+zULjWO0r3y4eyMpP4EW6XPWJoLtC 4ATyxT5V/zvG9SZWAHuCLZiYi04FJNc9xP+AtZO8IUi3edoHrY7GL+SUA/b/ZXjli3Le HsKOi7ygi/HJjnxcUjeoWW2Dt3iCHdR455Qws= MIME-Version: 1.0 Received: by 10.90.14.13 with SMTP id 13mr11437361agn.117.1260216189625; Mon, 07 Dec 2009 12:03:09 -0800 (PST) In-Reply-To: <20091207191048.GB1795@garage.freebsd.pl> References: <2a5e326f0912061134s79c05e75td77e6874d409c675@mail.gmail.com> <20091207191048.GB1795@garage.freebsd.pl> Date: Mon, 7 Dec 2009 14:03:09 -0600 Message-ID: <2a5e326f0912071203y35d45205n4566c1bb3260166d@mail.gmail.com> From: Kurt Touet To: Pawel Jakub Dawidek Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: zpool create fails on gpart device 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, 07 Dec 2009 20:03:11 -0000 On Mon, Dec 7, 2009 at 1:10 PM, Pawel Jakub Dawidek wrote= : > On Sun, Dec 06, 2009 at 01:34:13PM -0600, Kurt Touet wrote: >> I've been interested in using a gptzfsboot setup on a few of my >> systems, and thought I'd try it out in a VM first, but I'm blocked at >> creating a zpool. =A0Here's what I did: >> >> - create a new VM with 2 drives (da0 & da1) >> - install 8.0R amd64 >> - install subversion from sysinstall & checkout base/head >> - build & install -current >> >> Instead of creating a gptzfsboot install disc, I thought I'd just >> create the zpool on the second drive, install things to there, and >> then make the VM boot off the second drive afterwards (and remove the >> first). =A0I was following the >> http://blogs.freebsdish.org/lulf/2008/12/16/setting-up-a-zfs-only-system= / >> guide, and got to this stage: >> >> # gpart create -s GPT da1 >> # gpart add -b 34 -s 128 -t freebsd-boot da1 >> # gpart add -b 162 -s 5242880 -t freebsd-swap da1 >> # gpart add -b 5243042 -s 57671485 -t freebsd-zfs da1 >> # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da1 >> >> # gpart show da1 >> =3D> =A0 =A0 =A034 =A062914493 =A0da1 =A0GPT =A0(30G) >> =A0 =A0 =A0 =A0 34 =A0 =A0 =A0 128 =A0 =A01 =A0freebsd-boot =A0(64K) >> =A0 =A0 =A0 =A0162 =A0 5242880 =A0 =A02 =A0freebsd-swap =A0(2.5G) >> =A0 =A05243042 =A057671485 =A0 =A03 =A0freebsd-zfs =A0(27G) >> >> # zpool create data /dev/da1p3 >> cannot create 'data': permission denied > > Can you ktrace this? > > -- > Pawel Jakub Dawidek =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://ww= w.wheel.pl > pjd@FreeBSD.org =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http:= //www.FreeBSD.org > FreeBSD committer =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Am I Ev= il? Yes, I Am! > If more than this snippet is of interest, let me know. 5665 zpool CALL readlink(0x8010ee6bb,0x7fffffffa610,0x400) 5665 zpool NAMI "/etc/malloc.conf" 5665 zpool RET readlink -1 errno 2 No such file or directory 5665 zpool CALL issetugid 5665 zpool RET issetugid 0 5665 zpool CALL break(0x600000) 5665 zpool RET break 0 5665 zpool CALL __sysctl(0x7fffffffa830,0x2,0x7fffffffa84c,0x7fffffffa840,0,0) 5665 zpool SCTL "kern.osreldate" 5665 zpool RET __sysctl 0 5665 zpool CALL mmap(0,0x200000,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,0xffffffff,0) 5665 zpool RET mmap 19079168/0x801232000 5665 zpool CALL mmap(0x801432000,0x1ce000,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,0xfffff= fff,0) 5665 zpool RET mmap 21176320/0x801432000 5665 zpool CALL munmap(0x801232000,0x1ce000) 5665 zpool RET munmap 0 5665 zpool CALL open(0x800783661,O_RDWR,0) 5665 zpool NAMI "/dev/zfs" 5665 zpool RET open 3 5665 zpool CALL open(0x80078366a,O_RDONLY,0x1b6) 5665 zpool NAMI "/dev/null" 5665 zpool RET open 4 5665 zpool CALL open(0x800782e7d,O_RDONLY,0x1b6) 5665 zpool NAMI "/etc/zfs/exports" 5665 zpool RET open 5 5665 zpool CALL open(0x7fffffffedba,O_RDONLY,0) 5665 zpool NAMI "/dev/da1p3" 5665 zpool RET open 6 5665 zpool CALL ioctl(0x6,DIOCGSECTORSIZE,0x7fffffff9de4) 5665 zpool RET ioctl 0 5665 zpool CALL close(0x6) 5665 zpool RET close 0 5665 zpool CALL open(0x7fffffff9ff0,O_RDONLY,0x1411040) 5665 zpool NAMI "/dev/da1p3" 5665 zpool RET open 6 5665 zpool CALL close(0x6) 5665 zpool RET close 0 5665 zpool CALL open(0x7fffffff94c0,O_RDONLY,0) 5665 zpool NAMI "/dev/da1p3" 5665 zpool RET open 6 5665 zpool CALL fstat(0x6,0x7fffffff92a0) 5665 zpool STRU struct stat {dev=3D100728576, ino=3D101, mode=3Dcrw-r----- , nlink=3D1, uid=3D0, gid=3D5, rdev=3D101, atime=3D126021= 5299, stime=3D1260215299, ctime=3D1260215299, birthtime=3D-1, size=3D0, blksize=3D4096, blocks=3D0, flags=3D0x0 } 5665 zpool RET fstat 0 5665 zpool CALL pread(0x6,0x801415000,0x40000,0) 5665 zpool GIO fd 6 read 4096 bytes "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\= 0\0\0\0\0\0\0\0\0\0\0\0\ \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0= \0\0\0\0\0\0\0\0\ .... snip .... \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0= \0\0\0\0\0\0\0\0\ \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0= \0\0\0\0\0\0\0\0\ \0" 5665 zpool RET pread 262144/0x40000 5665 zpool CALL pread(0x6,0x801415000,0x40000,0x40000) 5665 zpool GIO fd 6 read 4096 bytes "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\= 0\0\0\0\0\0\0\0\0\0\0\0\ \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0= \0\0\0\0\0\0\0\0\ .... snip .... \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0= \0\0\0\0\0\0\0\0\ \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0= \0\0\0\0\0\0\0\0\ \0" 5665 zpool RET pread 262144/0x40000 5665 zpool CALL pread(0x6,0x801415000,0x40000,0xfffffffffff80000) 5665 zpool RET pread -1 errno 5 Input/output error 5665 zpool CALL pread(0x6,0x801415000,0x40000,0xfffffffffffc0000) 5665 zpool RET pread -1 errno 5 Input/output error 5665 zpool CALL close(0x6) 5665 zpool RET close 0 5665 zpool CALL stat(0x7fffffffa670,0x7fffffffa590) 5665 zpool NAMI "/data" 5665 zpool RET stat -1 errno 2 No such file or directory 5665 zpool CALL ioctl(0x3,0xcc285a00 ,0x7fffffff9570) 5665 zpool RET ioctl -1 errno 13 Permission denied 5665 zpool CALL write(0x2,0x7fffffff8d80,0x28) 5665 zpool GIO fd 2 wrote 40 bytes "cannot create 'data': permission denied " 5665 zpool RET write 40/0x28 5665 zpool CALL close(0x3) 5665 zpool RET close 0 5665 zpool CALL close(0x4) 5665 zpool RET close 0 5665 zpool CALL close(0x5) 5665 zpool RET close 0 From owner-freebsd-fs@FreeBSD.ORG Mon Dec 7 20:40:22 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C8931065670 for ; Mon, 7 Dec 2009 20:40:22 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id 593518FC0C for ; Mon, 7 Dec 2009 20:40:20 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 4298D45F18; Mon, 7 Dec 2009 21:40:19 +0100 (CET) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 0A90645C9C; Mon, 7 Dec 2009 21:40:12 +0100 (CET) Date: Mon, 7 Dec 2009 21:40:12 +0100 From: Pawel Jakub Dawidek To: Kurt Touet Message-ID: <20091207204012.GD1795@garage.freebsd.pl> References: <2a5e326f0912061134s79c05e75td77e6874d409c675@mail.gmail.com> <20091207191048.GB1795@garage.freebsd.pl> <2a5e326f0912071203y35d45205n4566c1bb3260166d@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ieNMXl1Fr3cevapt" Content-Disposition: inline In-Reply-To: <2a5e326f0912071203y35d45205n4566c1bb3260166d@mail.gmail.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: zpool create fails on gpart device 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, 07 Dec 2009 20:40:22 -0000 --ieNMXl1Fr3cevapt Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 07, 2009 at 02:03:09PM -0600, Kurt Touet wrote: > On Mon, Dec 7, 2009 at 1:10 PM, Pawel Jakub Dawidek wro= te: > > On Sun, Dec 06, 2009 at 01:34:13PM -0600, Kurt Touet wrote: > >> I've been interested in using a gptzfsboot setup on a few of my > >> systems, and thought I'd try it out in a VM first, but I'm blocked at > >> creating a zpool. =A0Here's what I did: > >> > >> - create a new VM with 2 drives (da0 & da1) > >> - install 8.0R amd64 > >> - install subversion from sysinstall & checkout base/head > >> - build & install -current > >> > >> Instead of creating a gptzfsboot install disc, I thought I'd just > >> create the zpool on the second drive, install things to there, and > >> then make the VM boot off the second drive afterwards (and remove the > >> first). =A0I was following the > >> http://blogs.freebsdish.org/lulf/2008/12/16/setting-up-a-zfs-only-syst= em/ > >> guide, and got to this stage: > >> > >> # gpart create -s GPT da1 > >> # gpart add -b 34 -s 128 -t freebsd-boot da1 > >> # gpart add -b 162 -s 5242880 -t freebsd-swap da1 > >> # gpart add -b 5243042 -s 57671485 -t freebsd-zfs da1 > >> # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da1 > >> > >> # gpart show da1 > >> =3D> =A0 =A0 =A034 =A062914493 =A0da1 =A0GPT =A0(30G) > >> =A0 =A0 =A0 =A0 34 =A0 =A0 =A0 128 =A0 =A01 =A0freebsd-boot =A0(64K) > >> =A0 =A0 =A0 =A0162 =A0 5242880 =A0 =A02 =A0freebsd-swap =A0(2.5G) > >> =A0 =A05243042 =A057671485 =A0 =A03 =A0freebsd-zfs =A0(27G) > >> > >> # zpool create data /dev/da1p3 > >> cannot create 'data': permission denied Ok, I guess this is HEAD, right? I think you just had bad luck. I break this here: Date: Sat Dec 5 14:24:22 2009 New Revision: 200125 And fixed here: Date: Sat Dec 5 20:16:28 2009 New Revision: 200158 It looks like you get the source from this window. Please rebuild with r200158 in place and retry. Sorry for the breakage. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --ieNMXl1Fr3cevapt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFLHWgsForvXbEpPzQRAsI9AKDql37PlIaWLR/FpJoNSkhtWrImSwCg0uMg eayiOqtEl+3MAkLvvlWdQLM= =YJJ0 -----END PGP SIGNATURE----- --ieNMXl1Fr3cevapt-- From owner-freebsd-fs@FreeBSD.ORG Mon Dec 7 20:59:06 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A10E01065696; Mon, 7 Dec 2009 20:59:06 +0000 (UTC) (envelope-from ktouet@gmail.com) Received: from mail-yw0-f194.google.com (mail-yw0-f194.google.com [209.85.211.194]) by mx1.freebsd.org (Postfix) with ESMTP id 3A87E8FC14; Mon, 7 Dec 2009 20:59:06 +0000 (UTC) Received: by ywh32 with SMTP id 32so5080100ywh.14 for ; Mon, 07 Dec 2009 12:59:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZHe6pOmhHF/kQnP1tkmCdIGQhKW/ig0uMfUOz0IcXf8=; b=Jh2FbtF9khLOb16NyWLrYlmrYVG3ZvX0o3FgcJGl6cOhsIBg3KQCIyTnVv/wyVcxPO 5Wa459gwpDrxVwCKxbH87Dkku/PwIA+UzT2ybopK1XR6fIa6t8X9KVQXNLSZau4OnLAr 0TpxyzosOHqMFZimc+eSuXY/hA3XLL/g7Kn/w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=E9ODH0+0rTpLroDhkBynFfNQR86ionDpx4r3ozaGTEhYAKp9kvHv30mzgzluldFSrh YiyrmjPU0CHUImNvgwsRhGVNCn2DUAIjB1EpkJ66iNRCc6FZL9KRTNSjvVKgswsORigN 14Bj43urzwo0bZ1HQKXJQolot53kfwIByHlWM= MIME-Version: 1.0 Received: by 10.91.21.25 with SMTP id y25mr2070745agi.66.1260219544722; Mon, 07 Dec 2009 12:59:04 -0800 (PST) In-Reply-To: <20091207204012.GD1795@garage.freebsd.pl> References: <2a5e326f0912061134s79c05e75td77e6874d409c675@mail.gmail.com> <20091207191048.GB1795@garage.freebsd.pl> <2a5e326f0912071203y35d45205n4566c1bb3260166d@mail.gmail.com> <20091207204012.GD1795@garage.freebsd.pl> Date: Mon, 7 Dec 2009 14:59:04 -0600 Message-ID: <2a5e326f0912071259g840e88ejc9951137380d9f95@mail.gmail.com> From: Kurt Touet To: Pawel Jakub Dawidek Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: zpool create fails on gpart device 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, 07 Dec 2009 20:59:06 -0000 On Mon, Dec 7, 2009 at 2:40 PM, Pawel Jakub Dawidek wrote= : > On Mon, Dec 07, 2009 at 02:03:09PM -0600, Kurt Touet wrote: >> On Mon, Dec 7, 2009 at 1:10 PM, Pawel Jakub Dawidek wr= ote: >> > On Sun, Dec 06, 2009 at 01:34:13PM -0600, Kurt Touet wrote: >> >> I've been interested in using a gptzfsboot setup on a few of my >> >> systems, and thought I'd try it out in a VM first, but I'm blocked at >> >> creating a zpool. =A0Here's what I did: >> >> >> >> - create a new VM with 2 drives (da0 & da1) >> >> - install 8.0R amd64 >> >> - install subversion from sysinstall & checkout base/head >> >> - build & install -current >> >> >> >> Instead of creating a gptzfsboot install disc, I thought I'd just >> >> create the zpool on the second drive, install things to there, and >> >> then make the VM boot off the second drive afterwards (and remove the >> >> first). =A0I was following the >> >> http://blogs.freebsdish.org/lulf/2008/12/16/setting-up-a-zfs-only-sys= tem/ >> >> guide, and got to this stage: >> >> >> >> # gpart create -s GPT da1 >> >> # gpart add -b 34 -s 128 -t freebsd-boot da1 >> >> # gpart add -b 162 -s 5242880 -t freebsd-swap da1 >> >> # gpart add -b 5243042 -s 57671485 -t freebsd-zfs da1 >> >> # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da1 >> >> >> >> # gpart show da1 >> >> =3D> =A0 =A0 =A034 =A062914493 =A0da1 =A0GPT =A0(30G) >> >> =A0 =A0 =A0 =A0 34 =A0 =A0 =A0 128 =A0 =A01 =A0freebsd-boot =A0(64K) >> >> =A0 =A0 =A0 =A0162 =A0 5242880 =A0 =A02 =A0freebsd-swap =A0(2.5G) >> >> =A0 =A05243042 =A057671485 =A0 =A03 =A0freebsd-zfs =A0(27G) >> >> >> >> # zpool create data /dev/da1p3 >> >> cannot create 'data': permission denied > > Ok, I guess this is HEAD, right? I think you just had bad luck. > > I break this here: > > =A0 =A0 =A0 =A0Date: Sat Dec =A05 14:24:22 2009 > =A0 =A0 =A0 =A0New Revision: 200125 > > And fixed here: > > =A0 =A0 =A0 =A0Date: Sat Dec =A05 20:16:28 2009 > =A0 =A0 =A0 =A0New Revision: 200158 > > It looks like you get the source from this window. > > Please rebuild with r200158 in place and retry. Sorry for the breakage. > > -- > Pawel Jakub Dawidek =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://ww= w.wheel.pl > pjd@FreeBSD.org =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http:= //www.FreeBSD.org > FreeBSD committer =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Am I Ev= il? Yes, I Am! > I think I managed to miss that -- I'm running FreeBSD 9.0-CURRENT #0 r200177 amd64. But, I will update again and see if that solves the problem. From owner-freebsd-fs@FreeBSD.ORG Mon Dec 7 21:06:50 2009 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1179710657C5; Mon, 7 Dec 2009 21:06:50 +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 C89418FC13; Mon, 7 Dec 2009 21:06:48 +0000 (UTC) Received: from kremvax.housenet.jrv (kremvax.housenet.jrv [192.168.3.124]) by mail.jrv.org (8.14.3/8.14.3) with ESMTP id nB7L6kaD089217; Mon, 7 Dec 2009 15:06:46 -0600 (CST) (envelope-from james-freebsd-fs2@jrv.org) Authentication-Results: mail.jrv.org; domainkeys=pass (testing) header.from=james-freebsd-fs2@jrv.org DomainKey-Signature: a=rsa-sha1; s=enigma; d=jrv.org; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=Fl2ZGftq+Bs9HYoLAoaQlWuP/7G8z/2GBiKHTQqWyMWikEJOXLsQ+8BPt5z0T68TR rnZKY9AtZ+XCd7DnxErQl5kdWVnJXpfkCvDtJ0L/lKdJz4RTkENU+5/jQQk+MJbIelv M6SSdzSJkWXgqmgzYoOE9KuWWYW3Ilqdd6zp4Ro= Message-ID: <4B1D6E66.4000700@jrv.org> Date: Mon, 07 Dec 2009 15:06:46 -0600 From: "James R. Van Artsdalen" User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 References: <20091205170400.GM73250@gremlin.foo.is> <8555674.871260033069220.JavaMail.root@zimbra> <20091205184112.GP73250@gremlin.foo.is> <5da0588e0912051052p25fb743ele098ed9cb9de8fa0@mail.gmail.com> <20091205190641.GQ73250@gremlin.foo.is> <20091205191526.GR73250@gremlin.foo.is> <20091206122603.GD2339@garage.freebsd.pl> In-Reply-To: <20091206122603.GD2339@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs , Pawel Jakub Dawidek Subject: Re: ZFS and reordering drives 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, 07 Dec 2009 21:06:50 -0000 Pawel Jakub Dawidek wrote: > but there was a small > bug, which I fixed yesterday, where guid wasn't checked if name matched. After looking at the change and thinking about this I think there is still a problem. Consider a pool consisting of da1, da2 and da3. Assume da2 fails hard such that it is no longer seen by the system. When the pool is imported da1 is attached by PATH since the GUID matches when zpool.cache expects. But when da2 is attached: 1. Attach by PATH & GUID fails even though there is a /dev/da2 (what was da3) the GUID does not match. 2. Attach by GUID using GEOM search fails since da2 is no longer visible and no disk has that GUID. 3. Attach by PATH falsely succeeds since the PATH exists even though the GUID is wrong. Furthermore, attempts to attach da3 fail since it was already attached above. The result, at least, might be a RAIDZ that should only DEGRADED being FAULTED instead. I don't see any way to fix this without callers specifying whether a device is being added to a pool (don't check GUID) or merely attached as part of a pool (always check GUID). From owner-freebsd-fs@FreeBSD.ORG Mon Dec 7 22:21:24 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1ABB410656A3; Mon, 7 Dec 2009 22:21:24 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-yw0-f194.google.com (mail-yw0-f194.google.com [209.85.211.194]) by mx1.freebsd.org (Postfix) with ESMTP id AD2C68FC14; Mon, 7 Dec 2009 22:21:23 +0000 (UTC) Received: by ywh32 with SMTP id 32so5161794ywh.14 for ; Mon, 07 Dec 2009 14:21:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=XRfmUT7uEEKSKWviSMJRNLKHFIOaDSQYH2dJ8cLPg6o=; b=tBqc1YneqeiruYkuUCf9hwl61NYDkcxqIJ0QNaLn6TVn+PDXi3UWjToa+1q+r680K+ mMnK27u8ls0n5tQB8ZaC8K6h4X8Qx0yk9LibO8S7b8rPHL2FhpbD0wroUx9Hw5107fSg RzpuI78voKbLU5FVtYkMKWNG0oMyZCl6CK4mU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=D4rA2R+stp8jFjxtcwqjmID/O84YdgytMVZgt2NV2Ra9mMm8hIY924MdIsbXF+MGug /Dpx3v0N4+JNYBBBntHJ4IkMoFXqaoEF4/qQPwnf23chM6++UQoISjQpGCKdZTTUra8f gGTzsokPw3RXMEgHWhnJrzoIZ9lu+J+Z5KX9I= Received: by 10.101.165.14 with SMTP id s14mr6204225ano.186.1260224483057; Mon, 07 Dec 2009 14:21:23 -0800 (PST) Received: from dimension.5p.local (ppp-22.226.dialinfree.com [209.172.22.226]) by mx.google.com with ESMTPS id 36sm2711950yxh.49.2009.12.07.14.21.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 07 Dec 2009 14:21:21 -0800 (PST) Sender: "J. Hellenthal" Date: Mon, 7 Dec 2009 17:21:07 -0500 From: jhell To: "James R. Van Artsdalen" In-Reply-To: <4B1D6E66.4000700@jrv.org> Message-ID: References: <20091205170400.GM73250@gremlin.foo.is> <8555674.871260033069220.JavaMail.root@zimbra> <20091205184112.GP73250@gremlin.foo.is> <5da0588e0912051052p25fb743ele098ed9cb9de8fa0@mail.gmail.com> <20091205190641.GQ73250@gremlin.foo.is> <20091205191526.GR73250@gremlin.foo.is> <20091206122603.GD2339@garage.freebsd.pl> <4B1D6E66.4000700@jrv.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs , Pawel Jakub Dawidek Subject: Re: ZFS and reordering drives 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, 07 Dec 2009 22:21:24 -0000 On Mon, 7 Dec 2009 16:06, james-freebsd-fs2@ wrote: > > I don't see any way to fix this without callers specifying whether a > device is being added to a pool (don't check GUID) or merely attached as > part of a pool (always check GUID). > Prevention of this should IMHO be determined by the type of device being used and method of implementation. Using daN ? devices and the characteristics of those devices could best be handled by glabel before the device is attached to a pool. Maybe there is a way that a device could still be labeled but thus allow to still use the raw device and check what the label is so if that device happens to go missing any device shifts won't effect future operations upon replacing a drive. -- Mon Dec 7 17:14:56 2009 -0500 jhell From owner-freebsd-fs@FreeBSD.ORG Tue Dec 8 00:01:04 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6ACF1065672 for ; Tue, 8 Dec 2009 00:01:04 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from mail-px0-f192.google.com (mail-px0-f192.google.com [209.85.216.192]) by mx1.freebsd.org (Postfix) with ESMTP id 9EBAE8FC19 for ; Tue, 8 Dec 2009 00:01:03 +0000 (UTC) Received: by pxi30 with SMTP id 30so2223908pxi.14 for ; Mon, 07 Dec 2009 16:01:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=6Sa9OxI+kKXPKFqRsbuSVN1dZVGXbap2JxieYh0J9kA=; b=liIbv07PZt2zTz5nwJrtaGkBtmLiOHHDG8v0XUwYE/LYj9Oq6MBiQ0C2yWOfQiv9/c 43uUbCESlLvflYvzRCMscaIvIrpVkbl+X6a0y7OHWPaOWFdSoIpRnokomAFxw7sG5U+o KjizsngZlEncjzX5s5oeKL7pMdbuibbOOFlnA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=AU9sK3XwMaxB1FDV2w7G6kVI8uEvp+a86OsZDonHCOmWOjXN7bHoz0v6GzpJkCijvj v4Ej58PZFBcMDqu7+QjsG43+oyqUyKy4QArEBWXY8AXaW/GqWf2JILGCcE3tdAzjnnAQ 9vZ5dWvosU2Qf8HiNe0v8rd1S/bf9KxEa/354= MIME-Version: 1.0 Received: by 10.143.26.32 with SMTP id d32mr805085wfj.297.1260230463367; Mon, 07 Dec 2009 16:01:03 -0800 (PST) Date: Mon, 7 Dec 2009 16:01:03 -0800 Message-ID: From: Matt Reimer To: freebsd-fs Content-Type: multipart/mixed; boundary=001636e0ac8f1aab05047a2c4518 Subject: PATCH: increase heap size for (gpt)zfsboot 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, 08 Dec 2009 00:01:04 -0000 --001636e0ac8f1aab05047a2c4518 Content-Type: text/plain; charset=ISO-8859-1 Enlarge the heap size for gptzfsboot and zfsboot. This is necessary so the ZFS code has enough memory to handle decompression and error recovery. Before this patch the heap grew from the end of the (gpt)zfsboot code and static data up to 640KB, possibly overrunning the stack. Now the heap is located at 16MB-64MB. Note that this requires machines with at least 64MB RAM, but this is not likely to be a problem on any machine running ZFS. Sponsored by: VPOP Technologies, Inc. Matt Reimer --001636e0ac8f1aab05047a2c4518 Content-Type: application/octet-stream; name="more-mem.patch" Content-Disposition: attachment; filename="more-mem.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g2xwmr700 LS0tIC9zeXMvYm9vdC9pMzg2L3pmc2Jvb3QvemZzYm9vdC5jLk9SSUcJMjAwOS0xMi0wNyAxMDoz MjoyMi4wMDAwMDAwMDAgLTA4MDAKKysrIC9zeXMvYm9vdC9pMzg2L3pmc2Jvb3QvemZzYm9vdC5j CTIwMDktMTItMDcgMTI6NDg6MDUuMDAwMDAwMDAwIC0wODAwCkBAIC0yNDEsOCArMjQxLDggQEAK IAlzdGF0aWMgY2hhciAqaGVhcF9lbmQ7CiAKIAlpZiAoIWhlYXBfbmV4dCkgewotCQloZWFwX25l eHQgPSAoY2hhciAqKSBkbWFkYXQgKyBzaXplb2YoKmRtYWRhdCk7Ci0JCWhlYXBfZW5kID0gKGNo YXIgKikgKDY0MCoxMDI0KTsKKwkJaGVhcF9uZXh0ID0gKGNoYXIgKikgKDE2ICogMTAyNCAqIDEw MjQpOworCQloZWFwX2VuZCA9IChjaGFyICopICg2NCAqIDEwMjQgKiAxMDI0KTsKIAl9CiAKIAlj aGFyICpwID0gaGVhcF9uZXh0OwotLS0gL3N5cy9ib290L3pmcy96ZnNpbXBsLmMuT1JJRwkyMDA5 LTExLTIxIDA3OjAyOjM1LjAwMDAwMDAwMCAtMDgwMAorKysgL3N5cy9ib290L3pmcy96ZnNpbXBs LmMJMjAwOS0xMi0wNyAxMjo1NDo0NC4wMDAwMDAwMDAgLTA4MDAKQEAgLTUxLDcgKzUxLDcgQEAK IHN0YXRpYyBjaGFyICp6YXBfc2NyYXRjaDsKIHN0YXRpYyBjaGFyICp6ZnNfdGVtcF9idWYsICp6 ZnNfdGVtcF9lbmQsICp6ZnNfdGVtcF9wdHI7CiAKLSNkZWZpbmUgVEVNUF9TSVpFCSgxKlNQQV9N QVhCTE9DS1NJWkUpCisjZGVmaW5lIFRFTVBfU0laRQkoMTAyNCAqIDEwMjQpCiAKIHN0YXRpYyBp bnQgemlvX3JlYWQoc3BhX3QgKnNwYSwgY29uc3QgYmxrcHRyX3QgKmJwLCB2b2lkICpidWYpOwog Cg== --001636e0ac8f1aab05047a2c4518-- From owner-freebsd-fs@FreeBSD.ORG Tue Dec 8 00:03:30 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D12E3106566C for ; Tue, 8 Dec 2009 00:03:30 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx1.freebsd.org (Postfix) with ESMTP id A8F838FC15 for ; Tue, 8 Dec 2009 00:03:30 +0000 (UTC) Received: by pwi15 with SMTP id 15so1244836pwi.3 for ; Mon, 07 Dec 2009 16:03:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=A02mO+YPeskwVcs5GUDYD7Hfs4qKkKkyinAXkNV3EFI=; b=UmD9AWzoxEEiE7JDUyRGgp7L5rP+u+ViWgCEvYd4zVZZX0XZ9Gfyg9om98V6aIFhoo FIuI9j17SaHAsenSD/o++HeIhSxl8vueGjFyi5RcVc2ftQHbWtWvPc3nqYQaxWgvCnbC R0WMpWee0bdgsSNy9Hi6laRJqlixEgDZ1Nlx0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=P2F3dNOpzF3S2ATwyhvIHE0FX0SmFih/EkgtnjRTrzjc//MSEVYrYsmKgsjZA8QepV Fix7HwtwEidwHO3XTVWHgD1hytWAwPC1OGDwUCc290dSyjXTQGDmuiEFNhBoJEd+zzIc ZZwhuyq1Wo5tTM84Vm77BehPcU0WjZf8iUkUg= MIME-Version: 1.0 Received: by 10.142.2.9 with SMTP id 9mr794827wfb.39.1260230610143; Mon, 07 Dec 2009 16:03:30 -0800 (PST) Date: Mon, 7 Dec 2009 16:03:30 -0800 Message-ID: From: Matt Reimer To: freebsd-fs Content-Type: multipart/mixed; boundary=00504502bd71da48e4047a2c4d8c Subject: PATCH: more efficient raidz memory usage for (gpt)zfsboot 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, 08 Dec 2009 00:03:30 -0000 --00504502bd71da48e4047a2c4d8c Content-Type: text/plain; charset=ISO-8859-1 Teach the (gpt)zfsboot raidz code to use its buffers more efficiently. Before this patch, in the worst case memory use would increase exponentially on the number of drives in the raidz vdev. Sponsored by: VPOP Technologies, Inc. Matt Reimer --00504502bd71da48e4047a2c4d8c Content-Type: application/octet-stream; name="raidz-mem.patch" Content-Disposition: attachment; filename="raidz-mem.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g2xwredv0 LS0tIC9zeXMvY2RkbC9ib290L3pmcy96ZnNzdWJyLmMuT1JJRwkyMDA5LTExLTE0IDA4OjE0OjUx LjAwMDAwMDAwMCAtMDgwMAorKysgL3N5cy9jZGRsL2Jvb3QvemZzL3pmc3N1YnIuYwkyMDA5LTEy LTA3IDE1OjI3OjQ5LjAwMDAwMDAwMCAtMDgwMApAQCAtNDU0LDcgKzQ1NCw3IEBACiAKIHN0YXRp YyB2b2lkCiB2ZGV2X3JhaWR6X3JlY29uc3RydWN0X3BxKHJhaWR6X2NvbF90ICpjb2xzLCBpbnQg bnBhcml0eSwgaW50IGFjb2xzLAotICAgIGludCB4LCBpbnQgeSkKKyAgICBpbnQgeCwgaW50IHks IHZvaWQgKnRlbXBfcCwgdm9pZCAqdGVtcF9xKQogewogCXVpbnQ4X3QgKnAsICpxLCAqcHh5LCAq cXh5LCAqeGQsICp5ZCwgdG1wLCBhLCBiLCBhZXhwLCBiZXhwOwogCXZvaWQgKnBkYXRhLCAqcWRh dGE7CkBAIC00NzgsMTAgKzQ3OCw4IEBACiAJeHNpemUgPSBjb2xzW3hdLnJjX3NpemU7CiAJeXNp emUgPSBjb2xzW3ldLnJjX3NpemU7CiAKLQljb2xzW1ZERVZfUkFJRFpfUF0ucmNfZGF0YSA9Ci0J CXpmc19hbGxvY190ZW1wKGNvbHNbVkRFVl9SQUlEWl9QXS5yY19zaXplKTsKLQljb2xzW1ZERVZf UkFJRFpfUV0ucmNfZGF0YSA9Ci0JCXpmc19hbGxvY190ZW1wKGNvbHNbVkRFVl9SQUlEWl9RXS5y Y19zaXplKTsKKwljb2xzW1ZERVZfUkFJRFpfUF0ucmNfZGF0YSA9IHRlbXBfcDsKKwljb2xzW1ZE RVZfUkFJRFpfUV0ucmNfZGF0YSA9IHRlbXBfcTsKIAljb2xzW3hdLnJjX3NpemUgPSAwOwogCWNv bHNbeV0ucmNfc2l6ZSA9IDA7CiAKQEAgLTU1MSw5ICs1NDksMTIgQEAKIAl1aW50NjRfdCBmID0g YiAlIGRjb2xzOwogCXVpbnQ2NF90IG8gPSAoYiAvIGRjb2xzKSA8PCB1bml0X3NoaWZ0OwogCXVp bnQ2NF90IHEsIHIsIGNvZmY7Ci0JaW50IGMsIGMxLCBiYywgY29sLCBhY29scywgZGV2aWR4LCBh c2l6ZSwgbjsKKwlpbnQgYywgYzEsIGJjLCBjb2wsIGFjb2xzLCBkZXZpZHgsIGFzaXplLCBuLCBt YXhfcmNfc2l6ZTsKIAlzdGF0aWMgcmFpZHpfY29sX3QgY29sc1sxNl07CiAJcmFpZHpfY29sX3Qg KnJjLCAqcmMxOworCXZvaWQgKm9yaWcsICpvcmlnMSwgKnRlbXBfcCwgKnRlbXBfcTsKKworCW9y aWcgPSBvcmlnMSA9IHRlbXBfcCA9IHRlbXBfcSA9IE5VTEw7CiAKIAlxID0gcyAvIChkY29scyAt IG5wYXJpdHkpOwogCXIgPSBzIC0gcSAqIChkY29scyAtIG5wYXJpdHkpOwpAQCAtNTYxLDYgKzU2 Miw3IEBACiAKIAlhY29scyA9IChxID09IDAgPyBiYyA6IGRjb2xzKTsKIAlhc2l6ZSA9IDA7CisJ bWF4X3JjX3NpemUgPSAwOwogCQogCWZvciAoYyA9IDA7IGMgPCBhY29sczsgYysrKSB7CiAJCWNv bCA9IGYgKyBjOwpAQCAtNTc3LDYgKzU3OSw4IEBACiAJCWNvbHNbY10ucmNfdHJpZWQgPSAwOwog CQljb2xzW2NdLnJjX3NraXBwZWQgPSAwOwogCQlhc2l6ZSArPSBjb2xzW2NdLnJjX3NpemU7CisJ CWlmIChjb2xzW2NdLnJjX3NpemUgPiBtYXhfcmNfc2l6ZSkKKwkJCW1heF9yY19zaXplID0gY29s c1tjXS5yY19zaXplOwogCX0KIAogCWFzaXplID0gcm91bmR1cChhc2l6ZSwgKG5wYXJpdHkgKyAx KSA8PCB1bml0X3NoaWZ0KTsKQEAgLTc3Nyw4ICs3ODEsMTMgQEAKIAkJCS8vQVNTRVJUKGMgIT0g YWNvbHMpOwogCQkJLy9BU1NFUlQoIXJjLT5yY19za2lwcGVkIHx8IHJjLT5yY19lcnJvciA9PSBF TlhJTyB8fCByYy0+cmNfZXJyb3IgPT0gRVNUQUxFKTsKIAorCQkJaWYgKCF0ZW1wX3ApCisJCQkJ dGVtcF9wID0gemZzX2FsbG9jX3RlbXAobWF4X3JjX3NpemUpOworCQkJaWYgKCF0ZW1wX3EpCisJ CQkJdGVtcF9xID0gemZzX2FsbG9jX3RlbXAobWF4X3JjX3NpemUpOworCiAJCQl2ZGV2X3JhaWR6 X3JlY29uc3RydWN0X3BxKGNvbHMsIG5wYXJpdHksIGFjb2xzLAotCQkJICAgIGMxLCBjKTsKKwkJ CSAgICBjMSwgYywgdGVtcF9wLCB0ZW1wX3EpOwogCiAJCQlpZiAoemlvX2NoZWNrc3VtX2Vycm9y KGJwLCBidWYpID09IDApCiAJCQkJcmV0dXJuICgwKTsKQEAgLTg0NSwxOCArODU0LDEyIEBACiAJ CXJldHVybiAoRUlPKTsKIAl9CiAKLQlhc2l6ZSA9IDA7Ci0JZm9yIChjID0gMDsgYyA8IGFjb2xz OyBjKyspIHsKLQkJcmMgPSAmY29sc1tjXTsKLQkJaWYgKHJjLT5yY19zaXplID4gYXNpemUpCi0J CQlhc2l6ZSA9IHJjLT5yY19zaXplOwotCX0KIAlpZiAoY29sc1tWREVWX1JBSURaX1BdLnJjX2Vy cm9yID09IDApIHsKIAkJLyoKIAkJICogQXR0ZW1wdCB0byByZWNvbnN0cnVjdCB0aGUgZGF0YSBm cm9tIHBhcml0eSBQLgogCQkgKi8KLQkJdm9pZCAqb3JpZzsKLQkJb3JpZyA9IHpmc19hbGxvY190 ZW1wKGFzaXplKTsKKwkJaWYgKCFvcmlnKQorCQkJb3JpZyA9IHpmc19hbGxvY190ZW1wKG1heF9y Y19zaXplKTsKIAkJZm9yIChjID0gbnBhcml0eTsgYyA8IGFjb2xzOyBjKyspIHsKIAkJCXJjID0g JmNvbHNbY107CiAKQEAgLTg3NCw4ICs4NzcsOCBAQAogCQkvKgogCQkgKiBBdHRlbXB0IHRvIHJl Y29uc3RydWN0IHRoZSBkYXRhIGZyb20gcGFyaXR5IFEuCiAJCSAqLwotCQl2b2lkICpvcmlnOwot CQlvcmlnID0gemZzX2FsbG9jX3RlbXAoYXNpemUpOworCQlpZiAoIW9yaWcpCisJCQlvcmlnID0g emZzX2FsbG9jX3RlbXAobWF4X3JjX3NpemUpOwogCQlmb3IgKGMgPSBucGFyaXR5OyBjIDwgYWNv bHM7IGMrKykgewogCQkJcmMgPSAmY29sc1tjXTsKIApAQCAtODk1LDkgKzg5OCwxNCBAQAogCQkv KgogCQkgKiBBdHRlbXB0IHRvIHJlY29uc3RydWN0IHRoZSBkYXRhIGZyb20gYm90aCBQIGFuZCBR LgogCQkgKi8KLQkJdm9pZCAqb3JpZywgKm9yaWcxOwotCQlvcmlnID0gemZzX2FsbG9jX3RlbXAo YXNpemUpOwotCQlvcmlnMSA9IHpmc19hbGxvY190ZW1wKGFzaXplKTsKKwkJaWYgKCFvcmlnKQor CQkJb3JpZyA9IHpmc19hbGxvY190ZW1wKG1heF9yY19zaXplKTsKKwkJaWYgKCFvcmlnMSkKKwkJ CW9yaWcxID0gemZzX2FsbG9jX3RlbXAobWF4X3JjX3NpemUpOworCQlpZiAoIXRlbXBfcCkKKwkJ CXRlbXBfcCA9IHpmc19hbGxvY190ZW1wKG1heF9yY19zaXplKTsKKwkJaWYgKCF0ZW1wX3EpCisJ CQl0ZW1wX3EgPSB6ZnNfYWxsb2NfdGVtcChtYXhfcmNfc2l6ZSk7CiAJCWZvciAoYyA9IG5wYXJp dHk7IGMgPCBhY29scyAtIDE7IGMrKykgewogCQkJcmMgPSAmY29sc1tjXTsKIApAQCAtOTA5LDcg KzkxNyw3IEBACiAJCQkJbWVtY3B5KG9yaWcxLCByYzEtPnJjX2RhdGEsIHJjMS0+cmNfc2l6ZSk7 CiAKIAkJCQl2ZGV2X3JhaWR6X3JlY29uc3RydWN0X3BxKGNvbHMsIG5wYXJpdHksCi0JCQkJICAg IGFjb2xzLCBjLCBjMSk7CisJCQkJICAgIGFjb2xzLCBjLCBjMSwgdGVtcF9wLCB0ZW1wX3EpOwog CiAJCQkJaWYgKHppb19jaGVja3N1bV9lcnJvcihicCwgYnVmKSA9PSAwKQogCQkJCQlyZXR1cm4g KDApOwo= --00504502bd71da48e4047a2c4d8c-- From owner-freebsd-fs@FreeBSD.ORG Tue Dec 8 00:08:57 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF1DD1065672 for ; Tue, 8 Dec 2009 00:08:57 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from mail-pz0-f185.google.com (mail-pz0-f185.google.com [209.85.222.185]) by mx1.freebsd.org (Postfix) with ESMTP id C662D8FC14 for ; Tue, 8 Dec 2009 00:08:57 +0000 (UTC) Received: by pzk15 with SMTP id 15so1958954pzk.3 for ; Mon, 07 Dec 2009 16:08:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=1DHUhE6ezhw8Wblc2dGYYJcSkpDk52E1cZkSknm8MF8=; b=FCGJ4Mz1KDD06wX+FQB9IFBr5WD9it8grVYaS+xQ2efPgWTDV6GzH1+C+nzvbC3u0z rMXEvOajEzx3MpIDG67+eHzOhyKly2PfporkYlS40D5lMyZkhT1l1OdXURZTztIgRs4j krAEIVAR38+HGGCf5JTCv/Ng1sPazEW9XZIWI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Ky7BBCW0lF89E0jh+ur2CKX33rMnKM8EixljLQUkEZwVydS6xAszeZQ96m16uEyJ7h 391fCZ9FZkkHX422tzH/vqHgFsG3eCOOZM25pC1RM9hLIWnMHXKtALmV1JkB9swwVXuC q2eShc/iEu3qcowJqiDB77y9SNNVBGgfG4Eak= MIME-Version: 1.0 Received: by 10.143.26.32 with SMTP id d32mr805988wfj.297.1260230937355; Mon, 07 Dec 2009 16:08:57 -0800 (PST) Date: Mon, 7 Dec 2009 16:08:57 -0800 Message-ID: From: Matt Reimer To: freebsd-fs Content-Type: multipart/mixed; boundary=001636e0ac8f5b2579047a2c611f Subject: PATCH: teach (gpt)zfsboot to discern vdev status correctly 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, 08 Dec 2009 00:08:58 -0000 --001636e0ac8f5b2579047a2c611f Content-Type: text/plain; charset=ISO-8859-1 Instead of assuming all vdevs are healthy, check the newest vdev label for each vdev's status. Booting from a degraded vdev should now be more robust. Sponsored by: VPOP Technologies, Inc. Matt Reimer (Note that much of this patch is merely whitespace change due to a block needing to be reindented.) --001636e0ac8f5b2579047a2c611f Content-Type: application/octet-stream; name="correct-status.patch" Content-Disposition: attachment; filename="correct-status.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g2xwxjhw0 LS0tIC9zeXMvY2RkbC9ib290L3pmcy96ZnNpbXBsLmguT1JJRwkyMDA5LTExLTIxIDA3OjAyOjM1 LjAwMDAwMDAwMCAtMDgwMAorKysgL3N5cy9jZGRsL2Jvb3QvemZzL3pmc2ltcGwuaAkyMDA5LTEy LTA3IDEzOjUwOjI2LjAwMDAwMDAwMCAtMDgwMApAQCAtNTQ2LDcgKzU0Niw2IEBACiAjZGVmaW5l CVpQT09MX0NPTkZJR19EVEwJCSJEVEwiCiAjZGVmaW5lCVpQT09MX0NPTkZJR19TVEFUUwkJInN0 YXRzIgogI2RlZmluZQlaUE9PTF9DT05GSUdfV0hPTEVfRElTSwkJIndob2xlX2Rpc2siCi0jZGVm aW5lCVpQT09MX0NPTkZJR19PRkZMSU5FCQkib2ZmbGluZSIKICNkZWZpbmUJWlBPT0xfQ09ORklH X0VSUkNPVU5UCQkiZXJyb3JfY291bnQiCiAjZGVmaW5lCVpQT09MX0NPTkZJR19OT1RfUFJFU0VO VAkibm90X3ByZXNlbnQiCiAjZGVmaW5lCVpQT09MX0NPTkZJR19TUEFSRVMJCSJzcGFyZXMiCkBA IC01NTYsNiArNTU1LDE2IEBACiAjZGVmaW5lCVpQT09MX0NPTkZJR19IT1NUTkFNRQkJImhvc3Ru YW1lIgogI2RlZmluZQlaUE9PTF9DT05GSUdfVElNRVNUQU1QCQkidGltZXN0YW1wIiAvKiBub3Qg c3RvcmVkIG9uIGRpc2sgKi8KIAorLyoKKyAqIFRoZSBwZXJzaXN0ZW50IHZkZXYgc3RhdGUgaXMg c3RvcmVkIGFzIHNlcGFyYXRlIHZhbHVlcyByYXRoZXIgdGhhbiBhIHNpbmdsZQorICogJ3ZkZXZf c3RhdGUnIGVudHJ5LiAgVGhpcyBpcyBiZWNhdXNlIGEgZGV2aWNlIGNhbiBiZSBpbiBtdWx0aXBs ZSBzdGF0ZXMsIHN1Y2gKKyAqIGFzIG9mZmxpbmUgYW5kIGRlZ3JhZGVkLgorICovCisjZGVmaW5l IFpQT09MX0NPTkZJR19PRkZMSU5FICAgICAgICAgICAgIm9mZmxpbmUiCisjZGVmaW5lIFpQT09M X0NPTkZJR19GQVVMVEVEICAgICAgICAgICAgImZhdWx0ZWQiCisjZGVmaW5lIFpQT09MX0NPTkZJ R19ERUdSQURFRCAgICAgICAgICAgImRlZ3JhZGVkIgorI2RlZmluZSBaUE9PTF9DT05GSUdfUkVN T1ZFRCAgICAgICAgICAgICJyZW1vdmVkIgorCiAjZGVmaW5lCVZERVZfVFlQRV9ST09UCQkJInJv b3QiCiAjZGVmaW5lCVZERVZfVFlQRV9NSVJST1IJCSJtaXJyb3IiCiAjZGVmaW5lCVZERVZfVFlQ RV9SRVBMQUNJTkcJCSJyZXBsYWNpbmciCkBAIC01ODgsNyArNTk3LDkgQEAKIAlWREVWX1NUQVRF X1VOS05PV04gPSAwLAkvKiBVbmluaXRpYWxpemVkIHZkZXYJCQkqLwogCVZERVZfU1RBVEVfQ0xP U0VELAkvKiBOb3QgY3VycmVudGx5IG9wZW4JCQkqLwogCVZERVZfU1RBVEVfT0ZGTElORSwJLyog Tm90IGFsbG93ZWQgdG8gb3BlbgkJCSovCisgICAgICAgIFZERVZfU1RBVEVfUkVNT1ZFRCwJLyog RXhwbGljaXRseSByZW1vdmVkIGZyb20gc3lzdGVtCSovCiAJVkRFVl9TVEFURV9DQU5UX09QRU4s CS8qIFRyaWVkIHRvIG9wZW4sIGJ1dCBmYWlsZWQJCSovCisgICAgICAgIFZERVZfU1RBVEVfRkFV TFRFRCwJLyogRXh0ZXJuYWwgcmVxdWVzdCB0byBmYXVsdCBkZXZpY2UJKi8KIAlWREVWX1NUQVRF X0RFR1JBREVELAkvKiBSZXBsaWNhdGVkIHZkZXYgd2l0aCB1bmhlYWx0aHkga2lkcwkqLwogCVZE RVZfU1RBVEVfSEVBTFRIWQkvKiBQcmVzdW1lZCBnb29kCQkJKi8KIH0gdmRldl9zdGF0ZV90Owot LS0gL3N5cy9ib290L3pmcy96ZnNpbXBsLmMuT1JJRwkyMDA5LTExLTIxIDA3OjAyOjM1LjAwMDAw MDAwMCAtMDgwMAorKysgL3N5cy9ib290L3pmcy96ZnNpbXBsLmMJMjAwOS0xMi0wNyAxNDozNjoy MC4wMDAwMDAwMDAgLTA4MDAKQEAgLTQwNCw3ICs0MDQsNyBAQAogfQogCiBzdGF0aWMgaW50Ci12 ZGV2X2luaXRfZnJvbV9udmxpc3QoY29uc3QgdW5zaWduZWQgY2hhciAqbnZsaXN0LCB2ZGV2X3Qg Kip2ZGV2cCkKK3ZkZXZfaW5pdF9mcm9tX252bGlzdChjb25zdCB1bnNpZ25lZCBjaGFyICpudmxp c3QsIHZkZXZfdCAqKnZkZXZwLCBpbnQgaXNfbmV3ZXIpCiB7CiAJaW50IHJjOwogCXVpbnQ2NF90 IGd1aWQsIGlkLCBhc2hpZnQsIG5wYXJpdHk7CkBAIC00MTIsNyArNDEyLDggQEAKIAljb25zdCBj aGFyICpwYXRoOwogCXZkZXZfdCAqdmRldiwgKmtpZDsKIAljb25zdCB1bnNpZ25lZCBjaGFyICpr aWRzOwotCWludCBua2lkcywgaTsKKwlpbnQgbmtpZHMsIGksIGlzX25ldzsKKwl1aW50NjRfdCBp c19vZmZsaW5lLCBpc19mYXVsdGVkLCBpc19kZWdyYWRlZCwgaXNfcmVtb3ZlZDsKIAogCWlmIChu dmxpc3RfZmluZChudmxpc3QsIFpQT09MX0NPTkZJR19HVUlELAogCQkJREFUQV9UWVBFX1VJTlQ2 NCwgMCwgJmd1aWQpCkBAIC00MjQsMTcgKzQyNSw2IEBACiAJCXJldHVybiAoRU5PRU5UKTsKIAl9 CiAKLQkvKgotCSAqIEFzc3VtZSB0aGF0IGlmIHdlJ3ZlIHNlZW4gdGhpcyB2ZGV2IHRyZWUgYmVm b3JlLCB0aGlzIG9uZQotCSAqIHdpbGwgYmUgaWRlbnRpY2FsLgotCSAqLwotCXZkZXYgPSB2ZGV2 X2ZpbmQoZ3VpZCk7Ci0JaWYgKHZkZXYpIHsKLQkJaWYgKHZkZXZwKQotCQkJKnZkZXZwID0gdmRl djsKLQkJcmV0dXJuICgwKTsKLQl9Ci0KIAlpZiAoc3RyY21wKHR5cGUsIFZERVZfVFlQRV9NSVJS T1IpCiAJICAgICYmIHN0cmNtcCh0eXBlLCBWREVWX1RZUEVfRElTSykKIAkgICAgJiYgc3RyY21w KHR5cGUsIFZERVZfVFlQRV9SQUlEWikpIHsKQEAgLTQ0Miw0NCArNDMyLDk1IEBACiAJCXJldHVy biAoRUlPKTsKIAl9CiAKLQlpZiAoIXN0cmNtcCh0eXBlLCBWREVWX1RZUEVfTUlSUk9SKSkKLQkJ dmRldiA9IHZkZXZfY3JlYXRlKGd1aWQsIHZkZXZfbWlycm9yX3JlYWQpOwotCWVsc2UgaWYgKCFz dHJjbXAodHlwZSwgVkRFVl9UWVBFX1JBSURaKSkKLQkJdmRldiA9IHZkZXZfY3JlYXRlKGd1aWQs IHZkZXZfcmFpZHpfcmVhZCk7Ci0JZWxzZQotCQl2ZGV2ID0gdmRldl9jcmVhdGUoZ3VpZCwgdmRl dl9kaXNrX3JlYWQpOworCWlzX29mZmxpbmUgPSBpc19yZW1vdmVkID0gaXNfZmF1bHRlZCA9IGlz X2RlZ3JhZGVkID0gMDsKKworCW52bGlzdF9maW5kKG52bGlzdCwgWlBPT0xfQ09ORklHX09GRkxJ TkUsIERBVEFfVFlQRV9VSU5UNjQsIDAsCisJCQkmaXNfb2ZmbGluZSk7CisJbnZsaXN0X2ZpbmQo bnZsaXN0LCBaUE9PTF9DT05GSUdfUkVNT1ZFRCwgREFUQV9UWVBFX1VJTlQ2NCwgMCwKKwkJCSZp c19yZW1vdmVkKTsKKwludmxpc3RfZmluZChudmxpc3QsIFpQT09MX0NPTkZJR19GQVVMVEVELCBE QVRBX1RZUEVfVUlOVDY0LCAwLAorCQkJJmlzX2ZhdWx0ZWQpOworCW52bGlzdF9maW5kKG52bGlz dCwgWlBPT0xfQ09ORklHX0RFR1JBREVELCBEQVRBX1RZUEVfVUlOVDY0LCAwLAorCQkJJmlzX2Rl Z3JhZGVkKTsKKworCXZkZXYgPSB2ZGV2X2ZpbmQoZ3VpZCk7CisJaWYgKCF2ZGV2KSB7CisKKwkJ aXNfbmV3ID0gMTsKKworCQlpZiAoIXN0cmNtcCh0eXBlLCBWREVWX1RZUEVfTUlSUk9SKSkKKwkJ CXZkZXYgPSB2ZGV2X2NyZWF0ZShndWlkLCB2ZGV2X21pcnJvcl9yZWFkKTsKKwkJZWxzZSBpZiAo IXN0cmNtcCh0eXBlLCBWREVWX1RZUEVfUkFJRFopKQorCQkJdmRldiA9IHZkZXZfY3JlYXRlKGd1 aWQsIHZkZXZfcmFpZHpfcmVhZCk7CisJCWVsc2UKKwkJCXZkZXYgPSB2ZGV2X2NyZWF0ZShndWlk LCB2ZGV2X2Rpc2tfcmVhZCk7CisKKwkJdmRldi0+dl9pZCA9IGlkOworCQlpZiAobnZsaXN0X2Zp bmQobnZsaXN0LCBaUE9PTF9DT05GSUdfQVNISUZULAorCQkJREFUQV9UWVBFX1VJTlQ2NCwgMCwg JmFzaGlmdCkgPT0gMCkKKwkJCXZkZXYtPnZfYXNoaWZ0ID0gYXNoaWZ0OworCQllbHNlCisJCQl2 ZGV2LT52X2FzaGlmdCA9IDA7CisJCWlmIChudmxpc3RfZmluZChudmxpc3QsIFpQT09MX0NPTkZJ R19OUEFSSVRZLAorCQkJREFUQV9UWVBFX1VJTlQ2NCwgMCwgJm5wYXJpdHkpID09IDApCisJCQl2 ZGV2LT52X25wYXJpdHkgPSBucGFyaXR5OworCQllbHNlCisJCQl2ZGV2LT52X25wYXJpdHkgPSAw OworCQlpZiAobnZsaXN0X2ZpbmQobnZsaXN0LCBaUE9PTF9DT05GSUdfUEFUSCwKKwkJCQlEQVRB X1RZUEVfU1RSSU5HLCAwLCAmcGF0aCkgPT0gMCkgeworCQkJaWYgKHN0cmxlbihwYXRoKSA+IDUK KwkJCSAgICAmJiBwYXRoWzBdID09ICcvJworCQkJICAgICYmIHBhdGhbMV0gPT0gJ2QnCisJCQkg ICAgJiYgcGF0aFsyXSA9PSAnZScKKwkJCSAgICAmJiBwYXRoWzNdID09ICd2JworCQkJICAgICYm IHBhdGhbNF0gPT0gJy8nKQorCQkJCXBhdGggKz0gNTsKKwkJCXZkZXYtPnZfbmFtZSA9IHN0cmR1 cChwYXRoKTsKKwkJfSBlbHNlIHsKKwkJCWlmICghc3RyY21wKHR5cGUsICJyYWlkeiIpKSB7CisJ CQkJaWYgKHZkZXYtPnZfbnBhcml0eSA9PSAxKQorCQkJCQl2ZGV2LT52X25hbWUgPSAicmFpZHox IjsKKwkJCQllbHNlCisJCQkJCXZkZXYtPnZfbmFtZSA9ICJyYWlkejIiOworCQkJfSBlbHNlIHsK KwkJCQl2ZGV2LT52X25hbWUgPSBzdHJkdXAodHlwZSk7CisJCQl9CisJCX0KKworCQlpZiAoaXNf b2ZmbGluZSkKKwkJCXZkZXYtPnZfc3RhdGUgPSBWREVWX1NUQVRFX09GRkxJTkU7CisJCWVsc2Ug aWYgKGlzX3JlbW92ZWQpCisJCQl2ZGV2LT52X3N0YXRlID0gVkRFVl9TVEFURV9SRU1PVkVEOwor CQllbHNlIGlmIChpc19mYXVsdGVkKQorCQkJdmRldi0+dl9zdGF0ZSA9IFZERVZfU1RBVEVfRkFV TFRFRDsKKwkJZWxzZSBpZiAoaXNfZGVncmFkZWQpCisJCQl2ZGV2LT52X3N0YXRlID0gVkRFVl9T VEFURV9ERUdSQURFRDsKKwkJZWxzZQorCQkJdmRldi0+dl9zdGF0ZSA9IFZERVZfU1RBVEVfSEVB TFRIWTsKIAotCXZkZXYtPnZfaWQgPSBpZDsKLQlpZiAobnZsaXN0X2ZpbmQobnZsaXN0LCBaUE9P TF9DT05GSUdfQVNISUZULAotCQlEQVRBX1RZUEVfVUlOVDY0LCAwLCAmYXNoaWZ0KSA9PSAwKQot CQl2ZGV2LT52X2FzaGlmdCA9IGFzaGlmdDsKLQllbHNlCi0JCXZkZXYtPnZfYXNoaWZ0ID0gMDsK LQlpZiAobnZsaXN0X2ZpbmQobnZsaXN0LCBaUE9PTF9DT05GSUdfTlBBUklUWSwKLQkJREFUQV9U WVBFX1VJTlQ2NCwgMCwgJm5wYXJpdHkpID09IDApCi0JCXZkZXYtPnZfbnBhcml0eSA9IG5wYXJp dHk7Ci0JZWxzZQotCQl2ZGV2LT52X25wYXJpdHkgPSAwOwotCWlmIChudmxpc3RfZmluZChudmxp c3QsIFpQT09MX0NPTkZJR19QQVRILAotCQkJREFUQV9UWVBFX1NUUklORywgMCwgJnBhdGgpID09 IDApIHsKLQkJaWYgKHN0cmxlbihwYXRoKSA+IDUKLQkJICAgICYmIHBhdGhbMF0gPT0gJy8nCi0J CSAgICAmJiBwYXRoWzFdID09ICdkJwotCQkgICAgJiYgcGF0aFsyXSA9PSAnZScKLQkJICAgICYm IHBhdGhbM10gPT0gJ3YnCi0JCSAgICAmJiBwYXRoWzRdID09ICcvJykKLQkJCXBhdGggKz0gNTsK LQkJdmRldi0+dl9uYW1lID0gc3RyZHVwKHBhdGgpOwogCX0gZWxzZSB7Ci0JCWlmICghc3RyY21w KHR5cGUsICJyYWlkeiIpKSB7Ci0JCQlpZiAodmRldi0+dl9ucGFyaXR5ID09IDEpCi0JCQkJdmRl di0+dl9uYW1lID0gInJhaWR6MSI7CisKKwkJaXNfbmV3ID0gMDsKKworCQlpZiAoaXNfbmV3ZXIp IHsKKworCQkJLyogV2UndmUgYWxyZWFkeSBzZWVuIHRoaXMgdmRldiwgYnV0IGZyb20gYW4gb2xk ZXIKKwkJCSAqIHZkZXYgbGFiZWwsIHNvIGxldCdzIHJlZnJlc2ggaXRzIHN0YXRlIGZyb20gdGhl CisJCQkgKiBuZXdlciBsYWJlbC4gKi8KKworCQkJaWYgKGlzX29mZmxpbmUpCisJCQkJdmRldi0+ dl9zdGF0ZSA9IFZERVZfU1RBVEVfT0ZGTElORTsKKwkJCWVsc2UgaWYgKGlzX3JlbW92ZWQpCisJ CQkJdmRldi0+dl9zdGF0ZSA9IFZERVZfU1RBVEVfUkVNT1ZFRDsKKwkJCWVsc2UgaWYgKGlzX2Zh dWx0ZWQpCisJCQkJdmRldi0+dl9zdGF0ZSA9IFZERVZfU1RBVEVfRkFVTFRFRDsKKwkJCWVsc2Ug aWYgKGlzX2RlZ3JhZGVkKQorCQkJCXZkZXYtPnZfc3RhdGUgPSBWREVWX1NUQVRFX0RFR1JBREVE OwogCQkJZWxzZQotCQkJCXZkZXYtPnZfbmFtZSA9ICJyYWlkejIiOwotCQl9IGVsc2UgewotCQkJ dmRldi0+dl9uYW1lID0gc3RyZHVwKHR5cGUpOworCQkJCXZkZXYtPnZfc3RhdGUgPSBWREVWX1NU QVRFX0hFQUxUSFk7CiAJCX0KIAl9CisKIAlyYyA9IG52bGlzdF9maW5kKG52bGlzdCwgWlBPT0xf Q09ORklHX0NISUxEUkVOLAogCQkJIERBVEFfVFlQRV9OVkxJU1RfQVJSQVksICZua2lkcywgJmtp ZHMpOwogCS8qCkBAIC00ODgsMTAgKzUyOSwxMiBAQAogCWlmIChyYyA9PSAwKSB7CiAJCXZkZXYt PnZfbmNoaWxkcmVuID0gbmtpZHM7CiAJCWZvciAoaSA9IDA7IGkgPCBua2lkczsgaSsrKSB7Ci0J CQlyYyA9IHZkZXZfaW5pdF9mcm9tX252bGlzdChraWRzLCAma2lkKTsKKwkJCXJjID0gdmRldl9p bml0X2Zyb21fbnZsaXN0KGtpZHMsICZraWQsIGlzX25ld2VyKTsKIAkJCWlmIChyYykKIAkJCQly ZXR1cm4gKHJjKTsKLQkJCVNUQUlMUV9JTlNFUlRfVEFJTCgmdmRldi0+dl9jaGlsZHJlbiwga2lk LCB2X2NoaWxkbGluayk7CisJCQlpZiAoaXNfbmV3KQorCQkJCVNUQUlMUV9JTlNFUlRfVEFJTCgm dmRldi0+dl9jaGlsZHJlbiwga2lkLAorCQkJCQkJICAgdl9jaGlsZGxpbmspOwogCQkJa2lkcyA9 IG52bGlzdF9uZXh0KGtpZHMpOwogCQl9CiAJfSBlbHNlIHsKQEAgLTU5Myw3ICs2MzYsOSBAQAog CQkiVU5LTk9XTiIsCiAJCSJDTE9TRUQiLAogCQkiT0ZGTElORSIsCisJCSJSRU1PVkVEIiwKIAkJ IkNBTlRfT1BFTiIsCisJCSJGQVVMVEVEIiwKIAkJIkRFR1JBREVEIiwKIAkJIk9OTElORSIKIAl9 OwpAQCAtNzExLDcgKzc1Niw3IEBACiAJdWludDY0X3QgcG9vbF90eGcsIHBvb2xfZ3VpZDsKIAlj b25zdCBjaGFyICpwb29sX25hbWU7CiAJY29uc3QgdW5zaWduZWQgY2hhciAqdmRldnM7Ci0JaW50 IGksIHJjOworCWludCBpLCByYywgaXNfbmV3ZXI7CiAJY2hhciB1cGJ1ZlsxMDI0XTsKIAljb25z dCBzdHJ1Y3QgdWJlcmJsb2NrICp1cDsKIApAQCAtNzkzLDEyICs4MzgsMTUgQEAKIAkJc3BhID0g c3BhX2NyZWF0ZShwb29sX2d1aWQpOwogCQlzcGEtPnNwYV9uYW1lID0gc3RyZHVwKHBvb2xfbmFt ZSk7CiAJfQotCWlmIChwb29sX3R4ZyA+IHNwYS0+c3BhX3R4ZykKKwlpZiAocG9vbF90eGcgPiBz cGEtPnNwYV90eGcpIHsKIAkJc3BhLT5zcGFfdHhnID0gcG9vbF90eGc7CisJCWlzX25ld2VyID0g MTsKKwl9IGVsc2UKKwkJaXNfbmV3ZXIgPSAwOwogCiAJLyoKIAkgKiBHZXQgdGhlIHZkZXYgdHJl ZSBhbmQgY3JlYXRlIG91ciBpbi1jb3JlIGNvcHkgb2YgaXQuCi0JICogSWYgd2UgYWxyZWFkeSBo YXZlIGEgaGVhbHRoeSB2ZGV2IHdpdGggdGhpcyBndWlkLCB0aGlzIG11c3QKKwkgKiBJZiB3ZSBh bHJlYWR5IGhhdmUgYSB2ZGV2IHdpdGggdGhpcyBndWlkLCB0aGlzIG11c3QKIAkgKiBiZSBzb21l IGtpbmQgb2YgYWxpYXMgKG92ZXJsYXBwaW5nIHNsaWNlcywgZGFuZ2Vyb3VzbHkgZGVkaWNhdGVk CiAJICogZGlza3MgZXRjKS4KIAkgKi8KQEAgLTgwOCwxNiArODU2LDE2IEBACiAJCXJldHVybiAo RUlPKTsKIAl9CiAJdmRldiA9IHZkZXZfZmluZChndWlkKTsKLQlpZiAodmRldiAmJiB2ZGV2LT52 X3N0YXRlID09IFZERVZfU1RBVEVfSEVBTFRIWSkgeworCWlmICh2ZGV2ICYmIHZkZXYtPnZfcGh5 c19yZWFkKQkvKiBIYXMgdGhpcyB2ZGV2IGFscmVhZHkgYmVlbiBpbml0ZWQ/ICovCiAJCXJldHVy biAoRUlPKTsKLQl9CiAKIAlpZiAobnZsaXN0X2ZpbmQobnZsaXN0LAogCQkJWlBPT0xfQ09ORklH X1ZERVZfVFJFRSwKIAkJCURBVEFfVFlQRV9OVkxJU1QsIDAsICZ2ZGV2cykpIHsKIAkJcmV0dXJu IChFSU8pOwogCX0KLQlyYyA9IHZkZXZfaW5pdF9mcm9tX252bGlzdCh2ZGV2cywgJnRvcF92ZGV2 KTsKKworCXJjID0gdmRldl9pbml0X2Zyb21fbnZsaXN0KHZkZXZzLCAmdG9wX3ZkZXYsIGlzX25l d2VyKTsKIAlpZiAocmMpCiAJCXJldHVybiAocmMpOwogCkBAIC04MzgsNyArODg2LDYgQEAKIAlp ZiAodmRldikgewogCQl2ZGV2LT52X3BoeXNfcmVhZCA9IHJlYWQ7CiAJCXZkZXYtPnZfcmVhZF9w cml2ID0gcmVhZF9wcml2OwotCQl2ZGV2LT52X3N0YXRlID0gVkRFVl9TVEFURV9IRUFMVEhZOwog CX0gZWxzZSB7CiAJCXByaW50ZigiWkZTOiBpbmNvbnNpc3RlbnQgbnZsaXN0IGNvbnRlbnRzXG4i KTsKIAkJcmV0dXJuIChFSU8pOwo= --001636e0ac8f5b2579047a2c611f-- From owner-freebsd-fs@FreeBSD.ORG Tue Dec 8 00:23:26 2009 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 C92C71065693 for ; Tue, 8 Dec 2009 00:23:26 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx1.freebsd.org (Postfix) with ESMTP id A26FB8FC15 for ; Tue, 8 Dec 2009 00:23:26 +0000 (UTC) Received: by pwi15 with SMTP id 15so1255248pwi.3 for ; Mon, 07 Dec 2009 16:23:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=cf83HbYaYLKQROmAPLKjtfGt+a/ZCCjA/lp6wsTV/yc=; b=VIQdYWHf1eAkuH4I4YUil1BXvOCXapY0Bh3JuUcNDaDzwb6VS2fQu5JmZ3iAlopWeK wpPJnS1ZyrHZ4H3C8HqCKH65E16g1zpyi+dsgXwN0vCwE0IkIKNnGxIb/KDxc7mCoLui 1rA21AB3Vh8C/rBUFDvriGaVfpqYgakUC7TQQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=GbpDat9O6RlzXigiu4oEJngo5QENQMNPhxMWcS5V6NUJso2myNPEz1ynG+dm5smJEt 6HVWbpGwXVYnT9MKJausQj9jUT40oIVydv8DZP7pvMYmxounhEtcjHbyVpCOWIDFsUgj P0CMx7Dow+dhvdR20DUGKnViQ14d+ebAjnA/Q= MIME-Version: 1.0 Received: by 10.142.56.11 with SMTP id e11mr887631wfa.118.1260231806156; Mon, 07 Dec 2009 16:23:26 -0800 (PST) In-Reply-To: References: Date: Mon, 7 Dec 2009 16:23:26 -0800 Message-ID: From: Matt Reimer To: fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: Current gptzfsboot limitations X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 00:23:26 -0000 On Fri, Nov 20, 2009 at 4:46 PM, Matt Reimer wrote: > I've been analyzing gptzfsboot to see what its limitations are. I > think it should now work fine for a healthy pool with any number of > disks, with any type of vdev, whether single disk, stripe, mirror, > raidz or raidz2. > > But there are currently several limitations (likely in loader.zfs > too), mostly due to the limited amount of memory available (< 640KB) > and the simple memory allocators used (a simple malloc() and > zfs_alloc_temp()). With some help from John Baldwin I've been able to fix these limitations. I've posted three patches to fs@. I've successfully booted from a degraded raidz2 pool, with a drive offline, and also with single and double errors in a given block. > 1. gptzfsboot might fail to read compressed files on raidz/raidz2 > pools. The reason is that the temporary buffer used for I/O > (zfs_temp_buf in zfsimpl.c) is 128KB by default, but a 128KB > compressed block will require a 128KB buffer to be allocated before > the I/O is done, leaving nothing for the raidz code further on. The > fix would be to make more the temporary buffer larger, but for some > reason it's not as simple as just changing the TEMP_SIZE define > (possibly a stack overflow results; more debugging needed). > Workaround: don't enable compression on your root filesystem (aka > bootfs). The heap size has been increased from something around 400KB or so to 48M, and the ZFS temp buffer has been increased from 128KB to 1MB. I think 1MB should be enough for the worst case scenario where compression is enabled and two child vdevs in a raidz2 vdev are offline. > 2. gptzfsboot might fail to reconstruct a file that is read from a > degraded raidz/raidz2 pool, or if the file is corrupt somehow (i.e. > the pool is healthy but the checksums don't match). The reason again > is that the temporary buffer gets exhausted. I think this will only > happen in the case where more than one physical block is corrupt or > unreadable. The fix has several aspects: 1) make the temporary buffer > much larger, perhaps larger than 640KB; 2) change > zfssubr.c:vdev_raidz_read() to reuse the temp buffers it allocates > when possible; and 3) either restructure > zfssubr.c:vdev_raidz_reconstruct_pq() to only allocate its temporary > buffers once per I/O, or use a malloc that has free() implemented. > Workaround: repair your pool somehow (e.g. pxeboot) so one or no disks > are bad. This is fixed by the increased heap size and temp buffer size, and also by tweaking the raidz code a bit to reuse its temp buffers. Before temp buffer usage could grow exponentially on the number of drives in the raidz vdev, but now it uses at most 4x the size of the largest column's I/O. For example, if a 128KB raidz2 block is broken down into 4 * 32KB + 2 * 32KB parity, then the largest column I/O size is 32KB and the max memory use is 4 * 32KB. > 3. gptzfsboot might fail to boot from a degraded pool that has one or > more drives marked offline, removed, or faulted. The reason is that > vdev_probe() assumes that all vdevs are healthy, regardless of their > true state. gptzfsboot then will read from an offline/removed/faulted > vdev as if it were healthy, likely resulting in failed checksums, > resulting in the recovery code path being run in vdev_raidz_read(), > possibly leading to zfs_temp_buf exhaustion as in #2 above. This is fixed by getting each drive's status from the newest vdev label, rather than assuming all are healthy. > I think I've also hit a stack overflow a couple of times while debugging. Actually what was happening was that the heap was overrunning the stack. I fixed this by moving the heap to the range 16M-64M. Now the stack has much more room to grow. If these three patches are acceptable, can someone commit them and MFC? Matt From owner-freebsd-fs@FreeBSD.ORG Tue Dec 8 03:01:12 2009 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51BE8106568B; Tue, 8 Dec 2009 03:01:12 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2772A8FC14; Tue, 8 Dec 2009 03:01:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nB831COB003134; Tue, 8 Dec 2009 03:01:12 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nB831BW2003121; Tue, 8 Dec 2009 03:01:12 GMT (envelope-from linimon) Date: Tue, 8 Dec 2009 03:01:12 GMT Message-Id: <200912080301.nB831BW2003121@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/141257: [gvinum] No puedo crear RAID5 por SW con gvinum 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, 08 Dec 2009 03:01:12 -0000 Old Synopsis: No puedo crear RAID5 por SW con gvinum New Synopsis: [gvinum] No puedo crear RAID5 por SW con gvinum Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Tue Dec 8 02:59:35 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=141257 From owner-freebsd-fs@FreeBSD.ORG Tue Dec 8 05:01:23 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B0321065672 for ; Tue, 8 Dec 2009 05:01:23 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from mail-pz0-f185.google.com (mail-pz0-f185.google.com [209.85.222.185]) by mx1.freebsd.org (Postfix) with ESMTP id D70CB8FC13 for ; Tue, 8 Dec 2009 05:01:22 +0000 (UTC) Received: by pzk15 with SMTP id 15so2110701pzk.3 for ; Mon, 07 Dec 2009 21:01:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=aFw3TYMtc40Ftv3iUCkTmnGfVYDNByoR9QlPkbP9wcs=; b=Hu4WC4NOuZres78Lk2rdmoFbRqnEIMVWufjgOtaiLj7GDEHhXxGGj0y6BFd7kmhxAV EY0UVaUGR8Tq4S/fqErIAk2upMvWiIrJrLMW2JqZxM6o1f92fnw5iPunyEB3qlkPlZwD DjBDYCsBhXJ4MIQ5V0GlEI1rBuZ40y2fcgrME= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=k24SN4eUHMZLcWVtGgl9W4AAm+BRfq3AgYlOtFAGPwY7NLxMz5CYyUf9YgVikhwj0K StJ6ACGwldZx73NQJemt+L3m7omRHujFGdzAvsdD6Z4p+XL0TCH0HUHfHfHSSpR51Ato o6m1HV6pN+peR/+1ognPrvUjStF3QaxeqUH3o= MIME-Version: 1.0 Received: by 10.142.7.2 with SMTP id 2mr882512wfg.104.1260248482081; Mon, 07 Dec 2009 21:01:22 -0800 (PST) In-Reply-To: References: Date: Mon, 7 Dec 2009 21:01:22 -0800 Message-ID: From: Matt Reimer To: freebsd-fs Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: PATCH: increase heap size for (gpt)zfsboot 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, 08 Dec 2009 05:01:23 -0000 On Mon, Dec 7, 2009 at 4:01 PM, Matt Reimer wrote: > Enlarge the heap size for gptzfsboot and zfsboot. This is necessary so > the ZFS code has enough memory to handle decompression and error > recovery. While this patch doesn't affect zfsloader's heap size, it does change its ZFS temp buffer size from 128K to 1MB, with the same effect of making it possible to handle compression and error recovery. Matt From owner-freebsd-fs@FreeBSD.ORG Tue Dec 8 05:01:54 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29C30106566B for ; Tue, 8 Dec 2009 05:01:54 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx1.freebsd.org (Postfix) with ESMTP id 01DEB8FC0A for ; Tue, 8 Dec 2009 05:01:53 +0000 (UTC) Received: by pwi15 with SMTP id 15so1395307pwi.3 for ; Mon, 07 Dec 2009 21:01:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=X2uZQSDEpX3QjDFxrDOUI4UMvPciEgmF8h4O91EDEkg=; b=tWdEU7HV7SOExwkhx2G7HRvX9Bf7plvAkdDf7FExnfRy+yGtixydDry8ipdDmb7U5w ifTRkCdLyC+/rs0/ftynRm0A3QCpvJoBNc6HbT/Ryz91tVhEckwVGw1Xx7sZ1HwdLiNV 8JywBch0KBUEv0hfWbTecfGm1YMUexXYFXKRc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=SEDJjRWk3sa2vXrcQNFaOQxs/5KZ+xMKTADr4NyxajmiNU6k0uaj6oGe/TDQ3+aIkP j6MTG92aAGa6hv6Fk3xPiLhqbPWPvtN9yiuDRnWCeDeAES/vwG5Q1kwQcAFvTmhwfh0z AYlWf74aUQs94ZIeo62UbtE3+Clse9VI8HHHQ= MIME-Version: 1.0 Received: by 10.142.1.41 with SMTP id 41mr871993wfa.26.1260248513421; Mon, 07 Dec 2009 21:01:53 -0800 (PST) In-Reply-To: References: Date: Mon, 7 Dec 2009 21:01:53 -0800 Message-ID: From: Matt Reimer To: freebsd-fs Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: PATCH: more efficient raidz memory usage for (gpt)zfsboot 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, 08 Dec 2009 05:01:54 -0000 On Mon, Dec 7, 2009 at 4:03 PM, Matt Reimer wrote: > Teach the (gpt)zfsboot raidz code to use its buffers more efficiently. And zfsloader. Matt From owner-freebsd-fs@FreeBSD.ORG Tue Dec 8 05:02:46 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 814B01065670 for ; Tue, 8 Dec 2009 05:02:46 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from mail-pz0-f185.google.com (mail-pz0-f185.google.com [209.85.222.185]) by mx1.freebsd.org (Postfix) with ESMTP id 58DC68FC08 for ; Tue, 8 Dec 2009 05:02:46 +0000 (UTC) Received: by pzk15 with SMTP id 15so2111437pzk.3 for ; Mon, 07 Dec 2009 21:02:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=G+HgWaKJmJPMEZrjq0lpEJwsy2ZZLptKaDyfMR8I4Hg=; b=UWCd6PMANhPqrUmIwT9LlwF7cCoovsOaLn2VflX0cgAwTIKzr9aWiEY4Q7DxS3K7dh K+UoX5/V2dDe4gAe5mQIOPm3aR3WUifOd83vV33wMDDqzEezj1rWmCNyURmuMtFSTwc4 vWo0nPaIF8dDZNgfo5D7eY4ciR6+wgJ+TYytk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=t/kpvjUnemyN43jVioDzp3cXpZIaQ+i3cLZS+oIhaIZkZvMbnZNd0pBDxkDqUKt6Mr FrauMIigl5MPstV8QTyqQ24dO8q75ifL8bIKlEmzXXu9qssCB1MbLJUQxH63V4bi0yug mK4bUb8D/wj86eyH/dVVxlQCNJLgDoXWNHMUA= MIME-Version: 1.0 Received: by 10.142.1.22 with SMTP id 22mr44458wfa.303.1260248565929; Mon, 07 Dec 2009 21:02:45 -0800 (PST) In-Reply-To: References: Date: Mon, 7 Dec 2009 21:02:45 -0800 Message-ID: From: Matt Reimer To: freebsd-fs Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: PATCH: teach (gpt)zfsboot to discern vdev status correctly 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, 08 Dec 2009 05:02:46 -0000 On Mon, Dec 7, 2009 at 4:08 PM, Matt Reimer wrote: > Instead of assuming all vdevs are healthy, check the newest vdev label > for each vdev's status. Booting from a degraded vdev should now be > more robust. This is also applicable to zfsloader. Matt From owner-freebsd-fs@FreeBSD.ORG Tue Dec 8 05:06:20 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F2E6106566C; Tue, 8 Dec 2009 05:06:20 +0000 (UTC) (envelope-from ktouet@gmail.com) Received: from mail-gx0-f218.google.com (mail-gx0-f218.google.com [209.85.217.218]) by mx1.freebsd.org (Postfix) with ESMTP id E9C438FC0A; Tue, 8 Dec 2009 05:06:19 +0000 (UTC) Received: by gxk10 with SMTP id 10so3930516gxk.3 for ; Mon, 07 Dec 2009 21:06:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BpKGkon4sOgc48+cetkxnfNV6cYJH/TbTGEIiJ9EoK0=; b=kC9cNr7YHHQ9SVgpZeJ1jgBtWcJwfzsskdLTh+OMAr05hXCrsEerC3U6mHVpXOz5RO rsusSJRwz4PUrgq+1jTZSGBSyRgNNxdp9vewe3aMb2XxBzFjKJH4tVFMROqkKxSKMl5H y4YlXxvWevk+JLIJW1xd535Ga5ErzOYgU1SZ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=cynrRJ0fGPTr+qa5O04Q9T2kbnlG59l2h9dp0UQsVoNrRJjee9FVtGxhhtSJiY1vdk mRYtgXdiHwG+p6ZRe1Vf8hb6SO/mVFU45RuvlSOXFcWpjLRjEJFec8j0E91AgJ6DG6AV 90piUTNv7//lbmnHPc9wue+6WVd8Bct4/ojAQ= MIME-Version: 1.0 Received: by 10.91.21.25 with SMTP id y25mr2819602agi.66.1260248778129; Mon, 07 Dec 2009 21:06:18 -0800 (PST) In-Reply-To: <2a5e326f0912071259g840e88ejc9951137380d9f95@mail.gmail.com> References: <2a5e326f0912061134s79c05e75td77e6874d409c675@mail.gmail.com> <20091207191048.GB1795@garage.freebsd.pl> <2a5e326f0912071203y35d45205n4566c1bb3260166d@mail.gmail.com> <20091207204012.GD1795@garage.freebsd.pl> <2a5e326f0912071259g840e88ejc9951137380d9f95@mail.gmail.com> Date: Mon, 7 Dec 2009 23:06:18 -0600 Message-ID: <2a5e326f0912072106w58e31924ja8e22dc009665080@mail.gmail.com> From: Kurt Touet To: Pawel Jakub Dawidek Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: zpool create fails on gpart device 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, 08 Dec 2009 05:06:20 -0000 On Mon, Dec 7, 2009 at 2:59 PM, Kurt Touet wrote: > On Mon, Dec 7, 2009 at 2:40 PM, Pawel Jakub Dawidek wro= te: >> On Mon, Dec 07, 2009 at 02:03:09PM -0600, Kurt Touet wrote: >>> On Mon, Dec 7, 2009 at 1:10 PM, Pawel Jakub Dawidek w= rote: >>> > On Sun, Dec 06, 2009 at 01:34:13PM -0600, Kurt Touet wrote: >>> >> I've been interested in using a gptzfsboot setup on a few of my >>> >> systems, and thought I'd try it out in a VM first, but I'm blocked a= t >>> >> creating a zpool. =A0Here's what I did: >>> >> >>> >> - create a new VM with 2 drives (da0 & da1) >>> >> - install 8.0R amd64 >>> >> - install subversion from sysinstall & checkout base/head >>> >> - build & install -current >>> >> >>> >> Instead of creating a gptzfsboot install disc, I thought I'd just >>> >> create the zpool on the second drive, install things to there, and >>> >> then make the VM boot off the second drive afterwards (and remove th= e >>> >> first). =A0I was following the >>> >> http://blogs.freebsdish.org/lulf/2008/12/16/setting-up-a-zfs-only-sy= stem/ >>> >> guide, and got to this stage: >>> >> >>> >> # gpart create -s GPT da1 >>> >> # gpart add -b 34 -s 128 -t freebsd-boot da1 >>> >> # gpart add -b 162 -s 5242880 -t freebsd-swap da1 >>> >> # gpart add -b 5243042 -s 57671485 -t freebsd-zfs da1 >>> >> # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da1 >>> >> >>> >> # gpart show da1 >>> >> =3D> =A0 =A0 =A034 =A062914493 =A0da1 =A0GPT =A0(30G) >>> >> =A0 =A0 =A0 =A0 34 =A0 =A0 =A0 128 =A0 =A01 =A0freebsd-boot =A0(64K) >>> >> =A0 =A0 =A0 =A0162 =A0 5242880 =A0 =A02 =A0freebsd-swap =A0(2.5G) >>> >> =A0 =A05243042 =A057671485 =A0 =A03 =A0freebsd-zfs =A0(27G) >>> >> >>> >> # zpool create data /dev/da1p3 >>> >> cannot create 'data': permission denied >> >> Ok, I guess this is HEAD, right? I think you just had bad luck. >> >> I break this here: >> >> =A0 =A0 =A0 =A0Date: Sat Dec =A05 14:24:22 2009 >> =A0 =A0 =A0 =A0New Revision: 200125 >> >> And fixed here: >> >> =A0 =A0 =A0 =A0Date: Sat Dec =A05 20:16:28 2009 >> =A0 =A0 =A0 =A0New Revision: 200158 >> >> It looks like you get the source from this window. >> >> Please rebuild with r200158 in place and retry. Sorry for the breakage. >> >> -- >> Pawel Jakub Dawidek =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://w= ww.wheel.pl >> pjd@FreeBSD.org =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http= ://www.FreeBSD.org >> FreeBSD committer =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Am I E= vil? Yes, I Am! >> > > I think I managed to miss that -- I'm running FreeBSD 9.0-CURRENT #0 > r200177 amd64. =A0But, I will update again and see if that solves the > problem. > I've updated to r200237 and I am getting the same error. Is there another way that I can go about troubleshooting this? Thanks, -kurt From owner-freebsd-fs@FreeBSD.ORG Tue Dec 8 10:28:13 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61FD7106568B for ; Tue, 8 Dec 2009 10:28:13 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id A265B8FC0C for ; Tue, 8 Dec 2009 10:28:12 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 9B6F045D8D; Tue, 8 Dec 2009 11:28:10 +0100 (CET) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 965F045CD9; Tue, 8 Dec 2009 11:28:05 +0100 (CET) Date: Tue, 8 Dec 2009 11:28:05 +0100 From: Pawel Jakub Dawidek To: Kurt Touet Message-ID: <20091208102805.GH1795@garage.freebsd.pl> References: <2a5e326f0912061134s79c05e75td77e6874d409c675@mail.gmail.com> <20091207191048.GB1795@garage.freebsd.pl> <2a5e326f0912071203y35d45205n4566c1bb3260166d@mail.gmail.com> <20091207204012.GD1795@garage.freebsd.pl> <2a5e326f0912071259g840e88ejc9951137380d9f95@mail.gmail.com> <2a5e326f0912072106w58e31924ja8e22dc009665080@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WIIRZ1HQ6FgrlPgb" Content-Disposition: inline In-Reply-To: <2a5e326f0912072106w58e31924ja8e22dc009665080@mail.gmail.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: zpool create fails on gpart device 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, 08 Dec 2009 10:28:13 -0000 --WIIRZ1HQ6FgrlPgb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 07, 2009 at 11:06:18PM -0600, Kurt Touet wrote: > I've updated to r200237 and I am getting the same error. Is there > another way that I can go about troubleshooting this? I looked at you ktrace closly. Your zpool calls pread(2) four times on your partition, where in my ktrace I see only one pread(2). Also two of the pread(2) have invalid offset and get EIO. Could you show the output of: # diskinfo -v /dev/da1{,p3} Try setting vfs.zfs.debug to 2, then retry the creation and watch logs. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --WIIRZ1HQ6FgrlPgb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFLHio1ForvXbEpPzQRAja/AKCp0cO7iJKY/BrCw9EYtF/tv3oF3ACdHK7H kKuMbrBL/N1KweG0lyEkRD4= =ymLr -----END PGP SIGNATURE----- --WIIRZ1HQ6FgrlPgb-- From owner-freebsd-fs@FreeBSD.ORG Tue Dec 8 10:50:03 2009 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9231106568F for ; Tue, 8 Dec 2009 10:50:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B84058FC12 for ; Tue, 8 Dec 2009 10:50:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nB8Ao3dB042804 for ; Tue, 8 Dec 2009 10:50:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nB8Ao3BI042803; Tue, 8 Dec 2009 10:50:03 GMT (envelope-from gnats) Date: Tue, 8 Dec 2009 10:50:03 GMT Message-Id: <200912081050.nB8Ao3BI042803@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Alexandre Krasnov Cc: Subject: Re: kern/129059: [zfs] [patch] ZFS bootloader whitelistable via WITHOUT_CDDL X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alexandre Krasnov List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 10:50:03 -0000 The following reply was made to PR kern/129059; it has been noted by GNATS. From: Alexandre Krasnov To: bug-followup@freebsd.org, gcooper@freebsd.org Cc: Subject: Re: kern/129059: [zfs] [patch] ZFS bootloader whitelistable via WITHOUT_CDDL Date: Tue, 8 Dec 2009 13:18:37 +0300 The same (or a similar one) exists in 7.2-STABLE If I specify WITHOUT_ZFS=yes (or WITHOUT_CDDL=yes) buidworld fails because zfs code still tries to compile for boot loader. btxld -v -E 0x2000 -f bin -b /home/dev/obj/usr/src/sys/boot/i386/zfsboot/../btx/btx/btx -l zfsboot.ldr -o zfsboot.ld -P 1 zfsboot.bin btxld: zfsboot.ldr: Invalid argument *** Error code 2 Stop in /usr/src/sys/boot/i386/zfsboot. *** Error code 1 Stop in /usr/src/sys/boot/i386. -- Alexander Krasnov. Tel: +7 (495) 234-9885 Fax: +7 (499) 317-4127 www.tern.ru From owner-freebsd-fs@FreeBSD.ORG Tue Dec 8 13:36:07 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F06E106566B for ; Tue, 8 Dec 2009 13:36:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 52F4A8FC14 for ; Tue, 8 Dec 2009 13:36:07 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 1027B46B45; Tue, 8 Dec 2009 08:36:07 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 39E208A020; Tue, 8 Dec 2009 08:36:06 -0500 (EST) From: John Baldwin To: freebsd-fs@freebsd.org Date: Tue, 8 Dec 2009 08:13:58 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20091103; KDE/4.3.1; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200912080813.58600.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 08 Dec 2009 08:36:06 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Subject: Re: PATCH: increase heap size for (gpt)zfsboot 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, 08 Dec 2009 13:36:07 -0000 On Monday 07 December 2009 7:01:03 pm Matt Reimer wrote: > Enlarge the heap size for gptzfsboot and zfsboot. This is necessary so > the ZFS code has enough memory to handle decompression and error > recovery. > > Before this patch the heap grew from the end of the (gpt)zfsboot code > and static data up to 640KB, possibly overrunning the stack. Now the > heap is located at 16MB-64MB. > > Note that this requires machines with at least 64MB RAM, but this is > not likely to be a problem on any machine running ZFS. > > Sponsored by: VPOP Technologies, Inc. > > Matt Reimer Unfortunately the 16M - 64M range may not all be useable RAM. It may contain ACPI tables, etc. A robust approach would involve walking the SMAP, etc. I just committed some changes to sys/boot/i386/loader/biosmem.c that make it smarter about choosing a heap region. I suggest adopting that algorithm for figuring out a safe heap range. zfsboot and gptzfsboot should have enough free space to take the bios_getmem() function. You can increase the minimum heap size beyond 3M if desired (though 3M is the minimum the loader will guarantee currently, and if ZFS needs more than that it likely needs to be changed in both places). -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Tue Dec 8 17:44:22 2009 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B79D2106566C; Tue, 8 Dec 2009 17:44:22 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 908F28FC18; Tue, 8 Dec 2009 17:44:22 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nB8HiMF8007441; Tue, 8 Dec 2009 17:44:22 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nB8HiMFv007437; Tue, 8 Dec 2009 17:44:22 GMT (envelope-from linimon) Date: Tue, 8 Dec 2009 17:44:22 GMT Message-Id: <200912081744.nB8HiMFv007437@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/141289: [nfs] [panic] newnfs panic "nfs sent cache" with IPv6 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, 08 Dec 2009 17:44:22 -0000 Old Synopsis: newnfs panic "nfs sent cache" with IPv6 New Synopsis: [nfs] [panic] newnfs panic "nfs sent cache" with IPv6 Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Tue Dec 8 17:44:06 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=141289 From owner-freebsd-fs@FreeBSD.ORG Tue Dec 8 19:37:32 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B3421065693; Tue, 8 Dec 2009 19:37:32 +0000 (UTC) (envelope-from ktouet@gmail.com) Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.210.171]) by mx1.freebsd.org (Postfix) with ESMTP id 15B2C8FC15; Tue, 8 Dec 2009 19:37:30 +0000 (UTC) Received: by yxe1 with SMTP id 1so5305453yxe.3 for ; Tue, 08 Dec 2009 11:37:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=m/XCpiP9/+9BDc/BCIkNbOEeCCGTumigTdsAaermqmY=; b=neFVDdYuvnw1/kvXRgIpworposPfDpb/ZKN3Xk0ADV8K98dmlSw8KF02JML0Y7f6oL WQmSJO++eGah8HnhtEZCDDEcXflM2nO63ZSmMuSefmMcxHYBgtZeo7PdaHsX/lQAwZXN XF6r9l0t+yZ0g9pPvbBVFg4ZexarzvtEt2sZI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=YeKTnrkIbEGqZYLxIbNFqa9k2q9P62I5BpJg+xb5piX6JLmVVMbWC7C6cdo3uQ/ZpB 2XS/ghdOdkGmqQgUt6kWu0oHjTI6R1iO0Z5qgNcWFJgKKUiLfbsk3MT3Bj3jHYwJvkUg MjurpvKQBQobEcV/rlKJCQp0dQYAMv4zqaFBw= MIME-Version: 1.0 Received: by 10.91.192.14 with SMTP id u14mr13710875agp.2.1260301049995; Tue, 08 Dec 2009 11:37:29 -0800 (PST) In-Reply-To: <20091208102805.GH1795@garage.freebsd.pl> References: <2a5e326f0912061134s79c05e75td77e6874d409c675@mail.gmail.com> <20091207191048.GB1795@garage.freebsd.pl> <2a5e326f0912071203y35d45205n4566c1bb3260166d@mail.gmail.com> <20091207204012.GD1795@garage.freebsd.pl> <2a5e326f0912071259g840e88ejc9951137380d9f95@mail.gmail.com> <2a5e326f0912072106w58e31924ja8e22dc009665080@mail.gmail.com> <20091208102805.GH1795@garage.freebsd.pl> Date: Tue, 8 Dec 2009 13:37:29 -0600 Message-ID: <2a5e326f0912081137l62abb81ap76f6c69350dc1196@mail.gmail.com> From: Kurt Touet To: Pawel Jakub Dawidek Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: zpool create fails on gpart device 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, 08 Dec 2009 19:37:32 -0000 On Tue, Dec 8, 2009 at 4:28 AM, Pawel Jakub Dawidek wrote= : > On Mon, Dec 07, 2009 at 11:06:18PM -0600, Kurt Touet wrote: >> I've updated to r200237 and I am getting the same error. =A0Is there >> another way that I can go about troubleshooting this? > > I looked at you ktrace closly. Your zpool calls pread(2) four times on > your partition, where in my ktrace I see only one pread(2). Also two of > the pread(2) have invalid offset and get EIO. > > Could you show the output of: > > =A0 =A0 =A0 =A0# diskinfo -v /dev/da1{,p3} > > Try setting vfs.zfs.debug to 2, then retry the creation and watch logs. > > -- > Pawel Jakub Dawidek =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://ww= w.wheel.pl > pjd@FreeBSD.org =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http:= //www.FreeBSD.org > FreeBSD committer =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Am I Ev= il? Yes, I Am! > # diskinfo -v /dev/da1{,p3} /dev/da1 512 # sectorsize 32212254720 # mediasize in bytes (30G) 62914560 # mediasize in sectors 3916 # Cylinders according to firmware. 255 # Heads according to firmware. 63 # Sectors according to firmware. # Disk ident. /dev/da1p3 512 # sectorsize 29527800320 # mediasize in bytes (27G) 57671485 # mediasize in sectors 3589 # Cylinders according to firmware. 255 # Heads according to firmware. 63 # Sectors according to firmware. # Disk ident. # zpool create data /dev/da1p3 cannot create 'data': permission denied logs: kernel: vdev_geom_open_by_path:466[1]: Found provider by name /dev/da1p3. kernel: vdev_geom_attach:112[1]: Attaching to da1p3. kernel: vdev_geom_attach:133[1]: Created geom and consumer for da1p3. kernel: vdev_geom_read_guid:301[1]: Reading guid from da1p3... kernel: vdev_geom_detach:173[1]: Closing access to da1p3. kernel: vdev_geom_detach:177[1]: Destroyed consumer to da1p3. kernel: vdev_geom_detach:185[1]: Destroyed geom zfs::vdev. kernel: vdev_geom_open_by_path:477[1]: guid mismatch for provider /dev/da1p3: 16452466135488744636 !=3D 0. kernel: vdev_geom_open_by_guid:435[1]: Searching by guid [16452466135488744= 636]. kernel: vdev_geom_read_guid:301[1]: Reading guid from acd0t01... kernel: vdev_geom_read_guid:301[1]: Reading guid from acd0... kernel: vdev_geom_read_guid:301[1]: Reading guid from da1p3... kernel: vdev_geom_read_guid:301[1]: Reading guid from da1p2... kernel: vdev_geom_read_guid:301[1]: Reading guid from da1p1... kernel: vdev_geom_read_guid:301[1]: Reading guid from da0s1f... kernel: vdev_geom_read_guid:301[1]: Reading guid from da0s1e... kernel: vdev_geom_read_guid:301[1]: Reading guid from da0s1d... kernel: vdev_geom_read_guid:301[1]: Reading guid from da0s1b... kernel: vdev_geom_read_guid:301[1]: Reading guid from da0s1a... kernel: vdev_geom_read_guid:301[1]: Reading guid from da0s1... kernel: vdev_geom_read_guid:301[1]: Reading guid from da1... kernel: vdev_geom_read_guid:301[1]: Reading guid from da0... kernel: vdev_geom_read_guid:301[1]: Reading guid from gptid/78398fed-e369-11de-a6aa-000c298c3c39... kernel: vdev_geom_read_guid:301[1]: Reading guid from ufsid/4b1c06d3f757961= 5... kernel: vdev_geom_read_guid:301[1]: Reading guid from gptid/663a8d5a-e293-11de-a6aa-000c298c3c39... kernel: vdev_geom_read_guid:301[1]: Reading guid from gptid/5ec68721-e293-11de-a6aa-000c298c3c39... kernel: vdev_geom_read_guid:301[1]: Reading guid from iso9660/FreeBSD_Insta= ll... kernel: vdev_geom_open_by_guid:449[1]: Search by guid [16452466135488744636] failed. kernel: vdev_geom_open_by_path:466[1]: Found provider by name /dev/da1p3. kernel: vdev_geom_attach:112[1]: Attaching to da1p3. kernel: vdev_geom_open:521[1]: Provider /dev/da1p3 not found. root: ZFS: vdev failure, zpool=3Ddata type=3Dvdev.open_failed From owner-freebsd-fs@FreeBSD.ORG Tue Dec 8 19:54:45 2009 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAE38106568F; Tue, 8 Dec 2009 19:54:45 +0000 (UTC) (envelope-from marius@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 92A668FC12; Tue, 8 Dec 2009 19:54:45 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nB8JsjE3019742; Tue, 8 Dec 2009 19:54:45 GMT (envelope-from marius@freefall.freebsd.org) Received: (from marius@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nB8Jsji6019738; Tue, 8 Dec 2009 19:54:45 GMT (envelope-from marius) Date: Tue, 8 Dec 2009 19:54:45 GMT Message-Id: <200912081954.nB8Jsji6019738@freefall.freebsd.org> To: glewis@freebsd.org, marius@FreeBSD.org, freebsd-fs@FreeBSD.org From: marius@FreeBSD.org Cc: Subject: Re: sparc64/140797: [nfs] [panic] panic on 8.0-RC3/sparc64 as an NFS server X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 19:54:45 -0000 Synopsis: [nfs] [panic] panic on 8.0-RC3/sparc64 as an NFS server State-Changed-From-To: open->closed State-Changed-By: marius State-Changed-When: Tue Dec 8 19:49:01 UTC 2009 State-Changed-Why: Close; this was fixed in r199274/r199284 for HEAD and in r199733 for stable/8. It was also submitted to re@ for consideration as an 8.0 erratum. This is pretty much all that can be done about this PR from a committer point of view. http://www.freebsd.org/cgi/query-pr.cgi?pr=140797 From owner-freebsd-fs@FreeBSD.ORG Tue Dec 8 21:24:05 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 246341065693 for ; Tue, 8 Dec 2009 21:24:05 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id 55FE18FC14 for ; Tue, 8 Dec 2009 21:24:03 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 5888C45E98; Tue, 8 Dec 2009 22:24:01 +0100 (CET) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 0E3C34569A; Tue, 8 Dec 2009 22:23:55 +0100 (CET) Date: Tue, 8 Dec 2009 22:23:55 +0100 From: Pawel Jakub Dawidek To: Kurt Touet Message-ID: <20091208212355.GA2466@garage.freebsd.pl> References: <2a5e326f0912061134s79c05e75td77e6874d409c675@mail.gmail.com> <20091207191048.GB1795@garage.freebsd.pl> <2a5e326f0912071203y35d45205n4566c1bb3260166d@mail.gmail.com> <20091207204012.GD1795@garage.freebsd.pl> <2a5e326f0912071259g840e88ejc9951137380d9f95@mail.gmail.com> <2a5e326f0912072106w58e31924ja8e22dc009665080@mail.gmail.com> <20091208102805.GH1795@garage.freebsd.pl> <2a5e326f0912081137l62abb81ap76f6c69350dc1196@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IS0zKkzwUGydFO0o" Content-Disposition: inline In-Reply-To: <2a5e326f0912081137l62abb81ap76f6c69350dc1196@mail.gmail.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: zpool create fails on gpart device 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, 08 Dec 2009 21:24:05 -0000 --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 08, 2009 at 01:37:29PM -0600, Kurt Touet wrote: > kernel: vdev_geom_read_guid:301[1]: Reading guid from iso9660/FreeBSD_Ins= tall... > kernel: vdev_geom_open_by_guid:449[1]: Search by guid [164524661354887446= 36] failed. > kernel: vdev_geom_open_by_path:466[1]: Found provider by name /dev/da1p3. > kernel: vdev_geom_attach:112[1]: Attaching to da1p3. > kernel: vdev_geom_open:521[1]: Provider /dev/da1p3 not found. > root: ZFS: vdev failure, zpool=3Ddata type=3Dvdev.open_failed I don't see how you can run with the fix I committed. With the fix there should be two such messages: vdev_geom_open_by_path:466[1]: Found provider by name /dev/da1p3. One when checking by name+guid and one when checking by name only. In you logs there is only one such message, so you are clearly running without my latest fix. Could you paste the output of: % grep -n vdev_geom_open_by_path /sys/cddl/contrib/opensolaris/uts/common/= fs/zfs/vdev_geom.c --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --IS0zKkzwUGydFO0o Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFLHsPrForvXbEpPzQRAhioAKCl9+fgu2pYDBj2cJqTt4YaWMN45wCgvNLU Bx7TLSJmxsBQdaTTL9cPGmA= =eUrh -----END PGP SIGNATURE----- --IS0zKkzwUGydFO0o-- From owner-freebsd-fs@FreeBSD.ORG Tue Dec 8 22:17:56 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD609106566B; Tue, 8 Dec 2009 22:17:56 +0000 (UTC) (envelope-from ktouet@gmail.com) Received: from mail-yw0-f199.google.com (mail-yw0-f199.google.com [209.85.211.199]) by mx1.freebsd.org (Postfix) with ESMTP id 515108FC14; Tue, 8 Dec 2009 22:17:56 +0000 (UTC) Received: by ywh37 with SMTP id 37so3735718ywh.13 for ; Tue, 08 Dec 2009 14:17:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yrCPU4iK7PAaRGEXShA992hjx2k3ElhnHQc39GlXiHU=; b=x+40QYcJPJc7OBGgNdpXKAmQTESUo/PvGxBOE2CEqutqK+gThCkJXuecatG9A+kEMf 5kfSCpZ79wZnKabsU5QYMyEPuZ7DAVktEqQ70Yx9zOeaNNBnPy7Lem6uRQzoC2Ok3dPT Nael3+280Qw3aOqPQbr0RmACZpVRVJvY6c3ZY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=P4/ATzqjG7qLpsXVLaAd09duhAGaaM7zAELs95XMjf1VRGccGC0ZRPvA+N1ySTyZFB LokY9huh0/ojje5uYjM6HMMrvu61Bs6JapJdtz7TP18F7yUZH9vd8QlSkDnIpgfdl904 lgdHUT6rS3NeCA/joU0Qn272878G+wnVuCQ8U= MIME-Version: 1.0 Received: by 10.91.183.4 with SMTP id k4mr13861862agp.41.1260310673711; Tue, 08 Dec 2009 14:17:53 -0800 (PST) In-Reply-To: <20091208212355.GA2466@garage.freebsd.pl> References: <2a5e326f0912061134s79c05e75td77e6874d409c675@mail.gmail.com> <20091207191048.GB1795@garage.freebsd.pl> <2a5e326f0912071203y35d45205n4566c1bb3260166d@mail.gmail.com> <20091207204012.GD1795@garage.freebsd.pl> <2a5e326f0912071259g840e88ejc9951137380d9f95@mail.gmail.com> <2a5e326f0912072106w58e31924ja8e22dc009665080@mail.gmail.com> <20091208102805.GH1795@garage.freebsd.pl> <2a5e326f0912081137l62abb81ap76f6c69350dc1196@mail.gmail.com> <20091208212355.GA2466@garage.freebsd.pl> Date: Tue, 8 Dec 2009 16:17:53 -0600 Message-ID: <2a5e326f0912081417m2586f3dbt92b62e81dd45d2b9@mail.gmail.com> From: Kurt Touet To: Pawel Jakub Dawidek Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: zpool create fails on gpart device 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, 08 Dec 2009 22:17:56 -0000 On Tue, Dec 8, 2009 at 3:23 PM, Pawel Jakub Dawidek wrote= : > On Tue, Dec 08, 2009 at 01:37:29PM -0600, Kurt Touet wrote: >> kernel: vdev_geom_read_guid:301[1]: Reading guid from iso9660/FreeBSD_In= stall... >> kernel: vdev_geom_open_by_guid:449[1]: Search by guid [16452466135488744= 636] failed. >> kernel: vdev_geom_open_by_path:466[1]: Found provider by name /dev/da1p3= . >> kernel: vdev_geom_attach:112[1]: Attaching to da1p3. >> kernel: vdev_geom_open:521[1]: Provider /dev/da1p3 not found. >> root: ZFS: vdev failure, zpool=3Ddata type=3Dvdev.open_failed > > I don't see how you can run with the fix I committed. > > With the fix there should be two such messages: > > vdev_geom_open_by_path:466[1]: Found provider by name /dev/da1p3. > > One when checking by name+guid and one when checking by name only. > In you logs there is only one such message, so you are clearly running > without my latest fix. > > Could you paste the output of: > > =A0 =A0 =A0 =A0% grep -n vdev_geom_open_by_path /sys/cddl/contrib/opensol= aris/uts/common/fs/zfs/vdev_geom.c > > -- > Pawel Jakub Dawidek =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://ww= w.wheel.pl > pjd@FreeBSD.org =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http:= //www.FreeBSD.org > FreeBSD committer =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Am I Ev= il? Yes, I Am! > # uname -a FreeBSD freebase 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r200237: Mon Dec 7 22:17:59 CST 2009 k@freebase:/usr/obj/usr/src/sys/GENERIC amd64 # grep -n vdev_geom_open_by_path /sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c 456:vdev_geom_open_by_path(vdev_t *vd, int check_guid) 509: cp =3D vdev_geom_open_by_path(vd, 1); 519: cp =3D vdev_geom_open_by_path(vd, 0); # svn info /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geo= m.c Path: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c Name: vdev_geom.c URL: svn://svn.freebsd.org/base/head/sys/cddl/contrib/opensolaris/uts/commo= n/fs/zfs/vdev_geom.c Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 200237 Node Kind: file Schedule: normal Last Changed Author: pjd Last Changed Rev: 200158 Last Changed Date: 2009-12-05 14:16:28 -0600 (Sat, 05 Dec 2009) Text Last Updated: 2009-12-05 23:53:15 -0600 (Sat, 05 Dec 2009) Checksum: c1ca9bb1684c2aba028feb187af8de03 From owner-freebsd-fs@FreeBSD.ORG Tue Dec 8 23:06:25 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0915A106566B; Tue, 8 Dec 2009 23:06:25 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from mail-pz0-f185.google.com (mail-pz0-f185.google.com [209.85.222.185]) by mx1.freebsd.org (Postfix) with ESMTP id C83E68FC0A; Tue, 8 Dec 2009 23:06:24 +0000 (UTC) Received: by pzk15 with SMTP id 15so2702811pzk.3 for ; Tue, 08 Dec 2009 15:06:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=I3A6cVy6tTxUMm72ddXe8J1ivM3u7sC7sb0gnYCYCms=; b=xKb1fxeKC+1sUZ4qQWc96Ld0vijXwz9dWLDg9CSNYLMjqaQX+js5IUwdW5cd4ygYap 8MTLl5VUZUUqOErpcHXdlSC7JFWkARYUtynw8EyWwPBZM7Jb0w5MrKceWIqZjvye2G0j kfWV2mrsxmynFo7PjjlGdhR3B+Yi0Eut0WyYw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fZGrzOLieiSBy4ESSBCfWavIUf6Uxw0c0p4QertFAMTNm2fOtEV3N/AYH+q1QS6Xup ATD2KiPrh4eUkNoMulnsNn3Vlh7aZYpi9XFcOGM+PIN9ovRheWWS6rIFHiKntujC864j SdSYLtwQkqFwbsMsca7+OKxnJI+Jcm0IscDSk= MIME-Version: 1.0 Received: by 10.142.120.3 with SMTP id s3mr961769wfc.301.1260313574968; Tue, 08 Dec 2009 15:06:14 -0800 (PST) In-Reply-To: <200912080813.58600.jhb@freebsd.org> References: <200912080813.58600.jhb@freebsd.org> Date: Tue, 8 Dec 2009 15:06:14 -0800 Message-ID: From: Matt Reimer To: John Baldwin Content-Type: multipart/mixed; boundary=001636e0b9c5f10ee2047a3f9eb3 Cc: freebsd-fs@freebsd.org Subject: Re: PATCH: increase heap size for (gpt)zfsboot 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, 08 Dec 2009 23:06:25 -0000 --001636e0b9c5f10ee2047a3f9eb3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Dec 8, 2009 at 5:13 AM, John Baldwin wrote: > On Monday 07 December 2009 7:01:03 pm Matt Reimer wrote: >> Enlarge the heap size for gptzfsboot and zfsboot. This is necessary so >> the ZFS code has enough memory to handle decompression and error >> recovery. >> >> Before this patch the heap grew from the end of the (gpt)zfsboot code >> and static data up to 640KB, possibly overrunning the stack. Now the >> heap is located at 16MB-64MB. >> >> Note that this requires machines with at least 64MB RAM, but this is >> not likely to be a problem on any machine running ZFS. >> >> Sponsored by: VPOP Technologies, Inc. >> >> Matt Reimer > > Unfortunately the 16M - 64M range may not all be useable RAM. =A0It may c= ontain > ACPI tables, etc. =A0A robust approach would involve walking the SMAP, et= c. =A0I > just committed some changes to sys/boot/i386/loader/biosmem.c that make i= t > smarter about choosing a heap region. =A0I suggest adopting that algorith= m for > figuring out a safe heap range. =A0zfsboot and gptzfsboot should have eno= ugh > free space to take the bios_getmem() function. =A0You can increase the mi= nimum > heap size beyond 3M if desired (though 3M is the minimum the loader will > guarantee currently, and if ZFS needs more than that it likely needs to b= e > changed in both places). Thanks John. I dropped the bios_getmem() into zfsboot.c and it works for me. How's the attached patch look to you? Matt --001636e0b9c5f10ee2047a3f9eb3 Content-Type: application/octet-stream; name="more-mem.patch" Content-Disposition: attachment; filename="more-mem.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g2za5nle0 LS0tIC9zeXMvYm9vdC96ZnMvemZzaW1wbC5jLk9SSUcJMjAwOS0xMS0yMSAwNzowMjozNS4wMDAw MDAwMDAgLTA4MDAKKysrIC9zeXMvYm9vdC96ZnMvemZzaW1wbC5jCTIwMDktMTItMDcgMTI6NTQ6 NDQuMDAwMDAwMDAwIC0wODAwCkBAIC01MSw3ICs1MSw3IEBACiBzdGF0aWMgY2hhciAqemFwX3Nj cmF0Y2g7CiBzdGF0aWMgY2hhciAqemZzX3RlbXBfYnVmLCAqemZzX3RlbXBfZW5kLCAqemZzX3Rl bXBfcHRyOwogCi0jZGVmaW5lIFRFTVBfU0laRQkoMSpTUEFfTUFYQkxPQ0tTSVpFKQorI2RlZmlu ZSBURU1QX1NJWkUJKDEwMjQgKiAxMDI0KQogCiBzdGF0aWMgaW50IHppb19yZWFkKHNwYV90ICpz cGEsIGNvbnN0IGJsa3B0cl90ICpicCwgdm9pZCAqYnVmKTsKIAotLS0gL3N5cy9ib290L2kzODYv emZzYm9vdC96ZnNib290LmMuT1JJRwkyMDA5LTEyLTA3IDEwOjMyOjIyLjAwMDAwMDAwMCAtMDgw MAorKysgL3N5cy9ib290L2kzODYvemZzYm9vdC96ZnNib290LmMJMjAwOS0xMi0wOCAxNDo1NToz Mi4wMDAwMDAwMDAgLTA4MDAKQEAgLTI3LDYgKzI3LDcgQEAKIAogI2luY2x1ZGUgPG1hY2hpbmUv Ym9vdGluZm8uaD4KICNpbmNsdWRlIDxtYWNoaW5lL2VsZi5oPgorI2luY2x1ZGUgPG1hY2hpbmUv cGMvYmlvcy5oPgogCiAjaW5jbHVkZSA8c3RkYXJnLmg+CiAjaW5jbHVkZSA8c3RkZGVmLmg+CkBA IC0xNDksNiArMTUwLDE5IEBACiBzdGF0aWMgdWludDMyX3QgYm9vdGRldjsKIHN0YXRpYyB1aW50 OF90IGlvY3RybCA9IElPX0tFWUJPQVJEOwogCit2bV9vZmZzZXRfdAltZW10b3AsIG1lbXRvcF9j b3B5aW4sIGhpZ2hfaGVhcF9iYXNlOwordV9pbnQzMl90CWJpb3NfYmFzZW1lbSwgYmlvc19leHRt ZW0sIGhpZ2hfaGVhcF9zaXplOworCitzdGF0aWMgc3RydWN0IGJpb3Nfc21hcCBzbWFwOworCisv KgorICogVGhlIG1pbmltdW0gYW1vdW50IG9mIG1lbW9yeSB0byByZXNlcnZlIGluIGJpb3NfZXh0 bWVtIGZvciB0aGUgaGVhcC4KKyAqLworI2RlZmluZQlIRUFQX01JTgkoMyAqIDEwMjQgKiAxMDI0 KQorCitzdGF0aWMgY2hhciAqaGVhcF9uZXh0Oworc3RhdGljIGNoYXIgKmhlYXBfZW5kOworCiAv KiBCdWZmZXJzIHRoYXQgbXVzdCBub3Qgc3BhbiBhIDY0ayBib3VuZGFyeS4gKi8KICNkZWZpbmUg UkVBRF9CVUZfU0laRQk4MTkyCiBzdHJ1Y3QgZG1hZGF0IHsKQEAgLTE2Myw2ICsxNzcsNyBAQAog c3RhdGljIHZvaWQgcHJpbnRmKGNvbnN0IGNoYXIgKiwuLi4pOwogc3RhdGljIHZvaWQgcHV0Y2hh cihpbnQpOwogc3RhdGljIHVpbnQzMl90IG1lbXNpemUodm9pZCk7Cit2b2lkIGJpb3NfZ2V0bWVt KHZvaWQpOwogc3RhdGljIGludCBkcnZyZWFkKHN0cnVjdCBkc2sgKiwgdm9pZCAqLCBkYWRkcl90 LCB1bnNpZ25lZCk7CiBzdGF0aWMgaW50IGtleWhpdCh1bnNpZ25lZCk7CiBzdGF0aWMgaW50IHhw dXRjKGludCk7CkBAIC0yMzcsMTQgKzI1Miw2IEBACiBzdGF0aWMgdm9pZCAqCiBtYWxsb2Moc2l6 ZV90IG4pCiB7Ci0Jc3RhdGljIGNoYXIgKmhlYXBfbmV4dDsKLQlzdGF0aWMgY2hhciAqaGVhcF9l bmQ7Ci0KLQlpZiAoIWhlYXBfbmV4dCkgewotCQloZWFwX25leHQgPSAoY2hhciAqKSBkbWFkYXQg KyBzaXplb2YoKmRtYWRhdCk7Ci0JCWhlYXBfZW5kID0gKGNoYXIgKikgKDY0MCoxMDI0KTsKLQl9 Ci0KIAljaGFyICpwID0gaGVhcF9uZXh0OwogCWlmIChwICsgbiA+IGhlYXBfZW5kKSB7CiAJCXBy aW50ZigibWFsbG9jIGZhaWx1cmVcbiIpOwpAQCAtMzUzLDYgKzM2MCw5NiBAQAogICAgIHJldHVy biB2ODYuZWF4OwogfQogCit2b2lkCitiaW9zX2dldG1lbSh2b2lkKQoreworICAgIHVpbnQ2NF90 IHNpemU7CisKKyAgICAvKiBQYXJzZSBzeXN0ZW0gbWVtb3J5IG1hcCAqLworICAgIHY4Ni5lYngg PSAwOworICAgIGRvIHsKKwl2ODYuY3RsID0gVjg2X0ZMQUdTOworCXY4Ni5hZGRyID0gMHgxNTsJ CS8qIGludCAweDE1IGZ1bmN0aW9uIDB4ZTgyMCovCisJdjg2LmVheCA9IDB4ZTgyMDsKKwl2ODYu ZWN4ID0gc2l6ZW9mKHN0cnVjdCBiaW9zX3NtYXApOworCXY4Ni5lZHggPSBTTUFQX1NJRzsKKwl2 ODYuZXMgPSBWVE9QU0VHKCZzbWFwKTsKKwl2ODYuZWRpID0gVlRPUE9GRigmc21hcCk7CisJdjg2 aW50KCk7CisJaWYgKCh2ODYuZWZsICYgMSkgfHwgKHY4Ni5lYXggIT0gU01BUF9TSUcpKQorCSAg ICBicmVhazsKKwkvKiBsb29rIGZvciBhIGxvdy1tZW1vcnkgc2VnbWVudCB0aGF0J3MgbGFyZ2Ug ZW5vdWdoICovCisJaWYgKChzbWFwLnR5cGUgPT0gU01BUF9UWVBFX01FTU9SWSkgJiYgKHNtYXAu YmFzZSA9PSAwKSAmJgorCSAgICAoc21hcC5sZW5ndGggPj0gKDUxMiAqIDEwMjQpKSkKKwkgICAg Ymlvc19iYXNlbWVtID0gc21hcC5sZW5ndGg7CisJLyogbG9vayBmb3IgdGhlIGZpcnN0IHNlZ21l bnQgaW4gJ2V4dGVuZGVkJyBtZW1vcnkgKi8KKwlpZiAoKHNtYXAudHlwZSA9PSBTTUFQX1RZUEVf TUVNT1JZKSAmJiAoc21hcC5iYXNlID09IDB4MTAwMDAwKSkgeworCSAgICBiaW9zX2V4dG1lbSA9 IHNtYXAubGVuZ3RoOworCX0KKworCS8qCisJICogTG9vayBmb3IgdGhlIGxhcmdlc3Qgc2VnbWVu dCBpbiAnZXh0ZW5kZWQnIG1lbW9yeSBiZXlvbmQKKwkgKiAxTUIgYnV0IGJlbG93IDRHQi4KKwkg Ki8KKwlpZiAoKHNtYXAudHlwZSA9PSBTTUFQX1RZUEVfTUVNT1JZKSAmJiAoc21hcC5iYXNlID4g MHgxMDAwMDApICYmCisJICAgIChzbWFwLmJhc2UgPCAweDEwMDAwMDAwMHVsbCkpIHsKKwkgICAg c2l6ZSA9IHNtYXAubGVuZ3RoOworCisJICAgIC8qCisJICAgICAqIElmIHRoaXMgc2VnbWVudCBj cm9zc2VzIHRoZSA0R0IgYm91bmRhcnksIHRydW5jYXRlIGl0LgorCSAgICAgKi8KKwkgICAgaWYg KHNtYXAuYmFzZSArIHNpemUgPiAweDEwMDAwMDAwMHVsbCkKKwkJc2l6ZSA9IDB4MTAwMDAwMDAw dWxsIC0gc21hcC5iYXNlOworCisJICAgIGlmIChzaXplID4gaGlnaF9oZWFwX3NpemUpIHsKKwkJ aGlnaF9oZWFwX3NpemUgPSBzaXplOworCQloaWdoX2hlYXBfYmFzZSA9IHNtYXAuYmFzZTsKKwkg ICAgfQorCX0KKyAgICB9IHdoaWxlICh2ODYuZWJ4ICE9IDApOworCisgICAgLyogRmFsbCBiYWNr IHRvIHRoZSBvbGQgY29tcGF0aWJpbGl0eSBmdW5jdGlvbiBmb3IgYmFzZSBtZW1vcnkgKi8KKyAg ICBpZiAoYmlvc19iYXNlbWVtID09IDApIHsKKwl2ODYuY3RsID0gMDsKKwl2ODYuYWRkciA9IDB4 MTI7CQkvKiBpbnQgMHgxMiAqLworCXY4NmludCgpOworCQorCWJpb3NfYmFzZW1lbSA9ICh2ODYu ZWF4ICYgMHhmZmZmKSAqIDEwMjQ7CisgICAgfQorCisgICAgLyogRmFsbCBiYWNrIHRocm91Z2gg c2V2ZXJhbCBjb21wYXRpYmlsaXR5IGZ1bmN0aW9ucyBmb3IgZXh0ZW5kZWQgbWVtb3J5ICovCisg ICAgaWYgKGJpb3NfZXh0bWVtID09IDApIHsKKwl2ODYuY3RsID0gVjg2X0ZMQUdTOworCXY4Ni5h ZGRyID0gMHgxNTsJCS8qIGludCAweDE1IGZ1bmN0aW9uIDB4ZTgwMSovCisJdjg2LmVheCA9IDB4 ZTgwMTsKKwl2ODZpbnQoKTsKKwlpZiAoISh2ODYuZWZsICYgMSkpIHsKKwkgICAgYmlvc19leHRt ZW0gPSAoKHY4Ni5lY3ggJiAweGZmZmYpICsgKCh2ODYuZWR4ICYgMHhmZmZmKSAqIDY0KSkgKiAx MDI0OworCX0KKyAgICB9CisgICAgaWYgKGJpb3NfZXh0bWVtID09IDApIHsKKwl2ODYuY3RsID0g MDsKKwl2ODYuYWRkciA9IDB4MTU7CQkvKiBpbnQgMHgxNSBmdW5jdGlvbiAweDg4Ki8KKwl2ODYu ZWF4ID0gMHg4ODAwOworCXY4NmludCgpOworCWJpb3NfZXh0bWVtID0gKHY4Ni5lYXggJiAweGZm ZmYpICogMTAyNDsKKyAgICB9CisKKyAgICAvKiBTZXQgbWVtdG9wIHRvIGFjdHVhbCB0b3Agb2Yg bWVtb3J5ICovCisgICAgbWVtdG9wID0gbWVtdG9wX2NvcHlpbiA9IDB4MTAwMDAwICsgYmlvc19l eHRtZW07CisKKyAgICAvKgorICAgICAqIElmIHdlIGhhdmUgZXh0ZW5kZWQgbWVtb3J5IGFuZCBk aWQgbm90IGZpbmQgYSBzdWl0YWJsZSBoZWFwCisgICAgICogcmVnaW9uIGluIHRoZSBTTUFQLCB1 c2UgdGhlIGxhc3QgM01CIG9mICdleHRlbmRlZCcgbWVtb3J5IGFzIGEKKyAgICAgKiBoaWdoIGhl YXAgY2FuZGlkYXRlLgorICAgICAqLworICAgIGlmIChiaW9zX2V4dG1lbSA+PSBIRUFQX01JTiAm JiBoaWdoX2hlYXBfc2l6ZSA8IEhFQVBfTUlOKSB7CisJaGlnaF9oZWFwX3NpemUgPSBIRUFQX01J TjsKKwloaWdoX2hlYXBfYmFzZSA9IG1lbXRvcCAtIEhFQVBfTUlOOworICAgIH0KK30gICAgCisK Kwogc3RhdGljIGlubGluZSB2b2lkCiBnZXRzdHIodm9pZCkKIHsKQEAgLTUzNiw2ICs2MzMsMTYg QEAKICAgICBvZmZfdCBvZmY7CiAgICAgc3RydWN0IGRzayAqZHNrOwogCisgICAgYmlvc19nZXRt ZW0oKTsKKworICAgIGlmIChoaWdoX2hlYXBfc2l6ZSA+IDApIHsKKwloZWFwX2VuZCA9IFBUT1Yo aGlnaF9oZWFwX2Jhc2UgKyBoaWdoX2hlYXBfc2l6ZSk7CisJaGVhcF9uZXh0ID0gUFRPVihoaWdo X2hlYXBfYmFzZSk7CisgICAgfSBlbHNlIHsKKwloZWFwX25leHQgPSAoY2hhciAqKSBkbWFkYXQg KyBzaXplb2YoKmRtYWRhdCk7CisJaGVhcF9lbmQgPSAoY2hhciAqKSBQVE9WKGJpb3NfYmFzZW1l bSk7CisgICAgfQorCiAgICAgZG1hZGF0ID0gKHZvaWQgKikocm91bmR1cDIoX19iYXNlICsgKGlu dDMyX3QpJl9lbmQsIDB4MTAwMDApIC0gX19iYXNlKTsKICAgICB2ODYuY3RsID0gVjg2X0ZMQUdT OwogCkBAIC01NTAsOCArNjU3LDggQEAKIAogICAgIGJvb3RpbmZvLmJpX3ZlcnNpb24gPSBCT09U SU5GT19WRVJTSU9OOwogICAgIGJvb3RpbmZvLmJpX3NpemUgPSBzaXplb2YoYm9vdGluZm8pOwot ICAgIGJvb3RpbmZvLmJpX2Jhc2VtZW0gPSAwOwkvKiBYWFggd2lsbCBiZSBmaWxsZWQgYnkgbG9h ZGVyIG9yIGtlcm5lbCAqLwotICAgIGJvb3RpbmZvLmJpX2V4dG1lbSA9IG1lbXNpemUoKTsKKyAg ICBib290aW5mby5iaV9iYXNlbWVtID0gYmlvc19iYXNlbWVtIC8gMTAyNDsKKyAgICBib290aW5m by5iaV9leHRtZW0gPSBiaW9zX2V4dG1lbSAvIDEwMjQ7CiAgICAgYm9vdGluZm8uYmlfbWVtc2l6 ZXNfdmFsaWQrKzsKICAgICBib290aW5mby5iaV9iaW9zX2RldiA9IGRzay0+ZHJpdmU7CiAK --001636e0b9c5f10ee2047a3f9eb3-- From owner-freebsd-fs@FreeBSD.ORG Tue Dec 8 23:11:11 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B49CD106568D; Tue, 8 Dec 2009 23:11:11 +0000 (UTC) (envelope-from kevin@your.org) Received: from mail.your.org (chi02.mail.your.org [204.9.55.23]) by mx1.freebsd.org (Postfix) with ESMTP id 793A88FC14; Tue, 8 Dec 2009 23:11:11 +0000 (UTC) Received: from mail.your.org (chi02.mail.your.org [204.9.55.23]) by mail.your.org (Postfix) with ESMTP id D9E8F1808264; Tue, 8 Dec 2009 23:11:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=your.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=selector1 ; bh=ekEb4ENR61rbDYNQlhMFDqsNf1g=; b=v+3PaCV92/SfJO0Y08KRJzskbpq ntq7Tl+L++CRfjZ6VCB6kKPMC2QAlbd40pCThd1Pd6vSl0hWbt8dfRpWzPFr8mHf mKJLmsttj9DvLrLy5J1WESFNDFVSgMN+eH3iRA6tqMVMR5qyx40j1aUQT47sjru0 qBjZgBGJym38dhzA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=your.org; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns; s=selector1; b=0n1FldpcKJ269RW TC+f6afLLf4ARbB6Ldgp3LXFkM2X6Q7oZYVUn/jKtTI5vQfqI3UVrg+7RGy3nUbu Z+vwjmVIsi/GOW/WtsWVUUjIElBktOMZEqTXUp+PQ6GUZGSfrcNFLbq5EIXsFZdt sYosrsKxJrW7ZbPDr41MVtSHyTfI= Received: from vpn177.ord02.your.org (vpn177.ord02.your.org [204.9.55.177]) by mail.your.org (Postfix) with ESMTPA id 903531808261; Tue, 8 Dec 2009 23:11:10 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Kevin In-Reply-To: <20091204202134.GA1716@garage.freebsd.pl> Date: Tue, 8 Dec 2009 17:11:10 -0600 Content-Transfer-Encoding: 7bit Message-Id: References: <30582AF2-B1E8-4C07-A487-C220845963D2@your.org> <20091204202134.GA1716@garage.freebsd.pl> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1076) Cc: freebsd-fs@freebsd.org Subject: Re: "zfs receive" lock time 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, 08 Dec 2009 23:11:11 -0000 On Dec 4, 2009, at 2:21 PM, Pawel Jakub Dawidek wrote: > On Wed, Dec 02, 2009 at 02:55:23PM -0600, Kevin wrote: >> >> If the slave is completely idle, "zfs receive" takes a fraction of a >> second. If the slave has been very busy (lots of read activity, no >> writes - the slave has everything mounted read only), suddenly "zfs >> receive" can take 30 seconds or more to complete, the whole time it >> has the filesystem locked. For example, I'd see: >> > > Read activity is related to the dataset on the slave that is being > received? Is that right? > Correct. > There are two operations that can suspend you file system this way: > rollback and receive. The suspend is done by acquiring write lock for > the given file system where every other operation acquires read lock. > In the end receive to acquire write lock has to wait for all read > operations to finish. > > I'm not sure how your applications use it, but if files are open for > short period of time only and then closed, you could do something like > this: > > master# curtime=`date "+%Y%m%d%H%M%S"` > master# zfs snapshot pool/fs@${curtime} > master# zfs send -i pool/fs@${oldtime} pool/fs@${curtime} | \ > ssh slave zfs recv pool/fs > slave# zfs clone pool/fs@${curtime} pool/fs_${curtime} > slave# ln -fs /pool/fs_${curtime} /pool/usethis > > Then point your application to use directory /pool/usethis/ (clone, > instead of received file system). And clean up clones as you wish. > Read activity on clones shouldn't affect received file system. This worked much much better, thank you! I'm still a little blurry on why "zfs receive" is so so so much slower (going from ms to >20s) if there's any read activity going on at all, but this seems to make it not matter to us. -- Kevin From owner-freebsd-fs@FreeBSD.ORG Tue Dec 8 23:20:58 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E57B106566B for ; Tue, 8 Dec 2009 23:20:58 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id 4D4FA8FC1A for ; Tue, 8 Dec 2009 23:20:56 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 7597945C9C; Wed, 9 Dec 2009 00:20:55 +0100 (CET) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 62CF3456B1; Wed, 9 Dec 2009 00:20:46 +0100 (CET) Date: Wed, 9 Dec 2009 00:20:46 +0100 From: Pawel Jakub Dawidek To: Kurt Touet Message-ID: <20091208232046.GB2466@garage.freebsd.pl> References: <2a5e326f0912061134s79c05e75td77e6874d409c675@mail.gmail.com> <20091207191048.GB1795@garage.freebsd.pl> <2a5e326f0912071203y35d45205n4566c1bb3260166d@mail.gmail.com> <20091207204012.GD1795@garage.freebsd.pl> <2a5e326f0912071259g840e88ejc9951137380d9f95@mail.gmail.com> <2a5e326f0912072106w58e31924ja8e22dc009665080@mail.gmail.com> <20091208102805.GH1795@garage.freebsd.pl> <2a5e326f0912081137l62abb81ap76f6c69350dc1196@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dTy3Mrz/UPE2dbVg" Content-Disposition: inline In-Reply-To: <2a5e326f0912081137l62abb81ap76f6c69350dc1196@mail.gmail.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: zpool create fails on gpart device 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, 08 Dec 2009 23:20:58 -0000 --dTy3Mrz/UPE2dbVg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 08, 2009 at 01:37:29PM -0600, Kurt Touet wrote: > kernel: vdev_geom_open_by_path:466[1]: Found provider by name /dev/da1p3. > kernel: vdev_geom_attach:112[1]: Attaching to da1p3. > kernel: vdev_geom_attach:133[1]: Created geom and consumer for da1p3. > kernel: vdev_geom_read_guid:301[1]: Reading guid from da1p3... > kernel: vdev_geom_detach:173[1]: Closing access to da1p3. > kernel: vdev_geom_detach:177[1]: Destroyed consumer to da1p3. > kernel: vdev_geom_detach:185[1]: Destroyed geom zfs::vdev. [...] > kernel: vdev_geom_open_by_guid:449[1]: Search by guid [164524661354887446= 36] failed. > kernel: vdev_geom_open_by_path:466[1]: Found provider by name /dev/da1p3. > kernel: vdev_geom_attach:112[1]: Attaching to da1p3. > kernel: vdev_geom_open:521[1]: Provider /dev/da1p3 not found. > root: ZFS: vdev failure, zpool=3Ddata type=3Dvdev.open_failed Actually I was wrong previously. You do have two those messages, there is just a log of other debug in-between. To diagnose this further, you could try this patch: http://people.freebsd.org/~pjd/patches/vdev_geom.c.patch And try to recreate with vfs.zfs.debug set to 1? --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --dTy3Mrz/UPE2dbVg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFLHt9NForvXbEpPzQRAvUqAJ9UpfzBkdvKdlkMNeyIsYpv0t19iACdHl6Z NglwmXwT6kqqbFDYPYJHs58= =ttEe -----END PGP SIGNATURE----- --dTy3Mrz/UPE2dbVg-- From owner-freebsd-fs@FreeBSD.ORG Tue Dec 8 23:44:59 2009 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA0451065679; Tue, 8 Dec 2009 23:44:59 +0000 (UTC) (envelope-from delphij@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BF0188FC12; Tue, 8 Dec 2009 23:44:59 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nB8NixJF019652; Tue, 8 Dec 2009 23:44:59 GMT (envelope-from delphij@freefall.freebsd.org) Received: (from delphij@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nB8Niw5S019648; Tue, 8 Dec 2009 23:44:58 GMT (envelope-from delphij) Date: Tue, 8 Dec 2009 23:44:58 GMT Message-Id: <200912082344.nB8Niw5S019648@freefall.freebsd.org> To: lampa@fit.vutbr.cz, delphij@FreeBSD.org, freebsd-fs@FreeBSD.org, delphij@FreeBSD.org From: delphij@FreeBSD.org Cc: Subject: Re: kern/141289: [nfs] [panic] newnfs panic "nfs sent cache" with IPv6 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, 08 Dec 2009 23:45:00 -0000 Synopsis: [nfs] [panic] newnfs panic "nfs sent cache" with IPv6 State-Changed-From-To: open->patched State-Changed-By: delphij State-Changed-When: Tue Dec 8 23:44:34 UTC 2009 State-Changed-Why: Patch applied against -HEAD, MFC reminder. Responsible-Changed-From-To: freebsd-fs->delphij Responsible-Changed-By: delphij Responsible-Changed-When: Tue Dec 8 23:44:34 UTC 2009 Responsible-Changed-Why: Take. http://www.freebsd.org/cgi/query-pr.cgi?pr=141289 From owner-freebsd-fs@FreeBSD.ORG Wed Dec 9 01:20:25 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 594AA1065695 for ; Wed, 9 Dec 2009 01:20:25 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nschwqsrv01p.mx.bigpond.com (nschwqsrv01p.mx.bigpond.com [61.9.189.231]) by mx1.freebsd.org (Postfix) with ESMTP id D7A118FC08 for ; Wed, 9 Dec 2009 01:20:24 +0000 (UTC) Received: from nschwotgx03p.mx.bigpond.com ([124.188.161.100]) by nschwmtas03p.mx.bigpond.com with ESMTP id <20091208224710.BZKY4789.nschwmtas03p.mx.bigpond.com@nschwotgx03p.mx.bigpond.com> for ; Tue, 8 Dec 2009 22:47:10 +0000 Received: from duncan.reilly.home ([124.188.161.100]) by nschwotgx03p.mx.bigpond.com with ESMTP id <20091208224710.XEVW7394.nschwotgx03p.mx.bigpond.com@duncan.reilly.home> for ; Tue, 8 Dec 2009 22:47:10 +0000 Date: Wed, 9 Dec 2009 09:47:10 +1100 From: Andrew Reilly To: freebsd-fs@freebsd.org Message-ID: <20091208224710.GA97620@duncan.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Authentication-Info: Submitted using SMTP AUTH LOGIN at nschwotgx03p.mx.bigpond.com from [124.188.161.100] using ID areilly@bigpond.net.au at Tue, 8 Dec 2009 22:47:10 +0000 X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150201.4B1ED76E.0089,ss=1,fgs=0 X-SIH-MSG-ID: rRwzEtP7TAD0zmQs0WyzOwJxyArnqyN48Z4QX81loRIGTUDCp8DeQ9rHNvZRtdu1xC5EJhiHNGUnaa3kTY3RstCK Subject: On gjournal vs unexpected shutdown (-->fsck) 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, 09 Dec 2009 01:20:25 -0000 Hi there, I thought that I'd try a gjournal'd UFS on one of my spare drives (so: dedicated to the task, formatted from clean, per the instructions in the gjournal man page.) The filesystem itself seems to be working swimmingly, although it isn't heavily used. In the time that I've had it running, though, I've had two power outages that have resulted in unexpected shutdowns, and I was surprised to find that the boot process did nothing unexpected: file system not marked clean: fsck before you can mount. So both times I fsck'd the drive, and as near as I can tell this took exactly as long as fsck on a regular UFS system of similar size. Isn't the journalling operation supposed to confer a shortcut benefit here? I know that the man page doesn't mention recovery by journal play-back, but I thought that it didn't need to: that's the whole point. Is there a step that I'm missing? Perhaps a gjournal-aware version of fsck that I should run instead of regular fsck, that will quickly mark the file system clean? (Running -current as of last weekend, if that matters.) Cheers, -- Andrew From owner-freebsd-fs@FreeBSD.ORG Wed Dec 9 04:24:23 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECBBA106566C; Wed, 9 Dec 2009 04:24:23 +0000 (UTC) (envelope-from ktouet@gmail.com) Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.210.171]) by mx1.freebsd.org (Postfix) with ESMTP id 901998FC14; Wed, 9 Dec 2009 04:24:23 +0000 (UTC) Received: by yxe1 with SMTP id 1so5699031yxe.3 for ; Tue, 08 Dec 2009 20:24:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fgpAlmoBNaKP/piLLjM5dkfNBF49vyYBNUBgDgy7Z4A=; b=fi8RliVy/qJAt/2Qi0gEcCKIKUv26oef0ZJvK1NHjgVnxCbAjfGA3rYSzJtcfHD40M Qi398iGAut1C7Klbgx8Sj83HRcwvUrOQZo8bgDl2reJju0EKOU2EtFF4fNe+FCiwxFoJ d08fJGfTSqKwjvInnOUNMKKvwsCBmb+gvuAek= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=j6AfIGYFqPW6+WjjeNU8U0jPFC9z+PIGEXh7lbqf1cEWK2fB1bETOJFdxG0KQX+41J RFnQ9eQMkgyYQj2Fk1Ik/iwi6MxuNzUt7jUmTy7xbxESBtpn9O7bs4RtSDuzOQLQg93c 62BHzualu6JcvdouUbv9trp+qWpjqQ6vwiDvw= MIME-Version: 1.0 Received: by 10.91.148.11 with SMTP id a11mr3067634ago.14.1260332662503; Tue, 08 Dec 2009 20:24:22 -0800 (PST) In-Reply-To: <20091208232046.GB2466@garage.freebsd.pl> References: <2a5e326f0912061134s79c05e75td77e6874d409c675@mail.gmail.com> <20091207191048.GB1795@garage.freebsd.pl> <2a5e326f0912071203y35d45205n4566c1bb3260166d@mail.gmail.com> <20091207204012.GD1795@garage.freebsd.pl> <2a5e326f0912071259g840e88ejc9951137380d9f95@mail.gmail.com> <2a5e326f0912072106w58e31924ja8e22dc009665080@mail.gmail.com> <20091208102805.GH1795@garage.freebsd.pl> <2a5e326f0912081137l62abb81ap76f6c69350dc1196@mail.gmail.com> <20091208232046.GB2466@garage.freebsd.pl> Date: Tue, 8 Dec 2009 22:24:22 -0600 Message-ID: <2a5e326f0912082024n4a3a0dfau983df9e0dc07f7ac@mail.gmail.com> From: Kurt Touet To: Pawel Jakub Dawidek Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: zpool create fails on gpart device 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, 09 Dec 2009 04:24:24 -0000 On Tue, Dec 8, 2009 at 5:20 PM, Pawel Jakub Dawidek wrote= : > On Tue, Dec 08, 2009 at 01:37:29PM -0600, Kurt Touet wrote: >> kernel: vdev_geom_open_by_path:466[1]: Found provider by name /dev/da1p3= . >> kernel: vdev_geom_attach:112[1]: Attaching to da1p3. >> kernel: vdev_geom_attach:133[1]: Created geom and consumer for da1p3. >> kernel: vdev_geom_read_guid:301[1]: Reading guid from da1p3... >> kernel: vdev_geom_detach:173[1]: Closing access to da1p3. >> kernel: vdev_geom_detach:177[1]: Destroyed consumer to da1p3. >> kernel: vdev_geom_detach:185[1]: Destroyed geom zfs::vdev. > [...] >> kernel: vdev_geom_open_by_guid:449[1]: Search by guid [16452466135488744= 636] failed. >> kernel: vdev_geom_open_by_path:466[1]: Found provider by name /dev/da1p3= . >> kernel: vdev_geom_attach:112[1]: Attaching to da1p3. >> kernel: vdev_geom_open:521[1]: Provider /dev/da1p3 not found. >> root: ZFS: vdev failure, zpool=3Ddata type=3Dvdev.open_failed > > Actually I was wrong previously. You do have two those messages, there > is just a log of other debug in-between. > > To diagnose this further, you could try this patch: > > =A0 =A0 =A0 =A0http://people.freebsd.org/~pjd/patches/vdev_geom.c.patch > > And try to recreate with vfs.zfs.debug set to 1? > > -- > Pawel Jakub Dawidek =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://ww= w.wheel.pl > pjd@FreeBSD.org =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http:= //www.FreeBSD.org > FreeBSD committer =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Am I Ev= il? Yes, I Am! > Sure thing: kernel: vdev_geom_open_by_path:472[1]: Found provider by name /dev/da1p3. kernel: vdev_geom_attach:112[1]: Attaching to da1p3. kernel: vdev_geom_attach:135[1]: Created geom and consumer for da1p3. kernel: vdev_geom_read_guid:307[1]: Reading guid from da1p3... kernel: vdev_geom_detach:179[1]: Closing access to da1p3. kernel: vdev_geom_detach:183[1]: Destroyed consumer to da1p3. kernel: vdev_geom_detach:191[1]: Destroyed geom zfs::vdev. kernel: vdev_geom_open_by_path:483[1]: guid mismatch for provider /dev/da1p3: 8873377865615214901 !=3D 0. kernel: vdev_geom_open_by_guid:441[1]: Searching by guid [88733778656152149= 01]. kernel: vdev_geom_read_guid:307[1]: Reading guid from acd0t01... kernel: vdev_geom_read_guid:307[1]: Reading guid from acd0... kernel: vdev_geom_read_guid:307[1]: Reading guid from da1p3... kernel: vdev_geom_read_guid:307[1]: Reading guid from da1p2... kernel: vdev_geom_read_guid:307[1]: Reading guid from da1p1... kernel: vdev_geom_read_guid:307[1]: Reading guid from da0s1f... kernel: vdev_geom_read_guid:307[1]: Reading guid from da0s1e... kernel: vdev_geom_read_guid:307[1]: Reading guid from da0s1d... kernel: vdev_geom_read_guid:307[1]: Reading guid from da0s1b... kernel: vdev_geom_read_guid:307[1]: Reading guid from da0s1a... kernel: vdev_geom_read_guid:307[1]: Reading guid from da0s1... kernel: vdev_geom_read_guid:307[1]: Reading guid from da1... kernel: vdev_geom_read_guid:307[1]: Reading guid from da0... kernel: vdev_geom_read_guid:307[1]: Reading guid from gptid/78398fed-e369-11de-a6aa-000c298c3c39... kernel: vdev_geom_read_guid:307[1]: Reading guid from ufsid/4b1c06d3f757961= 5... kernel: vdev_geom_read_guid:307[1]: Reading guid from gptid/663a8d5a-e293-11de-a6aa-000c298c3c39... kernel: vdev_geom_read_guid:307[1]: Reading guid from gptid/5ec68721-e293-11de-a6aa-000c298c3c39... kernel: vdev_geom_read_guid:307[1]: Reading guid from iso9660/FreeBSD_Insta= ll... kernel: vdev_geom_open_by_guid:455[1]: Search by guid [8873377865615214901] failed. kernel: vdev_geom_open_by_path:472[1]: Found provider by name /dev/da1p3. kernel: vdev_geom_attach:112[1]: Attaching to da1p3. kernel: vdev_geom_attach:132[1]: g_access() failed kernel: vdev_geom_open:527[1]: Provider /dev/da1p3 not found. root: ZFS: vdev failure, zpool=3Ddata type=3Dvdev.open_failed Does 132[1]: g_access() failed help you out? -kurt From owner-freebsd-fs@FreeBSD.ORG Wed Dec 9 08:36:40 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68884106566C for ; Wed, 9 Dec 2009 08:36:40 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id A57CA8FC13 for ; Wed, 9 Dec 2009 08:36:38 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id EBD5545CD8; Wed, 9 Dec 2009 09:36:36 +0100 (CET) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 93EBE45CAC; Wed, 9 Dec 2009 09:36:31 +0100 (CET) Date: Wed, 9 Dec 2009 09:36:31 +0100 From: Pawel Jakub Dawidek To: Kurt Touet Message-ID: <20091209083631.GC2466@garage.freebsd.pl> References: <2a5e326f0912061134s79c05e75td77e6874d409c675@mail.gmail.com> <20091207191048.GB1795@garage.freebsd.pl> <2a5e326f0912071203y35d45205n4566c1bb3260166d@mail.gmail.com> <20091207204012.GD1795@garage.freebsd.pl> <2a5e326f0912071259g840e88ejc9951137380d9f95@mail.gmail.com> <2a5e326f0912072106w58e31924ja8e22dc009665080@mail.gmail.com> <20091208102805.GH1795@garage.freebsd.pl> <2a5e326f0912081137l62abb81ap76f6c69350dc1196@mail.gmail.com> <20091208232046.GB2466@garage.freebsd.pl> <2a5e326f0912082024n4a3a0dfau983df9e0dc07f7ac@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VywGB/WGlW4DM4P8" Content-Disposition: inline In-Reply-To: <2a5e326f0912082024n4a3a0dfau983df9e0dc07f7ac@mail.gmail.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: zpool create fails on gpart device 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, 09 Dec 2009 08:36:40 -0000 --VywGB/WGlW4DM4P8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 08, 2009 at 10:24:22PM -0600, Kurt Touet wrote: > kernel: vdev_geom_open_by_path:472[1]: Found provider by name /dev/da1p3. > kernel: vdev_geom_attach:112[1]: Attaching to da1p3. > kernel: vdev_geom_attach:132[1]: g_access() failed > kernel: vdev_geom_open:527[1]: Provider /dev/da1p3 not found. > root: ZFS: vdev failure, zpool=3Ddata type=3Dvdev.open_failed >=20 > Does 132[1]: g_access() failed help you out? We are getting closer:) I'd need the output of those command: # gpart list da1 | grep -A3 'Name: da1p3' | tail -1 # sysctl -b kern.geom.confxml If the first command gives you 'r0w0e0' then we would need this updated patch: http://people.freebsd.org/~pjd/patches/vdev_geom.c.patch It looks like when your pool is trying to open provider it is already open by someone else. This is strange, because you said you can newfs and mount it without problems, so maybe something opens it temporairly. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --VywGB/WGlW4DM4P8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFLH2GOForvXbEpPzQRAgYWAKDgPyBpI9ate4f5sSzk8Z1cVNBjDwCg4hJ4 nYwiCbd3AUE+jMgiqdpE07c= =IsI/ -----END PGP SIGNATURE----- --VywGB/WGlW4DM4P8-- From owner-freebsd-fs@FreeBSD.ORG Wed Dec 9 13:02:23 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8524106566C for ; Wed, 9 Dec 2009 13:02:23 +0000 (UTC) (envelope-from nekoexmachina@gmail.com) Received: from mail-fx0-f209.google.com (mail-fx0-f209.google.com [209.85.220.209]) by mx1.freebsd.org (Postfix) with ESMTP id 83A0B8FC17 for ; Wed, 9 Dec 2009 13:02:23 +0000 (UTC) Received: by fxm2 with SMTP id 2so330810fxm.13 for ; Wed, 09 Dec 2009 05:02:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=eazs2LxAPKwFseI1X9jsEMJzJoQ4ZmtHmknzmSzs4HM=; b=k6T2+G6/cwr8hvWwuvFdTEzDfdfogphj6HzBMm0MlhnfL3ut750MwWFa4lpNsSoljO yiEcE7VNA/hXPkZoj2rpYycWxrxkzUmnimtgqGJMrZgvQTHr+pSnsEmhxRGVuA8Mfnhn NRDosdYbz1GZNhp/5iBz1/mBER6GOdssptAws= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=xUUIKS1hc7Wk2HbHJKmHVPGAaBxnpfMRPYwITlaLDTiDCbH0RTDsC8FfP5+jKY+ETA 8JzVphzMmnQJuplaDSep+QGGVscGI2uaQMTWGaVSp+RZ62EyFd0/zzUz6oce6stXSzbn h0z/5EIU0Fs3uMTE5arYfhjXIDoGLUPOsIYWU= MIME-Version: 1.0 Received: by 10.102.193.20 with SMTP id q20mr3223217muf.28.1260362290798; Wed, 09 Dec 2009 04:38:10 -0800 (PST) Date: Wed, 9 Dec 2009 12:38:10 +0000 Message-ID: <884554e60912090438h5811c06fx2f8ea8c93995c7bd@mail.gmail.com> From: Mikle Krutov To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: [8.0-RELEASE] ext2fs mount fails 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, 09 Dec 2009 13:02:24 -0000 Hello, I'm currently migrating one of my systems from linux to fbsd, and i've chosen the ext2 fs as most compatible one. Problem is, i cannot mount it. mount -t ext2fs /dev/ad8p1 /tmp/ext2/1 mount: /dev/ad8p1 : Invalid argument ext2fs: ad8p1: wrong magic number 0 (expected 0xef53) It mounts normally under linux, and i've fsck'd it. Also, under fbsd i cannot even run fsck: fsck_ext2fs /dev/ad8p1 e2fsck 1.41.9 (22-Aug-2009) /sbin/e2fsck: Superblock invalid, trying backup blocks... /sbin/e2fsck: Bad magic number in super-block while trying to open /dev/ad8p1 The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 I've found the sb backups with testdisk and tried the e2fsck -b -B - doesn't work, returns the very same message as above. Any suggestions? From owner-freebsd-fs@FreeBSD.ORG Wed Dec 9 13:24:41 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A416E106568F for ; Wed, 9 Dec 2009 13:24:41 +0000 (UTC) (envelope-from sarawgi.aditya@gmail.com) Received: from mail-px0-f190.google.com (mail-px0-f190.google.com [209.85.216.190]) by mx1.freebsd.org (Postfix) with ESMTP id 761A28FC13 for ; Wed, 9 Dec 2009 13:24:41 +0000 (UTC) Received: by pxi28 with SMTP id 28so1972059pxi.7 for ; Wed, 09 Dec 2009 05:24:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=tpxClbhE4FObvzYpC2qBXaJj82910rXOZoG17d9zXEg=; b=YAoqACV0uN2BnwisQHBzowASUW2iJbIdFbO4wSl8PcXpYBawpHv4lsjoJ27gCV+tXQ I4SR50QWURqN4527PvTffitzphuYi1ntyM92FLE1KPiZx8UvGZiBld3WCF/79+fDWCY+ yJ4BKlgc/fUDOOcKWINwe0yUXo7erV5u8kAwA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=lpbLq1216zEMcGH8eJqmOMGUyeQcZkG5ZNyyi6yM38a4WBmuHsO88Wg5HdBo1sVIg0 TS96tm+m0+jS+rHBPVJtwW3qxiSD6IZ6fdsZf3yoiBz9zF0R8PmUIVfQuBBlyE5OuKa5 ghwj5VMqE1oWryyfnpkVxJrCiUr+95wBWJ2hU= Received: by 10.115.84.21 with SMTP id m21mr3502646wal.109.1260365080739; Wed, 09 Dec 2009 05:24:40 -0800 (PST) Received: from ([183.87.28.86]) by mx.google.com with ESMTPS id 21sm6969875pzk.7.2009.12.09.05.24.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 09 Dec 2009 05:24:40 -0800 (PST) Date: Wed, 9 Dec 2009 18:55:21 +0000 From: Aditya Sarawgi To: Mikle Krutov Message-ID: <4b1fa518.9513f30a.3c39.ffffcab9@mx.google.com> References: <884554e60912090438h5811c06fx2f8ea8c93995c7bd@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <884554e60912090438h5811c06fx2f8ea8c93995c7bd@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-fs@freebsd.org Subject: Re: [8.0-RELEASE] ext2fs mount fails 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, 09 Dec 2009 13:24:41 -0000 On Wed, Dec 09, 2009 at 12:38:10PM +0000, Mikle Krutov wrote: > Hello, > I'm currently migrating one of my systems from linux to fbsd, and i've > chosen the ext2 fs as most compatible one. > Problem is, i cannot mount it. > mount -t ext2fs /dev/ad8p1 /tmp/ext2/1 > mount: /dev/ad8p1 : Invalid argument > ext2fs: ad8p1: wrong magic number 0 (expected 0xef53) > > It mounts normally under linux, and i've fsck'd it. > Also, under fbsd i cannot even run fsck: > fsck_ext2fs /dev/ad8p1 > e2fsck 1.41.9 (22-Aug-2009) > /sbin/e2fsck: Superblock invalid, trying backup blocks... > /sbin/e2fsck: Bad magic number in super-block while trying to open /dev/ad8p1 > > The superblock could not be read or does not describe a correct ext2 > filesystem. If the device is valid and it really contains an ext2 > filesystem (and not swap or ufs or something else), then the superblock > is corrupt, and you might try running e2fsck with an alternate superblock: > e2fsck -b 8193 > I've found the sb backups with testdisk and tried the e2fsck -b > -B - doesn't work, returns the > very same message as above. > Any suggestions? Firstly make sure that ad8p1 does infact have a ext2/3 filesytem. If it is try getting a dump by using dumpe2fs on freebsd(you need e2fsprogs from ports for this) or linux and mail me the dump. -- Aditya Sarawgi From owner-freebsd-fs@FreeBSD.ORG Wed Dec 9 14:12:30 2009 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C41A1065672; Wed, 9 Dec 2009 14:12:30 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 639DA8FC17; Wed, 9 Dec 2009 14:12:30 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nB9ECUHr044834; Wed, 9 Dec 2009 14:12:30 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nB9ECUn0044830; Wed, 9 Dec 2009 14:12:30 GMT (envelope-from linimon) Date: Wed, 9 Dec 2009 14:12:30 GMT Message-Id: <200912091412.nB9ECUn0044830@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/141305: [zfs] FreeBSD ZFS+sendfile severe performance issues (no 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: Wed, 09 Dec 2009 14:12:30 -0000 Old Synopsis: FreeBSD ZFS+sendfile severe performance issues (no cache) New Synopsis: [zfs] FreeBSD ZFS+sendfile severe performance issues (no cache) Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Wed Dec 9 14:12:12 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=141305 From owner-freebsd-fs@FreeBSD.ORG Wed Dec 9 15:19:10 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4257110656A3 for ; Wed, 9 Dec 2009 15:19:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id DD28B8FC2D for ; Wed, 9 Dec 2009 15:19:09 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 71D7F46B45; Wed, 9 Dec 2009 10:19:09 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 974158A020; Wed, 9 Dec 2009 10:19:08 -0500 (EST) From: John Baldwin To: Matt Reimer Date: Wed, 9 Dec 2009 10:15:15 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20091103; KDE/4.3.1; amd64; ; ) References: <200912080813.58600.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200912091015.15450.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 09 Dec 2009 10:19:08 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-fs@freebsd.org Subject: Re: PATCH: increase heap size for (gpt)zfsboot 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, 09 Dec 2009 15:19:10 -0000 On Tuesday 08 December 2009 6:06:14 pm Matt Reimer wrote: > On Tue, Dec 8, 2009 at 5:13 AM, John Baldwin wrote: > > On Monday 07 December 2009 7:01:03 pm Matt Reimer wrote: > >> Enlarge the heap size for gptzfsboot and zfsboot. This is necessary so > >> the ZFS code has enough memory to handle decompression and error > >> recovery. > >> > >> Before this patch the heap grew from the end of the (gpt)zfsboot code > >> and static data up to 640KB, possibly overrunning the stack. Now the > >> heap is located at 16MB-64MB. > >> > >> Note that this requires machines with at least 64MB RAM, but this is > >> not likely to be a problem on any machine running ZFS. > >> > >> Sponsored by: VPOP Technologies, Inc. > >> > >> Matt Reimer > > > > Unfortunately the 16M - 64M range may not all be useable RAM. It may contain > > ACPI tables, etc. A robust approach would involve walking the SMAP, etc. I > > just committed some changes to sys/boot/i386/loader/biosmem.c that make it > > smarter about choosing a heap region. I suggest adopting that algorithm for > > figuring out a safe heap range. zfsboot and gptzfsboot should have enough > > free space to take the bios_getmem() function. You can increase the minimum > > heap size beyond 3M if desired (though 3M is the minimum the loader will > > guarantee currently, and if ZFS needs more than that it likely needs to be > > changed in both places). > > Thanks John. I dropped the bios_getmem() into zfsboot.c and it works > for me. How's the attached patch look to you? I tweaked it slightly (memtop* aren't needed for gptboot, and memsize() isn't used anymore). Can you test the updated version below? Index: i386/zfsboot/zfsboot.c =================================================================== --- i386/zfsboot/zfsboot.c (revision 200271) +++ i386/zfsboot/zfsboot.c (working copy) @@ -27,6 +27,7 @@ #include #include +#include #include #include @@ -90,8 +91,6 @@ #define ARGS 0x900 #define NOPT 14 #define NDEV 3 -#define MEM_BASE 0x12 -#define MEM_EXT 0x15 #define V86_CY(x) ((x) & 1) #define V86_ZR(x) ((x) & 0x40) @@ -149,6 +148,19 @@ static uint32_t bootdev; static uint8_t ioctrl = IO_KEYBOARD; +vm_offset_t high_heap_base; +uint32_t bios_basemem, bios_extmem, high_heap_size; + +static struct bios_smap smap; + +/* + * The minimum amount of memory to reserve in bios_extmem for the heap. + */ +#define HEAP_MIN (3 * 1024 * 1024) + +static char *heap_next; +static char *heap_end; + /* Buffers that must not span a 64k boundary. */ #define READ_BUF_SIZE 8192 struct dmadat { @@ -162,7 +174,7 @@ static int parse(void); static void printf(const char *,...); static void putchar(int); -static uint32_t memsize(void); +static void bios_getmem(void); static int drvread(struct dsk *, void *, daddr_t, unsigned); static int keyhit(unsigned); static int xputc(int); @@ -237,14 +249,6 @@ static void * malloc(size_t n) { - static char *heap_next; - static char *heap_end; - - if (!heap_next) { - heap_next = (char *) dmadat + sizeof(*dmadat); - heap_end = (char *) (640*1024); - } - char *p = heap_next; if (p + n > heap_end) { printf("malloc failure\n"); @@ -344,15 +348,92 @@ return 0; } -static inline uint32_t -memsize(void) +static inline void +bios_getmem(void) { - v86.addr = MEM_EXT; - v86.eax = 0x8800; - v86int(); - return v86.eax; -} + uint64_t size; + /* Parse system memory map */ + v86.ebx = 0; + do { + v86.ctl = V86_FLAGS; + v86.addr = 0x15; /* int 0x15 function 0xe820*/ + v86.eax = 0xe820; + v86.ecx = sizeof(struct bios_smap); + v86.edx = SMAP_SIG; + v86.es = VTOPSEG(&smap); + v86.edi = VTOPOFF(&smap); + v86int(); + if ((v86.efl & 1) || (v86.eax != SMAP_SIG)) + break; + /* look for a low-memory segment that's large enough */ + if ((smap.type == SMAP_TYPE_MEMORY) && (smap.base == 0) && + (smap.length >= (512 * 1024))) + bios_basemem = smap.length; + /* look for the first segment in 'extended' memory */ + if ((smap.type == SMAP_TYPE_MEMORY) && (smap.base == 0x100000)) { + bios_extmem = smap.length; + } + + /* + * Look for the largest segment in 'extended' memory beyond + * 1MB but below 4GB. + */ + if ((smap.type == SMAP_TYPE_MEMORY) && (smap.base > 0x100000) && + (smap.base < 0x100000000ull)) { + size = smap.length; + + /* + * If this segment crosses the 4GB boundary, truncate it. + */ + if (smap.base + size > 0x100000000ull) + size = 0x100000000ull - smap.base; + + if (size > high_heap_size) { + high_heap_size = size; + high_heap_base = smap.base; + } + } + } while (v86.ebx != 0); + + /* Fall back to the old compatibility function for base memory */ + if (bios_basemem == 0) { + v86.ctl = 0; + v86.addr = 0x12; /* int 0x12 */ + v86int(); + + bios_basemem = (v86.eax & 0xffff) * 1024; + } + + /* Fall back through several compatibility functions for extended memory */ + if (bios_extmem == 0) { + v86.ctl = V86_FLAGS; + v86.addr = 0x15; /* int 0x15 function 0xe801*/ + v86.eax = 0xe801; + v86int(); + if (!(v86.efl & 1)) { + bios_extmem = ((v86.ecx & 0xffff) + ((v86.edx & 0xffff) * 64)) * 1024; + } + } + if (bios_extmem == 0) { + v86.ctl = 0; + v86.addr = 0x15; /* int 0x15 function 0x88*/ + v86.eax = 0x8800; + v86int(); + bios_extmem = (v86.eax & 0xffff) * 1024; + } + + /* + * If we have extended memory and did not find a suitable heap + * region in the SMAP, use the last 3MB of 'extended' memory as a + * high heap candidate. + */ + if (bios_extmem >= HEAP_MIN && high_heap_size < HEAP_MIN) { + high_heap_size = HEAP_MIN; + high_heap_base = bios_extmem + 0x100000 - HEAP_MIN; + } +} + static inline void getstr(void) { @@ -536,6 +617,16 @@ off_t off; struct dsk *dsk; + bios_getmem(); + + if (high_heap_size > 0) { + heap_end = PTOV(high_heap_base + high_heap_size); + heap_next = PTOV(high_heap_base); + } else { + heap_next = (char *) dmadat + sizeof(*dmadat); + heap_end = (char *) PTOV(bios_basemem); + } + dmadat = (void *)(roundup2(__base + (int32_t)&_end, 0x10000) - __base); v86.ctl = V86_FLAGS; @@ -550,8 +641,8 @@ bootinfo.bi_version = BOOTINFO_VERSION; bootinfo.bi_size = sizeof(bootinfo); - bootinfo.bi_basemem = 0; /* XXX will be filled by loader or kernel */ - bootinfo.bi_extmem = memsize(); + bootinfo.bi_basemem = bios_basemem / 1024; + bootinfo.bi_extmem = bios_extmem / 1024; bootinfo.bi_memsizes_valid++; bootinfo.bi_bios_dev = dsk->drive; Index: zfs/zfsimpl.c =================================================================== --- zfs/zfsimpl.c (revision 200271) +++ zfs/zfsimpl.c (working copy) @@ -51,7 +51,7 @@ static char *zap_scratch; static char *zfs_temp_buf, *zfs_temp_end, *zfs_temp_ptr; -#define TEMP_SIZE (1*SPA_MAXBLOCKSIZE) +#define TEMP_SIZE (1024 * 1024) static int zio_read(spa_t *spa, const blkptr_t *bp, void *buf); -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Wed Dec 9 18:00:49 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DF051065679; Wed, 9 Dec 2009 18:00:49 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from mail-yw0-f194.google.com (mail-yw0-f194.google.com [209.85.211.194]) by mx1.freebsd.org (Postfix) with ESMTP id C947F8FC16; Wed, 9 Dec 2009 18:00:48 +0000 (UTC) Received: by ywh32 with SMTP id 32so7147873ywh.14 for ; Wed, 09 Dec 2009 10:00:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Lb35aUgAQinNpJK2cuJa0Q1Br/ZXefQlqHMtn6Fq25E=; b=dzte4mX7E7+BJCVpE8ZdTSJ0+tb5ToaORFING7vMJS8DlKFfkutL4EJbW6+rjjb0s7 f23RAzS3Gf6lVpweMLtBN6X+q0i20fY3+V4HnB2FaonDDHPXLIgRsl8oMHYc2YHdP0JD O8eX7h7n2AOWNQCyX8MkPxsqJPrjsSRb+XiSc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pa6CKmOiELH6D3OUJuCala4drl/13QsvnEAn29DszgeBusdAMOj2Z9w0UTOEvW3+QB E4I/N1uEL4nM4ubqxVCz+Vp0xVgPJLftQUMtgGJtbzAVhaPINonteqjbel2XhxLo4wCP SYLfMW7mwFEbql78z84UqqaLthIzGqugTfNDs= MIME-Version: 1.0 Received: by 10.150.108.32 with SMTP id g32mr16896651ybc.244.1260381647831; Wed, 09 Dec 2009 10:00:47 -0800 (PST) In-Reply-To: <200912091015.15450.jhb@freebsd.org> References: <200912080813.58600.jhb@freebsd.org> <200912091015.15450.jhb@freebsd.org> Date: Wed, 9 Dec 2009 10:00:47 -0800 Message-ID: From: Matt Reimer To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: PATCH: increase heap size for (gpt)zfsboot 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, 09 Dec 2009 18:00:49 -0000 On Wed, Dec 9, 2009 at 7:15 AM, John Baldwin wrote: > On Tuesday 08 December 2009 6:06:14 pm Matt Reimer wrote: >> On Tue, Dec 8, 2009 at 5:13 AM, John Baldwin wrote: >> > On Monday 07 December 2009 7:01:03 pm Matt Reimer wrote: >> >> Enlarge the heap size for gptzfsboot and zfsboot. This is necessary s= o >> >> the ZFS code has enough memory to handle decompression and error >> >> recovery. >> >> >> >> Before this patch the heap grew from the end of the (gpt)zfsboot code >> >> and static data up to 640KB, possibly overrunning the stack. Now the >> >> heap is located at 16MB-64MB. >> >> >> >> Note that this requires machines with at least 64MB RAM, but this is >> >> not likely to be a problem on any machine running ZFS. >> >> >> >> Sponsored by: VPOP Technologies, Inc. >> >> >> >> Matt Reimer >> > >> > Unfortunately the 16M - 64M range may not all be useable RAM. =A0It ma= y contain >> > ACPI tables, etc. =A0A robust approach would involve walking the SMAP,= etc. =A0I >> > just committed some changes to sys/boot/i386/loader/biosmem.c that mak= e it >> > smarter about choosing a heap region. =A0I suggest adopting that algor= ithm for >> > figuring out a safe heap range. =A0zfsboot and gptzfsboot should have = enough >> > free space to take the bios_getmem() function. =A0You can increase the= minimum >> > heap size beyond 3M if desired (though 3M is the minimum the loader wi= ll >> > guarantee currently, and if ZFS needs more than that it likely needs t= o be >> > changed in both places). >> >> Thanks John. I dropped the bios_getmem() into zfsboot.c and it works >> for me. How's the attached patch look to you? > > I tweaked it slightly (memtop* aren't needed for gptboot, and memsize() i= sn't > used anymore). =A0Can you test the updated version below? It works. But making bios_getmem() inline causes a compiler warning: /usr/src/sys/boot/i386/gptzfsboot/../zfsboot/zfsboot.c: In function 'main': /usr/src/sys/boot/i386/gptzfsboot/../zfsboot/zfsboot.c:353: warning: inlining failed in call to 'bios_getmem': --param max-inline-insns-single limit reached /usr/src/sys/boot/i386/gptzfsboot/../zfsboot/zfsboot.c:620: warning: called from here Matt From owner-freebsd-fs@FreeBSD.ORG Wed Dec 9 19:17:50 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5535106566C; Wed, 9 Dec 2009 19:17:50 +0000 (UTC) (envelope-from ktouet@gmail.com) Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.210.171]) by mx1.freebsd.org (Postfix) with ESMTP id 49F828FC1E; Wed, 9 Dec 2009 19:17:49 +0000 (UTC) Received: by yxe1 with SMTP id 1so6334541yxe.3 for ; Wed, 09 Dec 2009 11:17:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=XBo9x7zwJzTMv01kfmgSLdh3iIggZNV0bfx24Q5pKrk=; b=lIlTEh8YhgcsT+8N2E9ZFZvYMR2o9UW7Jm4KC/I9lgvb3kGHf26jjhJra0Xw0O8oBN hA9shJD2ymkBY+hgvZwoDfwoAPLXtPVBY6KVsRvG4OpbmFvReYfb3Ecf0mqH5We2sfZq F9aTau2i9m8RZraP9s5IP2Orl5YFMTiSF69i4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hqQY86n8AMnGxSRDS2H98pZueL2QB9Q+5BSQuiSLpk7RTJVh0gblZ3HZDEYUFD86Ge zTlGjVEXH5Q3+etpKgvGCASSLS44fIwb5Z6QwXNsHFGw+rVTKt71umvawxkw6umn2m6D FHyPwBuXe+0umwiCgzPTb/y2PBQ94hJgQ0u20= MIME-Version: 1.0 Received: by 10.90.253.16 with SMTP id a16mr2586604agi.3.1260386269063; Wed, 09 Dec 2009 11:17:49 -0800 (PST) In-Reply-To: <20091209083631.GC2466@garage.freebsd.pl> References: <2a5e326f0912061134s79c05e75td77e6874d409c675@mail.gmail.com> <2a5e326f0912071203y35d45205n4566c1bb3260166d@mail.gmail.com> <20091207204012.GD1795@garage.freebsd.pl> <2a5e326f0912071259g840e88ejc9951137380d9f95@mail.gmail.com> <2a5e326f0912072106w58e31924ja8e22dc009665080@mail.gmail.com> <20091208102805.GH1795@garage.freebsd.pl> <2a5e326f0912081137l62abb81ap76f6c69350dc1196@mail.gmail.com> <20091208232046.GB2466@garage.freebsd.pl> <2a5e326f0912082024n4a3a0dfau983df9e0dc07f7ac@mail.gmail.com> <20091209083631.GC2466@garage.freebsd.pl> Date: Wed, 9 Dec 2009 13:17:48 -0600 Message-ID: <2a5e326f0912091117x708968edlcde85a8997d1232b@mail.gmail.com> From: Kurt Touet To: Pawel Jakub Dawidek Content-Type: multipart/mixed; boundary=001636284e4ad8fa71047a508b0a X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: Re: zpool create fails on gpart device 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, 09 Dec 2009 19:17:50 -0000 --001636284e4ad8fa71047a508b0a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Dec 9, 2009 at 2:36 AM, Pawel Jakub Dawidek wrote= : > On Tue, Dec 08, 2009 at 10:24:22PM -0600, Kurt Touet wrote: >> kernel: vdev_geom_open_by_path:472[1]: Found provider by name /dev/da1p3= . >> kernel: vdev_geom_attach:112[1]: Attaching to da1p3. >> kernel: vdev_geom_attach:132[1]: g_access() failed >> kernel: vdev_geom_open:527[1]: Provider /dev/da1p3 not found. >> root: ZFS: vdev failure, zpool=3Ddata type=3Dvdev.open_failed >> >> Does 132[1]: g_access() failed =A0 help you out? > > We are getting closer:) > > I'd need the output of those command: > > =A0 =A0 =A0 =A0# gpart list da1 | grep -A3 'Name: da1p3' | tail -1 > =A0 =A0 =A0 =A0# sysctl -b kern.geom.confxml > > If the first command gives you 'r0w0e0' then we would need this updated > patch: > > =A0 =A0 =A0 =A0http://people.freebsd.org/~pjd/patches/vdev_geom.c.patch > > It looks like when your pool is trying to open provider it is already > open by someone else. This is strange, because you said you can newfs > and mount it without problems, so maybe something opens it temporairly. > > -- > Pawel Jakub Dawidek =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://ww= w.wheel.pl > pjd@FreeBSD.org =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http:= //www.FreeBSD.org > FreeBSD committer =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Am I Ev= il? Yes, I Am! > # gpart list da1 | grep -A3 'Name: da1p3' | tail -1 Mode: r0w0e0 The output from sysctl -b kern.geom.confxml is attached. I will grab the patch and send back results from that later today. -kurt --001636284e4ad8fa71047a508b0a-- From owner-freebsd-fs@FreeBSD.ORG Wed Dec 9 20:32:08 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30FAB106566B for ; Wed, 9 Dec 2009 20:32:08 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 003F28FC16 for ; Wed, 9 Dec 2009 20:32:07 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id A5A2D46B2A; Wed, 9 Dec 2009 15:32:07 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id D51B58A020; Wed, 9 Dec 2009 15:32:06 -0500 (EST) From: John Baldwin To: Matt Reimer Date: Wed, 9 Dec 2009 15:31:42 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20091103; KDE/4.3.1; amd64; ; ) References: <200912091015.15450.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200912091531.42421.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 09 Dec 2009 15:32:06 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-fs@freebsd.org Subject: Re: PATCH: increase heap size for (gpt)zfsboot 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, 09 Dec 2009 20:32:08 -0000 On Wednesday 09 December 2009 1:00:47 pm Matt Reimer wrote: > On Wed, Dec 9, 2009 at 7:15 AM, John Baldwin wrote: > > On Tuesday 08 December 2009 6:06:14 pm Matt Reimer wrote: > >> On Tue, Dec 8, 2009 at 5:13 AM, John Baldwin wrote: > >> > On Monday 07 December 2009 7:01:03 pm Matt Reimer wrote: > >> >> Enlarge the heap size for gptzfsboot and zfsboot. This is necessary so > >> >> the ZFS code has enough memory to handle decompression and error > >> >> recovery. > >> >> > >> >> Before this patch the heap grew from the end of the (gpt)zfsboot code > >> >> and static data up to 640KB, possibly overrunning the stack. Now the > >> >> heap is located at 16MB-64MB. > >> >> > >> >> Note that this requires machines with at least 64MB RAM, but this is > >> >> not likely to be a problem on any machine running ZFS. > >> >> > >> >> Sponsored by: VPOP Technologies, Inc. > >> >> > >> >> Matt Reimer > >> > > >> > Unfortunately the 16M - 64M range may not all be useable RAM. It may contain > >> > ACPI tables, etc. A robust approach would involve walking the SMAP, etc. I > >> > just committed some changes to sys/boot/i386/loader/biosmem.c that make it > >> > smarter about choosing a heap region. I suggest adopting that algorithm for > >> > figuring out a safe heap range. zfsboot and gptzfsboot should have enough > >> > free space to take the bios_getmem() function. You can increase the minimum > >> > heap size beyond 3M if desired (though 3M is the minimum the loader will > >> > guarantee currently, and if ZFS needs more than that it likely needs to be > >> > changed in both places). > >> > >> Thanks John. I dropped the bios_getmem() into zfsboot.c and it works > >> for me. How's the attached patch look to you? > > > > I tweaked it slightly (memtop* aren't needed for gptboot, and memsize() isn't > > used anymore). Can you test the updated version below? > > It works. But making bios_getmem() inline causes a compiler warning: > > /usr/src/sys/boot/i386/gptzfsboot/../zfsboot/zfsboot.c: In function 'main': > /usr/src/sys/boot/i386/gptzfsboot/../zfsboot/zfsboot.c:353: warning: > inlining failed in call to 'bios_getmem': --param > max-inline-insns-single limit reached > /usr/src/sys/boot/i386/gptzfsboot/../zfsboot/zfsboot.c:620: warning: > called from here Ok, the inline is probably not needed for zfsboot since it isn't quite as space constrained. I will commit it w/o the inline. -- John Baldwin From owner-freebsd-fs@FreeBSD.ORG Wed Dec 9 20:48:11 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE0381065672; Wed, 9 Dec 2009 20:48:10 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from mail-px0-f190.google.com (mail-px0-f190.google.com [209.85.216.190]) by mx1.freebsd.org (Postfix) with ESMTP id 9C0F08FC15; Wed, 9 Dec 2009 20:48:10 +0000 (UTC) Received: by pxi28 with SMTP id 28so2275687pxi.7 for ; Wed, 09 Dec 2009 12:48:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BsoNuhp3xPV/IxJPtfqvvDtXjAOg+dDGO9Xg1+LqVh8=; b=oYQOBasKDkmOHj2/zrRedvxqNVMa20JToFsNsUyCrib1I8nV1uWEjcYCwsuXEs2PFs ioeDXf5yMW1xRbMyVIM8bhTruFOawQFj6g7xcFurd42obIAZkSS4SeAz+QE3tcuN9PRY OSKI2hUPv4+9NhdGIkZ6E6Int8e0YqttgXzVA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Afcp6QjK4hp6IgCTyyZug1lkhp2coaqnJBk7T9cp9ao3H33zixqZMelvGkcT6SJCEr 2mfR6yv+XG4oqx18Q22gWPpSy1OiPLXIFH6AHvM5Wn80z6Zard3cEpjaZTCL3UoIRbT6 S+Qf6MtissYW13jeFKdh04ZEdAzSCOkEEyTFs= MIME-Version: 1.0 Received: by 10.143.154.14 with SMTP id g14mr1503587wfo.266.1260391689541; Wed, 09 Dec 2009 12:48:09 -0800 (PST) In-Reply-To: <200912091531.42421.jhb@freebsd.org> References: <200912091015.15450.jhb@freebsd.org> <200912091531.42421.jhb@freebsd.org> Date: Wed, 9 Dec 2009 12:48:08 -0800 Message-ID: From: Matt Reimer To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: PATCH: increase heap size for (gpt)zfsboot 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, 09 Dec 2009 20:48:11 -0000 On Wed, Dec 9, 2009 at 12:31 PM, John Baldwin wrote: > On Wednesday 09 December 2009 1:00:47 pm Matt Reimer wrote: >> On Wed, Dec 9, 2009 at 7:15 AM, John Baldwin wrote: >> > On Tuesday 08 December 2009 6:06:14 pm Matt Reimer wrote: >> >> On Tue, Dec 8, 2009 at 5:13 AM, John Baldwin wrote: >> >> > On Monday 07 December 2009 7:01:03 pm Matt Reimer wrote: >> >> >> Enlarge the heap size for gptzfsboot and zfsboot. This is necessar= y so >> >> >> the ZFS code has enough memory to handle decompression and error >> >> >> recovery. >> >> >> >> >> >> Before this patch the heap grew from the end of the (gpt)zfsboot c= ode >> >> >> and static data up to 640KB, possibly overrunning the stack. Now t= he >> >> >> heap is located at 16MB-64MB. >> >> >> >> >> >> Note that this requires machines with at least 64MB RAM, but this = is >> >> >> not likely to be a problem on any machine running ZFS. >> >> >> >> >> >> Sponsored by: VPOP Technologies, Inc. >> >> >> >> >> >> Matt Reimer >> >> > >> >> > Unfortunately the 16M - 64M range may not all be useable RAM. =A0It= may contain >> >> > ACPI tables, etc. =A0A robust approach would involve walking the SM= AP, etc. =A0I >> >> > just committed some changes to sys/boot/i386/loader/biosmem.c that = make it >> >> > smarter about choosing a heap region. =A0I suggest adopting that al= gorithm for >> >> > figuring out a safe heap range. =A0zfsboot and gptzfsboot should ha= ve enough >> >> > free space to take the bios_getmem() function. =A0You can increase = the minimum >> >> > heap size beyond 3M if desired (though 3M is the minimum the loader= will >> >> > guarantee currently, and if ZFS needs more than that it likely need= s to be >> >> > changed in both places). >> >> >> >> Thanks John. I dropped the bios_getmem() into zfsboot.c and it works >> >> for me. How's the attached patch look to you? >> > >> > I tweaked it slightly (memtop* aren't needed for gptboot, and memsize(= ) isn't >> > used anymore). =A0Can you test the updated version below? >> >> It works. But making bios_getmem() inline causes a compiler warning: >> >> /usr/src/sys/boot/i386/gptzfsboot/../zfsboot/zfsboot.c: In function 'mai= n': >> /usr/src/sys/boot/i386/gptzfsboot/../zfsboot/zfsboot.c:353: warning: >> inlining failed in call to 'bios_getmem': --param >> max-inline-insns-single limit reached >> /usr/src/sys/boot/i386/gptzfsboot/../zfsboot/zfsboot.c:620: warning: >> called from here > > Ok, the inline is probably not needed for zfsboot since it isn't quite as > space constrained. =A0I will commit it w/o the inline. Thanks for committing this John. Matt From owner-freebsd-fs@FreeBSD.ORG Wed Dec 9 21:20:32 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9661D106566C; Wed, 9 Dec 2009 21:20:32 +0000 (UTC) (envelope-from ktouet@gmail.com) Received: from mail-gx0-f214.google.com (mail-gx0-f214.google.com [209.85.217.214]) by mx1.freebsd.org (Postfix) with ESMTP id 387938FC08; Wed, 9 Dec 2009 21:20:31 +0000 (UTC) Received: by gxk6 with SMTP id 6so5894757gxk.13 for ; Wed, 09 Dec 2009 13:20:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=opzVSO56Oxw42RJI4KrZAzZvGC8DbFiLJdKQZv6L1no=; b=T2CkBPMhp27Ch2DFp8j8ex8caJ5IPB0/C2Rl+j+rWs3kLFlSJb0qoBn/oXw1Yo7p44 SUUODM7aRXLXKzjaVqvsBChFHsAgJiBUGMltOzaN/IGC2/ZJe063ruBsAH/Q90ltH7ju gM1ihLZQSNd6eXeoEqmMzd7xfVkbF+65Lthqc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WTY+RpvRJvfVbxl90fcWo+iuNcp8BwKP/yo3R5FeG5R0TcZH2Qfz0lLnML1TT9hc/m QhnoaYMhqz++1ODF0FJaFQB62RI0M2eADKpWULMd9HdiFZ3M0UhyERaf6hMedlUXgi0g QBLRNVbT06Zkuggl/BTEeOZHJ4HvJb7JCL85I= MIME-Version: 1.0 Received: by 10.91.105.3 with SMTP id h3mr4328340agm.6.1260393631331; Wed, 09 Dec 2009 13:20:31 -0800 (PST) In-Reply-To: <2a5e326f0912091117x708968edlcde85a8997d1232b@mail.gmail.com> References: <2a5e326f0912061134s79c05e75td77e6874d409c675@mail.gmail.com> <20091207204012.GD1795@garage.freebsd.pl> <2a5e326f0912071259g840e88ejc9951137380d9f95@mail.gmail.com> <2a5e326f0912072106w58e31924ja8e22dc009665080@mail.gmail.com> <20091208102805.GH1795@garage.freebsd.pl> <2a5e326f0912081137l62abb81ap76f6c69350dc1196@mail.gmail.com> <20091208232046.GB2466@garage.freebsd.pl> <2a5e326f0912082024n4a3a0dfau983df9e0dc07f7ac@mail.gmail.com> <20091209083631.GC2466@garage.freebsd.pl> <2a5e326f0912091117x708968edlcde85a8997d1232b@mail.gmail.com> Date: Wed, 9 Dec 2009 15:20:31 -0600 Message-ID: <2a5e326f0912091320t25ecf91ag90daa5e36029c0f4@mail.gmail.com> From: Kurt Touet To: Pawel Jakub Dawidek Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: zpool create fails on gpart device 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, 09 Dec 2009 21:20:32 -0000 On Wed, Dec 9, 2009 at 1:17 PM, Kurt Touet wrote: > On Wed, Dec 9, 2009 at 2:36 AM, Pawel Jakub Dawidek wro= te: >> On Tue, Dec 08, 2009 at 10:24:22PM -0600, Kurt Touet wrote: >>> kernel: vdev_geom_open_by_path:472[1]: Found provider by name /dev/da1p= 3. >>> kernel: vdev_geom_attach:112[1]: Attaching to da1p3. >>> kernel: vdev_geom_attach:132[1]: g_access() failed >>> kernel: vdev_geom_open:527[1]: Provider /dev/da1p3 not found. >>> root: ZFS: vdev failure, zpool=3Ddata type=3Dvdev.open_failed >>> >>> Does 132[1]: g_access() failed =A0 help you out? >> >> We are getting closer:) >> >> I'd need the output of those command: >> >> =A0 =A0 =A0 =A0# gpart list da1 | grep -A3 'Name: da1p3' | tail -1 >> =A0 =A0 =A0 =A0# sysctl -b kern.geom.confxml >> >> If the first command gives you 'r0w0e0' then we would need this updated >> patch: >> >> =A0 =A0 =A0 =A0http://people.freebsd.org/~pjd/patches/vdev_geom.c.patch >> >> It looks like when your pool is trying to open provider it is already >> open by someone else. This is strange, because you said you can newfs >> and mount it without problems, so maybe something opens it temporairly. >> >> -- >> Pawel Jakub Dawidek =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://w= ww.wheel.pl >> pjd@FreeBSD.org =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http= ://www.FreeBSD.org >> FreeBSD committer =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Am I E= vil? Yes, I Am! >> > > # gpart list da1 | grep -A3 'Name: da1p3' | tail -1 > =A0 Mode: r0w0e0 > > The output from sysctl -b kern.geom.confxml is attached. > > I will grab the patch and send back results from that later today. > -kurt > With the patch: # sysctl vfs.zfs.debug=3D1 vfs.zfs.debug: 0 -> 1 # zpool create data /dev/da1p3 cannot create 'data': permission denied kernel: vdev_geom_open_by_path:487[1]: Found provider by name /dev/da1p3. kernel: vdev_geom_attach:112[1]: Attaching to da1p3. kernel: vdev_geom_attach:140[1]: Created geom and consumer for da1p3. kernel: vdev_geom_read_guid:322[1]: Reading guid from da1p3... kernel: vdev_geom_detach:194[1]: Closing access to da1p3. kernel: vdev_geom_detach:198[1]: Destroyed consumer to da1p3. kernel: vdev_geom_detach:206[1]: Destroyed geom zfs::vdev. kernel: vdev_geom_open_by_path:498[1]: guid mismatch for provider /dev/da1p3: 9777046094809499960 !=3D 0. kernel: vdev_geom_open_by_guid:456[1]: Searching by guid [97770460948094999= 60]. kernel: vdev_geom_read_guid:322[1]: Reading guid from acd0t01... kernel: vdev_geom_read_guid:322[1]: Reading guid from acd0... kernel: vdev_geom_read_guid:322[1]: Reading guid from da1p3... kernel: vdev_geom_read_guid:322[1]: Reading guid from da1p2... kernel: vdev_geom_read_guid:322[1]: Reading guid from da1p1... kernel: vdev_geom_read_guid:322[1]: Reading guid from da0s1f... kernel: vdev_geom_read_guid:322[1]: Reading guid from da0s1e... kernel: vdev_geom_read_guid:322[1]: Reading guid from da0s1d... kernel: vdev_geom_read_guid:322[1]: Reading guid from da0s1b... kernel: vdev_geom_read_guid:322[1]: Reading guid from da0s1a... kernel: vdev_geom_read_guid:322[1]: Reading guid from da0s1... kernel: vdev_geom_read_guid:322[1]: Reading guid from da1... kernel: vdev_geom_read_guid:322[1]: Reading guid from da0... kernel: vdev_geom_read_guid:322[1]: Reading guid from gptid/78398fed-e369-11de-a6aa-000c298c3c39... kernel: vdev_geom_read_guid:322[1]: Reading guid from ufsid/4b1c06d3f757961= 5... kernel: vdev_geom_read_guid:322[1]: Reading guid from gptid/663a8d5a-e293-11de-a6aa-000c298c3c39... kernel: vdev_geom_read_guid:322[1]: Reading guid from gptid/5ec68721-e293-11de-a6aa-000c298c3c39... kernel: vdev_geom_read_guid:322[1]: Reading guid from iso9660/FreeBSD_Insta= ll... kernel: vdev_geom_open_by_guid:470[1]: Search by guid [9777046094809499960] failed. kernel: vdev_geom_open_by_path:487[1]: Found provider by name /dev/da1p3. kernel: vdev_geom_attach:112[1]: Attaching to da1p3. kernel: vdev_geom_attach:132[1]: g_access() failed kernel: vdev_geom_attach:136[1]: cp=3D0xffffff0002b70480 r0w0e0 geom=3Dzfs::vdev class=3DZFS::VDEV kernel: vdev_geom_attach:136[1]: cp=3D0xffffff000263bd00 r1w0e1 geom=3Dda1p3 class=3DLABEL kernel: vdev_geom_attach:136[1]: cp=3D0xffffff000263bd80 r0w0e0 geom=3Dda1p3 class=3DLABEL kernel: vdev_geom_attach:136[1]: cp=3D0xffffff000272d180 r0w0e0 geom=3Dda1p3 class=3DPART kernel: vdev_geom_attach:136[1]: cp=3D0xffffff0002639580 r0w0e0 geom=3Dda1p3 class=3DDEV kernel: vdev_geom_open:542[1]: Provider /dev/da1p3 not found. root: ZFS: vdev failure, zpool=3Ddata type=3Dvdev.open_failed From owner-freebsd-fs@FreeBSD.ORG Wed Dec 9 23:27:55 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51EB31065679 for ; Wed, 9 Dec 2009 23:27:55 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id 89E6A8FC16 for ; Wed, 9 Dec 2009 23:27:54 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 45F0A45CA6; Thu, 10 Dec 2009 00:27:51 +0100 (CET) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 4622845CD9; Thu, 10 Dec 2009 00:27:46 +0100 (CET) Date: Thu, 10 Dec 2009 00:27:44 +0100 From: Pawel Jakub Dawidek To: Kurt Touet Message-ID: <20091209232744.GB4177@garage.freebsd.pl> References: <20091207204012.GD1795@garage.freebsd.pl> <2a5e326f0912071259g840e88ejc9951137380d9f95@mail.gmail.com> <2a5e326f0912072106w58e31924ja8e22dc009665080@mail.gmail.com> <20091208102805.GH1795@garage.freebsd.pl> <2a5e326f0912081137l62abb81ap76f6c69350dc1196@mail.gmail.com> <20091208232046.GB2466@garage.freebsd.pl> <2a5e326f0912082024n4a3a0dfau983df9e0dc07f7ac@mail.gmail.com> <20091209083631.GC2466@garage.freebsd.pl> <2a5e326f0912091117x708968edlcde85a8997d1232b@mail.gmail.com> <2a5e326f0912091320t25ecf91ag90daa5e36029c0f4@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="o7gdRJTuwFmWapyH" Content-Disposition: inline In-Reply-To: <2a5e326f0912091320t25ecf91ag90daa5e36029c0f4@mail.gmail.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-fs@freebsd.org Subject: Re: zpool create fails on gpart device 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, 09 Dec 2009 23:27:55 -0000 --o7gdRJTuwFmWapyH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 09, 2009 at 03:20:31PM -0600, Kurt Touet wrote: > With the patch: >=20 > # sysctl vfs.zfs.debug=3D1 > vfs.zfs.debug: 0 -> 1 >=20 > # zpool create data /dev/da1p3 > cannot create 'data': permission denied >=20 [...] > kernel: vdev_geom_open_by_path:487[1]: Found provider by name /dev/da1p3. > kernel: vdev_geom_attach:112[1]: Attaching to da1p3. > kernel: vdev_geom_attach:132[1]: g_access() failed > kernel: vdev_geom_attach:136[1]: cp=3D0xffffff0002b70480 r0w0e0 geom=3Dzf= s::vdev class=3DZFS::VDEV > kernel: vdev_geom_attach:136[1]: cp=3D0xffffff000263bd00 r1w0e1 geom=3Dda= 1p3 class=3DLABEL So some label keeps it open exclusively. Could you also send the output of: # glabel list --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --o7gdRJTuwFmWapyH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFLIDJvForvXbEpPzQRAh0/AJ9TfBCwh/itQMYNZnF7jcz/XFE1PQCfcIHd s0ZPROAptdDeHn4mF5Z/sqU= =PVon -----END PGP SIGNATURE----- --o7gdRJTuwFmWapyH-- From owner-freebsd-fs@FreeBSD.ORG Thu Dec 10 10:06:27 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D8C71065697; Thu, 10 Dec 2009 10:06:27 +0000 (UTC) (envelope-from petri@helenius.fi) Received: from silver.he.iki.fi (mx.helenius.fi [IPv6:2001:1bc8:1018::42]) by mx1.freebsd.org (Postfix) with ESMTP id 3849E8FC16; Thu, 10 Dec 2009 10:06:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.he.iki.fi (Postfix) with ESMTP id B5DA0C1D8; Thu, 10 Dec 2009 12:06:23 +0200 (EET) Received: from silver.he.iki.fi ([127.0.0.1]) by localhost (silver.he.iki.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VT9ZqGZbSWoT; Thu, 10 Dec 2009 12:06:22 +0200 (EET) Received: from [83.150.107.196] (d196.helenius.fi [83.150.107.196]) by silver.he.iki.fi (Postfix) with ESMTP; Thu, 10 Dec 2009 12:06:21 +0200 (EET) Message-ID: <4B20C809.1000008@helenius.fi> Date: Thu, 10 Dec 2009 12:06:01 +0200 From: Petri Helenius User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.5) Gecko/20091130 Thunderbird/3.0 MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: CA100C20-5F93-4DCE-B576-474DAEC10747@multipart-mixed.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pjd@freebsd.org Subject: ZFS and reordering drives 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, 10 Dec 2009 10:06:27 -0000 Hi, Could you provide a pointer to the guid-check patch and if possible, have it in RELENG_8 too? Pete From owner-freebsd-fs@FreeBSD.ORG Thu Dec 10 18:27:31 2009 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C9B4106566B; Thu, 10 Dec 2009 18:27:31 +0000 (UTC) (envelope-from bp@barryp.org) Received: from itasca.hexavalent.net (itasca.hexavalent.net [67.207.138.180]) by mx1.freebsd.org (Postfix) with ESMTP id 129DD8FC15; Thu, 10 Dec 2009 18:27:30 +0000 (UTC) Received: from barryp.org (host-145-114-107-208.midco.net [208.107.114.145]) by itasca.hexavalent.net (Postfix) with ESMTPS id 0B81E23C4D8; Thu, 10 Dec 2009 12:12:17 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=barryp.org; s=itasca; t=1260468737; bh=NcAOkvnTTjr+zmiGynQdrODp2uujB/aCueVFUgGavmo=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=QAldEow1XC4R StSut6xksPfbv483A7Sx8EpDUx9hQJtuf0V46/1ia6/6er/MftrHhlcmGsr6kMCjTsP xvP6WyvFDMSIUYAP78SGNPY/B0E/ykCSeUqGfKGu5Uon32UJ5XR3GwKedGMQTcwz09N 8Rnnc9bBYnXt33xIEdurR6038= Received: from octane.med.und.nodak.edu ([134.129.166.23]) by barryp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1NInUs-000HkV-W5; Thu, 10 Dec 2009 12:12:15 -0600 Message-ID: <4B2139FE.8020200@barryp.org> Date: Thu, 10 Dec 2009 12:12:14 -0600 From: Barry Pederson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <200911102227.nAAMRXTf073603@svn.freebsd.org> <20091110224524.GC3194@garage.freebsd.pl> In-Reply-To: <20091110224524.GC3194@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: HEADS UP: Important bug fix in ZFS replay code! 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, 10 Dec 2009 18:27:31 -0000 On 11/10/09 4:45 PM, Pawel Jakub Dawidek wrote: > Hi. > > There was important bug in ZFS replay code. If there were setattr logs > (not related to permission change) in ZIL during unclean shutdown, one > can end up with files that have mode set to 07777. > > This is very dangerous, especially if you have untrusted local users, as > this will set setuid bit on such files. Note that FreeBSD will remove > setuid bits when someone will try to modify the file, but it is still > dangerous. > > You can locate such files with the following command: > > # find / -perm -7777 -print0 | xargs -0 ls -ld > > You can locate and fix such files with the following command: > > # find / -perm -7777 -print0 | xargs -0 chmod a-s,o-w,-t I just noticed this fix didn't make it into 8.0, I just had an 8.0-RELEASE-p1 machine crash and come back with a bunch of 07777 files. Maybe this should be documented as an errata or security advisory. Barry From owner-freebsd-fs@FreeBSD.ORG Thu Dec 10 20:08:32 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBEFA106566B for ; Thu, 10 Dec 2009 20:08:32 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from mail-gx0-f214.google.com (mail-gx0-f214.google.com [209.85.217.214]) by mx1.freebsd.org (Postfix) with ESMTP id AB83A8FC0A for ; Thu, 10 Dec 2009 20:08:32 +0000 (UTC) Received: by gxk6 with SMTP id 6so278529gxk.13 for ; Thu, 10 Dec 2009 12:08:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=GOMw0NuuwQK3a1s/RhTexMf8vQt8gK5S7aPJRvTApEg=; b=Hvpqc1WDXpm3BL5tlr5PjkCioAwyKp1gx6EwpZB3UH7ie8UtKce7Xy3iTBoTa+rszS 8deiZXJEVMxdXQwJTTTuyZ2C3m5bRMSWdFn2fBZWVH4s1R7bTEZ5lkmo6F+PP/pOfMr0 /F7TtUK9XC3YpO03Gi0GqEoKQDqpzYANglRJw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=sW0uQWP44+W1JzTMJvV+jAoYkKeJP4MnXectGUnU6zfOGe2bsh6BwZNCCptQM1jtuC OavI7peo1+2O0e/oH6MO1OHLOIi6Zhc5JIGF5muTm5ha2CmkeZwKZ2O+OdZj4mIASKiC H6TEbzjurOgurs8oQCQmHkShPavDV69bhWMWw= MIME-Version: 1.0 Received: by 10.150.6.19 with SMTP id 19mr987415ybf.63.1260475711280; Thu, 10 Dec 2009 12:08:31 -0800 (PST) In-Reply-To: References: Date: Thu, 10 Dec 2009 12:08:31 -0800 Message-ID: From: Matt Reimer To: freebsd-fs Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: PATCH: more efficient raidz memory usage for (gpt)zfsboot 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, 10 Dec 2009 20:08:33 -0000 On Mon, Dec 7, 2009 at 4:03 PM, Matt Reimer wrote: > Teach the (gpt)zfsboot raidz code to use its buffers more efficiently. > > Before this patch, in the worst case memory use would increase > exponentially on the number of drives in the raidz vdev. > > Sponsored by: VPOP Technologies, Inc. > > Matt Reimer Anyone want to commit this? Matt From owner-freebsd-fs@FreeBSD.ORG Thu Dec 10 20:09:03 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 928A410656C9 for ; Thu, 10 Dec 2009 20:09:03 +0000 (UTC) (envelope-from mattjreimer@gmail.com) Received: from mail-yw0-f197.google.com (mail-yw0-f197.google.com [209.85.211.197]) by mx1.freebsd.org (Postfix) with ESMTP id 5142A8FC26 for ; Thu, 10 Dec 2009 20:09:03 +0000 (UTC) Received: by ywh35 with SMTP id 35so154232ywh.7 for ; Thu, 10 Dec 2009 12:09:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=q4HpYum29MY+Vj73cY0bv1HR4quwsr7BogYjkfcSd3g=; b=dv01b/yTLNhNbGCsBc+TzvM0Nz5TvxHLxVLH5WFcFcBCctytyerDxy7hiBCX3Qxr1M y/hg7O8V8GpNHmBgMORXUQKIN342VOhcPWfU+dT5YlojU9l5q9SpI0Ub8zcJGjxvvh5O kNLnhyvzv10v0LfbKzc+YQwXt8MSR9N5zdDoY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=FoO3WlwrmaDEAieFWJLtGtO7vO4EyehfnEBlyJMHcx+egqsDkqzeytLD2T/KsCvN5e Fr4tHjB4vktHQbA8GLBGOu1o7sVj+2n2VhXHBJFsJM0mdrV+02fSnpXXI3fB7yZFZu3C NiDAab9UU9qCohHFJ7hQSPiN1APPctC4w6Tsg= MIME-Version: 1.0 Received: by 10.150.251.6 with SMTP id y6mr944876ybh.188.1260475742594; Thu, 10 Dec 2009 12:09:02 -0800 (PST) In-Reply-To: References: Date: Thu, 10 Dec 2009 12:09:02 -0800 Message-ID: From: Matt Reimer To: freebsd-fs Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: PATCH: teach (gpt)zfsboot to discern vdev status correctly 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, 10 Dec 2009 20:09:03 -0000 On Mon, Dec 7, 2009 at 4:08 PM, Matt Reimer wrote: > Instead of assuming all vdevs are healthy, check the newest vdev label > for each vdev's status. Booting from a degraded vdev should now be > more robust. > > Sponsored by: VPOP Technologies, Inc. > > Matt Reimer > > (Note that much of this patch is merely whitespace change due to a > block needing to be reindented.) Anyone want to commit this? Matt From owner-freebsd-fs@FreeBSD.ORG Thu Dec 10 22:51:14 2009 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C089106566B; Thu, 10 Dec 2009 22:51:14 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 53A128FC1B; Thu, 10 Dec 2009 22:51:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBAMpEcO041428; Thu, 10 Dec 2009 22:51:14 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBAMpEkT041424; Thu, 10 Dec 2009 22:51:14 GMT (envelope-from linimon) Date: Thu, 10 Dec 2009 22:51:14 GMT Message-Id: <200912102251.nBAMpEkT041424@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/141355: [zfs] zfs recv can fail with E2BIG 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, 10 Dec 2009 22:51:14 -0000 Synopsis: [zfs] zfs recv can fail with E2BIG Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Thu Dec 10 22:51:00 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=141355 From owner-freebsd-fs@FreeBSD.ORG Thu Dec 10 23:31:27 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40669106566C for ; Thu, 10 Dec 2009 23:31:27 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.freenix.fr (cl-180.mrs-01.fr.sixxs.net [IPv6:2a01:240:fe00:b3::2]) by mx1.freebsd.org (Postfix) with ESMTP id E3F8F8FC0A for ; Thu, 10 Dec 2009 23:31:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by keltia.freenix.fr (Postfix/TLS) with ESMTP id A050A3B191 for ; Fri, 11 Dec 2009 00:31:25 +0100 (CET) X-Virus-Scanned: amavisd-new at keltia.freenix.fr Received: from keltia.freenix.fr ([127.0.0.1]) by localhost (keltia.freenix.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMFfiglb1BdN for ; Fri, 11 Dec 2009 00:31:25 +0100 (CET) Received: from sidhe.keltia.net (sidhe.keltia.net [193.56.58.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.freenix.fr (Postfix/TLS) with ESMTPSA id 314B439F7E for ; Fri, 11 Dec 2009 00:31:25 +0100 (CET) Date: Fri, 11 Dec 2009 00:34:40 +0100 From: Ollivier Robert To: freebsd-fs@freebsd.org Message-ID: <20091210233440.GB82061@sidhe.keltia.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: MacOS X / PowerBook G4 - FreeBSD 5.0 / 2x PIII/800 SMP User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: PATCH: more efficient raidz memory usage for (gpt)zfsboot 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, 10 Dec 2009 23:31:27 -0000 According to Matt Reimer: > Anyone want to commit this? Me but I'd like to see Pawel or Kip review it first. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ From owner-freebsd-fs@FreeBSD.ORG Fri Dec 11 09:20:08 2009 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E764106568D for ; Fri, 11 Dec 2009 09:20:08 +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 238338FC12 for ; Fri, 11 Dec 2009 09:20:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBB9K8nG020958 for ; Fri, 11 Dec 2009 09:20:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBB9K7hW020957; Fri, 11 Dec 2009 09:20:08 GMT (envelope-from gnats) Date: Fri, 11 Dec 2009 09:20:08 GMT Message-Id: <200912110920.nBB9K7hW020957@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org From: Martin Matuska Cc: Subject: Re: kern/141355: [zfs] zfs recv can fail with E2BIG X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Martin Matuska List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2009 09:20:08 -0000 The following reply was made to PR kern/141355; it has been noted by GNATS. From: Martin Matuska To: bug-followup@FreeBSD.org, mm@FreeBSD.org Cc: Subject: Re: kern/141355: [zfs] zfs recv can fail with E2BIG Date: Fri, 11 Dec 2009 10:08:43 +0100 This is a multi-part message in MIME format. --------------070208060700060803030000 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit I have created a patch from OpenSolaris mercurial for head. Diffs used: hg clone ssh://anon@hg.opensolaris.org/hg/onnv/onnv-gate hg diff -r 7837 -r 7994 onnv-gate/usr/src/uts/common/fs/zfs/dmu_send.c hg diff -c 8986 onnv-gate Patch is easily backportable to RELENG_8. I am testing it in RELENG_8. --------------070208060700060803030000 Content-Type: text/plain; name="sys.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sys.patch" Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/dmu.h =================================================================== --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/dmu.h (revision 200402) +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/dmu.h (working copy) @@ -19,7 +19,7 @@ * CDDL HEADER END */ /* - * Copyright 2008 Sun Microsystems, Inc. All rights reserved. + * Copyright 2009 Sun Microsystems, Inc. All rights reserved. * Use is subject to license terms. */ @@ -237,7 +237,7 @@ int dmu_object_claim(objset_t *os, uint64_t object, dmu_object_type_t ot, int blocksize, dmu_object_type_t bonus_type, int bonus_len, dmu_tx_t *tx); int dmu_object_reclaim(objset_t *os, uint64_t object, dmu_object_type_t ot, - int blocksize, dmu_object_type_t bonustype, int bonuslen, dmu_tx_t *tx); + int blocksize, dmu_object_type_t bonustype, int bonuslen); /* * Free an object from this objset. Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_object.c =================================================================== --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_object.c (revision 200402) +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_object.c (working copy) @@ -19,12 +19,10 @@ * CDDL HEADER END */ /* - * Copyright 2008 Sun Microsystems, Inc. All rights reserved. + * Copyright 2009 Sun Microsystems, Inc. All rights reserved. * Use is subject to license terms. */ -#pragma ident "%Z%%M% %I% %E% SMI" - #include #include #include @@ -108,19 +106,51 @@ int dmu_object_reclaim(objset_t *os, uint64_t object, dmu_object_type_t ot, - int blocksize, dmu_object_type_t bonustype, int bonuslen, dmu_tx_t *tx) + int blocksize, dmu_object_type_t bonustype, int bonuslen) { dnode_t *dn; + dmu_tx_t *tx; + int nblkptr; int err; - if (object == DMU_META_DNODE_OBJECT && !dmu_tx_private_ok(tx)) + if (object == DMU_META_DNODE_OBJECT) return (EBADF); err = dnode_hold_impl(os->os, object, DNODE_MUST_BE_ALLOCATED, FTAG, &dn); if (err) return (err); + + if (dn->dn_type == ot && dn->dn_datablksz == blocksize && + dn->dn_bonustype == bonustype && dn->dn_bonuslen == bonuslen) { + /* nothing is changing, this is a noop */ + dnode_rele(dn, FTAG); + return (0); + } + + tx = dmu_tx_create(os); + dmu_tx_hold_bonus(tx, object); + err = dmu_tx_assign(tx, TXG_WAIT); + if (err) { + dmu_tx_abort(tx); + dnode_rele(dn, FTAG); + return (err); + } + + nblkptr = 1 + ((DN_MAX_BONUSLEN - bonuslen) >> SPA_BLKPTRSHIFT); + + /* + * If we are losing blkptrs or changing the block size this must + * be a new file instance. We must clear out the previous file + * contents before we can change this type of metadata in the dnode. + */ + if (dn->dn_nblkptr > nblkptr || dn->dn_datablksz != blocksize) + dmu_free_long_range(os, object, 0, DMU_OBJECT_END); + dnode_reallocate(dn, ot, blocksize, bonustype, bonuslen, tx); + + dmu_tx_commit(tx); + dnode_rele(dn, FTAG); return (0); Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c =================================================================== --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c (revision 200402) +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dnode.c (working copy) @@ -415,8 +415,7 @@ dnode_reallocate(dnode_t *dn, dmu_object_type_t ot, int blocksize, dmu_object_type_t bonustype, int bonuslen, dmu_tx_t *tx) { - int i, nblkptr; - dmu_buf_impl_t *db = NULL; + int nblkptr; ASSERT3U(blocksize, >=, SPA_MINBLOCKSIZE); ASSERT3U(blocksize, <=, SPA_MAXBLOCKSIZE); @@ -428,42 +427,25 @@ ASSERT3U(bonustype, <, DMU_OT_NUMTYPES); ASSERT3U(bonuslen, <=, DN_MAX_BONUSLEN); - for (i = 0; i < TXG_SIZE; i++) - ASSERT(!list_link_active(&dn->dn_dirty_link[i])); - /* clean up any unreferenced dbufs */ dnode_evict_dbufs(dn); - ASSERT3P(list_head(&dn->dn_dbufs), ==, NULL); - /* - * XXX I should really have a generation number to tell if we - * need to do this... - */ - if (blocksize != dn->dn_datablksz || - dn->dn_bonustype != bonustype || dn->dn_bonuslen != bonuslen) { - /* free all old data */ - dnode_free_range(dn, 0, -1ULL, tx); - } - - nblkptr = 1 + ((DN_MAX_BONUSLEN - bonuslen) >> SPA_BLKPTRSHIFT); - - /* change blocksize */ rw_enter(&dn->dn_struct_rwlock, RW_WRITER); - if (blocksize != dn->dn_datablksz && - (!BP_IS_HOLE(&dn->dn_phys->dn_blkptr[0]) || - list_head(&dn->dn_dbufs) != NULL)) { - db = dbuf_hold(dn, 0, FTAG); - dbuf_new_size(db, blocksize, tx); - } - dnode_setdblksz(dn, blocksize); dnode_setdirty(dn, tx); - dn->dn_next_bonuslen[tx->tx_txg&TXG_MASK] = bonuslen; - dn->dn_next_blksz[tx->tx_txg&TXG_MASK] = blocksize; + if (dn->dn_datablksz != blocksize) { + /* change blocksize */ + ASSERT(dn->dn_maxblkid == 0 && + (BP_IS_HOLE(&dn->dn_phys->dn_blkptr[0]) || + dnode_block_freed(dn, 0))); + dnode_setdblksz(dn, blocksize); + dn->dn_next_blksz[tx->tx_txg&TXG_MASK] = blocksize; + } + if (dn->dn_bonuslen != bonuslen) + dn->dn_next_bonuslen[tx->tx_txg&TXG_MASK] = bonuslen; + nblkptr = 1 + ((DN_MAX_BONUSLEN - bonuslen) >> SPA_BLKPTRSHIFT); if (dn->dn_nblkptr != nblkptr) dn->dn_next_nblkptr[tx->tx_txg&TXG_MASK] = nblkptr; rw_exit(&dn->dn_struct_rwlock); - if (db) - dbuf_rele(db, FTAG); /* change type */ dn->dn_type = ot; @@ -1187,11 +1169,6 @@ if (dn->dn_free_txg) return (TRUE); - /* - * If dn_datablkshift is not set, then there's only a single - * block, in which case there will never be a free range so it - * won't matter. - */ range_tofind.fr_blkid = blkid; mutex_enter(&dn->dn_mtx); for (i = 0; i < TXG_SIZE; i++) { Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_send.c =================================================================== --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_send.c (revision 200402) +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_send.c (working copy) @@ -828,12 +828,8 @@ { int err; dmu_tx_t *tx; + void *data = NULL; - err = dmu_object_info(os, drro->drr_object, NULL); - - if (err != 0 && err != ENOENT) - return (EINVAL); - if (drro->drr_type == DMU_OT_NONE || drro->drr_type >= DMU_OT_NUMTYPES || drro->drr_bonustype >= DMU_OT_NUMTYPES || @@ -846,12 +842,21 @@ return (EINVAL); } - tx = dmu_tx_create(os); + err = dmu_object_info(os, drro->drr_object, NULL); + if (err != 0 && err != ENOENT) + return (EINVAL); + + if (drro->drr_bonuslen) { + data = restore_read(ra, P2ROUNDUP(drro->drr_bonuslen, 8)); + if (ra->err) + return (ra->err); + } + if (err == ENOENT) { /* currently free, want to be allocated */ + tx = dmu_tx_create(os); dmu_tx_hold_bonus(tx, DMU_NEW_OBJECT); - dmu_tx_hold_write(tx, DMU_NEW_OBJECT, 0, 1); err = dmu_tx_assign(tx, TXG_WAIT); if (err) { dmu_tx_abort(tx); @@ -860,45 +865,34 @@ err = dmu_object_claim(os, drro->drr_object, drro->drr_type, drro->drr_blksz, drro->drr_bonustype, drro->drr_bonuslen, tx); + dmu_tx_commit(tx); } else { /* currently allocated, want to be allocated */ - dmu_tx_hold_bonus(tx, drro->drr_object); - /* - * We may change blocksize and delete old content, - * so need to hold_write and hold_free. - */ - dmu_tx_hold_write(tx, drro->drr_object, 0, 1); - dmu_tx_hold_free(tx, drro->drr_object, 0, DMU_OBJECT_END); - err = dmu_tx_assign(tx, TXG_WAIT); - if (err) { - dmu_tx_abort(tx); - return (err); - } - err = dmu_object_reclaim(os, drro->drr_object, drro->drr_type, drro->drr_blksz, - drro->drr_bonustype, drro->drr_bonuslen, tx); + drro->drr_bonustype, drro->drr_bonuslen); } - if (err) { - dmu_tx_commit(tx); + if (err) return (EINVAL); + + tx = dmu_tx_create(os); + dmu_tx_hold_bonus(tx, drro->drr_object); + err = dmu_tx_assign(tx, TXG_WAIT); + if (err) { + dmu_tx_abort(tx); + return (err); } dmu_object_set_checksum(os, drro->drr_object, drro->drr_checksum, tx); dmu_object_set_compress(os, drro->drr_object, drro->drr_compress, tx); - if (drro->drr_bonuslen) { + if (data != NULL) { dmu_buf_t *db; - void *data; + VERIFY(0 == dmu_bonus_hold(os, drro->drr_object, FTAG, &db)); dmu_buf_will_dirty(db, tx); ASSERT3U(db->db_size, >=, drro->drr_bonuslen); - data = restore_read(ra, P2ROUNDUP(drro->drr_bonuslen, 8)); - if (data == NULL) { - dmu_tx_commit(tx); - return (ra->err); - } bcopy(data, db->db_data, drro->drr_bonuslen); if (ra->byteswap) { dmu_ot[drro->drr_bonustype].ot_byteswap(db->db_data, --------------070208060700060803030000-- From owner-freebsd-fs@FreeBSD.ORG Fri Dec 11 17:38:35 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECAB1106566C for ; Fri, 11 Dec 2009 17:38:35 +0000 (UTC) (envelope-from nekoexmachina@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 7A1238FC14 for ; Fri, 11 Dec 2009 17:38:35 +0000 (UTC) Received: by bwz5 with SMTP id 5so807567bwz.3 for ; Fri, 11 Dec 2009 09:38:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=LvVPJhh0dhI72ZFuKLi1JybrMAotkdeGnWNJeP5z4y8=; b=vlHPJmpilE4N82vZLGp53dBOOIAhvkVPEetCVsfTnUSxPBDSaitTjg+MZ6Fyh7So/1 bABpcx+cDjCh4XbA4S/v5IJZxKuIZ2mkCD56W9LLdUO0GPzGud+D3N3caTx4TrR0TpPe OPX6HgPW4piOiCgQdnaGkNFfUXhMyjXjnvpY4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=eAf5qdC5KWuKTJoTdnUwrzLug3dxNGGS/gErc4fOhDytkLCdZ25bqgCgpimj/H3KjB D081O/HA9i3oGqG7SiK20ZWfhX8WWRxSbNeosw+Gy1WYUTWHnZClN2bN3gJOhxswesRM DyarExMckSepq0CPj8udod7mlGa7HNhEtlV8c= MIME-Version: 1.0 Received: by 10.102.197.8 with SMTP id u8mr649309muf.37.1260553114013; Fri, 11 Dec 2009 09:38:34 -0800 (PST) In-Reply-To: <4b21a7b9.5744f10a.3378.6447@mx.google.com> References: <884554e60912090549y7216ad27l9c9673eb722b2540@mail.gmail.com> <884554e60912090627q2b01de98q30e24a5c41cdef4a@mail.gmail.com> <20091209200855.GA2281@aditya> <884554e60912090648o4521bb88o7dfc7a626cacf0f5@mail.gmail.com> <20091209203213.GB2281@aditya> <884554e60912090842x1bf1e8e4u842cbce4647aa63@mail.gmail.com> <20091209225000.GD2281@aditya> <884554e60912101333j1698e4c4o5d5903eb9c97211c@mail.gmail.com> <884554e60912101351o2d592c6fn99f64bb2fd8c33be@mail.gmail.com> <4b21a7b9.5744f10a.3378.6447@mx.google.com> Date: Fri, 11 Dec 2009 20:38:33 +0300 Message-ID: <884554e60912110938n79439fc1p4a3d41f81bb88991@mail.gmail.com> From: Mikle Krutov To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Re: [8.0-RELEASE] ext2fs mount fails 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, 11 Dec 2009 17:38:36 -0000 I do not understand anything, because after recompiling a) only ilbstand b) libstand + mount c) whole kernel+world mount -t ext2fs /dev/ad8p1 still returns the same message. I've grep'd '0xef53' in /usr/src & /usr/share - only 2 files in /usr/src, that i've already changed already before recompile. Also, i'm really sorry for writing only private to Aditya's mail, didn't mention that gmail has changed the recipient address. The previous mail summary: 1) i've already tried to update src (still with RELENG_8) && rebuild the kernel 2) (just done) have tried to edit files in /usr/src where i've grep'd '0xef53' - somehow it didn't help. From owner-freebsd-fs@FreeBSD.ORG Fri Dec 11 22:48:41 2009 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C501106566C; Fri, 11 Dec 2009 22:48:41 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E7A298FC08; Fri, 11 Dec 2009 22:48:40 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBBMmeB0000847; Fri, 11 Dec 2009 22:48:40 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBBMmeGn000843; Fri, 11 Dec 2009 22:48:40 GMT (envelope-from linimon) Date: Fri, 11 Dec 2009 22:48:40 GMT Message-Id: <200912112248.nBBMmeGn000843@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/141387: [zfs] [patch] zfs snapshot -r failed because filesystem was busy 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, 11 Dec 2009 22:48:41 -0000 Synopsis: [zfs] [patch] zfs snapshot -r failed because filesystem was busy Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Fri Dec 11 22:48:30 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=141387 From owner-freebsd-fs@FreeBSD.ORG Sat Dec 12 06:03:18 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 347E5106566C for ; Sat, 12 Dec 2009 06:03:18 +0000 (UTC) (envelope-from rincebrain@gmail.com) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by mx1.freebsd.org (Postfix) with ESMTP id B82E88FC08 for ; Sat, 12 Dec 2009 06:03:17 +0000 (UTC) Received: by fxm28 with SMTP id 28so42064fxm.13 for ; Fri, 11 Dec 2009 22:03:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5nKsI7BgJXFrCbsG0ERbNhjRm5wkJgUNu3zY0Gf87x8=; b=b1fM3M8TyR1dYkcCBqf2BrcL0TcXGylWDkZ1FYLk6PJDLaC6/nqIQtehoqrjFLrsko 3T6ADPfk/uH1MBrkDTKAl063EylFQD3VxldumJ9yTLjTghcrftdTxOdr2vnzwUeRhrip ZtG5iXoDpDQ6yV4ri7j3NYpcVM6Vtt7NAelQA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=cTITWKP0neWpcG/PAjMlISlKgAm9pSvyiiszbn0AyA85toKLcFPMTSiB5fMRFMYlFS fwDRZ94zGnntWOyILt2ADdO6jEbdCVpX7iS3tU63AjEkiKg4xEJEg4jOwJv/HzmyxeHM PYhvmlFxfqBv862O2X+dtgJX4PvMteFiBpRgA= MIME-Version: 1.0 Received: by 10.239.141.136 with SMTP id c8mr241594hba.148.1260597796389; Fri, 11 Dec 2009 22:03:16 -0800 (PST) In-Reply-To: <884554e60912110938n79439fc1p4a3d41f81bb88991@mail.gmail.com> References: <884554e60912090549y7216ad27l9c9673eb722b2540@mail.gmail.com> <20091209200855.GA2281@aditya> <884554e60912090648o4521bb88o7dfc7a626cacf0f5@mail.gmail.com> <20091209203213.GB2281@aditya> <884554e60912090842x1bf1e8e4u842cbce4647aa63@mail.gmail.com> <20091209225000.GD2281@aditya> <884554e60912101333j1698e4c4o5d5903eb9c97211c@mail.gmail.com> <884554e60912101351o2d592c6fn99f64bb2fd8c33be@mail.gmail.com> <4b21a7b9.5744f10a.3378.6447@mx.google.com> <884554e60912110938n79439fc1p4a3d41f81bb88991@mail.gmail.com> Date: Sat, 12 Dec 2009 01:03:16 -0500 Message-ID: <5da0588e0912112203v52653fb2ic71d97970b615547@mail.gmail.com> From: Rich To: Mikle Krutov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org Subject: Re: [8.0-RELEASE] ext2fs mount fails 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, 12 Dec 2009 06:03:18 -0000 Are you sure it's ext2/3, and not ext4? ext4 isn't mountable as ext2 if you have ever had certain [default] flags on in Linux [the extents feature, in particular, breaks backward compatibility]. dumpe2fs with a list of the filesystem's feature flags is relevant here. - Rich On Fri, Dec 11, 2009 at 12:38 PM, Mikle Krutov wr= ote: > I do not understand anything, because after recompiling > a) only ilbstand > b) libstand + mount > c) whole kernel+world > mount -t ext2fs /dev/ad8p1 still returns the same message. I've grep'd > '0xef53' in /usr/src & /usr/share - only 2 files in /usr/src, that > i've already changed already before recompile. > > Also, i'm really sorry for writing only private to Aditya's mail, > didn't mention that gmail has changed the recipient address. > > The previous mail summary: > 1) i've already tried to update src (still with RELENG_8) && rebuild the = kernel > 2) (just done) have tried to edit files in /usr/src where i've grep'd > '0xef53' - somehow it didn't 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" > --=20 La=E7o bacana para panaca bo=E7al. -- pal=EDndromo From owner-freebsd-fs@FreeBSD.ORG Sat Dec 12 13:47:05 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1507106566C for ; Sat, 12 Dec 2009 13:47:05 +0000 (UTC) (envelope-from nekoexmachina@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id 5C0D68FC15 for ; Sat, 12 Dec 2009 13:47:04 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 16so466409fgg.13 for ; Sat, 12 Dec 2009 05:47:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=dvKsWbe5LbehW1kFX/91JPe+TGzTln9/tnipPA6rcrM=; b=Lj0L0SRRFACpf9FSTqttjaItKWViO+iG1YcnrcZUqS3l8hbuoYD0ho5+YfhZZNoKSA Kjle8Rvdwf447kcjWAc1VH7+9xWS/PUbprF2Od5Nq+Ia4oPd9d9+/1osIBKHocTwp8U1 SO/Ke5eTXm3m9rQFw0saUOALxEPrVkKbKuhtU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=NZYdAuWDjhWBFoYr9dB0/2OaJ8KjJmuP6A5XvQz3u2pwjQ4+UvK/UZGyxMX6bXPdQN tOfP4b2ImVvSr+aAXyTtiPCaM8mAm2ez2LZ1P7J9nLwDeFcz5xo02Cu46T3h1Ezrmofo lo/559ghL1lZdl6keAGcGYl0ckYZ7fz1OgfZQ= MIME-Version: 1.0 Received: by 10.102.14.17 with SMTP id 17mr1011866mun.40.1260625623307; Sat, 12 Dec 2009 05:47:03 -0800 (PST) In-Reply-To: <884554e60912120149t6cd0df5me349b1fdf485b0c@mail.gmail.com> References: <884554e60912090549y7216ad27l9c9673eb722b2540@mail.gmail.com> <20091209203213.GB2281@aditya> <884554e60912090842x1bf1e8e4u842cbce4647aa63@mail.gmail.com> <20091209225000.GD2281@aditya> <884554e60912101333j1698e4c4o5d5903eb9c97211c@mail.gmail.com> <884554e60912101351o2d592c6fn99f64bb2fd8c33be@mail.gmail.com> <4b21a7b9.5744f10a.3378.6447@mx.google.com> <884554e60912110938n79439fc1p4a3d41f81bb88991@mail.gmail.com> <5da0588e0912112203v52653fb2ic71d97970b615547@mail.gmail.com> <884554e60912120149t6cd0df5me349b1fdf485b0c@mail.gmail.com> Date: Sat, 12 Dec 2009 16:47:02 +0300 Message-ID: <884554e60912120547i1ccca7acob8714fd5121a5508@mail.gmail.com> From: Mikle Krutov To: freebsd-fs@freebsd.org Content-Type: multipart/mixed; boundary=0016363b94f478d739047a884619 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: [8.0-RELEASE] ext2fs mount fails 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, 12 Dec 2009 13:47:06 -0000 --0016363b94f478d739047a884619 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, it's 100% ext2fs. I could not create dump with fbsd - 'wrong magic number', so i used linux livecd. 2009/12/12 Mikle Krutov : > Yes, it's 100% ext2fs. > I could not create dumps with fbsd - 'wrong magic number', so i used > linux livecd. > > > > 2009/12/12 Rich : >> Are you sure it's ext2/3, and not ext4? >> >> ext4 isn't mountable as ext2 if you have ever had certain [default] >> flags on in Linux [the extents feature, in particular, breaks backward >> compatibility]. >> >> dumpe2fs with a list of the filesystem's feature flags is relevant here. >> >> - Rich >> >> On Fri, Dec 11, 2009 at 12:38 PM, Mikle Krutov = wrote: >>> I do not understand anything, because after recompiling >>> a) only ilbstand >>> b) libstand + mount >>> c) whole kernel+world >>> mount -t ext2fs /dev/ad8p1 still returns the same message. I've grep'd >>> '0xef53' in /usr/src & /usr/share - only 2 files in /usr/src, that >>> i've already changed already before recompile. >>> >>> Also, i'm really sorry for writing only private to Aditya's mail, >>> didn't mention that gmail has changed the recipient address. >>> >>> The previous mail summary: >>> 1) i've already tried to update src (still with RELENG_8) && rebuild th= e kernel >>> 2) (just done) have tried to edit files in /usr/src where i've grep'd >>> '0xef53' - somehow it didn't 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" >>> >> >> >> >> -- >> >> La=C3=A7o bacana para panaca bo=C3=A7al. -- pal=C3=ADndromo >> > --0016363b94f478d739047a884619--