There's definately something strange going on as these are the only uberblocks I can find by scanning /dev/dsk/c0t0d0s7 - nothing to conflict with my theory so far:
TXG: 106052 TIME: 2009-01-04:11:06:12 BLK: 0e29000 (14848000) VER: 10 GUID_SUM: 9f8d9ef301489223 (11497020190282519075) TXG: 106052 TIME: 2009-01-04:11:06:12 BLK: 0e69000 (15110144) VER: 10 GUID_SUM: 9f8d9ef301489223 (11497020190282519075) TXG: 106053 TIME: 2009-01-04:11:06:42 BLK: 0e29400 (14849024) VER: 10 GUID_SUM: 9f8d9ef301489223 (11497020190282519075) TXG: 106053 TIME: 2009-01-04:11:06:42 BLK: 0e69400 (15111168) VER: 10 GUID_SUM: 9f8d9ef301489223 (11497020190282519075) skipped 248 blocks... TXG: 114710 TIME: 2009-01-07:11:14:10 BLK: 0e1d800 (14800896) VER: 10 GUID_SUM: 9f8d9ef301489223 (11497020190282519075) TXG: 114710 TIME: 2009-01-07:11:14:10 BLK: 0e5d800 (15063040) VER: 10 GUID_SUM: 9f8d9ef301489223 (11497020190282519075) TXG: 114715 TIME: 2009-01-07:11:15:41 BLK: 0e1ec00 (14806016) VER: 10 GUID_SUM: 9f8d9ef301489223 (11497020190282519075) TXG: 114715 TIME: 2009-01-07:11:15:41 BLK: 0e5ec00 (15068160) VER: 10 GUID_SUM: 9f8d9ef301489223 (11497020190282519075) TXG: 1830158 TIME: 2008-11-20:08:46:41 BLK: 0023800 (145408) VER: 4 GUID_SUM: 9ab0d28ccc7d2e94 (11146640579909987988) TXG: 1830158 TIME: 2008-11-20:08:46:41 BLK: 0063800 (407552) VER: 4 GUID_SUM: 9ab0d28ccc7d2e94 (11146640579909987988) TXG: 1830382 TIME: 2008-11-20:09:05:20 BLK: 003b800 (243712) VER: 4 GUID_SUM: 9ab0d28ccc7d2e94 (11146640579909987988) TXG: 1830382 TIME: 2008-11-20:09:05:20 BLK: 007b800 (505856) VER: 4 GUID_SUM: 9ab0d28ccc7d2e94 (11146640579909987988) skipped 248 blocks... TXG: 1832026 TIME: 2008-11-20:11:22:18 BLK: 0036800 (223232) VER: 4 GUID_SUM: 9ab0d28ccc7d2e94 (11146640579909987988) TXG: 1832026 TIME: 2008-11-20:11:22:18 BLK: 0076800 (485376) VER: 4 GUID_SUM: 9ab0d28ccc7d2e94 (11146640579909987988) TXG: 1832027 TIME: 2008-11-20:11:22:19 BLK: 0036c00 (224256) VER: 4 GUID_SUM: 9ab0d28ccc7d2e94 (11146640579909987988) TXG: 1832027 TIME: 2008-11-20:11:22:19 BLK: 0076c00 (486400) VER: 4 GUID_SUM: 9ab0d28ccc7d2e94 (11146640579909987988) # zdb -l /dev/dsk/c0t0d0s7 -------------------------------------------- LABEL 0 -------------------------------------------- version=4 name='zpool' state=0 txg=1809157 pool_guid=17419375665629462002 top_guid=12174008987990077602 guid=12174008987990077602 vdev_tree type='disk' id=0 guid=12174008987990077602 path='/dev/dsk/c0t0d0s7' devid='id1,s...@n5000cca321ca2647/h' whole_disk=0 metaslab_array=14 metaslab_shift=30 ashift=9 asize=129904410624 DTL=24 -------------------------------------------- LABEL 1 -------------------------------------------- version=4 name='zpool' state=0 txg=1809157 pool_guid=17419375665629462002 top_guid=12174008987990077602 guid=12174008987990077602 vdev_tree type='disk' id=0 guid=12174008987990077602 path='/dev/dsk/c0t0d0s7' devid='id1,s...@n5000cca321ca2647/h' whole_disk=0 metaslab_array=14 metaslab_shift=30 ashift=9 asize=129904410624 DTL=24 -------------------------------------------- LABEL 2 -------------------------------------------- -------------------------------------------- LABEL 3 -------------------------------------------- -Steve > After having a think I've come up with the following > hypothesis: > > 1) When I was on Solaris 10u4 things were working > fine. > 2) When I re-installed with Solaris 10u6 and imported > the zpool (with zpool import -f), it created a > zpool.cache file and didn't update the on disk data > structures for some reason. > 3) When I re-installed Solaris 10u6, I lost the > zpool.cache file and now zfs looks at the data > structures on the disk and they are inconsistent. > > Could the above have actually happened? It would > explain what I'm seeing. > > -Steve -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss