From owner-freebsd-fs@FreeBSD.ORG Mon Jun 22 07:43:20 2015 Return-Path: Delivered-To: freebsd-fs@nevdull.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 8C9B25CB for ; Mon, 22 Jun 2015 07:43:20 +0000 (UTC) (envelope-from quartz@sneakertech.com) Received: from douhisi.pair.com (douhisi.pair.com [209.68.5.179]) (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 6B8D59F for ; Mon, 22 Jun 2015 07:43:20 +0000 (UTC) (envelope-from quartz@sneakertech.com) Received: from [10.2.2.1] (pool-173-48-121-235.bstnma.fios.verizon.net [173.48.121.235]) by douhisi.pair.com (Postfix) with ESMTPSA id AD7E63F6AB for ; Mon, 22 Jun 2015 03:43:18 -0400 (EDT) Message-ID: <5587BC96.9090601@sneakertech.com> Date: Mon, 22 Jun 2015 03:43:18 -0400 From: Quartz User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Freebsd fs Subject: Re: ZFS pool restructuring and emergency repair References: <5584C0BC.9070707@sneakertech.com> In-Reply-To: <5584C0BC.9070707@sneakertech.com> Content-Type: text/plain; charset=ISO-8859-1; 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: Mon, 22 Jun 2015 07:43:20 -0000 > - A server is set up with a pool created a certain way, for the sake of > argument let's say it's a raidz-2 comprised of 6x 2TB disks. There's > only actually ~1TB of data currently on the server though. Let's say > there's a catastrophic emergency where one of the disks needs to be > replaced, but the only available spare is an old 500GB. As I understand > it, you're basically SOL. Even though a 6x500 (really 4x500) is more > than enough to hold 1Tb of data, you can't do anything in this situation > since although ZFS can expand a pool to fit larger disks, it can't > shrink one under any circumstance. Is my understanding still correct or > is there a way around this issue now? So I take it that, aside from messing with a gvirstor/ sparse disk image, there's still no way to really handle this because there's still no way to shrink a pool after creation?