Hi Erik, Erik Gulliksson wrote: > Hi, > > I have a zfs-pool (unfortunately not setup according to the Best > Practices Guide) that somehow got corrupted after a spontaneous server > reboot. On Solaris 10u4 the machine simply panics when I try to import > the pool.
Panic stack would be useful. > So what I've done is taken a dd-image of the whole LUN so > that I have something to lab with without breaking original data. Then > I've installed Solaris Express b95 (in a virtual machine) and made the > disk image visible via iSCSI. This in hope that the newer zfs-code in > b95 would be able to import the pool. > > Here is the output of some hopefully relevant commands to you zfs-gurus :) > > bash-3.2# zpool import > pool: data1 > id: 16337833607404088147 > state: ONLINE > status: The pool is formatted using an older on-disk version. > action: The pool can be imported using its name or numeric identifier, though > some features will not be available without an explicit 'zpool > upgrade'. > config: > data1 ONLINE > c2t2d0 ONLINE > > bash-3.2# zpool import data1 > cannot import 'data1': pool may be in use from other system > use '-f' to import anyway > > bash-3.2# zpool import -f data1 > (when sniffing the iscsi-traffic there is an initial burst of requests > and data, but then the command zpool hangs forever and can't even be > kill-9'd) It is apparently blocked somewhere in kernel. Try to do something like this from another window to get better idea: echo "<pid of zpool>::pid2proc|::walk thread|::findtsack -v" | mdb -k echo "::threadlist -v" | mdb -k Some useful information may be logged in FMA, try to see what is available there with fmdump -eV On Nevada you can try the following to (same option repeated several times increases verbosity): zdb -e -bb data1 zdb -e -dddd data1 This may take a while on 6 Tb pool depending on how full it is... > bash-3.2# zdb -l /dev/rdsk/c2t2d0s0 > -------------------------------------------- > LABEL 0 > -------------------------------------------- > version=3 > name='data1' > state=0 > txg=696136211 > pool_guid=16337833607404088147 > top_guid=8756997626625498593 > guid=8756997626625498593 > vdev_tree > type='disk' > id=0 > guid=8756997626625498593 > path='/dev/dsk/c6t213d0s0' > devid='id1,[EMAIL PROTECTED]/a' > whole_disk=1 > metaslab_array=13 > metaslab_shift=35 > ashift=9 > asize=6499480109056 > DTL=17 > (3 more labels with same content follows here) > > bash-3.2# zdb -uuu -e data1 > Uberblock > magic = 0000000000bab10c > version = 3 > txg = 698279317 > guid_sum = 6648087160320035124 > timestamp = 1214932560 UTC = Tue Jul 1 19:16:00 2008 > rootbp = [L0 DMU objset] 400L/200P DVA[0]=<0:56800000200:200> > DVA[1]=<0:3000020200:200> DVA[2]=<0:48800001800:200> fletcher4 lzjb LE > contiguous birth=698279317 fill=189 > cksum=89744d6d8:36e7cf71f81:b1d06b2acd36:1850b4cc5621f3 > > I have also tried to blindly execute the commands described by > signature kangurek in > <http://www.opensolaris.org/jive/thread.jspa?messageID=220125> but > without success. > > Without about knowing much about zfs, I couldn't help but notice that > the txg ids differs in the label and uberblock. Is this normal? Yes. Btw, why does timestamp on your uberblock show July 1? wbr, victor _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
