From owner-freebsd-questions@FreeBSD.ORG Fri Jun 19 16:16:43 2015 Return-Path: Delivered-To: freebsd-questions@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 DC7F825D for ; Fri, 19 Jun 2015 16:16:43 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 62575ABB for ; Fri, 19 Jun 2015 16:16:43 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from ox-dell39.ox.adestra.com (no-reverse-dns.metronet-uk.com [85.199.232.226] (may be forged)) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.15.1/8.15.1) with ESMTPSA id t5JGGcT9002107 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 19 Jun 2015 17:16:38 +0100 (BST) (envelope-from m.seaman@infracaninophile.co.uk) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=infracaninophile.co.uk DKIM-Filter: OpenDKIM Filter v2.9.2 smtp.infracaninophile.co.uk t5JGGcT9002107 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infracaninophile.co.uk; s=201001-infracaninophile; t=1434730598; bh=gPxib//6c5lHvJ9J0wSZ0EZaRvrvjDZt+DFUQ0/VBho=; h=Date:From:To:Subject:References:In-Reply-To; z=Date:=20Fri,=2019=20Jun=202015=2017:16:31=20+0100|From:=20Matthew =20Seaman=20|To:=20freebsd-questi ons@freebsd.org|Subject:=20Re:=20Expanding=20zfs+geli=20pool|Refer ences:=20<55843CF1.1070709@gundogan.us>|In-Reply-To:=20<55843CF1.1 070709@gundogan.us>; b=zZUQ1GFzMlCxbLh6MqDaY0MktXlCr6cuUeQDmM1uOuDVL75SQKHLBwoyL/NOZAhPW MesfTwjcVOzeV8xae7Qzjchdya1gvmlGvm+scEL2gScjoX2jCxwshbqlfGfSrzJQrL aYIgmk8h1rY1p8h5yVQyCTsiHpfGyuU0LbQ/9psY= X-Authentication-Warning: lucid-nonsense.infracaninophile.co.uk: Host no-reverse-dns.metronet-uk.com [85.199.232.226] (may be forged) claimed to be ox-dell39.ox.adestra.com Message-ID: <5584405F.7020407@infracaninophile.co.uk> Date: Fri, 19 Jun 2015 17:16:31 +0100 From: Matthew Seaman User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: freebsd-questions@freebsd.org Subject: Re: Expanding zfs+geli pool References: <55843CF1.1070709@gundogan.us> In-Reply-To: <55843CF1.1070709@gundogan.us> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="CFIggP7EGPA2MixpR2xEdOCMvGw4Cv85C" X-Virus-Scanned: clamav-milter 0.98.7 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-1.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on lucid-nonsense.infracaninophile.co.uk X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 16:16:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CFIggP7EGPA2MixpR2xEdOCMvGw4Cv85C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 06/19/15 17:01, Emre Gundogan wrote: > I have a 4-disk (2TB each) striped mirrored zfs pool consisting of geli= > vdevs in the following configuration: >=20 > pool: > mirror1: > disk1 (2TB) > disk2 (2TB) > mirror2 > disk3 (2TB) > disk4 (2TB) >=20 > I'd like to replace those disks with 4TB ones to essentially double the= > capacity of the pool. What's the recommended order of disks to 'zpool > offline/replace/resilver (automatic)' in this case? In sequence, or can= > I replace them in the following order: disk1 -> disk3 -> disk2 -> disk4= > ? Considering that two of the 4TB disks I am thinking of using in the > grown pool are few months older than the others, I thought putting the > older ones in separate mirrors would reduce the risk of pool becoming > unavailable when they fail (possibly both together at the same time). > Does this make sense, and is it possible to replace them in the odd > order I described? Just a note: I only have 4 SATA ports available on > this machine, and therefore can't have both old and replacement disk > plugged in at the same time. So long as you ensure that only one drive out of each vdev is replaced at a time, and that resilvering has completed before you replace the other one, then, subject to those constraints, the ordering doesn't matter. The order you describe would work fine. Ideally, yes, adding the new drives to the mirror before removing the old ones would be better, but as your hardware doesn't support that, you're going to have to accept a period of lower resilience while all of the resilvering goes on. Yes, making each mirrored vdev contain on new and one older drive would be sensible. Check the setting of the 'autoexpand' property on the zpool before you begin. I your shoes I'd set autoexpand=3Doff and then issue an explicit zpool online -e pool disk1 disk2 disk3 disk4 after all the resilvering is done so that you're in control of when the expanded space becomes available. Cheers, Matthew --CFIggP7EGPA2MixpR2xEdOCMvGw4Cv85C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVhEBfAAoJEABRPxDgqeTnxF0QAJ/Wo6ghNKD1/RJlM97Gxx8G rdcWLJUnDLIW9AMrt++sERQZhnL/DqkypMVNjK6CKBML3qYXHJu7ugHTOubzz2C9 GwmFdu2yI4f8Z5gAJfdNw6PjtZkdPQmx8zXIHlvOsSVHw7YSWHdpNz5C4hv3eCFc 6m+mnc3ZXFSSkngDjwLDHAknPB4LQCm0bLoX1IkCCjwrg9mDW6A2VGlZ08uLl99F f4Z2QKTtbG6+PAeJyDDAZZBX0KYRmJG4CvpLKkDV7gClz2f8OsrHAntLK9PE5AS4 4y1+zRvLb/AtJswaVqicQPg6oF8VYEbiD7EIjFHQrkLmI1r3yUXzdQXLOUCKRtgo 1YKF3w3JqH4CZj7i7m/FiXRAOfikvN5aXSgDSrdUNkbPeG3OYQz0fh4qktyAf5ay pgoH7IoFIa1M4Deu8Ewz7rNm4BUY0dy0JRu0Vy2vQMTdEiGVjdxWSPbFj5PgFJFT QihacZ2tMxcLuXdrudMJr6Q273RWDKFoDoE/MRVxVww95hTV5S4LNozCdSfPNYQ1 lUG0xyN8EOwcg7837cg1uGznfvzIWIxCVJgp9OeB5yU4NOb7i2pGT5dcK1Ytd6tM n8gN99p3BcWpiTPw5M4M9NQ4rKP0zBqPz6/jobNIxejQjrUUtBxWjy5jNoBIDtEe R9ScXm7n7iuBdcWrO1rq =AKqi -----END PGP SIGNATURE----- --CFIggP7EGPA2MixpR2xEdOCMvGw4Cv85C--