This only seems valuable in the case of an unreplicated pool.  We
already have 'zpool offline' to take a device and prevent ZFS from
talking to it (because it's in the process of failing, perhaps).  This
gives you what you want for mirrored and RAID-Z vdevs, since there's no
data to migrate anyway.

We are also planning on implementing 'zpool remove' (for more than just
hot spares), which would allow you to remove an entire toplevel vdev,
migrating the data off of it in the process.  This would give you what
you want for the case of an unreplicated pool. 

Does this satisfy the usage scenario you described?

- Eric

On Sun, Jun 11, 2006 at 07:52:37AM -0600, Gregory Shaw wrote:
> Pardon me if this scenario has been discussed already, but I haven't  
> seen anything as yet.
> 
> I'd like to request a 'zpool evacuate pool <device>' command.    
> 'zpool evacuate' would migrate the data from a disk device to other  
> disks in the pool.
> 
> Here's the scenario:
> 
> Say I have a small server with 6x146g disks in a jbod  
> configuration.   If I mirror the system disk with SVM (currently) and  
> allocate the rest as a non-raidz pool, I end up with 4x146g in a pool  
> of approximately 548gb capacity.
> 
> If one of the disks is starting to fail, I would need to use 'zpool  
> replace new-disk old-disk'.  However, since I have no more slots in  
> the machine to add a replacement disk, I'm stuck.
> 
> This is where a 'zpool evacuate pool <device>' would come in handy.   
> It would allow me to evacuate the failing device so that it could be  
> replaced and re-added with 'zpool add pool <device>'.
> 
> What does the group think?
> 
> Thanks!
> 
> -----
> Gregory Shaw, IT Architect
> Phone: (303) 673-8273        Fax: (303) 673-8273
> ITCTO Group, Sun Microsystems Inc.
> 1 StorageTek Drive MS 4382              [EMAIL PROTECTED] (work)
> Louisville, CO 80028-4382                 [EMAIL PROTECTED] (home)
> "When Microsoft writes an application for Linux, I've Won." - Linus  
> Torvalds
> 
> 
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

--
Eric Schrock, Solaris Kernel Development       http://blogs.sun.com/eschrock
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to