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

-----Original Message-----
[mailto:[EMAIL PROTECTED] On Behalf Of Will Murnane
Sent: Thursday, August 21, 2008 1:57 AM
To: Bob Friesenhahn
Subject: Re: [zfs-discuss] shrinking a zpool - roadmap

On Wed, Aug 20, 2008 at 18:40, Bob Friesenhahn
> 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.

zfs-discuss mailing list

zfs-discuss mailing list

Reply via email to