On Tue, 2011-01-18 at 13:34 -0800, Philip Brown wrote: > > On Tue, 2011-01-18 at 14:51 -0500, Torrey McMahon > > wrote: > > > > ZFS's ability to handle "short-term" interruptions > > depend heavily on the > > underlying device driver. > > > > If the device driver reports the device as > > "dead/missing/etc" at any > > point, then ZFS is going to require a "zpool replace" > > action before it > > re-accepts the device. If the underlying driver > > simply stalls, then > > it's more graceful (and no user interaction is > > required). > > > > As far as what the resync does: ZFS does "smart" > > resilvering, in that > > it compares what the "good" side of the mirror has > > against what the > > "bad" side has, and only copies the differences over > > to sync them up. > > > > Hmm. Well, we're talking fibre, so we're very concerned with the recovery > mode when the fibre drivers have marked it as "failed". (except it hasnt > "really" failed, we've just had a switch drop out) > > I THINK what you are saying, is that we could, in this situation, do: > > zpool replace (old drive) (new drive) > > and then your "smart" recovery, should do the limited resilvering only. Even > for potentially long outages. > > Is that what you are saying?
Yes. It will always look at the "replaced" drive to see if it was a prior member of the mirror, and do smart resilvering if possible. If the device path stays the same (which, hopefully, it should), you can even do: zpool replace (old device) (old device) -- Erik Trimble Java System Support Mailstop: usca22-317 Phone: x67195 Santa Clara, CA Timezone: US/Pacific (GMT-0800) _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
