Date: Thu, 11 Oct 2007 08:58:28 -0400 From: John Nielsen <lists@jnielsen.net> To: Ivan Voras <ivoras@freebsd.org> Cc: freebsd-geom@freebsd.org Subject: Re: removing / replacing in-use components in gvirstor Message-ID: <20071011085828.kpk7zrp4owok0wks@newwebmail.jnielsen.net>
next in thread | raw e-mail | index | archive | help
Quoting Ivan Voras <ivoras@freebsd.org>: > On 11/10/2007, Eric Anderson <anderson@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071011085828.kpk7zrp4owok0wks>