Joe Little wrote: > On Tue, May 27, 2008 at 4:50 PM, Eric Schrock <[EMAIL PROTECTED]> wrote: >> Joe - >> >> We definitely don't do great accounting of the 'vdev_islog' state here, >> and it's possible to create a situation where the parent replacing vdev >> has the state set but the children do not, but I have been unable to >> reproduce the behavior you saw. I have rebooted the system during >> resilver, manually detached the replacing vdev, and a variety of other >> things, but I've never seen the behavior you describe. In all cases, >> the log state is kept with the replacing vdev and restored when the >> resilver completes. I have also not observed the resilver failing with >> a bad log device. >> >> Can you provide more information about how to reproduce this problem? >> Perhaps without rebooting into B70 in the middle? >> > > Well, this happened live on a production system, and I'm still in the > process of rebuilding said system (trying to save all the snapshots) > > I don't know what triggered it. It was trying to resilver in B85, > rebooted into B70 where it did resilver (but it was now using cmdk > device naming vs the full scsi device names). It was marked "degraded" > still even though re-silvering finished. Since the resilver took so > long, I suspect the splicing in of the device took place in the B70. > Again, it would never work in B85 -- just kept resetting. I'm > wondering if the device path changing from cxtxdx to cxdx could be the > trigger point.
Joe, We're sorry about your problems. My take on how this is best handled, is that it be be better to expedite (raise priority) fixing the bug 6574286 removing a slog doesn't work rather than expend too much effort in understanding how it failed on your system. You would not have had this problem if you were able to remove a log device. Is that reasonable? Neil. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
