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
