On Tue, Jul 18, 2006 at 09:46:44AM -0400, Chad Mynhier wrote: > On 7/18/06, Brian Hechinger <[EMAIL PROTECTED]> wrote: > >On Tue, Jul 18, 2006 at 01:27:21AM -0700, Jeff Bonwick wrote: > >> > >> the ability to remap blocks would be *so* useful -- it would > >> enable compression of preexisting data, removing devices from > >> a pool, automatically moving cold data to slower devices, etc. > > > >Being able to remove devices from a pool would be a good thing. I can't > >personally think of any reason that I would ever do it, but a friend of > >mine keeps asking me why it can't do it and that it should be able to. > > > >-brian > > This situation is implicitly included in what Jeff said, but live data > migration is a good example of where this would come in handy. When > it comes time to replace your big storage array with a newer model (or > your 250GB drive with a 750GB drive), you could simply add the new > storage to an existing pool and then remove the old storage from the > pool. You need to wait for all of the data to be migrated, but in the > meantime the data is available to users. You'd be able to do this > with no significant downtime. And if the data migration happens at a > suitably low priority, there's not even a performance hit.
Size upgrades you can do in place, and even migrating to a new shelf you can do in place as well (replace individual disk in old shelf with individual disk in new chelf). The only place the removing disks from the pool would be useful in this scenario would be if the new array had a fewer number of larger disks. -brian _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
