Yes, if zpool remove works like you describe, it does the same
thing. Is there a time frame for that feature?
Thanks!
On Jun 11, 2006, at 10:21 AM, Eric Schrock wrote:
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
-----
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
