removing / replacing in-use components in gvirstor

[John Nielsen]

Quoting Ivan Voras <ivoras at freebsd.org>:
> On 11/10/2007, Eric Anderson <anderson at 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