> Jeremy Teo wrote:
> > On the issue of the ability to remove a device from
> a zpool, how
> > useful/pressing is this feature? Or is this more
> along the line of
> > "nice to have"?
> 
> This is a pretty high priority.  We are working on
> it.

Good news!  Where is the discussion on the best approach to take?

> On 18/01/2007, at 9:55 PM, Jeremy Teo wrote:
> The most common reason is migration of data to new
> storage  
> infrastructure. The experience is often that the
> growth in disk size  
> allows the new storage to consist of fewer disks/LUNs
> than the old.

I agree completely.  No matter how wonderful your current FC/SAS/whatever 
cabinet is, at some point in the future you will want to migrate to another 
newer/faster array with a better/faster interface, probably on fewer disks.  
The "just add another top level vdev" approach to growing a RAIDZ pool seems a 
bit myopic.

> On Thu, 2007-01-18 at 10:51 -0800, Matthew Ahrens
> wrote:
> I'd consider it a lower priority than say, adding a
> drive to a RAIDZ
> vdev, but yes, being able to reduce a zpool's size by
> removing devices
> is quite useful, as it adds a considerable degree of
> flexibility that
> (we) admins crave.

These two items (removing a vdev and restriping an array) are probably closely 
related.  At the core of either operation likely will center around some 
metaslab_evacuate() routine which empties a metaslab and puts the data onto 
another metaslab.

Evacuating a vdev could be no more than evacuating all of the metaslabs in the 
vdev.

Restriping (adding/removing a data/parity disk) could be no more than 
progressively evacuating metaslabs with the old stripe geometry and writing the 
data to metaslabs with the new stripe geometry.  The biggest challenge while 
restriping might be getting the read routine to figure out on-the-fly which 
geometry is in use for any particular stripe.  Even so, this shouldn't be too 
big of a challenge: one geometry will checksum correctly and the other will not.

Marty
 
 
This message posted from opensolaris.org
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to