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

Reply via email to