> 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 [email protected] http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
