From owner-freebsd-fs@FreeBSD.ORG Sun Jun 7 21:00:17 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 48E35D40 for ; Sun, 7 Jun 2015 21:00:17 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 224F11283 for ; Sun, 7 Jun 2015 21:00:17 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t57L0HeN005867 for ; Sun, 7 Jun 2015 21:00:17 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201506072100.t57L0HeN005867@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-fs@FreeBSD.org Subject: Problem reports for freebsd-fs@FreeBSD.org that need special attention X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 Date: Sun, 07 Jun 2015 21:00:17 +0000 Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2015 21:00:17 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 136470 | [nfs] Cannot mount / in read-only, over NFS Open | 139651 | [nfs] mount(8): read-only remount of NFS volume d Open | 144447 | [zfs] sharenfs fsunshare() & fsshare_main() non f 3 problems total for which you should take action. From owner-freebsd-fs@FreeBSD.ORG Mon Jun 8 20:44:57 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BF6F72ED for ; Mon, 8 Jun 2015 20:44:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A9F3E1E2A for ; Mon, 8 Jun 2015 20:44:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t58KivGY007598 for ; Mon, 8 Jun 2015 20:44:57 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 200513] Race at shutdown and corrupt fusefs systems Date: Mon, 08 Jun 2015 20:44:57 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 20:44:57 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200513 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-fs@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Tue Jun 9 01:30:20 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 387D12F4 for ; Tue, 9 Jun 2015 01:30:20 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from mail15.tpgi.com.au (smtp-out15.tpgi.com.au [220.244.226.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.tpg.com.au", Issuer "RapidSSL SHA256 CA - G3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B249511D3 for ; Tue, 9 Jun 2015 01:30:18 +0000 (UTC) (envelope-from ari@ish.com.au) X-TPG-Junk-Status: Message not scanned X-TPG-Antivirus: Passed X-TPG-Abuse: host=[202.161.115.54]; ip=202.161.115.54; date=Tue, 9 Jun 2015 11:10:22 +1000 Received: from fish.ish.com.au (202-161-115-54.static.tpgi.com.au [202.161.115.54] (may be forged)) by mail15.tpgi.com.au (envelope-from ari@ish.com.au) (8.14.3/8.14.3) with ESMTP id t591AKBt000707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 9 Jun 2015 11:10:22 +1000 Received: from ip-211.ish.com.au ([203.29.62.211]:40270 helo=ish.com.au) by fish.ish.com.au with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Z283N-0001ha-1g for freebsd-fs@freebsd.org; Tue, 09 Jun 2015 11:10:09 +1000 Received: from [203.29.62.136] (HELO ip-136.ish.com.au) by ish.com.au (CommuniGate Pro SMTP 6.1.2) with ESMTPS id 18080238 for freebsd-fs@freebsd.org; Tue, 09 Jun 2015 11:10:09 +1000 X-CTCH-RefID: str=0001.0A150209.55763CF1.0094:SCFSTAT29393324, ss=1, re=-4.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 To: freebsd-fs@freebsd.org From: Aristedes Maniatis Subject: multiple vdevs on boot ZFS pool Message-ID: <55763CF1.1020100@ish.com.au> Date: Tue, 9 Jun 2015 11:10:09 +1000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pTXL7iVqBP9vs3olNWNk9956fVj8sJW75" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 01:30:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pTXL7iVqBP9vs3olNWNk9956fVj8sJW75 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I'm running 9.2-release on a machine and when I try to expand the mirror = of two disks with another two disk mirror, I get an error that I cannot a= dd another vdev to the boot pool. I know this used to be an issue some time ago, but I see articles about b= ypassing the check by unsetting bootfs attribute temporarily. That seems = dangerous however and I don't want to create an unbootable array. Is this error really still an error in 9.2? I certainly have a 10.1 syste= m which boots from a 3 vdev array. Do I need to upgrade this system to al= low for booting from such an array? Thanks Ari --=20 --------------------------> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A --pTXL7iVqBP9vs3olNWNk9956fVj8sJW75 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlV2PPMACgkQ72p9Lj5JECr3WQCcCYo9NJ6uSFJz2R0LUiy0Zp8y kYsAn1zdCOLL7NSjBUX/9Qh7GUfMo7qq =NhzJ -----END PGP SIGNATURE----- --pTXL7iVqBP9vs3olNWNk9956fVj8sJW75-- From owner-freebsd-fs@FreeBSD.ORG Tue Jun 9 02:03:40 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 41DDD913 for ; Tue, 9 Jun 2015 02:03:40 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0B77E1AC4 for ; Tue, 9 Jun 2015 02:03:40 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by iebgx4 with SMTP id gx4so5558678ieb.0 for ; Mon, 08 Jun 2015 19:03:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ni6IF6tehsBXLPYO8WRtrG9wfEqCyRSTRCTWNcN6xOM=; b=e2H+z1uhpbEzAeAQL75rzdxJOLaFWSd36wUCyDVeH8sLPFROg8nwt8TPAeiljqmjoT F0ihtxPV+9PswKAZSYReqZWPFjnNRGi/G5wQWbyXbiCCT898mQN0A975YZkvD86xVl5V WoGX716OuxkbUo2IUxdo1j6nmH5mb6sJut2y5x0iJD8WzzJT/2ALOGnwyFAfeeWeH4KQ 0R6ddMcOiXm5E4NFihWuPx48MW8MCZxFAQOVm/b03cCDr+SJhldvH5VXL53joki2NTQn R7NSDngDi1VlLS4+kv87c7SN49YmsoEf/+Gx2TcmlgJ6m/PZyNEZnQEzDbmFtdpADZEB h2/g== MIME-Version: 1.0 X-Received: by 10.107.4.204 with SMTP id 195mr24129837ioe.40.1433815419344; Mon, 08 Jun 2015 19:03:39 -0700 (PDT) Received: by 10.64.123.100 with HTTP; Mon, 8 Jun 2015 19:03:39 -0700 (PDT) Received: by 10.64.123.100 with HTTP; Mon, 8 Jun 2015 19:03:39 -0700 (PDT) In-Reply-To: <55763CF1.1020100@ish.com.au> References: <55763CF1.1020100@ish.com.au> Date: Mon, 8 Jun 2015 19:03:39 -0700 Message-ID: Subject: Re: multiple vdevs on boot ZFS pool From: Freddie Cash To: Aristedes Maniatis Cc: FreeBSD Filesystems Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 02:03:40 -0000 It's a 9.2 "issue", fixed in 9.3. In running 2 mirror vdevs in the only pool on a 9.3 system. It's a bootable pool, and I've treated booting from all 4 disks (changing boot order in BIOS) without issues. Typos courtesy of my phone. On Jun 8, 2015 6:30 PM, "Aristedes Maniatis" wrote: > I'm running 9.2-release on a machine and when I try to expand the mirror > of two disks with another two disk mirror, I get an error that I cannot add > another vdev to the boot pool. > > I know this used to be an issue some time ago, but I see articles about > bypassing the check by unsetting bootfs attribute temporarily. That seems > dangerous however and I don't want to create an unbootable array. > > Is this error really still an error in 9.2? I certainly have a 10.1 system > which boots from a 3 vdev array. Do I need to upgrade this system to allow > for booting from such an array? > > Thanks > Ari > > > -- > --------------------------> > Aristedes Maniatis > ish > http://www.ish.com.au > Level 1, 30 Wilson Street Newtown 2042 Australia > phone +61 2 9550 5001 fax +61 2 9550 4001 > GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A > > From owner-freebsd-fs@FreeBSD.ORG Tue Jun 9 03:11:03 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E6C731DB for ; Tue, 9 Jun 2015 03:11:02 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from mail15.tpgi.com.au (mail15.tpgi.com.au [203.12.160.61]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.tpg.com.au", Issuer "RapidSSL SHA256 CA - G3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 61BD91B18 for ; Tue, 9 Jun 2015 03:11:01 +0000 (UTC) (envelope-from ari@ish.com.au) X-TPG-Junk-Status: Message not scanned X-TPG-Antivirus: Passed X-TPG-Abuse: host=[202.161.115.54]; ip=202.161.115.54; date=Tue, 9 Jun 2015 13:10:57 +1000 Received: from fish.ish.com.au (202-161-115-54.static.tpgi.com.au [202.161.115.54] (may be forged)) by mail15.tpgi.com.au (envelope-from ari@ish.com.au) (8.14.3/8.14.3) with ESMTP id t593Ath5002994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 9 Jun 2015 13:10:57 +1000 Received: from ip-211.ish.com.au ([203.29.62.211]:62280 helo=ish.com.au) by fish.ish.com.au with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Z29wC-0000RH-2m; Tue, 09 Jun 2015 13:10:53 +1000 Received: from [203.29.62.136] (HELO ip-136.ish.com.au) by ish.com.au (CommuniGate Pro SMTP 6.1.2) with ESMTPS id 18080345; Tue, 09 Jun 2015 13:10:52 +1000 X-CTCH-RefID: str=0001.0A150205.5576593D.0021:SCFSTAT29393324, ss=1, re=-4.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Subject: Re: multiple vdevs on boot ZFS pool To: Freddie Cash References: <55763CF1.1020100@ish.com.au> Cc: FreeBSD Filesystems From: Aristedes Maniatis Message-ID: <55765939.4090503@ish.com.au> Date: Tue, 9 Jun 2015 13:10:49 +1000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Lo90CJlgbbu3bOmpkF56LfOaHx9pxL0uG" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 03:11:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Lo90CJlgbbu3bOmpkF56LfOaHx9pxL0uG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Is the 'issue' that the error message can be ignored, or that you can't b= oot in 9.2? Thanks Ari On 9/06/2015 12:03pm, Freddie Cash wrote: > It's a 9.2 "issue", fixed in 9.3. In running 2 mirror vdevs in the only= pool on a 9.3 system. It's a bootable pool, and I've treated booting fro= m all 4 disks (changing boot order in BIOS) without issues. >=20 > Typos courtesy of my phone. >=20 > On Jun 8, 2015 6:30 PM, "Aristedes Maniatis" > wrote: >=20 > I'm running 9.2-release on a machine and when I try to expand the m= irror of two disks with another two disk mirror, I get an error that I ca= nnot add another vdev to the boot pool. >=20 > I know this used to be an issue some time ago, but I see articles a= bout bypassing the check by unsetting bootfs attribute temporarily. That = seems dangerous however and I don't want to create an unbootable array. >=20 > Is this error really still an error in 9.2? I certainly have a 10.1= system which boots from a 3 vdev array. Do I need to upgrade this system= to allow for booting from such an array? >=20 > Thanks > Ari >=20 >=20 > -- > --------------------------> > Aristedes Maniatis > ish > http://www.ish.com.au > Level 1, 30 Wilson Street Newtown 2042 Australia > phone +61 2 9550 5001 fax +61 2 955= 0 4001 > GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A >=20 --=20 --------------------------> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A --Lo90CJlgbbu3bOmpkF56LfOaHx9pxL0uG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlV2WTwACgkQ72p9Lj5JECpYGACfdbjxvTXzVcQ1P/cLN12h/drU vWcAn2bMmFj6VWQdZDBdALpWznYyV+VP =A82t -----END PGP SIGNATURE----- --Lo90CJlgbbu3bOmpkF56LfOaHx9pxL0uG-- From owner-freebsd-fs@FreeBSD.ORG Tue Jun 9 05:57:05 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4480F39D for ; Tue, 9 Jun 2015 05:57:05 +0000 (UTC) (envelope-from karli.sjoberg@slu.se) Received: from exch2-4.slu.se (pop.slu.se [77.235.224.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "webmail.slu.se", Issuer "TERENA SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CD7021FA0 for ; Tue, 9 Jun 2015 05:57:04 +0000 (UTC) (envelope-from karli.sjoberg@slu.se) Received: from exch2-4.slu.se (77.235.224.124) by exch2-4.slu.se (77.235.224.124) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 9 Jun 2015 07:56:28 +0200 Received: from exch2-4.slu.se ([fe80::3117:818f:aa48:9d9b]) by exch2-4.slu.se ([fe80::3117:818f:aa48:9d9b%22]) with mapi id 15.00.1076.000; Tue, 9 Jun 2015 07:56:28 +0200 From: =?utf-8?B?S2FybGkgU2rDtmJlcmc=?= To: Aristedes Maniatis CC: Freddie Cash , FreeBSD Filesystems Subject: Re: multiple vdevs on boot ZFS pool Thread-Topic: multiple vdevs on boot ZFS pool Thread-Index: AQHQolPTMeiu2B6oPEKn2pZ9O1kJ3J2jStKAgAASxICAAC5lAA== Date: Tue, 9 Jun 2015 05:56:27 +0000 Message-ID: <1433829412.25293.41.camel@data-b104.adm.slu.se> References: <55763CF1.1020100@ish.com.au> <55765939.4090503@ish.com.au> In-Reply-To: <55765939.4090503@ish.com.au> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [77.235.228.32] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 05:57:05 -0000 dGlzIDIwMTUtMDYtMDkga2xvY2thbiAxMzoxMCArMTAwMCBza3JldiBBcmlzdGVkZXMgTWFuaWF0 aXM6DQo+IElzIHRoZSAnaXNzdWUnIHRoYXQgdGhlIGVycm9yIG1lc3NhZ2UgY2FuIGJlIGlnbm9y ZWQsIG9yIHRoYXQgeW91IGNhbid0IGJvb3QgaW4gOS4yPw0KDQpUaGUgZXJyb3IgbWVzc2FnZSBj YW4gYmUgaWdub3JlZC4gSnVzdCB1bnNldCB0aGUgYm9vdGZzIHByb3BlcnR5DQp0ZW1wb3Jhcmls eSwgYWRkIHRoZSBkaXNrcyBhbmQgdGhlbiByZXNldCBib290ZnMuDQoNCkRvbsK0dCBmb3JnZXQg dG8gcGFydGl0aW9uIHRoZSBkaXNrcyB3aXRoIGEgImZyZWVic2QtYm9vdCIgcGFydGl0aW9uLA0K Ym9vdGNvZGUgdGhhdCwgdGhlIHpmcyBwYXJ0aXRpb24gc2hvdWxkIGJlIGFsaWduZWQgdG8gMU1p QiBhbmQgdXNlIGdub3ANCnRvIGZvcmNlICJhc2hpZnQ9MTIiIGZvciB0aGUgdmRldi4NCg0KL0sN Cg0KPiANCj4gVGhhbmtzDQo+IEFyaQ0KPiANCj4gT24gOS8wNi8yMDE1IDEyOjAzcG0sIEZyZWRk aWUgQ2FzaCB3cm90ZToNCj4gPiBJdCdzIGEgOS4yICJpc3N1ZSIsIGZpeGVkIGluIDkuMy4gSW4g cnVubmluZyAyIG1pcnJvciB2ZGV2cyBpbiB0aGUgb25seSBwb29sIG9uIGEgOS4zIHN5c3RlbS4g SXQncyBhIGJvb3RhYmxlIHBvb2wsIGFuZCBJJ3ZlIHRyZWF0ZWQgYm9vdGluZyBmcm9tIGFsbCA0 IGRpc2tzIChjaGFuZ2luZyBib290IG9yZGVyIGluIEJJT1MpIHdpdGhvdXQgaXNzdWVzLg0KPiA+ IA0KPiA+IFR5cG9zIGNvdXJ0ZXN5IG9mIG15IHBob25lLg0KPiA+IA0KPiA+IE9uIEp1biA4LCAy MDE1IDY6MzAgUE0sICJBcmlzdGVkZXMgTWFuaWF0aXMiIDxhcmlAaXNoLmNvbS5hdSA8bWFpbHRv OmFyaUBpc2guY29tLmF1Pj4gd3JvdGU6DQo+ID4gDQo+ID4gICAgIEknbSBydW5uaW5nIDkuMi1y ZWxlYXNlIG9uIGEgbWFjaGluZSBhbmQgd2hlbiBJIHRyeSB0byBleHBhbmQgdGhlIG1pcnJvciBv ZiB0d28gZGlza3Mgd2l0aCBhbm90aGVyIHR3byBkaXNrIG1pcnJvciwgSSBnZXQgYW4gZXJyb3Ig dGhhdCBJIGNhbm5vdCBhZGQgYW5vdGhlciB2ZGV2IHRvIHRoZSBib290IHBvb2wuDQo+ID4gDQo+ ID4gICAgIEkga25vdyB0aGlzIHVzZWQgdG8gYmUgYW4gaXNzdWUgc29tZSB0aW1lIGFnbywgYnV0 IEkgc2VlIGFydGljbGVzIGFib3V0IGJ5cGFzc2luZyB0aGUgY2hlY2sgYnkgdW5zZXR0aW5nIGJv b3RmcyBhdHRyaWJ1dGUgdGVtcG9yYXJpbHkuIFRoYXQgc2VlbXMgZGFuZ2Vyb3VzIGhvd2V2ZXIg YW5kIEkgZG9uJ3Qgd2FudCB0byBjcmVhdGUgYW4gdW5ib290YWJsZSBhcnJheS4NCj4gPiANCj4g PiAgICAgSXMgdGhpcyBlcnJvciByZWFsbHkgc3RpbGwgYW4gZXJyb3IgaW4gOS4yPyBJIGNlcnRh aW5seSBoYXZlIGEgMTAuMSBzeXN0ZW0gd2hpY2ggYm9vdHMgZnJvbSBhIDMgdmRldiBhcnJheS4g RG8gSSBuZWVkIHRvIHVwZ3JhZGUgdGhpcyBzeXN0ZW0gdG8gYWxsb3cgZm9yIGJvb3RpbmcgZnJv bSBzdWNoIGFuIGFycmF5Pw0KPiA+IA0KPiA+ICAgICBUaGFua3MNCj4gPiAgICAgQXJpDQo+ID4g DQo+ID4gDQo+ID4gICAgIC0tDQo+ID4gICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPg0K PiA+ICAgICBBcmlzdGVkZXMgTWFuaWF0aXMNCj4gPiAgICAgaXNoDQo+ID4gICAgIGh0dHA6Ly93 d3cuaXNoLmNvbS5hdQ0KPiA+ICAgICBMZXZlbCAxLCAzMCBXaWxzb24gU3RyZWV0IE5ld3Rvd24g MjA0MiBBdXN0cmFsaWENCj4gPiAgICAgcGhvbmUgKzYxIDIgOTU1MCA1MDAxIDx0ZWw6JTJCNjEl MjAyJTIwOTU1MCUyMDUwMDE+ICAgZmF4ICs2MSAyIDk1NTAgNDAwMSA8dGVsOiUyQjYxJTIwMiUy MDk1NTAlMjA0MDAxPg0KPiA+ICAgICBHUEcgZmluZ2VycHJpbnQgQ0JGQiA4NEI0IDczOEQgNEU4 NyA1RTVDICA1RUZBIEVGNkEgN0QyRSAzRTQ5IDEwMkENCj4gPiANCj4gDQoNCg== From owner-freebsd-fs@FreeBSD.ORG Tue Jun 9 12:36:41 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7698A2B for ; Tue, 9 Jun 2015 12:36:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C16181147 for ; Tue, 9 Jun 2015 12:36:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t59Caf77074534 for ; Tue, 9 Jun 2015 12:36:41 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 198242] [zfs] L2ARC degraded. Checksum errors, I/O errors Date: Tue, 09 Jun 2015 12:36:40 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: avg@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 12:36:41 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198242 --- Comment #7 from Andriy Gapon --- A patch to try / test: https://reviews.freebsd.org/file/data/x6oyddfagrgemmop3ygg/PHID-FILE-mpah42klhz4g4v6rqrfc/D2764.diff -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Tue Jun 9 15:22:49 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD8CAADB for ; Tue, 9 Jun 2015 15:22:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C89DE1CF5 for ; Tue, 9 Jun 2015 15:22:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t59FMn98055578 for ; Tue, 9 Jun 2015 15:22:49 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 198242] [zfs] L2ARC degraded. Checksum errors, I/O errors Date: Tue, 09 Jun 2015 15:22:49 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: gkontos@aicom.gr X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 15:22:50 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198242 --- Comment #8 from gkontos@aicom.gr --- Thanks Andiry, the link appears to be broken though. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Tue Jun 9 15:32:40 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5D0B0C20 for ; Tue, 9 Jun 2015 15:32:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4780B1F24 for ; Tue, 9 Jun 2015 15:32:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t59FWeIP066286 for ; Tue, 9 Jun 2015 15:32:40 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 198242] [zfs] L2ARC degraded. Checksum errors, I/O errors Date: Tue, 09 Jun 2015 15:32:39 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: Karli.Sjoberg@slu.se X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 15:32:40 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198242 Karli.Sjoberg@slu.se changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Karli.Sjoberg@slu.se --- Comment #9 from Karli.Sjoberg@slu.se --- I took a look at it before leaving work but now it's gone?! -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Tue Jun 9 16:40:52 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 28A1C517 for ; Tue, 9 Jun 2015 16:40:52 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from mail.in-addr.com (mail.in-addr.com [IPv6:2a01:4f8:191:61e8::2525:2525]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E2F9D1F6C for ; Tue, 9 Jun 2015 16:40:51 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by mail.in-addr.com with local (Exim 4.85 (FreeBSD)) (envelope-from ) id 1Z2Ma1-00064A-Gl; Tue, 09 Jun 2015 17:40:49 +0100 Date: Tue, 9 Jun 2015 17:40:49 +0100 From: Gary Palmer To: Karli Sj??berg Cc: Aristedes Maniatis , FreeBSD Filesystems Subject: Re: multiple vdevs on boot ZFS pool Message-ID: <20150609164049.GB29089@in-addr.com> References: <55763CF1.1020100@ish.com.au> <55765939.4090503@ish.com.au> <1433829412.25293.41.camel@data-b104.adm.slu.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1433829412.25293.41.camel@data-b104.adm.slu.se> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on mail.in-addr.com); SAEximRunCond expanded to false X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 16:40:52 -0000 On Tue, Jun 09, 2015 at 05:56:27AM +0000, Karli Sj??berg wrote: > tis 2015-06-09 klockan 13:10 +1000 skrev Aristedes Maniatis: > > Is the 'issue' that the error message can be ignored, or that you can't boot in 9.2? > > The error message can be ignored. Just unset the bootfs property > temporarily, add the disks and then reset bootfs. > > Don??t forget to partition the disks with a "freebsd-boot" partition, > bootcode that, the zfs partition should be aligned to 1MiB and use gnop > to force "ashift=12" for the vdev. Ari should really upgrade to 9.3 at least. 9.2 isn't receiving security fixes any more (as of Dec 31 2014). If that fixes the zfs issue at the same time so much the better. Regards, Gary > > > > Thanks > > Ari > > > > On 9/06/2015 12:03pm, Freddie Cash wrote: > > > It's a 9.2 "issue", fixed in 9.3. In running 2 mirror vdevs in the only pool on a 9.3 system. It's a bootable pool, and I've treated booting from all 4 disks (changing boot order in BIOS) without issues. > > > > > > Typos courtesy of my phone. > > > > > > On Jun 8, 2015 6:30 PM, "Aristedes Maniatis" > wrote: > > > > > > I'm running 9.2-release on a machine and when I try to expand the mirror of two disks with another two disk mirror, I get an error that I cannot add another vdev to the boot pool. > > > > > > I know this used to be an issue some time ago, but I see articles about bypassing the check by unsetting bootfs attribute temporarily. That seems dangerous however and I don't want to create an unbootable array. > > > > > > Is this error really still an error in 9.2? I certainly have a 10.1 system which boots from a 3 vdev array. Do I need to upgrade this system to allow for booting from such an array? > > > > > > Thanks > > > Ari > > > > > > > > > -- > > > --------------------------> > > > Aristedes Maniatis > > > ish > > > http://www.ish.com.au > > > Level 1, 30 Wilson Street Newtown 2042 Australia > > > phone +61 2 9550 5001 fax +61 2 9550 4001 > > > GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A > > > > > > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Tue Jun 9 17:57:46 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B33BC209 for ; Tue, 9 Jun 2015 17:57:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9E079128F for ; Tue, 9 Jun 2015 17:57:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t59HvkbI082570 for ; Tue, 9 Jun 2015 17:57:46 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 198242] [zfs] L2ARC degraded. Checksum errors, I/O errors Date: Tue, 09 Jun 2015 17:57:43 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: avg@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 17:57:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198242 --- Comment #10 from Andriy Gapon --- Please try this one instead: https://reviews.freebsd.org/D2764?download=true -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Thu Jun 11 20:28:15 2015 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C394EC50 for ; Thu, 11 Jun 2015 20:28:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AD9A01E63 for ; Thu, 11 Jun 2015 20:28:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t5BKSFTN066160 for ; Thu, 11 Jun 2015 20:28:15 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 198242] [zfs] L2ARC degraded. Checksum errors, I/O errors Date: Thu, 11 Jun 2015 20:28:11 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: oconnor@crystal.harvard.edu X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-fs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 20:28:15 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198242 Justin changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |oconnor@crystal.harvard.edu --- Comment #11 from Justin --- Thanks Andriy. Looks like the patch is for stable/10. Will upgrade a box from release to stable for testing. 1 issue (svn co stable/10 today)- Hunk #10 failed at 5324. 1 out of 10 hunks failed while patching sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c done Patched anyways and found the other lines by hand - diff arc.c arc.c.orig ... 5327,5328c5305,5306 < ARCSTAT_INCR(arcstat_l2_asize, stats_size); < vdev_space_update(dev->l2ad_vdev, stats_size, 0, 0); > ARCSTAT_INCR(arcstat_l2_asize, write_asize); > vdev_space_update(dev->l2ad_vdev, write_psize, 0, 0); Cheers -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-fs@FreeBSD.ORG Fri Jun 12 13:49:51 2015 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C028AD3 for ; Fri, 12 Jun 2015 13:49:51 +0000 (UTC) (envelope-from felipemonteiro.carvalho@gmail.com) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 72F3A1DF0 for ; Fri, 12 Jun 2015 13:49:51 +0000 (UTC) (envelope-from felipemonteiro.carvalho@gmail.com) Received: by pacyx8 with SMTP id yx8so23629962pac.2 for ; Fri, 12 Jun 2015 06:49:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=bnIuqotZbaiEnRuRxlHFXN0P9X6qOh4V5FfwoUXH8/U=; b=KHQfpHJUwggj2XbfgdPUZDKM/MFY588j+beKe7fvxZ/arGrN1Fz9W0I6LbY0sdYvA+ zxVDKRvbSK38fTlCygztPlxAYRGr1wW2NTiN4F0WM1HBCsVaIeMQXn6NgD8z4rQVNLWB k/me7qQJzr+XPwf0FZIXCrbcnN5ZbnC9VwQ3ZQTIMo3EgsUOWumCzjFAB0/QppqgSjXr m5jjaDakZlsHv2Z4i7TQaEm/c79RjIyceCA0IU5UUE7HjCdSL+S1joWuLBo6Cz9ttwgy 97BESYXWQyLyd63mEmz/9NJHodegtk/N7JdhMjtAudFNysLGCSU/9ZpvsZCnrYaBaK1r Wc/A== MIME-Version: 1.0 X-Received: by 10.66.122.5 with SMTP id lo5mr23509524pab.141.1434116990915; Fri, 12 Jun 2015 06:49:50 -0700 (PDT) Received: by 10.66.147.4 with HTTP; Fri, 12 Jun 2015 06:49:50 -0700 (PDT) Date: Fri, 12 Jun 2015 15:49:50 +0200 Message-ID: Subject: Uberblock location From: Felipe Monteiro de Carvalho To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 13:49:51 -0000 Hello, I am writing a program to read ZFS partitions, and although I already read a lot of documentation, there is 1 problem which is blocking me: How does the driver find the uberblock? I know, I can just get any test volume, find the ZFS uberblock and in my case it is positioned in 0x20C00 and there are lots and lots of copies (older versions?) of it. But there is no guarantee that it doesn't just happen to be in this position in my image and in another version it would be elsewhere, so I need the algorithm utilized to find it. Any ideas? thanks, -- Felipe Monteiro de Carvalho From owner-freebsd-fs@FreeBSD.ORG Fri Jun 12 16:01:39 2015 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 420CA340 for ; Fri, 12 Jun 2015 16:01:39 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9F195650 for ; Fri, 12 Jun 2015 16:01:38 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from jre-mbp.elischer.org (ppp121-45-248-228.lns20.per4.internode.on.net [121.45.248.228]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t5CG1Vns075470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 12 Jun 2015 09:01:34 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <557B0255.8060809@freebsd.org> Date: Sat, 13 Jun 2015 00:01:25 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Felipe Monteiro de Carvalho , freebsd-fs@freebsd.org Subject: Re: Uberblock location References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 16:01:39 -0000 On 6/12/15 9:49 PM, Felipe Monteiro de Carvalho wrote: > Hello, > > I am writing a program to read ZFS partitions, and although I already > read a lot of documentation, there is 1 problem which is blocking me: > How does the driver find the uberblock? > > I know, I can just get any test volume, find the ZFS uberblock and in > my case it is positioned in 0x20C00 and there are lots and lots of > copies (older versions?) of it. > > But there is no guarantee that it doesn't just happen to be in this > position in my image and in another version it would be elsewhere, so > I need the algorithm utilized to find it. I presume you have looked at the zfs reading library in the bootblocks? > > Any ideas? > > thanks, From owner-freebsd-fs@FreeBSD.ORG Fri Jun 12 16:31:52 2015 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CFB17EB2 for ; Fri, 12 Jun 2015 16:31:52 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 67EE2E00 for ; Fri, 12 Jun 2015 16:31:51 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id t5CGCcvG055635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 12 Jun 2015 18:12:39 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id t5CGCaN0079030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jun 2015 18:12:36 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id t5CGCahs086780; Fri, 12 Jun 2015 18:12:36 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id t5CGCZWI086779; Fri, 12 Jun 2015 18:12:35 +0200 (CEST) (envelope-from ticso) Date: Fri, 12 Jun 2015 18:12:35 +0200 From: Bernd Walter To: freebsd-fs@freebsd.org Cc: Bernd Walter Subject: ZFS dedup problem Message-ID: <20150612161235.GC85104@cicely7.cicely.de> Reply-To: ticso@cicely.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 16:31:52 -0000 On one given system I have some ZFS filesystems with dedup enabled. Now it happened to me that because of some strange disk problem a deduped file got damaged because RAIDZ redundance wasn't enough in this case. Well, ok so far. Without dedup I would just ignore snapshots, delete the file in the current dataset, recopy it from backup source and be done. With dedup however the new file got relinked to the unreadable data. Well - I could theoretically disable dedup to recopy the file, but if I reenable dedup any other file with same content might get relinked to the bad data as well. In this case it was Ok for me to drop all snapshots to work around. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-fs@FreeBSD.ORG Sat Jun 13 03:50:45 2015 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CE240743 for ; Sat, 13 Jun 2015 03:50:45 +0000 (UTC) (envelope-from matthew.ahrens@delphix.com) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 906E3E72 for ; Sat, 13 Jun 2015 03:50:45 +0000 (UTC) (envelope-from matthew.ahrens@delphix.com) Received: by iesa3 with SMTP id a3so34580777ies.2 for ; Fri, 12 Jun 2015 20:50:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphix.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7PRVerDub9qP2YQZiZ59VcomnkWy2z3CLl6NVgfsGlk=; b=KecRkZa0UIGw+aULxRz1xmMPDYUHEo1VV8HTBoLKuNZgPqBYhBP4lMkss2/xtTQmXN 9gRY13Qv6EXO0hpqqrjPLMqQj1Ue6x825B5W012ISj6mEwkJs2lkcd6QRbdV4lB+ppTM nm0I5Lm7Js8WiBHezg+87a3p5XpH3Hoz7SJ+c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7PRVerDub9qP2YQZiZ59VcomnkWy2z3CLl6NVgfsGlk=; b=BJM5W9JpgK78gpDSPGNqAgbwWD60L14z30PENafSUeUmUxp2vahEGW0gNl7z9aljkd 4ibMFq5Ingh3Xi0sgfshdao0AVDdjbTgBKs3rt2qMsHbBmjTF9hojhCqmZgUh6r30QF/ hzSnCrZrpU53qXqoWDzmHOMbdgzv5f7xbnFToGmb6T8eN/qzuiy1nChFJNpgZrzyoBQp 0SgSToW1+3mhPng2RCIe1+ewdtTbgPk++60uZuPysvHnQjYK3D2ns3qq1dDG4/SIHJEA iwb4St+1V6Jw6rr8jaPomx2jXl5Icjv0xXlE5y75ECUx7RXG1tfhA0t7NryIuVlU7kZB x01Q== X-Gm-Message-State: ALoCoQnikgEhAOLAuhbL0kPkUYoiliI+QO9Em2ZcP24XpP0WuNyv8eJStfPry6xoEBN/evh7cIen MIME-Version: 1.0 X-Received: by 10.107.15.163 with SMTP id 35mr13003879iop.44.1434167444895; Fri, 12 Jun 2015 20:50:44 -0700 (PDT) Received: by 10.36.85.197 with HTTP; Fri, 12 Jun 2015 20:50:44 -0700 (PDT) In-Reply-To: References: Date: Fri, 12 Jun 2015 20:50:44 -0700 Message-ID: Subject: Re: ZFS read performance disparity between clone and parent From: Matthew Ahrens To: Nathan Weeks Cc: freebsd-fs Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2015 03:50:45 -0000 On Wed, May 13, 2015 at 11:54 AM, Nathan Weeks wrote: > While troubleshooting performance disparities between development and > production jails hosting PostgreSQL instances, I noticed (with the help of > dtruss) that the 8k read() performance in the production jail was an order > of > magnitude worse than the read() performance in the development jail. As the > ZFS file system hosting the production jail was cloned from a snapshot of > the > development jail, and had not been modified, this didn't make sense to me. > > Using "dd" command with an 8k block size to emulate the PostgreSQL read() > size, I observed a large performance difference between reading one of the > large (1G) underlying postgres database files in the development jail's > file > system vs. the corresponding file in the cloned file system: > > # dd if=/jails/dev/usr/local/pgsql/data/base/16399/16436 of=/dev/null > bs=8192 > 131072+0 records in > 131072+0 records out > 1073741824 bytes transferred in 4.198993 secs (255714128 bytes/sec) > # dd if=/jails/prod/usr/local/pgsql/data/base/16399/16436 of=/dev/null > bs=8192 > 131072+0 records in > 131072+0 records out > 1073741824 bytes transferred in 17.314135 secs (62015331 bytes/sec) > # ls -l /jails/dev/usr/local/pgsql/data/base/16399/16436 > /jails/prod/usr/local/pgsql/data/base/16399/16436 > -rw------- 1 70 70 1073741824 Feb 5 16:41 > /jails/dev/usr/local/pgsql/data/base/16399/16436 > -rw------- 1 70 70 1073741824 Feb 5 16:41 > /jails/prod/usr/local/pgsql/data/base/16399/16436 > > I repeated this exercise several times to verify the read performance > difference. Interestingly, prefixing the "dd" command with "/usr/bin/time > -l" > revealed that in both cases, "block input operations" was 0, apparently > indicating that both files were being read from cache. In neither case did > "zpool iostat 1" show significant I/O being performed during the execution > of > the "dd" command. > > Has anyone else encountered a similar issue, and know of an > explanation/solution/better workaround? I had previously assumed that there > would be no performance difference between reading a file on a ZFS file > system > and the corresponding file on a cloned file system when none of the data > blocks have changed (this is FreeBSD 9.3, so the "Single Copy ARC" feature > should apply). Dedup isn't being used on any file system. > An unfortunate byproduct of the "single copy ARC" is that the first dataset to read a block performs better than subsequent readers, which have to do an extra bcopy() of the block. You should be able to alleviate this by evicting the buffers by unmounting the first filesystem or running "zinject -a". We are working on a fix for this as part of the "compressed ARC" feature that will be coming soon. You can verify this by looking at the flame graphs of CPU usage in both cases.(http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html) --matt > > The output of zfs-stats follows; I can provide any additional info that > might > be of use in identifying the cause of this issue. > > ------------------------------------------------------------------------ > ZFS Subsystem Report Wed May 13 12:22:00 2015 > ------------------------------------------------------------------------ > > System Information: > > Kernel Version: 903000 (osreldate) > Hardware Platform: amd64 > Processor Architecture: amd64 > > ZFS Storage pool Version: 5000 > ZFS Filesystem Version: 5 > > FreeBSD 9.3-RELEASE-p5 #0: Mon Nov 3 22:38:58 UTC 2014 root > 12:22PM up 166 days, 3:36, 7 users, load averages: 2.34, 2.31, 2.17 > > ------------------------------------------------------------------------ > > System Memory: > > 8.83% 21.95 GiB Active, 1.67% 4.14 GiB Inact > 68.99% 171.40 GiB Wired, 0.40% 1.00 GiB Cache > 20.10% 49.93 GiB Free, 0.01% 16.12 MiB Gap > > Real Installed: 256.00 GiB > Real Available: 99.99% 255.97 GiB > Real Managed: 97.06% 248.43 GiB > > Logical Total: 256.00 GiB > Logical Used: 78.49% 200.92 GiB > Logical Free: 21.51% 55.08 GiB > > Kernel Memory: 117.28 GiB > Data: 99.98% 117.25 GiB > Text: 0.02% 26.07 MiB > > Kernel Memory Map: 241.10 GiB > Size: 43.83% 105.67 GiB > Free: 56.17% 135.43 GiB > > ------------------------------------------------------------------------ > > ARC Summary: (HEALTHY) > Memory Throttle Count: 0 > > ARC Misc: > Deleted: 143.56m > Recycle Misses: 275.73m > Mutex Misses: 1.50m > Evict Skips: 20.24b > > ARC Size: 99.77% 127.71 GiB > Target Size: (Adaptive) 100.00% 128.00 GiB > Min Size (Hard Limit): 12.50% 16.00 GiB > Max Size (High Water): 8:1 128.00 GiB > > ARC Size Breakdown: > Recently Used Cache Size: 68.86% 88.15 GiB > Frequently Used Cache Size: 31.14% 39.85 GiB > > ARC Hash Breakdown: > Elements Max: 27.87m > Elements Current: 40.13% 11.18m > Collisions: 1.95b > Chain Max: 26 > Chains: 2.44m > > ------------------------------------------------------------------------ > > ARC Efficiency: 88.77b > Cache Hit Ratio: 99.52% 88.34b > Cache Miss Ratio: 0.48% 426.00m > Actual Hit Ratio: 98.86% 87.76b > > Data Demand Efficiency: 99.99% 58.75b > Data Prefetch Efficiency: 98.47% 1.08b > > CACHE HITS BY CACHE LIST: > Anonymously Used: 0.21% 187.51m > Most Recently Used: 1.93% 1.71b > Most Frequently Used: 97.41% 86.05b > Most Recently Used Ghost: 0.04% 39.14m > Most Frequently Used Ghost: 0.41% 358.78m > > CACHE HITS BY DATA TYPE: > Demand Data: 66.49% 58.74b > Prefetch Data: 1.21% 1.07b > Demand Metadata: 31.74% 28.04b > Prefetch Metadata: 0.56% 491.01m > > CACHE MISSES BY DATA TYPE: > Demand Data: 1.70% 7.26m > Prefetch Data: 3.89% 16.56m > Demand Metadata: 83.84% 357.15m > Prefetch Metadata: 10.57% 45.03m > > ------------------------------------------------------------------------ > > L2ARC is disabled > > ------------------------------------------------------------------------ > > File-Level Prefetch: (HEALTHY) > > DMU Efficiency: 187.26b > Hit Ratio: 82.21% 153.94b > Miss Ratio: 17.79% 33.32b > > Colinear: 33.32b > Hit Ratio: 0.01% 3.35m > Miss Ratio: 99.99% 33.32b > > Stride: 150.63b > Hit Ratio: 100.00% 150.63b > Miss Ratio: 0.00% 453.04k > > DMU Misc: > Reclaim: 33.32b > Successes: 0.36% 118.64m > Failures: 99.64% 33.20b > > Streams: 3.31b > +Resets: 0.00% 20.36k > -Resets: 100.00% 3.31b > Bogus: 0 > > ------------------------------------------------------------------------ > > VDEV cache is disabled > > ------------------------------------------------------------------------ > > ZFS Tunables (sysctl): > kern.maxusers 16718 > vm.kmem_size 266754412544 > vm.kmem_size_scale 1 > vm.kmem_size_min 0 > vm.kmem_size_max 329853485875 > vfs.zfs.l2c_only_size 0 > vfs.zfs.mfu_ghost_data_lsize 63695688192 > vfs.zfs.mfu_ghost_metadata_lsize 8300248064 > vfs.zfs.mfu_ghost_size 71995936256 > vfs.zfs.mfu_data_lsize 34951425024 > vfs.zfs.mfu_metadata_lsize 4976638976 > vfs.zfs.mfu_size 41843978240 > vfs.zfs.mru_ghost_data_lsize 41844330496 > vfs.zfs.mru_ghost_metadata_lsize 23598693888 > vfs.zfs.mru_ghost_size 65443024384 > vfs.zfs.mru_data_lsize 67918019072 > vfs.zfs.mru_metadata_lsize 411918848 > vfs.zfs.mru_size 71823354880 > vfs.zfs.anon_data_lsize 0 > vfs.zfs.anon_metadata_lsize 0 > vfs.zfs.anon_size 29893120 > vfs.zfs.l2arc_norw 1 > vfs.zfs.l2arc_feed_again 1 > vfs.zfs.l2arc_noprefetch 1 > vfs.zfs.l2arc_feed_min_ms 200 > vfs.zfs.l2arc_feed_secs 1 > vfs.zfs.l2arc_headroom 2 > vfs.zfs.l2arc_write_boost 8388608 > vfs.zfs.l2arc_write_max 8388608 > vfs.zfs.arc_meta_limit 34359738368 > vfs.zfs.arc_meta_used 34250008792 > vfs.zfs.arc_min 17179869184 > vfs.zfs.arc_max 137438953472 > vfs.zfs.dedup.prefetch 1 > vfs.zfs.mdcomp_disable 0 > vfs.zfs.nopwrite_enabled 1 > vfs.zfs.zfetch.array_rd_sz 1048576 > vfs.zfs.zfetch.block_cap 256 > vfs.zfs.zfetch.min_sec_reap 2 > vfs.zfs.zfetch.max_streams 8 > vfs.zfs.prefetch_disable 0 > vfs.zfs.no_scrub_prefetch 0 > vfs.zfs.no_scrub_io 0 > vfs.zfs.resilver_min_time_ms 3000 > vfs.zfs.free_min_time_ms 1000 > vfs.zfs.scan_min_time_ms 1000 > vfs.zfs.scan_idle 50 > vfs.zfs.scrub_delay 4 > vfs.zfs.resilver_delay 2 > vfs.zfs.top_maxinflight 32 > vfs.zfs.write_to_degraded 0 > vfs.zfs.mg_noalloc_threshold 0 > vfs.zfs.condense_pct 200 > vfs.zfs.metaslab.weight_factor_enable 0 > vfs.zfs.metaslab.preload_enabled 1 > vfs.zfs.metaslab.preload_limit 3 > vfs.zfs.metaslab.unload_delay 8 > vfs.zfs.metaslab.load_pct 50 > vfs.zfs.metaslab.min_alloc_size 10485760 > vfs.zfs.metaslab.df_free_pct 4 > vfs.zfs.metaslab.df_alloc_threshold 131072 > vfs.zfs.metaslab.debug_unload 0 > vfs.zfs.metaslab.debug_load 0 > vfs.zfs.metaslab.gang_bang 131073 > vfs.zfs.check_hostid 1 > vfs.zfs.spa_asize_inflation 24 > vfs.zfs.deadman_enabled 1 > vfs.zfs.deadman_checktime_ms 5000 > vfs.zfs.deadman_synctime_ms 1000000 > vfs.zfs.recover 0 > vfs.zfs.txg.timeout 5 > vfs.zfs.min_auto_ashift 9 > vfs.zfs.max_auto_ashift 13 > vfs.zfs.vdev.cache.bshift 16 > vfs.zfs.vdev.cache.size 0 > vfs.zfs.vdev.cache.max 16384 > vfs.zfs.vdev.trim_on_init 1 > vfs.zfs.vdev.write_gap_limit 4096 > vfs.zfs.vdev.read_gap_limit 32768 > vfs.zfs.vdev.aggregation_limit 131072 > vfs.zfs.vdev.scrub_max_active 2 > vfs.zfs.vdev.scrub_min_active 1 > vfs.zfs.vdev.async_write_max_active 10 > vfs.zfs.vdev.async_write_min_active 1 > vfs.zfs.vdev.async_read_max_active 3 > vfs.zfs.vdev.async_read_min_active 1 > vfs.zfs.vdev.sync_write_max_active 10 > vfs.zfs.vdev.sync_write_min_active 10 > vfs.zfs.vdev.sync_read_max_active 10 > vfs.zfs.vdev.sync_read_min_active 10 > vfs.zfs.vdev.max_active 1000 > vfs.zfs.vdev.bio_delete_disable 0 > vfs.zfs.vdev.bio_flush_disable 0 > vfs.zfs.vdev.trim_max_pending 64 > vfs.zfs.vdev.trim_max_bytes 2147483648 > vfs.zfs.cache_flush_disable 0 > vfs.zfs.zil_replay_disable 0 > vfs.zfs.sync_pass_rewrite 2 > vfs.zfs.sync_pass_dont_compress 5 > vfs.zfs.sync_pass_deferred_free 2 > vfs.zfs.zio.use_uma 0 > vfs.zfs.snapshot_list_prefetch 0 > vfs.zfs.version.ioctl 3 > vfs.zfs.version.zpl 5 > vfs.zfs.version.spa 5000 > vfs.zfs.version.acl 1 > vfs.zfs.debug 0 > vfs.zfs.super_owner 0 > vfs.zfs.trim.enabled 1 > vfs.zfs.trim.max_interval 1 > vfs.zfs.trim.timeout 30 > vfs.zfs.trim.txg_delay 32 > > ------------------------------------------------------------------------ > > -- > Nathan Weeks > USDA-ARS Corn Insects and Crop Genetics Research Unit > Crop Genome Informatics Laboratory > Iowa State University > http://weeks.public.iastate.edu/ > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Sat Jun 13 09:31:22 2015 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8EA08BC6 for ; Sat, 13 Jun 2015 09:31:22 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1E8A8688 for ; Sat, 13 Jun 2015 09:31:22 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by wifx6 with SMTP id x6so34744810wif.0 for ; Sat, 13 Jun 2015 02:31:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=1tdp4q/GpV+zPZt1zN61+43Ngs3PoNiReS52EPFQ22o=; b=pMb9mU0Xl5Po22MYL4+Mu50kvUOT2N4lZDcGBnI2c4qeuDNqyMNRCK6xLz8ZbcMEsF jnNuEBR6HNZidSBYyL3fKi/DSQ1hepfsvT5VnZOnNdTxz26HsNnI03UEkwaBNO/XHJz4 aa4zkg0Azt4UqJB2jWb/reFH9DWVi41nyAfsWhDHlR98ii66va/2rfOzTiqfN/sotF9m YqJR3ZK5iOcTlD6cwaqHBelsthye+R/AEhppdovJyinFwYt/NO8n7xevqw7ME00GzKfi uIM2gkN5RfKUrJs9Q9KPp4ZY0i7gOvR9Stgi3ccGapgYD1klyYhJgcu3C7Bi/lIERGjk H/yQ== X-Received: by 10.194.175.65 with SMTP id by1mr34651361wjc.152.1434187880573; Sat, 13 Jun 2015 02:31:20 -0700 (PDT) Received: from brick.home (eug18.neoplus.adsl.tpnet.pl. [83.20.178.18]) by mx.google.com with ESMTPSA id ha4sm6482236wib.0.2015.06.13.02.31.19 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 13 Jun 2015 02:31:19 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Sat, 13 Jun 2015 11:31:17 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Karli =?iso-8859-1?Q?Sj=F6berg?= Cc: Andreas Nilsson , "freebsd-fs@freebsd.org" Subject: Re: [Fwd: Strange networking behaviour in storage server] Message-ID: <20150613093117.GB37870@brick.home> Mail-Followup-To: Karli =?iso-8859-1?Q?Sj=F6berg?= , Andreas Nilsson , "freebsd-fs@freebsd.org" References: <1433146506.14998.177.camel@data-b104.adm.slu.se> <1433149349.14998.181.camel@data-b104.adm.slu.se> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1433149349.14998.181.camel@data-b104.adm.slu.se> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2015 09:31:22 -0000 On 0601T0902, Karli Sjöberg wrote: > mån 2015-06-01 klockan 10:33 +0200 skrev Andreas Nilsson: > > > > > > On Mon, Jun 1, 2015 at 10:14 AM, Karli Sjöberg > > wrote: > > -------- Vidarebefordrat meddelande -------- > > > Från: Karli Sjöberg > > > Till: freebsd-fs@freebsd.org > > > Ämne: Strange networking behaviour in storage server > > > Datum: Mon, 1 Jun 2015 07:49:56 +0000 > > > > > > Hey! > > > > > > So we have this ZFS storage server upgraded from 9.3-RELEASE > > to > > > 10.1-STABLE to overcome not being able to 1) use SSD drives > > as > > > L2ARC[1] > > > and 2) not being able to hotswap SATA drives[2]. > > > > > > After the upgrade we´ve noticed a very odd networking > > behaviour, it > > > sends/receives full speed for a while, then there is a > > couple of > > > minutes > > > of complete silence where even terminal commands like an > > "ls" just > > > waits > > > until they are executed and then it starts sending full > > speed again. I > > > ´ve linked to a screenshot showing this send and pause > > behaviour. The > > > blue line is the total, green is SMB and turquoise is NFS > > over jumbo > > > frames. It behaves this way regardless of the protocol. > > > > > > http://oi62.tinypic.com/33xvjb6.jpg > > > > > > The problem is that these pauses can sometimes be so long > > that > > > connections drop. Like someone is copying files over SMB or > > iSCSI and > > > suddenly they get an error message saying that the transfer > > failed and > > > they have to start over with the file(s). That´s horrible! > > > > > > So far NFS has proven to be the most resillient, it´s stupid > > simple > > > nature just waits and resumes transfer when pause is over. > > Kudus for > > > that. > > > > > > The server is driven by a Supermicro X9SRL-F, a Xeon 1620v2 > > and 64GB > > > ECC > > > RAM. The hardware has been ruled out, we happened to have a > > identical > > > MB > > > and CPU lying around and that didn´t improve things. We have > > also > > > installed a Intel PRO 100/1000 Quad-port ethernet adapter to > > test if > > > that would change things, but it hasn´t, it still behaves > > this way. > > > > > > The two built-in NIC's are Intel 82574L and the Quad-port > > NIC's are > > > Intel 82571EB, so both em(4) driven. I happen to know that > > the em > > > driver > > > has updated between 9.3 and 10.1. Perhaps that is to blame, > > but I have > > > no idea. > > > > > > Is there anyone that can make sense of this? > > > > > > [1]: > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197164 > > > > > > [2]: > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191348 > > > > > > /K > > > > > > > > > > > > Another observation I´ve made is that during these pauses, the > > entire > > system is put on hold, even ZFS scrub stops and then resumes > > after a > > while. Looking in top, the system is completly idle. > > > > Normally during scrub, the kernel eats 20-30% CPU, but during > > a pause, > > even the [kernel] goes down to 0.00%. Makes me think the > > networking has > > nothing to do with it. > > > > What´s then to blame? ZFS? > > > > /K > > _______________________________________________ > > 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" > > > > > > Hello, > > > > > > does this happen when clients are only reading from server? > > Yes it happens when clients are only reading from the server. > > > Otherwise I would suspect that it could be caused by ZFS writing out a > > large chunck of data sitting in its caches, and until that is complete > > I/O is stalled. > > That´s what so strange, we have three more systems set up about the same > size and none of others are acting this way. > > The only thing I can think of that differs that we haven´t tested ruling > out yet is ctld, the other systems are still running istgt as their > iSCSI daemon. So, were you able to rule out ctld? Do you have local, or terminal, access to the machine? When the problem manifests, do local commands work? In other words, is the whole machine wedged, or just the network? If it's just the network, it might be caused by ctld consuming all available mbufs. You could run "netstat -m" before and after to check that. From owner-freebsd-fs@FreeBSD.ORG Sat Jun 13 09:42:50 2015 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B1C09E4D for ; Sat, 13 Jun 2015 09:42:50 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46FDA9A0 for ; Sat, 13 Jun 2015 09:42:50 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by wigg3 with SMTP id g3so34652136wig.1 for ; Sat, 13 Jun 2015 02:42:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=YSqpnkdUbIpKnANghbE83hEZZAmLaA8ocholFUJHM6M=; b=fKGMCxWCRI68+GLJu6knyajaVLW7hDtw0Xjbh+Vwi6jRCL2JdUJfgOWbNjuZsE5S1V Z9exnUyzkd6GYERwJwVf+OYK1kyC5M2bAu63tAa7Ow4hQRnvtSXsr2dcjZJpnZUxnXZH 3a9pa9H4BPlfHvjHxmwimp8NR5fMAiVjzIeoK71s9IbGy55M+o0hG15KM9k16R9mFtrr C/G2UGG7TJvh4Abhs9ZMnhIn1bOuEn8SR9jUrOtdb0GnG/0Bs27XmKAuFGj9B0ywEnIy m2YQSWm5sQP7CG+DIuTbjQ4Ke36qn12dCBicJTZc/DP8erzV89hb3JYGH9Tcp6J/QnKg xY0g== X-Received: by 10.194.235.4 with SMTP id ui4mr34543344wjc.0.1434188566977; Sat, 13 Jun 2015 02:42:46 -0700 (PDT) Received: from brick.home (eug18.neoplus.adsl.tpnet.pl. [83.20.178.18]) by mx.google.com with ESMTPSA id v3sm6510553wiz.14.2015.06.13.02.42.46 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 13 Jun 2015 02:42:46 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Sat, 13 Jun 2015 11:42:44 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: javocado Cc: FreeBSD Filesystems Subject: Re: growfs failure Message-ID: <20150613094244.GC37870@brick.home> Mail-Followup-To: javocado , FreeBSD Filesystems References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2015 09:42:50 -0000 On 0603T1619, javocado wrote: > While trying to growfs a filesystem, I receive the following error: > > growfs: rdfs: read error: 5812093147771869908: Input/output error > > Here were the steps taken leading up to this point: > > (original file is 300 GB, growing to 500 GB) > > (the filesystem is clean with fsck_ufs /dev/md1) > > geli detach /dev/md1.eli > > mdconfig -d -u 1 > > truncate -s +200G geli.img > > mdconfig -f geli.img -u 1 > > geli resize -s 300G /dev/md1 > > geli attach /dev/md1 > > growfs /dev/md1.eli > > new file systemsize is: 262143999 frags > Warning: 326780 sector(s) cannot be allocated. > growfs: 511840.4MB (1048249216 sectors) block size 16384, fragment size 2048 > using 2786 cylinder groups of 183.72MB, 11758 blks, 23552 inodes. > super-block backups (for fsck -b #) at: > 629476448, 629852704, 630228960, 630605216, 630981472, 631357728, > 631733984, 632110240, > .... > growfs: rdfs: read error: 5812093147771869908: Input/output error I can't reproduce it. What's the FreeBSD version? The output messages above don't match current versions of growfs(8); could you try to upgrade and see if the problem is fixed? From owner-freebsd-fs@FreeBSD.ORG Sat Jun 13 09:43:52 2015 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 77FD3EC1; Sat, 13 Jun 2015 09:43:52 +0000 (UTC) (envelope-from felipemonteiro.carvalho@gmail.com) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0F64A9AC; Sat, 13 Jun 2015 09:43:52 +0000 (UTC) (envelope-from felipemonteiro.carvalho@gmail.com) Received: by wgzl5 with SMTP id l5so12670678wgz.3; Sat, 13 Jun 2015 02:43:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=sszTDdDFWFhG0nRm2U8UecEhY5ypPtXzgME8EIh8zgQ=; b=PPybmkpBoQdXoyTYCnD4ggWby49MbZzxfAe5IOZrcVcevT+QkaIbeApwzz4BcbFpTk Fx+faKu2BJ4yctM7i2D0AJ8hJGxmNf5gdPxd47u2AkdNpyHlmG+AXHuSyLDwD/Q0k9Yk G4c4gc+BxZcVJvKucd7hz3eV16j0HHOrYhWcWL9MCuSBZCrI+U92GJiO+4/LfO8zYD24 ksEFi7oZUQ67HdjFL6vfC2Dknq6XmnnXuexk7w8iOlDLzY4v8aSmtHiSbAhpELLJL1c3 gotPiQ6lFUcbBmx9kJ2kLUBiUEXrOkGStQnxSvCaFK1zCug+opOPN1MWMLrB2HlDDS7I VWxg== X-Received: by 10.194.59.79 with SMTP id x15mr18034422wjq.81.1434188630212; Sat, 13 Jun 2015 02:43:50 -0700 (PDT) Received: from [37.7.124.51] (apn-37-7-124-51.dynamic.gprs.plus.pl. [37.7.124.51]) by mx.google.com with ESMTPSA id m4sm8160080wjb.37.2015.06.13.02.43.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 13 Jun 2015 02:43:48 -0700 (PDT) References: <557B0255.8060809@freebsd.org> Mime-Version: 1.0 (1.0) In-Reply-To: <557B0255.8060809@freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <01184F08-1C6B-4282-9203-1BF98F07A05A@gmail.com> Cc: "freebsd-fs@freebsd.org" X-Mailer: iPhone Mail (11D257) From: felipemonteiro.carvalho@gmail.com Subject: Re: Uberblock location Date: Sat, 13 Jun 2015 11:43:37 +0200 To: Julian Elischer X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2015 09:43:52 -0000 hello, Where can I find the source code that you are mentioning? I am reading the s= ource in https://github.com/zfsonlinux/zfs?files=3D1 but it is very large an= d so far I couldnt pinpoint where it finds the uberblock. Also the mention of bootblock confuses me since ita for booting while I am w= orking in a general case, not necessarely involving boot. thanks, Felipe Enviada do meu iPhone > Em 12/06/2015, =C3=A0s 18:01, Julian Elischer escreve= u: >=20 >> On 6/12/15 9:49 PM, Felipe Monteiro de Carvalho wrote: >> Hello, >>=20 >> I am writing a program to read ZFS partitions, and although I already >> read a lot of documentation, there is 1 problem which is blocking me: >> How does the driver find the uberblock? >>=20 >> I know, I can just get any test volume, find the ZFS uberblock and in >> my case it is positioned in 0x20C00 and there are lots and lots of >> copies (older versions?) of it. >>=20 >> But there is no guarantee that it doesn't just happen to be in this >> position in my image and in another version it would be elsewhere, so >> I need the algorithm utilized to find it. >=20 > I presume you have looked at the zfs reading library in the bootblocks? >=20 >>=20 >> Any ideas? >>=20 >> thanks, >=20 From owner-freebsd-fs@FreeBSD.ORG Sat Jun 13 12:55:21 2015 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C20F9279 for ; Sat, 13 Jun 2015 12:55:21 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 98BA39FC for ; Sat, 13 Jun 2015 12:55:21 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-248-228.lns20.per4.internode.on.net [121.45.248.228]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t5DCtF7L079581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 13 Jun 2015 05:55:18 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <557C282D.8060809@freebsd.org> Date: Sat, 13 Jun 2015 20:55:09 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: felipemonteiro.carvalho@gmail.com CC: "freebsd-fs@freebsd.org" Subject: Re: Uberblock location References: <557B0255.8060809@freebsd.org> <01184F08-1C6B-4282-9203-1BF98F07A05A@gmail.com> In-Reply-To: <01184F08-1C6B-4282-9203-1BF98F07A05A@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2015 12:55:21 -0000 On 6/13/15 5:43 PM, felipemonteiro.carvalho@gmail.com wrote: > hello, > > Where can I find the source code that you are mentioning? I am reading the source in https://github.com/zfsonlinux/zfs?files=1 but it is very large and so far I couldnt pinpoint where it finds the uberblock. why are you posting to a FreeBSD mailing list and looking at Linux sources? Our ZFS code is not there, but in https://svnweb.freebsd.org/base/head/sys/cddl/ I speak of the boot code (at https://svnweb.freebsd.org/base/head/sys/boot/zfs/ specifically, and https://svnweb.freebsd.org/base/head/sys/boot/ in general, because it is a 'stand alone' implementation of a ZFS reader. it could be copied to run as a regular user process. > > Also the mention of bootblock confuses me since ita for booting while I am working in a general case, not necessarely involving boot. > > thanks, > > Felipe > > Enviada do meu iPhone > >> Em 12/06/2015, às 18:01, Julian Elischer escreveu: >> >>> On 6/12/15 9:49 PM, Felipe Monteiro de Carvalho wrote: >>> Hello, >>> >>> I am writing a program to read ZFS partitions, and although I already >>> read a lot of documentation, there is 1 problem which is blocking me: >>> How does the driver find the uberblock? >>> >>> I know, I can just get any test volume, find the ZFS uberblock and in >>> my case it is positioned in 0x20C00 and there are lots and lots of >>> copies (older versions?) of it. >>> >>> But there is no guarantee that it doesn't just happen to be in this >>> position in my image and in another version it would be elsewhere, so >>> I need the algorithm utilized to find it. >> I presume you have looked at the zfs reading library in the bootblocks? >> >>> Any ideas? >>> >>> thanks, > >