From owner-freebsd-geom@FreeBSD.ORG Thu Oct 11 12:58:29 2007 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1349316A420; Thu, 11 Oct 2007 12:58:29 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.freebsd.org (Postfix) with ESMTP id D75D313C4C3; Thu, 11 Oct 2007 12:58:28 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from ns1.jnielsen.net (jn@ns1 [69.55.238.237]) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id l9BCwSAU085397; Thu, 11 Oct 2007 08:58:28 -0400 (EDT) (envelope-from lists@jnielsen.net) Received: (from www@localhost) by ns1.jnielsen.net (8.12.9p2/8.12.9/Submit) id l9BCwSMw085396; Thu, 11 Oct 2007 08:58:28 -0400 (EDT) (envelope-from lists@jnielsen.net) X-Authentication-Warning: ns1.jnielsen.net: www set sender to lists@jnielsen.net using -f Received: from nc-2wac-zop08.wachovia.com (nc-2wac-zop08.wachovia.com [162.111.235.19]) by newwebmail.jnielsen.net (Horde MIME library) with HTTP; Thu, 11 Oct 2007 08:58:28 -0400 Message-ID: <20071011085828.kpk7zrp4owok0wks@newwebmail.jnielsen.net> Date: Thu, 11 Oct 2007 08:58:28 -0400 From: John Nielsen To: Ivan Voras MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) / FreeBSD-4.9 X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on ns1.jnielsen.net X-Virus-Status: Clean Cc: freebsd-geom@freebsd.org Subject: Re: removing / replacing in-use components in gvirstor X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2007 12:58:29 -0000 Quoting Ivan Voras : > On 11/10/2007, Eric Anderson wrote: >> > In thinking about how I personally would use it, I realized I would add >> > drives to a system until I ran out of slots or controller connections, and >> > then want to upgrade to larger drives. From the manpage (and the code) it >> > doesn't look like this is currently possible unless the drive you want to >> > replace happens to be unused. How feasible would it be to either extend >> > the "remove" verb to migrate in-use chunks to other (existing) >> providers or >> > create a "replace" verb to migrate in-use chunks to a new provider? >> >> I wonder if making each drive a member of a single-device mirror, and >> then including all the mirrors into the gvirstor GEOM would do the >> trick. That way, you can simply add a new drive to the mirrorset you >> want to replace, let the mirror sync, and then pop the old drive out. I >> think the only remaining step is to re-mirror the mirror, or extend the >> mirror or partition.. I was thinking along the same lines after I wrote yesterday, but I couldn't of an existing non-destructive way to extend the mirror. I thought about even doing some kind of virstor->mirror->virstor nesting, but I'm not sure that would work with gmirror, since it would try to sync ALL of the blocks of its (inner) virstor, and not just the ones in use. (correct me if I'm wrong.) Perhaps a mirror zpool could do it, but in either case the main (outer) virstor would have no knowledge of the real vs. virtual capacity of the inner members and so would likely oversubscribe one member (necessitating an expansion) while other members still had plenty of space. > I plan to add offline drive-replacing verb to the userland utility but > yes, that would also work. Sounds like a great place to start. Thanks! JN