Eric and Richard - thanks for your responses. I tried both:
echo ::spa -c | mcb zdb -C (not much of a man page for this one!) and was able to match the POOL id from the log (hex 4fcdc2c9d60a5810) with both outputs. As Richard pointed out, I needed to convert the hex value to decimal to get a match with the zdb output. In neither case, however, was I able to get a match with the disk vdev id from the fmdump output. It turns out that a disk in this machine was replaced about a month ago, and sure enough the vdev that was complaining at the time was the 0x179e471c0732582 vdev that is now missing. What's confusing is that the fmd message I posted about is dated Oct 22 whereas the original error and replacement happened back in September. An "fmadm faulty" on the machine currently doesn't return any issues. After physically replacing the bad drive and issuing the "zpool replace" command, I think that we probably issued the "fmadm repair <uuid>" command in line with what Sun has asked us to do in the past. In our experience, if you don't do this then fmd will re-issue duplicate complaints regarding hardware failures after every reboot until you do. In this case, perhaps a "repair" wasn't really the appropriate command since we actually replaced the drive. Would a "fmadm flush" have been better? Perhaps a clean reboot is in order? So, it looks like the root problem here is that fmd is confused rather than there being a real issue with ZFS. Despite this, we're happy to know that we can now match vdevs against physical devices using either the mdb trick or zdb. We've followed Eric's work on ZFS device enumeration for the Fishwork project with great interest - hopefully this will eventually get extended to the fmdump output as suggested. Sean Walmsley -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
