Can ADM ease the pain by migrating data only from one pool to the other. I know it's not what most of you want but...
Mertol Ozyoney Storage Practice - Sales Manager Sun Microsystems, TR Istanbul TR Phone +902123352200 Mobile +905339310752 Fax +902123352222 Email [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Will Murnane Sent: Thursday, August 21, 2008 1:57 AM To: Bob Friesenhahn Cc: zfs-discuss@opensolaris.org Subject: Re: [zfs-discuss] shrinking a zpool - roadmap On Wed, Aug 20, 2008 at 18:40, Bob Friesenhahn <[EMAIL PROTECTED]> wrote: > The errant command which accidentally adds a vdev could just as easily > be a command which scrambles up or erases all of the data. True enough---but if there's a way to undo accidentally adding a vdev, there's one source of disastrously bad human error eliminated. If the vdev is removable, then typing "zpool evacuate c3t4d5" to fix the problem instead of getting backups up to date, destroying and recreating the pool, then restoring from backups saves quite a bit of the cost associated with human error in this case. Think of it as the analogue of "zpool import -D": if you screw up, ZFS has a provision to at least try to help. The recent discussion on accepting partial 'zfs recv' streams is a similar measure. No system is perfectly resilient to human error, but any simple ways in which the resilience (especially of such a large unit as a pool!) can be improved should be considered. Will _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
